阿布尔·艾特什姆
肯特州立大学
肯特，俄亥俄州，美国
aehtesha@kent.edu

阿迪蒂·辛格
克利夫兰州立大学
克利夫兰，俄亥俄州，美国
a.singh22@csuohio.edu

高拉夫·库马尔·古普塔
杨斯敦州立大学
杨斯敦，俄亥俄州，美国
gkgupta@student.ysu.edu

萨凯特·库马尔
东北大学
波士顿，马萨诸塞州，美国
kumar.sak@northeastern.edu

摘要

由大规模语言模型（LLM）驱动的自主代理需要稳健且标准化的协议来集成工具、共享上下文数据并在异构系统中协调任务。临时集成难以扩展、保障安全并跨领域推广。本综述考察了四种新兴的代理通信协议：模型上下文协议（MCP）、代理通信协议（ACP）、代理到代理协议（A2A）和代理网络协议（ANP），每种协议都在不同的部署环境中解决了互操作性问题。MCP 提供了一个 JSON-RPC 客户端-服务器接口，用于安全的工具调用和类型化数据交换。ACP 引入了通过多部分消息和异步流支持多模态代理响应的 REST 原生消息传递。A2A 通过基于能力的代理卡实现点对点的任务外包，促进企业级工作流。ANP 使用去中心化标识符（DID）和 JSON-LD 图形支持开放网络中的代理发现和安全协作。这些协议在多个维度上进行了比较，包括交互模式、发现机制、通信模式和安全模型。基于比较分析，提出了一条分阶段采用路线图：从 MCP 开始进行工具访问，接着使用 ACP 进行多模态消息传递，使用 A2A 进行协作任务执行，并扩展到 ANP 以实现去中心化的代理市场。本研究为设计安全、互操作性强且可扩展的 LLM 驱动代理生态系统提供了全面的基础。

关键词 大型语言模型（LLMs）、代理通信、互操作性协议、模型上下文协议（MCP）、代理通信协议（ACP）、代理到代理协议（A2A）、代理网络协议（ANP）、自主代理、多模态消息传递、去中心化身份（DID）

1 引言

大型语言模型（LLMs）已成为现代人工智能的核心，驱动着在云端、边缘和桌面环境中运行的自主代理 [1, 2]。这些代理 [3] 吸收上下文信息、执行任务并与外部服务或工具交互。然而，不一致且碎片化的互操作性实践使得在 LLM 驱动的代理之间整合、保护和扩展通信变得困难 [4]。
互操作性（不同代理和系统无缝发现能力、交换上下文和协调行动的能力）对于模块化、可重用和有弹性的多代理 [5] 工作流至关重要。标准化协议
减少开发开销，提高安全性并实现跨平台协作。明确且普遍采用的标准仍处于起步阶段。

本综述考察了四种新兴的代理通信协议，每种协议针对不同的互操作性层级：

• 模型上下文协议（MCP）：一个 JSON-RPC 客户端-服务器接口，用于安全上下文吸收和结构化工具调用 $[6,7,8]$。
• • 代理到代理协议（A2A）：一个基于 HTTP 和服务器发送事件（SSE）的点对点框架，通过基于能力的代理卡实现企业规模的任务编排 [9]。
• • 代理通信协议（ACP）：一个 REST 原生表演性消息层，具有多部分消息、异步流和可观测性功能，适用于本地多代理系统 [10]。
• • 代理网络协议（ANP）：一个基于去中心化标识符（DIDs）和 JSON-LD 图形的去中心化发现和协作协议，用于开放互联网上的代理市场 [11, 12]。
    对每种协议的架构细节、集成方法、通信模式和安全考虑进行了审查。对比突出了交互模式、发现机制、通信模型和安全框架之间的权衡。分阶段采用路线图按顺序安排 MCP、A2A、ACP 和 ANP 的应用，以指导现实世界代理生态系统的逐步部署。

本文其余部分组织如下。第 2 节讨论代理互操作性面临的挑战。第 3 节回顾背景及相关工作。第 4 至第 7 节分别描述了 MCP、A2A、ACP 和 ANP 的架构。第 8 节呈现了比较评估。第 9 节概述了分阶段采用路线图。第 10 节总结全文并建议未来的研究方向。

2 代理协议互操作性中的挑战与解决方案

尽管出现了 MCP、ACP、A2A 和 ANP 等多种开放协议，但在实际 AI 系统中实现无缝代理互操作性仍然是一个非平凡的任务。本节识别了基于代理架构中遇到的关键挑战，并强调了每个协议如何通过量身定制的设计原则解决这些问题。
缺乏 LLMs 的上下文标准化：大型语言模型（LLMs）需要上下文基础才能产生准确的输出。然而，现有的应用程序架构没有提供统一的机制来向 LLMs 提供结构化上下文，导致临时工具集成和不可靠的行为。解决方案：模型上下文协议（MCP）通过标准化应用程序如何向 LLMs 提供工具、数据集和采样指令来解决这一问题，类似于 AI 的 USB-C。它支持灵活的即插即用工具、安全的基础设施集成以及跨 LLM 供应商的兼容性。
异构代理之间的通信障碍：企业系统通常由使用不同堆栈和框架构建的代理组成，导致孤立行为和较差的合作。解决方案：代理通信协议（ACP）提供了一个 RESTful、可选 SDK 的接口，在 Linux 基金会下进行开放治理。它实现了以异步为主的交互、离线发现和供应商中立的执行，弥合了大规模互操作性差距。

图 1：针对代理通信挑战的协议对齐解决方案
缺乏统一的代理协作标准：即使代理能够通信，也没有共享框架来进行动态协商、能力共享和协调。解决方案：Agent2Agent（A2A）协议引入了一个多模态通信标准，以解锁不透明、自主代理之间的动态交互——无论框架如何。它简化了企业集成并支持共享任务管理和用户体验协商。
互联网无关的代理通信：现代互联网针对人类交互进行了优化，但对需要低延迟、API 原生通信和去中心化身份验证的自主代理来说并不理想。解决方案：代理网络协议（ANP）提供了一个分层协议架构，结合去中心化身份（W3C DID）、语义网原则和加密通信，以促进开放互联网上的跨平台代理协作。

这些协议共同目标是将分散的 AI 生态系统转变为强大、安全且可互操作的代理网络——可在组织和供应商边界内扩展。详见表 7 的详细对比概述。

3 背景及相关工作

由大规模语言模型（LLMs）驱动的自主代理正迅速被各行业采用，以自动化复杂任务，然而分散的框架和临时集成阻碍了强大的互操作性、安全性和可扩展性 $[2,4]$。最近的调查开始表征 LLM 基础多代理系统的景观，分类协作模式、记忆架构和编排策略 [13, 14, 15]。然而，这些工作主要关注高层次的工作流程，忽视了动态对等发现、能力协商和安全工具调用所需的底层协议。
有效的互操作性——使代理能够发现能力、共享上下文和协调行动——对于构建模块化、可重用和有弹性的多代理系统至关重要。早期的动态发现努力引入了元数据清单和能力描述符，允许运行时代理注册和查找 [16]，而最近关于自动化工具测试框架（例如 TOOLFUZZ）的工作强调了确保跨演变 API 表面兼容性的挑战 [17]。然而，还没有出现统一的协议来指定代理应如何宣布其接口、验证对等方或在异构 LLM 框架中协商上下文共享。
为应对这一空白，最近提出的 Model Context Protocol (MCP)、Agent Communication Protocol (ACP)、Agent2Agent Protocol (A2A) 和 Agent Network Protocol (ANP) 瞄准定义用于上下文摄取、表现性消息传递和基于 JSON-RPC 架构的对等发现的轻量级、正式接口 [6, 10, 9, 11, 12]。每种协议都进行了详细审查，随后进行了比较分析和它们在新兴多代理生态系统中的集成路线图。

3.1 AI 代理：定义与范围

$AI$ 代理被定义为任何通过输入（如用户查询、传感器数据）感知其环境并通过输出（如 API 调用、消息）对其采取行动以实现指定目标的自主软件实体 [18]。代理在其环境中运行，该环境沿可观测性、确定性、片段性和动态性等维度进行特征描述，并可能使用传感器和执行器与物理或虚拟世界模型进行交互 [18, 19]。
根据 Franklin 和 Graesser 的分类法，代理可以根据自治性、社交性、反应性和适应性等属性进行分类，反映其在开放、多代理设置中的功能 [20]。Jennings 强调在不确定性下主动生成目标、复杂规划和稳健恢复能力是与简单反应程序的关键区别特征 [21]。Wooldridge 进一步确定了四个核心属性——自治性、社交能力、反应性和主动性，使代理能够在无人直接干预的情况下运行、与对等方协作并追求长期目标 [19]。
代理架构从简单的基于规则的反应模型跨越到丰富的审慎框架，如信念-愿望-意图（BDI）系统，支持符号推理、动态计划执行和意向重新考虑。在多代理系统中，通过通信协议、协商策略和组织结构实现协调，为需要强大互操作性、安全性和可扩展性的 LLM 动力生态系统奠定基础。这一广泛而精确的定义支撑了我们随后对通信标准、编排框架和协议设计的审查。

3.2 早期符号代理语言——代理通信标准的演变

第一批正式的代理消息语言出现在 20 世纪 90 年代初，目标是为知识型系统提供标准化的“信封”和表现性词汇。Genesereth 和 Ketchpel 提出的知识查询和操纵语言（KQML）定义了一组言语行为表现形式（例如 ask-if、tell、reply），以及一个灵活的消息信封，支持诸如 : content、: language、: ontology、: receiver 和 : reply-with 等参数。KQML 还指定了内容语言绑定（通常是 KIF），以机器可解释的形式表达命题 [22, 23]。尽管在 DARPA 的开放知识库和代理项目中广泛使用，KQML 缺乏表现形式的形式语义和重量级 XML 样式编码限制了大规模部署。
基于 KQML，智能物理代理基金会于 2000 年批准的 FIPA 代理通信语言（FIPA-ACL）通过规定基于代理心理状态（信念、愿望、意图）的精确前/后条件语义改进了交际行为的概念。FIPA-ACL 定义了更丰富的一组表现形式（例如 agree、refuse、request），标准化了内容语言（例如 SL0、SL1），并概述了合同网、迭代合同网和订阅/通知等常见模式的交互协议 [24]。在 JADE 和 JACK 等平台中的参考实现提供了基于 Java 的代理容器和消息处理 API，然而 FIPA 本体管理的复杂性以及冗长的 XML 编码将其使用限制在学术和国防用例而非轻量级、行业级系统。

3.3 面向服务的集成和检索增强生成

2000 年代初期见证了面向服务架构（SOA）的兴起，其中企业系统将功能作为 Web 服务（SOAP、WSDL、WS- ${}^{\circledR }$ 标准）暴露，并在 UDDI 注册表中注册端点 [25]。消息中间件和企业服务总线（ESBs）如 Apache Camel 和 Mule ESB 促进了协议桥接、消息路由和有效负载转换，利用了内容路由、消息拆分和聚合等模式 [26]。虽然 SOA 和 ESBs 将服务生产者与消费者解耦，但随着 API 的演变和安全要求的收紧，它们往往带来了高运营复杂性、脆弱的适配器和配置蔓延。
随着大规模语言模型的出现，检索增强生成（RAG）在 2020 年问世，通过将密集向量检索与自回归解码相结合，将外部知识集成到生成管道中 [27]。RAG 系统在共享嵌入空间（如 DPR）中对查询和文档进行编码，以获取顶级- $k$ 相关段落，然后在检索到的上下文条件下调整 LLM 输出，以减少幻觉并实现动态知识更新 [28]。尽管提高了事实性和灵活性，RAG 框架将检索和生成视为单独的批处理过程，并未规定 LLM 应如何将接地内容转化为可执行动作或编排多步骤工作流——这凸显了需要协议级别的标准来统一知识接地与动作调用。

3.4 LLM 代理和函数调用

大规模语言模型（LLMs）如 GPT-3.5、GPT-4、Claude 和 Gemini 的快速演变从根本上改变了代理设计，使零样本和少量样本理解复杂自然语言指令成为可能，而无需专门的规则引擎 [2]。这些基础模型可以解析用户意图、规划多步骤工作流，并在不同领域中保持对话连贯性，打开了“LLM 代理”将语言推理与外部工具执行相结合的大门。
为了实现工具使用，OpenAI 在 2023 年引入了函数调用，这是一种轻量级协议，LLM 可以输出对应于预定义 API 端点的 JSON 格式签名 [29]。在此范式下，开发人员向模型提供一个函数定义目录——每个函数由名称、JSON 模式定义参数和描述性帮助文本描述——模型在生成时决定是否调用函数，发出格式良好的 JSON，下游系统可以解析和执行。这种方法统一了自然语言理解和动作调用，使单个 LLM 响应中实时获取数据、查询数据库和执行事务操作成为可能。
在此核心功能的基础上，出现了几种框架以简化代理开发：

• LangChain 提供了用于链式 LLM 调用、内存缓冲区和函数调用的抽象，支持模块化工作流，并内置支持检索器、矢量存储和代理循环 [30]。
• • LlamaIndex（前身为 GPT Index）专注于将 LLM 与自定义知识库集成，提供文档加载器、索引包装器和“工具注册表”，将用户查询映射到 API 调用 [31]。
• • OpenAI 插件商店允许第三方工具提供商注册公开 RESTful 接口、元数据和身份验证流程的插件，这些插件可以被任何具有插件访问权限的模型发现和调用 [32]。
    尽管取得了这些进展，当前的函数调用生态系统存在几个局限性。工具定义通常是静态的：每当添加新 API 或更改模式时，代理必须重新初始化，防止真正
    表 1：轻量级 LLM 代理框架

框架	核心功能	参考
CrewAI	高级“团队”抽象，用于角色分配、子任务委派、 和代理之间的消息路由	$[38]$
SmolAgents	单文件 Python 库，结合检索、视觉和代理循环 原语进行快速原型设计	$[39]$
AG2（AutoGen）	开源 AgentOS，具有人在环检查点、政策 执行钩子和生命周期管理	$[40]$
Semantic Kernel	企业级 SDK，统一内存存储、规划模块和 跨会话的插件编排	$[41]$
Swarm	通过 JSON-RPC 常规实现无状态多代理协调，生成和 聚合并行代理任务	$[42]$

动态发现。安全边界——如身份验证令牌、速率限制和访问控制——是临时的且特定于框架，增加了未经授权调用的风险。此外，每个框架采用自己的元数据约定，阻碍了跨框架工具的重用，并需要定制适配器以实现互操作性 [33]。解决这些挑战需要协议级别的标准来规定通用的函数元数据模式、动态能力协商以及跨异构 LLM 代理平台的端到端安全保证。

3.5 编排和轻量级代理框架

最近的发展扩展了 LLM 的能力，不仅包括推理，还包括外部工具调用的编排。Toolformer 采用了一种自我监督的掩蔽策略，在预训练期间暴露潜在的 API 调用，使模型能够学习何时以及如何调用函数作为其文本生成的一部分 [34]。ReAct 交错链式思维推理与显式动作调用，允许模型根据中间观察结果在“思考”步骤和工具调用之间交替 [35]。这些方法在单代理级别统一了推理和动作，但没有解决对等发现或多代理协调的问题。
补充这些算法技术，出现了几种轻量级框架以最小的样板代码支持多代理编排（表 1）。额外的编排系统，如 AutoGPT 的自主循环 [36] 和 Reflexion 的迭代自我改进机制 [37]，强调了反馈和适应在代理工作流中的价值。然而，这些框架继续依赖静态工具注册表和定制通信层。在这些方法中，缺乏标准化协议来宣传能力、对等认证和跨框架组合，导致了碎片化——阻碍了连贯、可互操作的代理生态系统的出现。

3.6 协议演变时间轴

代理互操作性的演变通过可视化时间轴（图 2）和详细表格（表 2）展示。时间轴捕捉了高级里程碑，而表格提供了技术细节，描述了每次发展及其关键贡献。这些表示共同概述了互操作性标准和协议随时间的变化轨迹。
三个不同的演化阶段显现：

1. 符号和 SOA 基础（1993-2006）：早期的互操作性标准如 KQML 和 FIPAACL 设定了正式的语义基础。随后在 Web 服务和企业服务总线（ESB）框架中的发展简化了企业集成，但引入了复杂性并限制了灵活性。
2. 2. 检索和模型内行动（2020-2023）：以引入检索增强生成（RAG）为标志，此阶段利用基于向量的检索增强了语言模型输出的接地。像 Function Calling、Toolformer 和 ReAct 这样的创新使 LLM 能够直接将推理转化为可执行的 API 调用，显著推进了代理的自主性和灵活性。
3. 3. 面向协议的互操作性（2024-2025）：当前阶段强调轻量级、标准化的协议如 MCP、ACP、ANP 和 A2A。这些协议通过启用动态发现、安全通信和跨异构代理系统的去中心化协作来解决先前的限制，促进可扩展性和强大的互操作性。
4. 表 2：关键代理互操作性里程碑时间轴
   | 年份 | 里程碑 | 关键贡献 |
   | :–: | :–: | :–: |
   | 1993 | KQML | 为基于知识的代理引入了言语行为原语和灵活的消息信封 [22]。 |
   | 1998 | MASIF | 定义了代理环境的基本服务注册和发现机制 [43]。 |
   | 2000 | FIPA-ACL | 标准化了表现形式语义、内容语言和带有正式前/后条件的交互协议 [24]。 |
   | 2002 | Web 服务（SOAP/WSDL） | 通过 UDDI、XML 消息传递和合同定义实现了面向服务的代理集成 [25]。 |
   | 2006 | ESB 模式 | 在 Apache Camel 和 Mule 等 ESB 中规范了企业集成模式（路由、转换） [26]。 |
   | 2020 | RAG | 将密集向量检索与 LLM 解码相结合，以将输出接地在外部语料库中 [27]。 |
   | 2023 | 函数调用 | 允许 LLM 发出针对函数模式目录的 JSON 格式 API 调用 [29]。 |
   | 2023 | Toolformer | 通过自我监督掩蔽训练 LLM 来预测文本中的 API 调用位置 [34]。 |
   | 2023 | ReAct | 交错链式思维推理和显式动作调用以实现动态工作流 [35]。 |
   | 2024 | MCP | 提出了用于标准化上下文摄取和工具调用的 JSON-RPC 协议 [6]。 |
   | 2024 | ANP | 对等协议，实现在开放互联网上的跨平台和跨组织代理通信。 [11]。 |
   | 2024 | ACP | 定义了带有正式类型和安全层的表现性消息原语 [10]。 |
   | 2025 | A2A | 引入了对等发现、能力交换和去中心化的代理对话 [9]。 |

4 MCP

4.1 客户端应用程序（主机）

客户端应用程序（主机）在 MCP 生态系统中充当交互的发起者。它负责管理与一个或多个 MCP 服务器的连接，并根据协议规范协调通信工作流。在实践中，客户端初始化会话，请求和处理四个核心原语：资源、工具、提示和采样，并处理与服务器端事件相关的异步通知。客户端还必须实施强大的错误处理例程，以优雅地管理通信失败或超时情况，确保与远程 MCP 服务器的可靠协调。

4.2 MCP 服务器（提供上下文和能力）

MCP 服务器作为提供数据、服务和交互模板的提供者，客户端可以利用这些模板来丰富基于 LLM 的工作流。它暴露并管理上下文资源，通过工具执行外部操作，定义可重复使用的提示以实现一致的交互模式，并可选择通过采样委托文本生成任务。除了响应请求外，服务器还负责强制执行访问控制策略，维护操作安全性，并发出反映其可用能力变化的通知。这种提供方架构通过模块化访问复杂的或动态资源来补充客户端的协调逻辑。

4.3 核心组件

模型上下文协议由多个分层抽象组成，这些抽象控制通信的结构和语义。在基础层面是协议层，它使用 JSON-RPC 2.0 规范定义消息交换的语义。它确保每个请求都链接到相应的响应，并且所有交互都符合可预测的模式。在此之上，传输层处理客户端和服务器之间消息的物理传输，支持通过 Stdio 进行本地通信和通过 HTTP（可选使用服务器发送事件（SSE））进行基于网络的通道。在最高抽象层，MCP 将消息组织成四种类型：请求，这是期望回复的调用；结果，这是对早期请求的成功响应；和错误，这表示失败或无效调用。第四种类型，通知，用于不需要客户端确认的异步更新。

图 2：互操作性时间轴

图 3：MCP 概览 [7]

4.4 MCP 服务器核心功能

MCP 服务器提供四种核心功能：工具、资源、提示和采样，每种功能都映射到一个独特的控制模型，该模型管理客户端、服务器和 LLM 之间的交互。
工具是由模型控制的功能，允许 LLM 调用外部 API 或服务，通常自动调用，有时需要用户批准。这促进了与第三方系统的无缝集成，并简化了对真实世界数据和操作的访问。
资源是应用程序控制的元素，例如结构化文档或上下文数据集，由客户端应用程序选择和管理。它们为 LLM 提供定制的任务特定输入，并实现上下文感知的补全。
提示是由服务器定义但通过客户端界面由最终用户选择的用户控制模板。这些可重复使用的提示促进一致性，减少冗余，并支持可重复的交互模式。
采样由服务器控制，允许 MCP 服务器将生成 LLM 补全的任务委托给客户端。这支持复杂的代理工作流，并允许对模型的生成过程进行细粒度监督，包括动态调整温度、长度和其他采样参数的能力。

4.5 MCP 连接生命周期

模型上下文协议（MCP）为客户机-服务器交互定义了三个阶段的生命周期，旨在确保稳健的会话管理、安全的能力协商和干净的终止。这些阶段——初始化、操作和关闭——对应于客户端应用程序和 MCP 服务器之间的通信时间序列。

初始化通过建立协议兼容性和交换支持的功能开始。在版本协商期间，客户端和服务器同意最高相互支持的协议版本。随后是一个功能交换，双方广告可选功能——例如采样、提示、工具和日志记录——这些功能可以在会话期间使用。该阶段以客户端在收到服务器的初始化响应后发送的通知/已初始化消息结束，表明准备进入操作通信。
操作代表核心活动阶段，在此期间，客户端和服务器根据协商的功能交换 JSON-RPC 方法调用和通知。双方都应严格遵守初始化期间商定的功能，确保兼容性和可预测性。每次任务调用可能包括可配置的超时，如果在该窗口内未收到响应，客户端可能会发出取消通知，以防止资源耗尽或陈旧的执行线程。
关闭确保会话有一个干净和可预测的结束。任一方都可以通过关闭传输层（通常是 HTTP 或 stdio）来启动终止，这信号通信结束。在关闭时，客户端和服务器都有责任清理资源，包括移除活动超时、取消订阅以及释放任何生成的子进程。在此之后，不应再发送新的协议消息，例外是必需的诊断消息，如 ping 或日志刷新事件。

4.6 MCP 生命周期中的安全挑战和缓解措施

随着 MCP 在企业和开发者生态系统中的采用增加，其生命周期在初始化、操作和更新阶段引入了多个安全漏洞。这些风险包括工具中毒、特权持久化和命令注入等问题，其中许多由于 LLM 对提示操控的易感性和不透明的执行跟踪而加剧。
表 3 总结了 MCP 部署生命周期各阶段识别出的最关键的安全威胁及其相应的缓解策略和权威参考。这种综合反映了当前攻击披露和最近审计及协议审查中的最佳实践防御。

5 A2A 架构

代理到代理（A2A）架构促进了不同代理系统之间的通信和协作以完成任务。它包括三个主要参与者——用户、客户端代理和远程代理（服务器），它们通过明确定义的协议进行交互，实现安全和互操作性的执行。
表 3：MCP 生命周期中的威胁和缓解策略

阶段	威胁	描述	缓解策略
创建	安装程序伪造	恶意包在构建或安装管道中引入。	强制执行 SBOM、数字签名和可重现构建。
	供应链后门	通过 CI/CD 艺术品持续恶意软件。	加固 CI/CD、验证清单并验证艺术品完整性。
	名称冲突	使用相似名称冒充可信的 MCP 代理。	使用 Sigstore 和 DIDs 确保唯一、可验证的身份。
	无身份验证握手	客户端连接到未经身份验证或流氓服务器。	强制执行双向身份验证和基于 TLS 的验证。
操作	工具中毒	恶意提示或元数据影响 LLM 行为。	验证模式、使用过滤（YARA/RegEx）并应用语义防护。
	凭据盗窃	通过完成或工具输出泄露秘密。	使用 OAuth $2.1+$ PKCE、限制令牌范围并强制执行 mTLS。
	沙盒逃脱	工具访问主机操作系统或绕过隔离。	使用 syscall 过滤器、AppArmor 和容器加固。
	远程访问控制	LLM 注入 SSH 密钥或创建后门 shell。	使用 EDR/HIDS 监控并限制传出行为。
	命令注入 / RCE	不安全的输入触发系统执行。	清理输入、禁用 shell 访问并禁止 evals。
	工具重新定义	验证后工具变为恶意（“地毯拉动”）。	使用签名、版本化的清单并监控变异。
	跨服务器阴影	一个服务器覆盖另一个服务器的工具引用。	强制执行命名空间作用域并验证路由来源。
	缺乏可见性	客户端无法检查工具指令或有效载荷。	启用调试模式、元数据内省和日志记录。
更新	版本漂移	较旧的易受攻击的 MCP 版本仍在使用。	使用 GitOps 进行漂移检测并强制执行自动修复。
	特权持久化	保留提升的角色或旧的令牌范围。	在更新后审核角色并轮换凭据。
	配置漂移	更新后引入错误配置。	验证 CVE 并应用硬化的默认值。
	未签名的工具清单	清单在部署后被篡改或注入。	强制执行签名检查并阻止未签名的工具。

5.1 核心组件

用户发起任务或请求，通常不需要了解或直接与底层代理系统交互。客户端代理接收此请求，分析其意图，并通过检查其代理卡中宣传的功能来识别合适的远程代理（服务器）。选定后，客户端代理与远程代理交互以执行任务，协调消息交换并检索结果——称为工件——然后将其交付回用户。

5.1.1 用户

用户充当任何 A2A 交互的发起者，体现了启动代理过程的意图或需求。虽然经常是人类终端用户，用户也可以是系统、服务或另一代理在层次结构中

图 4：A2A 概览
工作流。无论其形式如何，用户都不会直接与远程代理交互；相反，它依赖于客户端代理将其请求翻译成可操作的任务，并调解所有响应。

A2A 支持多样化的用户交互模型。直接终端用户可以通过聊天机器人或语音助手等界面与客户端代理互动，提供任务输入并实时接收结果。间接终端用户与幕后透明使用 A2A 代理的高级系统交互，如企业仪表板或编排工具。系统或服务也可以充当用户，自主调用 A2A 代理以进行数据转换或监控等工作流。在多代理层次结构中，当一个代理触发另一个代理的下游动作以完成复杂任务时，会出现代理作为用户的场景。这些各种用户范式强调了协议对用户身份的不可知性，并强调其重点在于标准化客户端和远程代理之间的通信。

5.1.2 客户端代理

客户端代理作为中介，代表用户的意图并与远程代理协调以实现它。其职责贯穿任务生命周期的多个阶段。它首先执行代理发现，检索并评估描述每个远程代理技能、功能、输入/输出规范和身份验证要求的代理卡。基于此发现，客户端选择与用户任务对齐的远程代理。接下来，客户端代理负责任务启动。它构造一个结构化的任务对象，封装用户的意图、相关元数据和格式化的输入。然后，它使用格式正确的消息将此任务发送到选定的远程代理。在执行过程中，客户端代理管理消息和工件交换。它与远程代理双向通信，发送新指令或跟进，并接收输出——称为工件——以及任何中间更新。对于长时间运行或有状态的交互，它维护会话上下文，使用标识符将相关交换分组到统一的工作流中。
客户端代理还监督错误处理，解析远程代理返回的任何故障响应，并执行适当的恢复策略，如重试、备用代理选择或用户通知。执行后，结果演示步骤涉及将工件转换为用户可消费的格式，并将其集成到周围的应用程序或用户界面中。
在支持的情况下，客户端代理可以通过服务器发送事件（SSE）或推送通知等机制处理异步通信。对于 SSE，它建立持久连接并实时流式传输更新。如果支持推送通知，则客户端代理注册通知服务以接收带外交付的任务更新。总的来说，客户端代理在 A2A 协议中充当执行编排器、数据翻译器和通信桥梁，代表用户实现智能、上下文感知的交互。

5.1.3 远程代理（服务器）

远程代理（服务器）是执行客户端代理委派任务的服务端点。它提供一项或多项技能，这些技能代表它可以执行的离散操作，范围从简单的数据检索到涉及外部 API 或数据库的复杂计算或编排。每项技能都由其输入和输出模式正式定义，从而实现跨客户端的一致调用。
为了让这些功能可发现，远程代理发布代理卡——这是一个结构化的元数据文档，包含可用技能列表、使用说明、输入/输出格式、支持的协议和身份验证要求。此代理卡既作为广告又作为交互代理的接口合同。
远程代理还必须管理其内部资源使用，确保在任务执行期间公平分配计算、内存、网络和存储资源。除了执行之外，它还负责实施安全和访问控制机制。这包括验证客户端、验证消息完整性和根据访问策略或令牌范围授权对特定技能的访问。通过将服务功能抽象为模块化、独立管理的组件，远程代理支持可组合性、可靠性和代理生态系统中的互操作性。

5.2 A2A 主要组件

A2A 代理围绕几个核心组件构建，这些组件定义了其行为、能力和交互。这些组件作为任何代理在代理到代理生态系统中功能的操作和语义构建块。
代理卡充当自我描述和发现机制。它是一个 JSON 格式的文档，公开声明代理的元数据，包括其名称、版本、描述、支持的技能和身份验证要求。客户端代理依靠代理卡来发现和评估能够满足特定任务标准的远程代理。作为主要的协调入口点，没有代理卡的代理在 A2A 系统中实际上是不可见的。
技能代表代理提供的可操作能力。每项技能都由名称、目的、预期输入参数和输出格式描述。技能通过任务调用，并封装代理提供的核心实用功能。代理的相关性和专业化直接与其发布的技能广度和精度相关。
任务是工作委派的原子单位。它指定要执行的技能以及输入参数和上下文元数据。任务由客户端代理发出并由远程代理处理，实现异步或同步协作。通过以标准化格式结构化意图和调用，任务允许 A2A 代理在不同系统中互操作。
消息充当代理之间的主要通信渠道。这些封装数据交换和协调活动，如任务提交、中间状态更新或工件交付，并可由多个类型的部分组成，包括纯文本、结构化数据或文件引用。没有消息，代理间的交互是不可能的，这使它们成为 A2A 协议的基础。工件是技能执行的有形输出。一旦远程代理完成任务，它会生成工件，其中可能包含结构化响应、计算结果、文档或链接数据。这些输出被传输回客户端代理，客户端代理可能会将其渲染给用户或将它们纳入下游流程。工件代表通过代理协作创造的具体知识或价值。

5.3 A2A 传输层和通信

A2A 协议支持多种传输机制，以实现客户端和远程代理之间的通信，支持同步和异步工作流。当需要并且双方都支持实时流媒体时，可以使用服务器发送事件（SSE）。SSE建立持久的 HTTP 连接，远程代理可以通过该连接向客户端代理发送实时状态更新或部分工件，从而在长时间运行的任务期间提供连续反馈。
这些是通过 PushNotificationService 接口实现的，允许远程代理通过带外通道通知客户端任务进度或完成情况。此模型特别适合于容错工作流和后台任务编排。
所有核心任务通信在 A2A 中都遵循 JSON-RPC 2.0 规范。这确保了方法调用、参数传递和结果封装的标准化格式。此外，远程代理发现是通过 HTTP GET 请求引导至代理端点来实现的，具体是检索其代理卡作为
支持功能的结构化表示。这些机制共同实现了跨不同运行时环境的灵活、互操作性和可扩展通信。

5.4 A2A 远程代理（服务器）生命周期

A2A 协议中的远程代理生命周期遵循四个关键阶段的结构化进展：创建、操作、更新和终止。每个阶段反映了一组关键职责，确保代理行为的安全性、可发现性和可靠性。
创建始于发布代理卡，这是一个位于 /.well-known/agent.json 的 JSON 格式文档，声明元数据，如代理名称、版本、支持技能和身份验证方案。一旦代理卡可用，代理服务就会部署在指定端点并配置为通过 HTTP 处理 JSON-RPC 2.0 请求。为了完成创建阶段，远程代理必须实现声明的身份验证机制，启用安全的客户端验证和访问控制。
在操作期间，远程代理根据其宣传的技能处理客户端代理提交的任务。这包括接收结构化的任务负载、执行关联的技能逻辑并通过 JSON-RPC 状态消息和工件交付管理持续通信。如果支持，代理还可以使用服务器发送事件（SSE）或通过注册的 PushNotificationService 流式传输异步更新。代理负责在整个执行过程中维护内部任务状态，以确保交互的一致性和可追溯性。
在更新阶段，远程代理刷新其能力和配置。这包括在代理卡中递增版本字段、添加新技能或身份验证模式以及应用安全补丁以保持合规性。代理还可以弃用过时的功能或遗留接口，最好通过更新的文档或显式的生命周期状态字段向客户端发出这些变化信号。
最后，在终止阶段，远程代理优雅地结束其操作。飞行中的任务被驱动到完成或转换到终端状态，并关闭任何打开的 SSE 流。服务随后注销其代理卡——通过删除或存档发布的元数据并释放分配的系统资源，确保干净的关闭，没有残留暴露或陈旧端点。定义明确的远程代理生命周期增强了可发现性，促进了互操作性，并确保基于代理的合作在更广泛的 A2A 生态系统中保持安全、一致和可预测。

5.5 安全挑战及 A2A 生命周期中的缓解措施

安全的 A2A 部署需要解决整个生命周期阶段（创建、操作、更新和终止）中的威胁。表 4 汇总了主要漏洞及其对应的缓解策略，摘自官方 A2A 协议参考和最近的安全分析。

6 ACP 核心架构

代理通信协议（ACP）定义了一个分层的、REST 原生框架，用于互操作的人工智能代理。其静态架构包括不同的角色和协议层，每个层负责一组明确定义的功能。

6.1 ACP 架构概述

代理通信协议（ACP）定义了一个简化的三角色架构，旨在标准化 AI 代理之间的发现、调用和交互。该架构确保客户端可以无缝定位代理、发起结构化的任务请求并接收多模态响应，而无需定制集成。
在此架构的入口处是代理客户端，它通过已发布的注册表发现代理并组成符合 ACP 格式的结构化请求来启动通信。它将用户意图封装到多部分消息中，如有需要则管理会话级上下文，并处理从纯文本到丰富工件和由代理返回的二进制数据的有序响应部分。
ACP 系统的核心是 ACP 服务器，它充当协议代理。它维护代理注册表，这是由代理详细信息模式定义的元数据目录，并强制执行包括身份验证、授权和速率限制在内的系统范围策略。收到客户端请求后，ACP 服务器执行代理查找和路由，确保符合注册的能力，并促进按规定的顺序将响应部分安全传输回客户端。
表 4：A2A 生命周期安全挑战及缓解策略

阶段	安全挑战	威胁描述	缓解策略
创建	代理卡与清单伪造	对手可能篡改 /.well-known/agent.json 中的代理卡，冒充可信的远程代理。	数字签名代理卡，检索时验证校验和，并加固 CI/CD 管道以防止注入 [9]。
操作	任务注入与命令伪造	恶意的任务/send 或 tasks/sendSubscribe 调用可能操纵 JSON-RPC 以触发未经授权的执行。	强制执行 TLS，使用 JSON Web 签名 (JWS)，验证模式，并颁发作用域能力令牌 [44]。
	推送通知劫持	攻击者可能伪造 SSE 端点或拦截通知，导致虚假更新或泄露。	验证通知通道，隔离每会话流，并签署推送事件 [45]。
更新	未经授权的能力注入与版本漂移	未经授权的行为者可能向代理卡中添加隐藏技能，或客户端在过时配置上运行。	使用不可变、版本化的清单，通过 GitOps 检测漂移，并要求签名的清单差异 [46]。
终止	孤立资源与审计差距	令牌、SSE 流或代理注册可能在使用后仍然存在，使安全审计复杂化。	实现关闭挂钩，撤销凭据，并集中带有强制保留的审计日志 [47]。

图 5：ACP 概览

ACP 代理代表执行端点，其中包含特定领域的逻辑。它可以作为无状态微服务运行或维护会话上下文以支持多轮交互。代理摄取由语义元数据标记的有序消息部分组成的结构化请求，并按照注册的技能定义进行处理。任务完成后，代理发出符合 ACP 消息结构规范的响应部分，从而实现统一且可解释的响应管道。
一起，这三个组件建立了一个模块化且互操作性的代理通信框架，促进可扩展部署、松耦合以及发现、编排和执行逻辑的清晰分离。

6.2 ACP 主要组件

ACP 交互由一组定义代理行为、启用运行时互操作性并标准化任务通信的核心组件治理。此架构的核心是代理详情，这是一个自描述的 JSON 或 YAML 文档，作为代理的公共身份和功能配置文件。它提供了必要的元数据，包括
代理名称、可用操作、支持的内容类型、身份验证方案和运行时诊断。客户端依赖代理详情作为调用的前提条件，使信任和选择无需定制集成。
补充这一点，发现机制允许客户端在运行时动态定位代理。这些机制可以是集中的——例如注册表 API——或分散的，包括托管在知名 URL 下的清单文件（例如 / .well-known/agent.ym1）或嵌入在容器标签等部署元数据中的内容。这种可发现性层将客户端逻辑与固定配置解耦，并支持可扩展的代理网络。
一旦定位到代理，客户端就会发出任务请求，这是一个结构化的委派工作单元。任务请求由指定目标操作并包括文本输入、二进制有效载荷或外部托管数据引用的有序消息部分组成。此设计适应同步调用和长时间运行的异步任务。
所有请求和响应均符合 ACP 的消息结构，该结构标准化了通信信封。每条消息是一个有序的部分列表，具有显式的 MIME content_type 注释和嵌入内容或 dereferenceable content_url 值。可选的 name 属性允许使用语义标记的工件，便于下游解释。
最后，代理执行的结果封装在一个或多个工件中。这些可能包括结构化的 JSON 输出、纯文本补全、二进制文件甚至嵌套的消息引用。工件作为 Message Structure 响应的一部分交付，随后呈现、存储或链接到其他代理工作流中，确保在启用 ACP 的系统中具有可扩展性和可组合性。

6.3 ACP 代理生命周期

ACP 代理的生命周期紧密映射到 A2A 框架的四个典型阶段：创建、操作、更新和终止。每个阶段确保代理行为在整个活动部署期间保持可发现性、互操作性和安全性。
创建从代理的配置和部署开始。这涉及通过代理详情清单声明代理的能力和元数据，该清单通过 ACP 兼容服务器（如 ASGI 基础或内置实现）提供访问。代理初始化时带有身份验证机制和路由逻辑，这些共同确保服务发现和下游任务执行的安全性。
在操作期间，代理处理客户端提交的结构化 sendTask 请求。这些请求包含任务执行所需的编码参数。ACP 运行时支持同步执行以及中间结果的增量流式传输。每个任务通过定义良好的状态——如 created、in_progress 或 awaiting——进行管理，这些状态由 ACP 执行引擎处理。对于多轮工作流，会话级持久性确保多次交互之间上下文的连续性。
在更新阶段，代理详情清单会被刷新以反映代理行为或能力的变化。这些更新可能包括新操作、支持的 MIME 类型或版本增量。重要的是，发现过程对这些变化具有弹性：查询代理注册表的客户端检索最新清单而无需直接修改 API，从而保持向后兼容性。
终止涉及代理的优雅退役。所有活跃任务都被驱动到完成状态，正在进行的流被关闭，并注销或标记代理清单为非活动状态以防止未来的发现。所有分配的资源被释放，会话数据被最终化，以确保清洁和可审核的关闭。

6.4 ACP 生命周期中的安全考虑

基于 ACP 的系统在其生命周期阶段——从代理注册到关机——面临不同的安全挑战。表 5 总结了关键威胁及其相应的缓解策略，基于最近的红队测试、协议和平台级研究。

7 ANP 架构

代理网络协议（ANP）是一种去中心化的点对点通信标准，旨在开放互联网上的跨平台代理互操作性。ANP 允许代理使用结构化元数据和 AI 原生数据交换自主发现、身份验证和交互。以下章节将 ANP 架构与标准化生命周期和模块化框架对齐，与 MCP、A2A 和 ACP 一致建模。
表 5：ACP 生命周期安全挑战及缓解策略

阶段	安全挑战	威胁描述	缓解策略
创建	元数据伪造与供应链攻击	攻击者可能发布伪造的 Agent Detail 清单（例如，/.well-known/agent.yml）以冒充代理或注入恶意技能。	数字签名所有清单，在发现时验证，并强制执行 CI/CD 签名检查和工件验证 [10]。
操作	消息篡改与中间人攻击	对手可以拦截或更改 sendTask 或 getTask RPC 调用，导致有效载荷注入或消息损坏。	使用 TLS 进行传输安全并对每条消息部分使用 JWS 签名 [44]。
	认证缺陷与未经授权访问	弱承载令牌强制执行可能导致未经授权的执行或任务中断。	应用作用域限定、短生命周期令牌；强制执行相互 TLS 并带有身份吊销 [46]。
持久性	会话劫持与隐私泄露	在没有适当绑定或加密的长生命周期会话中可能发生重放攻击或令牌盗窃。	旋转会话 ID，加密持久上下文，并最小化令牌生命周期 [45]。
更新	版本回滚与配置漂移	更新后，陈旧的清单或软件可能会重新引入已修补的漏洞。	强制执行不可变、版本化的清单并使用 GitOps 检测漂移 [48]。
终止	孤立资源与审计差距	未能吊销令牌或关闭 SSE 流会使清理和取证复杂化。	排空活跃任务，吊销凭据，并集中带有保留政策的审计日志 [48]。

图 6：ANP 概览 $[12,11]$

7.1 核心组件

代理网络协议（ANP）基于一组基础组件，这些组件共同支持去中心化身份、语义自我描述、发现和自适应交互。核心是代理身份，它采用去中心化标识符（DIDs）在平台上唯一识别代理。具体来说，ANP 采用了 did:wba 方法，其中每个标识符对应一个 HTTPS 托管的 DID 文档，从而利用现有的 Web 基础设施进行去中心化身份解析。
基于这一身份层的是代理描述，通过代理描述协议（ADP）实现。这些 JSON-LD 格式的文档包含关于代理的结构化元数据，包括其名称、功能、支持的协议、身份验证方案和服务端点。它们充当代理公开可访问的配置文件，促进互操作性和语义理解。
代理通过发现目录公开其存在和功能，通常位于标准化的 .well-known/agent-descriptions 端点。此目录使人类用户和自动化系统都能检索给定域下的可用代理列表，形成可扩展代理索引和搜索的基础。
为了支持交互，ANP 容纳两类通信接口：结构化接口，如 JSON-RPC 和 OpenAPI，以及通过 YAML 或等效模式文件定义的自然语言接口。这两种接口类型都在代理描述中声明，并支持适合不同复杂度和用例的灵活交互模式。
最后，元协议协商者促进代理之间的动态协议对齐。此机制允许代理交换其通信需求和功能的自然语言描述，从中可以协商和实例化兼容的交互协议。通过支持运行时适应性和协商，这一层确保即使在异构代理生态系统中也能实现无缝互操作性。

7.2 ANP 代理生命周期

ANP 代理生命周期遵循创建、操作、更新和终止的经典阶段，反映了代理网络协议的去中心化设计原则。每个阶段确保代理在全球分布式代理生态系统中保持可发现性、可验证性和互操作性。
创建从使用 did:wba 方法生成去中心化标识符（DID）开始。该标识符与托管代理 DID 文档的公共可解析 HTTPS 端点相关联。同时，代理准备一份自描述的代理描述（ADP）文档，采用 JSON-LD 格式，详细说明其服务、支持的协议和身份验证机制。然后，ADP 发布在标准化路径下，如 /.well-known/agent-descriptions，启用基于 Web 的发现或可选的搜索代理注册。
在操作阶段，代理通过 DID 文档中定义的加密凭证进行身份验证和交互。所有通信遵循 ADP 中声明的结构化交互模型——例如，JSON-RPC 用于精确调用或基于 YAML 的接口用于自然语言协商。使用 HTTPS 建立安全传输，如适用，实时通信通过 Server-Sent Events（SSE）或长轮询等机制支持。代理通过调用外部服务、解释请求和以标准化格式返回结果来自主或协作行动。
更新阶段允许代理修订其 ADP 文档和相关的 DID 元数据以反映功能演变或接口变更。这些更新通过索引服务的定期爬取自动传播，或通过主动发现端点显式刷新。由于代理身份和服务描述独立版本化和发布，客户端可以动态适应更新而不破坏现有集成。
终止涉及代理的有意停用。这包括移除或归档其 DID 文档以及从发现目录中取消发布其 ADP 端点。任何已发布的身份验证令牌、访问凭据或相关元数据都必须吊销以确保安全。干净的关闭通过防止陈旧或孤立的条目保留在发现索引或受信任的注册表中，从而维护代理生态系统的完整性。

7.3 传输和格式

ANP 依赖 HTTP(S) 进行传输和 JSON-LD 进行数据格式化。Schema.org 词汇表和上下文（如 ‘ad:’）用于语义清晰。结构化接口如 JSON-RPC 和 OpenAPI 是兼容的并通过 ADP 嵌入。

7.4 ANP 生命周期中的安全考虑

表 6 汇总了 ANP 生命周期中的主要威胁及其相应的缓解措施。

8 代理协议比较

为了更清楚地了解主要代理互操作性协议的不同之处，表 7 提供了四种广泛讨论的框架的并列比较：模型上下文协议（MCP）、代理通信协议
表 6：ANP 生命周期安全挑战及缓解策略

阶段	安全挑战	威胁描述	缓解策略
创建	身份伪造	DID 文档可能被伪造或托管不安全，导致代理误识别。	强制 HTTPS 托管 DIDs，通过 DNS 记录验证，并要求 DID 签名验证。
操作	未验证代理	恶意行为者可能绕过 DID 检查或使用伪造凭据。	通过 DID 公钥认证并验证敏感动作的人类授权。
	接口篡改	代理可能更改结构化接口或注入自然语言端点。	要求对接口进行加密签名并记录带源元数据的访问事件。
更新	过时描述	过时或篡改的代理元数据可能欺骗客户端。	自动抓取代理描述并针对已知良好哈希值进行验证。
终止	孤立标识符	已过期的 DIDs 或代理声明（ADPs）可能保留在注册表或缓存中。	使用到期时间戳并在注销时要求撤销信号。

(ACP)，代理到代理协议 (A2A)，和代理网络协议 (ANP)。这种结构化分析突出了它们的架构选择、消息格式、发现方法、会话模型和预期用例，提供了对其在多样化部署场景中适用性的洞察。

9 代理互操作性的分阶段采用路线图

本节提出了一个基于协议成熟度、集成复杂性和领域特定用例的实际、多阶段部署策略。该路线图帮助组织逐步采用最适合的代理通信标准，同时确保可扩展性、可组合性和安全性。

9.1 第一阶段 - 使用 MCP 进行工具调用

初始阶段涉及采用模型上下文协议（MCP），以实现大型语言模型（LLMs）和外部工具或资源之间的安全和结构化交互。MCP 利用基于 JSON-RPC 的客户端-服务器模型，使其非常适合早期代理集成，其中工具调用、确定性执行和类型化输入/输出至关重要。

9.2 第二阶段 - 使用 ACP 进行丰富交互

一旦基本工具功能就位，就可以分层使用代理通信协议（ACP）来支持异步、多模态和 REST 原生消息传递。ACP 引入有序消息部分、灵活的任务模式和流支持——这些功能使得更丰富的代理对话和与更广泛的 RESTful 生态系统的集成成为可能。

9.3 第三阶段 - 使用 A2A 进行企业协作

在更复杂的企业环境中，代理到代理（A2A）协议通过结构化的能力卡片和工件交换实现多代理工作流和任务协调。A2A 支持通过代理卡进行动态发现，并在受信任的上下文中实现安全的组织内协作。

9.4 第四阶段 - 使用 ANP 进行开放代理市场

最后一个阶段涉及使用代理网络协议（ANP）将互操作性扩展到开放互联网。ANP 通过使用 JSONLD 图形促进去中心化的代理发现、基于 DID 的身份验证和点对点通信。它为可扩展的跨平台代理市场和 AI 原生的网络交互提供了基础。这种分阶段方法使组织能够逐步采用代理通信协议，最大化互操作性的同时在每个阶段最小化集成复杂性。
表 7：MCP、ACP、A2A 和 ANP 协议比较

方面	MCP（模型上下文协议）	ACP（代理通信协议）	A2A（代理到代理协议）	ANP（代理网络协议）
架构 模型	带有 JSON-RPC 原语的客户端-服务器	中介客户端-服务器（注册表 + 任务路由）	类似对等的客户端++远程代理	去中心化的点对点
代理发现	手动注册或静态 URL 查找	基于注册表	通过 HTTP 检索代理卡	搜索引擎发现
身份与认证	基于令牌的认证；可选支持 DIDs	承载令牌、相互 TLS、JWS	基于 DID 的握手或带外头	去中心化标识符（DID），特别是 did\wha
消息格式	带有提示、工具、资源的 JSON-RPC 2.0	带有 MIME 类型部分的结构化多部分消息	基于 JSON 的任务+工件消息传递	带有 Schema.org 和 ADP/元协议协商的 JSON-LD
核心组件	工具、提示、资源、采样	代理详情、消息、任务请求、工件	代理卡、任务、消息、工件	DID 文档、代理描述、元协议、结构化接口
传输层	HTTP、Stdio、服务器发送事件（SSE）	带增量流的 HTTP	带可选 SSE+推送通知的 HTTP	带 TLS 的 JSON-LD 超文本传输协议
会话支持	无状态+可选持久工具上下文	带运行状态跟踪的会话感知	会话感知或无状态；客户端管理的 ID	无状态； 跨连接使用的 DID 认证令牌
目标范围	$\begin{array}{rl}& \text{ LLM }\leftrightarrow \text{ 外部 }\\ & \text{ 工具/服务集成 }\end{array}$	模型无关，基础设施级代理	受信任的企业任务委派	开放互联网代理互联
主要用例	增强 LLM 的外部能力（如代码、搜索）	为不同代理提供安全、类型化的消息交换	组织信任边界内的多代理工作流	跨平台代理发现、安全 P2P 执行
优势	紧密集成 LLM；资源注入	多模态消息传递；中介注册表；工具模块化	代理间协商；工件驱动的委派	基于 DID 的无信任身份；AI 原生协议协商
局限	假设集中式服务器；提示注入风险	需要注册表；对服务器控制的强烈假设	以企业为中心；假设代理目录	协商开销高；发展中的采用生态系统

10 结论

随着由大规模语言模型驱动的自主代理在各领域不断普及，对安全、模块化和互操作性通信的需求变得日益紧迫。本综述对四种新兴协议——MCP、ACP、A2A 和 ANP 进行了结构化分析，这些协议各自解决了代理互操作性的不同层面。通过统一工具调用、多模态消息传递、任务协调和去中心化发现，这些协议共同构成了可扩展多代理系统的基石。比较评估表明，没有任何单一协议足以涵盖所有上下文；相反，分阶段的互补采用策略——从 MCP 开始，依次经过 ACP 和 A2A 到 ANP——为部署代理生态系统提供了一条实用途径。未来的研究应探索协议互操作性桥梁、代理协作的信任框架和标准化评估基准，以加速采用并确保现实世界部署中的弹性。这些基础努力对于推动下一代智能联网代理的发展至关重要。

参考文献

[1] Tom B Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, et al. 语言模型是少量学习者。Advances
in neural information processing systems, 33:1877-1901, 2020.
[2] Rishi Bommasani, Drew A Hudson, Ehsan Adeli, Russ Altman, Simran Arora, Sydney von Arx, et al. 基础模型的机会与风险。arXiv preprint arXiv:2108.07258, 2021.
[3] Lei Wang, Chen Ma, Xueyang Feng, Zeyu Zhang, Hao Yang, Jingsen Zhang, Zhiyuan Chen, Jiakai Tang, Xu Chen, Yankai Lin, Wayne Xin Zhao, Zhewei Wei, and Jirong Wen. 关于基于大型语言模型的自主代理的调查。Frontiers of Computer Science, 18(6), Mar. 2024.
[4] Grégoire Mialon, Roberto Dessì, Maria Lomeli, Christoforos Nalmpantis, Ram Pasunuru, Roberta Raileanu, Baptiste Rozière, Timo Schick, Jane Dwivedi-Yu, Asli Celikyilmaz, Edouard Grave, Yann LeCun, and Thomas Scialom. 增强型语言模型：综述。arXiv preprint arXiv:2302.07842, 2023.
[5] Taicheng Guo, Xiuying Chen, Yaqi Wang, Ruidi Chang, Shichao Pei, Nitesh V. Chawla, Olaf Wiest, and Xiangliang Zhang. 基于大型语言模型的多代理：进展与挑战的调查。arXiv preprint arXiv:2402.01680, 2024. Accessed: Apr. 30, 2025.
[6] Model Context Protocol. 模型上下文协议简介 (mcp). https://modelcontextprotocol. io/introduction, 2024. Accessed: Apr. 2025.
[7] Aditi Singh, Abul Ehtesham, Saket Kumar, and Tala Talaei Khoei. 模型上下文协议 (mcp) 调查：标准化上下文以增强大型语言模型 (llms). Preprints, Apr. 2025.
[8] Partha Pratim Ray. 模型上下文协议调查：架构、现状、挑战和未来方向。TechRxiv, Apr. 2025. Accessed: Apr. 30, 2025.
[9] Google. 代理到代理 (a2a) 协议文档。https://google.github.io/A2A/, 2024. Accessed: Apr. 2025.
[10] IBM BeeAI. 代理通信协议 (acp) 简介。https://docs.beeai.dev/acp/alpha/ introduction, 2024. Accessed: Apr. 2025.
[11] Agent Network Protocol Contributors. 代理网络协议 (anp). https://github.com/ agent-network-protocol/AgentNetworkProtocol, 2024. Accessed: Apr. 30, 2025.
[12] Agent Network Protocol Contributors. 代理网络协议官方网站。https:// agent-network-protocol.com/, 2024. Accessed: Apr. 30, 2025.
[13] Khanh-Tung Tran, Dung Dao, Minh-Duong Nguyen, Quoc-Viet Pham, Barry O’Sullivan, and Hoang D. Nguyen. 多代理协作机制：LLM 调查。CoRR, abs/2501.06322, 2025.
[14] Taicheng Guo, Xiuying Chen, Yaqi Wang, Ruidi Chang, Shichao Pei, Nitesh V. Chawla, Olaf Wiest, and Xiangliang Zhang. 基于大型语言模型的多代理：进展与挑战的调查。CoRR, abs/2402.01680, 2024.
[15] Bingyu Yan, Xiaoming Zhang, Litian Zhang, Lian Zhang, Ziyi Zhou, Dezhuang Miao, and Chaozhuo Li. 超越自言自语：基于 LLM 的多代理系统通信中心调查。CoRR, abs/2502.14321, 2025.
[16] Akram Sheriff. 动态 LLM 代理元数据清单驱动的代理发现平台中的 LLM 代理。技术报告 7522，技术披露公共，2024.
[17] Ivan Milev, Mislav Balunovic, Maximilian Baader, and Martin Vechev. Toolfuzz：自动化代理工具测试。CoRR, abs/2503.04479, 2024.
[18] Stuart J. Russell and Peter Norvig. 人工智能：现代方法。Prentice Hall, 第 3 版，2010.
[19] Michael Wooldridge. 多代理系统导论。John Wiley & Sons, 2009.
[20] Stan Franklin and Art Graesser. 它是一个代理，还是只是一个程序？自主代理的分类法。国际认知科学杂志，6(1-2):29-36, 1997.
[21] Nicholas R. Jennings. 论基于代理的软件工程。人工智能，117(2):277-296, 2000.
[22] Michael R. Genesereth and Scott P. Ketchpel. KQML 协议：语言和通信的规范。第三届国际信息和知识管理会议 (CIKM) 的论文集，第 $1-10$ 页。ACM, 1993.
[23] Tim Finin, Rich Fritzson, Donald McKay, and Robin McEntire. KQML 作为一种代理通信语言。第三届国际信息和知识管理会议论文集，第 456-463 页，1994.
[24] 智能物理代理基金会。FIPA 交际行为库规范。https://www.fipa. org/specs/fipa00037/SC00037J.html, 2000.
[25] Francisco Curbera, Marc Duftler, Rania Khalaf, William Nagy, Nirmal Mukhi, and Sanjiva Weerawarana. Web 服务：为什么以及如何。IBM 系统期刊，41(2):170-177, 2002.
[26] Gregor Hohpe 和 Bobby Woolf. 企业集成模式：设计、构建和部署消息解决方案。Addison-Wesley Signature Series (Fowler). Addison-Wesley Professional, 2006.
[27] Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Mike Lewis, William Yih, Tim Rocktäschel, and Sebastian Riedel. 检索增强生成用于知识密集型 NLP 任务。神经信息处理系统进展，第 33 卷，第 9459-9474 页，2020.
[28] Gautier Izacard 和 Edouard Grave. 朝着知识密集型 NLP 任务的有效管道迈进。arXiv preprint arXiv:2112.04426, 2021.
[29] OpenAI. OpenAI 模型中的函数调用。https://platform.openai.com/docs/guides/functions, 2023. Accessed: Apr. 2025.
[30] Harrison Chase. Langchain：通过组合性构建使用 LLM 的应用程序。https://github.com/ langchain-ai/langchain, 2022. Accessed: Apr. 2025.
[31] Jerry Wu 等人。Llamaindex：连接 LLM 到您的知识。https://github.com/jerryjliu/llama_ index, 2023. Accessed: Apr. 2025.
[32] OpenAI. OpenAI 插件商店。https://platform.openai.com/docs/plugins, 2023.
[33] Fangzhou Liu, Xinyu Li, Zihan Wu, Yang Song, Wayne Xin Zhao, and Ji-Rong Wen. Autotool：使用可自我扩展工具集构建通用 LLM 代理。arXiv preprint arXiv:2403.02659, 2024.
[34] Timo Schick 和 Hinrich Schütze. Toolformer：语言模型可以自己学会使用工具。在第 61 届计算语言学协会年会论文集（第一卷：长篇论文）第 8213-8229 页。ACL, 2023.
[35] Sheng Yao, Eric Urbach, and Dale Schuurmans. React：在语言模型中协同推理和行动。在 2023 年经验方法在自然语言处理国际会议 (EMNLP) 论文集第 2659-2671 页。ACL, 2023.
[36] AutoGen 社区。Autogpt：一个实验性的开源自主代理，使用 GPT-4。https://github. com/Significant-Gravitas/Auto-GPT, 2023. Accessed: Apr. 2025.
[37] Thomas Shinn 和 Regina Barzilay. Reflexion：通过迭代学习失败的语言模型自我改进。arXiv preprint arXiv:2310.02493, 2023. Available at https://arxiv.org/abs/2310.02493.
[38] CrewAI 项目。CrewAI：用于协作 LLM 代理的高级团队抽象。https://github.com/ crew-ai/crewai, 2024. Accessed: Apr. 2025.
[39] SmolAgents 项目。Smolagents：用于多模态 LLM 代理原型设计的单文件 Python 库。https: //github.com/smolagents/smolagents, 2024. Accessed: Apr. 2025.
[40] AutoGen 社区。AG2 (autogen)：具有人在环工作流程的开源 AgentOS。https: //github.com/Significant-Gravitas/Auto-GPT, 2025. Accessed: Apr. 2025.
[41] Microsoft. Semantic kernel：用于 LLM 编排和记忆的 SDK。https://github.com/microsoft/ semantic-kernel, 2024. Accessed: Apr. 2025.
[42] OpenAI. Swarm：通过 JSON-RPC 常规实现无状态多代理协调。https://platform.openai.com/ docs/models/swarm, 2024. Accessed: Apr. 2025.
[43] Dejan S. Milojicic, Markus Breugst, Ingo Busse, John Campbell, Stefan Covaci, Barry Friedman, Kazuya Kosaka, Danny B. Lange, Kouichi Ono, Mitsuru Oshima, Cynthia Tham, Sankar Virdhagriswaran, and Jim White. MASIF：OMG 移动代理系统互操作性设施。第二届移动代理国际研讨会论文集，MA '98，第 50-67 页，柏林，海德堡，1998。Springer-Verlag.
[44] Pengfei He, Yupin Lin, Shen Dong, Han Xu, Yue Xing, and Hui Liu. 通过通信攻击对 LLM 多代理系统进行红队测试。arXiv preprint arXiv:2502.14847, 2025.
[45] Sahar Abdelnabi, Amr Gomaa, Eugene Bagdasarian, Per Ola Kristensson, and Reza Shokri. 防火墙以确保动态 LLM 代理网络的安全。arXiv preprint arXiv:2502.01822, 2025.

[46] Carol Doe. A2A 协议：深入指南。对代理互操作性的需求。https://medium.com/ @author/a2a-protocol-guide, 2025. [在线；访问日期 2025-04-24].

[47] Google Developers Blog. 宣布代理到代理协议 (A2A)。https://developers.googleblog. com/en/a2a-a-new-era-of-agent-interoperability/, 2025. [在线；访问日期 2025-04-24].

[48] Fiona Zhang 和 George Kumar. 受威胁的 AI 代理：关键安全挑战和缓解措施的调查。在 ACM 系统中人工智能安全会议论文集，第 1-12 页，2025.

参考论文：https://arxiv.org/pdf/2505.02279