把一个大任务拆给”一群会自己干活的子 Agent”——Subagent 模式能让主 Agent 跳出上下文天花板、并行化执行不同子问题，但代价是 token 消耗成倍上升、调试路径从单步变成多步图、还必须严格约束子 Agent 的工具、内存和凭据。Anthropic 在 2025 年的 Research Multi-Agent 系统里报告，Opus 4 调度 Sonnet 4 子 Agent 的方案比单 Opus 4 在 BrowseComp 任务上高出 90.2%，但 token 消耗是单 Agent 的 15 倍。下文把优势、挑战、边界控制与一段 Claude Code 风格的 Subagent 配置代码逐项拆开。
一、Subagent 模式的核心收益
单 Agent 受限于上下文窗口、串行延迟和”注意力稀释”三大瓶颈。把任务切给多个 Subagent 之后，这三条限制都明显缓解：
| 收益维度 | 解决的问题 | 量化收益（参考） |
|---|---|---|
| 上下文隔离 | 大量中间结果不挤占主 Agent 窗口 | 复杂任务主 Agent 上下文占用降为单 Agent 的一半以内 |
| 并行加速 | 独立子任务可并发 | 4 个独立子任务从 20 分钟缩到 6~7 分钟 |
| 模型分级 | 不同子任务用不同档位模型 | Token 成本可降 30%~50% |
| 路径多样性 | 多个子 Agent 探索不同思路 | BrowseComp 任务比单 Agent 高 90.2% |
工程上真正的甜点不是”速度更快”，而是”模型可被分工”。例如主 Agent 负责规划与综合，路由与简单筛选用 Haiku/Sonnet mini，深度推理用 Opus，分级搭配能把单 Agent 架构中”所有环节都吃 Opus 预算”的浪费省下来。
二、典型挑战：token 与调试
收益的另一面是显性成本。Anthropic 报告的 15 倍 token 消耗意味着同一笔预算，Multi-Agent 系统能跑的单价是单 Agent 的 1/15。这并非不可接受——研究型任务、跨系统自动化任务的”决策价值”高，能承担溢价；客服问答、文档摘要这类轻量任务用 Subagent 反而是亏本买卖。
调试难度是第二道关。单 Agent 时看一遍 thinking 就能定位问题；Subagent 模式下问题可能发生在：① 主 Agent 的任务切分；② 子 Agent 的工具选择；③ 子 Agent 的回传压缩；④ 主 Agent 的综合判断。每一步都需要单独的 trace 和评估指标。LangGraph 的可视化 trace、Anthropic 的 Console 模拟器、Microsoft Agent Framework 的 tracing 模块都在尝试把这层不透明性压平。
第三是评估。单 Agent 的评估假设”输入 X → 路径 Y → 输出 Z”；Multi-Agent 没有固定路径，不同子 Agent 可能用不同 Tool 找到同一答案。LLM-as-judge 必须按”事实准确性、引用准确性、完整性、来源质量、Tool 效率”五维打分，而不是简单对比最终文本。
三、Subagent 类型的常见分层
主流框架（Claude Code、OpenClaw、CrewAI、LangGraph）的 Subagent 分类高度相似。Claude Code 在 v2.1.63 之前叫 Task，之后改名为 Agent，机制不变：
| 类型 | 典型模型 | 工具权限 | 适用场景 |
|---|---|---|---|
| Explore | Haiku | 只读（Glob/Grep/Read + 只读 Bash） | 代码库搜索、文档爬取 |
| Plan | Sonnet | 只读 | 实施前的方案研究 |
| General-purpose | Sonnet/Opus | 全部工具 | 复杂多步任务（含改写） |
| 自定义角色 | 视任务定 | 按 manifest 收紧 | 安全审计、代码审查、测试执行 |
注意一个易错点：Explore 是”只读 Haiku”，但不是”无脑快”——它能调 Bash，只是命令被限制在 ls/git status/cat/head/tail/wc 等只读前缀里，含 && > ; $(...) 的命令会触发 prompt 拒绝。
四、父 Agent 调子 Agent 的边界控制
边界是 Subagent 模式的安全带，没有边界的 Subagent 等于无限制的子进程。工程上有四道必做：
- 任务边界：子 Agent 的 prompt 必须写清”目标、输出格式、Tool 来源、不应越界做什么”。Anthropic 工程团队报告，初版用”研究半导体短缺”这种短指令时，三个子 Agent 重复研究同一问题；改成详细描述后分工才明显；
- 工具边界：子 Agent 默认继承父 Agent 的工具集，必须按最小权限收紧。OpenClaw 通过
skills列表约束，Claude Code 通过tools字段限制； - 时间与步数边界：单子 Agent 必须设
timeout与max_iterations，避免一个子 Agent 把主任务卡住； - 凭据边界：子 Agent 不应直接持有父 Agent 的长期凭据，应由控制平面为每次任务签发短期 grant。
下面是一段 Claude Code 风格的自定义 Subagent 配置示例（YAML frontmatter + Markdown），展示如何同时收紧描述、工具与模型：
# .claude/agents/security-auditor.md
---
name: security-auditor
description: "专项代码安全审计，仅在用户提到 security / 漏洞 / 注入 / 越权 时启用"
model: sonnet
tools:
- Read
- Grep
- Glob
- Bash # 仅用于 git log / grep 类只读命令
disallowedTools:
- Write
- Edit
- MultiEdit
timeout_seconds: 180
max_iterations: 12
permissionMode: "readOnly"
---
你是一名资深安全审计员。任务范围：
1. 检查认证与授权逻辑是否存在越权（IDOR、缺失的 RBAC 检查）；
2. 扫描 SQL/NoSQL 注入、XSS、SSRF 风险点；
3. 报告所有"硬编码密钥、不安全随机数、过期依赖"等静态问题。
**禁止**改写任何文件、**禁止**调用网络、**禁止**访问 .env / secrets 目录。
输出必须为 Markdown 表格：文件路径 | 行号 | 风险类型 | 修复建议。把这段放到项目 .claude/agents/ 下，Claude Code 启动后会自动注册。description 决定何时被触发，tools / disallowedTools 收紧权限，timeout_seconds 与 max_iterations 兜底失控——四道边界一行不少。
五、并行与同步陷阱
并行不是越多越好。Anthropic 的经验是复杂研究任务 3~5 个子 Agent 平行启动已经能拿到 90% 的加速收益；10+ 个子 Agent 时调度开销、上下文传递成本开始反噬。子 Agent 之间的依赖也要严格控制——子 Agent A 的输出是子 Agent B 的输入时，必须串行或通过共享状态总线交换，不能让两者各自独立跑完再拼结果，否则会出现”两人对同一问题给出矛盾答案”的死锁。
到这里，Subagent 模式从收益、挑战、类型到边界控制的链路就完整了。
常见问题（FAQ）
Q1：所有任务都该用 Subagent 吗？
不是，依赖少、可并行的复杂任务才适合；轻量问答用单 Agent 更省 token。
Q2：子 Agent 能不能直接改父 Agent 的状态？
不应直接；通过结构化回传 + 控制平面落盘，避免状态被多个子 Agent 并发改写。
Q3：怎么防止子 Agent 跑飞？
设 timeout、max_iterations、工具白名单、关键操作 HITL 四道闸同时上。
