多智能体协作：多个AI分工完成复杂任务

读完这篇你会知道

先说说几个核心判断。单个Agent搭配工具，理论上确实能解决不少问题。但到了实际应用场景中，你会发现两个无法回避的瓶颈。

第一个瓶颈是专业度。如果你想让一个Agent既会检索、又会计算、还要能审查代码，那你必须给它编写一份超长的Prompt。Prompt越长，逻辑越容易混乱，最终效果反而更差。相反，把职责拆分开来，让每个Agent只专注于一个领域，效果会明显提升。

第二个瓶颈是并行处理能力。单Agent只能串行执行任务，五个任务就得逐个完成。而多Agent可以并发运行，总耗时大幅缩短。

幸运的是，Eino框架提供了两种官方推荐的多Agent模式，此外还有一种不推荐但值得了解的模式。我们逐一来深入解析。

一、Host-Worker：任务分发模式

源代码位于 eino/flow/agent/multiagent/host/。

整体架构

该模式的核心是：一个Host Agent负责决策，它掌握着所有Specialist的“工具描述”。当用户提出问题时，Host通过ToolCall选择一个或多个Specialist，然后这些Specialist并发执行任务。如果选择了多个Specialist，最后还有一个Summarizer来汇总结果。

Host并非普通的ChatModel，而是ToolCallingChatModel——能够输出结构化的ToolCall，告诉系统“去找哪个Specialist、传递什么参数”。每个Specialist的名字和描述被封装成一个“工具”注册到Host上，Host根据用户问题决定调用哪个。

核心配置

源码中，Host、Specialist和Summarizer的结构清晰可见：

Host是决策者，SystemPrompt可以设置为“你是一个任务分发助手，根据用户需求选择合适的专家”。Specialist是执行者，每个都有独立的Name和IntendedUse，这两个字段决定了Host如何描述它。Summarizer是可选的汇总者，用于综合多位专家的回答。

实际使用

在实战中，配置起来非常直接。例如，你可以将Host定义为“项目经理”，再注册两个Specialist：一个“researcher”负责资料检索，一个“coder”负责编写代码。最后添加一个Summarizer来综合输出。

单个vs多个Specialist

这里有一个关键点：如果Host只选了一个Specialist，则直接返回结果，不经过Summarizer。如果选择了多个，Specialist并发执行，结果才送入Summarizer进行汇总。这个逻辑非常合理，没必要为单一结果浪费一次汇总调用。

HandOff事件监控

每当Host把任务转交给Specialist，会触发一个HandOff事件。你可以通过Callback监听，追踪任务转给了哪个Specialist、传递了什么参数。这在调试和监控时非常实用。

二、Plan-Execute-Replan：规划循环模式

源代码位于 eino/adk/prebuilt/planexecute/plan_execute.go。

这种模式适合步骤不确定的复杂任务：你不知道需要多少步，每步成功后才能知道下一步怎么走，中途可能需要调整计划。本质上，它是一个循环：Planner制定计划，Executor执行，Replanner评估结果，然后决定是继续还是结束。

三个角色

Planner → 制定计划（步骤列表）
Executor → 执行第一步（使用工具）
Replanner → 查看结果，决定继续执行或宣布完成

三者形成循环：Planner → (Executor → Replanner) × N，直到Replanner宣布完成。

状态通过Session传递

各阶段依靠Session键值对共享状态，没有显式消息总线。Session中存储了用户原始问题、当前计划、本次执行结果以及所有历史执行结果。Planner写入Plan，Executor读取Plan.FirstStep()并执行，然后写入ExecutedStep，Replanner读取所有ExecutedSteps判断是否完成。

Planner：强制使用ToolChoiceForced输出结构化计划

Planner强制LLM调用plan()工具输出结构化步骤，不允许输出普通文本。这样保证了输出的规范性。

Replanner：只有两个选择

Replanner只有两个选项：要么任务未完成，输出新计划继续；要么目标达成，输出最终回复退出循环。这种限制非常巧妙，避免了Replanner偏离方向。

完整示例：旅行规划Agent

以旅行规划为例。Planner输出计划：查询热门景点、查询天气、规划路线、预订酒店。Executor先调用searchTool查询景点，再调用weatherTool查询天气，每步结果都写入Session。Replanner每步都检查进度，更新计划，直到所有步骤完成，最后输出行程。

三、Supervisor：官方不推荐的原因

源代码位于 eino/adk/prebuilt/supervisor/supervisor.go。

Supervisor模式的做法是：把整段对话上下文传给Sub-Agent，Sub-Agent执行后再把全部上下文还给Supervisor，如此循环往复。

问题出在哪里？全上下文传递经过实验并没有带来更好的效果，反而让Context越来越长，每次调用成本越来越高。Eino代码注释中明确标注了 ⚠️ Not Recommended。

推荐的替代方案是AgentTool：把Sub-Agent包装成工具，按需调用，不共享全上下文。Parent Agent通过ToolCall调用Sub-Agent，和调用普通工具一样。这样既轻量又高效。

四、Agent之间靠什么通信

无论哪种模式，Agent之间传递的都是 schema.Message 列表。Host-Worker依靠ToolCall路由，Plan-Execute-Replan依靠Session键值对。

核心是Message结构体，它包含Role、Content、ToolCalls等字段。ToolCall中的Function.Name用于路由到对应的Specialist，开发者不需要手动编写路由逻辑，框架帮你处理了。

五、任务分配的三种策略

总结一下，任务分配有三种策略：

小结

最后，如何选择？

记住一个原则：多Agent并非越复杂越好。能用一个Agent加工具解决的，就不要上多Agent。如果确实需要，优先选择Host-Worker或Plan-Execute-Replan，不要默认选Supervisor。这才是务实的选择。