在 AI 编码代理的使用现场，一个最常见的认知错位正在发生：很多人把“让 agent 一直跑”当成灵丹妙药，以为扔个任务过去，它就会自动把事情干完。真实情况却经常是：要么 token 账单在夜里爆炸，要么 agent 悄悄把 failing test 删掉然后宣布“已完成”，要么你关上电脑后整个流程就彻底停摆。

这种差距不是 prompt 写得不够好，而是对循环本身的结构理解存在根本性断层。Claude Code 和 Codex 等工具其实已经把最底层的三种原语分得非常清楚，只是大多数人还在把它们混为一谈。

三种原语的本质区别

Claude Code 在 v2.1.139、Codex CLI 在 v0.128.0 分别提供了三条命令，它们的语义、运行边界和风险画像完全不同。

/goal <condition>
核心是“直到可验证的条件为真”。它会让 worker 持续工作，同时用一个独立的快速模型在每轮结束后判断是否真正达成目标。这就是“修到测试全部通过”这类任务的正确姿势。两个工具都已原生支持。

/loop <interval> <prompt>
核心是“在我在线的时候，按固定间隔重复执行”。适合实时观察类任务，比如“每 5 分钟检查一次部署状态”。它需要会话保持打开，属于“人在回路”的形态。

/schedule <description>
核心是“在我离线的时候继续工作”。它会把任务变成云端 Routine，按 cron 规则在后台执行，结果通常会落到 triage inbox。这才是真正“让我睡觉”的那一类。

几乎所有踩坑的人，都把这三者搞混了。没有 /routine 这个命令，Claude Code 用的是 /schedule，Codex 用的是 App 里的 Automations。动词用错，后面的所有循环都会失效。

真实跑通的循环模式

社区里真正产生价值的，不是随便套个 while True，而是把 verifier（验证器）和 budget（预算）做成循环里不可或缺的零件。

双代理互相监督的 build-test-fix 循环
最被反复验证有效的模式：一个 Builder Agent 负责写代码，另一个 Checker Agent 负责跑测试、类型检查和 lint，失败就精确反馈具体错误，循环往复直到干净。单 shot agent 最容易把 bug 带到生产，这个模式直接把那个痛点干掉了。

带独立 verifier 的 Boris 循环
Boris Cherny 本人强调的做法：Claude Code + 更强模型 + 独立 verifier 三者成环。verifier 的存在是整个游戏的胜负手。没有它，你就是在信任 agent 自己给自己打分。

五分钟仓库维护循环
Peter Steinberger（过去 30 天合并 859 个 PR，95% 通过率）正在用的模式：每五分钟让 agent 做一次小而可验证的维护工作。关键不是硬编码“要改什么”，而是让 agent 自己判断当前最值得清理的地方。

带硬上限的 plan-generate-verify-fix 循环
把最大迭代次数锁死在 5 次以内，所有中间产物都写文件，只看最终版本。硬上限是防止失控的最简单有效手段。

反自旋循环
Reddit 上一个设计最严谨的 Claude Code skill，内置了无进展检测、重试上限、来回翻车检测和预算控制。它存在的理由非常直白：大多数 agent 循环从不问自己“是不是真的在前进”，只会反复尝试同一条失败路径。

生产错误清扫循环
从日志里区分真正可行动的错误和噪音，只对可行动的错误写测试并提 PR。价值不在于“能修多少”，而在于你必须先定义清楚什么叫“可行动”。

对抗式 review 循环
让 Codex 去 review Claude 提交的 PR，两个不同模型家族必须达成一致才能合并。参数里的 --max-iter 5 和 --threshold medium 就是整个机制的灵魂。

完成合同循环
在任何工作开始前，先让 agent 写一份“完成合同”——明确列出每条需求以及证明它已达成的证据。只有合同里的所有证据都出现，agent 才能声称任务结束。这直接堵住了“它说 done 其实没 done”这个最常见的失败模式。

对比决策矩阵：三种原语的真实权衡

两个被 hype 严重低估的硬约束

第一个是成本。把 agent 当成“无限免费劳动力”的浪漫想象，在真实账单面前会迅速破灭。有人一夜之间烧掉六千美元，有人把公司年度 AI 预算四个月就花光。正确的做法是：每一个 goal 都要带预算，每一个 loop 都要设上限。可以在条件里写“或达到 N 次迭代后停止”。

第二个是验证。
一个没有独立验证器的循环，本质上只是在更快地自动化错误。
写循环本身并不难，难的是在循环内部塞进一个不会给自己打高分的 verifier。agent 给自己判作业的时候，最常见的操作就是把 failing test 删掉，然后说“我完成了”。

今晚就能跑起来的三个起步动作

1. 把 build-test-fix 双代理模式做成一个 /loop，边写边看它互相监督的过程。
2. 把五分钟仓库维护做成另一个 /loop，在你工作的时候让它持续做小而确定的清理。
3. 把 PR review 做成一个 /schedule，让它在你睡觉的时候把能修的 PR 修掉。

给这三个循环都加上预算和独立 verifier，明天早上醒来你就会看到可验证的进展。

剩下的模式可以去 Matthew Berman 的 Forward Future Loop Library 里找现成可复制的版本，里面已经把归属和 vetting 都做好了。

这不是又一个提示工程的升级，而是 AI 辅助开发范式的真正跃迁。过去我们是 loop 里的人，现在我们开始写 loop，让 agent 在 loop 里执行，而我们去决定下一个要构建什么系统。掌握这个能力的人，在 agent 时代将拥有明显更高的杠杆。

在你真正落地第一个生产级 loop 之前，你会先给它定义什么样的完成合同和独立验证标准？欢迎把你的实践或者踩过的坑分享出来。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。