上周末我在折腾一个多Agent系统，三个Agent各干各的，数据传不过来，调度全靠手写Webhook。

折腾到凌晨两点，群里有人甩了句：“试试A2A协议？”

我查了一下，发现这玩意儿最近是真的火。Google推的Agent-to-Agent协议，GitHub上已经6万star了。今天聊聊它到底解决了什么问题，以及我试下来的真实感受。

背景：Agent越来越多，但谁都不理谁

说实话，2026年做AI开发的人，手头没几个Agent都不好意思跟人打招呼。

我自己的项目里就跑了三个Agent：

• 一个负责数据分析（Python脚本生成+执行）
• 一个负责内容生成（写报告、总结）
• 一个负责外部API调用（查天气、查股票、查新闻）

每个Agent都跑得很好。但问题是——它们之间不说话。

数据分析Agent查出了异常数据，想让内容Agent在报告里重点写一下。怎么做？

我之前的方式是：数据分析Agent把结果写到Redis → 内容Agent轮询Redis → 取到数据后生成报告。

这个方案有三个痛点：

1. 轮询效率低：5秒查一次，浪费API调用
2. 格式不统一：今天我写JSON，明天改成protobuf，后天又换回JSON
3. 耦合太紧：一个Agent改了输出格式，所有依赖它的Agent都得改

说白了，缺一个Agent之间通用的"交流协议"。

A2A是什么：不是又一个RPC框架

A2A的全称是 Agent-to-Agent Protocol，由Google在2025年4月提出，本质上是定义了Agent之间"说话"的规范。

它不是RPC框架，也不是消息队列。它更像是Agent界的HTTP——定义了请求和响应的格式，但不关心你怎么实现。

核心概念就几个：

1. Agent Card（能力名片）

每个Agent需要公开一个 agent-card.json，描述自己会什么、不会什么。

GET /.well-known/agent-card.json

返回示例：

{
  "name": "数据分析Agent",
  "capabilities": ["csv_analysis", "trend_detection", "anomaly_finding"],
  "input_formats": ["csv", "json", "parquet"],
  "output_formats": ["markdown", "json", "chart_data"],
  "rate_limit": 100
}

这个设计我觉得很妙。以前我要知道一个Agent能干什么，得看文档、翻代码。现在直接GET一下，一清二楚。

2. Task（任务单元）

一个Agent向另一个Agent发出的请求，叫做一个Task。

{
  "task_id": "task_20260513_001",
  "type": "data_analysis",
  "input": {
    "data_source": "sales_q1_2026.csv",
    "analysis_type": "trend",
    "params": {
      "time_column": "date",
      "value_column": "revenue"
    }
  },
  "callback_url": "https://my-agent/callback/task_20260513_001",
  "ttl": 300
}

Task有唯一ID、有回调地址、有过期时间。这样设计的好处是——发完就不用管了。对方处理完了会主动call back。

3. Artifact（产物）

Agent完成任务后产出的结果，可以是数据、报告、图表、代码等。

{
  "task_id": "task_20260513_001",
  "status": "completed",
  "artifacts": [
    {
      "type": "markdown",
      "content": "# Q1销售趋势分析\n\n总体营收同比增长23%，但3月份出现下滑..."
    },
    {
      "type": "chart_data",
      "format": "vega-lite",
      "spec": "{...}"
    }
  ]
}

4. Agent-to-Agent协商

如果一个Agent发现另一个Agent能力不够，可以发起能力协商。比如：

• Agent A：我需要图片分析
• Agent B：我只能处理文本
• Agent A：那你帮我调用Agent C？

这个过程自动完成，不需要开发者手动配置。

实测：把我的三个Agent连上A2A

我花了一个周末，把之前那三个各自为政的Agent改造成了A2A兼容。

改造过程

不需要推翻重写。A2A的设计很聪明，只需要在每个Agent外面包一层Adapter。

class A2AAdapter:
    def __init__(self, agent, agent_card):
        self.agent = agent
        self.card = agent_card
        
    def handle_task(self, task):
        # 解析A2A请求，转换为Agent内部格式
        # 执行任务
        # 包装成A2A Artifact返回
        pass

每个Agent加一个Adapter，总共加了不到200行代码。说实话比我预期的工作量小多了。

效果

改完之后，我用一个简单的工作流测试：

1. 从API拉取股票数据
2. 分析趋势
3. 生成分析报告

三个Agent串起来，中间不需要我写任何胶水代码。

最让我惊喜的是错误处理。以前如果中间某个环节挂了，整条链路就断了，我还得手动去查日志。用A2A之后，每个Task都有状态追踪：

{
  "status": "failed",
  "error": {
    "code": "RATE_LIMIT_EXCEEDED",
    "message": "API rate limit hit, retry after 30s",
    "retry_after": 30
  }
}

接收方可以自动重试，不需要我插手。

A2A vs MCP：两个协议到底什么关系

很多同学会搞混这两个概念，我一开始也懵了。

MCP (Model Context Protocol) 是让 AI模型调用外部工具的协议。
A2A (Agent-to-Agent Protocol) 是让 Agent之间互相通信的协议。

打个比方：

• MCP = Agent的手和脚（能操作外部工具）
• A2A = Agent的嘴巴和耳朵（能跟其他Agent交流）

两者是互补关系，不是替代关系。实际上Google的架构推荐是：MCP + A2A一起用。

一个典型的三层架构：

[用户] → [编排Agent] ←→ [专用Agent集群]
                ↓                ↓
             [MCP工具]       [MCP工具]

编排Agent通过A2A调度多个专用Agent，每个专用Agent再通过MCP调用外部工具。

如何开始用A2A

如果你也想试试A2A，最快的方式是看Google官方的Python实现。

pip install google-adk

ADK（Agent Development Kit）内置了A2A支持。创建一个Agent并声明Card：

from google.adk import Agent

agent = Agent(
    name="data_analyzer",
    instructions="你是一个数据分析专家",
    capabilities=["csv_analysis", "trend_detection"],
    enable_a2a=True
)

就这么几行，Agent就有了A2A能力。其他Agent可以通过 agent.discover(url) 发现它，然后 agent.send_task() 发送任务。

对于非Python项目，可以用A2A的HTTP API直接交互。只要实现Agent Card接口和Task处理接口就行，语言不限。

我遇到的坑

坑1：Task超时设计

A2A的TTL默认是60秒。但我的数据分析Agent处理大CSV文件时，很可能超过60秒。

解决方案：A2A支持 streaming=True 模式。改为流式传输，先返回部分结果，再逐步补充。

{
  "streaming": true,
  "parts": [
    {"status": "processing", "progress": 0.3},
    {"status": "processing", "progress": 0.7},
    {"status": "completed", "artifacts": [...]}
  ]
}

坑2：Agent Card的版本管理

刚上线时，我的数据分析Agent改了capability名字，从 csv_analysis 改成了 csv_analysis_v2。结果其他Agent根据旧Card发来的Task全部路由失败。

解决方案：在Agent Card里加 versions 字段，显式声明兼容的历史版本。同时加个 redirect 机制，旧Task自动转发到新接口。

坑3：安全认证

A2A协议本身没有强制认证。如果Agent暴露在公网上，任何人都可以向它发Task。

我一开始没注意这个问题，直到有个Agent被隔壁团队的测试脚本频繁打扰，才发现裸奔太危险。

我加了一层简单的Token验证器：

def verify_task(task, token):
    if not validate_jwt(token, ISSUER):
        return False
    if not check_permission(token, task.type):
        return False
    return True

官方推荐用OAuth 2.0 + JWT，但我自己的项目暂时用了API Key + IP白名单，够用了。

写在最后

A2A协议的出现，让我感觉Agent开发的"野蛮生长阶段"快要结束了。就像当年Web开发从手写Socket到有了HTTP协议一样，Agent之间也需要一个通用的交流语言。

Google这次做得很聪明——协议本身很轻量，没有强绑定到某个框架或云平台。你可以用Python写、用Go写、甚至用Node.js写，只要能解析JSON加上发HTTP请求就行。

我用下来最直观的感受：写胶水代码的时间至少省了70%。

以前搞多Agent系统，一半时间都在写Agent之间的数据传递和格式转换。现在声明一下Agent Card，剩下的交给协议本身去处理。

如果你也在搞多Agent系统，建议看看A2A。不一定要用，但了解一下这个"Agent界的HTTP"是怎么设计的，对你设计自己的系统也有启发。

下篇准备写一下A2A + MCP的组合实战，欢迎关注。