大多数设置只运行一次代理,然后把结果丢给你。而一个循环运行的团队会持续迭代,直到工作真正通过。
以下是 3 个文件组成的方案:代理、驱动它们的循环、以及告诉它们何时停止的规则。
完整方案如下 👇
在深入之前,我每天在我的 Telegram 频道中分享 AI 和 Vibe Coding 相关的笔记:https://t.me/zodchixquant🧠

为什么一次性的团队不够用
一个只运行一次的团队就像没有终点检查的接力赛。写作者写,测试者测,审阅者审,然后所有东西都丢给你——包括那些有问题的部分。
而一个循环团队则填补了这个差距。当测试者发现失败时,它不只是报告后就退出。循环会把它送回给写作者,写作者修复后,再次运行整个流程。你只需在所有环节真正通过时介入,或者当团队遇到无法逾越的障碍时出手。
整个设置包含 3 个文件:代理、循环和停止规则。

文件 1:代理
两个专家,每人一个任务。放在 .claude/agents/ 目录下。
builder.md:
1---2name: builder3description: 编写和修复代码。用来实现任务或修复检查者发现的失败。4tools: Read, Write, Edit, Glob, Grep, Bash5model: sonnet6---78你负责构建和修复,没有其他任务。910- 对于新任务:实现它,保持与现有风格一致。11- 对于修复请求:阅读失败信息,找到原因,只修复那个原因。12- 永远不要为了通过测试而削弱测试本身。修复代码。13- 用一行报告你更改的内容。
checker.md:
1---2name: checker3description: 运行所有检查并报告失败的内容。在 builder 之后调用。永远不编辑代码。4tools: Read, Grep, Glob, Bash5model: sonnet6---78你只检查,从不修复。910按顺序运行以下三项:111. 测试:`npm test`(或 `pytest -q`、`cargo test --quiet`)122. 类型检查:`npx tsc --noEmit`(或 `pyright`、`cargo check`)133. 代码检查:`npm run lint`(或 `ruff check`、`cargo clippy`)1415然后按以下精确格式报告:16- 全部通过:"ALL GREEN"17- 有任何失败:"FAILED",然后每个原因写成18 `file:line - 什么出错了 - 哪个检查捕获的`1920永远不要转述失败信息。直接复制真实错误。builder 根据你的报告来修复,21所以模糊的报告会浪费整个循环。
文件 2:循环
这是驱动循环的编排器。放在 .claude/commands/loop.md 中:
1---2description: 以循环方式运行 builder 和 checker,直到所有检查通过3argument-hint: <task>4allowed-tools: Read, Grep, Glob, Bash, Task5model: opus6---78以循环方式运行此任务:$ARGUMENTS9101. 写一行简要说明:目标、涉及的文件、完成的定义。112. 派发 builder 来实现任务。123. 派发 checker 运行所有检查。134. 如果 checker 说 ALL GREEN:停止,展示结果。145. 如果 checker 说 FAILED:将失败信息发送给 builder 修复,15 然后回到步骤 3。166. 最多重复 5 个循环。大声跟踪循环次数。1718停止条件在 CLAUDE.md 中。严格遵守它们。
循环就是整个核心理念:构建、检查,如果失败,再构建。
编排器自动将失败信息从 checker 传递给 builder,所以团队可以持续运行,无需你手动传递消息。
文件 3:停止规则
没有刹车的循环要么永远跑下去,要么假装通过。把这些规则放在 CLAUDE.md 中:
1## 循环停止规则23团队循环直到以下条件之一成立:45- ALL GREEN:所有检查通过。停止并报告成功,附带证据。6- 已用 5 个循环:停止。报告仍然失败的内容以及尝试过的措施。7- 连续两次相同的失败:停止。builder 在猜测而不是修复。8 升级给我处理。9- 一次修复导致之前通过的检查失败:停止。正在为了修复某样东西而破坏另一样东西。1011永远不要在没有最终循环的 checker 输出的情况下报告成功。12永远不要为了达到 ALL GREEN 而削弱或删除检查。
这些规则正是区分一个有用循环和一个空转消耗令牌的代理的关键。
"连续两次相同失败"的规则最重要:两次相同的失败意味着团队卡住了,需要人工介入。
实际运行时的效果
你只需输入一行:
1/loop add rate limiting to the login route, 5 attempts per IP per minute
然后看着团队自行循环:
1Done in 3 cycles. Review the diff?23Cycle 14 builder → wrote rateLimiter.ts, edited login.ts5 checker → FAILED6 login.test.ts:42 - expected 429, got 200 - tests7 rateLimiter.ts:18 - 'window' possibly undefined - types89Cycle 210 builder → fixed the 429 response, added null guard on window11 checker → FAILED12 login.test.ts:51 - counter not reset after window - tests1314Cycle 315 builder → reset counter on window expiry16 checker → ALL GREEN (14/14 tests, types clean, lint clean)
这就是屏幕上看到的全部要点。你从未手动传递一次失败信息。checker 找到了它们,builder 修复了它们,循环在 3 轮后变绿,你甚至没有碰过键盘。
常见错误
没有循环上限。 如果没有"最多 5 个循环",卡住的团队会一直循环直到你的令牌用完。上限把一个无限循环变成了一个清晰的报告。
让 builder 自己检查自己。 同一个代理既写又评判,意味着它会用产生 bug 时同样的盲点给自己的作业打分。保持 builder 和 checker 分离。
没有"连续两次相同失败"规则。 连续两次相同的失败意味着猜测,而不是修复。这时候应该停下来检查,而不是花掉第四个循环。
循环可以作弊的检查。 如果 checker 可以通过删除一个测试来通过,它最终会那么做。停止规则禁止削弱检查是有原因的。
10 分钟设置
3 分钟:在 .claude/agents/ 目录下创建 builder.md 和 checker.md。
3 分钟:在 .claude/commands/loop.md 中创建循环编排器。
2 分钟:将停止规则添加到 CLAUDE.md。
2 分钟:在一个真实任务上运行 /loop,观察循环:构建、检查、修复、通过。
你不再需要来回传递失败消息。团队运行循环,你阅读结果。它并没有变得更聪明,只是不再在工作完成之前就放弃了。
感谢阅读!
我每天在我的 Telegram 频道分享 AI、金融和 Vibe Coding 的笔记:https://t.me/zodchixquant






