上篇我們把 Tool Calling 做成了能扛生產(chǎn)的招式——定義規(guī)范、校驗兜底、并行編排、超時重試冪等四件套單 Agent 調(diào)用工具這件事基本穩(wěn)了。但單個 Agent 再能打遇上先查庫、再寫報告、還要調(diào)外部系統(tǒng)對賬這種復合型任務一個人干活會累死、上下文也會爆。這篇就聊怎么組隊多智能體協(xié)作的三種編排模式到底怎么選。一、多智能體不是靈丹妙藥先潑盆冷水我見過太多團隊聽了幾場發(fā)布會上來就搞個 Multi-Agent 系統(tǒng)結果三個月后發(fā)現(xiàn)自己是在用三個大模型互相甩鍋。多智能體引入的是復雜度不是能力——單個強 Agent 加好工具搞不定的多 Agent 大概率也救不了反而多了狀態(tài)同步、收斂控制、成本爆炸三座大山。所以在看模式之前先記牢一條能一個 Agent 幾個工具解決的絕不上多智能體。下面三種模式是確實需要一個團隊時的選型菜單。二、三種主流模式長什么樣【Supervisor / 編排者-工作者】 Supervisor(大腦:拆解匯總) │ 派發(fā)子任務 ├─? WorkerA(查庫) ─┐ ├─? WorkerB(計算) ─┤ └─? WorkerC(報告) ─┘ │ 收回結果合成答案 ▼ 最終答案 ? 【Router / 分診-專家】 用戶輸入 │ ▼ Router(分類:意圖識別) │ 選定單一專家 ▼ Expert(一人到底) ──? 答案 (專家可再二級路由但仍是一條線) ? 【Swarm / 去中心化蜂群】 AgentA ─handoff─? AgentB ─handoff─? AgentC ▲ │ └────── 共享黑板(Blackboard) ?──┘ 無固定中心誰接得住誰上動態(tài)移交三種模式的本質(zhì)區(qū)別就一句話誰來決定下一步誰干——Supervisor 是集中決策Router 是一次性分發(fā)Swarm 是動態(tài)移交。三、Supervisor有規(guī)劃、能匯總時用它當任務能清晰拆成幾個子任務、且最終要有人把碎片拼成一個完整答案比如分析這個月的經(jīng)營數(shù)據(jù)并出一份周報Supervisor 最順手。核心是三段規(guī)劃 → 派發(fā) → 匯總。// SupervisorOrchestrator.java —— 編排者-工作者模式JDK 17 LangChain4j 1.x // 適用任務可拆解、子任務各有專長、需要匯總成統(tǒng)一輸出 public class SupervisorOrchestrator { ? private final ChatLanguageModel llm; // 主力大模型負責規(guī)劃與匯總 private final MapString, Agent workers; // 按能力名注冊的專能 worker ? public OrchestrationResult run(String goal) { // 1) 規(guī)劃讓 LLM 把目標拆成有序子任務強制輸出 JSON結構化是可控的前提 String planJson llm.generate(planPrompt(goal, workers.keySet())); TaskPlan plan JsonUtil.fromJson(planJson, TaskPlan.class); ? // 2) 派發(fā)有依賴的串行、無依賴的可并行并行編排見 Day 92 ListSubResult subs new ArrayList(); for (Task t : plan.tasks()) { Agent w workers.get(t.owner()); subs.add(new SubResult(t, w.execute(t.desc(), ctxWith(subs)))); } ? // 3) 匯總把子結果交給 LLM 合成最終答案這一步省不掉否則用戶拿到的是碎片 String finalAnswer llm.generate(synthPrompt(goal, subs)); return new OrchestrationResult(finalAnswer, subs); } }坑點Supervisor 串行派發(fā)很容易變成瓶頸。子任務多且獨立時必須并行復用 Day 92 的ParallelToolExecutor思路同時給規(guī)劃步驟加maxSubtasks上限別讓模型拆出 20 個子任務把你拖死。四、Router本質(zhì)是分診 單一專家很多所謂的多智能體其實根本不需要多個 Agent 同時干活——用戶輸入進來先判斷它屬于哪一類退款咨詢 / 技術排障 / 賬單問題然后交給對應的專家一人到底。這就是 Router它的價值在分診不在協(xié)作。// IntentRouter.java —— 路由/選擇器模式JDK 17 // 適用意圖可分類、每類一個專家、單一專家即可閉環(huán) public class IntentRouter { ? private final ChatLanguageModel llm; private final MapCategory, Agent experts; ? public String route(String userInput) { // 1) 分類這一步用便宜的小模型或規(guī)則就能干別浪費主力大模型 Category cat classify(userInput); // 例如規(guī)則匹配關鍵詞 / 輕量分類模型 Agent expert experts.get(cat); if (expert null) expert experts.get(Category.FALLBACK); ? // 2) 單一專家處理到底Router 模式不做多步拆解一人閉環(huán) return expert.execute(userInput, Map.of()); } ? // 進階專家處理完若發(fā)現(xiàn)這其實該轉給另一個專家可再調(diào)用 router 做二級路由 // 這種 multi-hop 仍是一條線不是并行協(xié)作延遲可控 }Router 最大的誤區(qū)是把它當 Supervisor 用——它不負責拆解和匯總硬塞復雜任務進去專家一個人扛不住也沒有第二個人幫它。五、Swarm邊界模糊、需要動態(tài)交接的探索型任務有些任務你根本不知道該走哪條線比如處理這個客戶投訴可能要先查訂單、再查物流、再查賠付規(guī)則每一步都可能冒出新的分支。給這類任務硬定一個 Supervisor 流程反而束手束腳。Swarm蜂群的思路是Agent 之間用 handoff移交互相把活甩出去共享一塊黑板記狀態(tài)誰接得住誰上。// AgentSwarm.java —— 去中心化協(xié)作JDK 17 // 適用任務邊界模糊、需按需動態(tài)交接、允許探索式多跳 public class AgentSwarm { ? private final MapString, SwarmAgent agents; private final Blackboard board new Blackboard(); // 共享上下文所有 agent 可見 ? public String run(String goal, int maxTurns) { String current pickEntry(goal); // 選入口 agent String msg goal; for (int i 0; i maxTurns; i) { SwarmAgent a agents.get(current); // agent 處理當前消息并返回下一步交給誰nextnull 表示任務結束 Handoff h a.act(msg, board); board.append(a.name(), h.output()); // 寫黑板保證上下文不丟 if (h.next() null) return h.output(); // 收斂信號沒有后繼 結束 current h.next(); // 動態(tài)移交而非中心調(diào)度 msg h.output(); } // 沒有 maxTurns 兜底Swarm 可能兩個 agent 互相 handoff 到天荒地老、Token 燒光 throw new RuntimeException(Swarm 超過最大輪次疑似陷入循環(huán)已強制中止); } }Swarm 最危險的地方是沒有收斂條件就會無限開會。所以maxTurns是必選項而且 Blackboard 必須可觀測、可版本化——否則多個 agent 互相覆蓋狀態(tài)排錯比單體 Agent 難十倍。六、選型判據(jù)一張表說清維度SupervisorRouterSwarm決策方式集中大腦拆解匯總一次性分發(fā)動態(tài)移交最適合可拆解需匯總分診單一專家閉環(huán)邊界模糊、探索式延遲中取決于并行度低一條線高多跳累積成本中高多次 LLM 調(diào)用低高易失控調(diào)試難度中低高收斂控制子任務數(shù)上限天然收斂必須 maxTurns一句話選型任務能拆且要匯總 → Supervisor本質(zhì)是分類分發(fā) → Router不知道流程、需要靈活探索 → Swarm。什么場景壓根不該用多智能體單步任務一個 Agent 幾個工具就夠硬上 Swarm 純屬燒 Token。延遲敏感多跳推理延遲疊加用戶等到花兒都謝了。沒有評估與可觀測能力多 Agent 的調(diào)試地獄不是開玩笑下一篇 Day 94 專門講可觀測。團隊連單體 Agent 的 Prompt 都沒調(diào)好——地基沒打就蓋樓必塌。七、三條落地建議先單后多多智能體是最后手段不是默認選項。我團隊的規(guī)定新需求先用一個 Agent 工具把鏈路跑通真遇到上下文爆了、單一職責過載的瓶頸再加 worker。提前上多 Agent八成是在給未來挖坑。任何模式都必須有收斂條件。Supervisor 加maxSubtasksSwarm 加maxTurnsRouter 雖然沒有循環(huán)但也要有兜底專家。沒有收斂條件的多智能體不是系統(tǒng)是碎鈔機。共享狀態(tài)Blackboard / 上下文要可觀測、可回放。多 Agent 出問題第一現(xiàn)場永遠是某個 agent 把上下文改壞了。把這層做成可追蹤的結構誰在什么輪次寫了什么等 Day 94 接上 OpenTelemetry你才排得動錯。多智能體不是人多力量大而是分工明確才不添亂沒有邊界和收斂條件的協(xié)作只是把一個人的糊涂攤成了一群人的混亂。下篇Day 94我們接著 Agent 工程化往下走聊Agent 可觀測性用 OpenTelemetry 記錄大模型調(diào)用鏈——多智能體一旦跑起來你最缺的就是它到底在每一步干了啥的透視能力下一篇見。