AI-Wiki

定义或身份

Sub-Agent 是一种子代理执行模式：由父 Agent 将一段定义清楚、边界明确的工作委派给子 Agent，子 Agent 在自己的独立上下文中完成处理后，再由父 Agent 回收其最终输出。

它不是“多开一个 Agent 就更智能”的同义词，也不是为了把任务按人类岗位拆成多个虚拟角色。其设计重点是 上下文边界驱动的多智能体设计|按上下文边界拆分任务：当某个子任务可以与主流程相对隔离、独立探索、最后只需返回结论时，Sub-Agent 才是合适结构。

从编排形态看，Sub-Agent 本质上接近一种 多智能体编排原语|orchestrator-worker（调度-执行） 模式：父 Agent 负责拆分、派发、汇总，子 Agent 负责在受控范围内各自完成工作。

角色职责

父 Agent 的职责

判断某个子任务是否适合独立切出，而不是强行按角色拆分。
为子 Agent 提供清晰的任务定义、目标边界、可用工具和必要约束。
负责路由：把不同类型的子任务分发给最合适的子 Agent。
汇总多个子 Agent 的最终输出，形成面向用户或主流程的统一结果。
充当唯一中转层，控制所有信息流和调用边界。

子 Agent 的职责

在独立上下文中完成指定子任务的探索、分析或检查。
使用被授予的工具和提示完成工作，但不越权扩展结构。
只返回最终输出或结论，不返回中间思考过程。

这种职责划分意味着：Sub-Agent 不是一个长期协作成员，而更像一次被发起、完成后回收的受控任务单元。

关键约束

原文明确给出四项硬约束，这些约束不是附属实现细节，而是 Sub-Agent 能保持稳定和可控的核心前提：

子 Agent 之间不能直接通信。
子 Agent 不能继续生成新的 Agent。
所有流量必须经过父 Agent。
子 Agent 只返回最终输出，不带中间思考。

这四项限制看起来像是在削弱能力，但其真实目的恰恰相反：它们是在用结构化边界换取系统级可控性。

为什么不能直接通信

如果子 Agent 之间直接通信，系统的信息流会从“树状父子结构”迅速变成“网状协作结构”。一旦变成网状，调试、审计、权限控制、错误追踪都会显著变复杂，Sub-Agent 就会滑向 Agent Team 式的共享协作架构。

因此，禁止子 Agent 直连，是为了保持任务彼此独立，确保它们适合并行、易于回收，也避免隐性共享状态。

为什么不能继续生成新 Agent

如果子 Agent 还能再创建新 Agent，编排深度会快速失控，系统会从“父 Agent 控制下的受限委派”演化成递归式自扩张结构。这样不仅成本和延迟不可预测，也会让谁在负责、谁有权限、谁产生了哪个结果变得难以追踪。

所以 Sub-Agent 被限制为不能再生新 Agent，本质上是为了防止结构无限膨胀，维持清晰的责任边界。

为什么所有流量都必须经过父 Agent

父 Agent 是唯一的信息汇聚点和治理点。所有流量经过父 Agent，意味着系统可以在一个中心位置完成任务派发、结果汇总、权限约束、日志记录和异常处理。

如果子 Agent 能绕过父 Agent 与外部或彼此自由交换信息，父 Agent 就失去了编排意义，整个系统也更难保证输出一致性与行为可审计性。

为什么只返回最终输出

Sub-Agent 的目标之一就是把一段探索过程压缩成可被父 Agent 消化的结论信号。如果把大量中间试探、分支思路、局部分析原样回传，父 Agent 的上下文就会再次被探索噪音占满，失去使用 Sub-Agent 的主要收益。

因此，Sub-Agent 强调“返回结论，不返回中间思考”，核心不是遮蔽能力，而是避免父上下文被子任务过程污染。

核心价值

原文把 Sub-Agent 的价值归纳为三类：隔离、压缩、并行。这三个词比“多代理更强大”更接近它的真实用途。

1. 隔离父上下文，防止探索过程污染

父 Agent 的上下文窗口是稀缺资源。长任务中最容易挤占上下文的，往往不是最终答案，而是“我先看看、再查查、试试另一种解释”的探索轨迹。

Sub-Agent 将这些探索留在自己的独立上下文中完成，不把过程性噪音直接带回主链路。这样父 Agent 可以保留更干净的任务主线，避免被局部调查、试错过程和临时分析撑满。

这也是它最适合边界清晰子任务的原因：当一个问题可以局部封装时，隔离收益最大。

2. 把复杂探索压缩为结论信号

Sub-Agent 返回的不是完整推理流水账，而是压缩后的结论。父 Agent 接收的信号更短、更干净、更容易继续编排。

这种压缩并不是简单省 token，而是把“探索过程”转化为“可复用判断结果”。从系统设计角度看，真正重要的是子任务最终留下了什么结论、发现了什么问题、给出了什么建议，而不是它中间尝试过哪些路径。

3. 支持互不依赖任务的并行执行

正因为子 Agent 之间不能直接通信，也不共享中间状态，它们特别适合处理互不依赖的并行子任务。

在这种场景下，父 Agent 可以一次派出多个 Sub-Agent，同步进行不同维度的检查，最后统一汇总结果。相比把多个检查串行塞给一个 Agent，Sub-Agent 模式往往更高效，也更容易控制每个子任务的边界。

典型适用场景

最典型的例子是代码审查中对不同维度做独立检查。

例如，一个父 Agent 接到“审查认证模块代码”的任务后，不一定要拆成 Planner、Developer、Tester、Reviewer 这类人类岗位链条，而可以按彼此独立的审查维度拆分为多个 Sub-Agent，例如：

一个专门检查安全漏洞和安全风险；
一个专门识别性能瓶颈；
一个专门检查测试覆盖率或测试遗漏；

这几个维度通常彼此不需要共享中间过程，完全可以并发运行。最后由父 Agent 汇总成统一审查报告。这正符合 Sub-Agent 的三大收益：独立上下文隔离、返回结论、并行执行。

实现细节

原文给出的实现示例来自 Claude Agent SDK。该模式通过 AgentDefinition 注册子代理，由父 Agent 在 agents 配置中声明可调用的子 Agent 集合。

示例中，父 Agent 在执行“Review the authentication module for issues”时，注册了如 security-reviewer 和 performance-optimizer 这样的子代理定义；每个定义包含其描述、提示、可用工具和模型配置。

其中一个非常关键、但容易被忽略的细节是 description 字段。

`description` 的实际作用是路由信号

在 Claude Agent SDK 的 Sub-Agent 模式里，description 表面上像是给开发者看的说明文字，但实际上承担的是任务分发时的路由信号作用：父 Agent 会根据这段描述，判断某项子任务应该交给哪个子 Agent。

这意味着：

Sub-Agent