这篇继续围绕 Claude Code 展开，主题是「Claude Code 的子代理怎么理解？把一个任务拆给不同角色」。前面几篇已经讲过安装、settings.json、-p 模式和 CLAUDE.md，这次往真实使用流程里再拆细一点。
子代理到底是什么
看到「子代理（subagents）」这个词，小白容易一脸懵。其实它的含义很朴素：把一个大任务拆给几个不同「身份」的小助手去做，每个小助手都是 Claude Code 的一个实例，但带着不同的指令和权限。
打个比方，你接了一个开发任务，可以请：
- 一个审查者：盯代码质量
- 一个测试员：负责跑测试和补测试
- 一个文档写手：负责写注释和 README
- 一个安全员：留意敏感操作
这就是子代理的基本思路。
为什么不用一个代理搞定
理论上一个 Claude Code 实例什么都能做，但实践中有几个问题：
- 角色混淆：让它「既写代码又审代码」时，它会自己原谅自己
- 上下文太满：把所有任务塞一起，提示词膨胀，关键信息容易被淹没
- 权限粒度粗：写代码需要写文件权限，审代码只需要读，混在一起更危险
拆成多个子代理，每个职责单一、权限单一、上下文干净，整体可靠性会提高。
常见角色和用法
以下角色是社区里讨论比较多的几种，不一定全都适合你的项目，按需挑选。
1. Reviewer（审查者）
职责：拿到 diff，挑毛病。
它的提示词大概是：「你只看 diff，不要改代码。重点关注命名、逻辑漏洞、边界条件、可读性。」
2. Tester（测试员）
职责：跑测试、补测试。
提示词重点：「你只负责测试相关文件。代码逻辑不要改。如果发现实现有问题，标记出来交给主代理。」
3. Doc Writer（文档写手）
职责：写注释、更新 README、补 API 文档。
它的好处是写出来的文档风格统一，不会一会儿正式一会儿口语化。
4. Security Reviewer（安全员）
职责：扫一遍代码里的潜在风险，比如硬编码密钥、SQL 注入风险、未校验输入。它不修问题，只标问题。
5. Researcher（资料员）
职责：去查文档、查 API、查依赖版本，不动代码。
子代理不是越多越好
小白容易掉进的坑是：「那我设 10 个子代理岂不是无敌？」实际并不是。每多一个子代理，都意味着：
- 更多的上下文窗口消耗
- 更复杂的协调成本
- 更多潜在的输出冲突
我个人的建议是：先用一两个子代理跑顺，再增加角色。比如先有一个 reviewer，体会到它的好处再加 tester。
子代理之间怎么协作
一个典型流程：
- 主代理写代码
- tester 子代理跑测试，反馈结果
- reviewer 子代理审 diff，给出建议
- 主代理根据反馈调整
- doc writer 子代理补文档
这个流程不是必须用所有角色，可以按任务大小裁剪。简单任务一个主代理就够，复杂任务再拆。
不要夸大
要诚实说一句：子代理不会让 AI 突然变聪明。它解决的是「角色混淆」和「上下文污染」的问题，而不是模型能力问题。如果你期望加几个子代理就能做出原本做不出来的复杂项目，大概率会失望。
小结
子代理的核心价值是「分工」：让每个角色专心做一件事，提示词更聚焦，权限更可控。先理解角色，再谈架构，这才是 Claude Code 多代理的正确打开方式。
延伸阅读
如果你还没看前面的基础篇，可以先看《Claude Code 从零搭建》《settings.json 权限配置》《CLAUDE.md 项目规则》这几篇，再回来看本文会更顺。
小结
Claude Code 真正好用的地方，不是让它一次性替你完成所有事，而是把流程拆清楚：哪些让 AI 做，哪些必须人来确认，哪些结果要留下验证记录。这个习惯养成之后，它就更像一个靠谱的编程搭档。
