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

上下文爆炸：你迟早会遇到的问题让 Agent 做一件复杂任务——比如"帮我调研竞品，整理成报告"。Agent 开始工作：搜索网页、读取文件、解析日志……十几轮工具调用之后，主对话的上下文里塞满了搜索结果片段、文件内容、中间推理过程。这些信息大部分只是"工作痕迹"，最终报告根本不需要它们。但它们已经永久占据了上下文窗口。后果是双重的：推理质量下降（模型要在海量噪声里找关键信息）和Token 成本飙升（每一轮调用都要携带这些历史）。这就是上下文爆炸。随着 Agent 执行的任务越来越复杂，这个问题不是偶发的，是必然的。SubAgent 解决的本质问题是：把"不需要主 Agent 记住的工作"派给隔离的上下文去做，只拿回一句摘要。这和软件工程里的"关注点分离"是同一个道理——不是因为子模块不重要，而是因为它的实现细节不应该污染上层调用者的状态。SubAgent 的核心模型：三个要素SubAgent 不是一个新模型，而是一种运行实例的隔离方式。理解它需要抓住三个核心要素。要素一：隔离的上下文窗口这是 SubAgent 最根本的特征。每个 SubAgent 运行在自己独立的上下文窗口里。它不知道父 Agent 在聊什么、做了什么——它只有：自己的 System Prompt（定义它是谁、能做什么）当前被委派的任务描述自己的工具调用历史父 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