@_philschmid Agents 如何管理其他 Agents：2026 年的四种 Subagent 模式
@_philschmid How Agents Manage Other Agents: Four Subagents Patterns in 2026
Phil Schmid 总结四种 subagent patterns：Inline Tool、Fan-Out、Agent Pool、Teams，按主 agent 对生命周期控制递增，分别涉及 call_agent、spawn/wait、messaging、cross-agent communication，并说明适用场景、限制与模型能力要求。
去年我写过，为什么把任务隔离到专注的 agent 中可以提升可靠性。此后，更好的规划和 tool use 解锁了一些此前过于脆弱的模式：持久化 worker pools，以及直接的 inter-agent messaging。
下面是四种模式，按主 agent 对 subagent 生命周期的控制程度排序。
1. Inline Tool：把 subagent 当作 Function Call
主 agent 调用一个 tool（例如 call_agent），该 tool 启动一个 subagent 并返回结果。对调用方来说，它就像 read_file 一样只是另一个 tool。subagent 在自己的 context 中运行，主 agent 从不管理它的生命周期。
这个模式支持两种方式：
- Sync：tool 会阻塞，直到 subagent 完成，然后直接返回结果。
- Async：tool 立即返回一个 ID。结果稍后以 notification 的形式注入，让主 agent 可以继续工作。 在 sync 中，tool response 包含结果。在 async 中，tool response 包含一个 ID，结果稍后以注入的 user message 形式到达。
适用场景：自包含工作。研究查询、code review、文件分析、test generation。大多数 subagent 用例从这里开始，也停留在这里。
限制：适用于任何支持 tool use 的模型，包括更小、更便宜的模型。结果会以单个 tool response（sync）或注入的 notification message（async）到达。无法发送后续指令、检查进度或提前取消。如果 subagent 误解了任务，你只能在结果返回时才知道。
2. Fan-Out：启动 Agents 并等待结果
启动和收集是分开的。spawn_agent 会立即返回一个 ID，wait_agent 会阻塞，直到结果就绪。这让模型可以交错处理任务，或在等待之前启动多个 agents。
两个 tools：spawn_agent 分发工作并立即返回一个 ID。wait_agent 阻塞，直到一个或多个 agents 完成。模型控制顺序。它可以启动 agents 后立刻调用 wait_agent（实际上就是同步），也可以先交错执行自己的工作：
模型决定如何交错。它可以启动多个 agents，执行其他 tool calls，然后把 wait_agent 当作全局 mailbox 来收集所有可用结果。
适用场景：多个可以并发运行的独立任务。主 agent 不需要一个 subagent 的中间结果来启动另一个。
限制：模型需要正确决定何时等待。一个在每次 spawn 后都立即调用 wait_agent 的模型，相比 Pattern 1 没有收益。价值取决于模型在 spawn 和 wait 之间交错执行自身工作的能力。结果通过 wait_agent 批量收集，wait_agent 返回自上次调用以来所有已完成的 agent 输出。它仍然是 fire-and-forget：无法向 subagents 发送后续指令，也无法在任务中途纠偏。
3. Agent Pool：带 Messaging 的持久化 Agents
主 agent 通过 messaging 管理长期存在、有状态的 subagents。这支持多步骤协调：主 agent 在保留 conversation history 的 specialists 之间路由信息。
Tools：spawn_agent、send_message、wait_agent、list_agents、kill_agent。
不同于 Pattern 2，这里的 agents 是有状态且可交互的。主 agent 发送一条 message，得到一个 response，然后向同一个 agent 发送另一条 message。该 agent 会保留完整的 conversation history。这支持多步骤 workflow，其中主 agent 在 specialists 之间进行协调。
模型控制是一次只与一个 agent 工作（sequential），还是在等待之间向多个 agents 发送 messages（parallel）。它可以同时发给 researcher 和 writer，也可以先等待 researcher：
模型控制 orchestration flow。结果通过 wait_agent 按 message 增量到达，让主 agent 可以基于中间输出调整指令。
适用场景：agents 需要协作的多步骤 workflow。主 agent 在 specialists 之间路由信息。
限制：主 agent 必须跟踪多个 agent states，决定何时发送 follow-up、何时等待，并正确路由信息。较小的模型会搞不清哪个 agent 拥有哪些 context，或者完成后忘记调用 kill_agent。frontier models 也许能勉强处理 2-4 个 agents。
4. Teams：Agents 彼此对话
Agents 使用 cross-agent messaging 或 shared mailboxes 直接协调。主 agent 组建 team 后退到后台，只等待最终报告，或定期检查状态。
tool surface 包含 cross-agent addressing。每个 agent 在自己的 tool set 中都有 send_message，并且可以按名称或路径寻址其他 agents。
从主 agent 的视角看，对话很短。它组建 team，启动 planner，然后等待最终报告。模型可以选择静默等待，也可以使用 list_agents 定期 check in：
Inter-agent collaboration 完全发生在 subagents 的 contexts 内。主 agent 只看到明确回报给它的内容。寻址可以使用 hierarchical paths、mailboxes 或 IPC。
适用场景：大型任务，其中协调逻辑已经超出单个 agent 逐步管理的能力。
限制：team 中每个 agent 都需要 frontier-class model 能力，而不只是主 agent。每个 team member 都必须独立决定何时给队友发送 message、包含什么内容，以及何时回报。模型可能会给错误的 agent 发 message、忘记报告完成，或陷入循环。除了模型能力，还有 infrastructure 挑战：cycle detection（A 等 B，B 等 A）、conflict resolution（两个 agents 编辑同一个文件）以及 shutdown coordination。调试很难，因为 agents 之间的 message chains 难以追踪，而且失败会级联。
选择一种 Pattern
Pattern Tools Main Agent Role Agent Lifetime Inline Tool call_agent Caller Single task Fan-Out spawn_agent, wait_agent Dispatcher Single task Agent Pool spawn, send, wait, list, kill Coordinator Multi-turn Teams All above + cross-agent send_message Supervisor Persistent
从 Pattern 1 开始；大多数任务不需要复杂 orchestration。只有在需要 parallel work（2）、multi-step collaboration（3）或 complex team coordination（4）时，再向上移动。
更高层级的 patterns 需要更强的模型。Pattern 1 适用范围很广。Pattern 2 需要对等待时间进行推理。Pattern 3 需要 multi-turn state tracking。Pattern 4 要求所有参与者都是 frontier models。