---
title: "子代理（subagent）是什么"
description: "子代理在主代理之外拥有独立上下文，只把结果摘要交回。它适合搜索、审查与并行探索，但协调成本和上下文割裂是实际代价；步骤少、需共享上下文时，单代理加工具更合适。"
updated: 2026-11-13
canonical: https://docai.cc/concepts/subagent/
markdown_mirror: https://docai.cc/concepts/subagent.md
---
## 它是什么

子代理（subagent）是主代理派生出来的独立代理：它有自己的上下文窗口、自己的系统提示和工具范围，只把任务说明带进去，做完后把结果摘要交回来。

关键在「独立上下文」。主代理不需要把搜索过程中的多次读取、报错和试错都留在自己的对话里，只保留一份结论。上下文越干净，后续判断越不容易被无关信息带偏。

它也不是另一个更聪明的模型。多数实现里，子代理用的是同一类模型，差别在任务范围、提示和工具权限。

## 怎么工作

一次委派大致是这样：

- 主代理判断任务可以拆，写一份任务说明，包含目标、边界和输出格式；
- 子代理在自己的上下文里执行，可以连续调用工具，中间过程不回传；
- 子代理结束时返回摘要，主代理决定采信、追问还是重新委派。

适合交给子代理的活有几类：大范围搜索与资料筛选；独立审查，例如只读代码找问题；互不依赖的并行探索；以及会产生大量中间输出的任务，比如逐个读文件。在 Claude Code 里，子代理还能限定工具集，做成只能读、不能写的审查角色，这时[工具调用](/concepts/tool-use/)的权限边界就落在子代理身上。

代价也很实际。写清楚任务说明本身要花心思，说明含糊，子代理就会跑偏；摘要会丢掉细节，主代理看到的不是全过程，出错时更难定位；多个子代理并行，token 消耗和执行时间都会上去。

失败是隔离的——一个子代理崩了，主代理的上下文还在——但它的错误结论如果被当成事实收下，就会污染后续判断，所以关键结论要能追溯到证据。

## 什么时候用，什么时候不用

适合拆分的信号：任务边界清晰、彼此不依赖、需要大量探索、单个子任务会产出很多中间材料。典型场景是资料调研、代码审查、多方案并行验证。

不适合的信号：步骤少而线性、子任务之间需要频繁共享上下文、对延迟和成本敏感，或者你还在摸索问题本身。这时单代理加几个工具就够了。先让一个代理把流程跑通，再考虑拆分，会比一上来就设计多代理稳得多。相关背景可以看[Agent](/concepts/agent/)、[Agent 框架](/concepts/agent-framework/)和[上下文窗口](/concepts/context-window/)。

## 常见误解

- **「子代理一定更强」**：它换来的是隔离和并行，不是更强的推理；很多任务拆开反而更差。
- **「子代理越多越好」**：每个都要写说明、等结果、做汇总，协调成本随数量上升。
- **「子代理能看到主对话」**：通常看不到。它只拿到交给它的说明，信息要在任务描述里写全。
- **「子代理失败不会影响主流程」**：错误被静默采纳时，影响比直接报错更大。