谷歌的A2A看起来很美，就不要想得太美了。

大家好，欢迎收听老范讲故事的YouTube频道。

“看起来很美，就不要想得太美了。”这句话哪来的呢？来自于猫腻的小说《将夜》。这个里面有一句话叫：“你长得很美，所以就不要想得太美了。”事情是在哪呢？是在隆庆皇子看到桑桑酒量很好，就想收其为侍女。桑桑呢，是里面的一位女主，而隆庆皇子呢，长得很漂亮，而且身份地位非常高，手持大义的一个人。他提出了这样的一个要求，当时的主人公宁缺就进行了反击，说：“你长得很美，就不要想得太美了。”意思是什么呢？就是保持对现实的清醒认知，你要知道自己是谁，几斤几两。而且呢，也要敢于对强权逻辑进行挑战。

那么，这个事儿跟今天咱们要讲的谷歌A2A有什么样的关系呢？首先先讲一下，谷歌A2A到底是个什么东西。

计算机和软件专家这么多年来呢，其实一直在为一件事情努力。什么事呢？就是让不同的系统，特别是异构的系统（所谓异构系统，就是说你的系统拿C语言写的在Windows上，我的系统是拿Python语言写的在Linux上，他的系统是拿其他什么语言写的在IBM小型机上或者什么这样的），让这些系统呢可以相互之间配合协作，完成一些更复杂的服务。这是这么多年来，计算机专家一直在努力干的事情。

很多的系统都沉淀下来了，你说你把那玩意扔了，让我重写一遍，这肯定不行。所以一定还是要让这个系统为我们大的事业去提供新的热量，不能推翻重干。这些旧的系统呢，实际上里边就都是“屎山”嘛，我们管它叫“屎山代码”。你真要重写一遍，也不是说写不出来，但是你总会丢一点什么东西。现在可能觉得不是什么问题，但是等以后需要找的时候，这个成本就可能会变得很高。你丢掉的这些东西，可能会变得很值钱。这些东西就是能不动就不动。像程序员讲的就是什么：“说我这代码很烂，说能跑不？”什么意思？“说代码跟你有一个能跑就行，要么代码能跑，要么你能跑。”所以能不动就别动这个东西，就要想办法让大家凑合起来，先把事儿做了。

A2A呢，其实也是类似这么一个事儿。它呢是人工智能代理协作的一个标准化方案。现在我们都在玩AI Agent，各种各样的Agent要搁在一起。A2A呢，就是Agent to Agent。它呢定义了统一的通信规则，智能体发现呀、任务分配呀、状态管理呀，我们定了一堆规则来解决跨平台协作的问题。比如说你这是Gemini，那边是OpenAI，Gemini下头还有一大堆的……

什么谷歌翻译、谷歌搜索、谷歌地图，OpenAI后头没准还有一堆office的东西，还有GPT4O画图。等于有一些这样的工具，它们相互之间说：“我们要去聊个天了，怎么能够协作把这事做好？”

我也不惦记说我把OpenAI干掉，你通通都用Gemini；OpenAI反过来也是这样，我也不惦记把Gemini干掉。咱们协作着能够把事干完就完了，各自把擅长的事情做掉。这个事呢，看起来挺美的是吧？

那咱们接着往下说。它呢还挺开放，这个协议。它基于什么样的通信协议呢？是HTTP，也就是咱们浏览网页的这个协议。通过这个协议来走，不要再去定义一些新的私有协议了。

然后，我们使用叫“服务端事件”的这样一种方式，来去确定说对方的服务器干怎么样了。叫SSE，Server-Side Event。通过这样的方式，来确定对方干完了没有，干成什么样了，去决定这个事情是不是接着往前走。

然后呢，让每个智能体写一个叫“智能体卡片”的东西。什么叫智能的卡片呢？就是说你写一个文件说：“我是谁谁谁，我擅长干什么，我在哪个服务器上，我的位置怎么样，你怎么找到我。”大概写这样的一个卡片，然后把这卡片呢找一个地方放好。

当要开始干活的时候，咱把这个卡片都找齐了。有这么多智能体，这个适合画画，那个适合搜索。我们把这些智能体都找齐了，然后现在我们要看一下，我们整个要干一什么事，让各个智能体一起去干活去。

然后还有一些什么状态管理干嘛呢？比如说视频渲染。我现在用AI生成视频了，这挺慢的对吧？你不能让所有的都等它一个。你说：“这边你去生成视频去吧，我就不管你了。”过一段时间去看一下，你的这个状态做完没有。过个5秒钟试一次，过个5秒钟试一次，发现做完了，我再把这个视频拎出来，合到整个的结果里边去。

它呢，通过任务对象，实现复杂协作流程的异步管理。这个话呢是有点计算机专业术语了。这里呢讲一下什么叫异步吧。同步、异步，这是两个相对应的词。

同步的意思就是说，我这边发出请求了，你要给我干一什么事。但是呢，你没干完之前，我站这等着你；你等你干完了，我拿着结果，我再往前走。这叫同步。

异步什么意思？就是刚才咱们讲的，你给我干事去，我就干别的去了。过过一会我再来回来看你，看一下状态对不对。状态变了以后，我再把你结果回收，我再接着去做其他事情。这个就是并行处理的一种方式吧。

所以现在呢，A2A都是可以支持异步处理的。这是目前为止Agent的通讯方面。

定义的最完善的一个协议了。能想到的，没想到的，基本上人全想到了。谷歌嘛，也不是白来的。

现在呢，有三种主流的大模型通讯协议，其实干的活都差不太多。

第一种是Function Calling，OpenAI做的。它呢，就是你把能够做事的工具描述成一个Function，也是用一个描述文件把它描述完了以后，告诉大模型说：“我这有一功能，等你需要的时候你就调就完了。”这是一种方式。

第二种方式呢，就是MCP，叫Model Context Protocol（模型上下文协议）。它呢，是把刚才我们讲的这个描述的过程变成了一个对服务的描述，说：“我这个功能是在哪台服务器上，或者是在本地的一个外部服务器上，怎么去调用，它能解决哪些问题，输入哪些参数，输出哪些参数。”也是这样的一个描述，然后把这个描述扔给大模型，它就干活去了。

那A2A呢，其实干的活也类似。它呢，就是说我们把所有的，甭管是功能也好，还是Agent也好，我们通通都写出卡片来：“我能干什么，我在哪。”然后把这些东西通通都扔在一个地儿，等干活的时候，我们把所有的卡片收集齐了，然后来决定到底怎么去干。

其实干的活都差不太多，只是呢：
– Function Calling必须是在本地进行编程；
– 而这个MCP呢，它支持调用服务器上的东西，可以调用远程的东西；
– 而A2A呢，就是你调用的东西不再仅仅是由大模型调用工具了，它可以在Agent之间、大模型之间进行调用了。它是这样的一个更进一步的协议。

说白了，这三个都差不太多，都是基于JSON的方式将功能描述出来，然后将这些描述呢作为提示词直接扔给大模型，扔过去就完事了。大模型适时调用，就是我需要的时候我就调它，调完了以后呢，让大模型是等在这儿，还是说接着干别的事去，定期来问询，来去确认状态。等收到结果以后，再把结果合并到大模型推理过程中再去干别的。

他们三个的区别就是一个比一个复杂，一个比一个完备，也就差在这了。那你说做的完备，这有什么不好的吗？这不应该把它设计的很完备吗？很多人听了以后说：“老范学了这么多年计算机，难道老想着拿这种半不拉拉的东西就凑合吗？”这个您还真说对了。最后流行起来的各种技术，基本上都是这种半吊子设计的。特别完备的技术一般都流行不起来。

给大家举一些历史上的这种追求完备性的失败的案例吧。这里说的失败呢，并不是说完全没有用起来的这个东西，而是说在未来没有成为主流协议，在大的竞争中失败了。

但是呢，还是有一些单位会去使用的这些方案。第一个叫Lotus Domino，这个呢就是多米诺骨牌那个Domino。这个是1996年出来的东西。IBM当时呢收购了Lotus Notes之后，雄心勃勃推出的系统。Lotus现在估计很多年轻人都没听说过。大家现在使用什么office、Excel这些东西，都觉得很强大很厉害。最早的做类似这种功能的人是谁呢？就是Lotus。第一个在电脑上可以让大家方便处理表格的工具，叫Lotus 123。Lotus也做了类似于Powerpoint、类似于word这样的工具。所以最早做office的实际上是他。后来被微软抄袭了以后呢很生气，把自己卖给IBM了。IBM说这我得替你把公道整回来，我们要让大家一起来继续用Lotus。

Lotus当时还做了一个叫Lotus Notes的工具，不但是把office功能都做完了，还做了很多的协作功能。我现在需要做工作流，我需要做OA系统，我需要在里头有权限，有正常的批文流转，你就可以用Lotus Notes来去实现的，要比office当时还是要领先挺多的。后来到IBM手里来说，我们既然已经可以让这个东西流转起来了，我们要怎么更进一步？他们就出了一个东西叫Domino。你像Domino骨牌嘛，推倒一块，哗啦哗啦要一一直这么往前走，起这个名字也是为了这个。它是最早期的群建解决方案，就是说可以把各种的信息都包装起来，支持分布式的数据库和安全机制。我的数据库不一定都要存在一个地儿，我可以存在不同的地方，相互之间配合来工作。曾被视为办公自动化的标杆，当时也是觉得非常非常强大。我当时还学了好长时间呢，学这玩意说这东西实在太厉害了，比其他的这些都要强太多了。因为各种你能想到没想到的，它全都给你做出来了。

但是就遇到了很多其他的问题。第一个是对于复杂系统的二次开发成本和部署、培训成本实在太高了。你要想开发这个系统，你必须要先去问说有几个处长，谁审批什么事，大家是怎么流程，你要先去干这个事。而且整个开发完了以后，你还要培训人家怎么使用。整个都做完了以后呢，下一个问题是什么？你业务不能变。你只要业务开始发生变化了，有迭代了，你刚才花的这些成本再来一遍，这个是很麻烦的。而且呢Lotus Domino有一个很大的问题是什么？它不支持Windows。IBM当时在推一个东西叫OS 2。IBM为什么去收购Lotus？

Lotus Notes回来要去跟Office打一仗呢，不服气。我是花钱找比尔·盖茨去开发PC DOS，后来又花钱去找比尔·盖茨去开发OS/2。结果比尔·盖茨呢，一边拿着我的钱去给我开发OS/2，还给我拖进度；一边自己偷偷把Windows做出来了。Windows把我的OS/2打得满地找牙，我不服气。我要找一个跟我补齐短板的东西，一起去把Windows跟Office重新战胜它。OS/2也没有打败Windows，Lotus Domino也没有打败Office，大概就是这样的。

而且IBM还干了一个什么事呢？它全套使用自己的解决方案和开发工具。你要想集成一些第三方的拓展，也是很麻烦的。最后呢，是被微软的Exchange和Office打败了。微软Exchange实际上是一套功能很强大的外部服务器。这是我们讲的第一个案例。

第二个案例是什么呢？叫SOA。这个东西呢，叫服务导向架构（Service-Oriented Architecture）。2000年左右开始推出，谁在后边推呢？Sun、IBM和Oracle。它是基于当时的J2EE架构。它什么意思呢？就是当时大家都是用Java去开发各种各样的业务系统。这些业务系统呢，你要让它跑起来，要让它相互串起来。比如说你开发了一个库存管理，我开发了一个电商系统，那边开发了一个物流系统。我们怎么能够让系统整个转起来呢？我最好是写一个我们叫企业服务总线，在这个上面把这个物流系统、仓储系统、电商系统串一块，这个事不就跑起来了吗？你们那系统我们就不用改了。

这个当时其实也是一个非常美好的愿景。它呢，支持跨语言、跨平台的服务调用，推动企业应用集成的规模化落地。你们原来都已经花了好多钱了，做了一大堆的这种子系统了，我们现在给你串起来，干这样的一个事情。他干这个事跟刚才咱们讲那个Lotus Domino有一点点像，只是这一块呢要更先进一些了。但最后也是失败了。

失败的原因呢，是服务编排依赖集中式治理，难以适应敏捷开发。大家都做好了以后，我们现在要给大家串起来。但其实是真的是每一个提供的服务接口后边都是一个屎山，光看所有的这些文档都看不过来。现在想规划各种新的业务，只能在屎山基础上再叠加屎山，最后就变得越来越复杂。这是第一个错误原因。

第二个呢，过度依赖于一些特别复杂的重量级标准。比如说里头有一个叫WSDL，这个标准呢叫Web服务描述语言。

Web service description language 就是我们要发现你的服务嘛？你这儿做了一个服务怎么办呢？你要写一堆的文件，让我去调用的时候可以去发现你。我们现在做很多的类似这种工作，都要做一个叫自解释。

我这有一个仓储管理的系统，这个仓储管理系统到底应该怎么用呢？你应该调用以后，你就出一个类似于文档式的东西，告诉你要怎么怎么调用，我使用什么样的权限，要把这东西都写在文档里，或者说写在一个说明的服务里面。就是你要调用这个服务，然后我来给你说明，我给你讲清楚，你才来个调用，要有很多这样的东西在里头。

然后呢，还有一个很重的协议叫SOAP（简单对象访问协议，Simple Object Access Protocol）。你也要描述说，我这个对象到底是怎么回事，它等于有一大堆这样的协议在里头。最后调用起来就非常非常麻烦。而且你想他这些东西，你也要把改造原来那个系统。以前你这有一个仓储系统，肯定是不支持什么WSDL和SOAP的，你得改造这个东西。

最后说我们懒得动了，或者说这个系统人家已经交付了，钱都付完了，我现在再去找人弄，没人理我了。所以最后也没推起来。最终呢，这个是被微服务架构给替代了。不要做这么复杂，不要做这么重，独立部署和轻量化的通讯，最后替代了这种SOA的系统。

现在我们正在使用的各种Restful。Restful是什么？就是说我也不用去说明你这个服务到底是怎么回事，我只管调用，调用完了以后，得到一个Json的返回结果就完事了。我们现在使用OpenAI的ChatGPT，使用Gemini，使用所有的这些网上服务的调用API接口，实际上都是Restful。这个就要简单很多，不需要这种自解释。

这是第二个失败案例。第三个失败案例呢叫Sharepoint。这个东西是2006年微软推的。微软说我这有office，有Windows，还有这么复杂的权限系统，大家进到我的Windows系统里头去，谁有什么样的权限我都管好了。我也想打造一个企业级的内容管理和协作平台，文档、门户、业务流程我都给你整合在一块。你们不要再去折腾找人买OA系统，找人再定制开发，别干这事了，我都一站式给你搞定。

我们以前写OA系统的时候，有一个很头疼的点是什么呢？就是我们需要处理office文档。你做了一大堆的各种流程，最后你还是要在office文档里去干活。微软说干脆我自己弄吧。

就整了这么一套东西出来。SharePoint这个东西，我也是参加过培训，还折腾了挺久。最后呢，也没有太大用起来。

它呢，深度集成了Office套件，提供了开箱即用的文档、版本控制和工作流引擎。比如说，你这儿是财务系统，我这儿是销售系统，那边是一个HR的系统。我们自己做自己的文档管理，别人想到我们的财务系统里去看一下财务的各种规章制度、一些相关的文件，根据他的权限就可以进来找了。它的这些功能都是完整的，听起来也是头头是道的一套系统。

最后呢，也是没玩下去。用户体验极其僵化，界面复杂、定制化依赖代码开发。你要定制这东西，你还是得写大量代码，非技术用户基本上没办法进行自我配置。而且它的生态碎片化非常严重，第三方插件兼容很差。企业需要投入大量的资源维护定制化功能，因为每一个企业都有各自的需求。这块对于SharePoint系统来说，基本上就是地狱。

最后替代的技术是什么呢？Slack。我们也别费劲了，你也别研究说谁有什么权限或者什么样的，咱们直接上IM，大家聊天就完了。需要的时候就直接把文件丢在里头，就传过去了。国内呢，就是像什么钉钉、飞书、企业微信，这些系统就把它替代掉了。微软呢后来说，我也不再推SharePoint这样复杂的、完善的东西了，最后做什么？叫Microsoft Teams。咱们在这个里面聊天传文件就完了，别搞什么权限管理这么复杂东西。

那么这些项目都是怎么失败的呢？咱们讲到这么多项目。第一个呢，就是这些都是大厂推的。咱们刚才讲的这三个案例，一个是IBM的，第二个是IBM、Sun、Oracle的，第三个是微软的，都是大厂在推，而且都是花了大钱在推。这3个都是请讲师讲课、出书、组织培训，我都参加过培训，也都买过书、都学过，而且非常完善，看起来都很美。他怎么能失败呢？

第一个是默认需求和各个组件的能力是固定的，要干什么这事就一定是定死了，不许改。第二个呢，就是每一个组件到底能干什么也是确定的，不允许有什么变化。这是他们这些系统在设计之初就已经埋下的雷，所以他们应对各种变化、应对第三方的这种接入，都是非常麻烦的。

那你说我们的系统就是很复杂，怎么办呢？他们解决的方法呢，都是通过增加复杂度来应对各种灵活性问题。你想把这东西变得稍微灵活一点，可以，没问题，我们增加一点复杂度，写点程序是可以搞定的。但这件事呢，你肯定是越往后复杂度就越高，那你最后里头堆积的屎山代码就越多。

最后，这维护性就越来越差嘛。而且呢，做类似这种协议里头，还有一个很大的问题是什么？私心太重。就像刚才咱们讲那个隆庆王子的故事似的，他想要人家女主回来给自己做侍女，都是有私心的。那你说这些大厂能有什么私心呢？都是想捆绑自己家的服务。一开始IBM说我不上Windows，我要上OS/2，这不是捆绑自己的东西吗？后边Oracle、IBM和Sun去推SOA的时候，他们都是卖小机的，卖中间件服务器的。你一旦走了这条路，大家就一定要把它这个全套系统都买齐。所以肯定还是说店家推自己的东西。至于最后这个Sharepoint，那微软说你得买我的操作系统，你买我的Office，一套都买齐了，你不要用别人任何东西。大家私心都很重，所以第三方技术很难兼容进来。

这种技术应用，刚才咱们讲了不是说没人用，也有人用。但是呢，它有一个很大的前提，就是需要有自上而下的需求，由最上面开会来决定这事要这么干，一层一层讨论，从上往下布置。这个事是可以用起来的。上层决策者呢，通常喜欢大厂，也喜欢相对比较完善的方案。举个例子吧，比如日本。日本的IT企业一般都是自上而下决策的。刚才咱们讲这三个技术：Lotus Domino，部分制造业企业比如丰田，早期用于内部的OA系统，依赖定制化开发。但是因为维护成本实在太高，后来还是被淘汰了，因为你不支持Windows，这事咋弄？没法整。SOA，日本的金融行业，比如像三菱的UFJ银行，曾经通过这个SOA进行整合过。但是因为架构僵化，难以支持移动端创新，近年来逐渐转向微服务，还没有彻底转干净。当时做SOA的时候，还没有移动互联网呢，所以没想到过这个问题。Sharepoint，政府机构比如说总务省用于文档管理。但是因为界面实在太不友好了，协作效率实在太低，现在已经逐渐被Google Workspace取代了。

走这条路呢，基本上就退出了创新迭代的第一梯队。最上面这个老板，他也是信息茧房，并不知道一线的人每天在遇到什么样的事情。由他去拍脑袋决定，下边人只管执行的这种模式，不是说这东西就做不好。但是呢，四平八稳的，所有新东西跟他没关系。通过这种方式呢，日本失去了它的互联网和移动互联网时代。现在在AI时代面前呢，也在踌躇吧，大概是这样的一个状态。

总结一下，A2A协议的设计逻辑呢，与历史案例中的很多失败范式高度相似。试图通过顶层设计解决复杂的协作问题，却忽略了技术演进。

{的动态性和生态多样性。当前Agent的核心其实还是大模型，而大模型本身的能力边界还非常不清晰，依然在快速扩张之中。这两天，谷歌Gemini 2.5又升级了，现在升级到Gemini 2.5 Pro 0506版，也就是5月6号这个版本，又遥遥领先了。这次是真遥遥领先，特别是在编码这一块遥遥领先。

那你现在都已经到这样了，你说你做一大堆A2A，把代码写进去了以后，你发现大模型升级了，你咋弄？你根本没法整这个事。所以，A2A的未来呢，充满了非常大的不确定性。作为现在的一些新的程序员，或者是一些新的技术人员来说，这种系统出来呢，还是值得学习一下的。但是，不建议大家在上面投入太多的精力，把一些很重的系统直接搭建在类似这样的协议上面去，未来转向会比较麻烦的。

好，这个故事今天就跟大家讲到这里。感谢大家收听，请帮忙点赞、点小铃铛，参加DISCORD讨论群。也欢迎有兴趣、有能力的朋友加入我们的付费频道。再见！