最近看到越來越多工具開始把不同 AI coding agent 接在一起：一個負責寫，一個負責 review；一個卡住時，另一個接手 rescue；甚至刻意用「對抗式審查」去找原本模型沒看到的問題。這個方向我覺得很合理，但也很容易被誤解成一句話：多找一個 AI 看過，就比較安全。
我現在比較在意的不是「有幾個模型參與」，而是團隊有沒有把反對意見設計成流程。
人類工程團隊早就知道一件事：code review 的價值不只是第二雙眼睛。真正有價值的是 review 角色和實作者之間有不同的責任、不同的視角，以及某種程度的獨立判斷。寫的人通常沉在實作細節裡，會自然地相信自己的假設；review 的人則應該站在需求、架構、維護成本、例外情境和資安風險的位置看同一段變更。
AI coding agent 進來之後，這個問題變得更微妙。因為如果只是把同一段 prompt 丟給另一個模型，叫它「幫我 review」，它常常會變成比較有禮貌的附和者。尤其當輸入裡已經包含原本 agent 的解釋、測試結果、甚至自我辯護，第二個 agent 很容易沿著同一條推理路徑走下去，最後產出一份看起來很完整、但本質上沒有增加多少獨立性的 review。
所以多代理互審的第一個重點，是不要只複製任務，要分離假設。
例如實作者拿到的是「完成這個功能」；reviewer 拿到的應該不是「請檢查他做得好不好」而已，而是更具體的檢查框架：需求是否被縮水、資料邊界是否被誤讀、錯誤處理是否只是 happy path、權限是否被放大、測試是否只證明目前案例會過、是否改到不該改的地方。這些問題會強迫 reviewer 從反方向拆解，而不是接著實作者的敘事往下寫。
第二個重點，是交接要有合約，不要只丟一坨上下文。
我看過不少 AI workflow 的失敗，不是因為模型不聰明，而是因為交接太像「把整個聊天紀錄轉寄給下一個人」。接手的 agent 讀了一堆過程，但不知道哪些是事實、哪些是假設、哪些已驗證、哪些只是前一個 agent 的猜測。最後它要嘛重跑一遍，要嘛更糟：把猜測當成結論。
如果要讓一個 agent 寫、另一個 agent review，或讓第三個 agent rescue 卡住的任務，我會希望 handoff 至少包含幾個明確欄位：目標、已修改檔案、已執行測試、未驗證風險、已知取捨、需要人工決定的問題。這些欄位不漂亮，但它們能把「故事」轉成「可接手的工程狀態」。
第三個重點，是 reviewer 不能同時背負「把事情做完」的壓力。
這點在人類團隊也一樣。如果 reviewer 的 KPI 是今天一定要把功能合併，那 review 很快就會變成幫忙擦屁股。AI agent 更容易掉進這個洞，因為它天生傾向完成任務、修補錯誤、讓 build pass。當 reviewer 發現問題時，它可能會順手改掉，然後又開始為自己的修改找理由。結果原本用來制衡的角色，又變成另一個實作者。
我比較偏好的模式是：review agent 可以提出 patch 建議，但它的主要輸出應該是風險清單、證據、嚴重度和建議處置。要不要套用、由誰套用、是否需要回到需求澄清，應該是流程裡另一個明確步驟。這聽起來比較慢，但對正式產品來說，慢一點通常比「兩個 AI 很快地互相同意」可靠。
第四個重點，是對抗式審查要有邊界。
「請用最嚴格的角度挑毛病」很有用，但如果沒有邊界，也會變成無限懷疑。好的 adversarial review 不該只是唱反調，而是針對高風險面向集中火力：資料遺失、權限繞過、交易一致性、背景任務重入、使用者看得到不該看的資訊、失敗後無法回復。換句話說，對抗不是情緒，是風險模型。
這也是我覺得 CTO 或技術主管不能只把多代理工具當成個人生產力玩具的原因。當這些工具進入團隊流程，真正要設計的是責任鏈：誰提出變更、誰驗證、誰反對、誰決定接受風險、紀錄在哪裡、事後如何回溯。模型只是角色的執行者，流程才是系統的骨架。
未來我相信 AI coding workflow 會越來越像一個小型工程組：planner、implementer、reviewer、tester、release checker，各自有不同工具和上下文。但這不代表我們可以放任它們在同一個聊天室裡自由發揮。相反地，越多 agent 參與，越需要清楚的輸入輸出契約、權限分層、停止條件和審計紀錄。
多代理互審最有價值的地方，不是讓 AI 彼此壯膽，而是讓系統裡真的出現一個會說「等一下，這裡不對」的角色。
如果那個反對意見有證據、有範圍、有後續處置，而且不會被「趕快合併」的壓力吃掉，那它才不是多叫一個 AI 來背書，而是工程流程的一部分。這也是我對 AI coding 工具下一階段最期待的地方：不是更會寫，而是更會把不同意見留下來，變成可管理的品質迴路。