题记：本文编译自 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 知识。

这两天一个新的 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 知识。