07 · 派助手去干活
翔宇第一次用 SubAgents 的时候，脑子里想的是「一个 Claude 变三个，效率翻三倍」。用了几次之后发现，并行确实快了一点，但真正让翔宇离不开它的原因
翔宇第一次用 SubAgents 的时候，脑子里想的是「一个 Claude 变三个，效率翻三倍」。用了几次之后发现，并行确实快了一点，但真正让翔宇离不开它的原因完全不是速度——是主对话不再被搞乱了。这个认知差异拆透之后，什么时候该用、什么时候不该用就变得清晰了。——翔宇
要点速览
- 你将理解 SubAgents 的核心价值不是「多了几个 Claude」，而是「多了几张独立的桌子」——上下文隔离
- 你将理解为什么子代理返回的是「结论」而不是「过程」，以及这个设计解决了什么问题
- 你将理解三个内置类型（Explore / Plan / General-purpose）和专业类型的各自定位
- 你将理解自定义子代理的配置方式——和 Skills 一样，是一个 Markdown 文件
1. 一个具体的场景
你在和 Claude Code 讨论一个认证模块的重构方案。讨论了十几轮，上下文里积累了大量关于认证逻辑、JWT 流程、中间件设计的信息。桌子上摆得整整齐齐。
这时候你突然想起来：「对了，先帮我查一下项目里有没有用到 Redis。」
Claude 去搜索了整个代码库，读了七八个文件，输出了一大段关于 Redis 使用情况的分析。
你回到认证模块的讨论，发现 Claude 的回答质量下降了——它开始在认证的回答里混入 Redis 的信息，有时候回答得不太连贯。
发生了什么？
回到第 2 篇的概念：上下文窗口是一张桌子。你之前桌子上整整齐齐摆着认证模块的资料。然后 Redis 的搜索把七八个文件的内容、搜索结果、分析过程全摊到了同一张桌子上。认证和 Redis 的资料混在一起，Claude 每次回答都要从混杂的信息里筛选。
更糟糕的是：那个 Redis 的搜索你只需要一个「有/没有」的答案——但它的中间过程占了桌子上一大块空间。
你付出了上下文空间，换来了一个简单的答案。性价比极差。
2. 如果有另一张桌子
现在换一种方式。
你和 Claude 讨论认证模块。当你说「帮我查一下项目里有没有用到 Redis」，Claude 没有自己去查——它派了一个「助手」去查。
这个助手有自己的一张桌子。它在自己的桌子上打开文件、搜索关键词、做分析。完成后，它把结论带回来——「项目中有 3 处使用了 Redis：缓存层、会话存储、消息队列」——就这一句话。
你的桌子上多了这一句结论。搜索过程——读了哪些文件、每个文件的内容——全留在了助手自己的桌子上。
你的认证讨论完好无损。
这就是 SubAgents 做的事。
🎯 一句话理解 SubAgents 的核心价值是「多了一张独立的桌子」——上下文隔离。子任务的中间过程不污染你的主对话。
3. 「并行」是附赠品，不是核心
这里需要纠正一个常见的理解偏差。
很多人第一反应是：SubAgents 的价值是并行——派三个人同时干三件事，快三倍。这个理解不能说错，但它抓的是次要矛盾。
想一想：如果并行是核心价值，那为什么不直接在主对话里开三个线程？为什么非要是独立的「子代理」？
🔑 关键点 因为独立的子代理有独立的上下文。三个线程共享同一张桌子，它们的搜索过程、读过的文件、分析的中间产物全都堆在你的桌子上——并行了，但桌子更乱了。三个子代理各有各的桌子，它们只把结论带回来，你的桌子几乎不受影响。
并行确实让速度变快了。但隔离才是让质量不下降的原因。
如果你只看到「快」，你会在不需要并行的场景里也用 SubAgents——浪费成本。如果你看到「隔离」，你就知道：只要子任务的中间过程会污染主对话，就值得用 SubAgent，哪怕只派一个。
4. 返回结论而不是过程
子代理完成任务后，返回给主对话的是一个精炼的摘要，不是全部工作过程。
这个设计值得停下来想一想。
如果子代理把所有读过的文件、所有分析过程都带回来，就等于把它桌子上的东西全倒到你桌子上——那和没有子代理有什么区别？
所以它只带回结论。就像你派一个人去图书馆查资料，你不需要他把图书馆搬回来——你只需要他回来说「关于这个问题，结论是 XYZ」。
这个设计的深层逻辑是信息压缩。子代理在自己的上下文里做了大量展开工作（读文件、搜索、分析），然后把结果压缩成摘要返回。主对话获得了子代理的工作成果，但只付出了极少的上下文空间。
当然也有代价——你看不到完整推理过程。如果结论有误，追溯困难。但在大多数场景下，这个权衡是值得的。
⚡ 速记 子代理适合两个条件都满足的场景：（1）任务的中间过程会显著污染主对话（2）你只需要结论而不需要完整过程。两个都不满足时，直接在主对话里做更高效。
5. 三个内置的通用类型
Claude Code 内置了三个通用子代理类型。它们的能力来自同一个 Claude，区别在于权限和模型的配置不同。
Explore——侦察兵
只读权限，只能看不能改。用 Haiku 模型——最快最便宜。
用来快速搜索代码库、查找文件、了解项目结构。你想知道「项目里哪些地方用了 Redis」「这个函数在哪些文件里被调用了」——纯粹的信息收集，不需要修改任何东西。
Plan——参谋
同样只读权限，但用 Sonnet 模型，推理能力更强。定位不是简单搜索，而是分析和规划。
当你让 Claude 先规划再执行时，它会自动调用 Plan 子代理去研究代码库——看目录结构、读关键文件、分析依赖关系——然后把调研结果带回来，作为制定计划的依据。
Explore 是「帮我找到 X」，Plan 是「帮我理解 X 的全貌然后给出建议」。
General-purpose——全能手
全部工具权限（读、写、执行命令），用 Sonnet 模型。适合需要实际动手的子任务——比如「修复这个模块的 Bug」「给这个文件写单元测试」。
🎨 打个比方 Explore 是图书管理员——帮你找书。Plan 是研究员——帮你读书并写摘要。General-purpose 是工程师——根据书里的方案把东西造出来。三个角色不是能力高低之分，是分工不同。
6. 专业子代理
除了三个通用类型，还有几种内置的专业子代理。
code-reviewer——代码审查专家。全部工具权限，系统提示里写了代码质量、安全性和最佳实践的检查清单。
bug-analyzer——Bug 分析专家。读写权限加 Bash，系统提示里写了调试方法论和根因分析框架。
ui-sketcher——UI 设计辅助。能生成 ASCII 原型和交互规格。
这些专业类型和通用类型的底层都是同一个 Claude。区别在于系统提示的侧重点不同——code-reviewer 被注入了审查方法论，bug-analyzer 被注入了调试框架。
这和上一篇讲的 Skills 是同一个逻辑——不是新能力，是方法论的注入。只不过 Skills 注入到主对话的上下文，子代理是在独立的上下文里带着方法论工作。
7. 自动派遣
大多数时候你不需要指定「用哪个子代理」——Claude 自己判断。
判断依据是你的请求和子代理 description 字段的匹配。你说「帮我查一下项目里有没有用到 Redis」，Claude 发现 Explore 的描述最匹配；你说「审查一下我刚写的代码」，它匹配到 code-reviewer。
但自动匹配不是万能的。如果你说「看看这段代码」，它可能派 Explore（浏览）而不是 code-reviewer（深度审查）。想要精准触发，把意图说具体：「从安全性和性能的角度审查这段代码」——Claude 更可能派出 code-reviewer。
你也可以直接指定：「让 code-reviewer 来看看。」
8. 自定义子代理
内置的不够用，可以创建自己的。
自定义子代理是一个 Markdown 文件，放在 .claude/agents/（项目级）或 ~/.claude/agents/（用户级）目录下。结构和 Skills 几乎一样——文件开头是 YAML 元数据，后面是指导方针。
元数据里的关键字段：
name——标识符。
description——Claude 据此判断什么时候派这个子代理。写法和 Skills 的 description 一样，要具体，要包含触发术语。
tools——可选，指定能用哪些工具。省略则继承所有工具。
model——可选，指定用哪个模型。
元数据之后的 Markdown 内容就是这个子代理的系统提示——角色定义、工作流程、输出格式要求。
💬 通俗讲 Skills 像给你自己贴了一张便签——你看到便签就知道该怎么做。子代理像你招了一个新员工，给他一份入职手册——他在自己的工位上按手册工作，完成后把结果交给你。便签改变你自己的行为，员工在独立空间里工作。
9. 编排模式——多个子代理怎么配合
一个子代理解决一个子任务。多个子代理可以组合出更复杂的模式。
扇出模式
同时派出多个子代理，各自独立工作，结果汇总。
场景：你要了解一个陌生项目。同时派三个 Explore——一个查 API 相关代码，一个查数据库相关代码，一个查认证相关代码。并行工作，结果汇总后你就有了项目的全貌。比串行快很多，而且各自的搜索过程不互相污染。
流水线模式
一个子代理的输出是下一个的输入。
场景：重构一个模块。第一个子代理分析现有代码结构 → 第二个基于分析设计重构方案 → 第三个执行重构 → 第四个跑测试验证。每一步在独立上下文里完成，结论传递给下一步。
专家咨询模式
根据问题类型自动路由到对应的专家子代理。
遇到代码质量问题 → code-reviewer。遇到 Bug → bug-analyzer。需要快速查代码 → Explore。Claude 自动判断该找谁。
10. 子代理的代价
每个子代理是一次独立的 AI 调用。这意味着三件事：
成本——每个子代理都消耗 token。派三个，成本约三倍。
延迟——子代理需要时间完成工作。虽然可以并行，但每个本身还是需要读文件、分析、生成结论。
信息损耗——返回的是压缩后的摘要，不是全部过程。如果摘要遗漏了关键信息，需要追问或重新派人查。
所以不是所有任务都适合用子代理。简单的一步就能完成的事——改个变量名、回答一个简单问题——直接在主对话里做就好。
🔍 深入一步 判断要不要用子代理有个简单标准：这个任务的中间过程（读了哪些文件、搜了什么关键词、每步的分析）你需要看吗？不需要 → 用子代理，只要结论。需要 → 在主对话里做，保留完整过程。
11. 和 Agent Teams 的区别——提前预告
SubAgents 是主从关系——主对话派子代理去干活，子代理做完回来汇报。子代理之间互相不知道对方的存在，也不能直接沟通。它们只和主对话沟通。
下一篇要讲的 Agent Teams 是协作关系——多个 Claude 实例有共享的任务列表，可以互相发消息、互相协调。
SubAgents 像你派了三个人去三个图书馆查资料，各查各的，查完各自回来告诉你。Agent Teams 像你组建了一个项目组，三个人坐在同一间办公室，看同一块白板，遇到问题直接沟通。
什么时候用哪个？下一篇展开。这里先记一条原则：能用 SubAgents 解决的，不用 Agent Teams。 因为 Agent Teams 的每个成员是一个完整的 Claude 实例，成本高得多。
12. 自检问题
这篇拆了一个概念：SubAgents 的核心价值是上下文隔离，不是并行处理。
费曼检验时间：
- 有人说「SubAgents 就是让 AI 同时做多件事」。这个理解遗漏了什么关键点？
- 为什么子代理返回的是「摘要」而不是「全部过程」？如果返回全部过程，会出什么问题？
- Explore、Plan、General-purpose 三种内置子代理，你能用一个具体场景说明它们各自适合干什么吗？
- SubAgents 和 Skills 都是「给 Claude 注入方法论的 Markdown 文件」。它们的核心区别是什么？