从零开始搭一个企业级 Agent Harness8/10：一个 Agent 不够时，要不要增加更多 Agent？

上一章，我们学会用同一组题检查一个Agent。带着这套评测方法，现在回到采购任务：比较三家供应商。价格研究需要查报价、税费和付款条件；合规审查需要读数据驻留、安全证明和合同条款。两条线使用不同资料，也可以同时进行。这里的数据驻留，指的是客户数据保存在哪个国家或地区；它会影响供应商是否满足公司的采购要求。

并行工作不等于必须增加Agent。同一个主Agent也可以按需加载价格与合规两份Skill，也就是专业流程说明；它在同一轮同时调用报价工具和合同查询工具，再把结果留在同一个上下文里。每个工具继续在代码里检查数据范围、动作权限和审批条件。

这里的单循环，就是由同一个Agent连续读结果、判断下一步并调用工具。所以我先跑单循环，再把确实需要独立上下文、独立核验或并行探索的部分拆出去。如果只是把同一份混乱任务复制给多个Agent，再让它们自由讨论，我们得到的往往不是分工，而是一场没人知道该由谁结束的会议。

先证明这件事值得拆

我先用单Agent跑同一组采购任务，记录完成率、延迟、成本和越权阻断。再把价格研究与合规审查拆开，用同一组任务比较。比较的终点仍是一份有证据的采购建议；子任务各自写得漂亮，却没能回答最终问题，也不算拆分成功。

只有出现具体收益，拆分才成立：两个分支需要独立上下文并安全并行；单循环已经出现可测的上下文拥挤或选错工具；一方要做不受主流程影响的独立核验；或者另一边本来就是拥有独立身份与运行生命周期的系统。仅仅因为资料由不同团队维护，或者工具权限不同，还可以先用Skill分工，并让每个工具在代码里检查权限。

所以，先保留单Agent的成绩单。拆开以后有没有更好，要拿相同任务比较，而不是数参与的Agent有几个。

2026年10月的新建议：先把多余的Agent合回来

Anthropic的Diane Sarkis在2026年10月22日发布的文章里指出，不少企业照着组织结构给每个团队造一个子Agent。结果是上下文在交接中丢失细节，每层调用增加延迟，各团队的局部评测都很好，整条任务的质量却没人负责。

她给出的替代路线，是先让一个主Agent保留规划与执行所需的共同上下文。专业流程、规则和判断放进Skill；读取实时数据、执行动作和返回固定格式结果放进工具。主Agent先看到简短说明，需要时再加载完整Skill或工具定义，也能在同一轮并行调用多个工具。它自己写计划，也根据新结果调整计划；价格结果可以直接影响合规判断，不必先压成一段交接摘要。

文章也保留了子Agent的位置：相互独立的并行任务、需要隔离的上下文、独立核验或模块化权限。放回采购任务，我会先建立端到端评测，一次只把一个子Agent合回主循环，对照质量、成本和延迟，并查看具体哪道题从通过变成失败；同一道题重复运行后，再决定保留还是合并。授权、审批和数据范围继续由工具与政策代码强制执行。

用两张工单代替一句“你们商量一下”

接下来，我把一种值得用评测验证的拆分方案展开：价格研究和合规审查各自使用一份独立上下文，只带上本分支要读的材料与工作记录，交回结论时再附上来源。合规审查由独立系统执行。我让负责总任务的Agent写两张工单。这个负责分派、跟进和汇总的角色，叫Orchestrator。

价格工单写清三家供应商、允许读取的报价和税费资料、交付格式、预算与截止时间。合规工单只提供合同与安全材料，要求引用正式来源，禁止发送消息或修改记录。两张工单都标明属于哪个总任务、能做什么、怎样算完成，以及报告交到哪里。

图里的两条分支就是价格研究（Price research）和合规审查（Compliance review）。每个Agent拿到自己的范围、工具、预算和期限。这里的合规审查由一个独立系统执行，并有自己的身份与运行生命周期，所以工单通过A2A协议送过去；如果只是另一团队维护一份合规Skill，主Agent可以直接按需加载，不必多造一个Agent。

报告回来以后，先经过核验者（Verifier）：价格计算对不对，合同证据能不能支持结论，两份报告有没有冲突。检查通过，总任务Agent才汇总建议。图里的取消线同时通向两边，表示用户取消采购后，两位执行者都要停下来。

如果你还想系统看多Agent适合什么任务、提示词怎样写清协作边界，以及上下文、并行和故障恢复怎样处理，我在《构建高效的多智能体系统：实践中的经验总结》里做了完整总结。这里继续沿着采购任务看委托责任：任务交出去以后，仍要有人把证据和结果收回来。

Delegation contract：总任务Agent交给执行Agent的结构化任务边界，包括输入、交付物、权限、预算、截止时间和验收标准。

分工以后，谁负责把事情收回来？

任务发出以后，Orchestrator保存哪些工单已经派发、哪些结果已经返回、截止时间与取消状态。

价格报告先交回来，总任务只记“部分完成”，继续等合规结果。合规审查超时，负责人决定取消剩余任务、调整安排或交给人处理。两份报告结论冲突，核验者回到合同和报价原文找证据。大家都同意一个结论，并不等于这个结论有依据。

负责拆分任务的程序先检查工单有没有写清输入、范围和交付物。工单无效时，在原授权范围允许的情况下退回单Agent执行；若某项审查必须独立完成，就暂停补齐安排。两张工单让不同Agent重复做同一件事时，则先重新划分范围。总预算分给各个执行者，每次调用都关联回原任务。这样才能算清整次采购研究的花费，而不会漏掉某个子任务反复调用模型的成本。

执行者多了，就用能力目录寻找合适的人选；这份目录记录哪个Agent会做什么、怎样联系它。工单交给另一个团队，连同身份和委托范围一起核对；总任务取消，把停止指令与凭证撤销传给每个子任务。这些都归总任务负责人管理。

四种协作方式，交接责任不同

请先看“交出去以后，谁继续负责”。叫价格Agent查资料，报告交回来后由我继续处理，这是子Agent调用（Subagent call）。把客户转给专门处理退款的Agent，接下来由它与客户对话，这是交接（Handoff）。

再看“对方在哪里”。给另一个团队独立部署的合规Agent发送工单，可以用A2A；查询数据库或调用邮件工具，可以用MCP。前者交换任务和交付物，后者提供工具与资源接口。

同一个应用里，OpenAI Agents SDK可以执行handoff或把Agent当工具调用；LangGraph、Microsoft Agent Framework和Google ADK帮助应用保存多个步骤之间的状态。跨到另一个独立系统时，A2A负责发现对方、交付任务和接收报告；这里的“发现”就是找到能接这类工单的Agent及其访问地址。连接数据库、搜索或邮件工具时，使用MCP。

Handoff：当前Agent把后续控制权和用户交互责任转交给另一个Agent。

2026年的进展：跨Agent工单有了稳定协议

A2A Protocol规定独立Agent系统怎样介绍自己、接受任务、交回结果。合规系统用能力卡片（Agent Card）公布自己能审什么；采购Agent提交任务（task），再接收作为交付物（artifact）的报告。双方按协议交换这些信息，各自维护内部提示词和执行状态。

A2A v1.0在2026年3月12日发布，成为第一条正式可用于生产的稳定协议线，支持不同通信方式、协议版本协商、多个客户组织，以及带签名的能力卡片；5月又发布1.0.1修正版。放到合规工单上，这些能力帮助两套系统先确认“用什么方式说话、代表哪个组织、这张能力卡片来自谁”，再交付任务。

协议解决怎样发现与交换工单，不替采购团队决定谁能读合同、什么结果算合规、超时由谁负责。签名Agent Card帮助检查卡片和发布者完整性，当前用户是否允许委托仍由Policy判断，产物仍由Verifier验收。

Anthropic在2026年8月13日公开多Agent系统研究，展示了多个Agent争用同一资源、互相附和错误结论、轻信恶意协作者，以及协作受隐私限制等问题。它提醒我们：Agent能互相说话以后，真正困难的是可靠分工、限制和验收。

Anthropic公开的research system也提供了一个适用案例。负责总任务的Agent把研究问题拆开，交给不同专长的子Agent并行探索，再汇总证据；官方在内部research eval与特定配置中报告过相对单Agent 90.2%的提升，同时说明多Agent的token消耗约为普通聊天的15倍。它的核心收益来自多个独立上下文并行探索，再把压缩后的结果交回总任务负责人；这适合价格研究这类宽度优先的任务，采购与支付流程仍要用自己的对照实验判断。

A2A：面向独立Agent系统之间发现、消息、任务和产物交换的互操作协议。

回到这次供应商比较

价格研究Agent按时交回标准化比较表，合规审查Agent交回带正式来源的数据驻留证据。Verifier分别检查金额计算和来源有效性，Orchestrator再把两份报告合成一份采购建议。

如果合规审查Agent没有证据，系统保留价格结果，却不会把整个任务标记完成；如果用户取消采购，两个执行Agent同时收到停止指令。多Agent带来的收益来自并行与隔离，结束权仍然留在原任务契约和Verifier手里。

前八篇的部件到这里都有了出现理由。下一篇把它们装进同一张企业架构图，再让第一篇的退款任务从入口走到最终证据。