SubAgent 原理深度解析：AI 系统如何通过委托实现专业化分工

上下文爆炸：你迟早会遇到的问题

让 Agent 做一件复杂任务——比如"帮我调研竞品，整理成报告"。

Agent 开始工作：搜索网页、读取文件、解析日志……十几轮工具调用之后，主对话的上下文里塞满了搜索结果片段、文件内容、中间推理过程。这些信息大部分只是"工作痕迹"，最终报告根本不需要它们。但它们已经永久占据了上下文窗口。

后果是双重的：推理质量下降（模型要在海量噪声里找关键信息）和Token 成本飙升（每一轮调用都要携带这些历史）。

这就是上下文爆炸。随着 Agent 执行的任务越来越复杂，这个问题不是偶发的，是必然的。

SubAgent 解决的本质问题是：把"不需要主 Agent 记住的工作"派给隔离的上下文去做，只拿回一句摘要。

这和软件工程里的"关注点分离"是同一个道理——不是因为子模块不重要，而是因为它的实现细节不应该污染上层调用者的状态。

SubAgent 的核心模型：三个要素

SubAgent 不是一个新模型，而是一种运行实例的隔离方式。理解它需要抓住三个核心要素。

要素一：隔离的上下文窗口

这是 SubAgent 最根本的特征。

每个 SubAgent 运行在自己独立的上下文窗口里。它不知道父 Agent 在聊什么、做了什么——它只有：

1. 自己的 System Prompt（定义它是谁、能做什么）
2. 当前被委派的任务描述
3. 自己的工具调用历史

父 Agent 的整个对话历史对 SubAgent 是完全不可见的。当 SubAgent 完成任务，它把结果打包返回给父 Agent——父 Agent 看到的只是结论，而不是 SubAgent 走过的每一步。

主对话上下文 SubAgent 上下文 ┌─────────────────────┐ ┌─────────────────────┐ │ 用户消息 1 │ │ System Prompt │ │ Agent 回复 1 │ 委派任务 │ （SubAgent 的角色定义）│ │ 工具调用 A │ ─────────→ │ 任务描述 │ │ 用户消息 2 │ │ 工具调用 X │ │ Agent 回复 2 │ ←───────── │ 工具调用 Y │ │ [SubAgent 返回摘要] │ 只返回摘要 │ 工具调用 Z │ └─────────────────────┘ └─────────────────────┘

主对话完全不知道 SubAgent 调用了多少次工具，搜索了多少内容——那些工作过程永远留在 SubAgent 的独立上下文里，随着任务结束而消失。

要素二：能力约束

SubAgent 可以被精确限制"能做什么"，从两个维度控制：

工具访问（Tool Access）

# 只读型 SubAgent：只能读，不能写tools:Read,Grep,Glob,Bash# 排除型 SubAgent：继承所有工具，但禁止写文件disallowedTools:Write,Edit# 全能型 SubAgent：继承父对话的所有工具# （不设置 tools 字段，默认继承）

模型选择（Model Selection）

SubAgent 可以使用和父 Agent 不同的模型。这是成本控制的关键杠杆：

model:haiku# 快速、低成本，适合简单探索任务model:sonnet