深度剖析谷歌A2A：AI智能体协作的标准化未来看似诱人，但“看起来很美，就不要想得太美了”，我们能从历史复杂系统的失败中吸取哪些宝贵教训以指导当前选择？
5 月 09
AIGC, Google的故事 A2A协议, AI Agent, AI协作标准, API设计, Function Calling, Gemini, Google AI, HTTP, JSON, LLM, Lotus Domino, MCP模型上下文协议, OpenAI, SharePoint, SOA (服务导向架构), SSE, YouTube频道, 人工智能, 历史失败案例, 复杂系统风险, 大语言模型, 屎山代码, 开发者视角, 异构系统集成, 异步处理, 微服务, 技术史借鉴, 技术演进规律, 技术评论, 技术选型, 智能体互操作, 智能体协作, 看起来很美就不要想得太美了, 科技趋势解读, 程序员经验, 系统设计, 老范讲故事, 谨慎评估, 谷歌A2A, 跨平台协作, 软件架构, 顶层设计批判 深度剖析谷歌A2A：AI智能体协作的标准化未来看似诱人，但“看起来很美，就不要想得太美了”，我们能从历史复杂系统的失败中吸取哪些宝贵教训以指导当前选择？已关闭评论
谷歌的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讨论群。也欢迎有兴趣、有能力的朋友加入我们的付费频道。再见！