上周写了一篇Codex /goal 上线后，我把 Ralph Loop 卸了，顺带吐槽了 Claude Code + Ralph Loop 跑长任务各种不靠谱。没想到没过几天，Anthropic 就在新版 Claude Code 里把/goal 命令抄过来了。官方推文直接说了，这就是 Claude Code 内置的 Ralph Loop（Ralph Loop 只是一个插件）。

用了几个场景，发现 /goal 确实比 Ralph Loop 好用不少，用起来也简单，一句/goal 就能启动，终于不用盯着 Agent 干活了。今天就带你一起看下这个新功能以及它背后的工作原理。

使用方法

升级 Claude Code 到最新版本之后，/goal 后面跟一个完成条件，Claude Code 就会一直干到条件满足为止，比如：

/goal 所有 test/auth 目录下的测试通过,lint 也没有报错

跟普通对话的区别是，每轮结束后 Claude Code 不会停下来等你输入，而是自动开始下一轮。界面上会显示一个/goal active 的状态条，标注运行时长。

具体的使用方法如下所示：

其实可用的命令也就三个：

• /goal <条件>：设置目标，立即开始执行
• /goal：查看状态，包括条件、时长、轮次、token 用量
• /goal clear：取消当前目标（也可以用 stop、cancel、reset）

需要你注意的是，条件怎么写很关键。写得模糊，模型还是有可能会糊弄你。比如这样写：

/goal 给这个项目写完整的测试

“完整”没有定义，模型可以写几十个空壳测试，全部通过，然后宣布完成。所以建议你换成更具体的条件，比如：

/goal 给 src/auth/ 下所有函数写单元测试,要求:
1. 每个测试必须包含真实断言,不能只有空壳
2. 测试覆盖率达到 80% 以上
3. npm test 退出码为 0
4. 不修改 src/ 下的源代码
5. 20 轮后未完成则停止

最后，我还加了条轮次上限，这个也很有用，防止 Claude Code 无限跑下去。

如果由于各种原因，中途退出了（比如到了 5 小时上限），后面再开启时可以用--resume 恢复目标继续执行。注意，你给它设置的条件最长支持 4000 个字符，可以写得很细了。

另外，还有两个比较好用的搭配：

第一个，/goal 跟 auto 模式搭配效果最好。auto 去掉每个工具调用的人工确认步骤，/goal 去掉每轮结束的等待，两个一起开就是完全无人值守。

第二个，在非交互模式开启，在自动化或者 SKILL 场景里面特别有用：

claude -p"/goal CHANGELOG.md 包含本周所有合并的 PR 记录"

实现原理

/goal 本质上是一个 session 级别的 prompt-based Stop hook。这一句话就把它跟 Ralph Loop 区分开了。

你设置一个/goal 条件后，Claude Code（Opus 或 Sonnet）正常工作，读文件、改代码、跑测试。每轮结束后，系统把完成条件和当前对话记录发给一个独立的小模型（默认是 Haiku）。这个模型返回 yes/no 和一条理由。如果 no，理由会注入下一轮对话，告诉 Claude 还差什么，然后自动开始下一轮。如果 yes，goal 标记为完成，记录到对话记录里。

关键是这个评估模型不能调用任何工具，它只能基于对话记录里已有的文字来判断。

评估的提示词很短，从 GitHub 上提取的系统提示词来看，核心逻辑是：

You are evaluating a stop-condition hook in Claude Code.
Read the conversation transcript carefully, then judge
whether the user-provided condition is satisfied.
Your response must be a JSON object with one of these shapes:
- {"ok": true, "reason": "<quote evidence from the
transcript that satisfies the condition>"}
- {"ok": false, "reason": "<quote what is missing or
what blocks the condition>"}
Always include a "reason" field, quoting specific text from
the transcript whenever possible. If the transcript does not
contain clear evidence that the condition is satisfied,
return {"ok": false, "reason": "insufficient evidence
in transcript"}

注意最后一条：找不到明确证据就默认返回证据不足。评估模型的默认立场是没做完，必须在对话记录里找到实锤才会放行。

不过实际用下来也是有不少问题的。评估模型只看对话文字，不能自己跑命令验证，所以如果工作模型在对话里写了“测试全通过”但实际没跑测试，评估模型看到的证据是充分的，自然会放行。想用好/goal，条件里最好写明具体的验证命令，让 AI 没法绕过。

跟 Ralph Loop 比

Ralph Loop 的核心机制是 Stop hook 拦截：Claude 干完一轮尝试退出时，hook 检查是否达到完成条件，没达到就把原始 prompt 重新注入。完成判断靠精确字符串匹配，Claude 输出<promise>DONE</promise> 就算完成。prompt 里反复强调“不要撒谎来退出循环”，但模型嘛，说不撒谎就不撒谎了？

跟/goal 比，最关键的差距在完成判断。Ralph Loop 是模型自己说了算，输出一个标记就能退出，bash 脚本做字符串匹配放行，没有任何独立验证。/goal 换成了一个独立的小模型来评估，至少不是自己批改自己的试卷了。另外 Ralph Loop 每轮都会把原始 prompt 原封不动重新注入，跑多了上下文里堆满重复内容，虽然 Claude Code 的 compaction 还是会生效，但这些重复注入本身就是噪音。

顺便提一下，Claude Code 还有个/loop 命令，按时间间隔触发下一轮（比如每 5 分钟跑一次），适合轮询类定时任务。/goal 是每轮结束后立即触发下一轮，适合连续执行的目标。

跟 Codex /goal 比

上篇文章里聊过，Codex/goal 的核心设计是三层：状态持久化（state-db）、权限控制（模型只能标记 complete，不能自行退出）、强制自审（continuation.md 要求拆检查清单，逐项对照真实文件和测试结果）。

Claude Code/goal 走了一条不同的路：不依赖工作模型的自查能力，而是引入独立的评估模型。

实际体验上两者差距明显。Codex 在目标执行和自审过程中可以通过工具来形成验证证据，grep 代码、跑测试、核对 spec，工作模型想造假成本很高。Claude Code 的评估模型只看对话文字，验证深度差一个量级，所以我自己跑下来还是 Codex 强得多（这也跟模型能力有关，Codex 搭配 GPT-5.5 才能达到最好的效果）。

写在最后

翻这几个方案的实现原理时，突然想到了最近一直在关注的 Agent harness 这个话题。你会发现不管是 Claude Code /goal 的评估循环还是 Codex /goal 的权限控制，关键的约束都不是写在提示词里的，而是写在代码里的。Claude Code 用代码层面的 Stop hook 来驱动循环，Codex 的运行时每轮自动注入一段自审提示词，强制模型拆检查清单、逐项验证，模型不能自己选择要不要自审，代码替它做了强制自审。

CLAUDE.md 和 AGENTS.md 里写的规则模型可能忽略，但代码层面的 hook 100% 总会触发。这也是为什么 Agent harness 是必要的，光靠模型自觉是不够的，需要有人在外面用代码控制 AI 行为和边界。

回到/goal 本身，对于验收条件清晰、按照 SPEC/PLAN 就能逐步完成的任务，它是目前最省心的选择。但要注意 token 消耗问题，/goal 模式下每轮都是完整的 Opus/Sonnet 调用，跑十几轮下来主模型的 token 用量轻松翻几倍（Haiku 评估的开销相对很小，主要成本还是多轮主模型调用）。建议在条件里加上轮次上限，保护好你的 token 账单。

相关链接：

• Claude Code /goal 官方文档：https://code.claude.com/docs/en/goal
• 上篇 Codex /goal 推荐：https://mp.weixin.qq.com/s/qwjxsGpMacLNy93g6dz4Aw
• Claude Code GitHub：https://github.com/anthropics/claude-code

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。

强烈推荐一下 Codex 的/goal 命令。搭配 GPT-5.5，我第一次感受到长时任务可以完成得这么丝滑。

之前用 Claude Code + Ralph loop 跑长任务，总是各种各样的问题：跑着跑着模型自己宣布胜利了，明明任务清单还有大半没做；状态文件越写越离谱，跨会话后新 Agent 看到的进度跟实际对不上；偶尔卡住，整套循环死在那里。社区里很多人也有同感，有人说自己用 Ralph loop 最长跑 3 小时就失控，中间得不停盯着；使用成本也是巨高，每轮循环都要重新读一遍代码库，token 消耗比正常操作高出很多。

上周升级 Codex 用上了新增的 Goal 命令，Greg Brockman 发推说“codex now has a built in Ralph loop++”。试了几天，太丝滑了，把 Ralph loop 卸了。今天就来给大家分享下它的用法。

/goal 怎么用

首先编辑~/.codex/config.toml 开启这个功能特性：

[features]goals =true

然后给它一个目标就可以等着它帮你干完了，比如：

/goal 把仓库里所有 axios 调用迁移到 fetch,要求:
1. 所有现存测试通过
2. 类型签名不变
3. 错误处理行为等价(4xx/5xx 都要 throw)
4. 完成后跑一遍 npm run build 和 npm test 确认

跟普通对话的区别就一条：每轮结束后 Codex 不停，自己接着干下一轮，直到目标达成。TUI 上有个进度面板，显示当前状态（pursuing / complete / paused）和 token 用量。你可以全程不看它的进度。

运行过程中可以用/goal 查看状态，用/goal pause 暂停，/goal resume 恢复，/goal clear 清除。

/goal 的三层设计

最开始我以为 /goal 就是把 Ralph loop 照搬到了 Codex 里面来。翻了 GitHub 源码才发现，这个设计比 Ralph loop 更进一步，如下图所示：

最底层是状态持久化。Codex 把 Goal 状态写进 state-db（源码在codex-rs/core/src/goals.rs），可能的值是pursuing /paused /complete /unmet /budget_limited。你中途退出再打开，Goal 还在，还可以接着跑。Ralph loop 脚本挂了虽然磁盘文件还在，但得手动重启、重新接上上下文。

中间层是权限控制。Codex 给模型三个工具：get_goal、create_goal、update_goal，但update_goal 的状态参数只接受一个值：complete。模型能宣布“我搞定了”，但不能说“预算快没了我撤了”。断了它的退路，要么真做完，要么继续干。

最上层是自审注入。每轮执行时，运行时注入continuation.md 里一段 prompt，强制模型把目标拆成检查清单，逐项对照真实文件和测试结果。最关键的一句：

Do not call update_goal unless the goal is complete. Do not mark a goal complete merely because the budget is nearly exhausted or because you are stopping work.

直接避免了我之前 Ralph loop 里最常碰到的问题：模型为了脱身硬说基本完成了。

把三层放在一起看，Ralph loop 只是让模型反复跑，/goal 让模型反复跑的同时不停反问自己“我真的做完了吗”。

GPT-5.5 + 100% confident loop

光有 /goal 还不够，模型还需要足够强大。

GPT-5.5 是少数会主动质疑自己的模型。/goal 的自审提示对一个不爱质疑自己的模型就是耳旁风，对 5.5 是放大器。并且 GPT-5.5 也没有之前 GPT 模型那种总是很懒的感觉了，你想不到的它也可以帮你想到了。

对比一下 Opus 4.7。你说“再检查一遍”，它说“你说得对”，然后说一堆早想好的话。你说“这有 bug”，它说“绝对的，我重写”，然后小幅改一下交回来。讨好型选手，跑长任务越跑越偏。而 GPT-5.5 不一样，让它再查一遍，它真会去 grep、跑测试、对照 spec，然后告诉你哪里还有边界情况。

社区里有个配套 prompt 传得很广：

Are you 100% confident in this strategy? If not, find all possible loopholes, suggest proper fixes and run this loop until you are factually 100% confident in the new strategy.

关键是让 5.5 自己开循环：找漏洞、提修复、再问自己一次。这招在 Opus 上完全不好使，它把自查当客套环节，5.5 当成一份正经工作。

我推荐的工作流是：先写 SPEC.md（或者任何保存到文件的目标任务），用这个 prompt 自审一遍，SPEC.md 没问题了再/goal 启动执行，完成后做 QA。

按这个流程，Codex 连续干十几个小时完全不是问题（如果你的 token 足够，更长应该也完全没问题）。

什么任务适合

判断标准就一个：你能不能把“做完了”写清楚。能写清楚，/goal 就可以跑的很多；写不清楚，跑出来也可能是垃圾。官方文档的说法是，好的 Goal 应该定义清楚四件事：要达成什么、不能动什么、怎么验证进度、什么时候停。

我自己跑下来，Goal 比较适合这几类场景：

代码迁移和大型重构。有明确的目标状态，有验收手段（ build 通过 + 测试通过 + e2e 通过）。比如：

/goal Migrate this project from [legacy stack] to [target stack]. Make sure all screens stay exactly the same visually, using playwright interactive to verify the output.

原型和游戏开发。写一份 PLAN.md 描述你要什么，然后让 Codex 实现它。Codex 会按里程碑推进，每个节点跑测试确认。

/goal Implement PLAN.md, creating tests for each milestone and verifying the output with playwright interactive

Prompt 优化。如果你有 eval 套件，可以让 Codex 自己迭代，做实验、看结果、调参数，循环到收敛。比如：

/goal Optimize the prompts in [prompt file] until the eval suite reaches [target score]. After each change, run [eval command], inspect the failing cases, and keep the prompt edits minimal and targeted.

夜间 QA 和批量处理。回归测试、数据校验、批量文件处理这类机械但耗时的活，丢给 /goal 过夜跑。

写在最后

回到开头说的那个问题：长时任务为什么一直不稳？

我之前开发 autonomous-skill 的时候，思路跟 Ralph loop 其实一样，都是在模型外面套一个逼它继续干活的循环。跑了大半年，我逐渐意识到问题不在循环本身，而在模型。模型没有自查能力的话，再套多少层也只是把错误重复 N 次。你可以逼它继续干，但你逼不了它承认自己没干好。

/goal 解决的恰恰是这一层。运行时不让模型耍赖，GPT-5.5 又真的会自查，两条腿一起走，长时任务才第一次变成可以托付的事情。

当然 /goal 也不是万能的。目标写不清楚的任务它照样跑偏，需要频繁跟人确认方向的任务它也不适合。不过对于那些验收标准明确、可以自动化验证的工作，它确实把盯着 Agent 干活这件事变成了睡一觉起来看结果。这个体验的差距，用过就知道了。

相关链接：

• Codex /goal 官方文档：https://developers.openai.com/codex/use-cases/follow-goals
• Codex GitHub 源码：https://github.com/openai/codex

欢迎长按下面的二维码关注Feisky 公众号，了解更多云原生和 AI 知识。