上一篇在谈一件很底层的事：多 Agent 怎么协作、也不要把成本烧在沟通上。不过底盘稳了，质量未必会自动跟上。
我们在开发中常见的剧情：让一个 Agent 写完 patch，再叫它自己 review，它回一句 looks good，测试一跑，直接挂掉。协作顺不顺，跟东西能不能上线，中间似乎还差了一整层的方法。
下面讲那一层。重点不在于能不能叫很多 Agent 一起做，重点在每一步有没有真的带来新信息。三个 pattern 背后都有研究支撑，前提也都很简单，少掉其中一个，后面的 review 很容易变成表演。
Pattern 6：Challenge Loop
最常见的假 review 长这样：叫 Agent B 去审 Agent A 的代码，它回一堆看起来很专业的话，像是「建议考虑错误处理」或「这里可能有风险」。句子很像有认真 review，但其实信息量却很低。修了两轮，bug 还在，因为整个过程从头到尾都没有人拿出可测试的证据。
更稳定的规则：每个 challenge 都要附证据。最常见的是会跑出失败的测试或可重现的反例；有时直接对照 spec，指出哪一条没满足也可以。拿不出这些东西，就当噪音。这样做有点凶，效果却差很多，因为 review 终于从「这里感觉怪怪的」变成「这个输入会错，这条验收条件没过」。
2025 年有个专门测 AI 谄媚的研究，看了大量 LLM 回复后发现，58% 带有奉承倾向。白话讲，模型很容易顺着用户，也很容易顺着前一个模型。没刻意把 review 设成对抗式，它自然会滑去橡皮图章。「帮忙 review 一下」这种 prompt 太空了，要的是「找出 3 个能证明会失败的地方」，或是「只回违反规格的条目」。
值得盯的一个数字：challenge 导致实际修改的比例。如果一轮 review 提了 10 个点，真正让代码或 spec 改动的只有 1 个，命中率连 20% 都不到，这轮大多是在演。问题通常不在 reviewer 太笨，而在 prompt 把它带去产生很像批评的废话。
这个 pattern 在 spec review 特别有感。一个金融算法 spec，整个 challenge loop 跑了 6 轮。R1 一进来就抓到 3 个真问题：有数据泄漏、滑价模型没补、重试路径也没上限。R2 又补出数据切分窗口（purge window）的 bug。一路收敛到第 6 轮，真正有效的 challenge 掉到 0，外部测试也全绿才收工。跑到第 6 轮本身不代表严谨，真正的关键是每一轮都得拿得出证据，下判断的人才知道该不该改。
challenge loop 也要给收敛上限。正常情况下，前 2 到 3 轮就该看到主要问题被抓出来。再拖下去，常见走向是每轮越写越长、越改越偏。研究把这类过度思考的循环归成高频失败模式。轮数一长，大家都像很努力，信息密度却一路往下掉。
Pattern 7：跨家族审查
模型自审这件事，可以几乎直接跳过。
理由很单纯。模型刚写完东西时，脑中那条路径还是热的。它会沿着自己刚刚的推理，把那份产出看得比实际更合理。研究也很直接：Self-Correction Bench 量到 64.5% 的盲点率，2026 年另一篇研究又看到模型在审自己产出时，放水机率大概是审别人的 5 倍，连带有风险的内容都更容易放过。
review 预算要花在独立性，不要花在仪式感。最实用的做法，就是让不同模型家族互审。ChatGPT 写的东西，交给 Claude 看；Claude 写的东西，交给 ChatGPT 看。原因也很务实：2025 年有份看 350 多个模型的分析，发现同家族模型的错误关联度明显高于跨家族。要抓盲点，得让 reviewer 带着不同的既有偏好进来。
这里也别神化。前沿模型之间的输出相似度还是很高，ICML 2025 的研究看到最高可以接近 90%。跨家族审查会提高命中率，却不会让人瞬间拥有全知视角。很多盲点是全模型共享的，像规格本来就模糊、或测试太弱、或背景知识本身有缺口。这些地方换 reviewer 也照样会漏。
最警觉的反模式叫「验证撤退」（Validation Retreat）。修补循环卡住时，Agent 很容易去改测试，让画面变绿，然后假装事情解掉了。表面上看是成功，实际上只是把基准改松。审修补时要回头看：这轮修复有没有动到测试？如果有，spec 有没有授权？改的是验收标准，还是真错误？
实战例子：让 ChatGPT 的 Codex 写一个修补，自审几乎秒过。接着用 Claude Sonnet 按验收条件一条一条审，马上抓到 3 个关键问题，而且都躲在旧路径上。Codex 的注意力全放在刚改的新逻辑，自然看不到那些地方。换一个家族来看，视角真的会变。
review 团队也不用越大越好。研究和实务都很像，两个 reviewer 差不多就是甜蜜点。再往上加，边际效益掉得很快，协调成本却继续长。对一般代码变更，保留一个写的 Agent、一个跨家族 reviewer，再加明确 spec 和测试，比堆三四个 reviewer 互相抄彼此作业稳定得多。
Pattern 8：Spec 驱动开发
很多人以为 bug 多是 review 不够严。实际上，天花板通常卡在 spec。
一开始交给 Agent 的任务如果写得模糊，后面不管审几轮，写的 Agent 跟 reviewer 都是在同一团雾里面摸。没有可执行 spec 的 AI review，本质上是一种结构性循环：两边都从同一段模糊文字推理，猜对算赚到，猜错就一起错。
这件事有数字支撑。ClarifyGPT 那篇研究把规格细化（spec refinement）放进流程后，一次通过率（Pass@1）直接从 70.96% 拉到 80.80%，提升 13.87%。很多修补循环看起来像在修代码，实际上是在补 spec 本来就该讲清楚的东西。
写复杂任务的 handoff，通常会固定放这几块：
Objective
Context
Acceptance Criteria
Interface Contract
Anti-patterns
Review Checklist题目跟数据或回测有关，再补数据完整性的要求，像是不能偷看未来数据（look-ahead）、要把交易成本和数据切分方式写实一点。这些字段写起来有点烦，却能把一大堆后面才会爆的问题直接挡在前面。
示例对照：
- 以前的 spec：「改 regime detector，改看绝对 APR，不要看相对」。
- 现在的 spec：至少写清楚一句 objective、几条验收条件、数据完整性限制，还有明确禁止的做法。
这个改法很繁琐，但效果却很明显。Codex 第一次交回来的东西通常更靠近想要的版本，修补循环也常从平均 3 轮缩到 1 到 2 轮。
Spec 也不是越厚越好。简单任务口头交代再配 1 到 2 个验收条件，常常就够了。中等复杂度的工作如果硬套完整模板，流程会明显变慢。原则是：只写到能避免歧义的程度，多的不要补。Spec 的作用是收敛，不是把所有脑内杂讯都倒给下一个 Agent。
Bonus：把三个 pattern 串成一条线
最常用的开发流水线很短：
Spec（Structured Handoff）
→ Challenge Loop（找 spec 漏洞）
→ 实作
→ Cross-family Review（找 code 漏洞）
→ 修复
→ 完成这条线的核心原则只有一句：每一步都要带入新信息。两个步骤只是同一个模型对着同一份材料再想一次，就倾向砍掉。
多 agent 并行也一样。DeepMind 那篇 orchestration scaling 研究很有参考价值：能平行拆分的任务，效果可以多出 80.9%；本质上偏串行推理的工作，表现反而会掉 39% 到 70%。沟通成本还会照 1.7 倍这个指数往上长。换成白话，Agent 变多以后，常常不是在做事，它们会互相等，接着花时间说明和验证。
Agent 数量别开太大。3 到 4 个差不多是上限，再上去 token 消耗很容易膨胀到单 Agent 流程的 3.5 倍左右。模块真的能独立拆，才值得并行。其他情况，短流程加高独立性，通常更稳。
模型会一直进步，2024 到 2026 这批研究里的具体数字，过一阵子多半会被改写。盲点率会降，review 工具也会更强，spec 生成多半也会越来越像样。
几个底层原则短时间不太会变：review 要有独立视角、spec 质量决定上限、迭代到某个点以后多半只是在空转。现在自审的盲点率大概还在 64.5% 这个量级，模型再往前走这个数字一定会掉。掉到多少以下自审才重新值得放回主流程，仍是开放问题。
延伸阅读
GitHub: https://github.com/p3nchan/orchestration-playbook
小企鹅的经验
OpenClaw 上实际跑的组合是 Opus / Sonnet / ChatGPT 三 Agent，这套 Challenge → 跨家族 review → Spec 驱动的流程也是从这里长出来的。最有感的一条：把 Opus 写的 spec 丢给 Codex 找碴，再让 Sonnet 看实作，盲点被另一家族抓出的命中率比同家族自审高很多。Spec 写薄一点、challenge 要附证据、reviewer 换家族，三条一起做才会稳。
常见问题
Q: 为什么 AI 的自我审查不可靠？
研究发现 AI 模型在审查自己的产出时有 64.5% 的盲点率，而且对自己写的东西容忍度高出 5 倍。这表示让同一个模型写完再自己审，大部分问题它根本看不到。解法是用不同家族的模型来审。
Q: 什么是 Challenge Loop？
Challenge Loop 是一种对抗式审查流程：一个 Agent 产出作品，另一个 Agent 尝试找出问题，但每个挑战都必须附上可测试的证据。没有证据的批评不算数。研究显示这种方式比一般 review 更能抓到真正的问题。
Q: Spec 质量为什么比 review 轮数更重要？
研究发现，改善 spec 质量可以让代码正确率提升 13.87%，效果比多加一轮 review 还好。原因是如果 spec 本身就模糊，reviewer 和 coder 会共享同一个误解，多审几次也发现不了。
整理：Penna｜小企鹅 Penchan