這篇解決什麼問題：同一個 AI 既規劃又驗收，等於球員兼裁判，出了錯沒人抓得到。這篇講怎麼把流程拆成四個互相制衡的角色，讓錯誤真的有人擋下來。
適合誰讀：已經在用 subagent 委派任務、但發現委派了準確度也沒提升的人。
讀完能做到什麼：能寫出四個角色各自的職責與硬性界線，並分清楚哪兩道關卡該在不同時間點、各自驗證什麼。
以下是 2026-07 當時的做法。這套流程之後還在演進，這篇沒有回頭逐條更新，數字與條款都停在那個時間點。
同一個 AI 規劃又驗收，就是球員兼裁判
起點是一次真實的卡關：我不具技術背景，發現「planner 自己出計畫、自己說沒問題」時完全無從判斷對錯。計畫合不合理、有沒有漏洞，全靠寫計畫的那個 AI 自己講。這跟找一個人自己出考題、自己改考卷沒有差別，分數再高也不能信。
解法是拆權力。規劃的人不能同時是驗收的人，中間還得插一個專門找碴的角色。
四個角色只做一件事，出錯才有人追得到
這四個角色是 coding agent 底下各自獨立的 subagent，各自有獨立的記憶。主 AI，也就是你直接對話的那一個，只負責彙整與派工，不親自做研究或審查。
流程走向如下：
flowchart LR Main[主AI彙整派工] --> R[researcher蒐集資料] R --> P[planner產出契約] P --> PR[plan-reviewer對抗審查] PR -->|改寫計畫| Main Main --> Impl[實作階段] Impl --> E[evaluator驗收] E -->|回報結果| Main
四個角色各自負責一件事：researcher 只蒐集不判斷，把競品、本地資料、網路文章整理成結構化摘要；planner 只分析不動手寫檔，產出一份帶量化驗收條款的契約；plan-reviewer 假設 planner 是錯的，對抗性審查計畫、直接改寫；evaluator 收尾驗收，零容忍放水，只回報不修理。
兩道關卡的驗證時點不一樣：plan-reviewer 在規劃期驗「契約本身合不合理」，evaluator 在交付期驗「實作符不符合契約」。這兩件事看起來都叫「審查」，但問的問題完全不同，職責不重疊。
技術細節：四角色完整權責表
角色 職責 硬性界線 researcher 蒐集競品、本地資料、網路文章，輸出 500 token 以內的結構化摘要 只蒐集不審查、不推薦方案；輸出必標「結論性質」（外部共識、非本場景實證、待實機仲裁） planner 讀文件、批判審查、產出可量化驗收契約 只分析不寫檔；契約必含行為驗收條款；researcher 的結論只能進「事前假設」區塊並配實機仲裁條款 plan-reviewer 假設 planner 是錯的，對抗性審查計畫並直接改寫 七面向逐項必檢：方案合理性、契約充分性、風險盲點、是否盲從研究結論、步驟粒度、既有決策覆蓋、對我是否友善。單輪定勝負不迭代；只改計畫檔案 evaluator 收尾驗收：跑型別檢查、逐條比對契約、掃描反模式 零容忍放水、只回報不修理；先檢查契約形狀，無行為驗收條款直接判形狀不合格；無法機械驗證的 UI 行為標「待我實機確認」而非放行
對抗審查抓到過會拖慢效能的規劃錯誤
某次預約功能任務裡，planner 的方案含有重複抓取資料的缺陷，也就是同一筆資料被前後兩次不必要的請求各拉一次。plan-reviewer 親自查過原始碼後抓出這個問題，任務因此降級簡化。它擋下了一個會實際拖慢效能的規劃錯誤。
委派只能由主 AI 發起，角色之間不准互相呼叫
每個 agent 都禁止再呼叫其他 agent，這是鏈式委派禁令。原因很直接：一旦 planner 可以自己叫 researcher、reviewer 可以自己叫 planner，權責邊界就瓦解了，主 AI 會失去對整條流程的可見性，出錯時也無法歸因到是哪一步出的問題。所有委派只能由主 AI 發起，其他角色專心做自己那一件事。
外部研究結論在實機驗證前只能當假設
AI 很容易把「網路上多數人這麼說」直接當成「本專案的事實」來用。曾有一次依外部共識判斷的技術方向，拿到實機上直接失敗。因此立了硬規則：researcher 的輸出必須標註結論性質，不准斷言為本專案的真值；planner 只能把外部結論寫進「事前假設」區塊，並配一條實機仲裁的驗收條款。曾有一個任務的 planner 假設經實機證偽後，整個任務方向被推翻重來——理論分析永遠讓位給實機證據。
純 prompt 調整治不好多 agent 失敗
UC Berkeley 的 MAST 研究（Why Do Multi-Agent LLM Systems Fail?）把多 agent 失敗歸成三大類十四種模式，包括規格與角色定義失敗、代理間失調（不請求澄清、資訊隱瞞、任務偏離）、驗證與終止失敗（提前終止、無驗證或錯誤驗證）。這份研究的關鍵發現是：純 prompt 層面的改進只帶來約 14% 改善，要根治得靠結構性重設計，也就是驗證機制、通訊協定、狀態管理這類硬邊界。四角色管線的硬性界線就屬於這類結構性機制。
Anthropic 官方的最佳實踐文件（Claude Code Best Practices）也提到一個膨脹傾向：被要求「找 gap」的 reviewer 一定會報出 gap，結果計畫越審越肥、走向過度工程化。目前這套管線靠「最小解自檢」條款間接防肥，「明文限定 reviewer 只報正確性缺口」這個對策評估過，但尚未採用。
另外，writer 與 reviewer 用互相隔離的乾淨 context 去審查，也就是所謂的 fresh-context review，是業界通則；actor-critic、test-writer 與 code-writer 分離等變體都是同一個原理的不同實作。
相關連結
待辦 / 疑問
- plan-reviewer 是否加「只報影響正確性或驗收的缺口」限定（官方警告的膨脹傾向，本次評估未採）