Google A2A 协议完整技术深度解析

admin · 2026 年3 月 26 日 08:13

Google A2A 协议完整技术深度解析

Google Agent2Agent（A2A）协议是目前最具影响力的 Agent 间通信开放标准，已于 2026 年 3 月 12 日正式发布 v1.0，标志着协议从实验阶段迈入生产就绪。协议由 Google 于 2025 年 4 月首次发布，同年 6 月捐赠给 Linux Foundation，目前拥有 150+ 组织支持，技术指导委员会（TSC）成员涵盖 Google、Microsoft、AWS、Cisco、Salesforce、ServiceNow、SAP、IBM 八大厂商。A2A 解决的核心问题是：不同框架、不同厂商构建的 AI Agent 如何以标准化方式发现彼此、委派任务、交换上下文并协作完成复杂工作流。它与 Anthropic 的 MCP 协议形成互补——MCP 管 Agent 连接工具（纵向），A2A 管 Agent 之间对话（横向）。

三层协议栈与核心设计原则

A2A 建立在六项核心设计原则之上：互操作性（跨框架跨厂商）、协作能力（任务委派与上下文共享）、动态发现（Agent Card 机制）、灵活传输（同步/流式/推送）、企业级安全、异步优先（支持长任务与人机协作）。协议贯彻"不透明执行"理念——Agent 协作时无需暴露内部思维链、执行计划或工具实现，仅通过标准消息交换。

协议栈分为清晰的三层架构：

第一层：规范数据模型（Canonical Data Model）。以 Protocol Buffers（proto3）为规范的唯一权威来源（spec/a2a.proto），定义所有数据结构——Task、Message、Part、Artifact、AgentCard 等。v1.0 将 proto 文件提升为 normative source of truth，所有绑定必须等价映射。

第二层：抽象操作（Abstract Operations）。定义 11 个核心操作，与传输无关：SendMessage（主交互方法）、SendStreamingMessage（流式变体）、GetTask（轮询状态）、ListTasks（列表/过滤任务，v1.0 新增）、CancelTask（取消任务）、SubscribeToTask（订阅更新流）、以及 Push Notification 的四个 CRUD 方法和 GetExtendedAgentCard（获取认证后扩展 Agent Card）。

第三层：协议绑定（Protocol Bindings）。提供三种等价绑定：

绑定	传输方式	流式支持	典型场景
JSON-RPC 2.0	HTTP POST，`Content-Type: application/json`	SSE（`text/event-stream`）	最简单、最广泛
gRPC	HTTP/2 + Protocol Buffers	Server Streaming RPC	高性能、强类型
HTTP+JSON/REST	标准 RESTful 端点	SSE	与现有 REST 基础设施集成

HTTP 层额外定义了 A2A-Version 头（如 "1.0"）和 A2A-Extensions 头（逗号分隔的扩展 URI），以及自定义 media type application/a2a+json。所有生产环境 必须使用 HTTPS（推荐 TLS 1.3+）。

Agent Card 的完整结构与发现机制

Agent Card 是 A2A 的"名片"——一份机器可读的 JSON 元数据文档，描述 Agent 的身份、能力、技能、认证要求和通信端点。发现机制支持三种模式：

Well-Known URI：https://{domain}/.well-known/agent-card.json（遵循 RFC 8615），任何客户端可直接 GET 获取
策展注册中心：中心化目录，Agent 发布自身信息，客户端按技能/标签查询
静态配置：已知关系间直接硬编码
Extended Agent Card：通过 GET /extendedAgentCard 认证端点获取更丰富的详情

以下是 v1.0 AgentCard 的完整 proto 定义及各字段：

message AgentCard {
  string name = 1;                              // 必填。人类可读名称
  string description = 2;                       // 必填。用途描述
  repeated AgentInterface supported_interfaces = 3; // 必填。支持的协议接口列表（按优先级排序）
  AgentProvider provider = 4;                    // 可选。提供者信息
  string version = 5;                           // 必填。Agent 版本号
  optional string documentation_url = 6;         // 可选。文档 URL
  AgentCapabilities capabilities = 7;            // 必填。能力声明
  map<string, SecurityScheme> security_schemes = 8;  // 安全方案定义
  repeated SecurityRequirement security_requirements = 9;  // 所需安全方案
  repeated string default_input_modes = 10;      // 必填。支持的输入 MIME 类型
  repeated string default_output_modes = 11;     // 必填。支持的输出 MIME 类型
  repeated AgentSkill skills = 12;               // 必填。技能列表
  repeated AgentCardSignature signatures = 13;   // JWS 签名（验证完整性）
  optional string icon_url = 14;                 // 可选。图标 URL
}

AgentInterface——多接口支持是 v1.0 的关键变更（替代旧版单一 url 字段），允许同一 Agent 暴露多种协议绑定：

message AgentInterface {
  string url = 1;               // 必填。绝对 HTTPS URL
  string protocol_binding = 2;  // 必填。"JSONRPC"、"GRPC" 或 "HTTP+JSON"
  string tenant = 3;            // 可选。租户 ID（多租户场景）
  string protocol_version = 4;  // 必填。A2A 版本（如 "1.0"）
}

AgentSkill——每个技能包含 ID、名称、描述、标签、示例 prompt，并可覆盖 Agent 级默认的输入/输出模态，甚至指定独立的安全要求：

message AgentSkill {
  string id = 1;                              // 必填。唯一标识符
  string name = 2;                            // 必填。人类可读名称
  string description = 3;                     // 必填。详细描述
  repeated string tags = 4;                   // 必填。关键词标签
  repeated string examples = 5;               // 示例 prompt
  repeated string input_modes = 6;            // 覆盖默认输入 MIME
  repeated string output_modes = 7;           // 覆盖默认输出 MIME
  repeated SecurityRequirement security_requirements = 8;  // 技能级安全
}

AgentCapabilities——声明 Agent 支持的高级功能：

message AgentCapabilities {
  optional bool streaming = 1;            // 支持流式响应
  optional bool push_notifications = 2;   // 支持推送通知
  repeated AgentExtension extensions = 3; // 支持的扩展
  optional bool extended_agent_card = 4;  // 支持认证后的扩展 Card
}

服务端应当在 Agent Card 响应中包含 Cache-Control（含 max-age）和 ETag 头，客户端应当使用条件请求（If-None-Match）实现高效缓存。Agent Card 签名使用 JWS（RFC 7515），支持通过 JWKS 端点分发公钥，确保 Card 在传输过程中未被篡改。

任务状态机与消息模型

九态状态机

Task 是 A2A 的核心工作单元，拥有完整的 9 个状态（v1.0 枚举值采用 SCREAMING_SNAKE_CASE）：

TASK_STATE_SUBMITTED ──→ TASK_STATE_WORKING ──→ TASK_STATE_COMPLETED (终态)
         │                      │                        
         │                      ├──→ TASK_STATE_FAILED (终态)
         │                      │
         │                      ├──→ TASK_STATE_CANCELED (终态)
         │                      │
         │                      ├──→ TASK_STATE_INPUT_REQUIRED (中断态)
         │                      │
         │                      └──→ TASK_STATE_AUTH_REQUIRED (中断态)
         │
         └──→ TASK_STATE_REJECTED (终态，Agent 拒绝接受任务)

终态（COMPLETED、FAILED、CANCELED、REJECTED）不可逆，任务结束后新工作必须创建新 Task（可复用同一 contextId）。中断态（INPUT_REQUIRED、AUTH_REQUIRED）表示任务暂停等待客户端操作——前者用于多轮对话中 Agent 需要澄清信息，后者用于任务中途需要认证升级。

Task 数据结构

message Task {
  string id = 1;                       // 必填，服务端生成的 UUID
  string context_id = 2;              // 关联上下文（分组相关任务/消息）
  TaskStatus status = 3;              // 必填，当前状态
  repeated Artifact artifacts = 4;    // 输出产物
  repeated Message history = 5;       // 消息历史
  google.protobuf.Struct metadata = 6; // 自定义元数据
}

Message 与 Part 类型

Message 是 Agent 间交换的基本信息载体：

message Message {
  string message_id = 1;              // 必填，发送方生成的 UUID
  string context_id = 2;             // 可选上下文关联
  string task_id = 3;                // 可选任务关联
  Role role = 4;                     // 必填：ROLE_USER 或 ROLE_AGENT
  repeated Part parts = 5;           // 必填，内容部分
  google.protobuf.Struct metadata = 6;
  repeated string extensions = 7;     // 扩展 URI
  repeated string reference_task_ids = 8;  // 引用的任务 ID
}

v1.0 的 Part 统一为单一消息类型（移除了旧版的 TextPart/FilePart/DataPart 独立类型），通过 oneof content 实现多态：

message Part {
  oneof content {
    string text = 1;                  // 纯文本
    bytes raw = 2;                    // 二进制数据（JSON 中 base64 编码）
    string url = 3;                   // 文件 URL 引用
    google.protobuf.Value data = 4;   // 结构化 JSON 数据
  }
  google.protobuf.Struct metadata = 5;
  string filename = 6;               // 可选文件名
  string media_type = 7;             // MIME 类型
}

同步 vs 异步 vs 流式

A2A 通过 SendMessageConfiguration 中的参数控制交互模式：

同步阻塞（return_immediately: false，默认）：请求阻塞直到任务达到终态或中断态
异步非阻塞（return_immediately: true）：立即返回任务引用，客户端后续轮询 GetTask 或订阅 SubscribeToTask
流式（SendStreamingMessage）：服务端以 SSE 流持续推送事件

流式响应的 SSE 格式：服务端返回 HTTP 200 + Content-Type: text/event-stream，每个 data: 字段包含完整的 JSON-RPC 2.0 Response 对象，内部封装 StreamResponse：

message StreamResponse {
  oneof payload {
    Task task = 1;                          // 初始任务状态
    Message message = 2;                    // 简单消息响应
    TaskStatusUpdateEvent status_update = 3;  // 状态变更事件
    TaskArtifactUpdateEvent artifact_update = 4; // 产物更新事件
  }
}

流的典型生命周期：首个事件为 Task（初始状态）→ 若干 TaskStatusUpdateEvent（working 中间更新）→ TaskArtifactUpdateEvent（append/lastChunk 机制实现增量输出）→ 终态事件后流关闭。断连后可通过 SubscribeToTask 重新订阅，首个事件为当前 Task 完整状态。

推送通知机制

对于无法保持长连接的场景，A2A 提供 Webhook 推送：

message TaskPushNotificationConfig {
  string id = 2;          // 配置 UUID
  string task_id = 3;     // 关联任务
  string url = 4;         // 必填。Webhook URL
  string token = 5;       // 验证令牌
  AuthenticationInfo authentication = 6;  // 服务端向 Webhook 认证的凭据
}

服务端在任务状态变更时向 Webhook URL 发送 HTTP POST，payload 为 StreamResponse 格式。安全措施包括：JWT 签名（含 iss、aud、iat、exp、jti、taskId claims）、JWKS 密钥轮换、SSRF 防护（域名白名单）、nonce 防重放。

企业级安全机制

A2A 的安全设计覆盖 5 种认证方案，通过 Agent Card 的 securitySchemes 声明：

message SecurityScheme {
  oneof scheme {
    APIKeySecurityScheme api_key_security_scheme = 1;     // API Key（header/query/cookie）
    HTTPAuthSecurityScheme http_auth_security_scheme = 2;  // HTTP Bearer/JWT
    OAuth2SecurityScheme oauth2_security_scheme = 3;       // OAuth 2.0
    OpenIdConnectSecurityScheme open_id_connect_security_scheme = 4;  // OIDC
    MutualTlsSecurityScheme mtls_security_scheme = 5;      // 双向 TLS
  }
}

OAuth 2.0 支持四种流（v1.0 废弃了 implicit 和 password 流）：Authorization Code（支持 PKCE）、Client Credentials、Device Code、以及 RFC 8414 元数据 URL 自动发现。SecurityRequirement 使用 map<string, StringList> 结构，键为方案名，值为所需 scopes。

认证流程：① 客户端从 Agent Card 读取 securitySchemes + securityRequirements → ② 带外获取凭据（OAuth 授权、API Key 申请等，不属于 A2A 协议范畴）→ ③ 通过 HTTP 头传递凭据（如 Authorization: Bearer <token>）→ ④ 服务端按声明的方案校验每个请求。特别地，AUTH_REQUIRED 状态支持任务中途的认证升级——Agent 可在处理过程中发现需要更高权限，暂停任务请求客户端提供新凭据。

服务端身份验证通过 TLS 证书验证和 Agent Card JWS 签名实现。签名使用 JSON Canonicalization Scheme 确保跨实现的一致性。

A2A 与 MCP 的互补架构

A2A 和 MCP 是 互补而非竞争 的两个协议，官方表述为：“Build with ADK (or any framework), equip with MCP (or any tool), and communicate with A2A.”

维度	MCP（Agent→Tool）	A2A（Agent→Agent）
定位	纵向集成——Agent 连接工具、API、数据源	横向集成——Agent 间发现、委派、协作
类比	USB-C 接口	网络电缆
消息模型	函数调用、结构化输入输出	多轮对话、任务状态机、流式事件
状态管理	通常无状态	完整任务生命周期管理
复杂度	低（几分钟上手）	较高（企业级特性丰富）

典型组合架构（官方"汽车修理店"类比）：客户 Agent 通过 A2A 向"店长 Agent"发送维修请求 → 店长 Agent 通过 A2A 委派给"技师 Agent" → 技师 Agent 通过 MCP 调用诊断工具（get_repair_procedure(error_code='P0300')）和物理控制工具（raise_platform(height_meters=2)）→ 技师 Agent 通过 A2A 向"零件供应商 Agent"订购配件。一个 Agent 完全可以同时使用两种协议——内部通过 MCP 连接工具生态，外部通过 A2A 与其他 Agent 通信。

Python SDK 代码实战

A2A 官方 Python SDK 包名 a2a-sdk，当前 PyPI 版本 0.3.25（适配 A2A v0.3 规范，v1.0 SDK 在 1.0-dev 分支开发中），仓库位于 github.com/a2aproject/a2a-python。

安装

pip install a2a-sdk                    # 核心 SDK
pip install "a2a-sdk[http-server]"     # HTTP 服务端（FastAPI/Starlette）
pip install "a2a-sdk[grpc]"            # gRPC 支持
pip install "a2a-sdk[postgresql]"      # PostgreSQL 任务存储
pip install "a2a-sdk[all]"             # 全部可选依赖

服务端实现：AgentExecutor + Starlette

# agent_executor.py
from a2a.server.agent_execution import AgentExecutor, RequestContext
from a2a.server.events import EventQueue
from a2a.utils import new_agent_text_message

class HelloWorldAgentExecutor(AgentExecutor):
    """最小化 A2A Agent 实现"""
    
    async def execute(self, context: RequestContext, event_queue: EventQueue) -> None:
        # context 提供: message, current_task, task_id, context_id
        user_input = context.get_user_input()
        event_queue.enqueue_event(new_agent_text_message(f"Hello! You said: {user_input}"))

    async def cancel(self, context: RequestContext, event_queue: EventQueue) -> None:
        raise Exception("cancel not supported")

# __main__.py — 服务端启动
from a2a.server.apps import A2AStarletteApplication
from a2a.server.request_handlers import DefaultRequestHandler
from a2a.server.tasks import InMemoryTaskStore
from a2a.types import AgentCard, AgentSkill, AgentCapabilities, AgentAuthentication
import uvicorn

skill = AgentSkill(
    id='hello_world',
    name='Hello World',
    description='Returns a greeting',
    tags=['greeting', 'demo'],
    examples=['hi', 'hello'],
)

agent_card = AgentCard(
    name='Hello World Agent',
    description='A minimal A2A demo agent',
    url='http://localhost:9999/',
    version='1.0.0',
    defaultInputModes=['text'],
    defaultOutputModes=['text'],
    capabilities=AgentCapabilities(streaming=True),
    skills=[skill],
    authentication=AgentAuthentication(schemes=['public']),
)

request_handler = DefaultRequestHandler(
    agent_executor=HelloWorldAgentExecutor(),
    task_store=InMemoryTaskStore(),  # 生产环境可替换为 PostgreSQL 后端
)

app = A2AStarletteApplication(
    agent_card=agent_card,
    http_handler=request_handler,
).build()

uvicorn.run(app, host='0.0.0.0', port=9999)
# 自动注册: GET /.well-known/agent.json → Agent Card
#          POST / → JSON-RPC 消息处理

客户端实现：发现 + 发送消息 + 流式接收

# client.py
import asyncio, httpx
from uuid import uuid4
from a2a.client import A2ACardResolver, A2AClient
from a2a.types import SendMessageRequest, SendStreamingMessageRequest, MessageSendParams

async def main():
    async with httpx.AsyncClient() as httpx_client:
        # 1. 发现 Agent Card
        resolver = A2ACardResolver(httpx_client=httpx_client, base_url='http://localhost:9999')
        agent_card = await resolver.get_agent_card()
        
        # 2. 初始化客户端
        client = A2AClient(httpx_client=httpx_client, agent_card=agent_card)
        
        # 3. 构造消息
        payload = MessageSendParams(message={
            'role': 'user',
            'parts': [{'kind': 'text', 'text': 'What is 100 USD in EUR?'}],
            'messageId': uuid4().hex,
        })
        
        # 4a. 同步请求
        response = await client.send_message(SendMessageRequest(id=str(uuid4()), params=payload))
        print(response.model_dump(mode='json', exclude_none=True))
        
        # 4b. 流式请求
        stream = client.send_message_streaming(
            SendStreamingMessageRequest(id=str(uuid4()), params=payload)
        )
        async for chunk in stream:
            print(chunk.model_dump(mode='json', exclude_none=True))

asyncio.run(main())

流式任务处理：状态事件 + 产物更新

# 高级 AgentExecutor —— 演示完整任务生命周期
from a2a.types import (TaskArtifactUpdateEvent, TaskState, TaskStatus, TaskStatusUpdateEvent)
from a2a.utils import new_agent_text_message, new_task, new_text_artifact

class CurrencyAgentExecutor(AgentExecutor):
    async def execute(self, context: RequestContext, event_queue: EventQueue) -> None:
        task = context.current_task or new_task(context.message)
        if not context.current_task:
            event_queue.enqueue_event(task)  # 首次创建 Task

        async for event in self.agent.stream(context.get_user_input(), task.contextId):
            if event['is_task_complete']:
                # 发送产物 + 完成状态
                event_queue.enqueue_event(TaskArtifactUpdateEvent(
                    taskId=task.id, contextId=task.contextId, append=False, lastChunk=True,
                    artifact=new_text_artifact(name='result', text=event['content']),
                ))
                event_queue.enqueue_event(TaskStatusUpdateEvent(
                    taskId=task.id, contextId=task.contextId,
                    status=TaskStatus(state=TaskState.completed), final=True,
                ))
            elif event['require_user_input']:
                # 进入 input_required 中断态（多轮对话）
                event_queue.enqueue_event(TaskStatusUpdateEvent(
                    taskId=task.id, contextId=task.contextId,
                    status=TaskStatus(
                        state=TaskState.input_required,
                        message=new_agent_text_message(event['content']),
                    ), final=True,
                ))
            else:
                # working 中间状态更新
                event_queue.enqueue_event(TaskStatusUpdateEvent(
                    taskId=task.id, contextId=task.contextId,
                    status=TaskStatus(
                        state=TaskState.working,
                        message=new_agent_text_message(event['content']),
                    ), final=False,
                ))

Google ADK 快捷方式

Google Agent Development Kit 提供了一行代码将 ADK Agent 暴露为 A2A 服务的能力：

from google.adk.agents import Agent
from google.adk.tools import google_search

agent = Agent(name="search_assistant", model="gemini-2.5-flash",
              instruction="Answer questions using Google Search.", tools=[google_search])
app = agent.to_a2a()  # 自动生成 Agent Card + A2A 端点
# uvicorn agent:app --host 0.0.0.0 --port 8001

从 v0.1 到 v1.0 的演进轨迹

版本里程碑

v0.1（2025年4月9日）——初始发布，50+ 合作伙伴。核心功能：JSON-RPC 2.0 / HTTP / SSE、Agent Card（路径 /.well-known/agent.json）、基本任务生命周期（submitted → working → completed/failed/canceled）、推送通知。发布伙伴包括 Atlassian、Box、Salesforce、SAP、LangChain、PayPal 等。

v0.2.x（2025年5-6月）——增量改进。v0.2.2 加入 gRPC 和 REST 定义、协议扩展框架、Agent Card iconUrl 字段、修复 JSON-RPC 2.0 一致性问题。

v0.3（2025年7月31日）——稳定性里程碑，150+ 组织支持。Breaking change：Agent Card 路径从 /.well-known/agent.json 改为 /.well-known/agent-card.json（IANA 反馈）；Python SDK 全面重构为 snake_case。新增：gRPC 支持固化、Agent Card JWS 签名、扩展客户端 SDK。

v1.0（2026年3月12日）——首个生产就绪版本。重大变更包括：枚举值改为 SCREAMING_SNAKE_CASE（completed → TASK_STATE_COMPLETED）；Part 统一为单一类型（移除 kind 鉴别器）；a2a.proto 升级为规范唯一权威来源；新增 ListTasks 方法（支持分页过滤）；现代 OAuth 2.0（废弃 implicit/password 流，新增 Device Code + PKCE）；原生多租户支持；三种协议绑定等价保证。

治理与合并

2025年6月23日——Google 在 Open Source Summit North America（丹佛）将 A2A 捐赠给 Linux Foundation，由 Jim Zemlin 和 Rao Surapaneni 共同宣布。AWS 和 Cisco 作为新验证者加入。

2025年8月底——IBM 的 Agent Communication Protocol（ACP，2025年3月发布的 REST-first Agent 通信协议）正式合并入 A2A。ACP 原用于驱动 IBM 的开源 BeeAI 平台，以简洁的 REST 设计和 MIME 类型扩展性著称。合并后，ACP 的 Kate Blair（IBM Research 孵化总监）加入 A2A TSC，BeeAI 平台完成从 ACP 到 A2A 的迁移。ACP 带来的影响包括：REST 简洁性理念、Agent 生命周期管理概念、OpenTelemetry 可观测性钩子。

框架生态支持

Google ADK：原生 A2A + MCP 支持，A2AServer / RemoteA2aAgent 组件
Microsoft Semantic Kernel：A2A 集成示例，承诺 Azure AI Foundry + Copilot Studio 支持
CrewAI v1.10+：内置 A2A 协议支持
LangGraph/LangChain：通过示例集成，为原始 50+ 发布伙伴之一
BeeAI（IBM）：ACP 合并后全面 A2A 支持
Cisco AGNTCY：基于 A2A + MCP 构建"Agent 互联网"
OpenAgents：声称同时原生支持 A2A 和 MCP

当前局限性与社区反馈的痛点

架构层面的瓶颈

点对点通信的 O(n²) 扩展性问题 是最被频繁讨论的技术限制。A2A 基于 HTTP/gRPC 直连，当 Agent 数量增长时，连接管理和编排开销呈二次方增长。HiveMQ 的技术分析指出："在小型隔离系统中可行，但在大规模企业环境中变得脆弱、复杂且不可持续。"多方建议引入事件网格或消息代理层解耦 Agent。

缺乏类型化技能定义。Agent Card 的 skills 只有名称、描述和自然语言示例，没有 JSON Schema 级别的输入/输出参数类型约束。CodiLime 指出：“LLM 规划器能发现’存在哪些技能’，但常常无法可靠地确定’必须提供什么结构化数据’”。这对自动化编排和测试构成挑战。

隐式技能调用。核心工作流中没有"调用技能 X"的一等语义——服务端 Agent 根据消息内容自行决定执行什么。许多实现通过在 DataPart 中嵌入 skillId 字段绕过，但因缺乏标准化，跨厂商一致性难以保证。

安全方面的已知风险

Cloud Security Alliance 的 MAESTRO 威胁分析和学术论文（arxiv:2505.12490）揭示了多项安全隐患：Agent Card 欺骗（攻击者可创建冒充可信机构的恶意 A2A 服务）；长生命周期令牌（有效期达数小时或数天，增大攻击面）；粗粒度授权（令牌未定义敏感操作的精确范围）；缺乏用户同意机制（Agent 可访问整个日历而无需显式用户授权）；跨 Agent 提示注入传播（恶意指令可通过 A2A 在 Agent 链中扩散）。

社区批评声音

Hacker News 上的讨论（450 points, 280 comments）呈现显著的怀疑态度。知名开发者 Simon Willison 评论道："LLM 调用 LLM 这个想法某种程度上是科幻……LLM 本身已经够不可靠了，把它们链在一起只会让不可靠性叠加。“多位评论者将 A2A 比作"SOA/WSDL/CORBA 的 LLM 时代复活”。独立开发者 Fatih Kadir Akın 在广泛传播的分析中认为 A2A “试图从第一天就解决所有可能的 Agent 通信场景”，其企业优先策略让个人开发者缺乏实验动机，而 MCP 的增量式方法在开发者社区中赢得了先发优势。

关键采纳障碍

"鸡和蛋"问题——Agent 间通信的价值需要临界量的 Agent 才能体现，但大多数组织仍在构建单体 Agent 而非多 Agent 系统。缺乏初始客户端基座——与 MCP 发布即有 Claude Desktop 和 Cursor 不同，A2A 发布时没有任何成熟客户端。竞争生态壁垒——Anthropic 和 OpenAI 均不在 A2A 合作伙伴名单中，OpenAI 曾拒绝了一个 1,200+ 行的 A2A 支持 PR。

缺失与期待中的能力

官方路线图列出的计划功能包括：QuerySkill() 方法（动态技能查询）、任务内动态 UX 协商（如对话中途加入音频/视频）、流式可靠性改进、推送通知增强。社区额外期望的能力包括：事件驱动架构、类型化技能 Schema、带认证的 Agent 注册中心、显式用户同意编排（如 USER_CONSENT_REQUIRED 状态）、短生命周期范围令牌、跨 Agent 链的标准化可观测性、以及经济/计费原语。

结论：标准之争的深层博弈

A2A v1.0 的发布标志着协议在技术成熟度上迈出了实质性的一步——proto-first 的规范化源、三种等价协议绑定、9 态状态机、完善的安全方案体系——这是目前 Agent 间通信领域最完整的开放规范。然而，协议的成功并不仅取决于技术完备性。A2A 面临的真正考验在于：在 MCP 已占据开发者心智的局面下，能否通过企业级部署（如 Tyson Foods 供应链、ServiceNow AI Agent Fabric）证明其不可替代的价值。IBM ACP 的合并和 Linux Foundation 的中立治理是正确的战略步骤，但 O(n²) 扩展性瓶颈和缺乏类型化技能定义等架构层面的短板，仍需要在后续版本中回应。最值得关注的趋势是：A2A 和 MCP 正在从"是否需要两个协议"的争论，演进为"两个协议如何在同一架构中各司其职"的工程实践——agentgateway 这类同时代理两种协议的基础设施项目，可能成为弥合两个生态的关键中间件。