上篇我们把 Tool Calling 做成了能扛生产的招式——定义规范、校验兜底、并行编排、超时重试幂等四件套单 Agent 调用工具这件事基本稳了。但单个 Agent 再能打遇上先查库、再写报告、还要调外部系统对账这种复合型任务一个人干活会累死、上下文也会爆。这篇就聊怎么组队多智能体协作的三种编排模式到底怎么选。一、多智能体不是灵丹妙药先泼盆冷水我见过太多团队听了几场发布会上来就搞个 Multi-Agent 系统结果三个月后发现自己是在用三个大模型互相甩锅。多智能体引入的是复杂度不是能力——单个强 Agent 加好工具搞不定的多 Agent 大概率也救不了反而多了状态同步、收敛控制、成本爆炸三座大山。所以在看模式之前先记牢一条能一个 Agent 几个工具解决的绝不上多智能体。下面三种模式是确实需要一个团队时的选型菜单。二、三种主流模式长什么样【Supervisor / 编排者-工作者】 Supervisor(大脑:拆解汇总) │ 派发子任务 ├─► WorkerA(查库) ─┐ ├─► WorkerB(计算) ─┤ └─► WorkerC(报告) ─┘ │ 收回结果合成答案 ▼ 最终答案 【Router / 分诊-专家】 用户输入 │ ▼ Router(分类:意图识别) │ 选定单一专家 ▼ Expert(一人到底) ──► 答案 (专家可再二级路由但仍是一条线) 【Swarm / 去中心化蜂群】 AgentA ─handoff─► AgentB ─handoff─► AgentC ▲ │ └────── 共享黑板(Blackboard) ◄──┘ 无固定中心谁接得住谁上动态移交三种模式的本质区别就一句话谁来决定下一步谁干——Supervisor 是集中决策Router 是一次性分发Swarm 是动态移交。三、Supervisor有规划、能汇总时用它当任务能清晰拆成几个子任务、且最终要有人把碎片拼成一个完整答案比如分析这个月的经营数据并出一份周报Supervisor 最顺手。核心是三段规划 → 派发 → 汇总。// SupervisorOrchestrator.java —— 编排者-工作者模式JDK 17 LangChain4j 1.x // 适用任务可拆解、子任务各有专长、需要汇总成统一输出 public class SupervisorOrchestrator { private final ChatLanguageModel llm; // 主力大模型负责规划与汇总 private final MapString, Agent workers; // 按能力名注册的专能 worker public OrchestrationResult run(String goal) { // 1) 规划让 LLM 把目标拆成有序子任务强制输出 JSON结构化是可控的前提 String planJson llm.generate(planPrompt(goal, workers.keySet())); TaskPlan plan JsonUtil.fromJson(planJson, TaskPlan.class); // 2) 派发有依赖的串行、无依赖的可并行并行编排见 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 串行派发很容易变成瓶颈。子任务多且独立时必须并行复用 Day 92 的ParallelToolExecutor思路同时给规划步骤加maxSubtasks上限别让模型拆出 20 个子任务把你拖死。四、Router本质是分诊 单一专家很多所谓的多智能体其实根本不需要多个 Agent 同时干活——用户输入进来先判断它属于哪一类退款咨询 / 技术排障 / 账单问题然后交给对应的专家一人到底。这就是 Router它的价值在分诊不在协作。// IntentRouter.java —— 路由/选择器模式JDK 17 // 适用意图可分类、每类一个专家、单一专家即可闭环 public class IntentRouter { private final ChatLanguageModel llm; private final MapCategory, Agent experts; public String route(String userInput) { // 1) 分类这一步用便宜的小模型或规则就能干别浪费主力大模型 Category cat classify(userInput); // 例如规则匹配关键词 / 轻量分类模型 Agent expert experts.get(cat); if (expert null) expert experts.get(Category.FALLBACK); // 2) 单一专家处理到底Router 模式不做多步拆解一人闭环 return expert.execute(userInput, Map.of()); } // 进阶专家处理完若发现这其实该转给另一个专家可再调用 router 做二级路由 // 这种 multi-hop 仍是一条线不是并行协作延迟可控 }Router 最大的误区是把它当 Supervisor 用——它不负责拆解和汇总硬塞复杂任务进去专家一个人扛不住也没有第二个人帮它。五、Swarm边界模糊、需要动态交接的探索型任务有些任务你根本不知道该走哪条线比如处理这个客户投诉可能要先查订单、再查物流、再查赔付规则每一步都可能冒出新的分支。给这类任务硬定一个 Supervisor 流程反而束手束脚。Swarm蜂群的思路是Agent 之间用 handoff移交互相把活甩出去共享一块黑板记状态谁接得住谁上。// AgentSwarm.java —— 去中心化协作JDK 17 // 适用任务边界模糊、需按需动态交接、允许探索式多跳 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(); // 动态移交而非中心调度 msg h.output(); } // 没有 maxTurns 兜底Swarm 可能两个 agent 互相 handoff 到天荒地老、Token 烧光 throw new RuntimeException(Swarm 超过最大轮次疑似陷入循环已强制中止); } }Swarm 最危险的地方是没有收敛条件就会无限开会。所以maxTurns是必选项而且 Blackboard 必须可观测、可版本化——否则多个 agent 互相覆盖状态排错比单体 Agent 难十倍。六、选型判据一张表说清维度SupervisorRouterSwarm决策方式集中大脑拆解汇总一次性分发动态移交最适合可拆解需汇总分诊单一专家闭环边界模糊、探索式延迟中取决于并行度低一条线高多跳累积成本中高多次 LLM 调用低高易失控调试难度中低高收敛控制子任务数上限天然收敛必须 maxTurns一句话选型任务能拆且要汇总 → Supervisor本质是分类分发 → Router不知道流程、需要灵活探索 → Swarm。什么场景压根不该用多智能体单步任务一个 Agent 几个工具就够硬上 Swarm 纯属烧 Token。延迟敏感多跳推理延迟叠加用户等到花儿都谢了。没有评估与可观测能力多 Agent 的调试地狱不是开玩笑下一篇 Day 94 专门讲可观测。团队连单体 Agent 的 Prompt 都没调好——地基没打就盖楼必塌。七、三条落地建议先单后多多智能体是最后手段不是默认选项。我团队的规定新需求先用一个 Agent 工具把链路跑通真遇到上下文爆了、单一职责过载的瓶颈再加 worker。提前上多 Agent八成是在给未来挖坑。任何模式都必须有收敛条件。Supervisor 加maxSubtasksSwarm 加maxTurnsRouter 虽然没有循环但也要有兜底专家。没有收敛条件的多智能体不是系统是碎钞机。共享状态Blackboard / 上下文要可观测、可回放。多 Agent 出问题第一现场永远是某个 agent 把上下文改坏了。把这层做成可追踪的结构谁在什么轮次写了什么等 Day 94 接上 OpenTelemetry你才排得动错。多智能体不是人多力量大而是分工明确才不添乱没有边界和收敛条件的协作只是把一个人的糊涂摊成了一群人的混乱。下篇Day 94我们接着 Agent 工程化往下走聊Agent 可观测性用 OpenTelemetry 记录大模型调用链——多智能体一旦跑起来你最缺的就是它到底在每一步干了啥的透视能力下一篇见。 Day93-多智能体协作：Supervisor-Router-Swarm 编排模式选型
上篇我们把 Tool Calling 做成了能扛生产的招式——定义规范、校验兜底、并行编排、超时重试幂等四件套单 Agent 调用工具这件事基本稳了。但单个 Agent 再能打遇上先查库、再写报告、还要调外部系统对账这种复合型任务一个人干活会累死、上下文也会爆。这篇就聊怎么组队多智能体协作的三种编排模式到底怎么选。一、多智能体不是灵丹妙药先泼盆冷水我见过太多团队听了几场发布会上来就搞个 Multi-Agent 系统结果三个月后发现自己是在用三个大模型互相甩锅。多智能体引入的是复杂度不是能力——单个强 Agent 加好工具搞不定的多 Agent 大概率也救不了反而多了状态同步、收敛控制、成本爆炸三座大山。所以在看模式之前先记牢一条能一个 Agent 几个工具解决的绝不上多智能体。下面三种模式是确实需要一个团队时的选型菜单。二、三种主流模式长什么样【Supervisor / 编排者-工作者】 Supervisor(大脑:拆解汇总) │ 派发子任务 ├─► WorkerA(查库) ─┐ ├─► WorkerB(计算) ─┤ └─► WorkerC(报告) ─┘ │ 收回结果合成答案 ▼ 最终答案 【Router / 分诊-专家】 用户输入 │ ▼ Router(分类:意图识别) │ 选定单一专家 ▼ Expert(一人到底) ──► 答案 (专家可再二级路由但仍是一条线) 【Swarm / 去中心化蜂群】 AgentA ─handoff─► AgentB ─handoff─► AgentC ▲ │ └────── 共享黑板(Blackboard) ◄──┘ 无固定中心谁接得住谁上动态移交三种模式的本质区别就一句话谁来决定下一步谁干——Supervisor 是集中决策Router 是一次性分发Swarm 是动态移交。三、Supervisor有规划、能汇总时用它当任务能清晰拆成几个子任务、且最终要有人把碎片拼成一个完整答案比如分析这个月的经营数据并出一份周报Supervisor 最顺手。核心是三段规划 → 派发 → 汇总。// SupervisorOrchestrator.java —— 编排者-工作者模式JDK 17 LangChain4j 1.x // 适用任务可拆解、子任务各有专长、需要汇总成统一输出 public class SupervisorOrchestrator { private final ChatLanguageModel llm; // 主力大模型负责规划与汇总 private final MapString, Agent workers; // 按能力名注册的专能 worker public OrchestrationResult run(String goal) { // 1) 规划让 LLM 把目标拆成有序子任务强制输出 JSON结构化是可控的前提 String planJson llm.generate(planPrompt(goal, workers.keySet())); TaskPlan plan JsonUtil.fromJson(planJson, TaskPlan.class); // 2) 派发有依赖的串行、无依赖的可并行并行编排见 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 串行派发很容易变成瓶颈。子任务多且独立时必须并行复用 Day 92 的ParallelToolExecutor思路同时给规划步骤加maxSubtasks上限别让模型拆出 20 个子任务把你拖死。四、Router本质是分诊 单一专家很多所谓的多智能体其实根本不需要多个 Agent 同时干活——用户输入进来先判断它属于哪一类退款咨询 / 技术排障 / 账单问题然后交给对应的专家一人到底。这就是 Router它的价值在分诊不在协作。// IntentRouter.java —— 路由/选择器模式JDK 17 // 适用意图可分类、每类一个专家、单一专家即可闭环 public class IntentRouter { private final ChatLanguageModel llm; private final MapCategory, Agent experts; public String route(String userInput) { // 1) 分类这一步用便宜的小模型或规则就能干别浪费主力大模型 Category cat classify(userInput); // 例如规则匹配关键词 / 轻量分类模型 Agent expert experts.get(cat); if (expert null) expert experts.get(Category.FALLBACK); // 2) 单一专家处理到底Router 模式不做多步拆解一人闭环 return expert.execute(userInput, Map.of()); } // 进阶专家处理完若发现这其实该转给另一个专家可再调用 router 做二级路由 // 这种 multi-hop 仍是一条线不是并行协作延迟可控 }Router 最大的误区是把它当 Supervisor 用——它不负责拆解和汇总硬塞复杂任务进去专家一个人扛不住也没有第二个人帮它。五、Swarm边界模糊、需要动态交接的探索型任务有些任务你根本不知道该走哪条线比如处理这个客户投诉可能要先查订单、再查物流、再查赔付规则每一步都可能冒出新的分支。给这类任务硬定一个 Supervisor 流程反而束手束脚。Swarm蜂群的思路是Agent 之间用 handoff移交互相把活甩出去共享一块黑板记状态谁接得住谁上。// AgentSwarm.java —— 去中心化协作JDK 17 // 适用任务边界模糊、需按需动态交接、允许探索式多跳 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(); // 动态移交而非中心调度 msg h.output(); } // 没有 maxTurns 兜底Swarm 可能两个 agent 互相 handoff 到天荒地老、Token 烧光 throw new RuntimeException(Swarm 超过最大轮次疑似陷入循环已强制中止); } }Swarm 最危险的地方是没有收敛条件就会无限开会。所以maxTurns是必选项而且 Blackboard 必须可观测、可版本化——否则多个 agent 互相覆盖状态排错比单体 Agent 难十倍。六、选型判据一张表说清维度SupervisorRouterSwarm决策方式集中大脑拆解汇总一次性分发动态移交最适合可拆解需汇总分诊单一专家闭环边界模糊、探索式延迟中取决于并行度低一条线高多跳累积成本中高多次 LLM 调用低高易失控调试难度中低高收敛控制子任务数上限天然收敛必须 maxTurns一句话选型任务能拆且要汇总 → Supervisor本质是分类分发 → Router不知道流程、需要灵活探索 → Swarm。什么场景压根不该用多智能体单步任务一个 Agent 几个工具就够硬上 Swarm 纯属烧 Token。延迟敏感多跳推理延迟叠加用户等到花儿都谢了。没有评估与可观测能力多 Agent 的调试地狱不是开玩笑下一篇 Day 94 专门讲可观测。团队连单体 Agent 的 Prompt 都没调好——地基没打就盖楼必塌。七、三条落地建议先单后多多智能体是最后手段不是默认选项。我团队的规定新需求先用一个 Agent 工具把链路跑通真遇到上下文爆了、单一职责过载的瓶颈再加 worker。提前上多 Agent八成是在给未来挖坑。任何模式都必须有收敛条件。Supervisor 加maxSubtasksSwarm 加maxTurnsRouter 虽然没有循环但也要有兜底专家。没有收敛条件的多智能体不是系统是碎钞机。共享状态Blackboard / 上下文要可观测、可回放。多 Agent 出问题第一现场永远是某个 agent 把上下文改坏了。把这层做成可追踪的结构谁在什么轮次写了什么等 Day 94 接上 OpenTelemetry你才排得动错。多智能体不是人多力量大而是分工明确才不添乱没有边界和收敛条件的协作只是把一个人的糊涂摊成了一群人的混乱。下篇Day 94我们接着 Agent 工程化往下走聊Agent 可观测性用 OpenTelemetry 记录大模型调用链——多智能体一旦跑起来你最缺的就是它到底在每一步干了啥的透视能力下一篇见。