你每天都在用 Subagent，可十个人里有九个把它想错了：当成”缩小版的 Agent”。
不是。它跟大小没关系，是主 Agent 临时借来的一块干净内存，用完就还。
这个误会不解开，你搭的多智能体系统不会更聪明，只会更慢、更贵。下面把边界讲清，再给一张”什么时候该拆、什么时候别拆”的判断表。
它不是”小一号的 Agent”，是另一种东西
大部分人是按”老板和下属”的直觉在理解这俩词：Agent 是大的，Subagent 是小的，大的指挥小的。
这套组织架构的想象，恰恰是错的源头。Agent 和 Subagent 的差别根本不在”谁大谁小、谁管谁”，而在三件事：有没有独立的上下文窗口、职责是不是被收窄、调度上是不是干完就散。
说白了：主 Agent 是攥着总目标、守着主线内存、最后把结论缝起来的那个；Subagent 是它临时雇来干一摊脏活、干完汇报就解散的临时工。
上下文窗口（context window），就是模型一次能”记住”的那块内存——你给它的指令、它读过的文件、工具吐回来的结果，全挤在这一块里，满了就开始往外掉东西。
把 Subagent 当”小 Agent”，是把一道内存管理题，错当成了组织架构题。 方向一错，后面怎么用都别扭。
（先把边界说清：这里讲的 Subagent，主要按 Claude Code、Anthropic Agent SDK 这类”主 Agent 派生独立上下文”的实现来谈。别的框架叫法未必一样，但判断内核不变——上下文要不要隔离。）
真正分开它俩的，是这三条线
第一条，也是最本质的：独立的上下文窗口。 Claude Code（Anthropic 出的命令行 AI 编程工具）官方文档把话说得很直白：“Each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions.”（每个 subagent 跑在自己的上下文窗口里，有自己的系统提示、特定的工具权限和独立的许可。）注意那个 “its own”——它和主线不共享内存。
第二条：职责被提前收窄，能碰的工具和权限也一起圈死。 Claude Code 内置的几个 subagent 就是活样本：Explore 只能读不能写、跑最便宜的 Haiku 模型、主打一个快和省；Plan 专管规划；General-purpose 才是通用那个。一个 Subagent 通常只干一件事，连能碰的工具都被提前圈好。
第三条：调度上从属，干完只汇报，然后就没了。 Agent SDK（Anthropic 给开发者搭 Agent 的工具包）的原话是：“Each subagent runs in its own fresh conversation. Intermediate tool calls and results stay inside the subagent; only its final message returns to the parent.”（每个 subagent 跑在自己全新的对话里，中间的工具调用和结果都留在它内部，只有最后一条消息回到主 Agent。）
Subagent 干完活，交回主线的只有最终结果；中间翻过的几十页，全烂在它自己那块内存里，散场就没了。
它最先解决的麻烦：上下文污染
知道了这三条，“为什么要有 Subagent”就不用解释了——它是来解决一个具体麻烦的：上下文污染。
主 Agent 要回答一个问题，中间得搜 20 次资料。每搜一次，几千字的原始网页就塞进那块内存。搜到第 20 次，你最早那个问题早被挤出窗口了，模型自己都快忘了在查什么。
Subagent 就是干这个的：把”搜 20 次”这种又脏又占地方的活，丢进一块独立内存里办，办完只把最终结果带回主线，原始垃圾留在原地销毁。
Anthropic（做 Claude 的那家 AI 公司）在自己的多智能体研究系统里就是这么干的：一个主 Agent 负责规划，并行派出 3-5 个 subagent 各查一摊，最后单独跑一遍核对引用的环节去汇总。效果是实打实的——在它内部的研究类评测上，这套多智能体设置比单个 Claude Opus 4 高出 90.2%。
上下文窗口是会被烧光的预算，Subagent 就是替你把账单留在别处的那个人。
该拆的信号：能并行、要隔离、可复用
那到底什么时候该派 Subagent？别凭感觉，对着下面四条对号入座，中一条就值得考虑：
- 任务能并行。三摊互不依赖的调研，与其排队串着查，不如三个 Subagent 同时上。
- 上下文该被隔离。输出特别啰嗦的活、漫无目的的探索性搜索，扔进子上下文，省得污染主线。
- 职责单一、还能复用。同一种活反复要干（比如”在代码库里找某类用法”），固化成一个专用 Subagent，下次直接调。
- 要换模型或收窄权限。简单的活想用更便宜的小模型省钱，或者某个环节只该给只读权限，拆出去单独配。
判断该不该拆，第一问从来不是”这活大不大”，而是”这块上下文，要不要留在主线上”。
别拆的信号：串行、紧耦合、契约说不清
反过来，下面这几种情况，硬拆只会更糟：
- 任务是串行强依赖的。后一步要等前一步的结果才能动，拆成并行没有意义，反而多绕一圈交接。
- 契约一句话讲不清。这是最容易踩的坑。Subagent 看不见你的上下文，它只拿到你写的那一段任务描述。你交代不清，它就自己脑补。Anthropic 自己早期就翻过车：一个 subagent 在查 2021 年的汽车芯片荒，另外两个却重复去查 2025 年的供应链——它们压根不知道彼此存在，也没法在干活途中对齐。
- 拆了反而烧钱。多智能体这套，token 用量大概是普通对话的 15 倍。活儿本身不复杂，这倍数得不偿失。
- 任务是紧耦合的。Anthropic 的判断是：多智能体擅长那种能切成并行支线的任务；对紧耦合、强依赖的活（比如写代码），拆开往往不划算。这不是说多智能体碰不得代码，而是说越是牵一发动全身的活，拆开协作要付的对齐代价越高。
拆得越细不等于跑得越快；契约一句话讲不清的活，拆出去就是给自己埋雷。
不是”任务大小”，是”上下文该不该隔离”
回到开头那个误会。Subagent 从来不是”小一号的 Agent”，它是一种管理上下文的手段——给主 Agent 临时续一块干净内存，让脏活、并行的活、需要隔离的活，都在别处办完，只把结论带回来。
还有第三种常被忽略的答案：单个 Agent 就够。 任务线性、上下文装得下、不需要并行、最后只交一个东西——这种就别拆。不是功能不够，是成本不值得。Subagent 是手段，不是目标。
所以下次要不要拆，别再盯着任务体量看了。
该问的是：这块上下文，配不配拥有它自己的一块内存。
引用出处
- Claude Code 官方 subagents 文档：https://code.claude.com/docs/en/sub-agents
- Claude Agent SDK subagents 文档：https://code.claude.com/docs/en/agent-sdk/subagents
- Anthropic 工程博客《How we built our multi-agent research system》：https://www.anthropic.com/engineering/multi-agent-research-system