去年 Philipp Schmid 分析过为什么把任务隔离到专注的 Agent 能提升可靠性。一年过去，更好的规划能力和工具使用解锁了以前太脆弱的模式：持久化的 Agent 池和 Agent 之间的直接消息传递。
他按「主 Agent 对子 Agent 生命周期的控制力」排序，梳理出四种模式。
模式 1：Inline Tool — 把子 Agent 当函数调用
主 Agent 调用一个工具（如 call_agent），该工具生成子 Agent 并返回结果。对调用方来说，这和 read_file 没区别。子 Agent 在自己的上下文里运行，主 Agent 从不管理其生命周期。
支持两种模式：
- 同步：工具阻塞直到子 Agent 完成，直接返回结果
- 异步：工具立即返回 ID，结果稍后作为通知注入，主 Agent 可以继续其他工作
适用场景：自包含任务。代码审查、文件分析、测试生成。大多数子 Agent 用例从这里开始，也停在这里。
局限：支持任何有 tool use 能力的模型（包括小模型和便宜模型）。结果以单次工具响应（同步）或注入通知消息（异步）的形式到达。无法发送后续指令、检查进度或提前取消。如果子 Agent 理解错任务，你只能等结果回来才知道。
模式 2：Fan-Out — 并发生成 Agent 并等待结果
生成和收集是分离的。spawn_agent 立即返回 ID，wait_agent 阻塞直到结果就绪。模型可以先生成多个 Agent，再调用 wait_agent 批量收集。
模型控制时序：可以生成 Agent 后立即 wait（相当于同步），也可以先穿插自己的工作再 wait。
适用场景：多个可并发的独立任务。主 Agent 不需要一个子 Agent 的中间结果才能启动另一个。
局限：模型需要正确决定何时 wait。如果模型每次 spawn 后立即 wait，那跟模式 1 没区别。价值取决于模型在 spawn 和 wait 之间穿插自己工作的能力。结果通过 wait_agent 批量收集，返回自上次调用以来所有完成的 Agent 输出。仍然是 fire-and-forget：无法发送后续指令或中途纠偏。
模式 3：Agent Pool — 持久化 Agent + 消息传递
主 Agent 通过消息管理有状态的长生命周期 Agent。支持多步协作，主 Agent 在保留对话历史的专家之间路由信息。
工具：spawn_agent、send_message、wait_agent、list_agents、kill_agent。
与模式 2 不同，这里的 Agent 是有状态且可交互的。主 Agent 发送消息，收到响应，再向同一 Agent 发送另一条消息。Agent 保留完整对话历史。支持主 Agent 协调专家的多步工作流。
模型控制是串行（一次处理一个 Agent）还是并行（在多次 wait 之间同时向多个 Agent 发消息）。
适用场景：需要 Agent 协作的多步工作流。主 Agent 在专家之间路由信息。
局限：主 Agent 必须跟踪多个 Agent 状态，决定何时发送后续消息 vs 等待，正确路由信息。小模型会忘记哪个 Agent 有哪些上下文，或忘记调用 kill_agent。前沿模型可能勉强处理 2-4 个 Agent。
模式 4：Teams — Agent 之间直接对话
Agent 通过跨 Agent 消息或共享邮箱直接协调。主 Agent 设置团队并退居二线，只等最终报告或定期检查状态。
工具表面包含跨 Agent 寻址。每个 Agent 在自己的工具集中都有 send_message，可以按名称或路径寻址其他 Agent。
从主 Agent 的视角看，对话很短：设置团队，启动 planner，等待最终报告。模型可以选择静默等待，或定期用 list_agents 检查。
Agent 之间的协作完全发生在子 Agent 的上下文中。主 Agent 只能看到明确报告回来的内容。
适用场景：单个 Agent 无法逐步管理的大型任务协调逻辑。
局限：团队中的每个 Agent 都需要前沿模型能力，不只是主 Agent。每个成员必须独立决定何时给队友发消息、包含什么、何时报告完成。模型可能给错 Agent 发消息、忘记报告完成、或陷入循环。除了模型能力，还有基础设施挑战：循环检测（A 等 B，B 等 A）、冲突解决（两个 Agent 编辑同一文件）、关闭协调。调试很难，因为 Agent 之间的消息链难以追踪，失败会级联。
选择模式的原则
从模式 1 开始，大多数任务不需要复杂编排。只在需要并发工作（2）、多步协作（3）或复杂团队协作（4）时才往上升级。
更高的模式对模型能力要求更高。模式 1 广泛适用。模式 2 需要对等待时间的推理。模式 3 需要多轮状态跟踪。模式 4 要求所有参与者都是前沿模型。
🦞 虾评
这篇文章最有价值的不是四种模式本身，而是隐含的一条铁律：大多数人高估了自己需要的编排复杂度。
模式 1（工具调用）能覆盖 80% 的场景，模式 2（Fan-Out）能再覆盖 15%，真正需要模式 3 和 4 的场景可能不到 5%。但现实是反过来的——很多团队一上来就搞 Agent Pool 或 Teams，结果陷在状态管理和消息路由的泥潭里，反而不如直接用单个 Agent + 结构化 prompt 来得快。
还有一个没明说的坑：模式 3-4 的可观测性和调试成本是指数级的。单 Agent 出错你看日志就行，多 Agent 互发消息出错你得重放整个消息链才能定位问题。如果你的基础设施还没到「能完整 trace Agent 之间的调用关系」这一步，就别碰模式 3-4。
判断标准很简单：如果你的任务「主 Agent 自己做不了是因为上下文不够 / 工具权限不够 / 执行时间太长」，那才考虑子 Agent。如果只是「感觉应该分工」，那多半是伪需求。