Google A2A 实战理解，相比 MCP 它实际上是任务队列协议

如何用 MCP 实现自动化运维？零基础从概念理解到实战开发复用本文的 MCP 实践，将这个功能用 A2A 复现。

观看这个时长一分半的Google 演示视频能更好理解文章内容，来自这个页面。

A2A 的特点在于让 Client 侧 LLM 去调 Remote 侧 Agent/Workflow。

远程 LLM Agent 要声明自己的服务 URL
客户端 Agent 要显式添加这个 URL。

标准的 List 能力和 Prompt 封装上， A2A 和 MCP 是非常类似的。

A2A 和 MCP 主要区别在于实现一个异步的 Task 发布订阅管理。

如果没有 A2A ，能否实现客户端 LLM 调用服务端 Agent workflow? 当然可以，Workflow 本身都能通过 API 直接暴露，则把这个 API 用 MCP 包一层，包装成 tool 函数，优化说明的 Prompt 就行。

Tool 本身是同步阻塞的，即当前对话一定要等 tool 执行完返回结果，LLM 再继续，是一个串行同步的执行 ,时间是累加的。
A2A 则是客户端LLM 向远程 LLM 提交一个 Task 并订阅，可以几天之后再主动接受 task 的完成情况，如同在和一个真人布置任务。
- 比如复杂任务『帮我背调这5个候选人』，明显背后是一个复杂的业务系统，需要几天来完成，用 Tool 方式阻塞对话则不合适。
- 即使 Tool 只是 call API 提交任务（如触发 workflow），也不知道后续的执行情况。这时在 LLM 的同一个对话上下文里，就需要一个持久化事件队列的实现，同时也是异步非阻塞的。

所以示例中大量代码实际上在处理这个 Task 的订阅机制，这才是 A2A 核心价值所在。

也和MCP 类似，这套机制需要在客户端添加复杂的实现。

目前 A2A 只有官方库的纯业务代码演示 ，对协议实现的通用逻辑没有抽象成 SDK 。我们需要尽量复用官方库的 Server 和 Client 来 POC 。先使用官方的 demo/ui

~~这个 UI 有问题见 issue ，我用 x86 硬件的 win10 和 ubuntu 启动，页面响应非常卡慢，只有 M1 MBP 能用~~

定义 Agent

这里复用官方库的 langGraph 实现基础上修改。这本质上是 workflow 的定义和 A2A 无关，快速过一下。

定义系统提示词prompt ，提示词代码
下面的代码都是通用逻辑，加了一些 log 方便理解
使用langGraph 的 tool 定义，和 FastMCP 相同，同样是使用函数的注释和参数的 pydantic 描述来定义 shcema , 所以直接引入 MCP 包内函数即可。引入代码另外langGraph 这 tool 要包装成同步，代码如下

Tool 复用

在 mcp 包内定义如下

python 复制代码

from pydantic import Field
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("Parameter Descriptions Server")

@mcp.tool()
def add_monitors(
    urls: list[str] = Field(description="监控URL列表,需要去重,且必须包含完整协议(如https://bing.com)"),
) -> str:
    """批量添加多个监控器到Uptime Kuma,添加完成后返回 Uptime Kuma 的页面地址,显示出来"""
   
   // rest code

会自动导入 LangGraph 的tool 定义。 而且这种框架内的 Tool 调用时会比 MCP 快一点。

启动服务

这样定义之后 http://localhost:10000/.well-known/agent.json 接口是展示 Remote Agent 能力，类似于 MCP 的list_tool ，如下：

json 复制代码

{
  "name": "Monitor Agent",
  "description": "Helps with managing website monitoring using Uptime Kuma",
  "url": "http://localhost:10000/",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "stateTransitionHistory": false
  },
  "defaultInputModes": [
    "text",
    "text/plain"
  ],
  "defaultOutputModes": [
    "text",
    "text/plain"
  ],
  "skills": [
    {
      "id": "website_monitoring",
      "name": "Website Monitoring Tool",
      "description": "Helps with managing website monitoring using Uptime Kuma",
      "tags": [
        "website monitoring",
        "status"
      ],
      "examples": [
        "Add monitor for https://example.com",
        "List all my monitors",
        "Delete monitor with ID 5"
      ]
    }
  ]
}

bash 复制代码

#启动服务
uv run .

启动在 localhost:10000 , 工具加载成功。

使用 A2A

先手动添加 Remote Agent 的Url ，可以看到名字和描述进入 conversation ，输入

把bing.com bing.com baidu.com baidu.com google.com google.com github.com 加入监控

可见 Client LLM 识别到了要用『Monitor Agent』完成本任务。这里直接把用户输入透传给 Remote Agent，没有做 Prompt 优化问题提取参数等处理。

过程中， task 初始状态为 submmited。可以看到 Task 有Id 和完整 Schema ，理论上可以入库持久化，用于需要长时间执行的任务。只是示例代码没这么复杂。

之后转化为 COMPLETED

从 remote 侧看 log，参数的提取去重和加上 https前缀都生效了，符合预期。注意这些都发生在 Remote 侧，而不像 MCP tool call 发生在 Client 侧。

（单击图片放大）

去monitor 页面查看，结果符合预期。

这个 demo/ui 问题有点多，交互能力和展示信息其实也有限，后半段 Client 切换到 CLI 工具演示

Client 侧

可以看到 jsonrpc 依次返回了 Task 中间态

Remote 侧

此处可以看到 A2A完整流程

GET /.well-known/agent.json 获得 Agent 能力说明 Schema
生成中间响应: submit task
生成中间响应: 调用 tool ， workflow 执行中
生成最终响应: 任务完成 task_complete: True

对应 Cient 侧显示的 jsonrpc 中间态。

可以看到 Task 的处理流程。

注意这块代码是业务逻辑，在 Remote Agent 侧使用业务代码实现。

SSE 本身断开连接后无法主动推送下一个事件，所以这里实现了持久化事件队列 ，每个 Task 都有 taskId，和完整 schema ,可以入库，且客户端需要实现重连机制。只是示例代码没有这个复杂实现。

这个 task_manager.py 实现了一个非阻塞的异步任务处理机制，可以看出这些特点：

SSE 流式推送：在 on_send_task_subscribe方法中，服务器创建一个异步任务(_run_streaming_agent)来处理请求，并立即返回一个事件流。客户端通过这个流接收实时更新。
如果客户端提供了 pushNotification 配置，服务器会在任务状态更新时调用send_task_notification方法，将任务状态推送到指定URL。

整个过程是完全异步的，不会阻塞会话执行。但很明显客户端的对话框 UI 要支持这个消息模式。这对现有的大部分 Client 都是破坏性改动，很难支持，不像 MCP 可以复用 Tool 展示。 在初期可能和 Google Agentspace 绑定，这东西只面向企业用户，还未正式开放。

思考：可能是 Google 先弄出来了 Google Agentspace 然后把这个业务系统中独特的 Task 交互流程提取出来变成了这个 A2A 协议。

总结

A2A 和 MCP 相比，标准化的能力发现，调用能力基本一致，考虑市面上的框架本来就能把 Agent Workflow 当 API 用，remote LLM 并不是 A2A 的核心价值。其核心价值在于：

实现了持久化事件队列 ，尽管示例代码没有把它入库持久化，但已经有了完整的 Schema 定义，针对的是异步的需要执行几天的 Task
针对上述模式要求特殊的 Client chat 交互 ，在初期可能和 Google Agentspace 绑定，是 Google 全家桶的 Workspace ，存在一定的商业利益。
如果企业广泛的采用本模式：即将一箩筐业务包装成完整的 Agent workflow 暴露，则只对接本接口规范，就能和各个潜在的第三方 Workspace 即 Client LLM 端集成。