【goal命令技术解析】Claude Code与Codex目标驱动自主执行机制全景解析

goal命令技术解析：Claude Code与Codex目标驱动自主执行机制全景解析

一、引言

亲爱的朋友们，创作不容易，若对您有帮助的话，请点赞收藏加关注哦，您的关注是我持续创作的动力，谢谢大家！有问题请私信或联系邮箱：jasonai.fn@gmail.com

2026年5月，Anthropic 为 Claude Code 推送了 v2.1.139，一个名为/goal的新命令随之上线。它的用法极其简单——输入一个完成条件，然后走开。

/goal all unit tests pass and TypeScript reports zero errors

Claude 会持续工作：执行、验证、修复，再验证——直到条件达成，或预设的轮次上限耗尽。期间不需要人在屏幕前坐着，不需要每次手动发起下一步。

这不是一个功能上的小改进，而是 AI 编码代理工作模式的一次根本性转变：从"你告诉 AI 每一步做什么"，变成"你告诉 AI 终点在哪里，让它自己找路"。

同期，OpenAI 的 Codex CLI 在四月底也推出了自己的/goal实现，以略有不同的架构解决同一个问题。两大主流 AI 编码平台同时将"目标驱动执行"提升为一等公民，标志着这一模式正式进入工程主流。

本文将深入拆解两平台/goal命令的底层机制、设计差异、工程实践要点，以及这一模式带来的风险与应对方法。

二、背景：一个命令解决了什么问题

2.1 Agent 工作的旧范式

在/goal出现之前，使用 AI 编码 Agent 的典型流程是：

用户 → 发一条指令 → Agent 执行 → 返回结果 用户 → 审查结果 → 再发下一条指令 → Agent 执行 → 返回结果 ...（重复 N 次）

这个模式有两个根本问题：

1. 人是执行链的中间节点：每轮结束后必须等人来决定"下一步做什么"，Agent 的效率受限于人的响应速度
2. 任务完成是主观判断：Agent 做完一步后，"够不够好"需要人来判断——这是最难外包给机器的环节

/goal同时解决了这两个问题：把"下一步做什么"和"任务是否完成"都交给系统自动判断，人只需要在开始时定义终点。

2.2 目标驱动执行的前提条件

为什么这个功能偏偏在 2026 年才实用化？因为它的可靠运行需要三个前提同时成立：

三者缺一，目标驱动执行要么不可靠，要么成本不可接受。2026 年是它们同时成熟的时间点。

三、Claude Code /goal：机制深解

3.1 整体运行流程

Claude Code 的/goal本质是在会话层加了一个持续验证的循环钩子：

用户输入：/goal <完成条件> │ ▼ ┌─────────────────────────────────────────────┐ │ Claude 执行一轮 │ │ 读文件 → 修改代码 → 运行测试 → 报告结果 │ └──────────────────────┬──────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ Haiku 评估器（独立模型） │ │ 读取对话记录 → 判断条件是否达成 │ │ 输出：YES（原因）或 NO（原因 + 指导） │ └──────────────────────┬──────────────────────┘ │ ┌────────────┴────────────┐ │ YES │ NO ▼ ▼ 目标达成，记录 Claude 开始下一轮 "achieved" 条目 （NO 的原因作为下轮提示） 会话返回控制权

3.2 评估器：Haiku 独立判题

这是 Claude Code/goal设计中最值得关注的工程细节：评估模型与执行模型是分开的。

分离设计的理由有三：

• 成本：条件检查每轮必须运行，用 Haiku 而非 Opus 做评估，成本可降低 90%+
• 独立性：执行模型容易"自我说服"（认为自己已经完成），独立评估器减少这种偏差
• 速度：Haiku 的评估延迟极低，不成为整体循环的瓶颈

评估器的局限同样明确：它不调用任何工具，只读对话记录。这意味着 Claude 必须在对话中明确汇报执行结果（如测试输出、编译日志），否则评估器无从判断。

3.3 轮次预算与停止控制

不设上限的/goal等于失控系统。Claude Code 提供了明确的预算语法：

# 基本用法：持续直到条件达成/goal all tests pass# 带轮次上限：最多执行 10 轮后停止/goal all tests pass or stop after10turns# 完整形式：条件 + 上限 + 约束/goal all tests pass and no othertestfileis modified, stop after15turns

超出轮次后，Claude 停止并报告当前进度，控制权交还用户。

3.4 版本信息

• 首次发布：Claude Codev2.1.139，2026 年 5 月 11 日
• 官方文档：code.claude.com/docs/en/goal
• 评估器 token 独立计费，不计入主会话预算

四、Codex /goal：机制深解

4.1 设计哲学差异

如果说 Claude Code/goal是"轻量钩子"风格，那 Codex/goal是"显式状态机"风格。

OpenAI 将/goal设计为一个持久化的"任务契约（task contract）"，每个目标有明确的生命周期状态：

Goal 状态机： [创建] → pursuing（执行中） │ ┌─────────┼─────────────┐ │ │ │ ▼ ▼ ▼ achieved unmet budget-limited （已达成） （未达成/放弃） （预算耗尽） ↑ paused （已暂停） ↑ [用户手动 pause]

4.2 持久化与断点恢复

Codex/goal的一个显著优势：目标状态持久化，跨进程重启存活。

这意味着：

• 终端意外关闭后，重新打开 Codex，目标仍处于pursuing状态，可无缝继续
• 可以主动pause一个目标，处理其他事情，再resume回来
• 目标的执行历史被完整记录，可以审查每一轮的决策轨迹

Claude Code 的/goal目前不具备这一能力——进程退出后，目标状态不保留。

4.3 续期触发机制

Codex 的续期（continuation）是事件驱动而非轮询式：

Codex 续期触发条件（必须同时满足）： ✓ 当前轮次已完成 ✓ 无其他进行中的任务 ✓ 无用户输入在队列中 ✓ 线程处于空闲状态

这个设计避免了在 Agent 还在执行时盲目触发下一轮，消除了并发竞争条件。

4.4 版本信息与演进

值得注意的是 0.132.0 的修复：修复前，无明确停止信号的目标会一直运行直到进程崩溃或账户触达限流。这个 bug 实际上把不少早期用户的 API 账单推高了。

五、横向对比：两大平台实现差异

5.1 核心机制对比

5.2 适用场景对比

5.3 评估器设计的哲学差异

两者在"如何判断目标是否达成"上体现了不同的工程哲学：

Claude Code 的思路：分离执行与判断。用廉价的 Haiku 做评估，主模型专注执行，每轮额外成本极低，但评估器只能看对话记录，无法主动探测文件系统状态。

Codex 的思路：完整状态机。Goal 本身是一个可感知、可查询的对象，评估逻辑更重，但支持更复杂的条件表达和状态管理。

两者都有意义。对于大多数编码任务，Claude Code 的轻量评估已经足够；对于需要在多天内断断续续推进的复杂任务，Codex 的持久化状态机更合适。

六、工程实践：如何写好一个 /goal

6.1 好的完成条件应具备什么

可量化、可自动验证是/goal条件的核心要求。以下是从好到差的条件案例：

6.2 标准条件模板

# 测试驱动完成/goal all testsinsrc/__tests__/ pass(npmtestexits0), stop after12turns# 类型安全完成/goal tsc--noEmitreports zero errors, no new any types introduced, stop after8turns# 构建验证/goalnpmrun build succeeds and bundle size does not increase bymorethan5%, stop after10turns# 多条件组合/goal all unit tests pass AND e2e tests pass AND no ESLint errors, stop after20turns# 文件级约束/goal README.md contains a valid## Usage section with at least one code example, stop after 5 turns

6.3 必须配套的工程约束

单纯的条件还不够，实践中还需要：

约束一：始终设定轮次上限

不加上限的/goal是风险敞口，条件稍有模糊就可能无限循环：

# 危险：没有上限/goal all tests pass# 安全：有明确上限/goal all tests pass, stop after10turns

约束二：条件必须包含"验证方式"

告诉 Agent 用什么命令来证明目标达成，而不是让它自行判断：

# 模糊（Agent 可能声称完成但不实际运行测试）/goal the authentication is fixed# 明确（强制要求运行具体命令）/goal all testsinauth/ pass when runningnpmtest----testPathPattern=auth, stop after8turns

约束三：声明不得修改的内容

防止 Agent 通过"删掉测试"来让测试通过：

/goal all tests pass;notestfiles may be deleted or modified;stop after10turns

6.4 Claude Code 与 /loop 组合使用

/goal和/loop是互补的命令，适合不同场景：

七、风险与反模式

7.1 最常见失败模式：条件模糊 → 语义漂移

早期用户最频繁踩到的坑：条件写得不够具体，评估器每轮都觉得有进展但永远不判"达成"：

条件：improve the code quality 第 1 轮：Claude 提取了一个重复函数 → 评估器：no（但有进步） 第 2 轮：Claude 加了 JSDoc → 评估器：no（但有进步） 第 3 轮：Claude 重命名了变量 → 评估器：no（但有进步） ...直到轮次耗尽

后果是轮次全部消耗，token 账单飙升，实际改进却零散无序。

7.2 评估器盲区：它看不见文件系统

Claude Code 的 Haiku 评估器只读对话记录，不直接检查文件或运行命令。这意味着：

• 如果 Claude 声称"测试通过了"但没有在对话中贴出实际输出，评估器可能错误地判"达成"
• 解法：在 CLAUDE.md 中明确要求 Claude 每轮必须汇报关键命令的完整输出

7.3 Codex 的历史教训：0.132.0 之前的无限循环

Codex 在 v0.132.0 之前存在一个严重 bug：当 Goal 没有清晰的停止信号时，系统不会在预算耗尽后停止，而是持续运行直到进程崩溃或账户触达限流。这个 bug 导致部分早期用户产生了意料之外的高额账单。

当前版本（0.132.0+）已修复，预算限制会正确触发budget-limited状态并停止执行。

7.4 反模式汇总

八、总结

/goal命令真正的意义，不在于它能让 AI 运行多少轮，而在于它第一次让开发者可以定义终点而非路径。当 Agent 足够可靠，人类工程师最有价值的输入从来不是"下一步做什么"，而是"什么叫做完成"。

这也是 Loop Engineering 整个方法论的核心判断：在 AI 能力越过临界点之后，工程杠杆从执行转向设计，从路径转向终点，从提示转向目标。/goal是这个转变最具体、最可落地的体现。

参考资料：

1. Keep Claude working toward a goal — Claude Code 官方文档
2. Claude Code 2.1.139 adds /goal command — explainx.ai
3. How to Use Claude Code’s /goal Command — MindStudio
4. Follow a goal — Codex 官方文档
5. Codex /goal vs Claude Code /goal — knightli.com
6. Codex Goal Mode & Remote Computer Use — ofox.ai
7. Claude Code and Codex both have /goal. Here’s how to use it — augusteo.com
8. Mastering Claude Code /goal: The Ultimate 2026 Guide — amitray.com