在实际工作和开发中经常会遇到这种情况，输出很多日志执行结果，有测试的、有执行的、有思考的。这些如果是小项目虽然看着很清楚，感觉很有掌控感，但是如果是大项目，我们操作的过程很多，真正重要的信息被淹没在茫茫输出海洋里。也就是说他们对“当下执行”是必要的，但对“后续决策”是噪声。
在实际工作中，你也会觉的Claude Code 越来越不好用，并不是模型退化了，而是你的对话上下文，已经被一次次中间过程污染了。
这就是子代理要解决的问题：把“高噪声的执行过程”隔离出去， 只让真正有价值的结论，留在主对话中。 子代理，通过上下文隔离，让专业的Agent做专业的事，不是为了让Claude做得更多，而是为了让Claude记得更少，但记得对。
子代理相当于一个“专职小助手”，带着自己的规则、工具权限、上下文窗口，去完成某一类任务，然后把“结果摘要”带回来。主Agent和sub-Agent的关系是什么？可以理解为老板和员工的关系。
并不是所有任务都值得动用子代理。子代理的价值，不在于“能不能用”，而在于“该不该用”。一个最直观的判断标准是：主对话到底需不需要承载执行过程本身。
高噪声输出任务 执行过程中会产生大量中间信息，但主对话真正关心的只是一个结论。例如跑测试，一次输出几百行日志，只关心是否成功。
角色边界非常明确的任务 有些事情，你只希望 Claude “看”，而不希望它“做”；有些操作，只能在特定目录、特定范围内发生。 例如：分析项目优化点，但不做修改。
可以并行展开的研究型任务 数据库设计、API、前端、后端可以同时进行，用子代理各自完成，再汇总结果。上下文更干净，还能并行加速。
可以拆成清晰阶段的流水线任务 定位 → 审查 → 修改 → 测试。用子代理固定每一步责任，避免不同阶段信息互相污染。
项目很小的时候没必要用，例如个人博客、毕设图书管理系统，或与主线高度关联的任务。
子代理不能嵌套调用子代理。
所有调用必须由主对话完成。
如果子代理需要技能/知识，用 skill 字段预加载，不要嵌套。
对于项目级 （当前项目可用）的子代理存放位置如下：需要先建立一个 .claude 文件夹，然后在这个文件夹下面继续建立一个agents文件夹，在agents文件夹下就添加你的Sub-Agent了。
在这里新建一个代码审查的子代理，起名为code-reviewer.md。
具体位置如下：
your-project/
└── .claude/
└── agents/
└── code-reviewer.md
你现在对于子代理的概念和用途有了清晰的了解。编写一个子代理，只要使用Markdown+Frontmatter格式 就可以了。那下面我们就看看如何创建一个子代理。如果你用过Hexo这样的博客系统，就很容易理解这种格式。
---
name: code-reviewer
description: Review code for security issues and best practices. Use after code changes.
tools: Read, Grep, Glob #工具权限的说明
model: qwen3.5-plus
---
你是一个代码审查专家。
当被调用时：
1. 首先理解代码变更的范围
2. 检查安全问题
3. 检查代码规范
4. 提供改进建议
输出格式：
## 审查结果
- 安全问题：[列表]
- 规范问题：[列表]
- 建议：[列表]
工具权限应遵循最小权限原则——只开放必要的工具，能用 Read 完成的任务，就不要给 Edit。以下是根据用途划分的典型工具组合：
只读型（审计/检查） 研究型（信息收集） 开发型（读写改）
├── Read ├── Read ├── Read
├── Grep ├── Grep ├── Write
└── Glob ├── Glob ├── Edit
├── WebFetch ├── Bash
└── WebSearch ├── Glob
└── Grep
使用方法很简单，只要在主对话中输入
用 code-reviewer 子代理审查首页模块