最近 multi-agent 越來越流行。
但我一直有一個疑問：我們到底是在解決一個必須用多個 Agent 才能解決的問題，還是只是因為現在流行 multi-agent，所以把原本一個 Agent 能完成的事情，拆成幾個 Agent 互相講話？
如果只是把 planner、critic、reviewer 拆成三個角色，但底層還是同一個模型、同一份資訊、同一組工具，最後再互相把答案傳來傳去，這是不是只是一個成本更高、鏈路更長的 single-agent workflow？
回歸到一個實際的面向上，什麼情況下，我們才真的應該把系統拆成 multi-agent？
我目前大概整理出四個判準。
一、需要保持真正獨立的認知路徑
AI 很容易被引導。
這裡的引導不一定是惡意 prompt injection，也可能只是一個非常普通的現象：一旦前面的上下文先給出了某種假設，後面的推理就很容易繼續沿著那個方向走。
例如一個 Agent 先提出：
「問題可能出在資料庫。」
接下來你再讓同一個 Agent 做檢查，它很可能會不斷從資料庫方向尋找證據，就算你告訴它「請批判前面的答案」，它還是已經看過前面的答案了。
這時候所謂 critic，其實已經被 anchor。
所以 multi-agent 其中一個合理用途，是讓不同 Agent 保持真正獨立的上下文和 framing。
一個 Agent 從支持這個假設開始，另一個 Agent 完全不知道前面的推理，從反方向調查，甚至還可以有一個 Agent 專門負責誘導其他 Agent，看它們會不會輕易改變判斷，避免所有 Agent 從同一個認知起點出發。
如果幾個 Agent 從一開始就共享了全部上下文，最後只是彼此同意，那麼這種 multi-agent 很可能沒有產生真正的新資訊。
我覺得這裡有一個很重要的區別：collaboration 不一定有價值，那我們不如試試看 controlled disagreement。
二、問題本身需要對抗，而不是討論
第二個情況，是任務需要互相質疑。
很多 multi-agent 系統看起來像這樣：
A 提一個方案，B 說這個方案不錯，但可以補充幾點。
C 再總結兩個人的意見。
最後大家得到一個更長的答案。
這種互動很像會議，但它未必真的增加了推理深度，真正有價值的對抗應該更明確。
例如：
Agent A 必須提出一個可以被驗證的結論，Agent B 的職責不是發表意見，而是尋找反例，Agent C 專門檢查兩邊有沒有使用未經證明的假設。
Agent D 再根據證據做裁決。
用 multi-agent 形成一套驗證機制，跟第一種不一樣的是，第一種目標是在建立思維的獨立性，第二種是利用對抗來進行驗證，最好還可以用多種不同的 LLM。
如果某項工作本身需要 red team、審計、漏洞尋找、證明與反證、多個假設競爭，那麼拆成多個 Agent 比較容易成立。
但對抗必須是制度化的，不能只是 prompt 裡面寫一句：「請大膽質疑其他 Agent。」
應該明確規定什麼東西可以被攻擊、需要提供什麼證據、什麼條件算推翻，以及最後如何做判斷。
否則很容易又變成 AI 在互相客氣商業吹捧。
三、單一 Agent 的注意力開始過載
Agent 並不是能力越多就一定越好，當一個 Agent 同時承擔太多角色，它需要不斷判斷：
- 現在應該關注什麼？
- 哪一條 instruction 優先？
- 要使用哪一個工具？
- 哪些上下文和現在的問題有關？
- 之前的狀態還需要保留嗎？
- 不同技能之間有沒有衝突？
這時候問題開始從「能力不夠」變成「注意力分配」，尤其是長期運行的 Agent，這個問題會越來越明顯。
為了保持它的工作範圍足夠窄，例如安全 Agent 長期只關注攻擊面，財務 Agent 只維護財務狀態等等。
執行 Agent 不需要知道全部戰略討論，更專注在執行的準確度、難度，以及回報等等；研究 Agent 也不需要擁有生產環境的寫權限，更著重在查驗、核實、搜尋案例等等。
這樣能減少不同 context、skill 和責任之間的干擾。
如果不同任務需要長期維護各自獨立的 context、memory、tool state 和關注點，那 multi-agent 可以讓彼此的工作更加準確。
四、工作流本身已經不是一條線
最後一個，也是我覺得經常被忽略的問題，不是所有工作都是：A → B → C → D。
很多 Agent 系統現在仍然是用類似 heartbeat 的方式推進，每隔一段時間醒來，檢查當前狀態，決定下一步，執行，再進入下一個狀態。
對於簡單流程，這沒有問題。
但真實工作經常不是線性的。
很多時候不同分支同時執行，例如剪輯部門同時會接手好幾個部門的資料排程剪輯，剪好之後營運審核，如果失敗了就要丟回重剪，但也可能要補鏡頭，讓原本生產部門重新拍攝，一拍攝又得跟手上任務排隊，但子任務可能又有時間急迫性等等。
營運通過的影片還要送轉檔分發，分發部門還要錯開高峰期避免被判定為機器人。
單 Agent 當然也不是完全做不到，你可以在一個 engine 裡面維護一個很大的狀態機，不斷檢查每一個 branch，然後模擬不同角色，當任務複雜度增加，這個 engine 最後本身就開始變成一個調度系統。
而且維護起來很困難。
而 multi-agent 的價值就在這裡出現了，每個 Agent 可以擁有自己的生命週期和狀態，不同分支可以真正並行，對於問題的產生可以各自解說調度規則，有些 Agent 等待外部環境，有些繼續工作，最後透過明確的同步機制重新匯流。
到了這個階段，我們面對的其實已經不只是 AI reasoning，它開始越來越像分散式系統。
你需要考慮：
- 誰擁有狀態。
- 誰可以修改狀態。
- 重複執行會不會出問題。
- 兩個 Agent 同時操作同一個資源怎麼辦。
- 一個 Agent 死掉之後由誰接管。
- 如何判斷整個任務已經結束。
- 什麼時候需要鎖。
- 什麼時候應該使用 lease。
- 如何處理版本衝突。
這些在單 Agent 裡的確難搞。
如果我要設計一個 Agent 系統，會先考慮是否無法合理壓縮回一個 Agent。
目前思考下來大約有四種：
第一種是認知無法壓縮，我們真的需要彼此獨立的觀察角度，避免同一套上下文把所有推理帶到同一個方向。
第二種是對抗無法壓縮，任務本身需要不同立場互相攻擊、證明和驗證。
第三種是注意力無法壓縮，不同角色需要長期維護自己的 context、memory、skill 或責任範圍。
第四種是工作拓撲無法壓縮，任務本身已經出現真正的並行、分叉、匯流、資源競爭和不同生命週期。
如果這幾個條件一個都不存在，單 Agent 會更好地解決問題，畢竟 multi-agent 本身不是免費的，越多 multi-agent 也意味著越高的成本，Agent 越多，意味著更多通訊、更多狀態同步、更多失敗點，也更難知道最後到底是誰出了問題。
因此不要先設計 Agent，先看問題裡面有沒有不可壓縮的差異，再決定這些差異應該被拆成幾個獨立執行單元。
這樣至少可以避免一種現在越來越常見的情況：為了讓 Agent 互相協作，所以先創造出一群 Agent，然後再開始想它們到底要協作什麼，雖然這樣看起來很帥。