Claude Code 中的 SubAgents 是什么?你需要了解的内容

CometAPI
AnnaOct 24, 2025
Claude Code 中的 SubAgents 是什么?你需要了解的内容

子智能体(常见写法为 subagentssub-agents)是面向智能体开发工具的最清晰且务实的进步之一:它们允许你在 Claude Code 内部组合一支由多个专业 AI 助手构成的小团队,每个助手都有自己的角色、工具与上下文窗口。这个理念简单却强大——与其让一个通用模型包揽所有任务,不如定义紧凑、单一用途的智能体,由主编排器将工作委派给它们(可自动或按你的明确请求)。这改变了你管理上下文、工具,以及复杂工作流的成本/时延权衡的方式。

什么是子智能体?

简短定义。 子智能体是一种预配置、任务专项的 AI“角色”,Claude Code 可以将任务委派给它。每个子智能体都有自己的系统提示词、自己的(隔离的)上下文窗口、明确授予的工具,以及可选的模型选择。子智能体既可在项目层级创建,也可在用户层级创建,可由 Claude 自动调用或由用户显式调用。

子智能体的关键属性

  • 专项目的与系统提示词。 你在系统提示词中描述子智能体的角色、约束与方法,使其在狭窄领域内行为可预测(例如,code-reviewerdebuggerdata-scientist)。
  • 隔离的上下文窗口。 每个子智能体维护自己的会话历史与上下文,避免主线程的上下文被低层细节污染。这是扩展那些会耗尽单一会话上下文的工作流的核心。
  • 工具范围与权限。 你可以授予或限制子智能体可使用的内部工具或外部 Model Context Protocol (MCP) 工具。这是关键的安全与治理特性。
  • 配置即代码。 子智能体以带 YAML 前置区块的 Markdown 文件定义(name、description、tools、model),存放于项目层级(.claude/agents/)或用户层级(~/.claude/agents/)。项目定义优先生效。

什么是自动委派与显式调用

当你的提示或子智能体的 description 与任务匹配时,Claude Code 可自动将任务委派给子智能体——或者你可以显式请求某个智能体(例如,> Use the code-reviewer subagent to check my recent changes)。将 description 写成行动导向("Use PROACTIVELY""MUST BE USED")可推动自动委派,这是在 Claude Code 中使用子智能体的两种互补方式:

  1. 自动委派 — Claude 检查请求并主动将匹配的工作委派给子智能体。
  2. 显式调用 — 你在提示/命令中按名称点名子智能体(例如,Use the code-reviewer subagent to check my changes)。

两种方式在用户体验与工程实现上均有不同的权衡。下文将逐一解析。

自动委派

用户看到的效果。 你发出一个高层命令(例如,“为这个新库准备一次安全审计”),Claude 根据子智能体配置中的 description 字段检测到一个或多个子智能体契合该任务。若配置为主动使用,该子智能体会被自动调度并以结构化输出返回结果。

团队为何使用它。

  • 它降低认知负担——你不必记住或输入每个子智能体的名称。
  • 它让共享工作流的入门更顺滑,在这些工作流中,特定任务应始终由同一专家处理。

注意事项。

  • 必须精心设计 description 和系统提示词,确保 Claude 能可靠地选择正确的子智能体。
  • 过度积极的委派可能增加 token 使用与噪音,如果许多子智能体会为类似任务同时激活;请保守地设计你的描述。

显式调用

用户看到的效果。 你显式调用一个子智能体:> Use the test-runner subagent to run the project tests。编排行为是确定性的:Claude 按该命名子智能体的预配置权限与提示进行调用。

团队为何使用它。

  • 完全可控:你准确决定哪个专家会运行,这简化了调试与复现。
  • 在 CI 或自动化脚本中更易于推断成本与工具访问。

注意事项。

  • 需要更多输入与纪律:开发者或自动化流程必须知道正确的子智能体名称。
  • 较少机会主义:你会失去一些由主智能体自动检测到合适子智能体的便利。

子智能体如何工作 — 技术概览

下面是从实现角度对创建与使用子智能体时发生的事情的实用性概述。

定义子智能体(配置即代码)

子智能体是一个带 YAML 前置区块的 Markdown 文件。重要字段包括:

  • name — 唯一的小写 id(用连字符分隔)
  • description — 用于自动委派匹配的自然语言描述
  • tools — 可选,允许工具的逗号列表(或省略以继承所有工具)
  • model — 可选,模型别名(sonnetopushaiku)或 inherit 以使用主会话的模型

一个小示例(概念性,非文档原文):

---
name: code-reviewer
description: Expert code reviewer. Proactively reviews code for quality, security, and maintainability.
tools: Read, Grep, Bash
model: inherit
---
You are a senior code reviewer. Focus on security, correctness, and maintainability.

这些文件位于 .claude/agents/(项目作用域)或 ~/.claude/agents/(用户作用域)。项目层级文件优先生效,这使得共享与版本控制子智能体变得简便。

模型选择与工具

  • Model 字段: 你可以为子智能体选择特定的模型别名,或让其继承主会话的模型。这让你可以混合成本/质量的权衡(例如,为大型数据扫描的子智能体使用更低成本的模型,为最终综合使用更高质量的模型)。
  • 工具范围: 为每个子智能体提供最小化的工具集合可降低风险面并简化安全性推理。工具包括标准 Claude Code 原语(Read、Grep、Bash、Edit 等)以及由 MCP 提供的集成。

运行时行为与上下文处理

当 Claude 将任务委派给子智能体时,该子智能体会接收:

  1. 它的系统提示词(YAML/Markdown 内容)。
  2. 仅所需的上下文(它自己的上下文窗口)。
  3. 按配置允许的工具访问。

因为每个子智能体维护隔离的上下文,长时间调查或大文件分析可以分解为许多小上下文,而不再强迫一个单一上下文容纳所有内容——这在可靠性与可解释性上都有巨大优势。

子智能体的架构模式

最常见的架构是一个编排器(主智能体)将高层任务分解,启动多个子智能体,并最终综合或验证它们的输出。两种典型模式广泛出现:

1) 编排器 + 专家智能体

一个智能体(即编排器)并行或串行协调多个子智能体。编排器决定调用哪个专家、聚合输出、验证一致性,并执行最终集成。这是常见的“经理将任务委派给团队成员”的方式,匹配许多示例与 Claude Code 材料中的推荐设计。优点包括并行化、更清晰的关注点分离,以及更容易的错误隔离(一个有问题的子智能体仅影响它的作用域)。

适用场景: 复杂任务且包含相互独立的子问题(例如,“生成测试”、“运行静态分析”、“重写模块”,然后“集成并运行端到端测试”)。

权衡: 编排逻辑可能变复杂;额外的往返可能略微增加时延。

2) 管道/串联的专家智能体

子智能体按序排列,一个的输出成为下一个的输入(例如,规格 → 脚手架 → 实现 → 测试 → 优化)。这本质上是以智能体表达的函数组合——当你需要逐步转换与严格的数据流保证时非常便利。它对线性工作流在概念上更简单,有时也更易调试。

适用场景: 确定性的多步骤转换(例如,将设计文档转化为脚手架代码,再到测试,再到优化)。

权衡: 对需要广泛探索(研究、头脑风暴)的任务不够自然,而且单点故障会阻塞整个管道。

子智能体与仅基于角色的提示有何不同?

1) 独立的上下文窗口

每个子智能体拥有自己的上下文缓冲区,存储与其角色相关的交互、文件与元数据。这防止主会话的上下文被嘈杂的中间信息污染,也意味着你可以为每项能力保留——或限制——历史。这让 Claude Code 能为专项任务保留长期、信噪比高的上下文,而无需支付将一切塞进同一提示的 token 成本或认知负担。

2) 系统提示与角色设定

子智能体以系统级指令创建,定义其角色、语气与约束(例如,“仅作为重构专家行动;不要执行 shell 命令”或“以 pytest 风格生成单元测试;仅使用公共接口”)。这些提示就像子智能体的职位描述,并由 Claude Code 的运行时在执行时强制生效。

3) 工具绑定与权限范围

一个关键的实践差异:子智能体可以被授予或拒绝访问特定工具——文件系统、进程执行、外部 API 或特权数据集。这让子智能体非常适合最小权限设计:文档生成器可被阻止运行任意命令,而 CI 子智能体在隔离沙箱中获得授权。许多社区文章倡导将子智能体与 Model Context Protocol (MCP) 或基于 hooks 的 MCP 服务器配对,以管理对密钥与 I/O 的安全访问。

4) 模型选择与成本-性能权衡

因为子智能体是模块化的,你可以根据任务复杂度分配不同的底层模型。对深度推理使用能力更强的 Sonnet 模型,对快速、重复的任务使用轻量的 Haiku 模型。这种异构部署有助于平衡时延、token 成本与能力。Anthropic 的产品更新与社区文章强调并行部署较小模型以实现具成本效益的扩展。

5) 通信模式

子智能体通过结构化消息或文件与编排器(或彼此)通信。典型模式包括:

  • 返回结构化的 JSON 负载(用于可编程编排的首选方式),
  • 写入共享工作区中受限范围的文件,
  • 或向编排器发送最终格式化的消息,包含置信度与理由。
    社区实践显示,团队更倾向于明确、机器可读的交接以避免歧义。

性能收益

子智能体不仅是设计上的整洁性——若正确使用,它们能实实在在提升性能与质量。

1) 通过并行降低总体耗时

通过并发调度多个工作者(例如,每个仓库文件夹一个工作者、每个微服务一个工作者、每个数据块一个工作者),编排器可以减少完成大型复合任务所需的总时间。诸如分拣缺陷报告、为多个模块生成文档或审计多个服务等用例天然适合这种方式。在工作负载真正可并行化时,能显著加速开发者工作流。

通过为每个角色提供独立的上下文,你可以避免提示膨胀,并降低由不相关历史噪音导致的幻觉风险。这意味着较少的上下文相关失败,以及更稳定的专项任务输出。社区文章与 Anthropic 的研究显示,多智能体设置在广度优先任务上往往优于单体智能体。Anthropic 的一项内部评估报告称,采用主导智能体 + 子智能体的架构在研究类任务上有显著改进。

注意:当子任务相互独立时,并行收益最佳。若工作者必须频繁等待彼此或共享沉重状态,你会看到收益递减。

2) 更好的上下文利用与更低的 token 浪费

与其将每个中间搜索结果塞进单一的全球上下文,不如让工作者仅在自己的窗口中保留相关内容,并返回精炼输出。这降低了编排器的 token 消耗,并减少触发上下文上限的风险——当你处理大型代码库、长日志或大文档仓库时,这是务实的优势。SDK 的压缩/总结功能进一步延展了长运行智能体的有效记忆。

3) 通过专家型提示提升准确性

作为狭义专家构建的子智能体可以通过系统提示与工具集进行调优,以在其领域优化精度:安全检查、代码风格或合规抽取。狭义提示往往能降低幻觉,因为智能体的可行动作空间与预期输出被约束。组织报告称,在自动化代码审查等任务上,使用领域特定子智能体往往比让通才包办一切产出更高质量的结果。

团队如何实际使用子智能体 — 示例工作流

下面给出具体示例以减少抽象感。

示例 A — 重构流水线(编排器 + 专家)

  1. 编排器收到“重构组件 X”的请求。
  2. 编排器调用 analysis-subagent(无写权限)识别复杂热点与风险依赖。
  3. 编排器调用 refactor-subagent(在类似分支的沙箱中具有写权限)生成重构后的文件。
  4. 编排器调用 test-gen-subagent(代码只读权限)生成单元测试。
  5. 编排器用 ci-runner-subagent(沙箱执行)运行 CI,并汇总结果供人工审阅。
    该模式将每个阶段隔离、控制风险,并保持整洁的审计轨迹。

示例 B — 研究 + 原型(流水线)

  1. literature-subagent 抓取并总结参考资料(无文件写入,受监管的网页访问)。
  2. prototype-subagent 根据摘要搭建最小 PoC。
  3. benchmark-subagent 在沙箱中运行微基准并报告结果。
    该链条强化研究任务的顺序性,同时保持职责清晰。

最佳实践与模式

设计与配置

  • 从小而窄的角色开始。 让每个子智能体只负责一个明确工作。职责越窄,调试越容易。
  • .claude/agents/ 文件夹纳入版本控制。 像管理代码一样管理子智能体定义——评审、测试并固定版本。这能减少漂移并简化审计。
  • 有目的地固定工具与模型。 当你需要与主会话保持一致时使用 model: inherit;为后台扫描指定更低成本的模型别名。锁定工具以最小化攻击面。

运行模式

  • 在确定性自动化中使用显式调用。 如果你在运行 CI 作业或钩子,明确调用特定子智能体以确保可预测结果。
  • 在交互式会话中使用自动委派。 对探索性工作,让 Claude 选择子智能体以降低摩擦——但要谨慎撰写 description 字段,避免自动化意外触发。
  • 为综合设计结构化输出。 强制子智能体写入文件或生成编排器可读取的 JSON;这简化了归并步骤与审计。

测试、监控与治理

  • 构建具代表性的评测。 跟踪子智能体的失败点,并构建能覆盖这些失效模式的测试。Anthropic 建议采用具代表性的测试集并迭代改进。
  • 监控 token 与工具使用。 为每个子智能体进行仪表化,并添加告警以检测成本失控或速率限制状况。

何时不应使用子智能体

子智能体很强大,但并非总是正确的工具。

  • 简单任务: 对短促的一次性提示或琐碎转换,子智能体会增加不必要复杂性。
  • 严格时延约束: 编排往返引入开销;如果你需要单轮、极低时延的响应,单体方式可能更简单。
  • 小团队且基础设施薄弱: 如果缺乏密钥管理、可观测性与沙箱工具,子智能体可能提高运维风险。社区文章强调从小做起,在需要模块化时再引入子智能体。

在何处最推荐使用 Claude Code cli

It was excited announce that CometAPI now fully supports the powerful Claude Code cli. 你只需安装 Claude Code 并使用获取到的 Comet API Key 与 Base Address 进行认证,即可在 Claude Code 上使用 Comet API 的模型。

为什么通过 CometAPI 使用 Claude Code?

顶级人工智能特性:使用专为开发者打造的模型,轻松生成、调试与优化代码。

  • 灵活的模型选择:我们提供全面的模型系列,助你更顺畅地开发。
  • 无缝集成:API 随时可用。几分钟内将 Claude Code 直接集成到你现有工作流。
  • 通过 CometAPI 使用 Claude Code 将节省更多成本。CometAPI 提供的 Claude API 比官方价格便宜 20%,并随着官方更新最新模型。

准备好使用 Claude Code cli?请查阅 API 指南 获取详细说明。

如果你想了解更多 AI 技巧、指南与资讯,请关注我们的 VKXDiscord

另见 如何通过 CometAPI 安装并运行 Claude Code?

结论 — 为什么子智能体在当下很重要

子智能体让智能体式工作流对团队而言切实可行:它们让你以一等公民的方式明确地推理角色、权限、上下文、成本与并行化。若慎重使用,子智能体能解锁更高的开发速度、更好的多步骤任务质量,以及更可预测的治理。另一方面,你必须像对待生产软件一样去设计、测试与监控这些子智能体——但这项投入会将提示工程转化为可靠的工程实践。

阅读更多

一个 API 中超 500 个模型

最高 20% 折扣