Tech老韩 · 谈点技术
探索异构 AI 系统实现语义级互操作的技术路径
随着 AI 智能体(Agent)从单一原型向大规模企业级应用演进,异构系统间的通信孤岛成为了制约协作效率的核心瓶颈。传统的 REST API 往往难以承载智能体之间复杂的上下文交换、长时运行的任务生命周期以及动态的能力发现。A2A (Agent-to-Agent) 协议应运而生,它并非又一个简单的消息格式,而是一套严谨的分层架构标准,目的在于解耦底层传输机制与上层业务语义。
今天老韩跟您一起深入剖析 A2A 的技术底座,从 Protocol Buffers 定义的规范数据模型,到基于 Agent Card 的发现机制,再到跨协议绑定的工程权衡,客观评估这一标准如何重塑“智能体互联网”的互操作性底座。
让我们从工程视角出发,拆解这一协议如何定义智能体协作的未来。
◆ ◆ ◆
CHAPTER 01
协议原点:打破多智能体系统的“巴别塔”
在多智能体系统(MAS)的演进过程中,开发者面临的首要挑战是协议碎片化。由不同厂商、不同框架(如 LangGraph、AutoGen)构建的智能体往往处于相互孤立的状态,缺乏统一的交互接口。A2A (Agent-to-Agent) 协议于 2025 年 4 月由 Google 推出,并随后移交给 Linux 基金会 进行开放治理,旨在为这些“不透明”的系统提供一种通用语言。
A2A 的核心设计哲学是不透明执行(Opaque Execution)。这意味着智能体之间在协作时,不需要暴露其内部的提示词(Prompts)、记忆存储或具体的工具实现,而是基于声明的能力进行交互。这种抽象保护了厂商的知识产权,同时降低了系统间的耦合度。研究表明,缺乏标准化的集成工作可能占据企业 Agent 开发预算的 40%,这使得 A2A 这种开放标准的引入具有显著的工程经济价值。
ℹ️ A2A 协议:一种开放标准,旨在促进独立、异构且可能不透明的 AI 智能体系统之间的通信与互操作性。它定义了发现、协商、任务委派和安全信息交换的通用机制。
· 互操作性:桥接不同框架间的通信鸿沟。
· 发现机制:允许智能体动态理解对方的技能边界。
· 异步性:原生支持可能耗时数小时甚至数天的长时任务管理。

· ·
CHAPTER 02
三层架构拆解:从数据模型到物理绑定
A2A 协议在架构设计上采用了清晰的三层分离模式,这种解耦确保了协议在演进过程中能够保持核心语义的稳定性,同时兼容多样化的传输环境。这种分层思想类似于网络协议栈中的 OSI 模型,将“做什么”与“怎么传”彻底分开。
1. Layer 1:规范数据模型 (Canonical Data Model):这是协议的“灵魂”,使用 Protocol Buffers (proto3) 定义。它规定了 Task(任务)、Message(消息)、AgentCard(智能体卡)等核心对象的结构。它是跨语言、跨框架互操作的基础。
2. Layer 2:抽象操作 (Abstract Operations):定义了智能体必须支持的基本行为,如 SendMessage、GetTask、CancelTask 等。这些操作独立于具体的底层传输协议。
3. Layer 3:协议绑定 (Protocol Bindings):负责将抽象操作映射到具体的物理协议上。目前官方支持 JSON-RPC 2.0、gRPC 以及 HTTP/REST。
💡 通过将核心语义限制在 Layer 1,A2A 允许开发者在不改变业务逻辑的情况下,灵活地从基于 HTTP 的简易实现迁移到基于 gRPC 的高性能生产环境。
这种架构使得 A2A 不仅适用于云端复杂的编排,也能适配边缘计算中资源受限的智能体通信。

· ·
CHAPTER 03
Layer 1 深度建模:Task 与 Message 的有状态协作
在 A2A 协议中,Task(任务) 是一个有状态的工作单元,而 Message(消息) 是通信的基本单位。与传统的即时通讯协议不同,A2A 强调任务的生命周期管理,而不仅仅是文本的传递。这种设计是为了应对 LLM 智能体在处理复杂逻辑时可能产生的长耗时操作。
· Task 结构:包含 id(服务端生成的唯一标识)、context_id(逻辑会话标识)、status(当前状态)以及 artifacts(产出物列表)。
· Message 结构:包含 role(USER 或 AGENT)、parts(模态无关的内容容器)以及 reference_task_ids(引用的任务 ID)。
特别值得关注的是 context_id 的设计,它允许跨多个 Task 维护逻辑关联。当客户端提供的 context_id 与 task_id 不匹配时,服务端必须拒绝该消息,以确保上下文的严格隔离与一致性。此外,Artifact 对象的设计实现了“通信”与“产出物”的职责分离:Message 用于对话,而 Artifact 用于返回正式的任务结果。
💡 这种建模方式解决了智能体协作中的“状态同步”难题。通过 Task 历史记录,一个新加入协作的智能体可以快速回溯之前的交互上下文,而无需重新执行整个流程。

· ·
CHAPTER 04
能力发现:Agent Card 的结构化声明
为了实现动态协作,智能体必须能够“自我介绍”。A2A 引入了 Agent Card(智能体卡) 机制,这是一种机器可读的 JSON 文档,通常发布在众所周知的 URL 上(如 /.well-known/agent.json)。Agent Card 的作用类似于 Web 服务的 OpenAPI 定义,但它更侧重于智能体的技能(Skills)和交互模态。
一个标准的 Agent Card 包含以下核心要素:
· 基本元数据:智能体的名称、描述及联系信息。
· 支持的技能:声明其擅长处理的任务类型(如“代码审查”、“财务分析”)。
· 输入/输出模态:支持 text、files、structured data 等哪些形式。
· 安全认证方案:要求 OAuth 2.0、API Keys 还是 mTLS。
在 v1.0 版本中,Agent Card 增加了加密签名功能,确保卡片内容是由域名所有者真实发布的。这为构建受信任的智能体联邦奠定了基础。通过解析 Agent Card,客户端智能体可以在运行时动态决定是否将任务委派给该远程节点,而无需硬编码集成逻辑。
❓ 如果两个智能体都声明了相同的技能,A2A 协议如何处理冲突?目前协议主要负责“声明”与“发现”,具体的调度与仲裁逻辑通常交由上层的编排器(Orchestrator)实现。

· ·
CHAPTER 05
状态机治理:管理长时运行任务的生命周期
A2A 协议不仅关注消息的传递,更是一套严谨的分布式状态机。在 TaskState 枚举中,任务被划分为三类核心状态,这对于处理具有不确定性的 AI 任务至关重要:
· 进行中 (In-progress):SUBMITTED(已提交)和 WORKING(正在处理)。
· 中断态 (Suspended):INPUT_REQUIRED(需要输入)和 AUTH_REQUIRED(需要认证)。
· 终态 (Terminal):COMPLETED(成功)、FAILED(失败)、CANCELED(已取消)及 REJECTED(拒绝)。
特别值得注意的状态是 REJECTED 和 AUTH_REQUIRED。智能体被赋予了自主拒绝权,如果它判定自己无法处理某个请求,可以主动转入终态。而 AUTH_REQUIRED 则是 v1.0 新增的状态,用于支持任务内的二次认证:当智能体在执行过程中发现缺少访问外部系统的凭证时,可以将任务挂起并委托客户端获取凭证。
💡 这种精细化的状态管理使得 A2A 能够原生支持“人机协同(Human-in-the-loop)”场景。当智能体遇到模糊指令时,通过转入 INPUT_REQUIRED 状态,可以优雅地请求人类介入,而不会导致连接超时或会话丢失。

· ·
CHAPTER 06
Layer 3 权衡:JSON-RPC 与 gRPC 的工程实践
在 Layer 3 的协议绑定中,A2A 展示了极高的灵活性。对于大多数 Web 开发者,JSON-RPC 2.0 over HTTP 是首选,因为它简单且易于调试。然而,在高性能要求的企业级场景中,gRPC 绑定的引入显著提升了吞吐量并降低了延迟。
· 实时反馈:A2A 利用 Server-Sent Events (SSE) 实现流式消息传递,允许智能体在处理过程中实时向客户端推送状态更新或部分结果。
· 异步通知:对于运行数天的超长任务,A2A 支持基于 Webhook 的推送通知配置(Push Notification Config),避免了长轮询带来的资源浪费。
根据 ProtocolBench 的测试数据,在流式队列场景下,不同协议实现导致的端到端延迟差异可达 3.48 秒。这意味着在构建实时性敏感的 MAS 系统时,选择正确的协议绑定(如 gRPC)至关重要。
⚠️ 开发者需要注意:虽然 A2A 提供了多种绑定,但并非所有智能体都必须支持全部绑定。Agent Card 应明确声明其支持的 Endpoint 类型,以避免连接尝试失败。

· ·
CHAPTER 07
生态协同:A2A 与 MCP 的功能边界
在讨论 A2A 时,经常会将其与 Anthropic 推出的 Model Context Protocol (MCP) 进行比较。事实上,两者并非竞争关系,而是高度互补的。这种关系可以类比为计算机系统中的“内部总线”与“外部网络”。
· MCP (Agent-to-Tool):解决的是智能体如何连接其工具(Tools)、API 和数据源的问题。它定义了智能体获取外部能力的垂直通道。
· A2A (Agent-to-Agent):解决的是智能体之间如何发现、委派和协作的问题。它定义了跨组织、跨框架协作的水平通道。
在一个典型的企业架构中,一个专门从事财务分析的智能体可能会通过 MCP 访问内部 SQL 数据库,然后通过 A2A 协议将其初步分析结果委派给另一个负责撰写报告的智能体。这种分层确保了每个协议都能专注于其特定的交互复杂性,共同构建出强大的复合型 AI 系统。
💡 目前的行业趋势是向少数核心标准收敛。A2A 处理水平委派,MCP 处理垂直工具访问,而 ANP 则在开放网络层面提供去中心化身份支持。这三者构成了成熟的智能体协议栈。

· ·
CHAPTER 08
语义对齐挑战:协议背后的“翻译损失”
尽管 A2A 在语法层面(消息格式、传输机制)表现出色,但在实现行为兼容性(Behavioral Compatibility)方面仍面临巨大挑战。不同模型(如 GPT-4 与 Claude 3.5)对同一指令的理解可能存在微小偏差,这种偏差在多级智能体委派链中会被逐级放大。
研究指出,当前的 A2A 协议仍存在以下未解决的难题:
· 语义失败 (Semantic Failures):跨协议转换(如 A2A 到 ANP)时,可能丢失微妙的任务状态或权限约束。
· 提示词注入防御:如何防止恶意指令通过 A2A 消息流注入到下游智能体中。
· 身份联邦:在跨组织协作时,如何验证一个智能体是否真的具备它所声称的权限。
截至 2026 年中,虽然 A2A 已进入生产级部署,但行业研究建议开发者必须在协议之上构建显式桥接合约 (Bridge Contracts)。这些合约不只是传输数据,更要验证语义的完整性,防止静默的“翻译损失”。
⚠️ 单纯实现 A2A 接口并不等同于实现了真正的智能。开发者仍需关注 LLM 的推理一致性,否则协议层即便返回“成功”,业务结果也可能已经偏离预期。

◆ ◆ ◆
从消息传递到语义对齐的架构跨越
通过对 A2A 协议的深度拆解,您已经理解了它如何通过三层架构解决异构智能体协作中的关键痛点:能力发现、长时任务管理和传输协议解耦。我们不仅探讨了技术实现的细节,如 Agent Card 的结构化声明和 Protobuf 驱动的数据模型,还客观分析了当前生态中协议碎片化的现实挑战。这种从底层规范到顶层生态的系统性视角,将帮助您在未来的多智能体系统设计中,做出更具前瞻性的技术决策。A2A 不仅仅是一个通信规范,它是迈向“智能体互联网”的重要一步,标志着 AI 系统正从封闭的黑盒转向开放的协作节点。
Key Insights
· 协议解耦是实现异构智能体互操作性的前提,Layer 1 的规范数据模型是跨语言协作的基石
· 智能体协作的本质是任务委派,而非简单的对话,因此必须具备完善的 Task 生命周期治理
· 互操作性不仅是语法层面的对齐,更面临语义解析一致性与安全委派边界的深层挑战
TECH老韩
谈点技术
夜雨聆风