AGENT

A2A 协议快速指南

解锁无缝AI协作的秘密：了解A2A协议如何让智能体以空前的效率进行通信、协作和扩展。

admin

• 27 min read
A2A 协议快速指南
微信 ezpoda免费咨询：AI编程 | AI模型微调| AI私有化部署
AI模型价格对比 | AI工具导航 | ONNX模型库 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

两个AI智能体通过A2A协议进行协调：交换结构化消息、通过Agent Card发布能力，并跨多智能体工作流跟踪任务生命周期状态。

1、A2A解决的多智能体通信问题

个人优秀，集体沉默。这是当今大多数AI智能体部署的状态。一个物流智能体无法向库存智能体提问。一个客户支持智能体没有办法在对话中途将工作移交给退货智能体。智能体在各自的岗位上已经变得非常出色。问题是每个智能体仍然在独自完成工作。这就是A2A协议要解决的多智能体通信问题。

在2025年的大部分时间里，每个智能体框架都发明了自己的解决方案。LangChain用一种方式，CrewAI用另一种方式。AutoGen有自己的方法，现在已统一到Microsoft Agent Framework 1.0（2026年4月3日发布），将AutoGen置于维护模式以支持统一的SDK。想要来自不同框架的智能体协作意味着编写自定义的粘合代码。大量的粘合代码。

谷歌的智能体到智能体协议（A2A）改变了这一切。于2025年4月9日在Google Cloud Next上宣布 [15]，并于2025年6月23日贡献给Linux基金会 [14][13]，A2A从一个规范草案成长为超过150个组织支持的生产协议 [12]。截至2026年初，它正在接近1.0版本 [1]，已成为AI智能体发现、通信和委派工作的领先标准。

2、什么是A2A协议？

A2A是一个定义AI智能体如何通信的开放协议。把它想象成智能体的HTTP。正如HTTP为我们提供了一种标准方式让Web客户端和服务器交换数据（无论它们用什么语言编写），A2A为智能体提供了一种标准方式来找到彼此、描述它们的能力、交换消息和在任务上协作。

该协议基于HTTP上的JSON-RPC 2.0构建 [2]。没有奇异的传输层。没有专有协议。如果你的服务能处理HTTP请求，它就能说A2A。

3、A2A协议 vs MCP：澄清最常见的混淆

多智能体架构中最让人困惑的是什么？将A2A与MCP混为一谈。它们不是竞争标准。它们在不同层次解决不同的问题，搞错这一点会导致你围绕错误的抽象来设计系统。

MCP（模型上下文协议）于2025年12月9日由Anthropic捐赠给Linux基金会下的Agentic AI Foundation（AAIF）[22]。

MCP将智能体连接到其工具。 把MCP想象成智能体用来拿锤子、读文件、查询数据库或调用外部API的接口。它是智能体与其控制的资源之间的垂直接口。

A2A将智能体连接到其他智能体。 把A2A想象成智能体用来与同伴协调、委派子任务和共享结果的接口。它是独立协作者之间的水平接口。

A2A官方文档说得很清楚："A2A是关于智能体在任务上的合作，而MCP更多是关于智能体使用能力。"[3] 谷歌最初的公告也呼应了这一点："A2A是一个开放协议，补充了Anthropic的模型上下文协议（MCP），后者为智能体提供有用的工具和上下文。"[15]

这种区别很重要，因为这两个问题有根本不同的形态：

  • 目的：MCP处理智能体到工具的通信。A2A处理智能体到智能体的通信。
  • 关系：MCP是层次化的——智能体控制其工具。A2A是对等的——智能体作为平等的合作者协作。
  • 发现：MCP使用工具清单和模式。A2A使用Agent Card。
  • 状态：MCP调用是无状态的。A2A任务携带完整的生命周期。
  • 通信：MCP仅支持请求-响应。A2A增加了流式传输和多轮模式。
  • 典型用例：MCP是"调用这个API"或"读取这个文件"。A2A是"分析这些数据并报告结果"。
  • 范围：MCP在单个智能体的上下文内操作。A2A跨越智能体边界。
None

2.1 MCP和A2A如何协同工作

这里有一个具体的例子。一个编排智能体收到一个客户请求。它使用A2A发现一个物流智能体并委派一个路由子任务。物流智能体使用MCP连接到承运商API（FedEx、UPS）、运费数据库和地理编码服务。物流智能体完成工作后，通过A2A将结果回复给编排智能体。

编排智能体永远不需要知道FedEx API的事情。物流智能体永远不需要知道客户的账户详情。每个智能体都有自己的工具（通过MCP），并通过共享协议（通过A2A）通信结果。

2.2 何时使用A2A vs MCP

这种分离很强大。你可以在不改变A2A接口的情况下更换物流智能体的内部工具。你可以用不同的实现替换整个物流智能体，只要它说A2A并在其Agent Card中发布相同的能力。MCP管理内部接线。A2A管理外部协作。

3、A2A协议核心概念：五个构建块

五个构建块驱动A2A协议：Agent Card、任务、消息、制品和流式传输。它们共同解决了独立智能体需要协同工作时出现的每个协调问题——发现、委派、进度跟踪、多轮对话和增量结果交付。每一个都不可或缺。

3.1 Agent Card：A2A智能体如何发现彼此

在智能体能够对话之前，它们需要找到彼此并了解对方能做什么。Agent Card解决了这个问题。它们是描述智能体能力、端点、认证要求和支持的交互模式的JSON文档。[4]

把Agent Card想象成一张名片；只不过它以机器可读的形式编码能力。它告诉其他智能体：我是谁，我能做什么，如何联系我，以及如何认证。

{
  "name": "Shipping Logistics Agent",
  "description": "Handles package routing, delivery scheduling, and carrier selection",
  "url": "<https://logistics.example.com/a2a>",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "skills": [
    {
      "id": "route-package",
      "name": "Route Package",
      "description": "Determines optimal shipping route and carrier",
      "inputModes": ["text"],
      "outputModes": ["text", "data"]
    },
    {
      "id": "track-shipment",
      "name": "Track Shipment",
      "description": "Real-time tracking for active shipments",
      "inputModes": ["text"],
      "outputModes": ["text"]
    }
  ],
  "authentication": {
    "schemes": ["bearer"]
  }
}

Agent Card位于/.well-known/agent-card.json，遵循RFC 8615定义的well-known URI约定。[21][4] 客户端智能体获取卡片，了解远程智能体能做什么，并决定是否参与。截至v1.0，Agent Card可以使用JSON Web Signature（JWS, RFC 7515）进行加密签名，因此客户端可以验证卡片的真实性和完整性 [9]：防止开放市场场景中的冒充。

3.2 A2A任务：有状态的智能体协调单元

当一个智能体想让另一个智能体做某事时，它创建一个任务。任务是A2A协议中的核心协调机制。[6] 每个任务有唯一的ID、生命周期和明确定义的状态机。

任务经历以下状态 [2]：

  • submitted（TASK_STATE_SUBMITTED）：远程智能体已确认请求并将其排队
  • working（TASK_STATE_WORKING）：智能体正在积极处理
  • input-required（TASK_STATE_INPUT_REQUIRED）：智能体需要客户端提供更多信息才能继续
  • auth-required（TASK_STATE_AUTH_REQUIRED）：智能体需要认证才能继续
  • completed（TASK_STATE_COMPLETED）：完成，结果可用
  • failed（TASK_STATE_FAILED）：出了问题
  • canceled（TASK_STATE_CANCELED）：任务在完成前被取消
  • rejected（TASK_STATE_REJECTED）：智能体拒绝执行任务（终态，与failed不同）
  • unspecified（TASK_STATE_UNSPECIFIED）：不确定或未知状态；proto默认/零值
💡 v1.0注意：状态枚举值从v1.0开始从小写连字符格式（submitted、input-required）变更为TASK_STATE_前缀的SCREAMING_SNAKE_CASE格式。如果你从v0.x迁移，请相应更新状态比较。
A2A Java SDK 1.0.0.Alpha1于2026年1月19日发布。A2A Java SDK的最新版本是1.0.0.Alpha2，于2026年2月12日发布。
None

以下是通过网络传输的任务创建过程：

{
  "jsonrpc": "2.0",
  "id": "req-001",
  "method": "message/send",
  "params": {
    "message": {
      "role": "user",
      "parts": [
        {
          "kind": "text",
          "text": "Route package PKG-7829 from warehouse Austin to customer in Portland, OR. Priority: next-day."
        }
      ]
    },
    "metadata": {
      "contextId": "order-ctx-4521"
    }
  }
}

远程智能体响应一个任务对象：

{
  "jsonrpc": "2.0",
  "id": "req-001",
  "result": {
    "kind": "task",
    "id": "task-a3f8b721",
    "contextId": "order-ctx-4521",
    "status": {
      "state": "submitted",
      "message": {
        "role": "agent",
        "parts": [
          {
            "kind": "text",
            "text": "Task received. Evaluating carrier options for Austin to Portland next-day delivery."
          }
        ]
      }
    }
  }
}

任务模型既支持快速的请求-响应模式，也支持长时间运行的工作流。简单的查询立即完成。复杂的多步分析需要几分钟，客户端可以定期检查或订阅流式更新。

为什么有状态的任务很重要：与普通的HTTP请求-响应调用相比。如果你通过REST API将复杂任务委派给另一个智能体，你没有标准的方式来检查进度、处理部分结果或在连接断开时恢复。A2A任务生命周期内置了所有这些功能。[6]

3.3 消息：A2A智能体如何交换多模态内容

消息承载智能体之间的实际内容。[5] 每条消息有一个角色（user或agent）并包含一个parts数组。Parts可以是：

  • 文本（text）：纯文本内容
  • 文件 — 原始（raw）：二进制文件字节，在JSON中base64编码（用于内联二进制载荷，如日志转储或图像）
  • 文件 — URL（url）：文件内容的外部URI引用（用于存储在外部的大文件）
  • 数据（data）：用于机器可读信息的结构化JSON
💡 v1.0注意：三个独立的part类型（TextPart、FilePart、DataPart）被合并为带有oneof区分符的单一Part消息。没有单一的"file"类型；文件内容要么是raw（内联二进制）要么是url（外部引用）。此外，mimeType在v1.0中被重命名为mediaType。

这种多模态设计意味着智能体可以在单条消息中同时交换文本指令、日志文件、图像或结构化数据。[5] 支持智能体可以将客户投诉（文本）、相关服务器日志（文件）和账户元数据（数据）作为一条协调消息发送给诊断智能体。

消息通过contextId关联，它将相关消息分组到对话线程中。[5] contextId是服务器生成的标识符，逻辑上分组多个相关的Task对象，在一系列交互中提供上下文。这让智能体能够跨多轮工作流维护上下文。

3.4 制品：A2A中的流式交付物

制品就是结果。当智能体完成工作时，输出以制品的形式返回。制品可以是生成的报告、一组运输标签、带有路由决策的JSON载荷或PDF发票。

制品使用TaskArtifactUpdateEvent [7] 增量流式传输，包含artifactId、append（用于分块交付）和lastChunk（信号完成）等字段：

{
  "kind": "artifact",
  "artifactId": "route-result-001",
  "parts": [
    {
      "kind": "data",
      "data": {
        "carrier": "FedEx",
        "service": "Priority Overnight",
        "estimatedDelivery": "2026-03-26T14:00:00Z",
        "cost": 47.50,
        "trackingNumber": "FX-9283746501"
      }
    }
  ],
  "lastChunk": true
}

你不需要等待50页的报告完全生成后才开始接收。制品在产生时就到达。对于大型输出，这很重要。

3.5 SSE流式传输：智能体到智能体委派的实时可见性

对于长时间运行的任务，A2A协议支持服务器发送事件（SSE）。[10] 客户端发送消息并订阅更新流。在v1.0中，组合发送和订阅的规范RPC方法是SendStreamingMessage（v1.0之前的JSON-RPC名称是message/stream）。

两种事件类型通过流传输：

  1. TaskStatusUpdateEvent：状态转换和进度消息 [7]
  2. TaskArtifactUpdateEvent：中间和最终结果随着可用性流式传输 [7]

每个SSE的data字段包含一个JSON-RPC 2.0对象。[10] 如果客户端的SSE连接在任务仍然活跃时断开，它可以使用SubscribeToTask方法重新连接。[7] 如果SSE对基础设施不实用，客户端也可以使用GetTask（v1.0规范名称；v1.0之前的别名：tasks/get）进行轮询。

这种流式传输模型对智能体到智能体工作流至关重要。当编排智能体委派给专家智能体时，它需要可见性：专家智能体是否卡住了？是否需要输入？是否快完成了？SSE提供了这种透明性，而不会用轮询请求轰炸服务器。

4、A2A实践：架构模式

四种A2A架构模式涵盖了大多数真实世界的部署。了解哪种模式适合你的用例，会影响你如何实现智能体发现、任务委派和跨系统集成。

4.1 模式1：中心辐射式智能体编排

最常见的模式。一个中央编排智能体接收请求并委派给专家智能体：

  • 客户问："我需要退货X并发送一个替代品"
  • 编排智能体将请求分解为子任务
  • 向退货智能体发送退货处理任务（通过A2A）
  • 向物流智能体发送替代品发货任务（通过A2A）
  • 聚合结果并回复客户

编排智能体永远不需要知道任何一个专家的实现细节。它只知道每个智能体的Agent Card说它能做什么。

None

4.2 模式2：智能体市场发现

Agent Card实现了标准化发现，这正是使智能体市场成为可能的原因。组织可以将智能体发布到市场，其他组织可以在承诺使用之前以编程方式发现和评估它们。Agent Card格式让你评估一个智能体的能力（它做什么、需要什么认证、产生什么输出格式）而无需编写任何集成代码。

谷歌用Agentspace（2024年12月推出 [16]）开创了这种模式，后者在2025年底被重新品牌为Gemini Enterprise，并合并到Gemini Enterprise Agent Platform（2026年4月22日GA）[18]。它建立的智能体市场模型仍然是核心的A2A模式。

4.3 模式3：跨组织协作

A2A的认证支持和明确定义的边界使其非常适合跨组织智能体通信。零售商的订单管理智能体可以与供应商的库存智能体对话，每个智能体在独立的环境中运行，具有独立的安全上下文。

基于HTTP的JSON-RPC基础意味着标准的API网关模式适用。速率限制、认证、日志记录和监控都以与REST API相同的方式工作。[2] 你的运维团队不需要新的运维手册。

4.4 模式4：混合MCP + A2A智能体

最复杂的模式：同时暴露MCP和A2A接口的智能体。作为MCP服务器，智能体表现为其他智能体可以直接调用的工具。作为A2A服务器，同一个智能体参与具有完整任务生命周期管理的多智能体工作流。

这种双接口方法让智能体既能服务于简单的工具调用场景（通过MCP），也能服务于复杂的协作工作流（通过A2A），而无需复制内部逻辑。

                      Orchestrator Agent
                     /                  \
                (A2A)                  (A2A)
                   /                      \
      Shipping Agent              Analysis Agent
       /          \                    |
    (MCP)        (MCP)              (MCP)
     /              \                  |
 FedEx API      Rate DB           Data Warehouse

物流智能体使用MCP连接其工具，使用A2A参与编排。这些协议不竞争。它们在不同层操作。

5、开始使用A2A协议

5.1 定义你的Agent Card

创建一个描述智能体能力的JSON文件，并托管在/.well-known/agent-card.json [4]。此路径遵循RFC 8615的well-known URI。每个想与你的智能体合作的其他智能体都会首先获取这个端点。

5.2 实现JSON-RPC方法

至少你需要 [2]：

  • message/send（v1.0中的SendMessage）：接受传入消息并创建任务
  • tasks/get（v1.0中的GetTask）：返回任务状态和结果

对于流式传输支持，添加：

  • message/stream（v1.0中的SendStreamingMessage）：接受消息并返回SSE流

5.3 使用A2A Python SDK实现

这里变得具体了。A2A Python SDK（a2a-sdk v1.0.x，v1.0.0于2026年4月20日发布）[26] 提供了客户端和服务器实现。安装它：

pip install a2a-sdk

该SDK实现了协议规范1.0，并兼容0.3版本 [11]。

服务器组装三个组件：你实现的AgentExecutor、将其连接到协议层的DefaultRequestHandler，以及通过HTTP暴露它的A2AFastAPIApplication [25]：

import uvicorn
from a2a.server.apps.jsonrpc import A2AFastAPIApplication
from a2a.server.request_handlers import DefaultRequestHandler
from a2a.server.agent_execution import AgentExecutor, RequestContext
from a2a.server.events import EventQueue
from a2a.server.tasks import InMemoryTaskStore, TaskUpdater
from a2a.types import (
    AgentCard, AgentCapabilities, AgentSkill,
    Part, TextPart,
)

class AnalysisAgentExecutor(AgentExecutor):
    async def execute(self, context: RequestContext, event_queue: EventQueue) -> None:
        updater = TaskUpdater(event_queue, context.task_id, context.context_id)
        await updater.start_work()
        result = await analyze_data(context.get_user_input())
        await updater.add_artifact(parts=[Part(root=TextPart(text=result))])
        await updater.complete()

    async def cancel(self, context: RequestContext, event_queue: EventQueue) -> None:
        updater = TaskUpdater(event_queue, context.task_id, context.context_id)
        await updater.cancel()

card = AgentCard(
    name="My Analysis Agent",
    description="Analyzes data and generates reports",
    url="https://my-agent.example.com",
    version="1.0.0",
    capabilities=AgentCapabilities(streaming=True),
    default_input_modes=["text/plain"],
    default_output_modes=["text/plain"],
    skills=[
        AgentSkill(
            id="analyze",
            name="Data Analysis",
            description="Analyzes datasets and produces insights",
            tags=["analysis", "data"],
        )
    ],
)

request_handler = DefaultRequestHandler(
    agent_executor=AnalysisAgentExecutor(),
    task_store=InMemoryTaskStore(),
)

app = A2AFastAPIApplication(agent_card=card, http_handler=request_handler).build()

if __name__ == "__main__":
    uvicorn.run(app, host="0.0.0.0", port=8080)

在客户端，ClientFactory.create_from_url()自动解析远程智能体的卡片并返回一个类型化连接 [25]：

from a2a.client import ClientFactory, ClientConfig
from a2a.types import Message, Part, TextPart, Role

# Connect: fetches /.well-known/agent-card.json automatically
client = await ClientFactory.create_from_url(
    "<https://my-agent.example.com>",
)
async with client:
    message = Message(
        role=Role.user,
        parts=[Part(root=TextPart(text="Analyze Q1 2026 sales data for anomalies"))],
    )
    # Stream updates as they arrive
    async for event in client.send_message(message):
        if isinstance(event, tuple):
            task, update = event
            print(f"Status: {task.status.state}")
        else:
            print(f"Result: {event}")

5.4 使用A2A Inspector测试

A2A Inspector [27]（A2A项目维护者的官方工具）实时验证你的实现是否符合规范。在你的端点上运行它，可以在上线之前捕获合规性问题。Technology Compatibility Kit（TCK）[28] 提供了更完整的合规性测试套件，组织在四个合规层级中进行生产就绪验证。

6、A2A协议安全：认证、签名和传输

A2A协议从一开始就为真实世界部署而设计。安全不是事后的想法。

认证方案：Agent Card声明支持的认证方法（bearer令牌、OAuth 2.0、API密）。[2] 客户端在发送消息之前进行认证。这映射到运维团队已经了解的标准API安全模式。规范支持的方案类型覆盖了大多数团队需要的：apiKey、http（Bearer）、oauth2、openIdConnect和mtls都受支持。

Agent Card签名：0.3版引入了Agent Card的加密签名，1.0版使用JSON Web Signature（JWS, RFC 7515）和JSON规范化方案（JCS, RFC 8785）将其正式化。在市场场景中，这很重要：没有签名，恶意行为者可以发布假冒受信任智能体的伪造Agent Card。

上下文隔离：每个任务在上下文边界内操作。处理任务的物流智能体不会自动获得对编排智能体内部状态或其他任务的访问权限。你通过消息和制品模型控制哪些信息跨智能体边界流动。

传输安全：A2A在生产环境中通过HTTPS运行。规范要求TLS 1.2或更高版本，推荐TLS 1.3+，并指定HSTS头。v1.0还将双向TLS（mTLS）正式化为支持的安全方案。结合认证，智能体到智能体通信获得了与任何REST API调用相同的安全保证。现有基础设施（API网关、WAF、速率限制器）无需修改即可工作。

授权模式：A2A在协议层面定义了认证。授权（哪些智能体可以访问哪些技能）留给实现。大多数生产部署在A2A的认证机制之上叠加OAuth范围或自定义RBAC。

A2A安全模型没有重新发明轮子。它建立在行业花了20年加固的相同HTTP安全模式上。你现有的API网关基础设施、WAF规则和速率限制策略直接转移到A2A部署。运维团队不需要学习新的安全模型。这是正确的决定。

使这个模型可用于生产的是各层如何叠加。每一层增加一个独特的控制面，因此生产团队可以将A2A插入现有的API网关策略、WAF规则和RBAC，而无需从零重建安全模型。五层一起意味着你在完整的智能体交互生命周期中获得纵深防御：

  1. 认证在Agent Card中声明（bearer、OAuth 2.0、API密钥）
  2. Agent Card签名（v0.3引入，v1.0正式化）防止开放市场中的冒充
  3. 每任务上下文隔离保持智能体状态边界清洁
  4. HTTPS传输复用现有WAF和速率限制器基础设施
  5. 实现层面的授权通过OAuth范围或RBAC叠加

7、真实世界的A2A协议集成模式

7.1 企业服务网格集成与A2A

拥有现有SOA或微服务架构的大型企业将A2A智能体视为其内部网络上的另一种服务类型。Agent Card注册到服务发现系统（Consul、Eureka或基于DNS的发现）。编排智能体查询注册表、获取Agent Card，并以与微服务调用下游服务相同的方式委派工作。

A2A智能体继承了组织已有的所有服务间通信运维模式。熔断器、重试策略、可观测性和部署管道直接转移。你不需要为A2A智能体准备单独的运维手册。它们插入你现有的服务网格。

A2A的企业文档确认与分布式追踪（OpenTelemetry、W3C Trace Context）和API管理平台兼容，用于策略执行。

7.2 事件驱动的多智能体协调与Kafka和A2A

一些团队将A2A与Kafka等事件流平台结合。[29][30] 编排智能体不直接进行智能体到智能体调用，而是将任务请求发布到一个主题。专家智能体从主题消费、处理工作并发布结果。A2A的任务生命周期清晰地映射到事件驱动模式：任务状态变为事件类型。

这在你需要智能体之间松耦合或任务量大且突发时效果很好。事件代理处理背压和负载均衡，而A2A提供结构化消息格式和任务生命周期。

8、A2A协议行业采用

A2A的采用数字令人印象深刻。截至2026年4月，超过150个组织支持它 [12]，建立在2025年4月宣布的启动合作伙伴群组之上 [15]：

企业技术：Salesforce、SAP、ServiceNow、Atlassian、Box、Intuit、Workday

AI/ML平台：Google Cloud、LangChain、Cohere、MongoDB

支付和商业：PayPal

供应链：Tyson Foods、Gordon Food Service（在跨组织试点中开创协作供应链智能体；Gordon Food Service正在积极计划将该系统投入Gemini Enterprise生产并在更多供应商中扩展）

截至2026年4月的主要平台集成包括Microsoft（Azure AI Foundry、Copilot Studio）和AWS（Amazon Bedrock AgentCore Runtime），Salesforce、SAP和ServiceNow是创始贡献者组织 [12]。

谷歌的Agent Development Kit（ADK）原生支持A2A [19]，Gemini Enterprise Agent Platform（谷歌的托管智能体平台，从Vertex AI重新品牌，2026年Cloud Next上发布，2026年4月22日正式可用）增加了托管A2A部署 [18]。社区还发布了A2A Inspector [27] 和Technology Compatibility Kit（TCK）[28] 用于开发和验证。

在标准方面，W3C AI Agent Protocol Community Group正在向官方Web标准推进，预计2026-2027年会有规范 [20]。A2A不再是单纯的谷歌项目。它于2025年6月被贡献给Linux基金会 [13]。它正在走上成为具有多年治理稳定性的Web标准的道路。

9、A2A协议的下一步

该协议在2026年初达到v1.0，在五个主要企业中确认了生产部署。未来12个月的发展将决定A2A是成为大规模Agentic AI的默认协调层还是多种选择之一。以下是重要的发展：

多协议绑定：1.0版提供三个官方协议绑定：JSON-RPC、gRPC和HTTP+JSON [2]。gRPC现在已经是生产基础设施，而不是路线图项目。预计更多框架将采用gRPC绑定用于高吞吐量智能体工作负载，其中HTTP/1.1开销很重要。

W3C标准化：推动官方Web标准意味着A2A正在为长期而设计。W3C AI Agent Protocol Community Group的目标是2026-2027年规范 [20]。这不是谷歌控制的过程。这是多利益相关者标准轨道。

智能体市场：Agent Card是这里的使能原语，使智能体在购买前可发现和可评估。ISV可以将其智能体货币化。企业可以在不需要自定义集成工作的情况下消费它们。

与MCP的融合：随着两个协议的成熟，预计会有更紧密的集成模式和共享工具，用于构建原生说两种协议的智能体。混合MCP+A2A模式正在复杂部署中出现。

10、更大的图景：A2A作为多智能体基础设施

我们正处于一个拐点。几十年来，软件系统通过人类设计和维护的API进行通信。有了A2A，我们正在构建软件智能体自主发现和相互通信的基础设施。

这不是理论上的。Salesforce、SAP、ServiceNow、Microsoft和AWS正在生产中运行A2A [12]。该协议已经越过了"有趣的规范"阶段，进入了"生产基础设施"阶段。

与HTTP的类比很贴切但不完整。HTTP标准化了文档检索。A2A标准化了协作。区别很重要，因为协作需要状态管理、能力发现和多轮交互。简单的请求-响应协议不能很好地处理这些问题。一个运行几分钟、需要中途输入并流式传回部分结果的任务，是一个与获取网页根本不同的协调问题。

如果你正在构建多智能体系统（甚至是一个有朝一日可能需要与其他智能体对话的单一智能体），A2A是你应该学习的协议。生态系统正在快速增长，规范在v1.0稳定化 [8]，工具已经达到你可以在其上构建真实系统的程度。

智能体不仅在学习相互对话。它们正在构建基础设施，以可靠地、大规模地、跨越组织边界地做到这一点——而标准已经在生产中。

11、A2A协议常见问题

问：什么是A2A，用一句话概括？ 答：一个开放协议（HTTP上的JSON-RPC 2.0），标准化AI智能体如何发现彼此的能力并在任务上协作。

问：A2A与MCP有什么区别？ 答：MCP将智能体连接到工具和数据源（垂直的，智能体控制工具）。A2A将智能体连接到其他智能体（水平的，对等协作）。它们是互补的。用MCP处理你的智能体与其工具的交互。用A2A处理你的智能体如何与其他智能体通信。

问：什么是Agent Card？ 答：描述智能体能力、端点、认证要求和支持技能的JSON文档。其他智能体从/.well-known/agent-card.json获取它，以了解该智能体能做什么。

问：任务生命周期状态有哪些？ 答：TASK_STATE_SUBMITTED、TASK_STATE_WORKING、TASK_STATE_INPUT_REQUIRED、TASK_STATE_COMPLETED、TASK_STATE_FAILED、TASK_STATE_CANCELED和TASK_STATE_REJECTED（智能体拒绝任务）。附加状态：TASK_STATE_AUTH_REQUIRED（智能体将认证委派给客户端）和TASK_STATE_UNSPECIFIED（未知/不确定）。注意：A2A v1.0将所有状态枚举值从小写连字符名称变更为TASK_STATE_前缀的SCREAMING_SNAKE_CASE [9]。

问：谁支持A2A？ 答：超过150个组织，包括Google、Salesforce、SAP、ServiceNow、LangChain、PayPal等 [12]。它在Linux基金会治理下，并朝着W3C标准化迈进。

问：我可以将A2A与任何AI框架一起使用吗？ 答：是的。A2A是框架无关的。它是一个线协议。如果你的智能体能发起和接收HTTP请求，它就能说A2A。

问：如果我已经在使用MCP，我需要A2A吗？ 答：取决于你的架构。如果你的智能体单独与工具工作，MCP就足够了。如果你的智能体需要将工作委派给其他智能体，或者其他智能体需要将工作委派给你的智能体，A2A是该协调层的正确协议。许多生产系统两者都使用。

原文链接: A2A Protocol v1 2026: How AI Agents Actually Talk to Each Other

汇智网翻译整理，转载请标明出处