Agent 如何管理其他 Agent：2026 年的四种 Subagent 模式

Philschmid](https://www.philschmid.de/)

搜索⌘k

博客项目Newsletter关于我切换菜单

Agent 如何管理其他 Agent：2026 年的四种 Subagent 模式

2026 年 5 月 5 日，阅读时间 11 分钟

去年我写过 subagent 的兴起，以及为什么把任务隔离到拥有独立 context、tools 和 instructions 的专用 agent 中，可以提升可靠性。那篇文章讲的是 subagent 是_什么_，以及你为什么会需要它们。此后，模型在 planning、tool use 和多步骤 instructions 方面都有所进步。这让一些过去过于脆弱的模式变得可行：例如由 agent 管理一组持久化 worker，或 agent 之间直接相互发送消息。

下面是四种模式，按主 agent 对 subagent lifecycle 的控制程度排序。

1. Inline Tool：把 Subagent 当作 Function Call

最简单的模式。主 agent 调用一个 tool，该 tool 启动一个 subagent，并把结果作为 tool response 返回。从主 agent 的视角看，调用 subagent 和调用 read_file 或 run_command 没有区别。

主 agent 有一个 tool，例如 call_agent。它发送任务，得到结果。subagent 在自己的 context 中运行，拥有自己的 tools 和 instructions。主 agent 从不直接管理 subagent 的 lifecycle。

[
  { "role": "user", "content": "Review PR #42 for security issues" },
  { "role": "assistant", "tool_calls": [
    { "name": "call_agent", "arguments": { "task": "Review PR #42 for security issues. Focus on auth changes.", "agent": "security-reviewer", "tools": ["read_file", "search_code"] } }
  ]},
  { "role": "tool", "name": "call_agent", "content": "Found 2 issues: 1) Auth token not validated in /api/users endpoint. 2) Session cookie missing HttpOnly flag in login handler." },
  { "role": "assistant", "content": "The review found 2 security issues..." }
]

这种模式在 tool 层面有 sync/async 的区别，因为 tool 本身既可以阻塞，也可以立即返回：

Sync（上例）： tool call 会阻塞。主 agent 的回合会暂停，直到 subagent 完成。结果会作为普通 tool response 返回。

Async： tool 会立即返回一个 agent ID。当 subagent 完成时，它的结果会作为 notification message 注入 conversation。主 agent 可以在结果到达前执行其他 tool calls。

[
  { "role": "user", "content": "Review PR #42 and also check the CI logs" },
  { "role": "assistant", "tool_calls": [
    { "name": "call_agent", "arguments": { "task": "Review PR #42 for security issues", "agent": "security-reviewer", "background": true } },
    { "name": "read_file", "arguments": { "path": "ci/logs/latest.txt" } }
  ]},
  { "role": "tool", "name": "call_agent", "content": "agent_id: agent-x1. Running in background." },
  { "role": "tool", "name": "read_file", "content": "Build passed. 142 tests green." },
  { "role": "assistant", "content": "CI looks clean. Waiting for the security review..." },
  { "role": "user", "content": "<notification agent_id='agent-x1' status='completed'>Found 2 issues: ...</notification>" },
  { "role": "assistant", "content": "The security review found 2 issues..." }
]

在 sync 中，tool response 包含结果。在 async 中，tool response 包含一个 ID，结果稍后以注入的 user message 形式到达。

适用场景： 自包含的工作。研究查询、code review、文件分析、测试生成。大多数 subagent 用例都会从这里开始，并停留在这里。

局限： 适用于任何支持 tool use 的模型，包括更小、更便宜的模型。结果会作为单个 tool response（sync）或注入的 notification message（async）到达。无法发送后续 instructions、检查进度或提前取消。如果 subagent 误解了任务，你只能在结果返回时才发现。

2. Fan-Out：启动多个 Agent 并等待结果

主 agent 启动 subagent，并使用 wait_agent tool 收集结果。与 inline tool 不同，启动和收集是两个独立步骤。spawn_agent 总是立即返回。模型决定接下来做什么：立刻调用 wait_agent，先做自己的工作，或在等待前启动更多 agent。

两个 tools：spawn_agent 分发工作并立即返回一个 ID。wait_agent 会阻塞，直到一个或多个 agent 完成。

模型控制顺序。它可以启动 agent 后立即调用 wait_agent（实际上等同于同步），也可以先穿插自己的工作：

[
  { "role": "user", "content": "Refactor the auth module and update all related tests" },
  { "role": "assistant", "tool_calls": [
    { "name": "spawn_agent", "arguments": { "task": "Refactor the auth module to use JWT tokens", "agent": "backend-engineer" } },
    { "name": "spawn_agent", "arguments": { "task": "Update all auth-related tests for the new JWT flow", "agent": "test-writer" } },
    { "name": "read_file", "arguments": { "path": "docs/auth-spec.md" } }
  ]},
  { "role": "tool", "name": "spawn_agent", "content": "Spawned agent-a (backend-engineer). Running." },
  { "role": "tool", "name": "spawn_agent", "content": "Spawned agent-b (test-writer). Running." },
  { "role": "tool", "name": "read_file", "content": "# Auth Spec\nJWT tokens with RS256..." },
  { "role": "assistant", "content": "I've kicked off both tasks. The auth spec confirms we should use RS256." },
  { "role": "assistant", "tool_calls": [{ "name": "wait_agent", "arguments": { "timeout": 300 } }]},
  { "role": "tool", "name": "wait_agent", "content": "2 agents completed:\n- agent-a: Refactored 3 files (auth.ts, middleware.ts, config.ts)\n- agent-b: Updated 12 tests, all passing" },
  { "role": "assistant", "content": "Both tasks are done. The auth module now uses JWT..." }
]

模型在同一次 tool call 中启动了两个 agent 并读取了一个文件，然后决定等待。另一个模型可能会在启动后立即调用 wait_agent，或先执行几次读取。tool surface 是一样的；由模型决定如何交错执行。

与模式 1 的区别在于：模型控制何时收集结果。它可以并行启动 5 个 agent，自己读取文件，然后再调用 wait_agent。wait_agent 可以充当一个全局 mailbox，在 subagent 完成时被唤醒，并返回所有可用结果。

适用场景： 多个可以并发运行的独立任务。主 agent 不需要拿到某个 subagent 的中间结果，才能启动另一个 subagent。

局限： 模型需要正确判断_何时_等待。如果模型每次启动后都立即调用 wait_agent，那相比模式 1 没有任何收益。价值取决于模型能否在 spawn 和 wait 之间穿插自己的工作。结果通过 wait_agent 批量收集，它会返回自上次调用以来所有已完成 agent 的输出。仍然是 fire-and-forget：无法向 subagent 发送后续 instructions，也无法在任务中途纠偏。

3. Agent Pool：带消息机制的持久化 Agent

主 agent 启动长生命周期的 subagent，并通过消息与它们通信。agent 会跨 interaction 持续存在。主 agent 可以发送后续 instructions、检查状态，并协调 agent 之间的工作。

这需要更丰富的 tool surface：spawn_agent、send_message、wait_agent、list_agents、kill_agent。

与模式 2 不同，这里的 agent 是有状态且可交互的。主 agent 发送一条消息，得到回应，然后再向同一个 agent 发送另一条消息。该 agent 会保留完整的 conversation history。这支持多步骤 workflow，其中主 agent 在多个 specialist 之间协调。

模型控制是一次只与一个 agent 工作（顺序），还是在等待之间给多个 agent 发送消息（并行）。它可以同时发给 researcher 和 writer，也可以先等待 researcher：

[
  { "role": "user", "content": "Write a blog post about WebAssembly performance" },
 
  { "role": "assistant", "tool_calls": [
    { "name": "spawn_agent", "arguments": { "role": "researcher", "tools": ["web_search", "read_url"] }},
    { "name": "spawn_agent", "arguments": { "role": "writer", "tools": ["write_file", "read_file"] }}
  ]},
  { "role": "tool", "name": "spawn_agent", "content": "Spawned agent-r (researcher)" },
  { "role": "tool", "name": "spawn_agent", "content": "Spawned agent-w (writer)" },
 
  { "role": "assistant", "tool_calls": [
    { "name": "send_message", "arguments": { "to": "agent-r", "message": "Research WebAssembly performance benchmarks. Find 5 sources with concrete numbers." } },
    { "name": "send_message", "arguments": { "to": "agent-w", "message": "Outline a blog post structure about WebAssembly performance. 4 sections." } }
  ]},
  { "role": "tool", "name": "send_message", "content": "Delivered to agent-r" },
  { "role": "tool", "name": "send_message", "content": "Delivered to agent-w" },
 
  { "role": "assistant", "tool_calls": [{ "name": "wait_agent", "arguments": {} }]},
  { "role": "tool", "name": "wait_agent", "content": "agent-w responded: Outline ready: intro, benchmarks, real-world, conclusion" },
 
  { "role": "assistant", "tool_calls": [{ "name": "wait_agent", "arguments": {} }]},
  { "role": "tool", "name": "wait_agent", "content": "agent-r responded: Found 5 sources: 1) Chrome benchmark shows 1.2x native speed..." },
 
  { "role": "assistant", "tool_calls": [{ "name": "send_message", "arguments": { "to": "agent-w", "message": "Fill in your outline using these sources: 1) Chrome benchmark shows 1.2x native speed..." } }]},
  { "role": "tool", "name": "send_message", "content": "Delivered to agent-w" },
 
  { "role": "assistant", "tool_calls": [{ "name": "wait_agent", "arguments": {} }]},
  { "role": "tool", "name": "wait_agent", "content": "agent-w responded: Draft complete. Title: 'WebAssembly Is Faster Than You Think'..." },
 
  { "role": "assistant", "tool_calls": [{ "name": "send_message", "arguments": { "to": "agent-r", "message": "Fact-check this draft against your sources: 'WebAssembly Is Faster Than You Think'..." } }]},
  { "role": "tool", "name": "send_message", "content": "Delivered to agent-r" },
 
  { "role": "assistant", "tool_calls": [{ "name": "wait_agent", "arguments": {} }]},
  { "role": "tool", "name": "wait_agent", "content": "agent-r responded: 2 corrections: paragraph 3 cites 2x speed but source says 1.5x..." },
 
  { "role": "assistant", "tool_calls": [
    { "name": "send_message", "arguments": { "to": "agent-w", "message": "Apply these corrections: paragraph 3 should say 1.5x not 2x..." } },
    { "name": "kill_agent", "arguments": { "agent_id": "agent-r" }}
  ]},
  { "role": "tool", "name": "send_message", "content": "Delivered to agent-w" },
  { "role": "tool", "name": "kill_agent", "content": "agent-r terminated" },
 
  { "role": "assistant", "content": "Here is the final post..." }
]

agent-r 收到了两次消息（先 research，再 fact-check），并保留了第一次任务中的 sources。模型一开始并行向两个 agent 分派工作，随后在 fact-check 阶段按顺序协调。另一个模型可能会把所有步骤串行化。tools 是一样的；模型控制 orchestration。

结果按消息通过 wait_agent 到达。每次调用 wait_agent 都会返回下一条 agent response，因此主 agent 可以增量处理结果，并根据返回内容调整下一条消息。

适用场景： agent 需要协作的多步骤 workflow。主 agent 在 specialist 之间路由信息。

局限： 主 agent 必须跟踪多个 agent 的状态，决定何时发送 follow-up、何时等待，并正确路由信息。较小的模型容易忘记哪个 agent 拥有哪些 context，或在完成后忘记调用 kill_agent。Frontier model 处理 2-4 个 agent 可能还算可以。

4. Teams：Agent 之间直接对话

agent 之间直接发送消息，不经过主 agent。主 agent 组建 team、定义 roles，然后退到后台。agent 使用直接消息或共享 mailbox 彼此协调。

tool surface 包含跨 agent 寻址。每个 agent 在自己的 tool set 中都有 send_message，并可以按名称或路径寻址其他 agent。

从主 agent 的视角看，conversation 很短。它组建 team，启动 planner，然后等待最终报告。模型可以选择静默等待，也可以定期使用 list_agents 查看进展：

[
  { "role": "user", "content": "Build feature X" },
 
  { "role": "assistant", "tool_calls": [
    { "name": "spawn_agent", "arguments": { "role": "planner", "tools": ["read_file", "search_code", "send_message"] } },
    { "name": "spawn_agent", "arguments": { "role": "implementer", "tools": ["read_file", "write_file", "run_command", "send_message"] } },
    { "name": "spawn_agent", "arguments": { "role": "reviewer", "tools": ["read_file", "search_code", "send_message"] } }
  ]},
  { "role": "tool", "name": "spawn_agent", "content": "Spawned agent-p (planner)" },
  { "role": "tool", "name": "spawn_agent", "content": "Spawned agent-i (implementer)" },
  { "role": "tool", "name": "spawn_agent", "content": "Spawned agent-v (reviewer)" },
 
  { "role": "assistant", "tool_calls": [{ "name": "send_message", "arguments": { "to": "agent-p", "message": "Plan and coordinate feature X. Your teammates: agent-i (implementer), agent-v (reviewer). Message them directly. Report back to me when done." } }]},
  { "role": "tool", "name": "send_message", "content": "Delivered to agent-p" },
 
  { "role": "assistant", "tool_calls": [{ "name": "wait_agent", "arguments": { "timeout": 60 } }]},
  { "role": "tool", "name": "wait_agent", "content": "Timed out. No agents responded." },
 
  { "role": "assistant", "tool_calls": [{ "name": "list_agents", "arguments": {} }]},
  { "role": "tool", "name": "list_agents", "content": "agent-p: running, agent-i: running, agent-v: idle" },
 
  { "role": "assistant", "tool_calls": [{ "name": "wait_agent", "arguments": { "timeout": 120 } }]},
  { "role": "tool", "name": "wait_agent", "content": "agent-p responded: Feature X complete. 3 files changed, all tests passing. Summary: ..." },
 
  { "role": "assistant", "content": "Feature X is built. Here's what was done..." }
]

planner 给 implementer 发消息、implementer 把代码发送给 reviewer、reviewer 请求修复——这些都发生在各个 agent 自己的 conversation 中。主 agent 的 context 保持干净。模型在 timeout 后用 list_agents 检查了一次。它也可以调用没有 timeout 的 wait_agent，一直阻塞到完成。

只有当某个 agent 明确发消息回来时，主 agent 才会收集结果（这里是 planner 报告完成）。其他所有内容对主 agent 都不可见。不同实现的跨 agent 寻址方式各不相同：层级路径（/root/planner 到 /root/implementer）、基于文件的 mailbox，或 IPC 协议。

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

局限： team 中的每个 agent 都需要 frontier-class 模型能力，而不只是主 agent。每个 team member 都必须独立决定何时给队友发消息、包含哪些内容，以及何时回报。模型可能给错误的 agent 发消息，忘记报告完成，或陷入循环。除了模型能力之外，还有基础设施挑战：cycle detection（A 等 B，B 等 A）、conflict resolution（两个 agent 编辑同一个文件）、shutdown coordination。调试很难，因为 agent 之间的消息链难以追踪，失败会级联传播。

选择一种模式

模式	Tools	主 Agent 角色	Agent 生命周期
Inline Tool	call_agent	Caller	单个任务
Fan-Out	spawn_agent, wait_agent	Dispatcher	单个任务
Agent Pool	spawn, send, wait, list, kill	Coordinator	Multi-turn
Teams	以上全部 + 跨 agent send_message	Supervisor	持久化

从模式 1 开始。大多数看起来需要 multi-agent system 的任务，用一个 prompt 得当的 inline tool call 就能很好完成。对于真正独立的并行工作，再转向模式 2。当 agent 需要跨多个步骤协作时，转向模式 3。模式 4 适用于协调逻辑已经超出单个 agent 可管理范围的情况。

每上升一个层级，都需要更强的模型。模式 1 适用于任何能调用 tools 的模型。模式 2 需要模型能推理何时等待。模式 3 需要模型能跨 turn 跟踪 multi-agent state。模式 4 要求每个 agent 都使用 frontier model。如果使用较小或较便宜的模型，应停留在模式 1 或 2。

不同模式下，结果收集方式也会变化。模式 1 以内联 tool response 形式返回结果。模式 2 通过 wait_agent 批量收集结果。模式 3 增量交付结果。模式 4 只暴露 agent 明确回报的内容；其他所有内容都留在 agent 间的 conversation 中。

对于模式 2-4，spawn_agent 总是立即返回，wait_agent 在模型决定调用时收集结果。framework 提供 tools。模型控制 orchestration。今天需要 4 个 agent 协调完成的任务，明天可能用一个更好的模型驱动的单个 agent 就能解决。

Philipp Schmid © 2026版权信息RSS Feed

主题

邮件TwitterLinkedInGitHub