多智慧體：扇出、對手、綜合
還有第二種「多個智慧體」的口味，它執行在一個任務之內，而非跨越彼此獨立的任務。不是讓一個智慧體做所有事，而是把角色拆開：
- 為求廣度的扇出。 多個智慧體從不同角度攻同一個問題——或探索一個大程式碼庫的不同部分——然後回報。當你想要覆蓋面時很有用：「找出我們呼叫這個已棄用函式的每一處」就很好並行。
- 對抗式審查者。 一個智慧體寫；第二個智慧體唯一的工作是攻擊第一個的輸出——找出 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，都是最不適合找出其缺陷的那個。用一段敵意的提示再過一遍，是廉價的保險。