如何以及何时在 Claude Code 中使用 子Agent

Claude Code 子Agent 实用指南：它们什么时候有帮助、如何指派它们，以及哪些信号说明值得把任务委托出去。

Claude Code 很擅长处理复杂的多步骤项目，但长会话会不断积累负担。每次读取文件、每次探索支线、每个写到一半的想法，都会留在 上下文窗口 里，让响应变慢，也推高 token 成本。

想象一下，在一个大型 TypeScript monorepo 里构建一个新功能。主要工作是实现功能，但旁支任务会不断冒出来：追踪现有 service 如何处理 auth，找到用于日期格式化的共享 util，检查 design system 里是否已经有接近需求的 component。这些任务都不需要完整的项目上下文，而且放在主会话里执行只会增加噪音。要是可以并行运行它们呢？

这就是 子Agent 的用武之地。子Agent 是一个隔离的 Claude 实例，拥有自己的 上下文窗口。它接收任务、完成工作，然后只返回结果。你可以把 子Agent 理解成 Claude Code 会话里的浏览器标签页：可以用来追一条支线，而不丢掉主线。

在本文中，我们会讨论什么时候适合使用 子Agent、如何调用它们，以及什么时候它们带来的开销并不值得。

什么是 子Agent？

子Agent 是自包含的 Agent，它们使用自己的 上下文窗口s 运行。当 Claude 生成一个 子Agent 时，这个 assistant 会独立读取文件、探索代码或进行修改。完成任务后，子Agent 只把相关结果返回给主对话。

每个 子Agent 都从全新状态开始，不会背负对话历史或已调用 skills 的负担。多个 子Agent 可以并行运行，而且每个都可以拥有不同权限：研究型 子Agent 可能只有只读访问权限，而实现型 子Agent 可以拥有完整编辑能力。

Claude Code 内置了几种 子Agent 类型，包括：

• 用于复杂多步骤任务的通用 Agent

• 在给出实现策略之前研究 代码库 的 plan Agent

• 为快速只读代码搜索优化的 explore Agent

Claude Code 经常会自行生成 子Agent 来处理分配的任务。你也可以显式引导这种行为，并定义可复用的专家角色，让 Claude 自动委托给它们。知道什么时候该使用 子Agent，才是这个功能真正有用的关键。

什么时候应该使用 子Agent？

有几类工作明显适合委托给 子Agent。学会识别它们，会让这个功能有效得多。

研究密集型任务

当理解某个东西的工作方式是修改它的前提时，子Agent 可以探索 代码库 并返回总结，而不是把几十个文件都塞进对话里。

信号：收集上下文需要阅读几十个文件。

收益：主对话保持干净，返回的是综合后的发现，而不是原始内容。

多个独立任务

当你需要修复多个文件里的错误、更新多个 components 中的模式，或者进行彼此不依赖的修改时，并行 子Agent 可以更快完成任务。

信号：子任务之间没有依赖关系。

收益：三个 子Agent 同时工作，通常能在更短时间内完成任务。

需要新视角

当目标是对实现进行不带偏见的 审查 时，子Agent 能提供一个干净起点，因为它不会继承主对话里的假设、上下文或盲点。

信号：需要在不受对话历史影响的情况下进行验证。

收益：反馈更干净、更客观。

专业提示：/clear 命令也会重置上下文和对话历史，提供类似的无偏起点，但代价是完全丢失这些历史。子Agent 可以获得同样的新视角，同时保留主对话。

提交前验证

在最终确定修改之前，可以让一个独立 子Agent 验证实现是否过度迎合测试，或者是否遗漏边界情况。

信号：提交代码前值得听取第二意见。

收益：能发现因为太熟悉代码而容易忽略的问题。

流水线式工作流

当任务有明确阶段时，例如先设计、再实现、再测试，每个阶段都适合专注处理。

信号：顺序阶段清晰，并且交接边界明确。

收益：每个 子Agent 专注于自己的阶段，不会被其他阶段的上下文干扰。

专业提示：当一个任务需要探索十个或更多文件，或者包含三个或更多独立工作项时，这是一个强信号，说明应该引导 Claude 使用 子Agent。

如何引导 子Agent 的使用

调用 子Agent 有几种方法，从简单对话到自动化工作流都有。合适的起点取决于工作流本身，随着模式逐渐清晰，可以再叠加更复杂的用法。

对话式调用

最灵活的方法，就是在对话里直接请 Claude 使用 子Agent。这适用于所有 Claude Code 界面：terminal、VS Code、JetBrains、web 和 desktop applications。

以下自然语言模式通常能稳定触发 子Agent：

• "Use a 子Agent to explore how authentication works in this 代码库"

• "Have a separate Agent 审查 this code for security issues"

• "Research this in parallel. Check the API routes, database models, and frontend components simultaneously"

• "Spin up 子Agent to fix these TypeScript errors across the different packages"

明确表达很重要。指定范围，在任务彼此独立时要求并行执行，并描述你想要的输出。

下面是一个有效的 提示词 结构：

使用 子Agent 并行探索这个 代码库：1. 找出所有 API endpoints 并总结它们的用途 2. 识别 database schema 和关系 3. 梳理 authentication flow 返回每一项的总结，不要返回完整文件内容。

这个 提示词 有效，是因为它清楚定义了三个独立任务，明确要求并行执行，并指定了输出格式。Claude 能理解意图，并生成合适的 子Agent。

有效进行对话式调用的建议包括：

• 清楚限定任务范围。"Explore how payments work" 比 "explore everything." 更好。

• 明确要求并行化。可以说 "these can run in parallel" 或 "work on all three simultaneously."

• 指定应该返回什么。可以是总结、具体发现或建议。说清楚输出格式有助于 Claude 给出符合预期的结果。

• 当需要无偏分析时，要求使用全新上下文。"Use a 子Agent that does not see our previous discussion" 可以确保评估更干净。

专业提示：当 子Agent 运行时间较长时，Ctrl+B 可以把它送到后台。你可以继续对话，结果会在完成后自动浮现。/tasks 命令会显示所有正在后台运行的任务。

自定义 子Agent

当你反复请求同一种 子Agent，比如 security 审查er、test writer、docs proofreader，就可以把它定义成一次性的 custom 子Agent。

之后只要任务匹配它的描述，Claude 就会自动委托给它，不需要额外提示。

Custom 子Agent 以 markdown 文件形式存放在 .claude/Agent/（项目级，与团队共享）或 ~/.claude/Agent/（用户级，跨项目可用）。每个 子Agent 都有自己的 system 提示词、tool permissions，并且可选地拥有自己的 model。

最简单的创建方式是使用 /Agent 命令，它会通过交互式流程引导设置，并可以根据描述生成第一版草稿。你也可以手写这个文件，例如：

--- name: security-审查er description: 审查代码修改中的安全漏洞、注入风险、auth 问题和敏感数据暴露。用于在提交涉及 auth、payments 或 user data 的代码之前主动检查。 tools: Read, Grep, Glob model: sonnet --- 你是一个关注安全的 code 审查er。请分析提供的修改，检查：- SQL injection、XSS 和 command injection 风险 - Authentication 和 authorization 缺口 - logs、errors 或 responses 中的敏感数据 - 不安全的 dependencies 或 configurations 返回按优先级排序的 findings 列表，每项包含 file:line 引用和建议修复方式。要严格审查。如果没有发现问题，请明确说明，不要编造问题。

有了这个配置后，Claude 会自动把匹配的工作路由给该 子Agent。也可以按名称调用："Have the security-审查er look at the staged changes."

Custom 子Agent 最适合以下情况：

• 希望 Claude 在任务匹配时自动委托给某个专家

• 这项工作受益于范围很窄的 system 提示词 和受限 tools

• 该配置需要在团队内共享，或跨项目复用

专业提示：description 字段是 Claude 用来决定何时委托的依据。要具体说明触发条件，而不只是能力。"审查s code for security issues before commits" 比 "security expert." 更容易正确路由。

完整配置参考，包括 permission modes 以及 project 和 user 子Agent 如何交互，请参阅我们的 Claude Code 子Agent docs。

CLAUDE.md 指令

Custom 子Agent 定义专家是谁。CLAUDE.md 文件定义 Claude 什么时候应该使用它们。如果每次 code 审查 都应该通过只读 子Agent，或者每个 architecture 问题都应该先触发研究流程，那么 CLAUDE.md 就是放置这类策略的地方。Claude 会在每次对话开始时读取它，因此跨会话、跨队友的行为都能保持一致，不需要任何人记得主动要求。

以下情况适合在 CLAUDE.md 中写 子Agent 指令：

• Code 审查s 应该总是使用只读 子Agent

• 项目有 Claude 应该遵循的特定研究模式

• 需要在团队成员和会话之间保持一致行为

下面是一个简单 CLAUDE.md 文件示例，会在特定条件下触发 子Agent：

## Code 审查 standards 当被要求 审查 code 时，ALWAYS 使用具有 READ-ONLY access 的 子Agent（仅 Glob、Grep、Read）。审查 应 ALWAYS 检查：- Security vulnerabilities - Performance issues - 是否遵循 /docs/architecture.md 中的项目模式 返回 findings 时使用按优先级排序的列表，并带 file:line 引用。

使用上面的 CLAUDE.md 文件后，每次 code 审查 请求都会自动采用定义好的模式，不再需要每次重复指定。

关于 CLAUDE.md 文件的更多内容，请参阅 Customizing Claude Code for your 代码库: setting up a CLAUDE.md file 以及我们的 Claude Code CLAUDE.md file docs。

Skills

对于会重复运行的复杂多步骤工作流，skills 提供了可复用接口。你可以在 .claude/skills/ 中定义一次 skill，然后用 /skill-name 调用它，或者让 Claude 在任务匹配其 description 时自动加载它。

Skills 和 CLAUDE.md 文件的区别在于作用范围。CLAUDE.md 文件总是被加载，并影响每次交互。skill 则按需加载，要么因为被显式调用，要么因为 Claude 将当前任务匹配到了该 skill 的 description 字段。因此，skills 适合放那些应该可用、但不应该应用到每个 提示词 的工作流。

Skills 适合以下情况：

• 某些动作会经常运行

• 不同团队成员需要访问同一个复杂操作

• 需要在团队内标准化某些任务的执行方式

下面是一个用于全面 code 审查 的 deep-审查 skill 示例：

# .claude/skills/deep-审查/SKILL.md --- name: deep-审查 description: 全面的 code 审查，会并行检查 security、performance 和 style。用于在 commit 或 PR 前 审查 staged changes。--- 对 staged changes 运行三个并行 子Agent 审查s：1. Security 审查 - 检查 vulnerabilities、injection risks、authentication issues 和 sensitive data exposure 2. Performance 审查 - 检查 N+1 queries、不必要的 iterations、memory leaks 和 blocking operations 3. Style 审查 - 检查是否与 /docs/style-guide.md 中记录的项目模式一致 将 findings 综合成一个 summary，并按优先级排序问题。每个问题都应包含 file、line number 和 recommended fix。

在上面的代码片段中，/deep-审查 会按需触发一个三部分的 子Agent 分析。因为 description 提到了在 commits 前 审查 staged changes，当出现这种上下文时，Claude 也可以自动使用这个 skill。

skill 是一个目录，不是单个文件。除了 SKILL.md，它还可以包含 Claude 要填充的 templates、展示预期格式的 example outputs，或 Claude 作为工作流一部分执行的 scripts。旧版 .claude/commands/ 格式是单个扁平文件，所以所有内容都必须写在 提示词 本身里。

关于在 Claude Code 中使用 skills 的更多内容，请参阅我们的 Claude Code skills docs。

Hooks

Hooks 是用户定义的 shell commands、HTTP endpoints 或 LLM 提示词s，会在 Claude Code 生命周期的特定节点自动执行。Hooks 可以根据事件自动化 子Agent workflows。Hooks 会在特定动作上触发，并在无需手动调用的情况下运行 子Agent tasks。

以下情况适合使用 hooks：

• 每次 commit 创建前都应该自动 审查

• Security checks 应该自动运行，不依赖任何人记得提出要求

• 类似 CI 的质量门禁应该属于本地开发流程的一部分

下面是一个 Stop hook 示例，它会阻止 Claude 结束当前回合，直到测试通过：

{ "hooks" : { "Stop" : [ { "hooks" : [ { "type" : "command" , "command" : "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/check-tests.sh" } ] } ] } }

以及 .claude/hooks/check-tests.sh 中的脚本：

#!/bin/bash INPUT=$(cat) STOP_HOOK_ACTIVE=$( echo " $INPUT " | jq -r '.stop_hook_active // false' ) # 不要无限循环：如果这一轮已经拦截过一次，就放行 if [ " $STOP_HOOK_ACTIVE " = "true" ]; then exit 0 fi if ! npm test --silent > /dev/null 2>&1; then jq -n '{ decision: "block", reason: "测试失败。请运行 `npm test` 查看失败原因，并在结束前修复它们。" }' exit 0 fi exit 0

当 Claude 结束它的回合时，会触发 Stop 事件。脚本会运行测试套件；如果测试失败，它会返回包含 decision: "block" 和 reason 的 JSON。Claude Code 读取到这个结果后，不会让 Claude 停下来，而是把这个 reason 作为继续工作的指令反馈到对话中。开头的 stop_hook_active 保护逻辑用于防止无限循环：如果 Claude 已经是因为之前的 stop-hook 拦截而继续运行，脚本就会允许它退出。

Hooks 是最自动化的 子Agent 编排方式。更适合作为起点的是对话式调用或 CLAUDE.md 指令；hooks 通常应该在工作流成熟之后再引入。

完整的 hooks 配置，请参阅 Claude Code 高级用户自定义：如何配置 hooks，或我们的 Claude Code hooks 文档。

使用 子Agent 的实用模式

下面这些模式展示了如何把 子Agent 指派应用到常见场景中。

实现前先研究

在不熟悉的代码中添加功能时，先把研究工作委托给 子Agent，可以让后续实现讨论建立在已知信息上，而不是一边探索一边讨论，例如：

在我实现用户通知之前，先用一个 子Agent 研究：- 这个代码库目前是如何发送邮件的？- 已经有哪些通知相关模式？- 按照当前架构，新的通知逻辑应该放在哪里？总结研究结果，然后我们再一起规划实现。

你收到的是一份综合总结，而不是二十个文件的原始上下文；实现讨论也能从扎实的基础开始。

并行修改

当同一种模式需要在多个文件中更新时，并行 子Agent 可以更快完成，并保持各自的关注点，例如：

使用并行 子Agent 更新这些文件中的错误处理：- src/api/users.ts - src/api/orders.ts - src/api/products.ts 每个都应该遵循 src/api/auth.ts 中已经建立的模式。三个文件同时处理。

三个 子Agent 并行工作，完成时间大致相当于一个 子Agent 处理一个文件所需的时间。每个 子Agent 都专注于自己的文件，不会因为其他文件的上下文而产生混乱或不一致。

独立审查

在实现复杂内容之后，让一个没有受实现过程影响的 子Agent 来验证，可以发现熟悉感掩盖的问题，例如：

使用一个新的 子Agent，以只读权限审查我对支付流程的实现。它不应该看到我们之前的讨论。我想要一份不带偏见的审查。检查：安全漏洞、未处理的边界情况，以及错误处理缺口。请严格一些。

审查 子Agent 会在不了解曾考虑过哪些权衡、拒绝过哪些方案、做过哪些假设的情况下评估代码。这种外部视角能暴露主对话可能漏掉的问题。

流水线工作流

对于多阶段任务，把 子Agent 串联起来，并在阶段之间设置明确交接，可以让每个阶段保持专注，例如：

我们把这个功能按流水线来做：1. 第一个 子Agent：设计 API 契约，并写入 docs/api-spec.md 2. 第二个 子Agent：根据该规范实现后端端点 3. 第三个 子Agent：为实现编写集成测试 每个阶段完成后，下一个阶段才能开始。使用输出文件作为阶段之间的交接机制。

使用流水线工作流时，任务中的每个阶段都会获得聚焦的上下文。设计 子Agent 不会被实现细节干扰，实现 子Agent 基于干净的规范工作，测试 子Agent 则独立评估结果。

什么时候不应该使用 子Agent？

虽然 子Agent 是一个有用功能，但它也有开销。每个 子Agent 都会启动自己的上下文，消耗 tokens，并在开发者和工作之间增加一层间接关系。只有当上下文隔离、并行处理或新鲜视角确实有帮助时，这些成本才值得。

对于较小的任务，或步骤紧密串行的任务，通常留在主对话中会更简单，例如：

• 顺序依赖的工作。如果第二步需要第一步的完整输出，第三步又需要前两步的结果，那么用一个会话处理整条链路，通常比让多个 子Agent 通过文件传递状态更清晰。

• 同文件编辑。让两个 子Agent 并行编辑同一个文件，很容易产生冲突。在这种场景下，应该把紧密相关的修改放在同一个上下文窗口中完成。

• 小任务。对于快速修复或聚焦问题，委托带来的开销会超过收益。直接在主对话中提示或提问即可。

• 过多的专家 Agent。为每件事都定义一个自定义 子Agent 很有诱惑力，但给 Claude 塞太多选项会让自动委派变得不可靠。大多数团队最终会保留少量边界清晰的 Agent，而不是维护一大串名单。

• 需要 Agent 彼此协作的工作。子Agent 会向主对话汇报，但不能互相交谈。对于需要 子Agent 之间沟通的任务，请使用 Agent 团队。使用 Agent 团队 时，子Agent 会跨独立会话协作，而不是在同一个会话内协作，因此更重、成本也更高。关于何时使用 子Agent、何时使用 Agent Teams，请查看我们的 Claude Code Agent 团队 文档。

前面描述的信号，也就是需要第二意见、子任务之间没有依赖关系，以及需要大量研究，能清楚说明什么时候值得把工作委托给 子Agent。

从对话开始，之后再自动化

有意识地使用 子Agent 时，它们才能发挥完整价值。Claude 提供的自动调用很有帮助，但知道什么时候委托研究、什么时候并行处理工作、什么时候请求新鲜视角，比完全交给自动判断能产生更好的结果。

使用 子Agent 时，先从对话式提示开始。观察哪些请求反复出现，等这些模式变清晰后再构建自动化。目标是让 子Agent 委托变得轻松，这样你的注意力就能留在真正重要的工作上。