字节笔记本
2026年10月24日 · 约 9 分钟读完
多 Agent 的拓扑，以及怎么权衡
本文是《从 0 写 Agent》系列第 20 章。这个系列基于开源项目 agents-go（OpenAI Agents SDK 的 Go 移植版），用 Go 从零实现一个生产级 Agent 运行时；本章讲「小结：多 Agent 的拓扑与权衡」。
Part III 六章，我们让 Agent 从"单打独斗"变成了"团队协作"。Handoff 接力、Agent-as-Tool 委托、Hook 监控，多 Agent 的三大支柱。
这一章做个收尾，什么时候该用多 Agent，什么时候单 Agent 就够，以及怎么在 Handoff 和 Agent-as-Tool 之间选。
Part III 回顾：三块拼图
拼图一：Handoff（第15-17章）
Agent 之间的"交接棒"。本质是暴露给模型的工具，调用它就切换 active agent。
HandoffTo便捷构造，transfer_to_xxx命名约定- InputFilter 改写目标 Agent 看到的历史（双 item 列表保证持久化完整）
- NestHandoffHistory 折叠长对话，避免"summary 的 summary"
- handoff 后重置 previousResponseID（过滤历史和服务端历史不一致）
拼图二：Agent-as-Tool（第18章）
把 Agent 当工具用。主 Agent 调用子 Agent，子 Agent 跑完返回结果，控制权归还。
- 子 Agent 只看传入 input（黑盒），不继承对话历史
- 继承 ModelProvider/Tracer（开箱即用），不继承 Usage/ApprovalStore（安全隔离）
- trace 合并到父 workflow（树状 span）
MaxTurns限制嵌套深度
拼图三：Lifecycle Hooks（第19章）
运行时事件钩子。在不改循环代码的前提下，注入监控/日志/审计/自定义行为。
- RunHooks（全局）+ AgentHooks（单 Agent），双发
- 七个回调点：AgentStart/End、LLMStart/End、ToolStart/End、Handoff
- BaseRunHooks 空实现 + CompositeRunHooks 组合
核心决策：单 Agent 还是多 Agent
这是最常被问的问题。先问自己三个问题：
问题一：指令是否臃肿
你的 Agent 指令是不是已经长到"做 A 时这样、做 B 时那样、做 C 时注意……"？
- 是 → 拆成多个 Agent，每个聚焦一个领域
- 否 → 单 Agent 够用
指令臃肿是拆分的第一信号。 模型在长指令里容易"忘了"某些规则，聚焦的短指令效果更好。
问题二：工具是否过多
你的 Agent 是不是挂了 10+ 个工具？
- 是 → 拆分，每个 Agent 只挂自己领域的工具
- 否 → 单 Agent 够用
工具过多，模型的工具选择准确率会下降（schema 占 token + 选择空间大）。每个 Agent 3-5 个工具最理想。
问题三：任务是否跨领域
用户的问题是不是需要完全不同的专业知识（法律 vs 技术 vs 财务）？
- 是 → 拆成专家 Agent，handoff 接力
- 否 → 单 Agent 够用
如果三个问题都"否"，别过度设计，单 Agent 更简单、更快、更省 token。 多 Agent 有协调成本（交接的 token、嵌套的延迟），不是越多越好。
Handoff vs Agent-as-Tool：决策矩阵
确认要多 Agent 后，怎么选模式？
| 你的场景 | 选择 |
|---|---|
| 不同领域专家接力（客服→退款→物流） | Handoff |
| 主 Agent 委托子任务，要结果继续干（查资料、校对） | Agent-as-Tool |
| 一次性转交，不需要回来 | Handoff |
| 反复调用不同子能力 | Agent-as-Tool |
| 子任务需要完整对话上下文 | Handoff（看到历史） |
| 子任务是黑盒，只要结果 | Agent-as-Tool（只看 input） |
| 线性流程（A→B→C） | Handoff |
| 树状调用（A 调 B、C、D） | Agent-as-Tool |
一句话，"转接"用 Handoff，"咨询"用 Agent-as-Tool。
混合模式：真实场景的常见组合
真实系统通常混合用两种模式：
分诊 Agent
├─ Handoff → 退款 Agent
│ ├─ Agent-as-Tool → 查询 Agent（查订单）
│ └─ Agent-as-Tool → 校对 Agent（检查退款金额）
├─ Handoff → 物流 Agent
└─ Handoff → 技术 Agent- 分诊用 Handoff 转给各专家（接力）
- 退款专家用 Agent-as-Tool 调查询和校对（委托）
- 每层都挂 Hook 监控
这种混合是生产级多 Agent 系统的常态。 别强求"全用 Handoff"或"全用 Agent-as-Tool"，按任务性质选。
多 Agent 的成本
别忽视多 Agent 的代价：
| 成本 | 说明 |
|---|---|
| Token | handoff 的历史传输、嵌套的独立上下文，都耗 token |
| 延迟 | 每多一层，多一轮模型调用 |
| 复杂度 | 多 Agent 的调试比单 Agent 难（要追踪控制流） |
| 错误传播 | 子 Agent 错误会影响主 Agent 决策 |
所以，能单 Agent 就别多 Agent。 多 Agent 是"指令/工具太多、任务跨领域"时的解法，不是默认选择。
现在你的 Agent 能做什么
Part I-III 走完，你的 Agent 已经具备：
| 能力 | 来源 |
|---|---|
| ✅ 循环调工具 | Part I |
| ✅ 流式输出 | Part I |
| ✅ 记忆（Session） | Part II |
| ✅ 暂停审批（HITL） | Part II |
| ✅ 安全护栏（Guardrails） | Part II |
| ✅ 多 Agent 协作（Handoff + As-Tool） | Part III |
| ✅ 事件钩子（Hooks） | Part III |
这是一个功能相当完整的 Agent 框架了。 但还缺两块，健壮性（模型挂了怎么办）和可观测性（怎么知道哪一步出错）。这是 Part IV 的内容。
Part IV 预告
Part IV 七章（21-27），主题是"模型工程与可观测性"：
- ModelProvider/Router（21），多模型路由
- Retry（22），指数退避重试
- Fallback（23），模型降级链
- 三装饰器组合（24），可任意嵌套
- Tracing（25-27），从 0 造一套可观测系统
让 Agent 健壮（不怕模型抖动）、可监控（出错能定位）。 这是把 Agent 从"demo"推向"生产"的关键。
阅读建议
如果你急着用多 Agent，Part III 够你搭团队协作了。回去试着把你的单 Agent 拆成 2-3 个，用 Handoff 连起来。
如果你关心健壮性，直接进 Part IV。模型会挂、会超时、会限流，没有 Retry/Fallback，生产环境寸步难行。
如果你关心外部连接，跳到 Part V。MCP、Skills、Sandbox 是让 Agent 真正"接入世界"的生态。
每个 Part 独立可读，按需跳转。
本文是《从 0 写 Agent》系列第 20 章，案例代码基于开源项目 agents-go（OpenAI Agents SDK 的 Go 移植版）。全系列目录见总览。
