// MCP、A2A 和 ACP 无法表达的内容 //

MCP 和 A2A 解决了能力发现和消息传递，但就在企业部署开始的地方止步了。

一项新研究对代理互操作性协议（MCP、A2A、ACP、ANP、ERC-8004）进行了系统性的差距分析，对照一个源自组织理论的六维治理需求分类法。这些维度包括：成员资格、审议、投票、异议保留、人工上报以及审计或回放。

这些协议支持面向任务的协调，但无法表达一个受治理的代理社区。你无法说明谁拥有投票权、如何保留异议、或者何时必须上报给人类。

论文：https://arxiv.org/abs/2606.31498

在我们的学院学习构建有效的 AI 代理：https://academy.dair.ai

代理互操作性协议中的治理空白：MCP、A2A 和 ACP 无法表达的内容

来源：https://arxiv.org/html/2606.31498

摘要

代理互操作性协议——MCP、A2A、ACP、ANP 和 ERC-8004——已迅速成熟，能够实现自主代理之间的身份识别、能力发现、工具访问和消息交换。然而，当企业部署异构代理群组，这些代理必须在治理约束下做出集体决策时，一个问题便浮现出来：这些协议能否支持受治理的代理社区，还是仅支持面向任务的协调？我们提出了一项系统性的差距分析，应用一个六维治理需求分类法——成员资格、审议、投票、异议保留、人工上报和审计/回放——该分类法源自组织理论、多代理系统文献以及企业治理标准。我们针对此分类法分析每个协议规范，将能力分为“支持”、“部分”或“缺失”。由此得出的差距矩阵显示，投票和异议保留在所有五个协议中普遍缺失；审议要么缺失，至多只是部分支持；没有协议编码了受治理代理社区所需的全套原语。我们区分了可扩展的差距（可通过协议扩展机制解决）和结构性差距（需要新的架构层），并基于观察到的协议演进速度评估了时间敏感性。该分析确立了代理社区治理构成了当前互操作性标准之上的一个缺失架构层——而非其中的一个缺失特性。

I 引言

基于 LLM 的代理在企业环境中的激增推动了互操作性协议的快速发展。模型上下文协议（MCP）1 使代理能够访问工具和数据源。代理到代理协议（A2A）2 标准化了代理之间的发现和委托。代理通信协议（ACP）3 形式化了结构化消息交换。代理网络协议（ANP）4 提供了基于图的路由和去中心化身份。ERC-8004 5 编码了链上身份、声誉和验证注册表。

这些协议共同解决了一组连贯的协调关注点：身份、能力声明、发现、工具访问、消息传递和声誉。部署代理群组的企业——AWS 报告 AgentCore 客户在一年内扩展到 17 个生产代理6——现在可以合理期望他们的代理能够互相发现、交换消息并调用彼此的能力。

然而，协调不等于治理。当银行必须决定自主编码代理是否应修改生产系统时，当制药公司必须在竞争性研究假设之间进行仲裁时，或者当监管机构必须确定 AI 系统是否符合合规阈值时，问题不是“哪个代理可以执行此任务？”，而是“代理应如何集体决定相信什么、测试什么或做什么？”这需要成员资格（谁参与）、审议（如何交换和质疑声明）、投票（如何解决立场分歧）、异议保留（少数意见如何存续）、人工上报（何时援引人类权威）和审计（过程如何可重现）。

本文提出的问题是：当前的代理互操作性协议是否编码了这些治理能力？

我们做出三项贡献：

1. 1. 一个治理需求分类法，包含六个维度（G1–G6），源自组织理论、多代理系统研究和企业治理标准，明确了受治理代理社区所需的协议级原语。
2. 2. 一个系统性的差距矩阵，将分类法应用于五个协议（MCP v1.1、A2A v1.0.1、ACP、ANP、ERC-8004），基于规范级证据将每个协议-维度对分类为“支持”、“部分”或“缺失”。
3. 3. 一个可扩展性和时间敏感性评估，区分了可通过现有扩展机制解决的差距与需要新架构层的差距，并描述了差距缩小的速度。

本文的其余部分组织如下。第二部分（https://arxiv.org/html/2606.31498#S2）介绍了五个协议及其设计意图。第三部分（https://arxiv.org/html/2606.31498#S3）推导了治理需求分类法。第四部分（https://arxiv.org/html/2606.31498#S4）呈现了差距分析和矩阵。第五部分（https://arxiv.org/html/2606.31498#S5）讨论了可扩展性、时间敏感性和影响。第六部分（https://arxiv.org/html/2606.31498#S6）将其与相关工作定位。第七部分（https://arxiv.org/html/2606.31498#S7）总结。

II 背景：代理互操作性协议

我们分析了五个协议，它们代表了截至 2026 年中代理互操作性的主要架构方法。每个协议都是针对特定的协调关注点设计的；理解这些设计意图对于公正地解释差距分析是必要的。

II-A 模型上下文协议 (MCP)

MCP 1 由 Anthropic 于 2024 年底推出，通过客户端-服务器架构标准化了 AI 代理访问工具、数据源和提示符的方式。该协议定义了三种原语类型——工具、资源和提示符——由 MCP 服务器公开并由 MCP 客户端（通常是基于 LLM 的代理）消费。MCP v1.1（模式日期为 2025-11-25）支持会话、引导、采样和流式传输。该协议在设计上以工具为中心：它回答“代理能做什么？”，而不是“代理之间应如何交互？”。MCP 已获得广泛采用，拥有超过 1,000 个社区集成，并得到 AWS AgentCore 网关的原生支持6。

II-B 代理到代理协议 (A2A)

A2A 2 由 Google 开发，并于 2026 年贡献给 Linux 基金会，使代理能够通过代理卡（描述能力、技能和端点的 JSON-LD 元数据）相互发现、委托任务和交换消息。版本 1.0.1（2026 年 5 月）引入了一个扩展机制，支持“新数据、需求、RPC 方法和状态机”7。A2A 以委托为中心：它回答“哪个代理可以处理此任务？”。有四个官方示例扩展（安全护照、时间戳、可追溯性、代理网关协议）；没有一个涉及治理。

II-C 代理通信协议 (ACP)

ACP 3 由 IBM Research 开发，形式化了结构化多代理通信，带有协商语义。ACP 定义了代理角色、消息类型和协商模式，借鉴了 FIPA-ACL 传统。它支持带有类型化执行语（提议、接受、拒绝、反提案）的多轮对话。ACP 以通信为中心：它回答“代理如何交换结构化消息？”

II-D 代理网络协议 (ANP)

ANP 4 为代理网络提供基于图的路由，使用 W3C 去中心化标识符 (DID) 进行代理身份识别。ANP 专注于在没有中心化注册表的情况下通过网络路由消息。它是以路由为中心的：它回答“消息如何跨网络到达正确的代理？”

II-E ERC-8004：无需信任的代理

ERC-8004 5 是一个以太坊改进提案（草案，创建于 2025 年 8 月），定义了三个链上注册表：身份注册表（代理地址和元数据）、声誉注册表（giveFeedback()/revokeFeedback()，带有签名的定点分数和标签）和验证注册表（通过 TEE 预言机、zkML 验证器和权益保障的重新执行进行独立验证者证明）。ERC-8004 以信任为中心：它回答“哪些代理可以信任？”它明确将范围限定为“发现、选择代理并与之交互”5。

II-F 设计意图总结

表一：协议设计意图 这些设计意图均未针对以下问题：代理应如何集体治理社区决策？

III 治理需求分类法

我们推导出一个治理需求分类法，明确了受治理代理社区所必需的协议级原语。该分类法借鉴了三类文献。

组织理论。 哈贝马斯的交往理性8将结构化论证、相互挑战和共识形成认定为合法集体决策的先决条件。议事程序9形式化了成员资格（法定人数）、结构化辩论（动议、修正案）、投票（多数规则、记录异议）和上报（程序问题）。这些直接映射到协议原语。

多代理系统研究。 奥斯特罗姆的制度分析框架10识别了公共池塘资源的治理规则：边界规则（成员资格）、位置规则（角色）、选择规则（决策程序）和信息规则（透明度）。Sierra 等人的电子机构11形式化了具有规范、角色和协议的代理社会。最近关于 LLM 代理治理的研究12, 13确认这些维度对于现代代理系统仍然相关。

企业治理标准。 监管框架包括 SR 11-7 14、ISO/IEC 42001 15 和欧盟 AI 法案16要求 AI 系统决策具有可审计性、人工监督和问责制。这些在协议层面转化为人工上报和审计要求。

通过综合，我们得出六个治理维度：

表二：治理需求分类法 (G1–G6)

III-A 充分性论证

我们认为这六个维度对于治理（而非所有协调）是必要且充分的。相关关注点要么映射到这些维度，要么属于治理范围之外：

• • 规范执行 是 G2（审议）和 G3（投票）内部的一种机制——规范通过审议过程得到执行。
• • 声誉/信任 是治理的先决条件（“谁可信？”），但其本身不是治理原语——ERC-8004 已解决此问题。
• • 资源分配 是治理决策的结果，而非治理机制。
• • 激励对齐/支付 在另一个架构层运作（经济协调，而非决策治理）。

III-B 分类标准

对于第四部分（https://arxiv.org/html/2606.31498#S4）中的差距分析，我们使用三个级别对每个协议-维度对进行分类：

• • 支持：协议规范明确定义了满足该维度完整定义的原语。
• • 部分：协议包含解决该维度要求子集的构造，但不满足完整定义。
• • 缺失：协议规范中没有解决该维度的构造。

分类基于规范编码的内容，而非理论上可以在上层构建的内容。这一区分至关重要：任何协议都可以作为治理消息的传输层，但我们评估的是治理语义是否是协议原生的。

IV 差距分析

我们现在将分类法应用于每个协议。对于每个“部分”分类，我们指明该维度的哪些子集已解决，哪些仍然缺失。

IV-A MCP v1.1

G1 成员资格：缺失。 MCP 定义了客户端和服务器，但未定义社区成员资格。没有准入、邀请或移除原语。MCP 服务器要么存在，要么不存在；没有“加入”或“被接纳进入”某个组的概念。

G2 审议：缺失。 MCP 启用工具调用，而非结构化参数交换。采样（服务器发起的 LLM 调用）存在，但不携带审议语义。

G3 投票：缺失。 没有投票原语存在。

G4 异议：缺失。 没有异议语义存在。

G5 人工上报：缺失。 MCP 的引导功能（协议版本 2025-06-18）允许服务器在工具执行期间请求人工输入，但这是用户输入征求，而非治理上报。没有协议级机制用于根据置信度阈值或风险评估将社区决策路由至人类权威。

G6 审计：部分。 MCP 会话维护连接状态，工具调用产生带有元数据的结构化响应。然而，没有防篡改事件日志、没有哈希链、没有重放保证。审计依赖于实现，而非协议规范。

IV-B A2A v1.0.1

G1 成员资格：部分。 代理卡声明能力并可在目录中注册。扩展机制支持新的状态机。然而，没有协议原生的准入、邀请或移除原语。代理通过发布代理卡而“存在”；没有与存在性不同的社区成员资格概念。

G2 审议：缺失。 A2A 支持任务委托和消息交换，但不支持带有挑战/响应语义的结构化论证。消息是面向任务的，而非审议性的。

G3 投票：缺失。 没有投票原语。四个官方扩展（安全护照、时间戳、可追溯性、代理网关协议）均未编码投票。

G4 异议：缺失。 任务响应或任何扩展中均无异议语义。

G5 人工上报：缺失。 没有用于上报至人类权威的协议机制。任务委托可以针对由人类支持的代理，但这是路由，而非带有触发条件的治理上报。

G6 审计：缺失。 可追溯性扩展添加了用于分布式追踪的相关 ID，但未定义防篡改日志或重放语义。

IV-C ACP

G1 成员资格：部分。 ACP 定义了对话中的代理角色并支持结构化多方对话。然而，角色是通信角色（发送者、接收者、调解者），而非治理角色（成员、主持人、审查者）。没有准入或移除协议。

G2 审议：部分。 ACP 的协商模式（提议、接受、拒绝、反提案）构成了带有某些挑战/响应语义的结构化交换。然而，协商是