题记：本文编译自 Claude Code 官方博客《Getting started with loops》，原文链接：https://claude.com/blog/getting-started-with-loops。本文在翻译基础上做了整理和补充。

上个月写完《Loop Engineering》这篇文章之后，我一直在用 /goal 跑各种任务。当时的结论是 loop 好不好用取决于你能不能把”做完了”写清楚。这话没错，但其实并不完整。后来我碰到很多任务，并不是把停止条件写清楚就能完事的，还有验证步骤和触发时机也很关键。

刚看到 Claude Code 团队发了一篇官方博客，把他们内部怎么想 loop 这件事系统梳理了一遍。读完觉得挺有价值的，它给了一个我之前缺的判断框架：loop 分四种，区分标准是你愿意交出去什么。验证步骤、停止条件、触发时机、整个决策流程，这四样东西对应四种 loop，具体怎么选择取决于你愿意放手多少。

Claude Code 团队把 loop 定义为 Agent 重复执行工作、循环直到满足停止条件，然后按触发方式、停止机制和适用场景分成了四种。这个分法比社区里各种五花八门的说法清楚得多，因为它有明确的递进关系：你交出去的东西越多，Claude Code 帮你自动完成的任务也就越多，当然对应的成本也会越高。

第一层：交出验证步骤

这是最基础的一种。你发一条 prompt，Claude Code 读代码、改代码、跑测试、返回结果，然后等你的下一条指令。

这就是我们每天都在用的标准交互模式。你还在循环里，每一轮都需要你判断"做完了没"。

怎么让这种模式更高效？Claude Code 团队的建议是把你的验证步骤写成 Skill。比如前端改了一个按钮，应该启动 dev server、打开页面、点一下、截图、检查 console。把这些写进 SKILL.md，Claude Code 就能自己跑完验证，不用你每次手动检查。

---name:verify-frontend-changedescription:任何 UI 改动在宣布完成前必须端到端验证。---# 前端改动验证流程1. 启动 dev server，在浏览器中打开改动页面。2. 直接与改动交互（点按钮、填表单），确认预期行为。3. 检查浏览器 console：不能有新的 error 或 warning。4. 用 Chrome Devtools MCP 跑一次性能追踪。

你可以看到，这一层交出去的是"怎么确认做对了"。Claude Code 替你检查，但做什么、做到什么程度，还是你说了算。

第二层：交出停止条件

Turn-based 的问题是复杂任务一轮搞不定，Claude Code 会频繁停下来问你要决策。/goal 解决的正是这个问题：你定义好成功标准，Claude Code 自己迭代到满足为止。

/goal 把首页 Lighthouse 分数提到 90 以上，最多试 5 次。

这一层你交出去的是"什么时候算做完"。/goal 的关键在于停止条件必须是确定性的。数字、测试通过数、分数阈值这种最好用。为什么？因为描述性结果要大模型自己给自己打分，这种打分很不靠谱，而跑个 Lighthouse 拿到 92 分这种确定性结果它才能判断得准。

每次 Claude Code 尝试停下来，会有一个独立的评估模型检查你的条件是否满足。没满足就打回去继续干，直到达标或者到了你设的次数上限。

这跟 Codex 的 /goal 机制本质上是一样的。我之前在《Codex /goal 》文章中提过的"完成契约"概念在这里同样适用：你把"做完"从主观判断变成可验证的合约，agent 才能真正闭环。

第三层：交出触发时机

前两种都是你手动触发的。但有些工作是周期性的，比如每天早上总结 Slack 消息，或者持续盯着一个 PR 等 review 评论进来。

/loop 做的就是这件事：按时间间隔重复执行同一条 prompt。

/loop 5m 检查我的 PR，处理 review 评论，修复挂掉的 CI

这一层你交出去的是"什么时候该跑"。每 5 分钟检查一次 PR，有新 review 就处理，CI 挂了就修。你不需要一直盯着，它自己按节奏跑。

有一点需要注意的是，/loop 跑在你本地，机器关掉它就停止了。如果想让它不间断，需要用 /schedule 把它变成一个云端任务。

我觉得这一层最有意思的地方是它把 Claude Code 变成了一个值班机器人。以前你盯 CI、盯 review、盯 deploy，现在这些事可以交给一个定时轮询的 agent。当然它是以 token 消耗为代价的，这个后面会说。

第四层：交出整个决策流程

最后一种是把前面所有原语组合起来，做成一个无人值守的长期任务流水线。

比如处理用户反馈：用 /schedule 每小时检查一次 #project-feedback 频道，用 /goal 定义每个 bug report 必须被分类、修复、回复，用动态工作流让多个 agent 并行探索不同修复方案，用 auto mode 跳过权限确认。

/schedule 每小时检查 #project-feedback 里的 bug 报告。/goal 这一轮发现的每个报告都必须被分类、修复、回复后才能停。修 bug 时用动态工作流在并行 worktree 里探索三种方案，再让一个独立 agent 做对抗性审查。

这一层你交出去的是整个决策流程：做什么、怎么做、什么时候做、做到什么程度，全部由 agent 自己决定。

说实话这一层出问题的概率是最高的。动态工作流加上 /schedule 加上 auto mode，组合起来确实是一个完整的 agent 流水线。这对大模型本身的性能和你提供给它的上下文信息有极高的要求，也是最烧 token 的模式，动态工作流一次能起几十 agent，没有做好成本控制的话，很容易账单就爆了。前阵子不少公司砍掉了员工的 Claude 订阅，我觉得这种跑法肯定是原因之一。

怎么控制 token 消耗

从前面可以看出，交给 Claude Code 的越多，token 消耗也就越大。Claude Code 团队给了几条实操建议：

速查表

写在最后

回到开头说的那个问题：loop 用不好，往往不是模型不行，是你选错了层级。

我自己的经验是，先从 /goal 开始。找一个你每天重复做的事，问自己能不能把"做完了"写成一句可验证的话。能写出来，你就可以从 turn-based 升级到 goal-based 了。这一步收益最大，门槛最低，最能节省人力。至于 /loop 和 proactive，等你把 /goal 用顺了再说也不迟。

如果你想了解更多，推荐阅读：

• Claude Code 官方 Loop 博客：https://claude.com/blog/getting-started-with-loops
• Loop Engineering 很好，但先想清楚一个问题：https://mp.weixin.qq.com/s/QR40uuNa1oxtV5ds3i3Ukw
• Codex /goal 上线后，我把 Ralph loop 卸了：https://mp.weixin.qq.com/s/qwjxsGpMacLNy93g6dz4Aw

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

题记：本文编译自 OpenAI 的《Codex Maxxing: long-running work》白皮书，原文链接：https://openai.com/index/codex-maxxing-long-running-work/。本文在翻译基础上做了整理和补充。

刚看到 OpenAI 发布了 GPT-5.6，分 Sol、Terra、Luna 三个档，各种测评性能果然又一次超过了 Claude（包括已经被禁用的 Fable 5）。不过应该是被 Anthropic 模型被禁的问题拖累了，只开放给了一些合作伙伴，普通人暂时用不上，只能眼馋了。

对我们来说，最重要的还是把手头的模型和工具用好。这不，翻到了 OpenAI 一份 27 页的白皮书，作者 Jason Liu 是 Codex 团队的开发者体验工程师。他把怎么让 Codex 的工作不断线这件事讲透了，关键在于把上下文、记忆、工具、定时任务和审查机制组成一个持续运转的工作台。

白皮书总共 10 个模块，构成一个完整闭环：上下文 → 工具 → 记忆 → 定时检查 → 审查。这五个环节哪个缺了，Agent 都可能会退化为一个更烧 Token 的聊天机器人。下面逐个拆解看看。

一、重要工作应该有个固定的家

第一个观点是别让重要工作散在不同的对话里。

把关键工作流都固定成持久会话线程。每个线程对应一个具体的工作域，比如有管 CLI 命令规范的，有管开源项目 issue 的，有专门追踪社交反馈的等等。

这样一来，上下文会随时间积累，旧决策不会丢，之前的工作都留在里面，并且会话上下文超出后会主动压缩。代价当然也有的，长线程会越来越贵，每次回来都要加载前面的历史。但对关键工作流来说，这个成本是值得的。

二、语音输入给 AI 的信息质量反而更高

这是为什么呢？

因为人说话时会把那些打字时觉得不好意思写出来的模糊想法也说出来。比如我记得 Slack 里有个叫 Ben 的人提过这个事，具体忘了，你去翻翻。这种指令打字很别扭，但说出来就很自然。而这恰恰是 AI 最需要的上下文。

让模型拿到你思考的原始版本，而不是你精心整理/清理过的版本，很多计划反而会执行得更好。

三、不用等它做完再说不对

Codex 在执行任务的过程中，你随时可以追加指令，不用等它跑完再推倒重来。

它在跑的时候你就可以插一句，这个做小一点、这段代码不对，甚至追加后续步骤，做完之后顺便开个 PR。

交互模式从一来一回变成了持续塑形，你在塑造一个正在进行的过程，随时可以调方向。这跟 Claude Code 的 Queuing 功能很像，但 Codex 把它做得更显性了。

四、光靠聊天历史是不够的

随着线程变长，对话历史翻起来越来越痛苦。有用的上下文应该变成可以打开、编辑、对比和复用的文件。

白皮书里用的是一个叫记忆库（vault）的文件结构：

vault/├── TODO.md├── people/├── projects/├── agent/└── notes/

要点是区分这两件事：Git 仓库放代码，记忆库放工作的流动上下文。人、决策、还没关闭的待办、日常笔记、项目状态，这些都放记忆库里。

记忆库放在 GitHub 上，这样每次 Codex 更新记忆库都会产生变更记录。变更记录就变成了记忆的审查界面，你能看到 AI 认为什么值得记下来。

那什么时候该写记忆呢？白皮书列了四条触发规则：

• 有人被提到 → 更新人物笔记
• 项目推进 → 更新项目页
• 待办关闭 → 标记已完成
• 有决策 → 写下决策和原因

这个思路跟我自己做的数字分身记忆系统几乎一模一样。我的 notes 仓库里也是用 OBSERVATIONS.md 和 REFLECTIONS.md 做分层记忆，用 git diff 做审查。这样做还有一个好处是记忆跟 Agent 解耦了，相同的记忆库可以方便共享给 Codex、Claude Code、Hermes 等各种 AI Agent。

五、AI 能操作什么？

线程有了记忆之后，下一个问题是它能真正帮你干啥。

Codex 内置了很多跟外界打交道的工具，大致可以分成五类：本地浏览器预览、需要登录态的 Chrome 页面、桌面操作、第三方连接器（比如 Slack、Gmail、日历、GitHub 等），以及可复用的技能包。原则也简单，接口能搞定的就别动图形界面，重复的活儿打包成技能。

六、人可以不在工位，但任务不能卡住

这估计是老板们最想看到的功能了吧！Codex 支持从手机远程查看和操作正在运行的任务。

无论你是去开会还是上个洗手间，活不能卡住。在电脑上启动任务后，离开工位去开会，到了决策点手机收到通知，批准、改方向或者换个思路。这样关键决策点能够随时介入，但人却不需要一直盯着屏幕了。

七、让 AI 自己回来检查

这部分最接近自主 Agent 的边界了。

线程自动化是绑定在会话线程上的心跳式定时任务，告诉 Codex 按照固定节奏回到这个对话，保持上下文，不要从头开始。

这跟普通提示词有什么区别呢？普通提示词是你告诉它现在做这个，做完就结束了。线程自动化不一样，它会持续盯着，有变化就自己往前推。

再往前走一步，一个线程可以有多个定时计划，可以设置条件退出，也可以随着任务变化调整频率。因为和线程上下文绑在一起，不用每次重新交代背景。

八、三个实战循环

白皮书给了三个完整的循环示例，每个都清楚地划分了 Codex 准备什么和人决定什么。

Loop 1：Chief of Staff

Codex 每 30 分钟检查 Slack 和 Gmail，找到需要关注的消息，搜索相关上下文，起草回复。你打开手机看到的不是一堆未读消息，而是整理好的待办清单和草稿，拍板发送就行。

Loop 2：Monitor for Feedback

第二个场景更自动化一些。Codex 每个工作日早上检查一个 Slack 频道里的用户反馈，更新 Remotion 项目，重新渲染，准备修改版供审查。反馈进来、代码改完、渲染跑完，人只需要做最后的创意判断。

Loop 3：Get a Refund

第三个最有意思。Codex 每 5 分钟检查客服线程里有没有人工客服加入。一旦检测到真人，自动切换到每分钟检查一次，准备下一轮回复的草稿和证据。你要做的就是看一眼草稿，觉得没问题就批准发送。

三个场景都是类似的，Codex 干活，人来拍板。任务在你不在的时候照样推进，但所有重大决策都卡在人手里。

九、怎么给 AI 设目标

目标设得好不好，直接决定 Codex 能不能高质量完成你分配的任务。

比如按照这个 Markdown 文件实现这个计划，看起来有目标，但做完之后没法自我验证。换一种写法：把这个库移植到 Rust，保持公共 API 兼容，用原来的单元测试作为验收标准，测试通过且差异已记录，工作才算完成。

后者给了 Codex 一个可以自己跑的验收条件。

就像我之前聊 Codex /goal 时说的，没有验证条件的目标，只能是个愿望，跑好跑坏全靠运气。

十、侧边栏

侧边栏不只是看看输出结果的预览窗口，还可以用来可以检查 Codex 正在操作的对象，加评论、审查变更、把产出物保留在线程里等等都可以在这里完成。

侧边栏支持的格式挺广的，Markdown、表格、CSV、PDF、幻灯片都能渲染。甚至一个 HTML 文件加点 JavaScript 就能变成可交互的工作面板。说白了，侧边栏是 Codex 从聊天应用变成工作台的关键界面。

写在最后

读完这份白皮书，给我触动最大的是这 10 个模块组合起来的闭环。上下文让 Agent 知道自己在干嘛，工具让它碰到真实世界，记忆让经验留下来，再加上定时检查和人工审查，整个系统才能持续转起来。少了哪一环，都可能退化成一个更烧 Token 的聊天机器人。

推荐完整读一遍原文，不管你用的是 Codex、Claude Code 还是别的 Agent 工具，这个闭环的思路都是通用的。

原文链接：https://openai.com/index/codex-maxxing-long-running-work/

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

这两天一个新的 AI 编程范式 Loop Engineering 火了。Peter Steinberger 发推说你不应该再 prompt coding agent，应该去设计 prompt agent 的 loop，两天冲到 800+ 万阅读。随后 Claude Code 负责人 Boris Cherny 也表达了类似的观点，他管理的几百个 agent 自己读 GitHub 和 Slack、自己决定干什么，过去 30 天合并了 250 多个 PR，全部由 Claude Code 完成。

今天 Anthropic 刚刚发布了最新的 Claude Fable 5 和 Mythos 5 模型，甚至能够把数月的工作压缩至几天内完成。

说实话挺有感触的。上个月 Codex 推出的 /goal 功能其实就是最好用的 Loop Engineering 实现，配合广受好评的 GPT-5.5，工作完成度一下子就把之前经常使用的 Claude Code + Ralph loop 组合拉开了，我自己的大部分工作也都切换到了 Codex 上面来。

但用了几个月之后，我发现 loop 好不好用，其实取决于一个很朴素的问题。这个问题后面会展开，先说说 Loop Engineering 到底是什么。

Loop 说白了就是一个替你 prompt agent 的小系统：给 agent 发任务，读结果，判断做完没有，没做完就继续执行。以前我们用 Claude Code，要靠你自己输入 prompt、盯着输出、中断后再输入，如此循环往复，你就是那个循环。Loop Engineering 则是把你从循环里摘出来，但如何摘出来是个问题。

什么是 Loop Engineering

说到 Loop Engineering，我觉得最早可以追溯到 ReAct 模式：你输入提示词后，模型推理、调工具、读结果、循环重复直到没有工具调用时结束。这个循环后面演变成了 AI Agent 最基本的执行过程，是所有 Agent 都必备的基础模块。

不过只有这个循环明显还不够，AI 经常会在执行完一些工具调用后停下来等待你的输入。所以后来就有了 Geoffrey Huntley 的 Ralph loop 模式：通过一行 bash，把同一个 prompt 文件反复发送给 agent 执行，直到模型说工作完成了才停止。

Ralph loop 推出后的确解决了很多长程任务的执行问题，但问题也不少：模型跑着跑着自己宣布胜利，任务清单还剩大半；状态文件越写越离谱，跨会话之后新 agent 看到的进度跟实际对不上；偶尔整个循环还会直接卡死。

后来，Codex 推出了第一个真正可以稳定执行长程任务的功能 /goal，通过状态持久化+权限控制+强制自审三层机制解决了这些问题。详细的实现原理和使用方法可以参考我之前写的《Codex /goal 上线后，我把 Ralph loop 卸了》，这儿就不展开了。

Claude Code 在随后的版本里也增加了相同的 Goal 功能，不过需要注意 Opus 模型相对 GPT-5.5 还是有差距，效果稍微差一些（Claude Fable 则会好一些）。

跟定时任务有什么区别

乍看起来，Loop Engineering 就像是把之前的定时任务改了个名字，底下都是让 AI 大模型不停地执行任务。

但这两者有很大的区别：

• 定时任务的目的是触发任务的执行，执行的时间是固定的。至于到了时间执行啥取决于你给它的指令，可以是脚本、提示词甚至是 Goal 这种复杂的任务目标；
• Loop Engineering 的目的是确保 AI 大模型能够以正确的方法完成你的任务目标，它能够自己查看状态、决定是否执行下一步，循环往复直到目标完成。

在实际使用中，你可以把它们结合在一起来使用。比如，使用定时任务来触发 Github issue 的排查，而在排查每个 issue 时使用 Loop 来确保任务执行的质量。

怎么用好 Loop Engineering

那怎么用好 Loop Engineering？

我的建议是，目标写清楚、步骤有边界、每步有检查、有明确的停止点，确保 Agent 能够闭环迭代就可以了。

Cherny 也给过几条建议，可以参考：权限开 auto 模式、让 Claude 自己编排子 agent、用 /goal 模式、跑在云端，以及自我验证。前四条大家都在用，但最重要的其实是最后一条：验证。产出没人查，方向迟早跑偏。

为什么验证这么重要？大模型给自己的产出打分很不可靠，但如果换一个独立上下文的子 agent 来评估，效果就稳定得多。Lance Martin 的测试里（链接见最后），Fable 5 最好的运行有 73% 的结论经过了独立验证，Opus 4.7 中位数只有 17% ，差距主要就在这儿。

这跟我翻 Codex /goal 源码看到的设计思路是一致的。模型能宣布做完，但不能说预算快没了先撤。再配上每轮注入的自审，强制逐项对照真实文件和测试结果。简单来说，你可以逼模型继续干活，但你逼不了它承认自己没干好，能戳穿它的只有独立的验证。

写在最后

回到开头说的那个朴素问题：你要不要给手头的事上 loop？判断标准跟我在 /goal 那篇里说的一样：你能不能把“做完了”写清楚。能写清楚，loop 确实能帮你省掉大量重复劳动。但如果连做完的标准都说不清，那还是老老实实一步步来吧。

另外还要提醒一点，Loop Engineering 绕不开一个现实问题：烧 token。跑起来烧钱比你想的快，自修正、验证子 agent、重试，每一步都在消耗 token。说白了，你是 token 富人还是 token 穷人，直接决定了你对 loop 的态度。如果你对 token 消耗比较敏感，建议优先使用订阅制的产品而不是直接调 API，能省不少钱。

如果你想了解更多的 Loop Engineering，推荐阅读：

• Addy Osmani: Loop Engineering：https://addyosmani.com/blog/loop-engineering/
• Lance Martin: Designing loops with Fable 5：https://x.com/RLanceMartin/status/2064397389189071163
• Boris Cherny 谈自我验证：https://x.com/bcherny/status/2064426115255730578
• Codex /goal 上线后，我把 Ralph loop 卸了：https://mp.weixin.qq.com/s/qwjxsGpMacLNy93g6dz4Aw

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

上周写了一篇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 知识。