A2A火了：Google刚出的Agent间通信协议，到底解决了什么问题

上个月在搞一个多Agent协作的项目三个Agent各干各的互不搭理。一个负责搜资料一个负责写代码还有一个负责检查结果。听起来分工明确对吧但问题是——它们根本没在协作各写各的中间结果全靠我手动传。折腾了两周我忍不住想Agent之间能不能自己聊起来然后A2A就来了。先说说A2A是什么A2A全称 Agent-to-Agent是Google在4月刚发布的一个开放协议。说白了就是让不同的AI Agent之间能直接对话自己协调工作任务不需要人类在中间当传话筒。这个协议一出来就炸了。不是因为Google做了个多牛的协议而是因为这是业界第一次有巨头站出来给Agent通信这件事定了个标准。要知道在这之前每个团队搞Agent通信都是造自己的轮子用HTTP硬写的、用消息队列的、用WebSocket的接口五花八门参数格式各写各的Agent A给Agent B传数据得先写个适配层我那个项目的痛基本就是整个行业的痛。为什么现在才有人做这件事你可能想问Agent都火了一年了怎么到现在才有统一的通信协议答案其实很尴尬——大家都在卷没人愿意等。去年到今年上半年所有AI团队都在忙着做一件事让单个Agent变得更强。更长的上下文、更好的推理能力、更多的工具调用。哪怕到了今年初市面上大部分的Agent都还是个单兵作战的状态。到了2026年Q2情况变了。单Agent的能力天花板开始显现。一个Agent再强也有它不擅长的领域代码Agent能写代码但不知道怎么查最新API文档搜索Agent擅长找资料但写出来的报告上下文不够多模态Agent能看图但推理链太浅这时候大家才意识到不是让Agent变成全能超人而是让多个专业Agent配合起来干活才是正解。也就是Multi-Agent System。然后问题就来了Agent之间怎么通信A2A解决了哪几个核心问题看了A2A的白皮书和实现我总结了一下它主要解决了3个问题问题1Agent发现Agent之间怎么找到彼此以前的做法是在代码里hardcode对方的API地址。但真实场景里Agent可能临时加入、退出或者动态被调用。A2A用了一个叫Agent Card的机制。每个Agent发布自己的身份信息、能力描述、接口限流策略。其他Agent通过Card发现它就像你打开手机蓝牙搜设备一样。这个设计我觉得挺聪明的——解耦了发现和通信两步。问题2任务编排A2A定义了一套标准的任务生命周期从提交 → 进行中 → 完成/失败。而且支持流式返回。就是Agent A给Agent B派了个任务Agent B开始干活的中间结果也会实时推回来。你不用等它全部做完才能拿结果。这点在真实场景里太重要了。我之前那个项目代码Agent写完代码要等彻底测试完才告诉我结果出错了还得重来一遍。如果能流式返回中间结果我可以在它写了一半的时候就看看方向对不对。问题3安全性说实话Agent通信最大的坑还不是技术是安全。你想Agent之间能互相发指令了那攻击面一下就大了。怎么验证对方的身份怎么防止Agent A给Agent B发恶意指令A2A把这些东西统一了。用OAuth 2.0那一套做身份认证通信加密权限控制也有标准接口。我之前搞Agent协作的时候光鉴权就写了三种不同方案。后来一测还有漏洞。说实话那代码我自己都不太敢看。和MCP有什么区别说到这肯定会有人问Google不是还有个MCP吗和A2A啥关系简单来说MCPModel Context Protocol解决的是AI模型怎么调用外部工具/API。Agent → 工具。A2AAgent-to-Agent解决的是Agent之间怎么互相通信。Agent → Agent。一个是纵向的Agent去操控工具一个是横向的Agent去协调其他Agent。两者不是替代关系是互补的。用我那个项目举例MCP让代码Agent能调用GitHub API、Code Review工具A2A让代码Agent、搜索Agent、测试Agent之间互相协调我的真实感受说实话刚看到A2A发布那天我第一反应是又来一个协议AI圈的协议实在太多了。今天这个标准明天那个规范开发者的学习成本越来越高。但仔细读了A2A的文档之后我改变了看法。原因很简单——这是刚需。你可以选择不用A2A自己写一套Agent通信。但你会发现凡是Agent协作稍微复杂一点的应用你最后写出来的东西跟A2A八九不离十。无非就是任务编排、状态同步、错误处理、安全认证这些。既然大家都在造同样的轮子不如有个统一标准省得重复劳动。而且A2A是开源的。Google没有把它搞成Google Cloud独占的东西可以自己部署。实际怎么用A2A的协议层基于HTTP消息格式用JSON所以接入成本很低。我试了一下写一个A2A兼容的Agent其实只需要三步# 1. 定义Agent的A2A能力Cardagent_card{name:search-agent,description:搜索互联网获取最新信息,skills:[web_search,news_query],auth:bearer_token,rate_limit:100# 每分钟最多100次}# 2. 实现标准的任务接口app.post(/a2a/task)asyncdefhandle_task(task:Task):iftask.typesearch:resultawaitsearch_web(task.params)returnTaskResult(statuscompleted,dataresult)else:returnTaskResult(statusfailed,error不支持的task类型)# 3. 注册到发现系统awaitregister_agent_card(agent_card)说真的比我想象的简单。可能踩的坑用了一个多星期总结几个实际遇到的坑坑1协议兼容性目前A2A还比较新不同框架实现A2A的方式有细微差异。我用LangGraph做的Agent和另一个用CrewAI做的Agent在A2A通信时出现过字段名不匹配的问题。解决方案两边都用Google官方A2A SDK或者自己写一个适配层。坑2错误传播Agent A调用Agent BB调用C。C出错了错误信息要一层层传回来。A2A虽然定义了错误码但不同Agent的错误处理策略不一样。有的Agent出错会重试3次有的直接放弃。这就导致了同一个错误在Agent C是重试3次后放弃传到Agent B是任务失败传回Agent A就成了未知错误。我在每个Agent的return结果里加了error_chain字段类似分布式追踪里的span id这样能定位到具体是哪个环节出的问题。坑3性能开销A2A走HTTP每次Agent通信都有网络开销。如果是大量小任务的场景比如Agent每生成一句话就同步一次性能会崩。建议大任务走A2A小批量数据走共享内存/缓存。别跪在协议上。写在最后A2A可能不是Agent通信的终极答案但它是目前最靠谱的起点。就像当年的REST API一样它不完美但有了它大家就不用各自为政了。如果你也在搞Agent项目建议花半小时看看A2A的文档。就算不用里面的设计思路也值得学习——任务生命周期管理、Agent发现、安全认证这些都是Multi-Agent系统的通用问题。下一篇打算写个A2A MCP的实战让Agent既能互相聊天又能调用工具。感兴趣的可以关注。参考资料Google A2A 官方文档A2A GitHub 仓库MCP 协议介绍