文章目录goal命令技术解析Claude Code与Codex目标驱动自主执行机制全景解析一、引言二、背景一个命令解决了什么问题2.1 Agent 工作的旧范式2.2 目标驱动执行的前提条件三、Claude Code /goal机制深解3.1 整体运行流程3.2 评估器Haiku 独立判题3.3 轮次预算与停止控制3.4 版本信息四、Codex /goal机制深解4.1 设计哲学差异4.2 持久化与断点恢复4.3 续期触发机制4.4 版本信息与演进五、横向对比两大平台实现差异5.1 核心机制对比5.2 适用场景对比5.3 评估器设计的哲学差异六、工程实践如何写好一个 /goal6.1 好的完成条件应具备什么6.2 标准条件模板6.3 必须配套的工程约束6.4 Claude Code 与 /loop 组合使用七、风险与反模式7.1 最常见失败模式条件模糊 → 语义漂移7.2 评估器盲区它看不见文件系统7.3 Codex 的历史教训0.132.0 之前的无限循环7.4 反模式汇总八、总结goal命令技术解析Claude Code与Codex目标驱动自主执行机制全景解析一、引言亲爱的朋友们创作不容易若对您有帮助的话请点赞收藏加关注哦您的关注是我持续创作的动力谢谢大家有问题请私信或联系邮箱jasonai.fngmail.com2026年5月Anthropic 为 Claude Code 推送了 v2.1.139一个名为/goal的新命令随之上线。它的用法极其简单——输入一个完成条件然后走开。/goal all unit tests pass and TypeScript reports zero errorsClaude 会持续工作执行、验证、修复再验证——直到条件达成或预设的轮次上限耗尽。期间不需要人在屏幕前坐着不需要每次手动发起下一步。这不是一个功能上的小改进而是 AI 编码代理工作模式的一次根本性转变从你告诉 AI 每一步做什么变成你告诉 AI 终点在哪里让它自己找路。同期OpenAI 的 Codex CLI 在四月底也推出了自己的/goal实现以略有不同的架构解决同一个问题。两大主流 AI 编码平台同时将目标驱动执行提升为一等公民标志着这一模式正式进入工程主流。本文将深入拆解两平台/goal命令的底层机制、设计差异、工程实践要点以及这一模式带来的风险与应对方法。二、背景一个命令解决了什么问题2.1 Agent 工作的旧范式在/goal出现之前使用 AI 编码 Agent 的典型流程是用户 → 发一条指令 → Agent 执行 → 返回结果 用户 → 审查结果 → 再发下一条指令 → Agent 执行 → 返回结果 ...重复 N 次这个模式有两个根本问题人是执行链的中间节点每轮结束后必须等人来决定下一步做什么Agent 的效率受限于人的响应速度任务完成是主观判断Agent 做完一步后够不够好需要人来判断——这是最难外包给机器的环节/goal同时解决了这两个问题把下一步做什么和任务是否完成都交给系统自动判断人只需要在开始时定义终点。2.2 目标驱动执行的前提条件为什么这个功能偏偏在 2026 年才实用化因为它的可靠运行需要三个前提同时成立前提2024 年状态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设计中最值得关注的工程细节评估模型与执行模型是分开的。角色模型职责执行模型Claude Sonnet / Opus实际读写文件、运行命令、修改代码评估模型Claude Haiku默认仅读取对话记录判断条件是否达成分离设计的理由有三成本条件检查每轮必须运行用 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.1392026 年 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.128.02026-04-30/goal首次发布0.132.02026-05-19修复到达用量上限时正确停止而非死循环0.141.02026-06状态机成熟官方文档正式收录用例值得注意的是 0.132.0 的修复修复前无明确停止信号的目标会一直运行直到进程崩溃或账户触达限流。这个 bug 实际上把不少早期用户的 API 账单推高了。五、横向对比两大平台实现差异5.1 核心机制对比维度Claude Code /goalCodex /goal发布时间2026-05-11v2.1.1392026-04-30CLI 0.128.0架构风格轻量会话钩子持久化状态机评估模型Haiku独立可配置内置评估逻辑状态持久化否进程退出即丢失是跨重启存活暂停/恢复不支持支持 pause / resumeGoal 状态达成 / 运行中pursuing / paused / achieved / unmet / budget-limited预算语法or stop after N turns内置 budget-limited 状态续期机制每轮结束后检查事件驱动安全边界触发评估范围仅读对话记录可配置工具调用官方文档code.claude.com/docs/en/goaldevelopers.openai.com/codex/use-cases/follow-goals5.2 适用场景对比场景推荐平台理由快速一次性目标修复测试、解决 TS 错误Claude Code更轻量启动快不需要状态持久化长时间运行、可能中断的任务Codex持久化 断点恢复不怕进程意外退出需要多个并发目标Codex状态机支持多 Goal 独立管理成本敏感场景Claude CodeHaiku 评估器独立计费评估成本极低已有 Claude Code 工作流的团队Claude Code与 /loop、hooks、CLAUDE.md 生态无缝集成5.3 评估器设计的哲学差异两者在如何判断目标是否达成上体现了不同的工程哲学Claude Code 的思路分离执行与判断。用廉价的 Haiku 做评估主模型专注执行每轮额外成本极低但评估器只能看对话记录无法主动探测文件系统状态。Codex 的思路完整状态机。Goal 本身是一个可感知、可查询的对象评估逻辑更重但支持更复杂的条件表达和状态管理。两者都有意义。对于大多数编码任务Claude Code 的轻量评估已经足够对于需要在多天内断断续续推进的复杂任务Codex 的持久化状态机更合适。六、工程实践如何写好一个 /goal6.1 好的完成条件应具备什么可量化、可自动验证是/goal条件的核心要求。以下是从好到差的条件案例质量示例条件问题/优势好npm test exits 0 and tsc --noEmit exits 0二进制结果自动可验证无歧义好git status shows no modified files except README.md精确约束可直接检查好Lighthouse performance score for /home exceeds 90数值边界可客观测量差code quality is improved无法验证评估器每轮都可以找到进步差user experience is better主观无停止条件差fix the auth bug缺乏验证机制Agent 完成后如何知道 bug 真的修了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 turns6.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----testPathPatternauth, stop after8turns约束三声明不得修改的内容防止 Agent 通过删掉测试来让测试通过/goal all tests pass;notestfiles may be deleted or modified;stop after10turns6.4 Claude Code 与 /loop 组合使用/goal和/loop是互补的命令适合不同场景命令适用场景结束条件/goal有明确完成标准的一次性任务条件达成或轮次耗尽/loop周期性持续运行的任务如每 30 分钟扫描 CI手动停止或计划终止/goal/loop每次循环触发一个带完成标准的子任务/loop 控制节奏/goal 保证每次子任务质量七、风险与反模式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 反模式汇总反模式表现正确做法条件模糊评估器永远说 no轮次耗尽用命令退出码、数值阈值等可量化标准无轮次上限失控运行成本不可控始终附加stop after N turns无约束声明Agent 删测试来让测试通过声明哪些文件/目录不得修改不汇报执行结果评估器看不到实际输出误判达成要求 Agent 将命令输出完整贴入对话跨域目标单个 /goal 涉及前后端、数据库、CI拆分为多个独立 /goal分别验证八、总结维度核心要点是什么/goal将 AI Agent 的工作模式从单轮问答升级为持续执行直到可验证条件达成Claude Code 特点Haiku 独立评估器、轻量钩子架构、低评估成本、不支持状态持久化Codex 特点完整状态机pursuing/paused/achieved/unmet/budget-limited、持久化跨重启存活、支持暂停恢复最重要一点完成条件必须是可自动验证的二进制结果命令退出码、数值阈值模糊条件是所有问题的根源必须配套始终设轮次上限声明禁止修改的范围要求 Agent 汇报实际命令输出最大风险条件模糊 无上限 语义漂移 成本失控Codex 0.132.0 之前的无限循环 bug 是真实案例/goal命令真正的意义不在于它能让 AI 运行多少轮而在于它第一次让开发者可以定义终点而非路径。当 Agent 足够可靠人类工程师最有价值的输入从来不是下一步做什么而是什么叫做完成。这也是 Loop Engineering 整个方法论的核心判断在 AI 能力越过临界点之后工程杠杆从执行转向设计从路径转向终点从提示转向目标。/goal是这个转变最具体、最可落地的体现。参考资料Keep Claude working toward a goal — Claude Code 官方文档Claude Code 2.1.139 adds /goal command — explainx.aiHow to Use Claude Code’s /goal Command — MindStudioFollow a goal — Codex 官方文档Codex /goal vs Claude Code /goal — knightli.comCodex Goal Mode Remote Computer Use — ofox.aiClaude Code and Codex both have /goal. Here’s how to use it — augusteo.comMastering Claude Code /goal: The Ultimate 2026 Guide — amitray.com