多 Agent 如何分工不失控：任务拆分、委托协议、冲突处理与失败回收

结论：企业不应先决定“要几个 Agent”，而应先判断一项业务能否被拆成边界清楚、结果可验证、权限可限制、失败可恢复的任务。只有当不同子任务确实需要不同知识、工具或权限，而且每次委托都有输入、输出、验收、超时和升级规则时，多 Agent 才比单 Agent 或普通工作流更有价值。否则，增加角色只会放大上下文丢失、重复执行、权限越界和责任不清。

适用对象与问题背景

本文适合准备建设跨知识库、业务系统和人工审批的 AI 助手、客服协同、资料审核、报价辅助或现场服务自动化的企业负责人、产品负责人和业务负责人。这里的 Agent 指能够读取信息、调用工具、委托其他 Agent 或推动业务状态变化的软件角色，不是给同一个模型换几个角色名称。

Google Cloud 在 2026 年 8 月发布的多 Agent 委托文章提出“contract-first decomposition”：先把目标拆到可以可靠验证的程度，再决定交给谁；同时强调最小权限、成本匹配和必要的人类判断。OpenAI Agents SDK 文档则区分了两种常见模式：由一个管理 Agent 调用专门 Agent 并统一汇总，或把当前会话完整移交给另一个 Agent。Microsoft 的多 Agent 指南进一步指出，只有子任务需要独立工具、知识或治理边界时，才值得拆成单独 Agent；否则从一个 Agent 开始更简单。

这些资料共同支持一个产品判断：多 Agent 不是组织架构的数字复制，而是一组有明确责任和交付证据的软件边界。

先判断是否真的需要多 Agent

以下情况通常先用确定性工作流或单 Agent：

• 输入类别有限，路由规则可以用代码清楚表达；
• 所有步骤使用同一份知识、相同权限和同一套验收标准；
• 后一步必须严格依赖前一步，流程很少变化；
• 一个 Agent 已能稳定完成任务，新增角色只是在重复阅读同一批资料；
• 任何错误都必须由人复核，Agent 之间的自由协商并不能减少人工工作。

以下情况才值得进入多 Agent 验证：

• 不同子任务需要相互隔离的知识源或工具，例如合同规则、设备资料和订单系统；
• 不同角色必须拥有不同权限，例如一个角色只能查资料，另一个只能创建待审核草稿；
• 任务可并行处理，且结果可以独立验收后再汇总；
• 执行中才会暴露所需专业能力，无法在请求开始时固定路由；
• 同一专门能力会被多个业务助手重复调用，适合形成可复用服务。

如果真实目标只是“分类后查一个知识库”，定制软件可以用规则、检索和一个 Agent 完成。不要为了展示复杂度把每个步骤都包装成 Agent。

每次委托都要有六项任务合同

1. 任务边界

写清要解决的问题、允许使用的资料、明确不做的事项和完成条件。不要只发送“帮我处理一下客户问题”。更可验收的委托是：“根据已批准的保修条款和设备序列号判断是否进入保修审核；不得承诺赔付，不得修改订单。”

2. 最小输入

子 Agent 只得到完成任务所需的字段和上下文。工资核对 Agent 不应把整份薪酬表交给负责格式化邮件的 Agent；售后 Agent 也不应把客户全部历史订单传给只需检查一个产品型号的资料 Agent。最小化既减少敏感数据暴露，也避免无关上下文干扰判断。

3. 结构化输出

输出至少包含结论、依据、置信或不确定原因、使用的来源版本和下一步建议。需要系统继续处理时，使用固定字段和枚举，不让下游从一段自由文本猜测状态。没有找到证据与确认“不符合条件”是两种结果，必须分别表达。

4. 验收方法

委托方在执行前就知道怎样判定结果合格：字段是否齐全、来源是否在允许清单、金额是否与系统记录一致、规则版本是否有效、是否需要人工签字。无法自动验收的部分应明确进入人工判断，不能假设另一个 Agent 会“凭感觉复核”。

5. 权限与成本预算

为每个 Agent 分配独立身份、可调用工具、数据范围、最大步骤、时间和费用预算。读取资料、创建草稿、正式提交、退款和删除数据应是不同权限。高风险动作默认要求人批准，不能因为上游 Agent 表示“已经确认”就继承更高权限。

6. 失败与升级规则

定义超时、无结果、冲突、工具错误、重复请求和部分成功分别进入什么状态，以及由谁接管。委托链不能无限向下扩展；达到深度、时间或成本上限后，应停止并保留现有证据，而不是继续生成新的 Agent 尝试碰运气。

四种常见编排方式怎样选

方式	适用情境	主要控制点
确定性顺序	步骤已知，后一阶段依赖前一阶段	用代码控制顺序、输入模式和停止条件
并行汇总	多个独立来源或专业判断可以同时完成	结果分别保存；汇总前检查缺失、重复与冲突
管理 Agent 调用专门 Agent	需要统一对外答复或统一护栏	管理 Agent 保留最终责任，子 Agent 不直接提交结果
动态移交	执行中才识别出所需专业角色	移交条件、上下文筛选、接收确认和返回路径必须明确

已知流程不应默认交给模型自由规划。OpenAI 的编排文档明确指出，代码编排在速度、成本和表现上更确定；Microsoft 的架构指南也建议，当路由可以预先判断时使用简单分派，而不是动态移交。企业可以把不确定判断交给模型，把付款、写库、权限检查和状态迁移保留在确定性代码中。

冲突不能靠“多数 Agent 投票”自动解决

多个 Agent 给出不同结果时，先判断冲突类型：

• 来源冲突：按已批准的来源等级、发布日期和适用范围处理，不按回答数量取多数；
• 数据冲突：回到业务系统主记录和查询时间，确认是否读取了不同版本；
• 规则冲突：停止高风险动作，交给规则负责人决定适用版本；
• 判断冲突：保留各自依据，由明确的裁决角色或人工按同一验收标准复核；
• 动作冲突：在执行前由唯一写入者检查当前状态、幂等键和并发锁。

“裁判 Agent”本身也不能凭空增加事实。它只能按既定来源和规则比较证据；材料不足时应返回待确认，而不是为了让流程继续而强行选一边。

失败回收要设计成业务状态，而不是重新提问

多 Agent 流程至少要区分待执行、执行中、待人工、成功、失败、补偿中和已终止。每个状态保存任务 ID、输入版本、执行角色、工具调用、输出、错误和时间。恢复时从最近一个已验收检查点继续，不把整条链重新运行。

对会改变外部系统的动作使用幂等键。例如同一售后申请只能创建一个工单；网络超时后先查询工单是否已经存在，再决定是否重试。若前半段已成功、后半段失败，补偿动作也要明确：可以撤销草稿、释放预留或转人工，但不能假设所有外部动作都能无损回滚。

并行 Agent 不应同时修改同一条业务记录。若确有必要，由一个写入服务集中校验版本并提交，其他 Agent 只返回建议。这样即使某个 Agent 超时或重复执行，也不会直接制造两份订单、两次通知或相互覆盖的状态。

一个明确的假设场景

以下是方法示例，不是客户案例或实测效果。假设一家设备服务企业希望让 AI 协助处理售后申请，可以采用：

1. 管理 Agent 读取申请并生成稳定任务 ID，只负责分派和汇总；
2. 产品资料 Agent 只读设备型号、手册和故障说明，返回对应证据；
3. 保修规则 Agent 只读有效合同和保修条款，返回适用版本与不确定项；
4. 订单 Agent 只查购买记录，不向其他 Agent 暴露无关客户历史；
5. 三方结果一致且字段完整时，工单服务创建“待审核”草稿；
6. 资料缺失、规则冲突、超过授权范围或涉及赔付时，进入人工队列；
7. 人工确认后才由单一写入服务变更正式状态并通知客户。

这里的关键不是使用了三个子 Agent，而是每个角色的知识、权限、输出和失败路径不同，而且正式动作仍由确定性服务控制。如果三项查询都来自同一个数据源且规则固定，一个普通服务加单 Agent 可能更简单。

上线验收清单

• 每个 Agent 有唯一职责，不与其他角色重复读取同一知识并给出同一种答案；
• 每次委托记录任务 ID、父任务、输入版本、允许工具和验收条件；
• 子 Agent 只接收最小必要上下文，敏感字段和无关历史不会沿链路扩散；
• 读取、草稿和正式写入使用不同身份与权限；
• 每种输出都有固定状态，未找到、冲突、拒绝和失败不会被合并成“已完成”；
• 并行结果有明确的汇总和冲突规则，不用多数票替代证据；
• 外部写入具备幂等检查，并能识别未知结果后先对账；
• 超时、成本、步骤和委托深度都有上限；
• 高风险动作有清楚的人类批准点，批准内容与实际提交内容一致；
• 可以从一次最终结果追到各子任务、来源、工具调用和人工决定；
• 代表性测试覆盖正常、资料缺失、权限不足、规则冲突、工具超时和重复请求；
• 上线后持续统计任务完成率、人工接管、冲突、重复动作、超时和单次合格结果成本。

常见误区与长期维护

按部门设置 Agent 就完成了架构。 部门名称不能代替软件责任、知识范围和权限边界。

Agent 越多，结果越可靠。 如果多个角色共享同一来源、同一模型和同一错误假设，只会重复产生相同结论并增加费用。

让模型自己讨论到一致。 没有来源优先级和停止条件的讨论可能消耗更多时间，却不能解决事实冲突。

失败就整条重跑。 这会重复外部动作、放大成本，并让已经人工批准的内容发生变化。

日志越全越好。 追踪需要足够完整，但提示词、附件和工具参数可能含敏感信息；日志应分级、脱敏、限权并设置保存期限。

上线后，每次新增 Agent、工具或知识源都要重新检查数据流、权限、任务合同、冲突规则和恢复路径。业务规则变化时先更新版本与评测样本，再发布编排变更。多 Agent 的成熟度不以角色数量衡量，而以失败能否被看见、限制和恢复衡量。

如果企业仍在判断单 Agent 是否已经足够，可结合AI 项目价值判断框架先建立任务基线；需要规划上线后的质量证据时，再参考AI 客服或业务助手验收方法确定业务结果、失败类型和人工复核范围。

参考来源

• Google Cloud：How agents can delegate better：提出可验证的任务拆分、成本匹配、敏感数据最小权限和委托链中的必要质疑机制。（发布：2026-08-21；访问：2026-09-17）
• OpenAI Agents SDK：Agent orchestration：区分管理 Agent 调用专门 Agent、动态移交和代码编排，并说明代码编排在速度、成本与表现上的可预测性。（访问：2026-09-17）
• Microsoft Learn：Multi-agent orchestration patterns and best practices：说明单独 Agent 的适用边界，以及数据移交、权限、审计和父子会话关联要求。（访问：2026-09-17）
• Microsoft Azure Architecture Center：AI Agent Orchestration Patterns：比较顺序、并行、移交等模式的适用和不适用条件。（访问：2026-09-17）

本文提供产品范围与验收框架。具体模型、平台能力和接口会变化，正式方案应以目标系统、实际权限、代表性业务样本及当期供应商文档验证。