Manager (agents as tools)
一种多 agent 编排模式，由 manager 保持会话总控，把 specialist agents 当作工具调用。
#tech / ai
#resource / manager-agents-as-tools
#type / concept
#status / growing
[!info] related notes
- 所属 MOC: AI MOC
- 前置概念: orchestration, Agent
- 并列概念: Handoffs, Skills
- 易混淆概念: Function Calling, a2a
- 关系笔记: ai-ability-and-protocol, 多 Agent 编排模式
Manager (agents as tools)
一句话定义
Manager (agents as tools) 是一种多 agent orchestration 模式：由一个 manager 持续掌控会话，把 specialist agents 当作工具调用，再统一整合最终结果。
它的基本结构
用户 -> manager
-> 调 research agent
-> 调 math agent
-> 调 writer agent
-> manager 汇总最终答案这里 specialist 的角色更像幕后专家，而不是直接接管用户对话的人。
什么时候适合用
适合这些情况：
- 你希望始终由一个 agent 对外输出最终答案
- 需要统一整合多个 specialist 的结果
- 想把共享 guardrails 和最终责任集中在 manager 上
- specialist 只是处理受限子任务，不应该接管用户会话
它解决什么问题
如果没有 manager，总流程容易出现：
- 谁负责最后整合结果不清楚
- specialist 输出风格不一致
- guardrails 和审计边界分散
- 用户面对多个 agent，交互成本变高
Manager 模式的价值，就是把这些总控职责收敛到一个入口。
它和 Handoffs 的区别
Manager 模式
- manager 始终保持对话控制权
- specialist 在后台做子任务
- 最终答案通常由 manager 统一输出
Handoffs
- 会把 active agent 切给 specialist
- specialist 直接接管当前阶段的会话
所以 manager 更像“统一总控”，handoff 更像“流程换人”。
它和普通工具调用的关系
从抽象层看，specialist agent 在这里确实很像一种“高阶工具”：
- 普通工具处理确定性动作
- specialist agent 处理更复杂的认知子任务
但它仍然属于 orchestration 范畴，因为你要考虑的不只是调用本身，还包括：
- 哪些 specialist 可用
- 谁负责路由
- 结果怎么整合
- guardrails 挂在哪
常见风险
- manager 太弱，无法有效整合 specialist 输出
- specialist 边界不清，导致重复工作
- manager 把一切都丢给 specialists，自己失去总控意义
- 上下文传得太多，导致成本上升和噪音增加
最短记忆方式
Manager 模式就是一个总控 agent 把多个 specialist 当作工具调度，最后自己对外给出统一结果。