Codex 与 Claude Code 的 /goal 模式对比：让 AI Agent 真正把任务做完

用 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 推出该功能。使用方式是：

1

/goal Reduce p95 latency below 120 ms without regressing correctness tests

Codex 的命令面还包含生命周期控制：

1
2
3
4

/goal          查看当前 Goal
/goal pause    暂停活跃 Goal
/goal resume   恢复暂停的 Goal
/goal clear    移除当前 Goal

这里最值得注意的是两个设计点。

第一，Codex 把 Goal 视为线程级完成契约。它记录目标、生命周期、预算和进度统计。一个 Goal 可能处于 active、paused、complete 或 budget-limited 等状态。预算耗尽不是“任务完成”，而是需要停止实质工作、总结进展和阻塞点。

第二，Codex 强调基于证据完成。一个 Goal 不应该因为模型“觉得差不多了”就完成，而应该对照文件变更、命令执行、测试结果、benchmark 输出、生成产物或研究证据来判断。

所以 Codex 的强 Goal 往往不只是“做 X”，而是包含：

弱 Goal：

1

/goal Improve performance

强 Goal：

1

/goal Reduce p95 checkout latency below 120 ms on the checkout benchmark while keeping the correctness test suite green

更强的写法还会补上允许修改的范围、每轮需要记录的指标，以及 benchmark 跑不起来时应该如何报告阻塞。这样 Codex 才有足够清晰的完成标准，也不容易把“局部改善”误报成“任务完成”。

Claude Code 的 /goal：会话级条件和独立评估器

Claude Code 的 /goal 目标也很直接：设置一个完成条件，让 Claude 跨轮次工作，直到条件满足。官方文档注明，/goal 需要 Claude Code v2.1.139 或更高版本。

它的基本用法是：

1

/goal all tests in test/auth pass and the lint step is clean

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 还支持把上限写进条件本身，例如：

1

/goal auth migration is complete and all related tests pass, or stop after 20 turns

官方文档说明，条件最长可达 4,000 个字符。如果会话结束时 Goal 仍然活跃，用 --resume 或 --continue 恢复该会话时，条件会被恢复；但轮次数、计时器和 token 花费基线会重置。已经达成或已清除的 Goal 不会被恢复。

在自动化场景里，Claude Code 的 /goal 也能用于非交互模式：

1

claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

这种情况下，-p 会让循环在单次调用中运行到完成；如果要提前终止，可以用 Ctrl+C。

最关键的差异

两者都叫 /goal，但产品语义并不完全一样。

一句话概括：

Codex 更重视“工作线程里的证据和生命周期”；Claude Code 更重视“每轮之后由独立评估器决定是否继续”。

这会直接影响 Goal 的写法。

在 Codex 中，你应该把测试、benchmark、产物和阻塞报告写进 Goal，让 Codex 在同一个线程里围绕证据推进。

在 Claude Code 中，你还要额外注意：评估器只能读 transcript。因此你不仅要要求 Claude 运行检查，还要要求它把关键检查结果明确展示出来。否则它可能实际做了工作，但评估器看不到足够证据。

sequenceDiagram
    participant User as 用户
    participant Codex as Codex
    participant Claude as Claude Code
    participant Eval as Claude 评估器

    User->>Codex: /goal 设定目标
    Codex->>Codex: 保存线程级目标与状态
    Codex->>Codex: 执行、测试、收集证据
    Codex->>Codex: 对照证据判断是否完成

    User->>Claude: /goal 设定条件
    Claude->>Claude: 执行一轮任务
    Claude->>Eval: 条件 + transcript
    Eval-->>Claude: yes/no + reason
    Claude->>Claude: no 则继续，yes 则清除 Goal

和 /loop、Stop hook、auto mode 的关系

Claude Code 文档专门把 /goal 放到几个自动化方式里对比，这部分也有助于理解它的定位。

• /goal：上一轮结束后触发评估，直到模型确认条件满足
• /loop：按时间间隔重复运行，直到用户停止或 Claude 判断完成
• Stop hook：上一轮结束后触发，由用户自己的脚本或提示词决定下一步
• auto mode：自动批准单轮里的工具调用，但不会自动开启下一轮

也就是说，Claude Code 的 /goal 可以理解为一个会话级快捷方式：你不用写 Stop hook，也不用每轮手动发“继续”。但如果你需要确定性的检查，例如运行一个固定脚本来判断是否继续，Stop hook 仍然是更可控的选择。

Codex 的资料没有把 Goal 描述成 hook 快捷方式，而是把它放在线程状态、调度、预算和证据审计的框架里。它的重心不是“用一个评估器读 transcript”，而是“让当前线程围绕明确目标持续推进，并且只有证据支持时才完成”。

什么时候选谁

如果你已经在 Codex 里处理一个复杂工程任务，尤其是性能优化、测试修复、迁移、研究复现这类需要不断收集证据的工作，Codex Goals 更贴合。它的线程级状态、生命周期控制和预算边界更适合长任务。

如果你已经在 Claude Code 里工作，想让当前会话持续推进到一个可验证条件，Claude Code 的 /goal 上手更轻。它适合“把这组检查跑绿”“按验收条件实现完”“拆完这个文件并确保每个模块低于指定行数”这类能从 transcript 判断进度的任务。

如果你的完成条件非常机械、必须确定性判断，在 Claude Code 里不要强行让 /goal 猜。用 Stop hook 跑脚本会更稳；/goal 更适合让模型评估“对话里展示的证据是否足够”。

如果任务只是一次性修改、一段解释或一个很短的 code review，两边都不必开 Goal。普通 prompt 更干净。

写 Goal 的通用模板

无论用 Codex 还是 Claude Code，一个可用的 Goal 都应该包含完成条件和证据来源。可以从这个模板开始：

1
2
3
4

/goal <最终要成立的结果>，通过 <具体检查、测试、benchmark 或产物> 验证；
同时保持 <不能回退的约束>。
每轮结束时说明 <已经尝试什么、证据是什么、下一步是什么>。
如果 <预算、轮次、时间或证据条件> 不满足，则停止并报告阻塞。

对 Claude Code，可以再加一句：

1

After each check, summarize the concrete evidence in the transcript so the goal evaluator can judge it.

这句不是形式主义。Claude Code 的评估器不读文件、不跑命令，只读对话；让 Claude 把证据写出来，就是让评估器看得见。

对 Codex，可以更强调证据标准：

1

Only mark the goal complete when the result is supported by concrete evidence from changed files, command output, test results, benchmark output, or the final artifact.

这能减少“做了一部分就宣布完成”的风险。

结论

/goal 模式背后其实是 AI 编码工具的一次产品转向：从“回答下一步”走向“围绕结果持续执行”。

Codex 和 Claude Code 的共同点，是都把“继续直到完成”从用户口头催促变成显式机制。差异在于，Codex 把 Goal 做成线程级、带生命周期和预算边界的证据契约；Claude Code 把 /goal 做成会话级、基于 Stop hook 和 small fast model 的完成条件评估。

真正用好它们，关键不在于写一个更长的 prompt，而在于把“完成”定义清楚：什么结果算成功，用什么证据证明，什么约束不能破坏，什么时候应该承认阻塞。

Goal 不应该让 Agent 无限循环。它应该让 Agent 在证据足够前不停得太早，在证据不足时也不假装完成。

参考资料

• Using Goals in Codex - OpenAI Cookbook
• Keep Claude working toward a goal - Claude Code Docs