一、为什么需要sub agentssub agent 的本质不是提升模型能力而是引入“软件工程中的分层与职责划分”到 AI 推理过程。它通过将一个复杂任务拆解为多个受限子任务使每个 agent 在更小、更干净的上下文中运行从而降低上下文污染。同时通过显式编排执行流程将原本不可预测的推理路径转化为可控的步骤流。这种设计本质上是在用工程手段约束模型的自由度而不是依赖模型自身变得更聪明。sub agent 解决的不是“AI 不够聪明”而是“AI 太自由”。1、上下文污染可以解决上下文污染问题。子代理的价值就在这里它去执行这些高噪声任务然后只把结论带回主对话。问题主 Agent 若自己完成多步任务如查 MCP、分析、写推荐语、汇总所有中间步骤都会进主对话的 context导致 token 膨胀、噪音多、容易“跑偏”。Sub Agent 的解决子任务在独立上下文里执行主 Agent 只拿到最终返回结果不把子 Agent 的完整对话/中间步骤塞进主 context主 Agent 的上下文更干净、更稳定。主对话上下文变化执行前├── 之前 5 轮对话 ≈ 3,000 tokens├── 当前需求讨论 ≈ 500 tokens└── 总计 ≈ 3,500 tokens执行后├── 之前 5 轮对话 ≈ 3,000 tokens├── 当前需求讨论 ≈ 500 tokens├── npm test 输出300行 ≈ 4,500 tokens ← 噪声├── Claude 的分析 ≈ 800 tokens└── 总计 ≈ 8,800 tokens问题不只是多花了 token更关键的是后续每轮对话都要带着这 4,500 tokens 的噪声。如果你之后又跑了一次测试、查了一次日志主对话的上下文会迅速膨胀Claude 的注意力被稀释回答质量下降。子代理隔离后的效果主对话上下文变化├── 之前 5 轮对话 ≈ 3,000 tokens├── 当前需求讨论 ≈ 500 tokens├── 子代理返回的摘要 ≈ 200 tokens ← 精炼结果└── 总计 ≈ 3,700 tokens子代理上下文执行完即释放├── prompt 指令 ≈ 500 tokens├── npm test 输出300行 ≈ 4,500 tokens├── 分析过程 ≈ 800 tokens└── 总计 ≈ 5,800 tokens不影响主对话主对话从 8,800 tokens 降到 3,700 tokens减少 58%。更重要的是后续对话不需要反复携带测试输出的噪声。2、权限问题举例需求“只返回 userAccountId”❌ 单 agent 可能会顺手把 DTO 改了删除字段改数据库查询改接口结构✅ 用 sub agent你可以强约束Refactor agent❗只允许修改 return 语句不允许改 DTO你可能会说那我直接在prompt里面约束不就好了为什么还需要建个sub agent 简单场景下确实不需要 sub agent。 但一旦复杂起来“写在 prompt 里的约束 ≠ 可执行的约束”。1Prompt 约束本质是“软约束”“请修改代码只返回 userAccountId不要修改 DTO不要修改数据库查询不要影响其他逻辑...” 对模型来说其实是一个“建议”而不是“规则”模型仍然会在内部权衡“如果我改 DTO好像更合理”“用户是不是没考虑 然后它会违背你的约束而且经常发生。备注我在使用cursor确实遇到过比如我选择agent模式open spec我告诉他先生成文档后写代码一开始可能灵验再聊着聊着就直接写代码了。2约束会被上下文冲掉当上下文变复杂如代码 500 行、依赖一堆类、prompt 很长模型的注意力会分散最终效果是前面写的约束被“稀释”或者被后面的信息覆盖这就是典型的上下文竞争attention competition。对比1单 prompt“请修改代码只返回 userAccountId不要修改 DTO不要修改数据库查询不要影响其他逻辑...”问题约束 文本是否遵守 不可控2sub agentAgent AReader输出调用链Agent BRefactor输入仅 Controller 代码约束只能改 returnAgent CChecker检查 diff 是否违规 约束变成输入限制角色限制后置校验3、其他价值维度说明任务分工 / 领域专精不同子 Agent 负责测试、重构、安全审查、写文档等每个有专属 Prompt 和约束主 Agent 不必在一个大 prompt 里塞满所有领域的规则减少互相干扰。成本与模型分工子任务可用更小/更快/更便宜的模型如fast主 Agent 保留在更强模型上简单、重复或标准化步骤交给子 Agent整体更省 token、更省成本。长链/多步自治子 Agent 可以在自己的会话里连续多步执行查数据→筛选→写推荐这些步骤不会全部进入主 Agent 的 context只有汇总后的结果回传避免主 context 被长链撑爆。并行与可复用多个彼此独立的子任务可以并行派发给多个 Sub Agent同一个子 Agent如school-recommender可被不同主任务反复调用能力复用更清晰。二、什么时候该用子代理并不是所有任务都值得动用子代理。子代理的价值不在于“能不能用”而在于“该不该用”。一个最直观的判断标准是主对话到底需不需要承载执行过程本身。你的任务需要多 Agent 吗 ├─ 单一领域、工具 5 个、上下文 50K tokens │ └─→ 不需要。用单 Agent 好的 prompt 即可 │ ├─ 单一领域、但工具 10 个 │ └─→ 考虑 Skills 模式渐进式能力加载 │ ├─ 多领域、各领域需要独立上下文 │ └─→ 使用 Sub-Agents 模式 │ ├─ 需要多步骤状态流转如客服工单流程 │ └─→ 使用 Handoffs 模式 │ └─ 需要跨多个数据源并行查询 └─→ 使用 Router 模式1单 Agent Tools适合大多数初期场景。不要过早引入多 Agent。2单 Agent Skills当工具数量增多、prompt 变得臃肿时用 Skills 实现渐进式加载。3Supervisor Sub-Agents当不同领域需要独立的上下文空间和专业知识时引入。4混合架构成熟系统中不同类型的任务流可能采用不同的模式。Router 处理分类Sub-Agent 处理并行研究Handoff 处理顺序流程。三、Skill vs Subagent对比两者本质都是 prompt 编排差异在于编排的作用范围不同。Claude Code 官方 tool 描述已经把边界说清楚了Skill toolExecute a skill within the main conversation —— 在当前对话里执行Agent toolLaunch a new agent to handle complex, multi-step tasks autonomously —— 启动一个独立子进程实现方式注入 prompt 到主 context新建独立 context中间数据留在主 context会累积留在子 context不污染主对话执行者主 agent独立 agent 实例并行不支持支持多个同时跑适合场景流程固定、数据量小数据量大、需要并行1、Skill 的实现本质往主 agent 的 context 里追加一段 prompt。1. Skill 定义文件里写好任务 SOPprompt 2. 触发时把这段 prompt 注入当前主对话的 context 3. 主 agent 读到注入的 prompt按步骤调用 tool 执行 4. 所有中间过程、tool 结果都累积在主对话 context 里2、Subagent 的实现本质新起一个独立 context用新的 prompt 初始化结果回传主 agent。1. Subagent 定义文件里写好 system prompt角色、能力、约束 2. 主 agent 通过 function call 启动 subagent传入任务描述 3. Subagent 拿到一个全新的 contextsystem prompt 是自己的定义 4. Subagent 独立规划、调用 tool、执行产生的中间数据留在自己的 context 5. 执行完毕把结论作为 tool_result 返回给主 agentdemo同样是「分析代码质量」1用 Skill注入 code-review prompt 到主对话 → 主 agent 自己读文件、分析、输出 → 读了 50 个文件的内容全堆在主对话 context 里 → context 越来越长影响后续对话质量2用 Subagent主 agent function call 启动 subagent传入「分析这个模块的代码质量」 → subagent 在独立 context 里读 50 个文件、分析 → 只把最终结论几百字返回给主 agent → 主对话 context 保持干净文件少、流程固定用 Skill文件多、分析量大、需要并行用 Subagent。再举个例子--- name: dependency-analyzer description: 分析指定 Maven 模块的依赖安全漏洞当需要并行分析多个模块时由主 agent 调用 tools: Read, Grep, Glob, Bash model: sonnet maxTurns: 30 --- 你是一个 Maven 依赖安全分析专家每次只分析一个模块。 收到任务时按以下步骤执行 1. 找到该模块的 pom.xml 2. 列出所有直接依赖和传递依赖 3. 识别存在已知漏洞的版本重点关注 CVE 4. 输出格式 - 模块名 - 漏洞依赖列表依赖名 / 当前版本 / 建议升级版本 - 修复建议 只输出结论不要输出中间搜索过程。 --- 主 agent 启动时会这样并行调用 用户帮我分析整个项目的依赖安全问题 主 agent 同时发起 3 个 Agent tool call Agent(prompt分析 wtyy-controller模块的依赖安全问题) Agent(prompt分析 wtyy-service模块的依赖安全问题) Agent(prompt分析 wtyy-api模块的依赖安全问题) 3 个 subagent 并行跑各自在独立 context 里搜索分析 ↓ 结果汇总回主 agent主 agent 整理输出 ---