上一篇在談一件很底層的事：多 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