Harness 工程 · 多 Agent
学习舱 / Harness 工程 / 多 Agent

Subagent 与多 Agent 编排:委托、隔离与仲裁

整理中 深度 · 应用 更新 2026-09-22

前置 Harness 概览、Agent、Subagent

Subagent 与多 Agent 编排:委托、隔离与仲裁

一句话定位:多 Agent 编排是整套 Harness 机制的汇聚点——前面七套机制(模型调用、上下文、工具、权限、记忆、Skill、状态机)都在回答「一支笔怎么写好」,本篇回答「多支笔怎么不打架」。前置:什么是 Harness、Agent 基础(四要素与三道刹车)、子代理的产品行为(委派解剖与派活两问,产品篇已讲,本篇讲机制)。

先从一次「被调研淹死」说起

你让主 Agent 调研三个框架的优缺点。它干活很卖力:读了三十个文件、跑了十几条验证命令,上下文被调研细节灌得满满当当。

等它开始写对比结论时,怪事发生了——真正需要的「三份结论」其实只占几百 token,但那三十个文件的分析过程还赖在上下文里。注意力被稀释,结论写得越来越平庸;你再让它顺手干点别的正事,它满脑子都是调研噪声,下手都不干脆。

能不能让脏活在别的房间干完,只把结论带回来?

答案是能——Subagent 的设计正为此而生:每个子代理拥有独立上下文(隔离,业界也叫 context quarantine——隔离的就是上下文,防的是主对话被过程污染)、受限的工具与权限(继承后收紧),干完只把摘要带回主对话(fork 型可继承完整上下文的例外见子代理产品篇)。当「房间」多到需要协作时,就升级成编排模式——本篇把这套机制从头讲到尾。

三种编排模式:从「派活」到「组队」 模式一 · Subagent 委托 主对话(项目经理) 子 A 调研 子 B 实验 派活 → 独立干 → 回摘要 适合:高噪声自包含的脏活 模式二 · Supervisor 工头 工头(分活与验收) 前端组 后端组 工头按进度反复分派 适合:多步骤可拆的工程活 模式三 · 分职协作 Planner 只出计划 Executor 只管执行 Reviewer 独立评审 适合:计划执行互不信任 默认仍是单 Agent——模式是升级项不是起点

图:三种编排模式——委托是主从派活,工头管反复分派,分职把计划与验收拆给不同的笔

渐进拆解

主 Agent 就是项目经理。能自己干的小活自己干(单 Agent);专业脏活外包给分包商——给清楚需求、给够工具、约好交付格式,验收时只看摘要(Subagent 委托);工地大了要请工头,按进度反复给不同班组派活(Supervisor);设计院与施工队分离、质检独立于施工(分职协作)——项目经理的合同怎么签,决定了工程的质量。

看一次三路调研的委托时序——注意每一环节对应的机制零件:

三路调研的委托与聚合 主对话拆任务 按委托合同写三份 子 A:读文档 隔离上下文 · 只读 子 B:跑实验 隔离上下文 · 沙箱执行 子 C:查社区 隔离上下文 · 网络白名单 摘要回传 结论 + 证据引用 主对话聚合 去重 · 排序 冲突标出 上下文只进结论 三个子代理互相看不见:A 不知道 B 在跑实验——隔离让三路证据彼此独立,聚合时冲突才真实 机制零件对号:独立上下文(压缩篇)· 工具白名单(工具执行)· 权限收紧(权限)· 只回结论不回过程

图:委托与聚合——主对话上下文只进结论,三个房间的过程噪声全部留在房间里

大白话:多 Agent 就是三个判断题:这个活值得外包吗——干完之后主对话更干净还是更满;分包合同要写清什么——九栏一样都不能少,少哪栏子代理就在哪栏自由发挥;结论打架听谁的——先按证据分量排,排不出高下再找人对质。

单 Agent 的边界(什么时候不编队)

编队有真实成本:每个子代理要显式喂上下文(它看不见主对话)、协调本身要花轮次、聚合可能丢细节。判断就一条——任务的噪声收益比,干完之后主对话是更干净了还是更满了。高噪声(读三十个文件)、自包含(不需要反复问主对话)、可摘要(结论远小于过程)三者齐备才值得派出去;反过来,频繁需要主对话反馈的活留在主线。

这有实证支撑:Anthropic 的多代理研究系统公开过一组工程教训——早期版本会「为一个简单查询派出五十个子代理」,模糊的委托还造成过两个子代理重复探索同一主题而第三个跑偏的浪费;后来改成按任务复杂度给编制:

  1. 简单事实核查——一个执行者,三到十次工具调用。
  2. 直接对比——两到四个子代理。
  3. 复杂研究——十个子代理以上。

编队的规模跟着任务复杂度走,不是越多越强。

三种编排模式

  • Subagent 委托:主从关系——主对话派活、收摘要,一问一答。
  • Supervisor:加一个专职工头,按进度反复给多个执行者分派与验收,适合多步骤工程活。
  • Planner-Executor 与 Reviewer:把「想」与「做」、以及「验」分给不同的笔——计划者不执行、执行者不自验。这是验证门的多笔化:评审者看不到执行者的自我感觉,只看产出。

委托九要素(合同条款)

  1. 目标:要什么。
  2. 上下文:只带需要的——自测第一问会再收一次。
  3. 工具:白名单裁剪。
  4. 权限:默认收紧,按需发放。
  5. 输出:交付什么。
  6. 格式:什么结构。
  7. 超时:多久算违约。
  8. 评价:怎么算干好了。
  9. 写限制:能动哪些、不动哪些。

九项条款是多方工程实践的综合(Anthropic 的工程博客给出其中四项:目标、输出格式、工具与来源指引、任务边界)。缺一项,子代理就多一分自由发挥的空间——而自由发挥正是返工的来源。

隔离区(quarantine)

上面说的独立上下文就是业界的 context quarantine。对高风险或高噪声任务,还可以在这层之上再加物理边界:子代理在受限环境(独立目录、受限网络)里跑,产出经「检疫」(验证与摘要)才回流主对话。它是委托的加强版:不是不信任结论,是不让过程的副作用外溢。

聚合、去重与仲裁

多路结果回流后三步走:

  1. 聚合:按约定的格式拼齐。
  2. 去重排序:与记忆召回的管线同一思想——既相关又不重复、新者优先。
  3. 仲裁:结论冲突时按证据分量定高下——一手来源压二手转述、新数据压旧数据、带验证的压凭记忆的。分量相当但可复现的,让双方重跑对质;重跑仍僵持或不可复现的,标出冲突点交给人——这不是失败,是多人协作的正常产物。

七套机制在编队下的形态(汇聚一览)

  • 调用:各自独立,重试预算按委托切分。
  • 上下文:各自独立,靠摘要回传连通。
  • 工具:注册表可按委托裁剪。
  • 权限:默认收紧,按九要素发放。
  • 记忆:分共享与私有——三级体系里的文件层共享、会话过程私有。
  • Skill:清单共享,子代理可复用流程。
  • 状态机:各自独立,主任务的状态由主对话聚合。

动手:委托合同与聚合仲裁

伪代码把九要素合同与三步聚合串起来:

def delegate(task, crew):
    brief = Brief(                          # 九要素:一份委托合同
        goal=task.goal,                     # 目标
        context=task.needed_context,        # 上下文:只带需要的
        tools=crew.allowlist(task),         # 工具:白名单裁剪
        permissions=LEAST_PRIVILEGE,        # 权限:默认收紧
        output=task.expected,               # 输出与格式
        format=task.schema,
        timeout=task.budget,                # 超时
        rubric=task.rubric,                 # 评价标准
        write_scope=task.write_scope)       # 写限制
    sub = spawn(brief)                      # 独立上下文 + 受限执行
    return sub.run()                        # 摘要回传(带证据引用)

def aggregate(results):
    deduped = dedup_rank(results)           # 去重排序(召回管线同思想)
    for c in find_conflicts(deduped):       # 冲突逐个裁
        best = evidence_rank(c)             # 一手 > 二手 · 新 > 旧 · 有据 > 凭记
        c.verdict = best if best.decisive else ask_human(c)
    return deduped                          # 冲突点与裁决理由一并入上下文

同一概念的叫法对照:

本篇用词文献中的其他叫法深挖去处
委托九要素委托合同 · 任务书(Anthropic 博客给其中四项)本篇
编排三模式工头模式 · orchestrator-worker(委托式的放大版)本篇
隔离区context quarantine(指独立上下文本身)· 物理边界同沙箱思路(DeepAgents 另有 Permissions/Sandboxes)工具执行
聚合仲裁结果聚合 · 冲突消解本篇
噪声收益比派活两问的产品视角子代理产品篇

冲突仲裁是多人协作最容易糊的一环,单独画成决策树:

两个结论打架:仲裁的先后次序 结论冲突 先别和稀泥 比证据分量 一手 · 够新 · 带验证 高下立判 采信分量重的一方 分量相当 查可复现性 可复现 重跑对质,僵持交人 不可复现 交人工裁决 裁决不是终点:裁决理由与被弃方的证据一起入上下文——被否的一方可能握着另一半真相

图:仲裁决策树——先比证据、再查复现、最后才找人;每次裁决都留档

边界与取舍:编队不是免费并行

协调成本会吃掉并行收益

三个子代理并行看着快,但写三份合同、等三路回传、聚合裁决都是主对话的轮次——总时长未必短于一个 Agent 闷头干。

token 账更直观:Anthropic 实测多 Agent 系统的 token 消耗约为普通聊天的 15 倍(单 Agent 约为 4 倍),换来的是该系统内部研究评估中超出一流单 Agent 90.2 个百分点的表现,以及复杂查询最高 90% 的时间缩短。但账要算清楚,省注意力与省 token 是两笔账,编队的正当理由是前者——把「并行」当第一理由的编队,多数会在聚合环节把省下的时间赔回去。

隔离省了 token,也丢了「看得见」(本篇第一问)

子代理看不见主对话——它不知道你已经知道了什么、之前试过什么、整个任务为什么而做。防「看不见该看的」有三条通道:

  • 委托时显式喂:九要素的 context 只装它需要的——任务背景、已知事实、约束条件,不是整个主对话的转发。
  • 回传时带证据:摘要附文件路径与记录号,主对话要深究随时可回查。
  • 共享文件当公告板:跨子代理的公共事实写进项目记忆或共享文件,谁需要谁读——避免每个子代理都靠上下文转发同一份背景。

仲裁的两种收场各有所归(本篇第二问)

证据优先级仲裁适合「事实之争」——两个版本号、两个基准分数、两个 API 行为,证据分量能分高下,机器裁得又快又可追溯;人工兜底适合「判断之争」——两个方案各有道理(架构取舍、优先级排序),或证据分量相当且不可复现(错过窗口的实验、依赖当时环境的观测)。误配的代价:该人裁的机裁,会显得武断;该机裁的人裁,是在浪费一张能自动判的牌。

坏味道预警

如果子代理回来的摘要总是「答非所问」,先查合同——九要素里大概率缺了评价标准(它不知道「干好了」长什么样);如果主对话聚合后上下文还是爆炸,查的是回传纪律——子代理把过程当结论交回来了。

自测

合上文章先自己答,再展开对照:

Subagent 隔离省了 token,但丢了什么——怎么防止子代理「看不见该看的」?

丢的是主对话的可见性:它不知道你已经知道什么、之前试过什么、任务为什么而做。防「看不见该看的」靠三条通道:①委托时显式喂——九要素里的 context 只装它需要的(任务背景、已知事实、约束),不是主对话的整体转发,喂少了它瞎猜、喂多了隔离就白设了;②回传时带证据——摘要附上文件路径与记录号等引用,主对话或复核者要深究可随时回查原始出处;③共享文件当公告板——跨子代理的公共背景写进项目记忆或共享文件,谁需要谁读,替代用上下文转发的做法。隔离的价值与代价要一起算:省下的是过程噪声的 token 与注意力,付出的是通信成本——所以高噪声、自包含、可摘要的活才值得隔离。

两个子代理结论冲突时:证据优先级仲裁和人工兜底各适用什么场景?

按「事实之争还是判断之争」分流。证据优先级仲裁适合事实之争:两个版本号、两个基准分、两个 API 行为——按证据分量定高下(一手来源压二手转述、新数据压旧数据、带验证的压凭记忆的),分量悬殊则高下立判,分量相当但可复现的让双方重跑对质,机器裁决又快又留痕。人工兜底适合判断之争与不可复现:方案取舍、优先级排序这类各有道理的价值判断,或证据相当且无法重演的观测(错过窗口的实验、依赖当时环境的结论)——硬裁会显得武断,交给人对质或拍板。共同纪律是留档:裁决理由与被弃方的证据一起进上下文,被否的一方可能握着另一半真相。

参考与延伸

  • Anthropic《Building Effective Agents》(2024-12):多 Agent 编排的评估者-执行者思路与协调原则 — anthropic.com/engineering/building-effective-agents
  • Anthropic 工程博客《How we built our multi-agent research system》(2025-06-13):多 Agent 研究系统的工程实践(orchestrator-worker 模式、15 倍 token 账、按复杂度给编制) — anthropic.com/engineering/built-multi-agent-research-system
  • Anthropic 官方文档:子代理(Subagents)的定义、配置与编排 — code.claude.com/docs/en/sub-agents
  • Pi 侧素材(2026-10-24 汇总):Armin《The Coming Loop》harness loop 理论(agent loop 之上的队列/编排/durable session 层)+ pi-durable 深读(工具调用=任务树父子所有权、effect sandwich 外部不可逆协议)+《Building Pi With Pi》的 /is 多窗口并行工作流——Pi 从「拒绝 sub-agents」到「sub-agents 的进程观+持久化编排」的演进全程 — 见「读 Pi 学 harness 27/31」与 W43 扫荡报告

至此本系列七篇机制全部讲完:调用怎么稳、上下文怎么省、工具怎么跑、权限怎么裁、记忆怎么存、流程怎么装、进度怎么保——最后汇聚到「多支笔怎么协作」。回到 Harness 总览,把拼图合上。

本节点大纲与自测题(5 个子点 · 2 问)

大纲

  • 单 Agent 的边界:什么时候不需要 Multi-Agent
  • Supervisor / Planner-Executor / Reviewer 三模式
  • Subagent 委托九要素:目标/上下文/工具/权限/输出/格式/超时/评价/写限制
  • 上下文隔离 quarantine
  • 结果聚合、去重排序与冲突仲裁

自测——答不上来就是缺口

  • Subagent 隔离省了 token,但丢了什么——怎么防止子代理「看不见该看的」?
  • 两个子代理结论冲突时:证据优先级仲裁和人工兜底各适用什么场景?