多智能体：扇出、对手、综合
还有第二种「多个智能体」的口味，它运行在一个任务之内，而非跨越彼此独立的任务。不是让一个智能体做所有事，而是把角色拆开：
- 为求广度的扇出。 多个智能体从不同角度攻同一个问题——或探索一个大代码库的不同部分——然后回报。当你想要覆盖面时很有用：「找出我们调用这个已弃用函数的每一处」就很好并行。
- 对抗式审查者。 一个智能体写；第二个智能体唯一的工作是攻击第一个的输出——找出 bug、漏掉的边界情况、未处理的错误。一个被指向 diff、带着「假设这是错的，并查清为什么」指令的审查者，会逮住作者智能体把自己说服了的东西。
- 综合。 最后一遍收集这些发现，产出一个连贯的结果——可运行的代码，外加一段简短的说明：审查者标出了什么，以及它是如何被解决的。
Reviewer agent brief:
You are reviewing a diff written by another agent. Assume it contains
at least one bug and find it. Specifically check:
- Does it actually satisfy the original goal, or just pass the tests?
- Edge cases: empty input, nulls, the largest realistic input.
- Anything deleted or changed that the task didn't ask for.
Report concrete problems with file and line. Do not rewrite the code —
just report. If you find nothing after a genuine look, say so plainly.
三个角色构成一条末端带关卡的流水线：在对抗式审查者过完一遍、综合环节解决掉它的发现之前，什么都到不了一次提交：
┌────────────────────── 在单个任务内 ───────────────────────┐
│ │
│ ┌──────────┐ │
│ │ 扇出 │ 多个智能体，不同角度 │
│ │ 智能体 │ ── 广度 / 覆盖 ──┐ │
│ └──────────┘ ▼ │
│ ┌──────────┐ ┌──────────────┐ │
│ │ 作者 │── 写差异 ────▶│ 审查者 │ │
│ │ 智能体 │ │ “假设它错， │ │
│ └──────────┘ │ 找出漏洞” │ │
│ │ │ │
│ └──────┬───────┘ │
│ ▼ │
│ ┌──────────────┐ │
│ │ 综合 │ 合并 │
│ │ 修复 + 备注 │ 发现 │
│ └──────┬───────┘ │
└────────────────────────────────────────┼──────────────────┘
▼
── 关卡 ──▶ commit ✓
对抗式审查者值得设置，即便你是没有一支智能体舰队的单枪匹马——因为一处改动的作者，无论人还是 AI，都是最不适合找出其缺陷的那个。用一段敌意的提示再过一遍，是廉价的保险。