2025 年 Anthropic 推出 Claude Code 的时候，它还只是一个在终端里帮你写代码的 AI 助手——你问一句，它答一局，像下棋一样回合制推进。今天发布的 Loops 功能，本质上把这个回合制游戏变成了一个自我驱动的循环系统：AI 不再等你发指令才动，它可以自己判断要不要再来一轮，也可以按时反复运行，甚至可以全自动化处理整条工作流。
这篇文章的核心观点很清晰：好的 AI 编程 agent 不是一次做对，而是能够自己反复迭代直到做对。Anthropic 把这个思想拆解成了四种递进的循环模式。
Turn-based Loop：把你的检查清单交给 AI
这是最基础的模式，也是你用 Claude Code 时一直在经历的——每次发送 prompt，Claude 就启动一个自主循环：读代码、做修改、跑测试、检查结果、如果没过就再来一遍，最后把结果交给你。
Anthropic 重点提到了一个容易被忽视的细节：验证步骤（verification）的质量，决定了整个循环的上限。你可以把你平时手动验收的步骤写进 SKILL.md 文件，让 Claude 替你跑完那些检查。比如前端改了个按钮，不要只看代码编辑成功就收工，而是让 Claude 启动 dev server、打开浏览器、点击按钮、截图前后对比、检查 console 里有没有新报错、跑一遍 Core Web Vitals 性能审计。这套流程量化得越好，Claude 自检的可靠性就越高。
背后的逻辑很朴素：人类 reviewer 怎么验，你就怎么写。用具体的、可量化的指标代替模糊的"看起来不错"。
Goal-based Loop（/goal）：定义"完成"的标准
Turn-based loop 的问题是：Claude 可能"觉得"自己已经完成了，但实际并没有。Goal-based loop 解决的就是这个问题——你明确告诉它什么叫"完成"。
用法很简单，比如：
这里的关键设计是引入了一个 evaluator 模型。每次 Claude 想要停下来汇报结果的时候，evaluator 会检查你设定的条件是否真的达成了。如果没有，Claude 会被打回去继续工作。这个过程会一直持续，直到目标达成或者你设定的最大尝试次数耗尽。
Anthropic 特别强调了确定性标准的重要性。"把代码改好"是一个模糊目标，Claude 可能改一行就觉得自己完成了。但"所有测试通过"或者"Lighthouse 分数达到 90+"是确定性目标，机器可以客观判断。所以写 /goal 的时候，尽量用量化的、可自动验证的退出条件。
Time-based Loop（/loop 和 /schedule）：让 AI 按时巡检
有些工作是周期性的：每天早上总结 Slack 消息，每隔几分钟检查一下 PR 有没有新的 review comment，CI 有没有挂掉。这类任务的共性是：任务不变，输入在变。
/loop 让你设定一个时间间隔，Claude 会定期执行你给的 prompt。比如：
这和很多开发者的日常工作模式完全一致——每隔几分钟刷新一下 GitHub，看看有没有新动态，有就处理，没有就等等。区别在于现在这个过程完全自动化了。
/loop 运行在你的本机，关机就停。如果需要持久运行，可以用 /schedule 把任务上云。这个设计很务实——简单任务本地跑，长期任务云端跑。
Proactive Loop：四种原语的全自动组合
这是 Anthropic 真正想卖的故事。Proactive loop 不是一种新原语，而是把前面三种加上 auto mode 和 dynamic workflows 编排到一起的全自动系统。
举个 Anthropic 给的例子：
翻译一下这个 prompt 的编排逻辑：
这不是玩具 demo。它描述的是一个生产可用的 agent 编排架构：触发层、控制层、执行层、审计层、权限层，各司其职。Anthropic 把这套架构用三个斜杠命令就表达清楚了，API 设计上很有品味。
代码质量：系统决定下限
Anthropic 对"怎么保证循环输出的质量"给了几条建议，条条都在点子上。
第一，代码库要干净。Claude 会模仿已有的模式和约定——如果你的代码风格统一，它生成的代码也会统一；如果代码库本身一团乱麻，Claude 的输出只会更乱。
第二，给 AI 自检的手段。通过 Skills 文档编码"什么是好的结果"，让 Claude 能用工具看到、测量、交互实际的产出。定性描述不够，定量指标才靠谱。
第三，用第二个 agent 做 code review。这是一个容易被忽略但极其重要的设计——fresh context 的 reviewer 不受主 agent 推理路径的影响，能更客观地发现问题。Claude Code 内置了 /code-review skill，可以直接用。
第四，单点问题要升维成系统改进。如果某次循环输出不达标，不要只修那个具体的 bug，而是把它编码到 SKILL.md 或者 CI 规则里，让所有未来的迭代都受益。
Token 用量管理：循环的双刃剑
Loops 的代价很直接——每多一轮迭代就多烧一轮 token。Anthropic 给了六条控量建议，整理成一张表：
| 策略 | 说明 |
|---|---|
| 选对原语和模型 | 小任务不需要多 agent，简单活用快模型 |
| 明确的成功/停止标准 | 让 Claude 尽快到达解，但不是太快 |
| 先跑小规模试点 | Dynamic workflows 可能 spawn 几百个 agent，先测一小片 |
| 确定性工作用脚本 | 跑脚本比让 AI 推理每一步便宜得多 |
| 按实际变化频率设间隔 | 别每分钟检查一个一小时才变一次的东西 |
| 监控用量 | /usage 查明细，/goal 查轮次和 token，/workflows 查每个 agent |
"确定性工作用脚本"这条特别值得展开。Anthropic 举了个例子：与其每次都让 AI 推理如何填写一个 PDF 表单，不如写一个填表脚本，AI 只需要调用这个脚本。这本质上是在 agent 循环里引入了"编译"的概念——把重复的推理路径固化成确定性的程序，只在决策点上才调用 LLM。Token 成本可以下降一个数量级。
四种循环的本质
| 循环类型 | 你交出什么 | 适用场景 | 核心命令 |
|---|---|---|---|
| Turn-based | 检查权 | 探索、决策 | 自定义验证 Skills |
| Goal-based | 停止条件 | 你知道"完成"长什么样 | /goal |
| Time-based | 触发时机 | 周期性工作、外部系统交互 | /loop, /schedule |
| Proactive | 整个提示词 | 重复性、定义明确的任务流 | 以上全部 + dynamic workflows |
这个递进关系不是功能堆叠，而是信任递进。Turn-based 你全程参与，每一轮都在看；Goal-based 你只管定义终点，中间过程不干预；Time-based 你甚至不需要在场；Proactive 你只需要写好 prompt 然后走人。每往上一级，你交给 AI 的控制权就多一分，前提是前面每一级的验证基础设施已经到位。
给开发者的建议
Anthropic 的建议很接地气：从你已有的工作流开始。找一个你目前是瓶颈的任务，问自己三个问题——我能写清楚验证步骤吗？完成的标准够明确吗？任务是不是周期性到达的？ 如果至少有一个答案是"是"，这个任务就适合用 Loops 来优化。
先跑起来，观察它在哪里卡住、在哪里过度执行，然后迭代你的 prompt 和 SKILL 文件。就像 Claude 自己在循环里迭代代码一样，你也在循环里迭代你的 agent 系统。