跳转到主内容 易典 AI 面向大众的 AI 入门指导平台，让每个人都能轻松用好人工智能。
© 2026 易典 AI. All rights reserved.
湘ICP备2025147101号
文档 Claude Code 完全指南 子智能体：让不同 AI 角色协作完成复杂任务 子智能体：让不同 AI 角色协作完成复杂任务 前八篇我们一直在和"一个 Claude"对话。它读文件、改代码、跑命令，什么都自己干。大多数时候这没问题，但你迟早会遇到一些场景，让你觉得一个 AI 不太够用：
你让它重构一个模块，它改着改着忘了最初的架构设计
你想同时调研三个方案，但它只能串行地一个个来
你需要它既当代码作者又当代码审查者，角色切换来切换去很别扭
Claude Code 的解决方案是子智能体 （Sub-agents）——主会话可以把任务委派给独立的 AI 实例，每个实例有自己的上下文窗口、工具权限和角色定位。
什么是子智能体
简单说：Claude Code 里的主对话可以"召唤"出一个新的 AI 来完成特定任务。这个新 AI 就是子智能体。
打个比方。你是项目经理，一直在和一个全能工程师（主会话的 Claude）讨论项目。突然你需要做一个安全审查，这个工程师可以自己做，但他得暂时放下手头的设计讨论，切换到安全审查的思维模式，做完再切回来。这个过程中，他的"工作记忆"会被安全审查的内容占据，之前讨论的设计细节可能就模糊了。
子智能体的做法不同：工程师叫来一个专门的安全审查员，把相关代码交给他，让他独立完成审查后交回报告。工程师自己继续设计讨论，上下文完全不受干扰。
技术上，子智能体的几个关键特征：
独立的上下文窗口 ：子智能体有自己的对话历史，不会占用主会话的 token独立的工具权限 ：可以限制子智能体只能用特定工具（比如只能读文件，不能写）任务完成后返回结果 ：子智能体把结果交回主会话，自身的上下文随即释放可以并行 ：多个子智能体可以同时工作
为什么需要子智能体 你可能会想：我直接让 Claude 做不就行了，为什么要搞这么复杂？
确实，简单任务完全不需要子智能体。但以下三种情况，子智能体的优势就很明显了。
保护主会话上下文 Claude Code 的上下文窗口是有限的。你和它讨论了一个小时的架构设计，上下文里全是有价值的决策和共识。这时候你说"帮我看看这 20 个文件有没有安全漏洞"——它去逐个读文件、分析代码，这些内容会大量涌入上下文，把之前的架构讨论挤到边缘。
用子智能体做安全审查，主会话只收到一份审查报告，上下文几乎不受影响。
角色专注 一个人同时当作者和审稿人，效果通常不如两个人分别做。AI 也一样。当你让一个 Claude 既写代码又审查自己的代码，它天然倾向于认为自己写的是对的。
把审查交给一个独立的子智能体，它没有"这是我写的"这个心理包袱，审查会更客观。
并行探索 你在做技术选型，想同时评估两个方案。在主会话里只能串行地先研究一个再研究另一个。用子智能体，可以派两个出去同时调研，各自带回报告。
内置的 Agent 工具 Claude Code 内置了一个 Agent 工具，主会话的 Claude 可以通过它来启动子智能体。你不需要手动调用这个工具——只需要用自然语言告诉 Claude 你想委派任务就行。
帮我派一个子智能体去检查 src/ 目录下所有组件的 props 类型定义是否完整
Claude 会自动使用 Agent 工具创建一个子智能体，给它分配任务、设定工具权限，然后等待结果。
subagent 类型 Agent 工具有一个 subagent_type 参数，用来指定子智能体的角色类型：
general-purpose （通用型）——默认类型，拥有完整的工具集，可以读写文件、执行命令。适合大多数需要"动手干活"的任务。
Explore （探索型）——专门用于代码探索和信息收集。通常只有搜索和读取权限，不会修改任何文件。适合"先帮我搞清楚这块代码是怎么回事"这类任务。
Plan （规划型）——用于分析和规划，生成方案但不执行。适合"帮我制定一个重构计划"这类需要深思熟虑但不需要立即动手的任务。
你通常不需要显式指定类型。告诉 Claude 你的意图，它会自动选择合适的类型：
帮我探索一下项目里所有数据库查询的写法，整理一份清单
→ Claude 会选择 Explore 类型
帮我制定一个把 REST API 迁移到 GraphQL 的方案
→ Claude 会选择 Plan 类型
帮我把所有组件里的 class 写法改成 hooks
→ Claude 会选择 general-purpose 类型
自定义 Agent 文件 内置类型足够灵活，但如果你反复需要同一种角色的子智能体，每次都用自然语言描述就显得啰嗦了。Claude Code 允许你在项目里定义自定义 Agent 。
定义方式 在项目根目录创建 .claude/agents/ 目录，放入 .md 文件：
.claude/agents/
├── code-reviewer.md
├── test-writer.md
└── doc-updater.md
文件格式 一个自定义 Agent 文件由 YAML frontmatter 和 Markdown 正文两部分组成：
---
name: "代码审查员"
description: "审查代码变更，检查潜在问题和改进空间"
tools: ["Read", "Glob", "Grep"]
model: "claude-sonnet-4-6"
---
你是一个严格的代码审查员。审查代码时请关注：
1. **逻辑错误**：是否有边界条件遗漏、空值处理缺失
2. **性能问题**：是否有不必要的重复计算、N+1 查询
3. **安全隐患**：是否有 SQL 注入、XSS 风险
4. **可读性**：命名是否清晰、逻辑是否容易理解
5. **一致性**：是否与项目现有风格一致
输出格式：
- 按严重程度分类（错误 / 警告 / 建议）
- 每个问题标注文件路径和行号
- 给出具体的修改建议
Frontmatter 参数说明 参数 说明 示例 nameAgent 的显示名称 "代码审查员"description简短描述，帮助 Claude 判断何时调用 "审查代码变更"tools允许使用的工具列表 ["Read", "Glob", "Grep"]model使用的模型（可选，默认同主会话） "claude-sonnet-4-6"
tools 参数 值得多说几句。通过限制工具，你可以控制 Agent 的行为边界：
只给 Read、Glob、Grep：Agent 只能看，不能改，适合审查和分析
加上 Edit、Write：Agent 可以修改文件
加上 Bash：Agent 可以执行命令，权限最大
工具权限遵循最小权限原则——给 Agent 完成任务所需的最少权限就好。
model 参数 可以帮你省钱。主会话用 Opus 保证复杂推理能力，子智能体的简单任务用 Sonnet 就够了，成本低很多。
实际使用场景
场景一：写代码 + 写测试 + 审查，三线并行 请同时做三件事：
1. 派一个子智能体为刚才的代码写单元测试
2. 派一个子智能体审查代码质量
3. 派一个子智能体更新相关的 API 文档
三个子智能体同时工作，主会话等它们都完成后，汇总结果给你。
场景二：大规模重构前的规划 你想把项目从 Pages Router 迁移到 App Router。直接让 Claude 一边规划一边改，很容易乱。
更好的做法：先派一个 Explore 类型的子智能体去梳理现有路由结构，交回清单。主会话拿着清单做决策，然后再分派具体的迁移任务。
场景三：代码审查 Agent 定义一个 .claude/agents/reviewer.md，以后每次提交前 /reviewer 请审查准备提交的改动，几十秒后收到一份结构化的审查报告。这是我们团队用得最频繁的自定义 Agent。
注意事项 Token 消耗 ：子智能体有自己的上下文窗口，消耗的 token 是额外的。太小的任务不值得启动子智能体。
上下文隔离是双刃剑 ：子智能体看不到主会话之前的讨论。委派任务时要把必要的上下文写在任务描述里——比如"使用 Zod 做验证"这类之前达成的共识。
什么时候不该用 ：简单的单文件修改、需要频繁交互的任务、高度依赖对话历史的任务——这些直接在主会话做更好。
一个判断标准 ：问自己"这个任务我能写成一段清晰的任务说明书吗？"如果能，就适合委派。如果你自己都说不清楚要什么，先在主会话里讨论清楚再说。
下一篇讲 Hooks——让 Claude Code 在特定事件触发时自动执行操作，比如编辑文件后自动格式化、提交前自动检查。
本篇要点：
子智能体是独立的 AI 实例，有自己的上下文和工具权限
用自然语言告诉 Claude 委派任务，它会自动使用 Agent 工具
自定义 Agent 文件放在 .claude/agents/ 目录，可以固化常用角色
核心价值：保护主会话上下文、角色专注、并行探索
委派时把必要上下文写在任务描述里，避免子智能体"两眼一抹黑"
