用子代理把脏活隔离出去，保住主对话的上下文

让它读四十份访谈稿，然后基于这些写一份发现总结。

问题是：四十份原文全都进了主对话的上下文。等它开始写总结时，上下文已经被原文塞满，而那些原文你之后一眼都不会再看。这正是上下文腐化最典型的触发方式。

子代理（subagent）就是为这个场景设计的。

它解决什么

官方的说法很准确：

当一项副任务会用你之后不会再引用的搜索结果、日志或文件内容淹没你的主对话时，就用一个子代理：它在自己的上下文里做那些工作，只返回摘要。

每个子代理运行在自己独立的上下文窗口里，有自己的系统提示词、指定的工具权限和独立的许可设置。

官方列的几项收益：

• 保住上下文——把探索和执行挡在主对话之外
• 强制约束——限制某个子代理能用哪些工具
• 复用配置——用户级的子代理可跨项目使用
• 专门化行为——为特定领域配聚焦的系统提示词
• 控制成本——把任务路由给更快更便宜的模型（比如 Haiku）

最后一条常被忽略。 「把四十份稿子读一遍并摘出要点」这种活儿，不需要最贵的模型。

怎么配

一个子代理就是一个 Markdown 文件：

---
name: interview-reader
description: 读取指定的访谈转录稿，按项目框架摘出要点。需要批量阅读访谈材料时使用。
tools: Read, Grep, Glob
model: sonnet
---

你是访谈材料的阅读者。对每一份材料：

1. 按 @docs/编码框架.md 的类目摘出要点
2. 每条要点附一句逐字原话，并标注访谈编号
3. 材料里没有依据的写「未涉及」，不要推断

**只返回结构化的要点，不要返回原文。** 主对话不需要看到转录稿本身。

放在哪决定作用范围：

配好之后，主对话里说「用 interview-reader 把 interviews/ 下的材料都读一遍」就行。

最关键的一行

上面那份配置里，真正起作用的是这句：

只返回结构化的要点，不要返回原文。

子代理的价值全在返回什么上。 如果它把读到的内容原样带回来，那和你自己读没有区别——上下文照样被填满，你只是多绕了一圈。

写子代理的提示词时，明确规定返回的形态和篇幅：

返回一张表格，每份材料一行：编号 | 三条要点 | 最有代表性的一句原话。
不要返回完整转录稿，不要返回你的分析过程。

什么时候该用，什么时候不该

该用：

• 要读一批文件，但你只关心结论
• 要在大量材料里做检索，中间过程你不关心
• 同一类活儿反复做，值得固化一个专门的配置

不该用：

• 一次性的、简单的任务——配置成本高于收益
• 你需要看到中间过程的任务——比如你想跟着它一起判断某段话该怎么归类
• 需要来回讨论的任务——子代理是「派出去、拿回来」，不适合对话

官方还有一条重要提醒（见检查点那篇）：子代理做的文件编辑，主会话的检查点回退不到。 要撤销只能靠 Git。所以让子代理只读是更稳的默认——需要它改文件时，先确认目录已纳入版本管理。

用 tools 字段限制权限是最直接的做法：只给 Read, Grep, Glob，它就改不了任何东西。

一个典型的两段式流程

主对话：规划 + 综合
   │
   ├─→ 子代理 A：读 interviews/ 全部材料 → 返回要点表
   │
   ├─→ 子代理 B：读客户历史报告 → 返回背景摘要
   │
   └─→ 主对话拿着两张表写发现章节

主对话从头到尾没有见过任何一份原文，但拿到了写作所需的全部信息。

这就是上下文工程里说的「关注点分离」：详细的检索上下文被隔离在子代理内部，主对话专注于综合与分析。

和 Skill 的区别

两个概念容易混：

可以组合：让子代理在执行时使用某个 Skill。

判断标准：你要的是「让它按某套方法做」→ Skill；你要的是「让它去把这堆东西读完但别把原文带回来」→ 子代理。