产物二·子代理：给脏活单独开一个上下文

6.1 为什么调查工作会拖垮主上下文

发布说明需要原料。上一章我们用 git log 灌了提交列表，但真实的发布往往要更深的调查：这些提交里哪些是用户可感知的？哪个 PR 引入了破坏性变更？为此模型可能要翻十几个文件、读一串 PR 描述。

问题是，这些中间材料会全部堆进你的主对话。你要的只是最后那份分好类的摘要，却为此在上下文里塞了几千行它读过的原文。聊得越久越慢、越容易犯糊涂，很多时候就是这么来的。

子代理解决的正是这件事：把调查搬到一个独立的上下文里去做，只把结论交回来。

6.2 写一个只读的 release-scanner

子代理是 .claude/agents/ 下的一个 Markdown 文件，格式和技能很像：YAML frontmatter + 正文系统提示。建 .claude/agents/release-scanner.md：

---
name: release-scanner
description: 在提交历史和 PR 里做只读调查，返回按类别分好的发布条目摘要。当需要梳理"上个版本到现在有哪些面向用户的变化"时委派给它。
tools: Read, Grep, Glob, Bash(git log *), Bash(git diff *)
model: haiku
---

你负责为发布说明做原料调查，只做调查，不写最终文案。

规则：
- 只读，绝不修改任何文件
- 翻查上个 tag 到 HEAD 的提交与相关文件
- 把发现按"新增 / 修复 / 破坏性变更"分类
- 每条给一句话摘要 + 对应的提交哈希，方便核对
- 纯内部重构、依赖升级不要列进来
- 返回的就是这份分类摘要，不要把读过的文件原文贴回来

6.3 用 tools 和 model 把它收窄

这个文件里有三个决定它性格的字段：

• tools：只给只读工具（Read、Grep、Glob 和只读的 git 命令）。这是从机制上保证它不会改东西——不给写工具，它就没法写。比正文里写一句”请不要修改文件”可靠得多。
• model: haiku：这类机械翻查不需要最强的模型。指定一个更便宜快速的模型，省钱也省时间。可选值有 haiku、sonnet、opus、fable，还有 inherit（跟主对话用同一个）。
• description：和技能一样，它决定这个子代理会不会被自动委派。写清”什么情况下把活交给它”。

其他可选字段里，permissionMode、disallowedTools、skills（预加载技能）等也常用到，起步阶段这三个字段足够。

6.4 它怎么被叫起来：自动委派与显式点名

子代理有两种触发方式：

• 自动委派：模型读到你的请求，觉得和某个子代理的 description 匹配，就把这段活交给它。所以 description 依然是关键。
• 显式点名：你直接说”让 release-scanner 去梳理一下这个版本的变化”，或者用 @ 从候选里选它。

有一点值得记住：所有子代理的 description 合起来有大约 15000 token 的预算。因为这些描述在启动时就要进上下文，供模型随时决定委派。所以描述要短，把复杂的说明放进正文系统提示里——正文只在子代理真正运行时才加载。

创建子代理不需要专门的命令，直接让 Claude 帮你写这个文件也行：告诉它”在 .claude/agents/ 建一个只读的 release-scanner，用 haiku，返回分类摘要”，它会带着正确的 frontmatter 写好。