合作伙伴多，不等于交付能力会自动相加
传统软件集成通常有相对明确的边界：系统 A 提供接口，系统 B 读取数据，实施方完成配置，企业负责验收。
Agent 改变了这种静态关系。一个面向采购业务的 Agent，可能先从企业知识库读取制度，再调用第三方风险服务查询供应商，由另一个模型形成判断，最后通过 ERP 创建审批任务。不同组件不仅传递数据，还会相互委派、解释上下文和决定下一步动作。
其中任何一次交接出现偏差，最终结果都可能失败：
因此，多供应商组合的最大风险，未必是某一款产品不够强，而是局部能力很强、整体结果无人负责。
- 上游 Agent 给出了正确内容，却遗漏下游决策需要的证据；
- 两家供应商对“完成”的定义不同，一方结束任务时另一方认为信息不完整；
- 模型或工具升级后，接口仍可调用，但输出语义已经变化；
- 故障发生在多方边界，日志分散，谁都无法还原完整过程；
- 每个组件都达到了自己的技术指标，业务任务却没有完成。
开放协议解决“能连接”，没有替企业定义“如何合作”
行业已经在为 Agent 互操作建立基础。NIST 于 2026 年 2 月启动 AI Agent Standards Initiative，明确把安全、身份和互操作列为可信采用的关键条件。微软在多 Agent 架构指南中也建议使用 A2A 等开放协议实现跨平台协作，并强调最小权限、可审计性和治理。
这些标准十分重要。它们可以降低专有集成成本，让企业更容易替换模型、工具或 Agent，避免每增加一个合作伙伴都重新建设一套连接。
但协议主要回答的是 Agent 如何发现彼此、交换消息和调用能力。它们不会自动回答：
6 月发布的一项关于 MCP、A2A 和 ACP 的研究指出，现有互操作协议在成员资格、异议保留、人工升级以及审计回放等治理语义上仍存在缺口。它是一项预印本研究，不能被视为最终行业结论，但提醒企业不要把“技术上连通”误认为“组织上已经可治理”。
连接标准是底座，合作规则仍需要企业自己定义。
- 哪个 Agent 有权接受任务；
- 交接时必须携带哪些事实、来源和限制；
- 多方结论冲突时采用什么规则；
- 哪一步需要人工批准；
- 最终结果由谁验收；
- 事故、费用和业务损失如何归属。
企业需要掌握一份“AI 编排契约”
这里的契约不只是一份法律合同，也不是接口文档，而是所有参与方共同执行的业务协议。它应把一次跨系统任务如何开始、交接、判断、结束和复盘写清楚。
一份可运行的 AI 编排契约，至少应包含五类内容。
1. 任务与结果
先定义共同交付的业务结果，而不是分别采购功能。
例如，“自动生成供应商报告”过于宽泛；更可验收的定义是：“基于指定内部制度与外部数据，对新供应商完成风险初筛，输出带来源的风险项，并将高风险或证据不足的情况送入人工复核。”
只有共同结果明确，各供应商的局部指标才有意义。
2. 交接包
Agent 之间不能只传递一段自然语言。每次交接应包含结构化任务状态，例如：
这相当于数字化工作中的“交接班记录”。它既减少信息在多次摘要中丢失，也让后续责任可以定位。
3. 冲突与升级
多 Agent 的价值之一是专业分工，但专业判断天然可能冲突。风险 Agent 认为应拒绝，业务 Agent 认为可以接受；内部知识与第三方数据也可能不一致。
系统不能默认让最后一个发言的 Agent 覆盖前面的异议。编排契约需要规定哪些冲突可以按规则解决，哪些异议必须保留，何时升级给哪类人员，以及人工决定如何回写系统。
世界经济论坛 5 月发布的 Agent 可信采用指南提出 Agent Capability and Authorization Profile，用部署级档案描述 Agent 能力与授权。这类方法的价值正在于：授权不能只按“可以调用某工具”判断，还要结合任务、风险和能力边界。
4. 版本与变更
合作链中的任一方更新模型、提示、数据字段、策略或接口，都可能改变整体表现。企业应要求关键变更提前通知，并用一组共同业务样本做回归验证。
需要记录的不是只有 API 版本，还包括任务定义、输入输出结构、模型与规则、授权范围及评估结果。否则，系统虽然保持在线，业务行为却可能在无人察觉时发生变化。
5. 全链路证据
每个合作伙伴保留自己的日志还不够。企业需要能够用统一任务标识串联整条轨迹，看到任务经过了哪些 Agent、访问了什么数据、产生过哪些中间判断、发生过哪些人工干预，以及最终如何进入业务系统。
这不是为了在事故后寻找某一家供应商承担全部责任，而是为了快速区分：问题来自数据、模型、交接、权限、业务规则，还是人的处置。
- 已确认的事实与对应来源；
- 尚未验证的假设；
- 使用的数据时间和版本；
- 已执行的工具与返回状态；
- 当前置信度或规则结果；
- 禁止继续执行的边界；
- 下一方必须完成的检查。
采购时不要只评单品，还要做“组合验收”
很多企业分别对模型、云平台、行业 Agent 和集成服务进行采购评审，却没有验收它们组合后的行为。
更合理的做法，是选取若干真实端到端任务进行联合测试：
1. 正常任务能否跨供应商顺利完成； 2. 信息不足时是否安全停止并请求补充； 3. 上下游结论冲突时是否保留异议并正确升级； 4. 某个服务不可用时，任务会重试、降级还是中止； 5. 某个组件升级后，整条链的结果是否仍满足标准； 6. 企业能否从统一证据中还原一次完整执行。
联合验收还应要求所有关键参与方到场。业务部门判断结果是否有用，IT 判断集成与运行，安全团队判断身份和权限，供应商则共同解释跨边界行为。
如果一次问题只能通过多家厂商互相转交工单来定位，这套生态还没有形成真正的共同交付能力。
生态价值要按整体结果衡量，而不是按组件活跃度相加
多供应商项目容易产生大量漂亮的局部数据：模型调用量增长、Agent 数量增加、知识检索成功率提高、自动化步骤变多。但这些数字相加，并不等于业务价值。
企业更应观察：
这套指标会让合作伙伴从“证明自己的产品被使用”，转向“共同证明客户的工作被完成”。
- 端到端任务成功率，而不是单个调用成功率；
- 跨 Agent 交接的一次通过率；
- 因证据缺失、格式错误或语义冲突造成的返工；
- 从异常发生到定位责任边界所需时间；
- 供应商或模型替换的迁移成本；
- 每个完整业务结果的总成本和人工投入。
企业必须做生态的主编排者
Intel 与 Google Cloud 的合作说明，大型企业的 AI 转型越来越可能依靠多方长期协作，而不是采购一项孤立工具。Cognizant、Accenture等服务商近期与云和模型平台扩展合作，也反映出行业正在把技术平台、行业能力和现场交付组合起来。
这是一条合理路径。企业没有必要自己开发所有模型、工具和集成能力。
但企业不能把业务编排权也一并外包。只有企业自己最清楚哪些结果值得追求、哪些事实可以信任、哪些风险不能接受、哪些冲突必须由人判断。合作伙伴可以参与设计和运行，最终的共同任务定义、交接标准、授权规则与证据要求，仍应成为企业自己的资产。
未来企业 AI 的竞争，不会只是“我们接入了多少领先厂商”，而是：
我们能否让不同厂商的能力在同一套业务规则下协同，并在任何一次交接失败时，仍然知道发生了什么、由谁处理、怎样恢复。
当企业掌握这套机制，生态越丰富，能力就越强；如果缺少它，合作伙伴越多，复杂度也只会越快增长。
