读完这篇你会知道

一、为什么一个 Agent 不够

使用者痛点：在实际业务中，单个大模型往往因为上下文膨胀、角色冲突和 Token 成本高昂而导致响应慢、答案模糊。

单 Agent 处理任何问题有一个根本限制：上下文会越来越长。

当你要求同一个 Agent 同时搜索资料、写代码、做数学计算时历史消息越积越多。模型要在所有历史里找线索，注意力被稀释。而且，同一个程序 Prompt 很难同时把三个角色都交代清楚——"你是搜索员。也是程序员，也是数学家"——通常代表着什么都不精。

多 Agent 的主要价值就在这里：每个 Agent 只看自己需要的上下文，专注自己的职责。

二、方案一：把 Agent 包装成工具

Eino 源码注释里明确写着：

// NewAgentTool creates a tool that wraps an agent for invocation.

使用者痛点：业务方常常希望“调用专家”却不想让整个程序因专家的内部细节而膨胀，这正是该方案解决的关键。

用法：把子 Agent 包装成工具，父 Agent 通过普通工具调用来“雇用”它。话说回来，这是 ADK 官方唯一推荐的 Multi‑Agent 模式。

// 创建子 Agent
researchAgent,_ := adk.NewChatModelAgent(ctx,&adk.ChatModelAgentConfig{
说到Name，"research_agent",Description: " agent responsible to search internet for info",Instruction: "You are a research agent...",Model: m,ToolsConfig: adk.ToolsConfig{...},})
// 把子 Agent 变成一个工具
researchTool := adk.NewAgentTool
// 父 Agent 把这个“工具”加到自己的工具列表
parentAgent。_ := adk.NewChatModelAgent(ctx,&adk.ChatModelAgentConfig{
Name的观点是，"project_manager",Model: m,ToolsConfig: adk.ToolsConfig{
ToolsNodeConfig: compose.ToolsNodeConfig{
Tools的观点是，tool.BaseTool{researchTool,codeTool,reviewTool},},},})

从外部看，父 Agent 仍然是正常的 ReAct 循环，只是“工具”恰好是另一个 Agent。父 Agent 不关心子 Agent 内部怎么工作——它只是调用了名为 research_agent 的工具，传入 {"request":"find US GDP"} 并等待返回结果。

再看关键特性，动作边界隔离

User Pain Point：A agent 内部出现异常退出时不应导致整条业务流程崩溃。老实说，ADK 正好提供了隔离机制。

子 Agent 内部可能触发 Exit、Transfer、BreakLoop 等动作，但agent_tool.go:-)：

// Action Scoping:
// - Interrupted: Propagated via CompositeInterrupt
// - Exit。TransferToAgent,BreakLoop: Ignored outside agent tool

白话：子 Agent 想“结束任务”，对它自己来说任务确实结束了但父 Agent 只看到“这个工具调用完成了返回了结果”。 子 Agent 不能意外终止父 Agent 的执行流。说起来，唯一例外是 Interrupted。它会通过 CompositeInterrupt 传递出去，让整个程序都知道需要暂停等待使用者。

Supervisor 预制模式

// eino-examples/adk/multiagent/supervisor/agent.go supervisorAgent,err := supervisor.New(ctx,&supervisor.Config{ Supervisor: sv。// 主控 Agent SubAgents: adk.Agent{searchAgent,mathAgent},// 子 Agent 列表 })

supervisor.New 自动把每个子 Agent 包装成 AgentTool 并注入到主控 Agent 的工具列表里。你只需定义主控 Agent 的 Instruction，其余工具调用由 ReAct 循环自动处理。按理说，

三、方案二：LLM 驱动的 Agent 切换

This mechanism lets LLM itself decide which sub‑agent should handle request.

// eino-examples/adk/intro/transfer/transfer.go
a。err := adk.SetSubAgents(ctx,routerAgent,adk.Agent{chatAgent,wearAgent})

User Pain Point：KPI 监控发现，这种全上下文共享方式会导致 Token 浪费和误判率上升，却没有明显提高准确度。

• 说到P1，把子 Agent 名字和描述注入 Router Agent 程序 Prompt；
• 说到P2，给 Router Agent 加内置工具 toagent （参数：)。
\

执行时Router Agent 根据使用者提问交给哪个子 Agent，接下来调用 toagent ——相当于给自己的接下来指路。

使用者："北京今天天气？"
RouterAgent → 判断：天气相关 → 调用 transfer_to_agent
WearAtom → 调用 get_wear → 返回结果

Eino 官方在源码里明确标注:

// NOT RECOMMENDED:
// Full context sharing 娱乐ween agents has not proven to be more effective empirically.
// Consider using ChatModelAgent with AgentTool or DeepAgent instead.

User Pain Point：The “full context sharing” makes downstream agent process irrelevant history。inflating token consumption and potentially confusing its reasoning.

上下文隔离机制

The framework creates an when performing a Transfer:

ID isolatedSession := &runSession{
Values的观点是，parentSession.Values,valuesMtx : parentSession.valuesMtx,// Events 不继承
}
The child agent gets an independent event history but shares session’s key‑value store . This allows passing a small amount of structured state while keeping most of conversation history isolated.

四、方案三：确定性移交 

User Pain Point : 在固定审批流或报告流程中，有时业务方希望“一步完成后强制转交”，但如果仍使用全上下文共享，会导致一样的问题。

// Execute agentA,n deterministically hand over to agentB
wrappedA := adk.AgentWithDeterministicTransferTo(ctx,&adk.DeterministicTransferConfig{
Agency : agentA。ToAgentsNames : string{"agentB"},})
After `agentA` finishes its logic framework automatically appends two messages and triggers `TransferTo-Agent`.