Codex /goal 不是自动驾驶:停止条件才是方向盘

“把这个项目彻底优化一下。”

第二天早上，Agent 还在工作。

它修改了几十个文件，升级了依赖，重写了部分模块，跑过几轮测试，还留下了一份看起来很完整的总结。

最麻烦的情况不是它失败了。

而是它非常努力地完成了一个错误目标。

传统对话模式里，模糊需求通常只浪费一轮回答。

进入 /goal 之后，模糊需求可能被持续执行、自动续跑，并在多轮上下文压缩后继续影响后续行动。

所以 /goal 最重要的问题不是：

它能不能一直工作？

而是：

它什么时候应该继续，什么时候应该停，什么证据才能证明真的完成？

先给结论：Goal mode 放大的不是能力，而是目标质量

截至 2026 年 7 月 15 日，Codex Goal mode 已经不再只是实验功能。

OpenAI 在 2026 年 5 月 21 日的 Codex 更新中宣布，Goal mode 退出实验状态，可在 Codex App、IDE 和 CLI 中使用。

它解决的是一个真实问题：

普通 Agent 任务经常被单轮上下文、人工确认和中途暂停打断。

Goal mode 会保存目标状态，在自动续跑时重新注入目标、完成条件和审计要求，让任务可以持续数小时甚至数天。

但它不是“自动驾驶按钮”。

更准确的理解是：

/goal 是一个会持续生效的工程合同。

合同写得清楚，自主性可以放大效率。

合同写得模糊，自主性就会放大返工、越界和错误方向。

可以用一个简单关系理解：

这篇文章提供三个信息增量：

• 一套原创的 GATE 目标合同框架。

• 一张截至 2026-07-15 的旧经验与当前事实对照图。

• 一套判断任务是否适合 /goal 的清晰度与可验证性矩阵。

/goal 真正保存的，不只是一个提示词

原文详细介绍了 /goal 的启动、暂停、恢复、预算和完成审计。

这些操作很重要。

但如果只把 /goal 理解成“让 Codex 持续工作的命令”，仍然会低估它。

Goal mode 实际上维护了一个任务状态。

这个状态至少包含：

• 当前目标。

• 是否处于活动状态。

• 已使用的上下文和预算信息。

• 任务应该何时完成。

• 什么情况下可以判定阻塞。

官方使用方式很直接：

/goal <objective> /goal /goal pause /goal resume /goal clear 

第一条创建目标。

第二条查看当前状态。

后面三条分别用于暂停、恢复和清理。

关键不在于命令数量。

关键在于 Goal 有明确的生命周期：

OpenAI 当前的 Goal continuation prompt 对“完成”和“阻塞”有严格约束。

它要求只有在目标真实达成、没有必需工作剩余时，才能标记完成。

只有同一阻塞条件连续重复多次、Agent 确实无法继续时，才能标记阻塞。

这说明官方设计 Goal mode 时，关注的并不是单纯“多跑几轮”。

而是如何避免 Agent 因为疲劳式总结而过早宣布完成。

信息增量：用 GATE 把愿望改造成工程合同

我建议在启动 /goal 前，先检查目标是否包含 

G：Ground truth，起点事实

第一步不是告诉 Agent 要做什么。

而是告诉它从哪里建立事实。

例如：

• 先读哪些代码和文档。

• 当前失败的测试是什么。

• 哪个接口或页面是现有行为基线。

• 哪些日志和数据可以视为事实来源。

如果没有起点事实，Agent 很容易通过猜测建立任务模型。

任务越长，最初的错误假设越可能被后续步骤不断强化。

A：Acceptance，验收证据

不要只写“完成迁移”“优化性能”或“修复所有问题”。

要明确什么证据可以证明完成。

例如：

• 指定测试全部通过。

• 构建产物可以生成。

• 性能指标达到阈值。

• 页面截图符合预期。

• 数据迁移前后数量一致。

• 关键接口的契约测试通过。

验收标准必须能被重复执行。

“代码看起来合理”和“Agent 说已经完成”都不是验收证据。

T：Taboo，禁止边界

长任务最容易忽略的是禁止项。

至少要写清楚：

• 哪些目录不能修改。

• 是否允许联网。

• 是否允许安装依赖。

• 是否可以读取密钥或生产配置。

• 是否允许操作数据库和云资源。

• 哪些兼容性约束不能破坏。

Goal mode 的价值来自持续执行。

但持续执行也意味着一次越界可能被扩散到更多步骤。

E：Exit，退出条件

最后必须定义什么时候停。

退出条件至少分四类：

• 完成：哪些证据齐全后可以结束。

• 暂停：遇到哪些风险必须等待人工确认。

• 阻塞：缺少什么信息时不能继续猜测。

• 清理：哪些临时文件、进程和实验改动必须恢复。

没有退出条件的 Goal，不是长期任务。

它只是一个可以自动续费的模糊愿望。

最新变化：旧教程中的四条经验需要更新

Goal mode 的迭代速度很快。

原文中的大部分操作思路仍然有价值，但截至 2026-07-15，有四个细节需要按最新官方资料修正。

Codex 化一：Goal mode 已退出实验状态

旧版本需要手动打开实验功能。

当前官方更新记录显示，Goal mode 已在 App、IDE 和 CLI 中可用。

不过，OpenAI 的使用页面仍保留了一个兼容性提示：

如果 /goal 没有出现在斜杠菜单中，可以在配置里启用：

[features] goals = true 

更合理的排查顺序是：

1. 先升级 Codex。

2. 检查 /goal 是否已经存在。

3. 命令确实缺失时，再使用功能配置兜底。

变化二：不要默认给每个 Goal 设置 token budget

原文建议通过预算避免失控，这个出发点没有问题。

但 Codex 当前开源代码对预算字段的要求更谨慎：

只有用户明确要求 token budget 时才设置。

原因也很现实。

如果 Agent 自己在目标里生成一个预算，这个数字并不一定代表用户真实意图。

它可能反而制造过早停止、错误完成或“为了省预算而降低验证”的行为。

更好的做法是：

• 对时间或费用敏感的任务，由用户明确设置预算。

• 对普通工程任务，优先设置阶段检查点和验收标准。

• 不要让 Agent 自己发明预算，再把它当成硬约束。

变化三：暂停状态要用 /goal pause

一条公开 issue 报告了一个很容易踩中的坑：

用户在对话里说“停止”或“暂停”，Agent 可能停止当前动作，但 Goal 的活动状态不一定同步暂停。

下一次自动续跑到来时，任务仍可能继续。

所以控制 Goal 状态时，应使用明确命令：

/goal pause 

自然语言可以表达意图。

斜杠命令负责修改状态。

不要把两者混为一谈。

变化四：不要假设 /goal 里的 $skill 一定会持续激活

截至 2026-07-15，OpenAI Codex 仓库里有一条很新的公开 issue：

当用户在 /goal 目标中显式写入 $skill-name 时，Skill 可能只被保存成普通文本，没有在自动续跑中重新激活对应 Skill 指令。

这是一条公开问题报告，不代表所有版本都会复现。

但它提醒我们：

• 关键安全规则不要只依赖一次 Skill 触发。

• 稳定规则应该写进项目的 AGENTS.md 或目标合同。

• 创建 Goal 前先确认必要 Skill 已经加载。

• 自动续跑过程中要检查能力和规则是否仍然生效。

反方观点：既然限制这么多，为什么不直接用普通任务？

这是合理问题。

如果每个目标都要写合同、设边界、做验收，Goal mode 会不会反而更麻烦？

答案是：

并不是所有任务都应该进入 /goal。

/goal 最适合两类特征同时存在的任务：

1. 任务需要持续多个步骤。

2. 结果可以被明确验证。

可以用下面的矩阵判断：

例如，“把指定服务从旧认证库迁移到新认证库，并通过现有集成测试”适合 Goal。

“研究一下怎样让产品更好”不适合。

前者有边界、有产物、有测试。

后者连成功意味着什么都没有定义。

一个坏 Goal 和一个可执行 Goal 的区别

下面这个目标看起来积极，实际风险很高：

/goal 全面优化这个项目，修复所有问题并提高性能。 

它缺少范围、事实来源、验收证据和退出条件。

Agent 可以无限扩展“所有问题”的定义。

更可执行的写法是：

/goal 将 auth-service 从旧认证中间件迁移到新版 SDK。  Ground truth: - 先读取 auth-service/README.md、现有集成测试和迁移说明。 - 以当前公开 API 行为作为兼容性基线。  Acceptance: - auth-service 的单元测试和集成测试全部通过。 - 构建成功，不新增高危依赖。 - 输出修改文件、测试结果和未解决风险。  Taboo: - 不修改 payment-service。 - 不读取生产密钥，不操作线上环境。 - 安装新依赖和访问外部网络前先确认。  Exit: - 缺少 SDK 凭据或需求冲突时暂停并说明阻塞。 - 验收证据齐全后才能标记完成。 - 清理临时文件和后台进程。 

这段目标不依赖华丽提示词。

它只是把工程团队原本隐含的交付合同写了出来。

给开发者：使用 /goal 前做这 7 项检查

1. 先判断任务是否可验证

无法描述成功证据，就不要启动长期自主执行。

2. 模糊任务先 /plan

先澄清范围、依赖和风险，再把稳定计划转换成 Goal。

3. 把禁止项和完成项写在一起

只写“要做什么”不够，还要写“不能做什么”。

4. 用 /goal pause 控制状态

不要只在普通对话里说“先停一下”。

5. 设置阶段检查点，而不是迷信 token budget

例如：

• 完成仓库分析后汇报。

• 完成迁移方案后等待确认。

• 修改超过指定文件数量时暂停。

6. 要求最终证据包

最终输出至少包含：

• 修改摘要。

• 完整 diff。

• 测试命令和结果。

• 新增依赖。

• 失败尝试。

• 未解决风险。

7. 完成后做一次反向审计

不要只问“完成了吗？”

还要问：

• 有没有改变任务定义？

• 有没有绕过测试？

• 有没有扩大修改范围？

• 有没有把无法验证的部分包装成已完成？

最后：长任务最重要的能力，是知道什么时候停

Goal mode 代表 Codex 正从一次性回答走向持续工程执行。

这会让迁移、重构、测试修复、文档整理和复杂研究变得更自动化。

但自动化的核心从来不是“让机器一直跑”。

而是让机器在正确目标、正确权限和正确停止条件下运行。

模型能力越强，任务持续时间越长，目标合同的重要性越高。

未来真正拉开团队差距的，不是谁最早学会输入 /goal。

而是谁能够把需求变成：

• 明确的起点事实。

• 可重复的验收证据。

• 不可跨越的安全边界。

• 清晰的退出条件。

一句话：

自主性是一台放大器。没有停止条件的 /goal，只会把一个模糊需求放大成一场漫长返工。

参考来源

• AIVI：《Codex /goal 模式深度指南：长时间自主执行，6 个坑你踩了吗？》，https://www.aivi.fyi/llms/codex-goal

• OpenAI Codex：Follow goals，https://developers.openai.com/codex/use-cases/follow-goals/

• OpenAI Codex Changelog：Goal mode is no longer experimental，https://developers.openai.com/codex/changelog

• OpenAI Codex source：goal continuation prompt，https://github.com/openai/codex/blob/main/codex-rs/core/templates/goal-prompt.md

• OpenAI Codex source：goal state and token budget，https://github.com/openai/codex/blob/main/codex-rs/core/src/goals/state.rs

• OpenAI Codex issue #24531：Chat “stop” does not pause an active goal，https://github.com/openai/codex/issues/24531

• OpenAI Codex issue #32170：Explicit skill mentions in /goal are not activated，https://github.com/openai/codex/issues/32170