导读
随着推理大模型的出现(deepseek,Qwen3等),进一步地推进了大模型的智能体系统发展。然而,如何使智能体更好的调用外部工具,智能体与智能体之间如何有机地协作,仍然没有一个完美的答案。这篇工作总结了各种智能体互操作协议(MCP/ACP/A2A/ANP等),推荐阅读学习。
©️【深蓝AI】编译
论文题目:A SURVEY OF AGENT INTEROPERABILITY PROTOCOLS: MODEL CONTEXT PROTOCOL (MCP), AGENT COMMUNICATION PROTOCOL (ACP), AGENT-TO-AGENT PROTOCOL (A2A), AND AGENT NETWORK PROTOCOL (ANP)
论文作者:Abul Ehtesham, Aditi Singh, Gaurav Kumar Gupta, Saket Kumar
论文地址:https://arxiv.org/pdf/2505.02279
大语言模型(LLMs)已成为现代人工智能的核心技术,驱动着可在云端、边缘端及本地终端环境中运行的自主代理。这类代理能够摄取上下文信息、执行任务,并与外部服务或工具进行交互。然而,当前不一致且碎片化的互操作性实践,导致LLM驱动型代理间的通信集成、安全保障及规模化扩展面临显著挑战。
互操作性(即不同代理与系统间实现能力发现、上下文交换及行动无缝协调的能力)是构建模块化、可复用且具备韧性的多代理[5]工作流的关键要素。标准化协议能够降低开发成本、增强安全性,并支持跨平台协作。然而当前清晰且被广泛采纳的通用标准仍处于萌芽阶段。该研究聚焦于四种新兴的代理通信协议,分别针对不同的互操作层级:
• 模型上下文协议(MCP) :一种基于JSON-RPC的客户端-服务器接口,支持安全上下文摄取与结构化工具调用。
• 代理间协议(A2A) :通过HTTP协议和服务器发送事件(SSE),利用能力导向的代理卡片实现点对点框架,服务于企业级任务编排[9]。
• 代理通信协议(ACP) :基于REST原生范式的声明式消息层,整合多部分消息、异步流式传输及可观测性功能,专为本地多代理系统设计[10]。
• 代理网络协议(ANP) :基于去中心化标识符(DIDs)和JSON-LD图结构构建的开放式互联网代理市场协议,支持去中心化发现与协作[11,12]
该研究从架构细节、集成方法、通信模式及安全考量四个维度对各协议进行系统性分析。通过横向对比,重点揭示了交互模式、发现机制、通信模型与安全框架之间的取舍关系。研究进一步提出分阶段实施路线图——按照MCP、A2A、ACP到ANP的顺序推进部署,为现实场景下智能体生态系统的渐进式扩展提供实施指引。
智能体系统面临的挑战与解决方案
尽管MCP、ACP、A2A和ANP等开放协议相继涌现,但在实际AI系统中实现智能体间的无缝互操作性仍非易事。本节剖析了基于代理的架构所面临的核心挑战,并着重阐释各协议如何通过针对性设计原则应对这些问题:
大语言模型上下文标准化缺失问题
大语言模型(LLMs)需要上下文基础才能生成准确输出。然而,现有应用架构缺乏统一的机制向LLMs传递结构化上下文,导致工具集成方式临时化且行为不可靠。
解决方案:模型上下文协议(MCP)通过标准化应用向LLMs传递工具、数据集和采样指令的方式,解决了这一问题——其作用类似于AI领域的USB-C标准。该协议支持灵活的即插即用工具、安全的基础设施集成,并兼容不同LLM供应商的技术体系。
异构智能体间的通信壁垒问题
企业系统通常由基于不同技术栈和框架构建的智能体组成,导致行为孤立且协作效率低下。
解决方案:智能体通信协议(ACP)提供符合RESTful风格、可选SDK的接口,并在Linux基金会下实行开放治理。它通过异步优先的交互模式、离线发现机制和供应商中立的执行环境,实现了大规模场景下的互操作性突破。
图片 1 应对智能体通信问题的解决方案
统一智能体协作标准缺失问题
即使智能体之间能够通信,当前仍缺乏支持动态协商、能力共享与协同调度的通用框架。
解决方案:智能体间协议(A2A)引入多模态通信标准,实现不同框架下异构自治智能体间的动态交互。该协议简化企业级系统集成,支持共享任务管理与用户体验协商机制。
普适性智能体通信挑战
现代互联网虽为人类交互优化,却难以满足智能体对低延迟、API原生通信及去中心化身份验证的需求。
解决方案:智能体网络协议(ANP)构建分层协议架构,整合万维网联盟去中心化标识符(W3C DID)、语义网原则与加密通信技术,赋能开放互联网环境中的跨平台智能体协作。
整体价值
上述协议共同致力于将碎片化的AI生态转化为健壮、安全且可互操作的智能体网络——实现跨组织与供应商边界的规模化扩展。
MCP(Model Context Protocol )架构
模型上下文协议(MCP)采用多层抽象架构规范通信结构与语义。其底层为协议层,基于JSON-RPC 2.0规范定义消息交换的语义规范,确保每个请求均与对应响应严格绑定,且所有交互行为遵循可预测模式。中间层为传输层,负责客户端与服务端间的物理消息传输,支持两种通道模式:通过标准输入输出(Stdio)实现的本地通信,以及基于HTTP协议的网络通信(可选集成服务器发送事件SSE实现实时流式传输)。最高抽象层将消息划分为四类核心类型:请求(Request)——需要接收方回复的同步调用指令; 结果(Result)——对成功执行请求的响应;错误(Error)——标识调用失败或非法操作的状态反馈;以及通知(Notification)——无需客户端确认的异步更新消息,适用于实时状态推送等场景。
图片 2 MCP的结构图
MCP服务器的四大核心能力
MCP服务器提供工具(Tools)、资源(Resources)、提示模板(Prompts)和采样(Sampling)四大核心功能,每项功能对应独特的控制模型,共同管理客户端、服务器与大语言模型间的交互逻辑:工具(Tools)
作为模型管控能力,允许LLM自动或经用户授权后调用外部API及服务。此机制实现与第三方系统的无缝集成,并简化对现实世界数据与操作的访问流程。
资源(Resources)
属于应用管控元素,由客户端应用自主选择并管理结构化文档、上下文数据集等内容。其为LLM提供任务定制化输入,支撑具备上下文感知能力的生成结果。
提示模板(Prompts)
采用用户主导模式,由服务器预定义可复用模板库,终端用户通过客户端界面按需选择。该机制保障交互一致性,降低重复劳动,支持标准化交互范式的构建。
采样(Sampling)
由服务器集中管控,MCP服务器可将LLM生成任务委派至客户端执行。此能力支持复杂智能体工作流,并允许对模型生成过程(如动态调节温度参数、生成长度等)实施细粒度监管。
MCP链接生命循环
模型上下文协议(MCP)交互生命周期
该协议为客户端-服务器交互定义了三阶段生命周期,旨在确保会话管理稳健性、功能协商安全性及终止流程可控性。三个阶段——初始化(Initialization)、操作(Operation)与关闭(Shutdown)——严格对应客户端应用与MCP服务器间的时序通信逻辑。初始化阶段
• 协议兼容性验证:客户端与服务器协商双方支持的最高协议版本• 功能交换机制:双方声明可选的会话级功能(如采样、提示模板、工具链、日志记录等)
• 就绪信号传递:客户端在接收服务器初始化响应后,发送notifications/initialized消息,标志进入操作阶段
操作阶段
• 交互规则:基于协商功能执行JSON-RPC方法调用与通知,双方须严格遵循初始化阶段达成的约束• 执行容错机制:每个任务调用可配置超时阈值,若超时未响应,客户端可触发取消通知以防止资源耗尽或陈旧线程
• 状态管理:实时维护会话上下文,确保多轮交互的连贯性与原子性
关闭阶段
• 终止触发方式:任一方可通过关闭传输层(HTTP或标准输入输出通道)发起会话终止• 资源清理责任:双方须释放活跃超时器、取消订阅事件、回收子进程资源
• 终止后约束:禁止发送新协议消息(诊断类基础操作如心跳检测、日志刷新除外)
MCP的问题与挑战
随着MCP协议在企业及开发者生态中的普及,其生命周期各阶段(初始化、运行、更新)暴露出多重安全漏洞。这些风险包括工具中毒、权限驻留、命令注入等攻击向量,而大语言模型对提示词操控的敏感性及执行链路的不透明性,进一步放大了安全威胁的潜在影响。
系统性梳理了MCP部署各阶段最严峻的安全威胁,并给出对应的缓解策略与权威参考标准。该分析框架整合了当前公开的攻击案例与来自最新审计报告、协议评审的最佳防御实践:
表格 1 MCP协议面临的安全挑战
A2A(Agent-to-Agent)架构
A2A架构旨在实现异构智能体系统间的通信与协作,以完成复杂任务。其核心由三大交互主体构成:
用户(User)
任务需求的发起方,通过客户端界面定义目标并监控执行状态。
客户端智能体(Client Agent)
作为用户代理,负责任务分解、资源调度,并与远程智能体建立安全会话通道。
远程智能体(服务端)
提供专业化服务能力,按协议规范响应任务请求并返回结构化结果。
三大主体通过标准化通信协议实现以下核心特性:
• 安全验证机制:基于零知识证明的跨链身份认证,防止中间人攻击• 语义互操作性:通过能力描述语言(ADL)统一服务接口语义,消除框架差异
• 执行原子性:支持两阶段提交(2PC)协议,保障分布式任务的事务完整性
该架构已在金融风控(实时反欺诈协作)与工业物联网(跨厂区设备协同运维)场景中验证其企业级扩展能力。
A2A核心组成部分
用户触发任务请求(通常无需理解底层智能体系统的技术细节),客户端智能体接收请求后解析任务意图,通过检索远程智能体发布的能力卡片(Agent Card)匹配最适格的服务提供方。随后,客户端智能体与选定的远程智能体建立会话通道,协调消息交换并获取任务执行产物(Artifacts),最终将结构化结果返回至用户端。
用户端
用户作为任何A2A交互的发起者,通常带有着启动智能体流程的意图或需求。虽然用户通常为人类最终用户,但它也可以是分层工作流程中的某个系统、服务或另一个智能体。无论其形式如何,用户都不会直接与远程智能体交互,而是依赖客户端智能体将其请求转化为可执行的任务,并协调所有响应。
客户端智能体
A2A支持多样化的用户交互模式。直接终端用户可通过聊天机器人或语音助手等接口与客户端智能体交互,实时提供任务输入并接收结果;间接终端用户则与更高层系统(如企业仪表盘或协调工具)交互,这些系统在后台透明化调用A2A智能体;系统或服务也可作为用户,自主调用A2A智能体完成数据转换、监控等工作流;在多智能体层级结构中,当某一智能体通过触发另一智能体的下游操作来完成复杂任务时,则形成"智能体即用户"场景。这些多样的用户范式体现了该协议对用户身份的不可知性,并着重强调其核心目标——标准化客户端智能体与远程智能体之间的通信。
客户端智能体作为代表用户意图的中介,负责与远程智能体协调以实现该意图。其职责涵盖任务生命周期的多个阶段:首先执行智能体发现流程,检索并评估描述各远程智能体技能、能力、输入/输出规格及认证要求的智能体卡片;基于此发现结果,选择与用户任务匹配的远程智能体;随后进行任务初始化,构建结构化的任务对象(封装用户意图、相关元数据及格式化输入),并通过规范化的消息格式将任务发送至选定远程智能体;在执行阶段,管理消息与产物交换——与远程智能体进行双向通信(发送新指令或后续请求,接收称为"产物"的输出及中间状态更新);对于长期运行或需状态保持的交互,则维护会话上下文,使用标识符将相关交互归组到统一工作流中。
客户端智能体还负责错误处理——解析远程智能体返回的失败响应,并执行适当的恢复策略(如重试、选择备用智能体或通知用户)。执行完成后,通过结果呈现步骤将产物转换为用户可用的格式,并集成到相关应用程序或用户界面中。
在支持相关功能的情况下,客户端智能体可通过Server-Sent Events(SSE)或推送通知等机制处理异步通信。对于SSE,客户端智能体会建立持久连接并实时流式传输更新;若支持推送通知,则向通知服务注册以通过独立通道接收任务更新。总体而言,客户端智能体在A2A协议中充当执行协调器、数据转换器与通信桥梁的角色,代表用户实现智能且具备上下文感知能力的交互。
远端智能体(服务端)
远端智能体(服务端)是执行客户端智能体委派任务的服务端点,其提供一项或多项"技能"——这些技能代表该智能体可执行的离散化操作,涵盖从简单数据检索到复杂计算,乃至涉及外部API或数据库的协调操作。每项技能均通过其输入/输出模式进行正式定义,从而实现跨客户端调用的一致性。
为实现这些能力的可发现性,远程智能体发布智能体卡片——这是一种包含可用技能列表、使用说明、输入/输出格式、支持协议及认证要求的结构化元数据文档。该智能体卡片既作为交互智能体间的服务宣传,又充当接口约定。
远程智能体还需管理其内部资源使用,确保任务执行期间对计算、内存、网络及存储资源的公平分配。除执行功能外,其还负责执行安全与访问控制机制——包括认证客户端身份、验证消息完整性,以及基于访问策略或令牌范围对特定技能的访问权限进行授权。通过将服务能力抽象为模块化且独立管理的组件,远程智能体支持智能体生态系统内的可组合性、可靠性与互操作性。
Agent Communication Protocol (ACP)架构
智能体通信协议(ACP)定义了一个层级化、基于REST原生设计的框架,专为实现可互操作AI智能体而构建。其静态架构由明确角色与协议层构成,各层级均负责明确定义的功能集。
ACP架构总览
智能体通信协议(ACP)定义了一种简化的三角色架构,旨在标准化AI智能体间的发现、调用与交互。该架构确保客户端无需定制化集成即可实现:无缝定位智能体、发起结构化任务请求、接收多模态响应。
智能体客户端作为该架构的入口点,通过已发布的注册表发现智能体并构建符合ACP规范的格式化请求来发起通信。其核心功能包括:将用户意图封装为多部分消息;按需管理会话级上下文;处理从纯文本到富产物及二进制数据等多种由智能体返回的有序响应组件。
ACP服务器作为该协议体系的核心,承担协议中介角色。其主要功能包括:维护遵循智能体详情模式定义的元数据目录——智能体注册表;执行系统级策略(包括身份认证、访问授权与速率限制)。当接收到客户端请求时,ACP服务器完成智能体查找与路由,确保请求符合注册能力范围,并按预定顺序将响应组件安全传输回客户端。
ACP智能体代表执行端点,承载领域特定逻辑。其可运行为无状态微服务,也可维护会话上下文以支持多轮交互。该智能体接收由有序消息组件构成的结构化请求(每个组件均按语义元数据标记),并根据注册技能定义进行处理;任务完成后,生成符合ACP消息结构规范的响应组件,从而建立统一且可解析的响应管道。
这三个组件共同构建了一个模块化且可互操作的智能体通信框架,促进可扩展部署、松耦合架构,以及发现、协调与执行逻辑的明确分离。
图片 3 ACP架构概览图
ACP主要组成部分
ACP交互由一组核心组件规范管理,这些组件定义智能体行为、实现运行时互操作性并标准化任务通信。其架构核心是智能体详情——一种采用JSON或YAML格式的自描述文档,充当智能体的公开身份与能力档案。该文档提供关键元数据,包括智能体名称、可用操作、支持的内容类型、认证方案及运行时诊断信息。客户端将智能体详情作为调用前提,无需定制化集成即可实现可信代理选择与调用。
作为补充,发现机制使客户端能在运行时动态定位智能体。这些机制既可采用中心化形式(如注册表API),也可采用去中心化形式——包括托管在知名URL路径下的清单文件(例如/.well-known/agent.yml)或内嵌于容器标签等部署元数据中的配置。该可发现性层将客户端逻辑与固定配置解耦,支持构建可扩展的智能体网络。
当智能体被定位后,客户端会发起任务请求——这种结构化的工作委托单元由有序消息组件构成,具体包含:指定目标操作、文本输入内容、二进制负载或外部托管数据引用。该设计既支持同步调用,也支持需长期运行的异步任务。
所有请求与响应均遵循ACP的消息结构规范,该规范对通信信封进行标准化定义。每个消息由有序部件列表构成,各部件均明确标注MIME内容类型,并包含内嵌内容或可解引用内容URL值。可选名称属性支持使用带有语义标记的产物,从而促进下游系统对数据的解析。
智能体执行的结果最终封装为一个或多个产物。这些产物可包括结构化JSON输出、纯文本结果、二进制文件乃至嵌套消息引用等类型。产物作为消息结构响应的一部分传递,随后可被呈现、存储或链接至其他智能体工作流,从而实现支持ACP协议系统间的可扩展性与可组合性。
Agent Network Protocol (ANP)架构
智能体网络协议(ANP)是一种去中心化的点对点通信标准,专为开放互联网上的跨平台智能体互操作性而设计。ANP使智能体能够通过结构化元数据与AI原生数据交换,实现自主发现、认证及交互。后续章节将ANP的架构与标准化生命周期及模块化框架进行对齐,使其与MCP、A2A、ACP等协议保持建模一致性。
图片 4 ANP结构图
ANP主要组成部分
智能体网络协议(ANP)的底层由一组基础组件支撑,共同实现去中心化身份、语义自描述、发现机制及自适应交互。其核心是智能体身份——采用去中心化标识符(DIDs)实现跨平台唯一身份识别。具体而言,ANP采用did:wba方法,每个标识符对应一个通过HTTPS托管的DID文档,从而充分利用现有Web基础设施进行去中心化身份解析。
智能体网络协议(ANP)在身份层之上构建了智能体描述功能,通过智能体描述协议(ADP)实现。这些采用JSON-LD格式的文档包含智能体的结构化元数据,涵盖名称、功能能力、支持协议、认证方案及服务端点等信息,作为智能体的公开可访问资料,促进互操作性与语义理解。
智能体通过发现目录对外公开其存在状态与功能能力,该目录通常位于标准化路径/.well-known/agent-descriptions下。此目录使人类用户与自动化系统均可获取特定域名下的可用智能体列表,为可扩展的智能体索引与搜索奠定基础。为支持交互,ANP协议提供两类通信接口:结构化接口(如REST API或gRPC端点,需严格遵循预定义模式),以及自适应接口(如自然语言指令通道,支持通过LLM驱动的意图解析与动态行为生成)。
为支持交互,智能体网络协议(ANP)提供两类通信接口:结构化接口(如JSON-RPC与OpenAPI)及自然语言接口(通过YAML或等效模式文件定义)。这两类接口均在智能体描述中声明,支持根据场景复杂度与用例灵活选择交互模式。
最后,元协议协商器实现智能体间的动态协议对齐。该机制允许智能体交换关于其通信需求与能力的自然语言描述,并基于此协商生成兼容的交互协议实例。通过支持运行时自适应性与协议协商,这一技术层确保即使在异构智能体生态系统间也能实现无缝互操作。
Agent协议对比
为更清晰理解主流智能体互操作性协议间的差异,下表对四个广泛讨论的框架进行横向对比:模型上下文协议(MCP)、智能体通信协议(ACP)、智能体间协议(A2A)与智能体网络协议(ANP)。该结构化分析聚焦各协议的架构设计、消息格式、发现机制、会话模式及目标用例,从而揭示其在多样化部署场景中的适用性。
结论
随着基于大语言模型的自主智能体在各领域快速普及,对安全、模块化且可互操作的通信需求变得日益紧迫。本研究通过结构化分析四类新兴协议——MCP、ACP、A2A与ANP,系统阐释了它们分别在智能体互操作的不同层级提供的解决方案。这些协议通过统一工具调用、多模态消息传递、任务协调及去中心化发现机制,共同构建了可扩展多智能体系统的技术基础。对比研究表明,单一协议无法满足所有场景需求,而采取分阶段互补的采用策略(从MCP起步,逐步演进至ACP、A2A直至ANP),为部署智能体生态系统提供了切实可行的路径。未来研究应聚焦于协议互操作桥梁构建、智能体协作信任框架开发及标准化评估基准建立,以加速技术落地并保障实际部署的鲁棒性。这些基础性工作将成为推动下一代智能网络化智能体发展的关键支撑。