主 Agent 管理子 Agent 的四种模式：从函数调用到自治团队，按控制力度分级选型

去年 Philipp Schmid 讨论过为什么把任务隔离进专注的 Agent 能提升可靠性。此后，更强的规划与工具使用能力解锁了此前过于脆弱的模式：持久工作池与代理间直接消息。本文按主 Agent 对子 Agent 生命周期的控制力度排序，讲透四种模式。

模式一：Inline Tool——子代理即函数调用

主 Agent 调用一个工具（如 call_agent）孵化子代理并取回结果。对调用方来说，它就像 read_file 一样只是另一个工具。子代理跑在自己的上下文里，主 Agent 从不管理其生命周期。

以安全审查为例的消息轨迹：用户要求”审查 PR #42 的安全问题”，主 Agent 发起 call_agent 工具调用，参数指定任务”专注 auth 变更”、代理类型 security-reviewer、可用工具 read_file 与 search_code；工具返回”发现 2 个问题：1) /api/users 端点未验证 auth token；2) 登录处理器 session cookie 缺 HttpOnly 标志”；主 Agent 汇总回复。

该模式支持两种形态：同步——工具阻塞到子代理完成，直接返回结果；异步——工具立即返回 ID，结果稍后以通知注入，主 Agent 可继续干活。异步轨迹里，主 Agent 同时发起后台安全审查与读取 CI 日志，先处理 CI 结果，随后收到 agent-x1 完成的通知消息再汇总。同步时工具响应含结果本体；异步时工具响应只有 ID，结果作为注入的 user 消息到达。

适用场景：自包含的工作。研究检索、代码审查、文件分析、测试生成。大多数子代理用例从这起步并停留在这。

局限：支持任何能工具调用的模型，包括更小更便宜的。结果以单次工具响应（同步）或注入通知（异步）到达。无法发送后续指令、检查进度或提前取消。子代理误解任务时，你只能在结果回来时才发现。

模式二：Fan-Out——分发再等待

分发与收集分离。spawn_agent 立即返回 ID，wait_agent 阻塞到结果就绪。这让模型可以交错任务或先孵化多个代理再等待。

两个工具：spawn_agent 派活立即返回 ID；wait_agent 阻塞到一个或多个代理完成。模型控制时序——可以孵化后立即等待（等效同步），也可以先插入自己的工作。

示例轨迹：用户要求”重构 auth 模块并更新所有相关测试”。主 Agent 一次性发起三个工具调用：spawn_agent 派 backend-engineer 做 JWT 重构、spawn_agent 派 test-writer 更新测试、同时自己 read_file 读 auth 规格文档。前两个返回”已孵化运行中”，第三个读到”JWT 用 RS256”。主 Agent 说”两个任务已启动，规格确认用 RS256”，然后 wait_agent(timeout=300) 等待，最终收到两份完成报告：agent-a 重构了 3 个文件，agent-b 更新 12 个测试全绿。

模型决定交错方式。可以孵化多个代理、执行其他工具调用，然后把 wait_agent 当全局邮箱批量收取所有已完成的结果。

适用场景：多个可并发的独立任务。主 Agent 不需要一个子代理的中间结果才能启动另一个。

局限：模型需要正确决定何时等待。每个 spawn 后立即 wait 的模型相比模式一毫无收益。价值取决于模型在 spawn 与 wait 之间穿插自己工作的能力。结果经 wait_agent 批量收集，返回自上次调用以来所有已完成输出。仍是发后即忘：无法给子代理发后续指令或中途纠偏。

模式三：Agent Pool——带消息的持久代理

主 Agent 通过消息管理长生命周期、有状态的子代理。支持多步协作：主 Agent 在保留各自会话历史的专家之间路由信息。

工具集：spawn_agent、send_message、wait_agent、list_agents、kill_agent。

与模式二不同，这里的代理是有状态且可交互的。主 Agent 发消息、收回复、再给同一代理发消息。代理保留完整会话历史，支撑主 Agent 在专家间协调的多步工作流。

以”写一篇 WebAssembly 性能博客”为例：主 Agent 孵化 researcher（带 web_search、read_url 工具）与 writer（带 write_file、read_file）。先同时给两者发消息——researcher 去找 5 个带具体数字的基准来源，writer 先出 4 节大纲。wait 收到 writer 大纲就绪、researcher 找到 5 个来源（Chrome 基准 1.2 倍原生速度等）。主 Agent 把来源转给 writer 填充大纲。writer 交稿后，主 Agent 再让 researcher 事实核查草稿，发现第 3 段引用 2 倍速度而来源是 1.5 倍。主 Agent 转发修正要求并 kill_agent 终结 researcher，最终交付。

模型控制编排流。结果经 wait_agent 按消息增量到达，主 Agent 可依据中间输出调整指令。

适用场景：需要代理协作的多步工作流。主 Agent 在专家间路由信息。

局限：主 Agent 必须追踪多个代理状态、决定何时追问何时等待、正确路由信息。小模型会记混哪个代理持有哪些上下文，或忘记收尾 kill_agent。前沿模型也就能应付 2-4 个代理。

模式四：Teams——代理互相直接通信

代理用跨代理消息或共享邮箱直接协调。主 Agent 搭好团队后退到一边，只等最终报告或定期查状态。

工具面包含跨代理寻址。每个代理在自己的工具集里拿到 send_message，能按名字或路径呼叫其他代理。

从主 Agent 视角看会话很短：孵化 planner、implementer、reviewer 三个角色（各自带 read_file/write_file/run_command/send_message 的子集），给 planner 发一条协调指令”规划并协调功能 X，队友是 agent-i 和 agent-v，直接给他们发消息，完成后向我汇报”，然后 wait。60 秒超时无人响应后 list_agents 查看状态（p 运行中、i 运行中、v 空闲），再 wait 120 秒收到 planner 汇报”功能完成，3 文件变更，测试全过”。

代理间协作完全发生在子代理自己的上下文里。主 Agent 只看到被显式汇报回来的内容。寻址可用层级路径、邮箱或 IPC。

适用场景：协调逻辑超出单个 Agent 逐步管理能力的大型任务。

局限：团队里每个代理都需要前沿级模型能力，不只是主 Agent。每个成员必须独立决定何时给队友发消息、发什么、何时汇报。模型可能发错对象、忘记汇报完成、陷入循环。模型能力之外还有基础设施挑战：环检测（A 等 B、B 等 A）、冲突解决（两代理改同一文件）、停机协调。调试困难——代理间消息链难以追踪，失败会级联。

选型速查

模式	工具	主 Agent 角色	代理生命周期
Inline Tool	call_agent	调用方	单任务
Fan-Out	spawn_agent, wait_agent	分发器	单任务
Agent Pool	spawn/send/wait/list/kill	协调者	多轮
Teams	以上全部+跨代理 send_message	监督者	持久

从模式 1 起步——大多数任务不需要复杂编排。只在需要并行工作（2）、多步协作（3）或复杂团队协调（4）时向上升级。

越高的模式要求越强的模型。模式 1 广泛适用；模式 2 需要推理等待时机；模式 3 需要多轮状态追踪；模式 4 要求所有参与者都是前沿模型。

原文信息

• 作者：Philipp Schmid（@_philschmid），Google DeepMind 工程师
• 原文发布日期：2026-05-05 原文地址：