Orac1e の blog

Back
Agent 通信协议综述Blur image
29 min read
简中
agent

Agent 通信协议综述

Agent 通信协议调研
views | comments

1、A SURVEY OF AGENT INTEROPERABILITY PROTOCOLS: MODELCONTEXT PROTOCOL (MCP), AGENT COMMUNICATIONPROTOCOL (ACP), AGENT-TO-AGENT PROTOCOL (A2A), ANDAGENT NETWORK PROTOCOL (ANP)#

image-20251207141524267

以往的综述描述基于 LLM 的多代理系统的特征，对协作模式、内存架构和协调策略进行分类。

然而，这些研究主要集中在高层次的工作流上，而忽略了动态同伴发现、能力协商和安全工具调用所需的底层协议。

为什么需要 Agent protocol?#

Interoperability (互操作性)：不同代理和系统发现、交换上下文和无缝协调行动的能力。

由大型语言模型（LLM）驱动的自主代理需要强大的标准化协议来整合工具、共享上下文数据（减少开发开销、提高安全性并实现跨平台协作），以及在异构系统间协调任务。临时集成难以扩展、安全和跨域通用。

Agent protocol 发展历程#

Agent被定义为任何自主软件实体，它通过输入（如用户查询、传感器数据）感知环境，并通过输出（如API接口调用、信息）对环境采取行动，以实现指定目标（早期基于规则、逻辑，后期基于LLM）

  1. 1990s - 2000 : 早期的符号Agent语言(KQML、FIPA-ACL),并非协议而是一种语义规范

KQML：第一种正式的Agent信息传递语言，定义了一组行为执行词（如：ask、tell、reply），以及发送者、接受者、消息内容(通常是 KIF、Prolog 等逻辑式)等原信息的封装格式

(ask 
  :sender A 
  :receiver B 
  :language KIF 
  :content "(price item123 ?p)")
ruby

大规模应用于DARPA的分布式知识库中，但因performative的语义不严格、无完整的交互协议等因素，工程实现难度大。

FIPA-ACL：在KQML的基础上提出的更严格语言，规定了基于行为者意图的精确的前置条件和后置条件语义。定义了一套更丰富的执行语，概述了完整的交互协议

在学术界和国防领域有所应用，但因为其实现和ontology管理的复杂性，没有在工业界形成完整生态

这些早期标准为后续Agent通信协议设计奠定了语义基础（Agent通信格式标准化和意图声明）

  1. 2000 - 2006 : 网络服务（SOA）和企业服务总线（ESB）框架的后续发展简化了企业集成，但也带来了复杂性和有限的灵活性。

SOAP：一种基于 XML 的远程调用协议，规范了消息格式、类型系统、错误码。

WSDL：用来描述一个服务的接口、输入/输出类型、端点，还有协议绑定方式。

WS-Security：一整套企业级协议，定义服务如何做可靠传输、安全、策略协商等。

  1. 2020 - 2023 : 检索增强（RAG）和模型内Action，这一阶段以引入检索增强生成（RAG）为标志，利用基于向量的检索来增强语言模型输出的基础。function calling、Toolformer 和 ReAct 等创新技术使 LLM 能够直接将推理转化为可执行的 API 调用，从而大大提高了代理的自主性和灵活性。

Toolformer : 让语言模型自己学会“什么时候需要使用工具、用哪个工具、如何构造调用参数”。

ReACT : 让 LLM 在一段structured text中交替进行推理（Thought）与行动（Action）

  1. 2024 - 2025 : 协议导向提高可操作性，现阶段强调轻量级标准化协议，如 MCP、ACP、ANP 和 A2A。这些协议通过在异构代理系统间实现动态发现、安全通信和分散协作，提高了可扩展性和强大的互操作性，从而解决了以往的局限性。

Agent protocol 挑战#

  1. LLM缺乏标准化的上下文：大型语言模型（LLM）需要以上下文为基础才能产生准确的输出结果。然而，现有的应用架构没有提供统一的机制来为 LLM 提供结构化的上下文，从而导致了临时的工具集成和不可靠的行为

Model Context Protocol —— MCP(2024.11):为了解决这个问题，它将应用程序向LLM传输工具调用结果、数据集和采样指令的方式标准化，类似于人工智能的 USB-C。它支持灵活的即插即用工具、安全的基础设施集成以及 LLM 供应商之间的兼容性。

  1. 异构代理间的通信障碍：企业系统通常由使用不同堆栈和框架构建的Agent组成，导致行为孤立、协作不畅。

Agent Communication Protocol —— ACP(2025.3):弥补互操作性

特性：提供RESTful,SDK可选的接口（利用HTTP通信、提供官方工具包），异步优先交互，离线发现（无需启动代理，通过读配置文件获知能力），厂商中立执行（在Linux基金会下开放治理的，不是大厂的私有协议）

  1. 缺乏统一的代理协作标准：即使代理进行了交流，也没有用于动态协商、能力共享和协调的共享框架。

Agent2Agent protocol —— A2A(2025.4):引入了一种多模式通信标准，以开启不透明的自主代理之间的动态交互

特性：Agent Cards机制（通过特定端点将Agent能力，认证方式等公开），共享任务管理（Agent共同维护、更新和追踪该任务的整体进度和状态），用户体验协商（多Agent共同决定和优化输出的格式、风格或交付方式）

  1. 互联网无关Agent通信：现代互联网针对人类交互进行了优化，但对于需要低延迟、API通信和分散式身份验证的自主代理来说却不是最佳选择

Agent Network protocol —— ANP(2025.5):提供了一个分层协议架构，以促进开放互联网上的跨平台代理协作。

特性：去中心化（非C/S架构），基于W3C DID的去中心化身份验证，自主发现机制

各协议不同生命周期可能遭遇的攻击#

MCP

阶段 (Phase)威胁 (Threat)描述 (Description)缓解策略 (Mitigation Strategy)
创建 (Creation)安装程序欺诈(Installer Spoofing)在构建或安装流水线中引入的恶意包。强制执行 SBOM（软件物料清单）、数字签名和可重现构建。
供应链后门(Supply-Chain Backdoors)通过 CI/CD 构建产物植入的持久性恶意软件。加固 CI/CD 流程，验证清单，并核实构建产物的完整性。
名称冲突(Name Collision)使用相似名称冒充受信任的 MCP 代理。使用 Sigstore 和 DID（去中心化身份）来确保唯一且可验证的身份。
无认证握手(No Auth Handshake)客户端连接到未认证或恶意的服务器。强制执行双向认证和基于 TLS 的验证。
运行 (Operation)工具中毒(Tool Poisoning)恶意提示词或元数据影响大语言模型 (LLM) 的行为。验证架构 (schemas)，使用过滤（YARA/正则），并应用语义防护。
凭据窃取(Credential Theft)通过补全或工具输出泄露机密信息。使用 OAuth 2.1 + PKCE，限制令牌范围，并强制执行 mTLS。
沙箱逃逸(Sandbox Escape)工具访问宿主操作系统或绕过隔离。使用系统调用过滤 (syscall filters)、AppArmor 和容器加固。
远程访问控制(Remote Access Control)LLM 注入 SSH 密钥或创建后门 Shell。使用 EDR/HIDS 监控并限制出站行为。
命令注入 / RCE(Command Injection / RCE)不安全的输入触发系统执行。清洗输入，禁用 Shell 访问，并禁止使用 eval。
工具重定义(Tool Redefinition)工具在验证后变恶意（“卷款跑路”/Rug pull）。使用签名且版本化的清单，并监控变更。
跨服务器遮蔽(Cross-Server Shadowing)一个服务器覆盖另一个服务器的工具引用。强制执行作用域命名空间并验证路由来源。
缺乏可见性(Lack of Visibility)客户端无法检查工具指令或载荷。启用调试模式、元数据内省 (introspection) 和日志记录。
更新 (Update)版本漂移(Version Drift)仍在使用旧的、易受攻击的 MCP 版本。使用 GitOps 进行漂移检测并强制自动修复。
权限持久化(Privilege Persistence)保留了提升的角色或旧的令牌范围。更新后审计角色并轮换凭据。
配置漂移(Configuration Drift)更新后引入了错误配置。对照 CVE 验证并应用加固的默认设置。
未签名的工具清单(Unsigned Tool Manifests)部署后清单被篡改或注入。强制执行签名检查并阻止未签名的工具。

A2A

阶段 (Phase)安全挑战 (Security Challenge)威胁描述 (Threat Description)缓解策略 (Mitigation Strategy)
创建 (Creation)代理卡片与清单欺骗(Agent Card & Manifest Spoofing)攻击者可能篡改代理卡片 (Agent Card) 或位于 ./well-known/agent.json 的清单，冒充受信任的远程代理。数字签名代理卡片，验证检索时的校验和，并加固 CI/CD 流水线以防止注入。
运行 (Operation)任务注入与命令伪造(Task Injection & Command Forgery)恶意任务或 send/sendSubscribe 调用可能操纵 JSON-RPC 以触发未经授权的执行。强制使用 TLS，使用 JSON Web 签名 (JWS)，验证架构 (schemas)，并签发带作用域的能力令牌。
推送通知劫持(Push Notification Hijacking)攻击者可能欺骗 SSE 端点或拦截通知，导致虚假更新或信息泄露。认证通知通道，按会话隔离流，并对推送的事件进行签名。
更新 (Update)未经授权的能力注入与版本漂移(Unauthorized Capability Injection & Version Drift)未经授权的行为者可能向代理卡片添加隐藏技能，或客户端可能依赖过时的配置。使用不可变、版本化的清单，用 GitOps 检测漂移，并要求签署清单差异。
终止 (Termination)废弃资源与审计漏洞(Orphaned Resources & Audit Gaps)令牌、SSE 流或代理注册可能在使用后仍然存在，使安全审计复杂化。实施关闭钩子 (shutdown hooks)，撤销凭据，并集中审计日志记录，强制保留。

ACP

阶段 (Phase)安全挑战 (Security Challenge)威胁描述 (Threat Description)缓解策略 (Mitigation Strategy)
创建 (Creation)元数据欺骗与供应链攻击(Metadata Spoofing & Supply Chain Attacks)攻击者可能发布伪造的代理细节 (Agent Detail) 清单（例如，位于 ./well-known/agent.yml），冒充代理或注入恶意技能。对所有清单进行数字签名，在发现时进行验证，并强制执行 CI/CD 签名检查和工件验证。
运行 (Operation)消息篡改与中间人攻击(Message Tampering & MITM)攻击者可能拦截或篡改 sendTask 或 getTask RPC 调用，导致载荷注入或消息损坏。使用 TLS 进行传输安全，并使用 JWS 签名每条消息载荷。
认证缺陷与未经授权的访问(Auth Flaws & Unauthorized Access)弱化的 Bearer 令牌强制执行可能允许未经授权的执行或任务中断。应用具有能力作用域的短期令牌；强制执行相互 TLS (mutual TLS)，并进行身份撤销。
持久化 (Persistence)会话劫持与隐私泄露(Session Hijacking & Privacy Leaks)在长寿命会话中，可能发生重放攻击或令牌窃取，缺乏适当的绑定或加密。轮换会话 ID，加密持久化的上下文 (persisted context)，并最小化令牌生命周期。
更新 (Update)版本回滚与配置漂移(Version Rollback & Config Drift)陈旧的清单或软件可能在更新后重新引入已打补丁的漏洞。强制执行不可变、版本化的清单，并使用 GitOps 检测漂移。
终止 (Termination)废弃资源与审计漏洞(Orphaned Resources & Audit Gaps)未能撤销令牌或关闭 SSE 流，使清理和取证复杂化。排除 (Drain) 活动任务，撤销凭据，并集中审计日志记录，实施保留策略。

ANP

阶段 (Phase)安全挑战 (Security Challenge)威胁描述 (Threat Description)缓解策略 (Mitigation Strategy)
创建 (Creation)身份欺骗(Identity Spoofing)DID 文档可能被欺骗或托管不安全，导致代理身份识别错误。强制执行 HTTPS 托管的 DID，使用 DNS 记录进行验证，并要求 DID 签名验证。
运行 (Operation)未验证的代理(Unverified Agents)恶意行为者可能绕过 DID 检查或使用欺骗的人类凭据。通过 DID 公钥进行认证，并验证敏感操作的 humanAuthorization。
接口篡改(Interface Tampering)代理可能更改结构化接口或注入到自然语言端点中。要求接口的加密签名，并记录带有源元数据的访问事件。
更新 (Update)过时的描述(Stale Descriptions)过时或被操纵的代理元数据可能欺骗客户端。自动化爬取代理描述，并针对已知良好哈希值进行验证。
终止 (Termination)废弃标识符(Orphaned Identifiers)过期的 DID 或代理声明 (ADPs) 可能残留于注册表或缓存中。使用过期时间戳，并要求在取消注册时发出撤销信号。

四种协议对比#

方面 (Aspect)MCP (模型上下文协议)ACP (代理通信协议)A2A (代理到代理协议)ANP (代理网络协议)
架构模型(Architecture Model)客户端-服务器，带 JSON-RPC 原语客户端-服务器 (注册表 + 任务路由)类对等体客户端 ↔\leftrightarrow 远程代理去中心化对等体
代理发现(Agent Discovery)手动注册或静态 URL 查找基于注册表HTTP 上的代理卡片检索搜索引擎发现
身份与认证(Identity & Auth)基于令牌的身份验证；可选支持 DIDBearer 令牌、相互 TLS、JWSDID-基于握手或带外标头去中心化标识符 (DID)，特别是 DID:wba
消息格式(Message Format)JSON-RPC 2.0，带原语、工具、资源结构化多部分消息，带 MIME 类型基于 JSON 的任务 + 产物消息JSON-LD，带 Schema.org 和 ADP/Meta-协议协商
核心组件(Core Components)工具、提示、资源、采样代理详情、消息、任务请求、产物代理卡片、任务、消息、产物DID 文档、代理描述、元-协议、结构化接口
传输层(Transport Layer)HTTP、Stdio、Server-Sent Events (SSE)带增量流的 HTTP带可选 SSE + 推送通知的 HTTP基于 TLS 的 HTTP，带 JSON-LD
会话支持(Session Support)无状态 + 可选的持久化上下文会话感知，带运行时状态追踪会话感知或无状态；客户端管理 ID无状态；跨连接使用 DID 认证令牌
目标范围(Target Scope)LLM ↔\leftrightarrow 外部工具/服务集成模型无关、基础设施级别的代理组织信任边界内的多代理工作流开放互联网代理互联互通
主要用例(Primary Use Case)增强 LLM 的外部能力（例如，代码、搜索）用于异构代理的安全、类型化消息交换信任代理任务委托跨平台发现、安全的 P2P 执行
优点(Strengths)紧密的 LLM 集成；资源注入多模态消息传递；托管式注册表；工具模块化；离线代理发现代理间协商；产物-代理委托基于 DID 的无信任身份；AI-原生协议协商
局限性(Limitations)集中式服务器假设；提示注入风险需要注册表；对服务器控制有强假设以企业为中心；假设存在代理目录高协商开销；演进中的采纳生态系统

Building A Secure Agentic AI Application Leveraging Google’s A2A Protocol#

image-20251215183057483

Motivation#

随着人工智能系统从孤立的任务特定模型演变为复杂的代理式 AI(Agentic AI)生态系统，智能体（Agents）不再仅仅是响应提示词，而是具备了跨组织边界自主决策、调用工具和相互协作的能力。

  • 互操作性需求： 代理需要在不同的组织、地理和信任边界之间协同工作，这迫切需要一种安全、标准化的互操作性协议
  • 安全真空： 如果缺乏共享的身份、认证和审计协议，代理交互将面临严重的碎片化和安全漏洞风险
  • 协议标准到安全实现间的空白：人工智能系统的安全不仅仅依赖于协议规范，更依赖于稳健的实现。

Contribution#

  1. 威胁建模分析：使用专为 AI 风险设计的 MAESTRO 威胁建模框架，系统性地分析了 A2A 生态系统的安全性，并提出了具体的防御措施
  2. 实战指南： 提供了构建强化版 A2A 服务器和客户端的实现最佳实践，并提供了代码示例库
  3. 协议协同分析： 探讨了 A2A 与模型上下文协议 (MCP) 之间的协同作用

MAESTRO Threat Modeling Methodology#

MAESTRO（Multi-Agent Environment, Security, Threat, Risk, and Outcome）专为代理人工智能设计的七层威胁建模方法，用于识别、评估和减轻整个代理人工智能生命周期中的威胁。

image-20251215193720652

  • Agent Card 欺骗
  • A2A 任务重放
  • A2A Message 注入
  • A2A Server冒名顶替
  • 跨代理任务升级
  • 拦截、篡改Artifacts
  • 通过A2A依赖进行供应链攻击
  • 操纵A2A任务进行内部工具/日志规避
  • 身份验证威胁
  • Agent Card投毒
安全领域 (Security Domain)关键实施点 (Key Implementation Points)具体措施与细节 (Specific Measures & Details)
AgentCard 安全
(Securing the AgentCard)		位置与访问控制• 将 agent.json 托管在 /.well-known/ 路径下并实施适当的访问控制
• 实施速率限制以防止枚举攻击
• 使用内容安全标头（Content Security Headers）防止未经授权的嵌入
内容安全• 仅包含必要的 Agent 能力信息，避免过度暴露
• 使用 OpenAPI 3.x Security Scheme 对象明确指定认证要求
• 定期验证内容，确保不包含敏感信息
认证与授权
(Authentication & Authorization)		服务器身份与请求验证• 使用受信任 CA 颁发的证书验证服务器身份
• 强制认证所有传入 HTTP 请求，无凭证请求返回 401/403
• 在 Agent Card 中明确声明支持的认证协议（OAuth、OIDC、API Keys）
敏感操作保护• 技能（Skills）：基于 Scope 进行细粒度授权（如只读）
• 工具（Tools）：限制 Agent 对敏感数据和高风险操作的访问
凭证管理• API Keys：使用强随机密钥，实施轮换策略，安全存储且不暴露于客户端
• JWT：验证签名、设置过期时间，仅包含必要 Claims
安全通信
(Secure Communication)		传输层安全（TLS）• 强制使用 HTTPS 和 TLS 1.3
• 定期更新证书并禁用不安全加密套件
数据保护• 传输中：消息全量加密，验证证书链，关键连接使用证书锁定（Pinning）
• 静态数据：对服务器存储的敏感数据进行加密
输入验证
(Input Validation)		消息与 URI 处理• 按 A2A 协议 Schema 验证消息并进行清洗，防止注入攻击
• 严格校验 URI，使用 Allow-list 防止 SSRF
文件处理（FilePart）• 扫描上传文件的恶意软件
• 校验文件类型并强制大小限制
• 安全存储文件并设置访问控制
服务器最佳实践
(Server Best Practices)		日志与错误处理• 错误信息不暴露敏感细节
• 记录认证、授权及安全事件日志并防篡改
抗攻击与防护• 实施速率限制与网络分段
• 部署 Web 应用防火墙（WAF）
• 对失败认证尝试使用指数退避
协议特定安全
(Protocol-Specific Security)		流式传输（SSE）• 对 SSE 连接实施认证与安全状态管理
• 监控资源耗尽攻击
推送通知（Webhooks）• 严格校验 Webhook URL（防 SSRF）与 Payload 签名
• 强制 HTTPS 并使用带退避的重试策略
连接管理• 配额与限制：限制每客户端/IP 的连接数
• 超时管理：设置空闲超时，使用 Keep-alive 清理僵尸连接
• 背压：对滞后客户端丢弃非关键消息或退避
服务器加固
(Server Hardening)		环境与流程• 制定并演练事件响应流程
• 定期进行安全评估与渗透测试
• 遵循语言级安全编码规范并进行代码审查

Synergy of MCP & A2A#

特性Google A2AAnthropic MCP
侧重点水平集成 (代理通信)垂直集成 (代理能力增强)
主要交互客户端代理 -> 远程代理MCP 客户端 (代理) -> MCP 服务器 (工具/数据)
核心机制Agent Card, 任务对象, 消息工具, 资源, 提示词
角色负责代理间的协作、任务委派和消息传递负责标准化模型与外部数据/工具的连接

image-20251217114242644

From Glue-Code to Protocols: A Critical Analysisof A2A and MCP Integration for Scalable AgentSystems#

image-20251217121931122

A2A & MCP协同的优缺点#

  1. 互操作性与标准化
  • 跨供应商/框架协作
  • 减少“胶水代码”

语义对齐gap： A2A 的 skill description 是自然语言，MCP 的 tool schema 是结构化 JSON，二者之间没有自动、可靠的映射机制

复合安全风险： 信任不再是单点，而是链式的，调试与可观测性没有统一trace，很难定位

  1. 系统能力增强
  • 专业化与模块化
  • 稳健性与故障隔离：将代理间的通信（A2A）与工具执行（MCP）解耦

编排复杂性 ：依赖Agent解决跨协议的任务移交、监控和结果整合问题

  1. 可扩展性与性能
  • 并行处理

管理开销： 要实现显著的加速，需要任务能够真正地并行化，并且需要复杂的协调机制来管理任务依赖关系和合并结果，这本身会带来额外的开销

A2A & MCP协同架构#

  1. A2A代理内部利用 MCP

一个 A2A 服务器代理在其内部使用 MCP 来访问工具和数据

  • 能保持协议间的清晰分离
  • 如果多个 A2A 代理都需要调用相同的 MCP 工具，可能会导致重复的开发工作
  • A2A 客户端无法直接看到远程代理内部使用了哪些 MCP 工具
  1. 通过 A2A Agent Card暴露 MCP 工具
  • MCP 工具可以通过 A2A 机制更容易地被发现
  • 语义不匹配
  1. A2A 用于复杂工具编排
  • 利用了 A2A 在处理长流程任务方面的优势
  • 绕过了 MCP 在标准化工具交互上的专长，可能导致整个系统中的工具处理缺乏一致性。

解决方案： Orchestration Layer

  • 将高层目标转换为 A2A 任务
  • 将任务匹配给具有相应 MCP 工具能力的代理
  • 管理跨协议的语义对齐
  • 处理跨协议的错误
  • 整合最终结果
Agent 通信协议综述
https://www.orac1e.me/blog/agent/1211
Author Orac1e
Published at December 8, 2025
Copyright CC BY-NC-SA 4.0
Buy me a cup of coffee ☕.

Agent的安全问题
Comment seems to stuck. Try to refresh?✨