模式矩阵 /模式白皮书/C5

ADPS Agent 设计模式白皮书

C5 · Sub-Agent Isolation · 子代理隔离

子 agent 在独立 context 中执行,返回前必须压缩成 schema 化 artifact,主 agent 只看 artifact 不看 raw trajectory。

版本
v0.3
状态
公开评审稿
发布日期
2026-07-13
分类
协作 Collaboration × 层级 Hierarchy(分)
目录地位
扩展模式
许可
CC BY 4.0

文档状态:本页为公开评审稿。模式定义与分类可供讨论和引用;未附来源链接的数字与应用示例只用于说明机制,不作为行业基准。

坐标 协作 Collaboration × 层级 Hierarchy(分)
成本 横切(跨切关注点,叠加在其他协作模式上)
模式组 协作模式
模式简介 子 agent 在独立 context 中执行,返回前必须压缩成 schema 化 artifact,主 agent 只看 artifact 不看 raw trajectory。

问题

主 agent 派 sub-agent 干活,sub-agent 跑完把全部工作过程 dump 回来,主 agent 的 context 立刻被淹没。50 份合同每份 3000 字的详细分析回传就是 15 万字,主 agent 接到后推理质量断崖式下降。问题的根子是主 agent 不该看 sub-agent 的 raw 工作过程,只该看工作结论——就像律所的 PM 不会要求每个律师汇报读了哪一行字,只看"哪几份异常加它们的关键问题"。

子代理隔离解决的是 enterprise multi-agent 系统的 context pollution。它让每个 sub-agent 跑在自己的隔离 context 里,返回前强制 reduce 成结构化 artifact,主 agent 只消费 artifact。这件事的工程价值独立到值得单独成一个模式:它是层级委派、扇出聚合这些协作模式能在生产环境跑稳的内功,没有它,主 agent 第三个任务必爆 context、多 agent 跑久了必然 cascade。

分类依据:协作 × 层级

  • 纵轴 · 协作:让 sub-agent 拥有独立的 context 和权限,是在协作中加边界的设计。它不是单纯的派工,而是给协作加上隔离纪律——主 agent 和 sub-agent 之间的信息流被刻意切断成"只传精炼结论"。
  • 横轴 · 层级:parent agent 调度 sub-agent,sub-agent 在自己的沙箱里跑,是层级加隔离的结构。它跟层级委派共格(都在协作 × 层级交点),但侧重不同——层级委派强调派工,子代理隔离强调隔离加摘要返回。

解决方案与机制

子代理隔离由四件工程要素构成:

  1. Context 隔离:sub-agent 启动时不继承 parent 的 history,只收到自己的 system prompt、具体的 task instruction、自己的 tool set。它看不到主 agent 跑过什么、其他 sub-agent 在做什么。
  2. Artifact schema 化返回:sub-agent 返回的不是自由文本总结,是结构化 artifact(pydantic model 或 JSON schema)。推荐三层结构——verdict(success / partial / failure)、top findings(3-5 条)、citations(可选)。这让主 agent 能用确定性代码直接 parse,不用再花 token 解析。
  3. 失败 boundary 隔离:一个 sub-agent timeout 或抛异常,主 agent 收到的是 verdict=failure 的 artifact,而不是被异常炸掉。N 个 sub-agent 中 1 个挂掉只损失 1/N。
  4. 并行互不干扰:N 个 sub-agent 各跑各的 context,互相看不到中间状态,也不直接通信——要交换信息必须经过主 agent。

适用条件

  • 子任务产出多、主 agent context 紧的批量任务:合同审阅、文档扫描、大规模代码检索,每个 sub-agent 处理一份、只回传精炼结论。
  • 需要防止任务间相互污染的场景:每份合同应该被独立 fresh review,不被其他合同的细节 prime(避免 anchoring bias),独立 context 是必需的。
  • 数据 scope 不能跨的场景:一个 sub-agent 看到的敏感数据不能流到另一个 sub-agent 或污染主 agent,隔离 context 提供了天然的数据边界。
  • 需要防 prompt 污染的场景:sub-agent 的试错失败 trace、越界尝试不应该拖累主 agent 或其他 sub-agent 的后续推理。

已知失效方式

  • sub-agent 继承主 agent history:在 demo 阶段看着没事,等第三个任务跑完后主 agent history 累计几万 token,每个 sub-agent 都背这些 token 起跑——成本爆炸加质量下降。sub-agent 必须用本地 messages 完全独立起跑。
  • 返回自由文本而非 schema artifact:自由文本让主 agent 端可用性差 10 倍——不能用确定性代码 parse、不能做 confidence 排序、不能做 verdict 分流。必须强制 schema 化。
  • sub-agent 之间直接通信:为了省事让 sub-agent A 调 sub-agent B,会立刻把层级拓扑变成网状拓扑,cascade failure 风险飙升。要交换信息必须经过主 agent。
  • 失败没有 boundary:sub-agent 抛异常没被捕获,主 agent 收到 raw exception 导致 reasoning loop 被中断、整个任务失败。失败时要返回 schema 化的 failure artifact。
  • 子任务输出本身就小还套隔离:子任务产出小于 500 token、或主 agent 确实需要看中间细节时,隔离是多余开销。它的价值在产出多、context 紧、能 schema 化输出三者同时成立时。

验证指标

  • 主 agent context 占用(健康区留足推理空间):所有 sub-agent artifact 加起来占主 agent context 的比例。50 份合同 artifact 控制在 1 万字以内、给主 agent 留 4 万 token 自己推理是一个好的目标。
  • artifact 合规率(健康区 > 95%):sub-agent 返回符合 schema 的比例。偶尔输出自由文本绕过 schema 会触发重派和延迟。
  • 失败级联率(健康区 < 5%):一个 sub-agent 失败拖垮其他 sub-agent 的概率。四件要素全做到位才能把这个指标压在健康线,缺一件就可能飙升。
  • artifact 压缩比(健康区高):raw trajectory 字数与 reduce 后 artifact 字数之比,反映隔离对 context 的节省效果。

参考实现

IsolatedSubAgent.execute(task):
    local_context = [system_prompt, task]      # 不传入 parent history → Context 隔离
    try:
        raw = run_loop(task, local_context)     # 独立 LLM call + 独立 tool set
    except: return Artifact(verdict="failure")  # 失败 boundary
    return reduce_to_artifact(raw)              # 强制压成 verdict/findings/citations

SupervisorWithSubAgents.execute(task):
    artifacts = 并行 gather(                     # N 个并行,各自独立 context → 互不干扰
        sub.execute(dispatch_subtask(task, sub)) for sub in sub_agents
    )
    return synthesize_from_artifacts(artifacts) # 主 agent 只看 artifact 不看 raw trajectory

四个工程要点对应四件要素:本地 messages 起跑实现 context 隔离;reduce_to_artifact 实现 schema 化返回;try/except 加 timeout 实现失败 boundary;并行 gather 加各自独立 context 实现互不干扰。

应用示例

某律所的合同审阅 Agent,第一版主 agent 派 sub-agent 扫描 50 份合同,sub-agent 把每份 3000 字的详细分析全部回传,主 agent 接到 15 万字后 context 完全爆炸。第二版加上四件隔离要素:每份合同分一个独立 sub-agent(context 隔离)、返回前强制 reduce 成固定 schema 的 artifact(verdict、top_3_concerns、recommendation 三字段必填)、每份合同独立 fresh review 不被其他合同 prime、某个 sub-agent 挂掉不影响其他 49 份、主 agent context 永远控制在 5 万 token 以内(50 份 artifact 加起来不到 1 万字,留 4 万给主 agent 推理)、低 confidence 的合同直接 mark 升人工。改完之后 50 份合同 1 小时跑完,主 agent 拿 1 万字 artifact 做 high-level 综合,律师 review 报告不到 1 小时。Claude Code 的 Task tool 是这个模式最完整的工业实现——子 agent 在完全独立的 context 跑(无主 agent history、独立 LLM call、独立 tool set),跑完只返回 final summary,主 agent 看不到子 agent 的中间 thinking 和 tool calls,50 次 grep 调用不会进主 agent 的 context。

相关模式

  • 层级委派(C1):共格且互为表里。层级委派是招式(supervisor 派 worker),子代理隔离是内功(worker 隔离 context 加 schema artifact 加失败 boundary)。没有隔离的层级委派必定 context 爆炸加 cascade failure,两者必须配套。
  • 扇出聚合(C2):扇出的每个并行 branch 都依赖隔离——独立 context,gather 阶段只看 reduced 结果。隔离是扇出能跑通大规模并行的工程基础。
  • Hierarchical Retention(记忆模块):同源思想。信息按层级分发、越上层越精简,子代理隔离是这个作用域分层原则在多 agent 协作层的落地。
  • 上下文分诊(感知模块):同源思路。主 agent 不预加载子 agent 的中间状态,需要时按需取(通常不需要,artifact 就够),类似延迟加载。

设计结论

子代理隔离看上去是 context 优化,本质是把组织管理里的信息分层精神编码进 agent 系统——CEO 看 manager 的 summary 不看每个员工的细节,主 agent 看 sub-agent 的 artifact 不看 raw trajectory,这是 multi-agent 系统从 demo 到生产的最后一公里。

企业证据

当前没有与本模式绑定的公开评审案例。模式定义不因此视为已经获得企业验证。

案例收录要求说明业务约束、实现结构、已知失败和迁移边界。参见 贡献与评审规则

引用建议:ADPS,《C5 子代理隔离》,Agent 设计模式白皮书 v0.3,2026-07-13。

模式目录 · 参考实现 · CC BY 4.0