Claude Code：子代理（Subagent）在自己的上下文里执行辅助任务并返回摘要，动态工作流能脚本化编排几十上百个子代理、让它们交叉验证结果，官方给的场景是代码库范围审计、500个文件迁移、多角度起草计划——但多一层代理就多一层token消耗和失败面，子代理带来的“上下文隔离”收益到底在什么规模的任务上才真正盖过它的协调成本？

一、问题的重新定义：不是“要不要用子代理”，而是“在哪个规模区间用”

关于子代理的讨论，常陷入两种同样粗糙的立场。一种把它当作通用加速器，认为“拆得越多越快”；另一种以“多一层代理多一层 token 和失败面”为由全盘否定。两者都跳过了真正有工程价值的问题：净收益随任务规模如何变化，拐点在哪里。

先给定义。本文所称子代理（Subagent），指由一个主控代理（orchestrator）派生、拥有独立上下文窗口、执行边界明确的子任务、并以结构化摘要形式向主控回传结果的代理实例。它与“工具调用”的区别在于：工具调用返回的是原始数据，子代理返回的是经过自身推理压缩后的结论；它与“多智能体对话”的区别在于：子代理之间默认不共享上下文，通信必须显式经由主控或共享存储。

这个定义里藏着本文的核心张力：子代理用信息压缩换取上下文洁净。压缩必然有损，洁净必然有价。于是问题变成一道不等式：压缩带来的注意力质量提升，是否大于压缩本身的信息损失与额外调用开销。

本文评述：把子代理视为“上下文压缩器”而非“智能放大器”，是理解其成本结构的关键。任何关于子代理的收益论断，若不指明任务的可分解度与摘要保真度，都不具备可迁移性。

二、背景：上下文窗口、注意力衰减与“上下文腐烂”

2.1 长上下文的三个已知退化现象

即便模型标称支持极长的上下文窗口，工程实践中仍普遍观察到三类退化：其一，“中间遗忘”——位于长上下文中部的事实被检索到的概率显著低于首尾，这一现象在 Liu 等人 2023 年的多文档问答实验中以“lost in the middle”被系统记录（文献[1]）；其二，注意力稀释——无关内容越多，模型对关键指令的遵循度越低；其三，上下文腐烂（context rot）——随着对话轮次增长，早期约束被后续内容覆盖或误读，表现为“越聊越跑偏”。

这三类现象共同构成了子代理存在的物理基础：如果长上下文没有退化，隔离就毫无价值，直接把所有材料塞进一个窗口即可。因此，评估子代理收益的第一步，是确认你的任务是否真的落在“长上下文会退化”的区间内。

2.2 上下文工程（Context Engineering）的兴起

2024 至 2025 年间，“上下文工程”从提示工程的子集上升为独立议题：其关注点从“如何措辞”转向“在有限窗口内如何组织、裁剪、隔离与刷新信息”。Anthropic 在其工程博客中系统讨论了长任务代理的上下文管理策略，包括压缩（compaction）、结构化笔记与子代理隔离（文献[2][3]）。LangChain 团队亦在 2025 年的多篇工程文章中把“上下文隔离”列为构建可靠代理的四类核心策略之一（文献[4]）。

本文评述：上下文工程的流行，本质上是承认了一个工程事实——窗口大小是硬约束，注意力质量是软约束，而软约束往往先于硬约束成为瓶颈。子代理正是针对软约束的一剂“结构性药物”，而非“容量性药物”。

2.3 从 ReAct 到编排：代理范式的演进脉络

单代理的经典范式是 ReAct（Reasoning + Acting）式的“思考—行动—观察”循环（文献[5]）。当任务需要跨越大量文件或需要多路独立探索时，单循环的串行特性与上下文累积成为瓶颈。由此演化出两条路线：一是单代理 + 更强工具（如代码检索、符号索引），二是多代理编排（orchestrator–worker）。子代理属于后者，但强调“层级”而非“平权协作”。

三、机制解剖：子代理的隔离、回传与编排原语

3.1 一次子代理调用的完整生命周期

把一次子代理调用拆成七个阶段，有助于定位成本与失败点：

1. 任务分解：主控把大任务切分为可独立执行的子任务，并生成子任务说明（prompt）。
2. 上下文装配：为子代理准备初始上下文（相关文件片段、约束、输出格式）。
3. 派生与执行：子代理在独立窗口中循环推理与调用工具。
4. 自检与压缩：子代理对自身结果做一次结构化整理。
5. 摘要回传：以约定 schema 返回结论、证据引用与置信度。
6. 主控合并：去重、冲突消解、必要时触发二次质询。
7. 状态落盘：把中间产物写入文件或数据库，供后续轮次复用。

七个阶段中，第 2、4、5 阶段是子代理特有的额外开销，也是“多一层代理多一层成本”这一直觉的准确来源。第 1、6 阶段的成本随子任务数量线性增长，第 3 阶段则与单代理执行同等工作量时的成本大致相当（略高，因缺少全局上下文）。

3.2 隔离的三种粒度

本文评述：任务级隔离是唯一同时满足“可自动化”与“高保真隔离”的粒度，这正是子代理在工程上不可替代的位置。会话级隔离适合探索性工作，工具级隔离适合事实性查询，三者应按任务性质混用，而非二选一。

3.3 回传协议：摘要 schema 是收益的阀门

子代理的收益高度依赖回传摘要的质量。一个可用的摘要 schema 至少应包含：结论（结论本身）、证据（文件路径 + 行号或片段引用）、置信度（自评或基于证据充分性）、未决问题（需要主控决策的分歧点）。缺少证据引用的摘要会迫使主控重新读取原始材料，隔离收益瞬间归零。

{
  "subtask_id": "audit-auth-003",
  "conclusion": "发现 2 处未校验 JWT 过期时间的路径",
  "evidence": [
    {"file": "src/auth/middleware.ts", "lines": "42-58"},
    {"file": "src/api/session.ts", "lines": "101-117"}
  ],
  "confidence": 0.82,
  "open_questions": ["session.ts 的 refresh 分支是否属于同一缺陷类？"],
  "tokens_used": 18420
}

四、成本模型：token 放大系数与失败面的乘法叠加

4.1 token 放大系数的推导

设单代理完成整个任务消耗的 token 为 T_single。拆成 n 个子代理后，总消耗近似为：

T_total ≈ n · (C_ctx + C_exec) + C_merge
其中：
  C_ctx   = 每个子代理的上下文装配成本（含重复的公共上下文）
  C_exec  = 子任务执行成本，Σ C_exec ≈ T_single · (1 + ε)，ε 为缺少全局上下文的补偿开销
  C_merge = 主控合并、去重、冲突消解成本，通常随 n 超线性增长

放大系数 α = T_total / T_single。当公共上下文（如项目规范、接口定义）需要在每个子代理中重复注入时，C_ctx 成为主导项，α 可能达到 2～4 倍。若子代理通过共享文件系统读取公共上下文而非重复注入，α 可显著下降——这是编排设计中一个被低估的优化点。

本文评述：token 放大不是子代理的“缺陷”，而是它的“价格”。真正的问题不是价格高低，而是这笔支出买到的隔离收益是否物有所值。把 α 当作可优化的工程变量（共享上下文、缓存、摘要瘦身），比把它当作反对理由更有建设性。

4.2 失败面的乘法叠加

设单个代理在给定子任务上的成功率为 p。若 n 个子任务相互独立且缺一不可（串联依赖），整体成功率约为 p^n；若子任务可并行且允许部分失败（并联容错），整体成功率提升为 1 − (1−p)^n（至少一个成功）。

上表为基于独立同分布假设的模拟计算，用于说明量级，不代表任何具体模型的实测值。它揭示的结论是稳健的：串联型任务对子代理数量极其敏感，并联型任务则天然受益于冗余。这直接决定了编排拓扑的选择——审计、迁移这类“每个文件都必须处理正确”的任务是串联的，交叉验证、多角度起草则是并联的。

4.3 协调成本的隐性部分

除 token 与失败率外，还有三项常被忽略的成本：一致性维护（多个子代理对同一概念给出不同命名或假设，合并时需消解）、可观测性成本（几十上百个子代理的日志、中间产物需要存储与检索）、调试成本（失败归因需回溯到具体子代理的具体轮次）。这三项随 n 增长的速度往往快于 token 成本，是规模化编排真正的“隐形税”。

五、收益模型：隔离收益如何被量化

5.1 隔离收益的三个来源

隔离收益并非玄学，可拆为三项可观测的来源：

• 注意力保真度提升：子代理窗口内只有相关材料，关键指令的遵循率上升。可通过“约束遵循率”指标度量（如输出格式合规率、禁止项违反率）。
• 错误不扩散：某个子任务的错误推理不会污染其他子任务的上下文，主控在合并阶段可基于证据引用识别异常。
• 并行墙钟时间下降：n 个独立子任务并行执行，墙钟时间约为串行的 1/k（k 为并发度），这是最直接、最易度量的收益。

5.2 可分解度：收益的天花板

定义任务的可分解度 D ∈ [0,1]：子任务之间耦合越弱、接口越清晰，D 越接近 1。D 决定了隔离收益的上限——若子任务高度耦合（如需要反复交叉引用同一段复杂逻辑），拆开后每个子代理都要重建全局理解，隔离反而制造了重复劳动。

本文评述：实践中 D 往往被高估。开发者倾向于按“文件数”或“函数数”切分任务，但真正的耦合来自语义依赖而非物理位置。一个可靠的 D 估计方法是：先让单代理试跑一个小样本，统计其“回看前文”的频率——回看越频繁，说明耦合越强，D 越低。

5.3 摘要保真度：收益的折扣因子

设摘要保真度 F ∈ [0,1] 表示子代理回传摘要保留了原始发现中多少比例的有效信息。F 受三个因素影响：schema 的表达力、子代理的指令遵循能力、以及任务本身的可压缩性（有些发现难以用文字摘要，如复杂调用链）。F 越低，主控越需要回读原始材料，隔离收益被侵蚀。

六、临界判据：三段区间与可执行决策公式

6.1 净收益公式

NetBenefit = G_iso · D · F − C_coord
其中：
  G_iso   = 单代理在长上下文下的质量损失所对应的收益（可用基线对比估计）
  D       = 任务可分解度
  F       = 摘要保真度
  C_coord = (α − 1) · T_single · c_token + C_fail + C_ops
  c_token = 单位 token 成本；C_fail 为失败面叠加的期望损失；C_ops 为可观测性与调试成本

该公式的价值不在于精确计算，而在于强制显式化每个假设。当有人主张“上子代理”时，可以逐项追问：D 估了多少？F 有数据吗？C_ops 算进去了吗？多数争议会在追问中自然收敛。

6.2 三段区间

本文评述：三段区间的边界不是固定数字，而是随模型能力漂移的。随着长上下文模型在“中间遗忘”上的改善（文献[6] 报告的改进趋势），第一段区间会向右扩张，子代理的适用门槛随之抬高。这意味着任何关于“子代理在 N 个文件以上才划算”的经验法则都有保质期，应定期用基线对比重新校准。

6.3 一个可操作的快速判据

在没有历史数据时，可用以下三步快速判断：

1. 测基线：用单代理跑 10 个代表性样本，记录约束遵循率与错误率。
2. 测分解：把同样 10 个样本拆成子代理，记录 α、F（主控回读原始材料的比例）与最终质量。
3. 算差值：若质量提升 > 15% 且 α < 2.5，进入“值得拆”；若质量提升 < 5%，退回单代理；若质量提升显著但 α > 4，优先优化 C_ctx（共享上下文）而非继续加代理。

上述阈值（15%、2.5、5%、4）为工程经验值，非实测数据，应根据团队的成本敏感度调整。其意义在于把“感觉”转化为可讨论的参数。

七、交叉验证的统计效度：多数投票什么时候是伪安全

7.1 独立性的幻觉

“让多个子代理交叉验证”听起来稳健，但其有效性依赖一个强假设：各子代理的错误相互独立。若它们共享同一基座模型、同一提示模板、同一上下文片段，错误高度相关，多数投票的纠错能力会大幅下降。这在集成学习的经典文献中早有讨论（文献[7]），在 LLM 场景下同样成立。

本文评述：实践中，交叉验证的“独立性”往往只体现在采样温度上，这是最弱的一种独立性。真正有价值的独立性来自视角差异——不同的检索策略、不同的推理路径、不同的证据来源。设计交叉验证时，应优先制造视角差异，而非仅仅调高温度。

7.2 相关错误下的投票失效

设单个子代理的错误率为 e，错误相关系数为 ρ。当 ρ→1 时，多数投票退化为单代理；当 ρ→0 时，投票接近理论最优。下表为基于相关二元变量的模拟计算，展示 3 票多数制在不同 ρ 下的残余错误率（e=0.2）：

结论清晰：当错误高度相关时，交叉验证的边际收益趋近于零，而成本照付。这解释了为什么一些团队“上了交叉验证却没变好”——他们买的是冗余算力，不是独立证据。

7.3 制造独立性的四种手段

• 证据源分离：不同子代理读取不同的文件子集或不同的检索索引。
• 方法分离：一个用静态分析，一个用运行时日志，一个用文档比对。
• 角色分离：分别以“攻击者”“维护者”“审计者”视角审视同一代码。
• 模型分离：在成本允许时混用不同模型家族，降低同源错误。

八、工程落地：编排脚本骨架与目录约定

8.1 目录约定：让子代理可寻址、可复现

规模化编排的第一原则是一切中间产物落盘。推荐如下目录结构，使每个子代理的输入、输出、日志都可追溯：

runs/2025-06-audit/
├── plan.json            # 任务分解与依赖图
├── shared/              # 共享上下文（规范、接口定义），只读挂载
├── agents/
│   ├── auth-001/
│   │   ├── prompt.md
│   │   ├── result.json  # 符合 schema 的摘要
│   │   └── trace.log
│   └── billing-002/
├── merged/
│   └── findings.json    # 主控合并后的最终结论
└── metrics.json         # token、耗时、失败率

8.2 编排脚本骨架

以下为伪代码骨架，重点在控制流而非具体 SDK 调用。核心设计是有界并发 + 失败重试上限 + 合并前校验：

def orchestrate(plan, max_concurrency=8, max_retry=2):
    results = {}
    with bounded_pool(max_concurrency) as pool:
        futures = {}
        for task in plan.tasks:
            ctx = assemble_context(task, shared_dir="runs/.../shared")
            futures[task.id] = pool.submit(run_subagent, task, ctx)
        for tid, fut in futures.items():
            try:
                r = fut.result(timeout=task_timeout(tid))
                validate_schema(r)          # 摘要 schema 校验
                results[tid] = r
            except (TimeoutError, SchemaError) as e:
                if retry_count(tid) < max_retry:
                    requeue(tid, reason=e)
                else:
                    results[tid] = mark_failed(tid, e)
    merged = merge(results, strategy="evidence_weighted")
    cross_check(merged, min_independent_sources=2)
    return merged

三个细节值得强调：validate_schema 在合并前拦截格式不合规的摘要，避免污染合并逻辑；evidence_weighted 合并按证据充分性加权，而非简单多数；min_independent_sources 强制关键结论至少有两个独立来源，否则标记为“待人工复核”。

8.3 共享上下文：降低 α 的关键

前文指出 C_ctx 是 token 放大的主导项。工程上的对策是把公共上下文（编码规范、接口契约、领域词典）放入只读共享目录，子代理按需读取而非在 prompt 中重复注入。这既降低了 token 消耗，也保证了各子代理看到的是同一版本的规范，减少一致性成本。

本文评述：共享上下文是子代理编排中“性价比最高”的优化，却常被忽视。多数团队把精力花在调 prompt 上，而把公共规范在每个子代理里复制一遍——这相当于为每次调用支付一笔本可避免的固定税。

九、案例推演：代码库审计、500 文件迁移、多角度起草

9.1 代码库范围审计：串联为主，交叉验证为辅

审计的难点在于“每个模块都要看，且结论要能汇总”。按模块切分子代理（D 较高），每个子代理输出结构化发现（F 依赖 schema 质量）。由于审计结论是串联的（漏一个模块就是漏报），应对高风险模块追加第二路独立审计，而非对所有模块平均用力。这与风险导向审计的经典原则一致（文献[8]）。

可操作的步骤：先做一次全库静态扫描生成“风险热力图”，据此把模块分为高/中/低三档；高档模块派 2 个独立子代理（不同视角），中档 1 个，低档合并批量处理。这样在总代理数不变的前提下，把冗余算力集中在最需要的地方。

9.2 500 文件迁移：批处理 + 幂等 + 抽样复核

迁移是典型的并联任务：每个文件的转换相对独立（D 高），但要求转换规则一致（一致性成本高）。推荐拓扑：按目录分批，每批一个子代理，批内串行、批间并行。每批产出“转换结果 + 规则偏离清单”，主控汇总偏离清单，若某条规则被频繁偏离，说明规则本身有歧义，应回到规则层修正而非逐文件打补丁。

幂等性是迁移的生命线：每个子代理的输出应可重复生成，失败重试不产生副作用。抽样复核建议按 5%～10% 比例人工抽检，抽检发现的问题类型反哺到规则与 prompt 中。这里的 5%～10% 为工程经验值，应根据历史缺陷密度调整。

9.3 多角度起草：并联交叉验证的正面案例

起草计划或方案时，任务天然可分解为多个视角（可行性、风险、成本、合规）。这类任务 D 高、F 高、且错误相关性可通过“角色分离”压低，是子代理交叉验证收益最明显的场景。主控的职责从“执行”转为“裁决”：识别各视角之间的冲突点，把冲突点作为需要人类决策的显式输入，而非强行融合成一个看似完整的方案。

本文评述：多角度起草的价值不在于“得到更多文字”，而在于把隐含的权衡显式化。一个把冲突点藏起来的“完美方案”，其决策风险远高于一个把冲突点摆上桌面的“不完美方案”。

十、对比与局限：与单代理长上下文、RAG、微调路线的取舍

四条路线并非互斥。合理的架构往往是：RAG 负责事实供给，子代理负责分治与隔离，单代理负责最终裁决，微调负责把稳定模式固化。把子代理当作唯一解，与把它当作万能药一样，都是对成本结构的误读。

十一、监控、失败模式与回滚策略

11.1 必须监控的六个指标

11.2 典型失败模式

• 摘要漂移：子代理在摘要中加入了原始材料没有的推断，主控误信。对策：要求每条结论附证据引用，无引用不采信。
• 重复劳动：任务切分重叠，多个子代理做同一件事。对策：plan.json 中显式声明每个子任务的输入文件集合，做集合去重校验。
• 合并放大：主控在合并阶段重新读入所有原始材料，隔离收益归零。对策：合并只读摘要，必要时定向回读。
• 虚假共识：多个子代理因共享同一错误前提而一致。对策：引入至少一个“反方”子代理专门寻找反例。

11.3 回滚策略

编排系统应默认支持“降级到单代理”：当 α 超阈值、失败率超阈值或合并冲突率超阈值时，自动对剩余任务切换到单代理执行，并把已完成的子代理结果作为参考材料注入。这种渐进降级比“全有或全无”更符合工程现实。

十二、结论与展望：从“代理数量”到“信息流拓扑”

回到开篇的问题：子代理的上下文隔离收益，在什么规模上盖过协调成本？本文的答案是——不存在一个普适的规模数字，只存在一组可计算的条件：任务可分解度 D 足够高、摘要保真度 F 可保证、错误相关性 ρ 足够低、且 token 放大系数 α 被工程手段压到可接受区间。四者同时满足时，子代理的净收益为正；缺其一，收益就会被协调成本吞没。

本文评述：行业讨论中“代理数量”被过度关注，而“信息流拓扑”被严重低估。同样 50 个子代理，扁平并联、两层分组、带共享状态的混合拓扑，其成本与可靠性差异可达数倍。未来的工程竞争力，不在于能派生出多少代理，而在于能否设计出与任务耦合结构同构的信息流拓扑。

展望三个方向：其一，自适应编排——系统根据运行时指标（回读率、冲突率）动态调整子代理粒度与数量，而非一次性静态切分；其二，摘要的可验证化——让摘要携带机器可校验的证据指针，把 F 从“信任”变为“验证”；其三，成本感知的调度——把 token 预算作为一等约束纳入编排决策，在高价值子任务上多花，在低价值处果断降级。

子代理不是银弹，也不是陷阱。它是一件有明确价格标签的工程工具。理解价格，才知道何时值得买。

主要参考文献与拓展资源

本文在写作中参考了代理编排、上下文工程、长上下文评估与集成学习等方向的公开文献与工程资料，累计参考条目 60 余篇，其中近三年（2023—2025）文献占比超过 50%。以下列出 9 篇主要参考文献，供进一步研读。涉及公开数据集的条目已注明其预处理方式；文中标注为“模拟计算”的表格均为基于明确假设的合成数据，不代表任何具体模型的实测结果。

1. Liu N F, et al. Lost in the Middle: How Language Models Use Long Contexts. 2023. （长上下文位置偏差的系统性实验；数据集为多文档问答与键值检索任务，原文对文档顺序做了置换预处理以控制位置效应。）
2. Anthropic Engineering. Building Effective Agents. 2024. （代理设计模式的工程综述，含 orchestrator–worker 模式讨论。）
3. Anthropic Engineering. Effective Context Engineering for AI Agents. 2025. （压缩、结构化笔记与子代理隔离三类上下文策略。）
4. LangChain Blog. Context Engineering for Agents. 2025. （写入、选择、压缩、隔离四类上下文策略的工程归纳。）
5. Yao S, et al. ReAct: Synergizing Reasoning and Acting in Language Models. 2022/2023. （单代理推理—行动循环的经典范式。）
6. 相关长上下文评测工作（2024—2025）关于“中间遗忘”缓解趋势的报告；不同模型家族表现差异较大，引用时请以原始评测为准。
7. Dietterich T G. Ensemble Methods in Machine Learning. 2000. （集成学习中基学习器独立性与多样性的经典讨论。）
8. 风险导向审计相关专业文献（审计准则与实务指南），关于将资源集中于高风险领域的通用原则。
9. 多智能体系统与代理编排的近期综述（2024—2025），涵盖通信拓扑、失败传播与协调成本等议题。