读完这篇你会知道

一、为什么要多个 Agent

痛点：单个 Agent 想兼顾检索、计算、代码审查等多种能力时Prompt 越写越长、越混乱，导致模型输出质量下降。

问题 ：专业度。让一个 Agent 既懂检索、又懂计算、又懂代码审查。prompt 会越写越长，越长越混乱，效果越来越差。把职责拆开，每个 Agent 只做一件事，效果好得多。

痛点：业务需求往往是并行的。但单 Agent 只能串行处理，导致整体响应时间不可接受。

问题 ：并行。单 Agent 串行执行，个任务得一个个来。多 Agent 可以并发跑，总时间缩短。不过，

Eino 提供了两种官方推荐的 Multi-Agent 模式。加一种不推荐但值得了解的模式。

二、Host-Worker：派活模式

源码：eino/flow/agent/multiagent/host/

整体结构

使用者问题
↓
↓ 通过 ToolCall 选择一个或多个 Specialist
↓
↓最终回复

痛点：If you try to let a single LLM handle all sub‑tasks。you quickly hit token limits and context dilution. Host‑Worker 把“谁干活”交给 LLM 决策，把实际执行交给专职 Specialist，从而保持每个模型的上下文简洁。

Host 不是普通 ChatModel。它是 ToolCallingChatModel——能输出结构化的 ToolCall，告诉程序“去找哪个 Specialist、传什么参数”。每个 Specialist 的名字和描述被包装成一个“工具”注册到 Host 上，Host 看完使用者问题后决定调哪个。

主要配置

// 源码：eino/flow/agent/multiagent/host/types.go
// Host：决策者
type Host struct {
ToolCallingModel model.ToolCallingChatModel
SystemPrompt string // "你是一个任务分发助手，根据使用者需求选择合适的专家"
}
// Specialist：执行者
type Specialist struct {
AgentMeta // Name + IntendedUse
ChatModel model.BaseChatModel
SystemPrompt string // "你是一个数学计算专家，只做数学题"
Invokable compose.Invoke*schema.Message。*schema.Message,agent.AgentOption]
}
// Summarizer：汇总者
type Summarizer struct {
ChatModel model.BaseChatModel
SystemPrompt string // "综合多位专家的回答，给出统一答复"
}

用起来

// 参考：eino-examples/adk/multiagent/integration-project-manager
hostCfg := &host.Config{
至于Host，host.Host{
ToolCallingModel: myLLM,SystemPrompt: "你是项目经理，根据任务类型分配给合适的专家。",},Specialists: host.Specialist{
{
AgentMeta: host.AgentMeta{
Name这方面，"researcher"。IntendedUse: "负责资料检索和调研",},ChatModel: researchLLM,SystemPrompt: "你是研究员，擅长搜索和分析信息。",Invokable: researchAgent.Invoke,},{
AgentMeta: host.AgentMeta{
说到Name，"coder"。IntendedUse: "负责编写和调试代码",},ChatModel: codingLLM,SystemPrompt: "你是工程师，只负责写代码，不做其他事。",Invokable: coderAgent.Invoke,},},Summarizer: &host.Summarizer{
ChatModel: summaryLLM。SystemPrompt: "综合研究员和工程师的输出，给出完整报告。",},}
multiAgent,_ := host.NewMultiAgent
result。_ := multiAgent.Generate

单个 vs 多个 Specialist

• 单一 Specialist：Host 选了一个 → 直接返回该 Specialist 的结果。
• 多位 Specialist：Host 同时选中多位 → 并发执行 → 所有结果送入 Summarizer 汇总后返回。

HandOff 事件监控

If you need visibility on task delegation，Host 每次把任务转给 Specialist 时会触发 HandOff 事件。可通过 Callback 捕获：

// 源码：eino/flow/agent/multiagent/host/callback.go
type HandOffInfo struct {
ToAgentName string // 转给哪个 Specialist
Argument string // 传了什么参数
}
handler := host.NewMultiAgentCallbackHandler context.Context {
log.Printf
return ctx
})

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

源码：EINO/adk/prebuilt/planexecute/plan_execute.go

This pattern fits步骤不确定** 的复杂业务，例如「全链路营销活动策划」或「跨地域物流路线调整」——每一步成功与否都会影响后续计划。

三个角色

→ 制定计划
→ 执行第一步先
→ 看结果，决定继续执行或宣布完成；若需调整，则输出新计划，Planner → × N，直到 Replanner 宣布完成。

状态通过 Session 键值对共享

The pain point of “跨阶段状态丢失” is solved by a simple key‑value store attached to workflow session.

// 源码：eino/adk/prebuilt/planexecute/plan_execute.go
const (
UserInputSessionKey = "UserInput" // 使用者原始问题
PlanSessionKey = "Plan" // 当前计划
ExecutedStepSessionKey = "ExecutedStep" // 本次执行结果
ExecutedStepsSessionKey = "ExecutedSteps" // 所有历史执行结果
)
// Plan 接口
type Plan interface {
FirstStep string // 当前待执行步骤
json.Marshaler
json.Unmarshaler
}
// 默认实现 – 有序步骤列表
type defaultPlan struct {
Steps string `json:"steps"`
}

• P​lanner* 写 *Plan*
• E​xecutor* 从 *Plan.FirstStep* 拿到待办事项并写 *ExecutedStep*
• D​replanner* 阅读所有 *ExecutedSteps* 判断是否完成或生成新 *Plan*

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

// Planner 强制 LLM 调 plan 工具输出结构化步骤，不允许普通文字输出
var PlanToolInfo = schema.ToolInfo{
再看Name，"plan",Desc: "制定按序执行的步骤列表",ParamsOneOf: NewParamsOneOfByParams(map*schema.ParameterInfo{
"steps": {
说到Type。schema.Array,ElemInfo: &schema.ParameterInfo{Type: schema.String},Desc: "按顺序排列的执行步骤",Required: true,},}),}

Replanner：只能做两个选择

// 两种返回：
// 1️⃣ 未完成 → 输出新的 plan
// 2️⃣ 完成 → 调 respond 给使用者最终答案
var RespondToolInfo = schema.ToolInfo{
说到Name，"respond",Desc:"当目标已达成时给出最终回复",ParamsOneOf : NewParamsOneOfByParams(map*schema.ParameterInfo{
"response": {Type:schema.String,Desc:"给使用者的完整答案",Required:true},}),}

完整示例的观点是，旅行规划 Agent

// eino-examples/adk/multiagent/plan-execute-replan/
cfg := &planexecute.Config{
Planner: planexecute.NewPlannerAgent(ctx,&planexecute.PlannerConfig{
ChatModelWithFormattedOutput: llm,}),Executor: planexecute.NewExecutorAgent(ctx,&planexecute.ExecutorConfig{
Model这方面，llm,ToolsConfig: adk.ToolsConfig{
ToolsNodeConfig: compose.ToolsNodeConfig{
Tools : tool.BaseTool{searchTool,wearTool,bookingTool},},},MaxIterations : 10,}),Replanner : planexecute.NewReplannerAgent,MaxIterations : 5,}
agent,_ := planexecute.New
result,_ := agent.Generate
// 执行过程示例：
Planner :
Executor① : 调 searchTool → “故宫、长城…”
Replanner① : 步骤未完 → 更新计划
Executor② : 调 wearTool → “明天晴”
Replanner② : 步骤未完 …ReplannerN : 所有步骤完成 → 调 respond → 输出完整行程方案 ← 循环结束
此模式天然支持 **失败重试** 与 **动态增删步骤**。

四、Supervisor：为什么官方不推荐

源码：EINO/adk/prebuilt/supervisor/supervisor.go

The Supervisor pattern passes **entire conversation context** to each Sub‑Agent. In practice this leads to:

• Pain point of ever‑growing token consumption.
• No measurable quality gain – experiments show flat or even degraded results.
• A clear warning in source code ⚠️ Not Recommended.

The recommended alternative is to wrap Sub‑Agents as ordinary tools and invoke m only when needed.

// 将 Sub‑Agent 包装为工具，仅在需要时调用。不共享全局上下文
agentTool := adk.NewAgentTool
parentCfg := &adk.ChatModelAgentConfig{
Model : llm,ToolsConfig : adk.ToolsConfig{
ToolsNodeConfig : compose.ToolsNodeConfig{
Tools : tool.BaseTool{agentTool,orTool},},},}

五、Agent 之间靠什么通信

No matter which pattern you adopt,data exchanged is always a list of s​chema.Message​s​.. The difference lies in how routing information is encoded:

• Host‑Worker: ToolCall​  —> The Host decides which specialist to call and passes arguments via a structured tool invocation.
• P​lan‑Execute‑Replan: Session​ keys​ — The Planner writes a plan into session;Executor reads it;Replanner updates it.
• beyond se two patterns you can also use plain tool calls .
<\/ul>

// eino/schema/message.go
type Message struct {
Role RoleType // user / assistant / system / tool
Content string
ToolCalls ToolCall // Host→Specialist 指令
ToolCallID string // 专家返回对应 ID
ToolName string // 哪个工具产生结果
}
type ToolCall struct {
ID string
Function struct {
Name string // Specialist 名称
Arguments string // JSON 参数
}
}

The framework automatically routes based on ToolCall.Function.Name,so developers don’t write custom dispatch logic.

六、任务分配三种策略

<\/tbody>

策略	原理	适用场景
LLM 路由	Host LLM 基于 ToolCall 决定派发对象；可处理类型多样且边界模糊的问题。	需要多专家并行处理，如调研+编码+审计。
结构化规划	Planner 拆解为可迭代的步骤；Executor 按步走；Replanner，如旅行策划、供应链调整。
AgentTool 调用	Parent Agent 把子 Agent 包装为普通工具，仅在明确需求时调用；避免全局上下文膨胀，怎么说呢，	子任务边界清晰且调用频率低。例如“生成报表”“调用内部业务服务”。

小结

Host-Worker
适合 → 多专家并行、任务类型多样
关键 → Host 用 ToolCall 路由，Specialist 并发 

Plan-Execute-Replan 适合 → 步骤不确定且可能失败的复杂任务 关键 → Session 跨阶段共享状态；Replanner 决定继续还是结束

Supervisor 问题 → 全上下文膨胀·实验效果不佳 替代 → AgentTool / DeepAgent

<\/pre>

怎么选？

场景痛点	建议模式
需要不同领域专家同时工作 ← 响应时间成为瓶颈 ← 单模型难以兼顾专业度  |  |  |   |	Host‑Worker    |   |   |
业务流程不可预知 ← 每一步成功与否决定后续方法 ← 必须支持动态重规   |	Plan‑Execute‑Replan |
子任务边界明确且调用频率低 ← 希望保持上下文轻量 ← 不想引入额外 Scheduler   |	AgentTool | <\/tbody>

*注意*: Multi‑Agent 并非越复杂越好。如果一个带工具的单一 LLM 能搞定，就不要上 Multi‑Agent；若必须上，多数情况下优先尝试 Host‑Worker 或 Plan‑Execute‑Replan 。切勿默认使用 Supervisor。

---