子代理:保护主窗口的关键手段

前面多篇都提到"丢给子代理"——工具爆炸篇用它隔离高噪音输出,模型篇用它做批量降档。本篇讲清楚:子代理到底是什么、怎么用、什么时候不该用。

子代理是什么

子代理(subagent)是主对话临时派生出来的一个独立 Agent 实例:它有自己的上下文窗口、自己的系统提示和工具集,领一个任务、自主执行(可能几十轮工具调用),最后只把一份结论报告交回主对话。

主对话(200K 窗口)
 │  "在整个仓库里找出所有直接读 process.env 的位置,归类汇总"
 ├──────────────► 子代理(独立的 200K 窗口)
 │                  grep × 30 次、read × 20 个文件
 │                  烧掉 8 万 token —— 都在它自己的窗口里
 ◄──────────────┘
 │  收到 500 token 的汇总报告
 ▼
主对话继续,窗口几乎没变大,缓存前缀完好

这就是它的核心价值:探索的成本被隔离,结论的价值被保留。主窗口保持小而稳,还顺带保住了缓存前缀。

Claude Code 里怎么用

内置子代理

不需要任何配置,直接在对话里要求即可("用子代理去……"/"并行开三个子代理分别……"),Claude Code 会通过 Task 工具派生。内置类型各有分工:

类型	特点	适合
Explore	只读,专做大范围搜索,读片段不读全文	"X 功能在哪实现的?""哪些地方调用了 Y?"
Plan	架构视角,产出实施方案	动手前的方案调研
general-purpose	全工具,能读能写	独立的完整子任务

自定义子代理

在 .claude/agents/(项目级)或 ~/.claude/agents/(用户级)放一个 Markdown 文件,即可定义带专属提示词、工具白名单和模型的子代理;用 /agents 命令可交互式创建管理:

---
name: code-reviewer
description: 代码评审专家。改动完成后主动用它评审 diff。
tools: Read, Grep, Glob, Bash
model: sonnet
---

你是严格的代码评审者。只关注:正确性、边界条件、安全问题。
输出格式:按严重程度列出问题,每条附 file:line。

两个字段最值得琢磨:

• model:探索、评审这类批量工作指定 sonnet 甚至 haiku,主对话留在 Opus——这是模型篇"批量降档"的落地方式;
• tools:只给必要的工具。评审代理不需要 Write,只读代理不需要 Bash——既省工具定义的上下文,也是权限收敛(见安全篇)。

并行

子代理可以多个同时跑:"开三个子代理,分别检查 A、B、C 三个模块的类型错误"。互不依赖的任务并行派发,墙钟时间约等于最慢的那一个。更进一步的形态是 agent teams(多个平级 Agent 协作互发消息),适合大型任务的分工,但复杂度也高,先用好普通子代理再说。

什么时候用、什么时候别用

该用:

1. 高噪音探索——全仓搜索、依赖排查、日志翻查,输出大、结论小;
2. 批量独立任务——逐文件迁移、逐模块检查,天然可并行;
3. 需要"另一双眼睛"——评审、验证,子代理没有主对话的思维定势,反而更容易发现问题;
4. 想省钱——探索类子任务降档到 Sonnet/Haiku。

别用:

1. 需要完整对话背景的任务——子代理看不到主对话历史,只有你派发的那段提示。上下文强相关的修改,派发成本(把背景讲清楚)可能高于收益;
2. 一两次调用就能完成的小查询——直接 grep 比派生一个代理更快;
3. 需要来回商量的工作——子代理是"领任务→交报告"的一次性模式,不适合交互式协作。

写好派发提示的三个要点

子代理的产出质量几乎完全取决于任务描述:

1. 自包含:它不知道你们前面聊了什么,把必要背景写进任务里("本项目用 pnpm,测试命令是 pnpm test");
2. 说清产出格式:"返回文件路径列表,每项附一句说明",否则你会收到一篇散文;
3. 限定范围:"只看 src/,忽略测试和生成代码"——范围不清的探索既慢又贵。

与本站其他主题的关系

• 子代理的窗口是独立的,但它的工具定义、系统提示同样吃它自己的上下文——工具爆炸的原则对子代理同样适用;
• 子代理跑完即弃,不产生跨会话记忆——可复用的发现要让它写进文件(如 ARCHITECTURE.md),或沉淀为 Skill;
• 主对话派发子代理的那条消息本身很短,所以派发行为对主窗口缓存几乎无损——这正是"探索外包"的精髓。