深度解析LM智能体互操作性协议：MCP、ACP、A2A与ANP全貌剖析

XCristiano
344 阅读16分钟

在当今人工智能领域，大语言模型（LLM）已成为核心驱动力。然而，由于缺乏一致性和标准化的互操作性实践，LLM驱动的智能体之间的通信整合、安全性和可扩展性面临巨大挑战。

图片

A Survey of Agent Interoperability Protocols: Model Context Protocol (MCP), Agent Communication Protocol (ACP), Agent-to-Agent Protocol (A2A), and Agent Network Protocol (ANP)

arxiv.org/pdf/2505.02…

本文将详细介绍四种新兴的智能体通信协议：模型上下文协议（MCP）、智能体通信协议（ACP）、智能体对智能体协议（A2A）和智能体网络协议（ANP），并探讨它们在不同部署场景中的互操作性解决方案。

智能体互操作性的挑战

随着大语言模型的广泛应用，自主智能体在多环境中的交互需求日益增加。然而，当前的互操作性实践存在以下问题：

  1. 碎片化与不一致性：不同智能体和系统之间的能力发现、上下文交换和行动协调缺乏统一标准，导致模块化、可重用性和弹性多智能体工作流难以实现。
  2. 开发与安全成本高：缺乏清晰、普遍接受的标准，使得开发和维护智能体通信系统变得复杂且成本高昂。
  3. 跨平台协作受限：不同平台之间的智能体难以实现无缝协作，限制了多智能体系统的潜力。

四种智能体通信协议概览

本文调研的四种协议分别针对不同的互操作性层级，旨在解决上述挑战：

  1. 模型上下文协议（MCP）：提供基于 JSON-RPC 的客户端-服务器接口，支持安全的上下文摄取和结构化工具调用。
  2. 智能体通信协议（ACP）：基于 REST 的原生消息层，支持多部分消息、异步流和可观测性，适用于本地多智能体系统。
  3. 智能体对智能体协议（A2A）：基于能力的 Agent Cards 和 HTTP/Server-Sent Events 的点对点框架，支持企业级任务编排。
  4. 智能体网络协议（ANP）：基于去中心化标识符（DIDs）和 JSON-LD 图的去中心化发现与协作协议，适用于开放网络中的智能体市场。

基于对四种协议的比较分析，本文提出了一个分阶段采用路线图，以指导智能体生态系统中的逐步部署：

  1. 第一阶段：MCP：从工具访问开始，确保智能体能够安全地调用外部工具。
  2. 第二阶段：ACP：引入多模态消息传递，支持智能体之间的复杂交互。
  3. 第三阶段：A2A：实现智能体之间的协作任务执行，支持企业级工作流。
  4. 第四阶段：ANP：扩展到去中心化智能体市场，实现开放网络中的动态发现和协作。

智能体协议的挑战与解决方案

大语言模型（LLM）需要上下文信息来生成准确的输出，但现有的应用架构缺乏统一机制来向LLM提供结构化上下文。这导致了工具集成的临时性和不可靠的行为。

解决方案：模型上下文协议（MCP）

MCP通过标准化应用程序向LLM提供工具、数据集和采样指令的方式，解决了这一问题。它类似于AI领域的“USB-C接口”，支持灵活的即插即用工具、安全的基础设施集成，并兼容不同LLM供应商的产品。

企业系统中常常包含使用不同技术栈和框架构建的智能体，导致它们行为孤立、协作困难。

解决方案：智能体通信协议（ACP）

ACP提供了一个RESTful接口，支持可选的SDK，并在Linux基金会下进行开放治理。它支持异步优先的交互、离线发现和供应商中立的执行，从而在大规模场景中弥合互操作性差距。

即使智能体之间能够通信，也缺乏共享框架来实现动态协商、能力共享和协调。

解决方案：智能体对智能体协议（A2A）

A2A引入了多模态通信标准，解锁了不透明自主智能体之间的动态交互，无论其使用何种框架。它简化了企业级集成，支持共享任务管理和用户体验协商。

现代互联网虽然适合人类交互，但对于需要低延迟、API原生通信和去中心化身份验证的自主智能体来说并不理想。

解决方案：智能体网络协议（ANP）

ANP提供了一个分层协议架构，结合了去中心化身份（W3C DID）、语义网原则和加密通信，以促进开放互联网上的跨平台智能体协作。

这些协议的目标是将碎片化的AI生态系统转变为强大、安全且可互操作的智能体网络，并能够跨越组织和供应商边界进行扩展。通过这些协议，我们可以实现以下目标：

  1. 标准化上下文传递：MCP确保LLM能够接收到结构化的上下文信息，从而提高输出的准确性和可靠性。
  2. 打破通信障碍：ACP通过RESTful接口和异步交互，使不同技术栈的智能体能够无缝协作。
  3. 实现动态协作：A2A通过多模态通信标准，支持智能体之间的动态交互和任务管理。
  4. 支持开放网络协作：ANP通过去中心化身份和加密通信，确保智能体在开放互联网上的安全协作。

智能体协议发展历程与未来展望

智能体被定义为能够感知环境并通过输出（如API调用、消息）实现目标的自主软件实体。智能体的架构从简单的基于规则的反应模型到复杂的信念-愿望-意图（BDI）系统不等。在多智能体系统中，智能体通过通信协议、协商策略和组织结构实现协作。

1. 早期符号化智能体语言

  • KQML（1993）：引入了基于言语行为（如询问、告知、回复）的消息格式和灵活的消息封装，但缺乏形式化的语义和复杂的XML编码，限制了其大规模部署。
  • FIPA-ACL（2000）：定义了更丰富的言语行为和交互协议，提供了Java平台（如JADE和JACK）的参考实现，但由于其复杂的本体管理和冗长的XML编码，主要应用于学术和国防领域。

2. 面向服务的集成与检索增强生成

  • 面向服务的架构（SOA，2002）：通过Web服务（SOAP、WSDL）和企业服务总线（ESB）实现企业系统的功能暴露和消息路由，但存在操作复杂性高、适配器脆弱等问题。
  • 检索增强生成（RAG，2020）：通过密集向量检索与自回归解码相结合，将外部知识集成到生成管道中，但缺乏将知识与行动调用统一的标准。

3. LLM驱动的智能体与函数调用

  • 函数调用（2023）：OpenAI引入了函数调用机制，使LLM能够输出JSON格式的API调用签名，统一了自然语言理解和行动调用。
  • 轻量级框架：如LangChain、LlamaIndex和OpenAI插件商店，简化了智能体开发，但存在工具定义静态化、安全边界分散和框架间互操作性差等问题。

在这里插入图片描述

4. 智能体的编排与轻量级框架

  • Toolformer（2023）：通过自监督掩码策略训练LLM预测API调用位置，将推理与行动调用相结合。
  • ReAct（2023）：通过交替“思考”步骤和工具调用实现动态工作流。
  • 轻量级框架：如CrewAI、SmolAgents和AG2，支持多智能体编排，但依赖静态工具注册表和定制通信层。

在这里插入图片描述

模型上下文协议（MCP）架构

在智能体互操作性领域，模型上下文协议（MCP）是一种重要的协议，旨在为大语言模型（LLM）提供标准化的上下文摄取和工具调用接口。

客户端应用是MCP生态系统中交互的发起者，负责管理与一个或多个MCP服务器的连接，并根据协议规范协调通信流程。客户端初始化会话，请求并处理MCP的四个核心原语：资源（Resources）、工具（Tools）、提示（Prompts）和采样（Sampling），同时处理与服务器端事件相关的异步通知。客户端还需要实现强大的错误处理机制，以优雅地管理通信失败或超时条件，确保与远程MCP服务器的可靠协调。

在这里插入图片描述

MCP服务器提供了四个核心能力：工具（Tools）、资源（Resources）、提示（Prompts）和采样（Sampling），每个能力都对应一个控制模型，管理客户端、服务器和LLM之间的交互。

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

智能体对智能体协议（A2A）架构

在人工智能领域，智能体之间的协作变得越来越重要。智能体对智能体协议（A2A）正是为了解决不同智能体系统之间的通信和协作问题而设计的。

在这里插入图片描述

A2A架构主要涉及三个核心参与者：

  1. 用户（User）：发起任务或请求的主体，可以是人类用户、系统、服务，甚至是其他智能体。
  2. 客户端智能体（Client Agent）：接收用户请求，分析意图，并协调远程智能体（Remote Agent）执行任务。
  3. 远程智能体（Remote Agent，也称为服务器端智能体）：执行客户端智能体委托的任务，并返回结果。

用户是A2A交互的发起者，可以是直接与客户端智能体交互的终端用户（如通过聊天机器人或语音助手），也可以是间接利用A2A智能体的系统或服务（如企业仪表板或编排工具）。用户不需要直接与远程智能体交互，而是依赖客户端智能体来翻译请求并协调响应。

客户端智能体是用户意图的代表，负责协调远程智能体完成任务。它的主要职责包括：

  • 智能体发现：通过Agent Card检索和评估远程智能体的能力。
  • 任务初始化：构建结构化的任务对象，封装用户意图和输入参数。
  • 消息与结果交换：与远程智能体双向通信，发送指令并接收输出（称为“工件”）。
  • 错误处理与结果呈现：解析失败响应，执行恢复策略，并将结果转换为用户可消费的格式。

远程智能体是执行任务的服务端点，提供一系列技能（Skills），这些技能是其可以执行的具体操作，如数据检索或复杂计算。每个技能都有明确的输入输出定义，确保跨客户端的一致调用。

远程智能体通过Agent Card公开其能力，该卡片是一个JSON格式的元数据文档，包含技能列表、使用说明、输入输出格式和支持的协议等信息。此外，远程智能体还需要管理内部资源使用，并执行安全与访问控制机制，以确保任务执行的安全性和可靠性。

A2A支持多种传输机制，以适应同步和异步工作流程：

  • Server-Sent Events（SSE）：用于实时流式传输，远程智能体可以通过持久HTTP连接向客户端智能体发送实时状态更新。
  • 推送通知：适用于移动或分布式部署，远程智能体可以通过推送通知服务向客户端智能体发送任务进度或完成通知。

智能体通信协议（ACP）架构

智能体通信协议（ACP）通过定义一个分层的、基于REST的框架，为AI智能体之间的互操作性提供了标准化的解决方案。

在这里插入图片描述

ACP采用了简化的三角色架构，旨在标准化智能体之间的发现、调用和交互：

  1. 智能体客户端（Agent Client）：负责发现智能体并通过注册表发起ACP兼容格式的结构化请求。它将用户意图封装到多部分消息中，管理会话级上下文，并处理智能体返回的有序响应部分。
  2. ACP服务器（ACP Server）：作为协议代理，维护智能体注册表（Agent Registry），并执行系统级策略（如身份验证、授权和速率限制）。它负责接收客户端请求，执行智能体查找和路由，并确保响应部分按顺序安全返回给客户端。
  3. ACP智能体（ACP Agent）：作为执行端点，负责处理具体的业务逻辑。它可以作为无状态微服务运行，也可以维护会话上下文以支持多轮交互。智能体接收结构化请求，按照注册的技能定义处理它们，并在任务完成后返回符合ACP消息结构规范的响应部分。

ACP支持集中式（如注册表API）和分布式（如在/.well-known/agent.yml路径下托管的清单文件或容器标签中的部署元数据）的发现机制。这些机制使得客户端可以在运行时动态地发现智能体，而无需依赖固定的配置，支持大规模智能体网络的扩展。

任务请求是客户端委托给智能体的结构化工作单元，由有序的消息部分组成，指定目标操作并包含文本输入、二进制负载或外部托管数据的引用。这种设计支持同步调用和长时间运行的异步任务。

ACP运行时支持同步执行和中间结果的增量流式传输。每个任务通过明确定义的状态（如创建、进行中、等待）进行管理。对于多轮交互工作流，会话级持久化确保上下文的连续性。

智能体网络协议（ANP）架构

智能体网络协议（ANP）作为一种去中心化的点对点通信标准，为智能体之间的自主发现、认证和交互提供了强大的支持。

在这里插入图片描述

  • 去中心化身份：通过去中心化标识符（DIDs）唯一标识智能体，支持跨平台的身份管理。
  • 动态协议协商：支持智能体之间动态协商交互协议，适应不同复杂度和使用场景。
  • 安全与隐私保护：通过加密通信和身份验证机制，确保智能体之间的安全交互。

ANP的核心是智能体身份，它通过去中心化标识符（DIDs）唯一标识智能体。ANP采用did:wba方法，每个标识符对应一个HTTPS托管的DID文档，利用现有的Web基础设施实现去中心化身份解析。

智能体描述是智能体的公开配置文件，以JSON-LD格式存储，包含智能体的名称、能力、支持的协议、认证方案和服务端点等元数据。这些描述文档通过Agent Description Protocol（ADP）发布，支持语义理解和互操作性。

ANP依赖HTTP(S)作为传输协议，使用JSON-LD作为数据格式。它利用Schema.org词汇表和上下文（如ad:）实现语义清晰性。结构化接口（如JSON-RPC和OpenAPI）通过ADP嵌入，兼容性强。

协议架构对比

协议架构模型
MCP客户端-服务器模型，基于JSON-RPC原语
ACP经过代理的客户端-服务器模型（注册表 + 任务路由）
A2A类似对等的客户端与远程智能体交互
ANP去中心化的对等交互
  • MCP采用经典的客户端-服务器架构，通过JSON-RPC实现请求和响应的交互，适合于资源注入和工具调用。
  • ACP引入了代理服务器，通过注册表和任务路由机制管理智能体之间的通信，支持多模态消息传递。
  • A2A更接近对等网络架构，客户端可以直接与远程智能体交互，适合企业级任务委托。
  • ANP则是完全去中心化的对等架构，基于DID（去中心化标识符）实现智能体之间的直接通信。
协议智能体发现机制
MCP手动注册或静态URL查找
ACP基于注册表的Agent Card检索（通过HTTP）
A2A搜索引擎发现
ANP基于DID的去中心化发现
  • MCP依赖于手动注册或静态URL，适合已知的、固定的工具和服务。
  • ACP通过注册表和Agent Card实现智能体发现，支持动态查找和能力匹配。
  • A2A利用搜索引擎技术，支持大规模智能体网络的发现。
  • ANP基于DID实现去中心化发现，适合开放互联网环境下的智能体互操作。
协议目标范围主要用例
MCPLLM与外部工具/服务集成为LLM注入外部能力（如代码执行、搜索）
ACP模型无关，基础设施级智能体多样化智能体之间的安全、类型化消息交换
A2A企业级任务委托组织内部的信任边界内的多智能体工作流
ANP开放互联网智能体互连跨平台智能体发现和安全P2P执行
  • MCP专注于LLM与外部工具的紧密集成。
  • ACP适用于需要多模态交互和安全通信的场景。
  • A2A适合企业级任务委托和工作流管理。
  • ANP则面向开放互联网环境下的智能体互操作性。
avatar
文章
阅读
粉丝