任务稍微复杂一点，人们就想到多智能体。这个直觉通常是错的。
真正要问的不是"该不该用多个 Agent"，而是"这个任务到底需要哪种协调方式"。这个问题的答案，决定了架构的走向。
左边是"过度协调"：四个 Agent 之间的箭头乱成一锅粥。右边是"结构化执行"：一个父 Agent 统一调度，清晰向下分发。选哪种架构，结果天差地别。
Claude 风格的系统给了你两个选择：Sub-Agent 和 Agent 团队。看着相似，解决的是完全不同的问题。
Sub-Agent：并行 + 隔离
Sub-Agent 是在独立上下文里运行的专注实例。最直接的理解方式是"委托"——你把一件具体的事交出去，它返回一个干净的结果。
每个 Sub-Agent 拿到的东西：
- 定义其角色的系统提示
- 一套有限的工具
- 完全隔离的上下文
- 一个范围明确的任务
完成之后，它只返回最终输出，没有推理过程，没有中间步骤。漏斗图说明了这一点：只有压缩后的结果回到父 Agent，上下文始终保持干净。
这一点容易被忽略：Sub-Agent 的价值不仅是速度，更是压缩。它把一团混乱的探索过程变成一个干净的信号传回来。
有三条硬性约束：
- Sub-Agent 之间不能互相通信
- Sub-Agent 不能再派生新的 Agent
- 所有信息流都经过父 Agent
这些限制让系统保持可预测。代码里是这个样子：
from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinition
async def main():
async for message in query(
prompt="Review the authentication module for issues",
options=ClaudeAgentOptions(
allowed_tools=["Read", "Grep", "Glob", "Agent"],
agents={
"security-reviewer": AgentDefinition(
description="Find vulnerabilities and security risks",
prompt="You are a security expert.",
tools=["Read", "Grep", "Glob"],
model="sonnet",
),
"performance-optimizer": AgentDefinition(
description="Identify performance bottlenecks",
prompt="You are a performance engineer.",
tools=["Read", "Grep", "Glob"],
model="sonnet",
),
},
),
):
print(message)
注意 description 字段——它是路由信号，父 Agent 靠这个判断把任务交给谁。
Agent 团队：通过通信协调
Agent 团队适合协作场景。不再是互相隔离的工作单元，而是能维持上下文、实时通信、动态调整的 Agent 集合。
结构上包含三层：
- 主导 Agent（Team Lead）：分配任务、综合结果，持久化会话
- 成员 Agent：Frontend Dev、Backend Dev、Test Writer 各自执行，彼此可以直接发消息
- 共享任务列表：记录任务状态和依赖关系，所有成员都能读写
前端 Agent 发出"API structure changed"的信号，后端和测试 Agent 立刻响应。任务之间不再是单向传递，而是真正的双向协调。
两者的本质差异
| Sub-Agent | Agent 团队 | |
|---|---|---|
| 状态 | 无状态 | 持久化 |
| 执行方式 | 一次性 | 持续交互 |
| 控制方式 | 父 Agent 管控 | 对等通信 |
| 适用场景 | 任务相互独立 | 任务之间有依赖 |
判断标准很简单：任务之间独立就用 Sub-Agent，任务之间有依赖就用 Agent 团队。
大多数人犯的错误
最常见的设计是按角色切分：规划者、开发者、测试者。这个方案在每次交接时都会丢信息。
左边的"传话游戏"：Planner → Implementer → Tester，每次交接都在损耗信息，测试者最后根本不知道规划者当时做了哪些决策。
右边的正确做法：Feature Agent 内部同时包含实现和测试，共享同一上下文，没有任何交接损耗。Auth Agent 是独立的另一个功能域，上下文可以干净切分，才值得分开。
核心原则：按 Agent 需要知道什么来划分，而不是按它扮演什么角色来划分。
五种真正有用的模式
Prompt Chaining（顺序链） — 上一步的输出作为下一步的输入，中间可以加可选检查。适合有明确流程的任务。
Routing（路由） — 基于 description 字段把任务派给最合适的 Agent。简单查询用 Haiku，复杂查询上 Sonnet。
Parallelization（并行化） — 独立任务同时跑，Sub-Agent 的典型用例，覆盖面更广。
Orchestrator–Worker（编排者-工作者） — 一个主 Agent 统一调度，其余专注执行。生产环境中最常见的模式。
Evaluator–Optimizer（评估-优化循环） — Generator 生成结果，Evaluator 评估并反馈，形成迭代。质量优先于速度。
什么时候不该上多智能体
有时候一个 Agent 就够了，不要高估架构复杂度带来的收益。
适合用多 Agent：需要上下文隔离、有真正可并行的独立任务、需要领域专业化。
不适合的场景：Agent 之间高度依赖彼此的结果、协调开销超过了并行收益、任务本身很简单。
围绕上下文边界做设计，而不是角色边界。复杂度只有在真正需要的地方才值得付出。
