這篇解決的問題：讓同一個 AI 同時負責規劃、實作與驗收，容易導致球員兼裁判、抓不出潛在的系統設計漏洞。 適合誰讀：已經在開發流程中使用 subagent，子代理程式，也就是由主 AI 委派執行特定小任務的獨立 AI 代理，但發現即使委派了，產出品質與準確度依然沒有提升的開發者。 讀完能做到什麼：能為 AI 協作開發流程設計出四個職責分明、互相制衡的角色，建立硬性防護邊界，並學會將規劃期與交付期的兩道驗收閘門完全解耦。
注意：本篇記錄的是 2026-07 當時的做法。這套流程之後還在演進，這篇沒有回頭逐條更新，所有數據、條款與結論都停留在該時間點。
為什麼要拆分多 Agent 協作？
這套分工的起點來自於一次在 Nailora，我開發的美甲情報 App 專案，中的真實反饋。我不具備深厚的技術背景，當我發現「planner 自己提出計畫、自己說沒問題」時，我完全無從判斷真偽。這就像是讓同一個工程師自己寫規格、自己開發、又自己簽章驗收。
為了解決這個球員兼裁判的問題，我引入了對抗性審查的機制，也就是強迫另一個 AI 站在對立面尋找漏洞。這套管線運作的邏輯如下：
graph TD Researcher[researcher 只負責蒐集資訊] --> Planner[planner 負責分析並產出契約] Planner --> PlanReviewer[plan-reviewer 負責對抗性審查與改寫] PlanReviewer --> Evaluator[evaluator 負責零容忍交付驗收]
四個角色的核心分工與硬性界線
這四個角色都是 coding agent，也就是輔助寫程式的 AI 代理，底下的 subagent。它們各自擁有獨立的上下文記憶，而不是由同一個對話串一演到底。
| 角色 | 職責 | 硬性界線 |
|---|---|---|
| researcher | 蒐集競品、本地資料、網路文章，輸出 500 token 以內的結構化摘要 | 只負責蒐集而不進行審查，也不推薦方案；其輸出必須明確標註結論性質（如：外部共識、非本場景實證、待實機仲裁） |
| planner | 閱讀文件、進行批判審查、產出可量化的驗收契約 | 只進行分析而不動手寫入檔案；產出的契約必須包含行為驗收條款；對於 researcher 提供的結論，只能放入事前假設區塊，並配對實機仲裁條款 |
| plan-reviewer | 假設 planner 的方案是錯的，進行對抗性審查並直接改寫計畫 | 必須逐項檢驗七個面向（方案合理性、契約充分性、風險盲點、是否盲從研究結論、步驟粒度、既有決策覆蓋、對我是否友善）；單輪對話定勝負不進行迭代；只允許修改計畫文件 |
| evaluator | 負責收尾驗收，包含跑型別檢查、逐條比對契約、掃描反模式 | 採取零容忍放水態度，只負責回報錯誤而不動手修理；先檢查契約形狀（若無行為驗收條款則直接判定形狀不合格）；無法進行機械化驗證的 UI 行為，必須標註待我實機確認，而非直接放行 |
兩道驗收閘門的時點解耦
這套管線的核心在於將兩道閘門在不同時點徹底分開。第一道閘門在規劃期，由 plan-reviewer 驗證「契約本身是否合理」；第二道閘門在交付期，由 evaluator 驗證「實作成果是否符合契約」。兩者的職責完全不重疊。
在一次預約功能的任務中，planner 提出的方案含有重複抓取資料（double-fetch）的缺陷。plan-reviewer 在規劃期親自驗證原始碼後抓出了這個問題，任務因此得以降級簡化，避免了後續實作上的災難。對抗審查並非形式，它在實務上確實能有效抓出規劃階段的錯誤。
嚴格禁止鏈式委派
在管線運行中，每個 subagent 都被硬性禁止呼叫其他 agent。一旦 planner 可以自己呼叫 researcher，或者 reviewer 可以自己呼叫 planner，權責邊界就會溶解。
這種權責模糊會導致主 AI 失去對流程的可見性，一旦出錯將無法歸因。因此，所有委派動作必須由主 AI 發起。主 AI 也就是我直接進行對話的那一個 AI，它只負責彙整與對話，絕對不越俎代庖去做研究或審查。
外部結論必須標註「待仲裁」
AI 非常容易犯下一個錯誤：把網路上多數人認同的共識，直接當成我當前專案的事實。
在開發實務中，我學到了血淋淋的教訓。researcher 整理出來的摘要，不等於專案驗收通過。我曾因為採信外部共識而決定技術方向，結果在實機上直接宣告失敗。因此我確立了「外部結論待仲裁」原則：
- researcher 的輸出必須標記結論性質，禁止直接斷言為本專案的真值。
- planner 只能將外部研究結論寫入「事前假設」區塊，且必須配有一條實機仲裁的驗收條款。
- 理論分析必須永遠讓位給實機證據。如果 planner 的假設經實機證偽，整個任務方向就得推翻重來。
技術細節：學術研究與業界實踐對照
關於多 Agent 系統的失敗模式與對抗審查的膨脹問題，可以對照以下業界研究：
UC Berkeley 的 MAST 失敗模式分類： 在 Why Do Multi-Agent LLM Systems Fail? 研究中，學者將多 Agent 系統的失敗歸納為三大類 14 種模式。主要包含規格與角色定義失敗、代理間協調失調（不請求澄清、資訊隱瞞、任務偏離）以及驗證與終止失敗（提前終止、無驗證或錯誤驗證）。該研究指出，純 prompt 層面的改進僅能帶來約 14% 的效果，要根治必須依靠「結構性的機制設計」（例如驗證機制、通訊協議與狀態管理）。本管線所設定的硬性角色界線，正是這種結構性機制。
Reviewer 的膨脹傾向： Claude Code Best Practices 官方最佳實踐中明確警告，被要求尋找缺口的 reviewer 往往會為了回報而回報，導致計畫越審越肥，造成過度工程化。對策是限制 reviewer 只能回報「影響正確性或驗收」的缺口。目前本管線主要依靠「最小解自檢」條款來間接防止計畫過度膨脹。關於「明文限定 reviewer 只報正確性缺口」的提案，我評估過但目前尚未採用。
業界共識做法： 讓寫作者（writer）與審查者（reviewer）使用完全隔離的乾淨上下文（fresh-context review）是業界的通用做法。本管線的角色隔離，與學術界常見的 actor-critic、test-writer 與 code-writer 分離等變體在邏輯上是一致的。
相關連結
待辦
- 待辦：評估是否為 plan-reviewer 加上「只回報影響正確性或驗收之缺口」的限制，以應對官方警告的 reviewer 膨脹傾向。