多智能體編排：五種模式與「該不該拆」的決策框架

多智能體編排：五種模式與「該不該拆」的決策框架

2025 年中，Anthropic 公開了自家 Research 功能的幕後架構：一隻「總管」agent 帶領 3 到 5 隻子 agent 併行做研究，複雜查詢的研究時間最多縮短 90%，內部評測比單一最強模型高出 90.2%。「多智能體」一夕成了所有 agent 產品的標配詞彙。

隔年（2026 年 4 月），Stanford 的研究卻潑了一盆冷水：在算力對等的條件下，單一 agent 常常一樣好、甚至更好——agent 之間交接時流失的資訊，往往把併行的紅利吃光。

於是問題變得很有意思：多智能體編排到底在解決什麼問題？本文整理五種常見模式，並給出一個「該不該拆」的決策框架。

一、Anthropic 怎麼做：Orchestrator–Worker

Anthropic 的多智能體研究系統是目前最有說服力的生產級案例（Anthropic Engineering Blog, 2025/6）。架構很直白：

  • 一隻 Lead agent（Claude Opus 4）負責分析查詢、制定研究策略、把任務切成可併行的線程；
  • 派給 3–5 隻 子 agent（Claude Sonnet 4），各自擁有獨立的 context window，平行探索不同角度；
  • Lead 等子 agent 全部回來後彙整成最終答案，必要時再派第二輪。

兩個層次的平行化。不只 agent 層併行（3–5 隻子 agent），工具層也併行——每隻子 agent 同時打 3 個以上的搜尋工具。這是時間縮短 90% 的主因。

代價是 token。多智能體系統的 token 用量約為純聊天的 15 倍，只划算在高價值任務上。這也是為什麼他們把「工作量級縮放規則」直接寫進總管的 prompt：簡單事實查詢只用 1 agent＋3–10 次 tool call，複雜研究才上 10+ 子 agent。

委派必須明確。實戰教訓：模糊的委派會造成重工。總管給子 agent 的指令要包含明確目標、輸出格式、以及與其他子 agent 的邊界。

一個反直覺的洞見。他們發現，升級到更好的模型（Sonnet 4）帶來的效率提升，大於把 token 預算直接翻倍——模型品質 > 算力堆疊。

同樣誠實的是他們的 caveat：需要緊密共享 context 的任務（例如寫程式）效益有限——這點後面 Stanford 的研究會用數字再證實一次。

二、五種編排模式速覽（如圖一）

把業界框架（LangGraph、AutoGen、CrewAI、OpenAI Agents SDK）與學術文獻攤開看，生產級的多智能體系統其實只收斂成五種形狀：

1. Orchestrator–Worker（總管—工人型）
總管拆解任務、派發、彙整。適合可分解、讀取密集、廣度優先的工作。LangGraph 稱之為 Supervisor Pattern（「supervisor 的工具就是其他 agent」），CrewAI 叫 Hierarchical Process，Anthropic 內部就叫 Orchestrator–Workers。

2. Sequential Pipeline（接力管線型）
agent 按固定順序接力：研究 → 撰寫 → 審查。上一棒的輸出是下一棒的輸入。沒有併行所以慢，但最容易理解與除錯，適合流程固定、每一步都要產出中間成品的任務（文件處理、合規審查）。

3. Fan-out / Fan-in（併行發散—收斂型）
多隻 agent 用不同策略／不同模型／不同工具集，同時解同一道題，最後投票或加權收斂。研究顯示，彼此看不到對方、只做單一面向的獨立驗證者能帶來 8–20% 的穩定增益，而「生成端」的多智能體（辯論、混合模型）在算力對等下常常贏不了強單一 agent。重點：併行的價值在「獨立驗證」，不在「一起發想」。

4. Hierarchical（階層團隊型）
總管下面還有 team lead，team lead 再帶工人。LangGraph 用子圖（subgraph）表達：一個團隊本身就是上層圖的一個節點。協調開銷最大，只有單一總管的協調負載成為瓶頸時（企業級規模）才需要。

5. Debate／Critic-Actor（辯論—批判型）
一隻 agent 提案，另一隻的唯一工作就是挑毛病，多輪攻防後定稿。目的不是快，而是抓出「自己審自己」會漏掉的錯誤。

如圖一，五種模式沒有絕對優劣，只有「適不適合手上的任務」。

三、Stanford 2026 的潑冷水：何時不該拆

2026 年 Stanford 連發了幾篇直指要害的研究，值得每個要做多智能體的人讀：

辯論在什麼時候真的有用？（2026/4）Stanford 團隊把辯論架構、序列鏈、集成方法、單一 agent 放在一起比較。辯論在團隊配置中勝出，但只在三種情境下優勢明顯：底層模型較弱、輸入資料有噪聲、需要從大量資訊中篩選。一旦把算力拉平——給單一 agent 同樣的總算力——單一 agent 常常打平甚至反超。元兇就是交接時的資訊流失。

會自己組織的團隊才算數。Stanford 的 SAT（self-organizing AI teams）框架讓模型自己學會組織策略，而不是硬套辯論協議。結果：平均準確率 66.7%，超過等算力單一 agent 的 58.7%，在 AIME 2026 上達到 71.2%。最有意思的發現是「可辨識性」（demonstrability）：當正確的推理一出現在對話中、團隊能認出來並跟進時，增益最大（Spearman 相關 0.90）。換句話說，多智能體的紅利不在「人多」，而在「懂得合作」——數學、物理這類推理鏈可驗證的領域最吃香。

辯論讓解釋變漂亮，但決策沒有變好。另一篇 Stanford 論文（arXiv:2609.29701）在模擬市場中跑了 210 次受控實驗：多輪辯論把推理品質評分從 0.72 拉到 0.84（+17.7%），但推理品質與投資組合的 Sharpe ratio 相關係數只有 r = 0.07——agent 們寫出了漂亮得多的辯護詞，配置決策本身卻沒有變好。評估時只看對話紀錄會被騙，這正是「評測要看終點、不要只看軌跡」的原因。

把三篇研究和 Anthropic 的實戰放在一起，結論很一致：多智能體的勝場集中在「可分解、讀取密集、廣度優先」的任務；凡是需要緊密共享 context、交接成本高的任務，單一 agent 往往是更好的答案。

四、決策框架：該不該拆？（如圖二）

動手前先依序回答三個問題：

問題一：任務能拆成獨立子任務嗎？
不能 → 直接用單一 agent。硬拆只會製造協調成本。

問題二：子任務之間依賴緊密、需要共享完整 context 嗎？
是 → 用單一 agent。Stanford 已經證明，handoff 的資訊流失會吃掉併行紅利；Anthropic 也承認寫程式這類任務效益有限。

問題三：任務是什麼型態？

  • 廣度優先／讀取密集（研究、資訊蒐集）→ Orchestrator–Worker。Anthropic 的 90.2% 就是在這裡拿到的。
  • 需要多視角糾錯 → Debate＋「新鮮 context 的驗證者」。Anthropic 的實戰結論：用全新 context 的子 agent 做驗證，效果優於讓原 agent 自我批判。
  • 嚴格順序相依（draft→review→revise）→ Sequential Pipeline。慢，但每一步都可審計。

最後檢查：成本。多智能體約 15 倍 token，任務的價值夠高嗎？不夠 → 回到單一 agent。這條檢查線應該寫成團隊的硬性門檻，而不是憑感覺。

五、實作要點

選定模式之後，還有四個工程細節決定成敗：

  1. 委派要寫規格：每個子 agent 的目標、輸出格式、與他人的邊界，全部寫死在 prompt 裡。模糊是重工的源頭。
  2. 狀態外部化：把研究計畫與已完成階段存在 agent 外部，才能撐過 context window 截斷、支援失敗續跑（durable execution）。
  3. 可觀測性＋人審核點：長跑流程需要漸進式部署（rainbow deployment）與中途介入機制，例如 LangGraph 的 interrupt()／Claude Code 的 plan-approval gating。
  4. 評測看終點：Anthropic 用單一 LLM judge 按固定維度（事實正確性、引用品質、完整性、來源權威性、工具效率）打分——judge 終態，不驗證每一步。

附上一段 LangGraph Supervisor 模式的骨架（Python，概念示意）：

def supervisor(state):
    # 總管：看目前狀態，決定下一個工人，或結束
    decision = supervisor_llm.invoke(state["messages"])
    return decision.next_agent  # "researcher" / "coder" / END

builder.add_node("supervisor", supervisor_node)
builder.add_node("researcher", researcher_node)
builder.add_node("coder", coder_node)
builder.add_conditional_edges(
    "supervisor", supervisor, ["researcher", "coder", END])
builder.add_edge("researcher", "supervisor")  # 做完回報總管
builder.add_edge("coder", "supervisor")

動態併行（「把 N 個子題各派一隻 agent」）則用 LangGraph 的 Send 原語：一個 plan 節點在執行期才決定派幾個分支。

結論

多智能體不是「越多越強」，而是「拆得對才強」。Anthropic 證明拆對了可以快 90%、品質高 90.2%；Stanford 證明拆錯了只是在燒 15 倍 token，還附贈資訊流失。

真正的功夫不在框架選型，而在動手前的三個問題：能不能拆、該不該拆、拆成哪種形狀。先回答，再開工。

來源

Uploaded Image Uploaded Image
Posted by at

沒有留言:

張貼留言

訂閱： 張貼留言 (Atom)