Codex 与 Claude 的 /goal 模式对比（一）
用 AI 编码工具做复杂任务时，最烦人的往往不是它不会写代码，而是它太容易“停”。跑完一次测试就等你下一句，修完一个局部问题就交差，遇到 benchmark 没过还需要你手动说“继续”。
这就是 /goal 模式想解决的问题：把“继续做，直到某个条件满足”为一个显式契约，而不是让用户不断补一句“keep going”。
最近 OpenAI Codex 和 Claude Code 相继推出了 /goal 功能，但两者的设计重心并不相同。Codex 更像是线程级、证据驱动的完成契约；Claude Code 更像是会话级、由独立评估器驱动的自动续跑机制。
这篇文章只围绕官方资料做介绍和对比，不把两边包装成“谁完全替代谁”。它们解决的是同一个体验痛点，但边界、风险和适用任务并不一样。
/goal 到底改变了什么
普通提示词的工作方式很直接：你说下一步要做什么，Agent 执行一轮，然后停下来等你。
/goal 的工作方式不同：你给它一个完成条件，Agent 在每轮工作之后检查是否达成。如果没达成，并且仍然满足继续执行的条件，它就进入下一轮。
flowchart LR
A(["普通 Prompt"]) --> B[执行一轮]
B --> C[返回结果并等待用户]
D(["/goal"]) --> E[执行一轮]
E --> F{完成条件满足?}
F -- 是 --> G[结束并报告结果]
F -- 否 --> H[继续下一轮]
H --> E
这听起来像一个简单循环，但真正重要的是“什么时候能继续”和“凭什么算完成”。Codex 和 Claude Code 的差异，基本都集中在这两个问题上。
Codex 的 Goal：线程里的持久目标和证据审计
OpenAI Cookbook 对 Codex Goals 的定义很明确：Goals 是 Codex 中的持久目标，会让一个线程跨轮次朝着明确结果推进。它不是全局记忆，也不是项目级配置，而是绑定在当前线程上的状态。
Codex 的 /goal 适合路径不确定、但完成线清晰的任务。例如：
- 性能优化：把 p95 延迟压到某个阈值以下，同时保持正确性测试通过
- flaky test 排查：持续复现、定位、修复并验证
- 迁移和重构：多轮修改，直到测试和约束都满足
- 研究复现：把论文、数据、实验结果拆成证据清单，而不是生成一个看似完整的结论
在 Codex 0.128.0 推出该功能。使用方式是：
| |
Codex 的命令面还包含生命周期控制：
| |
这里最值得注意的是两个设计点。
第一，Codex 把 Goal 视为线程级完成契约。它记录目标、生命周期、预算和进度统计。一个 Goal 可能处于 active、paused、complete 或 budget-limited 等状态。预算耗尽不是“任务完成”，而是需要停止实质工作、总结进展和阻塞点。
第二，Codex 强调基于证据完成。一个 Goal 不应该因为模型“觉得差不多了”就完成，而应该对照文件变更、命令执行、测试结果、benchmark 输出、生成产物或研究证据来判断。
所以 Codex 的强 Goal 往往不只是“做 X”，而是包含：
| 要素 | 作用 |
|---|---|
| Outcome | 最终要成立的结果 |
| Verification surface | 用什么测试、benchmark、报告或产物证明 |
| Constraints | 哪些东西不能回退 |
| Boundaries | 能动哪些文件、用哪些资料和工具 |
| 要素 | 作用 |
|---|---|
| Iteration policy | 每轮失败后如何选择下一步 |
| Blocked stop condition | 什么时候停止并说明阻塞 |
弱 Goal：
| |
强 Goal：
| |
更强的写法还会补上允许修改的范围、每轮需要记录的指标，以及 benchmark 跑不起来时应该如何报告阻塞。这样 Codex 才有足够清晰的完成标准，也不容易把“局部改善”误报成“任务完成”。
Claude Code 的 /goal：会话级条件和独立评估器
Claude Code 的 /goal 目标也很直接：设置一个完成条件，让 Claude 跨轮次工作，直到条件满足。官方文档注明，/goal 需要 Claude Code v2.1.139 或更高版本。
它的基本用法是：
| |
Claude Code 的 /goal 有几个很鲜明的实现特征。
首先，一个会话里只能有一个活跃 Goal。再次执行 /goal <condition> 会替换当前活跃 Goal；执行 /goal 不带参数会查看状态；执行 /goal clear 会提前清除。文档还提到，stop、off、reset、none、cancel 都是 clear 的别名，执行 /clear 开启新对话也会移除活跃 Goal。
其次，Claude Code 的 /goal 会在设置后立即开始一轮工作，不需要再额外发一条提示。之后每轮结束时，系统会把完成条件和当前对话交给一个 small fast model 评估；默认配置下这个评估器使用 Haiku。评估器返回 yes/no 和简短原因：如果是 no，Claude 继续下一轮；如果是 yes，Goal 自动清除，并在 transcript 里记录已达成状态。
这带来一个关键边界：Claude Code 的评估器不会自己调用工具，也不会独立读取文件。它只能判断 Claude 已经在对话里展示出来的内容。因此，Goal 条件必须写成“Claude 的输出能证明”的形式。
比如，“所有 test/auth 测试通过”是可行的，前提是 Claude 真的运行测试，并把结果留在 transcript 中。否则评估器没有额外通道去检查工作区。
Claude Code 还支持把上限写进条件本身，例如：
| |
官方文档说明，条件最长可达 4,000 个字符。如果会话结束时 Goal 仍然活跃，用 --resume 或 --continue 恢复该会话时，条件会被恢复；但轮次数、计时器和 token 花费基线会重置。已经达成或已清除的 Goal 不会被恢复。
在自动化场景里，Claude Code 的 /goal 也能用于非交互模式：
| |
这种情况下，-p 会让循环在单次调用中运行到完成；如果要提前终止，可以用 Ctrl+C。