# How Agents Manage Other Agents: Four Subagents Patterns in 2026
**作者**: Philipp Schmid
**日期**: 2026-05-05T14:45:32.000Z
**来源**: [https://x.com/_philschmid/status/2051674663965606052](https://x.com/_philschmid/status/2051674663965606052)
---
Last year I covered why isolating tasks into focused agents improves reliability. Since then, better planning and tool use have unlocked patterns previously too fragile: persistent worker pools and direct inter-agent messaging.
Here are four patterns, ordered by main agent control over the subagent lifecycle.
## 1. Inline Tool: Subagent as a Function Call
The main agent calls a tool (e.g., call_agent) that spawns a subagent and returns the result. To the caller, it's just another tool like read_file. The subagent runs in its own context, and the main agent never manages its 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..." }
]
```
This pattern supports both modes:
- Sync: The tool blocks until the subagent finishes, returning the result directly.
- Async: The tool returns an ID immediately. The result is injected as a notification later, letting the main agent continue work.
```
[
{ "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..." }
]
```
In sync, the tool response contains the result. In async, the tool response contains an ID, and the result arrives later as an injected user message.
When to use this: Self-contained work. Research lookups, code reviews, file analysis, test generation. Most subagent use cases start and stay here.
Limitations: Works with any model that supports tool use, including smaller and cheaper ones. Results arrive as a single tool response (sync) or as an injected notification message (async). No way to send follow-up instructions, check progress, or cancel early. If the subagent misunderstands the task, you find out when the result comes back.
## 2. Fan-Out: Spawn Agents and Wait for Results
Spawning and collecting are separate. spawn_agent returns an ID immediately, `wait_agent` blocks until results are ready. This lets the model interleave tasks or spawn multiple agents before waiting.
Two tools: `spawn_agent` dispatches work and returns immediately with an ID. `wait_agent` blocks until one or more agents finish. The model controls sequencing. It can spawn agents and call wait_agent immediately (effectively synchronous), or interleave its own work first:
```
[
{ "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..." }
]
```
The model decides the interleaving. It can spawn multiple agents, perform other tool calls, and then use `wait_agent` as a global mailbox to collect all available results.
When to use this: Multiple independent tasks that can run concurrently. The main agent does not need intermediate results from one subagent to start another.
Limitations: The model needs to correctly decide when to wait. A model that calls wait_agent immediately after every spawn gets no benefit over Pattern 1. The value depends on the model's ability to interleave its own work between spawn and wait. Results are collected in batch via wait_agent, which returns all completed agent outputs since the last call. Still fire-and-forget: no way to send follow-up instructions or course-correct mid-task to subagents.
## 3. Agent Pool: Persistent Agents with Messaging
The main agent manages long-lived, stateful subagents via messaging. This supports multi-step coordination where the main agent routes information between specialists who retain their conversation history.
Tools: `spawn_agent`, `send_message`, `wait_agent`, `list_agents`, `kill_agent`.
Unlike Pattern 2, agents here are stateful and interactive. The main agent sends a message, gets a response, and sends another message to the same agent. The agent retains its full conversation history. This supports multi-step workflows where the main agent coordinates between specialists.
The model controls whether it works with one agent at a time (sequential) or messages multiple agents between waits (parallel). It can send to the researcher and writer simultaneously, or wait for the researcher first:
```
[
{ "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..." }
]
```
The model controls the orchestration flow. Results arrive incrementally per message via wait_agent, allowing the main agent to adapt its instructions based on intermediate outputs.
When to use this: Multi-step workflows where agents need to collaborate. The main agent routes information between specialists.
Limitations: The main agent must track multiple agent states, decide when to send follow-ups vs wait, and route information correctly. Smaller models lose track of which agent has which context, or forget to call kill_agent when done. Frontier models might handle 2-4 agents okayish.
## 4. Teams: Agents Talk to Each Other
Agents coordinate directly using cross-agent messaging or shared mailboxes. The main agent sets up the team and steps back, only waiting for the final report or periodically checking status.
The tool surface includes cross-agent addressing. Each agent gets send_message in its own tool set and can address other agents by name or path.
From the main agent's perspective, the conversation is short. It sets up the team, kicks off the planner, and waits for the final report. The model can choose to wait silently, or periodically check in using 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..." }
]
```
Inter-agent collaboration happens entirely within the subagents' contexts. The main agent only sees what is explicitly reported back. Addressing can use hierarchical paths, mailboxes, or IPC.
When to use this: Large tasks where the coordination logic exceeds what a single agent can manage step-by-step.
Limitations: Every agent in the team needs frontier-class model capabilities, not just the main agent. Each team member must independently decide when to message teammates, what to include, and when to report back. Models can message the wrong agent, forget to report completion, or get stuck in loops. Beyond model capability, there are infrastructure challenges: cycle detection (A waits on B, B waits on A), conflict resolution (two agents edit the same file), and shutdown coordination. Debugging is hard because message chains between agents are difficult to trace and failures cascade.
## Choosing a 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
Start with Pattern 1; most tasks don't need complex orchestration. Move up only as needed for parallel work (2), multi-step collaboration (3), or complex team coordination (4).
Higher patterns demand more capable models. Pattern 1 works broadly. Pattern 2 requires reasoning about wait times. Pattern 3 needs multi-turn state tracking. Pattern 4 requires frontier models for all participants.
Originally published at: https://www.philschmid.de/subagent-patterns-2026
## 相关链接
- [Philipp Schmid](https://x.com/_philschmid)
- [@_philschmid](https://x.com/_philschmid)
- [13K](https://x.com/_philschmid/status/2051674663965606052/analytics)
- [Last year I covered](https://www.philschmid.de/the-rise-of-subagents)
- [https://www.philschmid.de/subagent-patterns-2026](https://www.philschmid.de/subagent-patterns-2026)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:45 PM · May 5, 2026](https://x.com/_philschmid/status/2051674663965606052)
- [13.2K Views](https://x.com/_philschmid/status/2051674663965606052/analytics)
- [View quotes](https://x.com/_philschmid/status/2051674663965606052/quotes)
---
*导出时间: 2026/5/6 09:12:58*
---
## 中文翻译
# 智能体如何管理其他智能体：2026年的四种子智能体模式
**作者**: Philipp Schmid
**日期**: 2026-05-05T14:45:32.000Z
**来源**: [https://x.com/_philschmid/status/2051674663965606052](https://x.com/_philschmid/status/2051674663965606052)
---
去年我探讨了为什么将任务隔离到专注的智能体中能提高可靠性。自那时起，更强大的规划和工具使用能力解锁了以前因为过于脆弱而无法实现的模式：持久化的工作池和直接的智能体间消息传递。
以下是四种模式，按照主智能体对子智能体生命周期的控制程度排序。
## 1. 内联工具：子智能体作为函数调用
主智能体调用一个工具（例如 `call_agent`），该工具生成一个子智能体并返回结果。对调用者而言，这就像是 `read_file` 一样的普通工具。子智能体在自己的上下文中运行，主智能体从不管理其生命周期。
```
[
{ "role": "user", "content": "审查 PR #42 的安全问题" },
{ "role": "assistant", "tool_calls": [
{ "name": "call_agent", "arguments": { "task": "审查 PR #42 的安全问题。重点关注身份验证变更。", "agent": "security-reviewer", "tools": ["read_file", "search_code"] } }
]},
{ "role": "tool", "name": "call_agent", "content": "发现 2 个问题：1) /api/users 端点未验证 Auth token。2) 登录处理程序中 Session cookie 缺少 HttpOnly 标志。" },
{ "role": "assistant", "content": "审查发现了 2 个安全问题..." }
]
```
此模式支持两种方式：
- **同步**：工具会阻塞，直到子智能体完成，直接返回结果。
- **异步**：工具立即返回一个 ID。结果稍后会作为通知注入，让主智能体可以继续工作。
```
[
{ "role": "user", "content": "审查 PR #42 并检查 CI 日志" },
{ "role": "assistant", "tool_calls": [
{ "name": "call_agent", "arguments": { "task": "审查 PR #42 的安全问题", "agent": "security-reviewer", "background": true } },
{ "name": "read_file", "arguments": { "path": "ci/logs/latest.txt" } }
]},
{ "role": "tool", "name": "call_agent", "content": "agent_id: agent-x1. 正在后台运行。" },
{ "role": "tool", "name": "read_file", "content": "构建通过。142 个测试全部通过。" },
{ "role": "assistant", "content": "CI 看起来没问题。正在等待安全审查..." },
{ "role": "user", "content": "<notification agent_id='agent-x1' status='completed'>发现 2 个问题：...</notification>" },
{ "role": "assistant", "content": "安全审查发现了 2 个问题..." }
]
```
在同步模式下，工具响应包含结果。在异步模式下，工具响应包含一个 ID，结果稍后作为注入的用户消息到达。
**何时使用**：独立的工作。研究查询、代码审查、文件分析、测试生成。大多数子智能体用例都始于此并停留于此。
**局限性**：适用于任何支持工具使用的模型，包括更小、更便宜的模型。结果作为单一工具响应（同步）到达，或作为注入的通知消息（异步）到达。无法发送后续指令、检查进度或提前取消。如果子智能体误解了任务，你只能在结果返回时才发现。
## 2. 扇出：生成智能体并等待结果
生成和收集是分离的。`spawn_agent` 立即返回一个 ID，`wait_agent` 会阻塞直到结果准备好。这使得模型可以交错执行任务，或者在等待之前生成多个智能体。
两个工具：`spawn_agent` 分派工作并立即返回一个 ID。`wait_agent` 阻塞直到一个或多个智能体完成。模型控制排序。它可以生成智能体并立即调用 `wait_agent`（实际上是同步的），或者先穿插执行自己的工作：
```
[
{ "role": "user", "content": "重构 auth 模块并更新所有相关测试" },
{ "role": "assistant", "tool_calls": [
{ "name": "spawn_agent", "arguments": { "task": "重构 auth 模块以使用 JWT tokens", "agent": "backend-engineer" } },
{ "name": "spawn_agent", "arguments": { "task": "更新所有与 auth 相关的测试以适应新的 JWT 流程", "agent": "test-writer" } },
{ "name": "read_file", "arguments": { "path": "docs/auth-spec.md" } }
]},
{ "role": "tool", "name": "spawn_agent", "content": "已生成 agent-a (backend-engineer)。运行中。" },
{ "role": "tool", "name": "spawn_agent", "content": "已生成 agent-b (test-writer)。运行中。" },
{ "role": "tool", "name": "read_file", "content": "# Auth Spec\nJWT tokens with RS256..." },
{ "role": "assistant", "content": "我已经启动了这两项任务。Auth 规范确认我们应该使用 RS256。" },
{ "role": "assistant", "tool_calls": [{ "name": "wait_agent", "arguments": { "timeout": 300 } }]},
{ "role": "tool", "name": "wait_agent", "content": "2 个智能体完成：\n- agent-a: 重构了 3 个文件 (auth.ts, middleware.ts, config.ts)\n- agent-b: 更新了 12 个测试，全部通过" },
{ "role": "assistant", "content": "两项任务都完成了。Auth 模块现在使用 JWT..." }
]
```
模型决定穿插方式。它可以生成多个智能体，执行其他工具调用，然后使用 `wait_agent` 作为全局邮箱来收集所有可用的结果。
**何时使用**：多个可以并发运行的独立任务。主智能体不需要一个子智能体的中间结果来启动另一个。
**局限性**：模型需要正确决定何时等待。如果在每次生成后立即调用 `wait_agent` 的模型，相比模式 1 没有任何优势。其价值取决于模型在生成和等待之间穿插自己工作的能力。结果通过 `wait_agent` 批量收集，返回自上次调用以来所有已完成的智能体输出。依然是“发后即忘”：无法发送后续指令或在任务中途纠正子智能体的方向。
## 3. 智能体池：带消息传递的持久化智能体
主智能体通过消息传递管理长期存在、有状态的子智能体。这支持多步骤协调，其中主智能体在保留其对话历史的专家之间路由信息。
工具：`spawn_agent`，`send_message`，`wait_agent`，`list_agents`，`kill_agent`。
与模式 2 不同，这里的智能体是有状态且交互式的。主智能体发送一条消息，获得响应，然后向同一个智能体发送另一条消息。智能体保留其完整的对话历史。这支持主智能体在专家之间进行协调的多步骤工作流。
模型控制是一次处理一个智能体（顺序），还是在等待之间向多个智能体发送消息（并行）。它可以同时向研究员和作家发送消息，或者先等待研究员：
```
[
{ "role": "user", "content": "写一篇关于 WebAssembly 性能的博客文章" },
{ "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": "已生成 agent-r (researcher)" },
{ "role": "tool", "name": "spawn_agent", "content": "已生成 agent-w (writer)" },
{ "role": "assistant", "tool_calls": [
{ "name": "send_message", "arguments": { "to": "agent-r", "message": "研究 WebAssembly 性能基准。找到 5 个带有具体数字的资源。" } },
{ "name": "send_message", "arguments": { "to": "agent-w", "message": "列出关于 WebAssembly 性能的博客文章大纲。4 个部分。" } }
]},
{ "role": "tool", "name": "send_message", "content": "已发送至 agent-r" },
{ "role": "tool", "name": "send_message", "content": "已发送至 agent-w" },
{ "role": "assistant", "tool_calls": [{ "name": "wait_agent", "arguments": {} }]},
{ "role": "tool", "name": "wait_agent", "content": "agent-w 响应：大纲就绪：介绍、基准、真实案例、结论" },
{ "role": "assistant", "tool_calls": [{ "name": "wait_agent", "arguments": {} }]},
{ "role": "tool", "name": "wait_agent", "content": "agent-r 响应：找到 5 个资源：1) Chrome 基准显示达到原生的 1.2 倍速度..." },
{ "role": "assistant", "tool_calls": [{ "name": "send_message", "arguments": { "to": "agent-w", "message": "使用这些资源填充你的大纲：1) Chrome 基准显示达到原生的 1.2 倍速度..." } }]},
{ "role": "tool", "name": "send_message", "content": "已发送至 agent-w" },
{ "role": "assistant", "tool_calls": [{ "name": "wait_agent", "arguments": {} }]},
{ "role": "tool", "name": "wait_agent", "content": "agent-w 响应：草稿完成。标题：《WebAssembly 比你想象的要快》..." },
{ "role": "assistant", "tool_calls": [{ "name": "send_message", "arguments": { "to": "agent-r", "message": "根据你的资源核实这份草稿：《WebAssembly 比你想象的要快》..." } }]},
{ "role": "tool", "name": "send_message", "content": "已发送至 agent-r" },
{ "role": "assistant", "tool_calls": [{ "name": "wait_agent", "arguments": {} }]},
{ "role": "tool", "name": "wait_agent", "content": "agent-r 响应：2 处更正：第 3 段引用了 2 倍速度但来源说是 1.5 倍..." },
{ "role": "assistant", "tool_calls": [
{ "name": "send_message", "arguments": { "to": "agent-w", "message": "应用这些更正：第 3 段应该说 1.5 倍而不是 2 倍..." } },
{ "name": "kill_agent", "arguments": { "agent_id": "agent-r" }}
]},
{ "role": "tool", "name": "send_message", "content": "已发送至 agent-w" },
{ "role": "tool", "name": "kill_agent", "content": "agent-r 已终止" },
{ "role": "assistant", "content": "这是最终的文章..." }
]
```
模型控制编排流程。结果通过 `wait_agent` 按消息增量到达，允许主智能体根据中间输出调整其指令。
**何时使用**：需要智能体协作的多步骤工作流。主智能体在专家之间路由信息。
**局限性**：主智能体必须跟踪多个智能体的状态，决定何时发送后续消息与等待，并正确路由信息。较小的模型会忘记哪个智能体拥有哪个上下文，或者在完成后忘记调用 `kill_agent`。前沿模型可能还能勉强应付 2-4 个智能体。
## 4. 团队：智能体彼此对话
智能体使用跨智能体消息传递或共享邮箱直接协调。主智能体组建团队并退后一步，只等待最终报告或定期检查状态。
工具集包括跨智能体寻址。每个智能体在自己的工具集中获得 `send_message`，并可以通过名称或路径寻址其他智能体。
从主智能体的角度来看，对话很短。它组建团队，启动规划者，并等待最终报告。模型可以选择静默等待，或者定期使用 `list_agents` 检查：
```
[
{ "role": "user", "content": "构建功能 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": "已生成 agent-p (planner)" },
{ "role": "tool", "name": "spawn_agent", "content": "已生成 agent-i (implementer)" },
{ "role": "tool", "name": "spawn_agent", "content": "已生成 agent-v (reviewer)" },
{ "role": "assistant", "tool_calls": [{ "name": "send_message", "arguments": { "to": "agent-p", "message": "规划并协调功能 X。你的队友：agent-i (implementer)，agent-v (reviewer)。直接给他们发消息。完成后向我汇报。" } }]},
{ "role": "tool", "name": "send_message", "content": "已发送至 agent-p" },
{ "role": "assistant", "tool_calls": [{ "name": "wait_agent", "arguments": { "timeout": 60 } }]},
{ "role": "tool", "name": "wait_agent", "content": "超时。没有智能体响应。" },
{ "role": "assistant", "tool_calls": [{ "name": "list_agents", "arguments": {} }]},
{ "role": "tool", "name": "list_agents", "content": "agent-p: 运行中, agent-i: 运行中, agent-v: 空闲" },
{ "role": "assistant", "tool_calls": [{ "name": "wait_agent", "arguments": { "timeout": 120 } }]},
{ "role": "tool", "name": "wait_agent", "content": "agent-p 响应：功能 X 完成。更改了 3 个文件，所有测试通过。摘要：..." },
{ "role": "assistant", "content": "功能 X 已构建。这是完成的内容..." }
]
```
智能体间的协作完全发生在子智能体的上下文内部。主智能体只能看到明确汇报回来的内容。寻址可以使用分层路径、邮箱或 IPC。
**何时使用**：协调逻辑超出单个智能体逐步管理能力的大型任务。
**局限性**：团队中的每个智能体都需要前沿级别的模型能力，而不仅仅是主智能体。每个团队成员必须独立决定何时给队友发送消息、包含什么内容以及何时汇报。模型可能会向错误的智能体发送消息，忘记汇报完成情况，或者陷入循环。除了模型能力之外，还存在基础设施挑战：循环检测（A 等待 B，B 等待 A）、冲突解决（两个智能体编辑同一个文件）和关闭协调。调试很困难，因为智能体之间的消息链难以追踪，且故障会级联传播。
## 选择模式
模式 | 工具 | 主智能体角色 | 智能体生命周期
--- | --- | --- | ---
内联工具 | call_agent | 调用者 | 单次任务
扇出 | spawn_agent, wait_agent | 分发器 | 单次任务
智能体池 | spawn, send, wait, list, kill | 协调者 | 多轮交互
团队 | 以上所有 + 跨智能体 send_message | 监督者 | 持久化
从模式 1 开始；大多数任务不需要复杂的编排。仅根据需要升级到并行工作（2）、多步骤协作（3）或复杂的团队协调（4）。
更高的模式需要更强大的模型。模式 1 广泛适用。模式 2 需要对等待时间进行推理。模式 3 需要多轮状态跟踪。模式 4 要求所有参与者都使用前沿模型。
最初发布于：https://www.philschmid.de/subagent-patterns-2026
## 相关链接
- [Philipp Schmid](https://x.com/_philschmid)
- [@_philschmid](https://x.com/_philschmid)
- [13K](https://x.com/_philschmid/status/2051674663965606052/analytics)
- [Last year I covered](https://www.philschmid.de/the-rise-of-subagents)
- [https://www.philschmid.de/subagent-patterns-2026](https://www.philschmid.de/subagent-patterns-2026)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:45 PM · May 5, 2026](https://x.com/_philschmid/status/2051674663965606052)
- [13.2K Views](https://x.com/_philschmid/status/2051674663965606052/analytics)
- [View quotes](https://x.com/_philschmid/status/2051674663965606052/quotes)
---
*导出时间: 2026/5/6 09:12:58*