谷歌宣布将A2A协议正式捐赠给Linux基金会，这是啥？

最新推荐文章于 2025-07-18 15:12:19 发布

攻城狮7号

最新推荐文章于 2025-07-18 15:12:19 发布

阅读量623

点赞数 26

CC 4.0 BY-SA版权

分类专栏： AI前沿技术要闻文章标签： A2A协议人工智能深度学习 Agent

本文链接：https://blog.youkuaiyun.com/linshantang/article/details/148895024

AI前沿技术要闻专栏收录该内容

82 篇文章

订阅专栏

引言

一、A2A协议的核心——为AI智能体建立"社交规则"

二、A2A与MCP——"团队对话"与"工具使用手册"的区别

三、开源的阳谋——谷歌为何将"王牌"捐给社区？

四、挑战与展望——A2A是万能药吗？

展望：通往"自组织"智能体网络的基石

🎬 攻城狮7号：个人主页

🔥 个人专栏:《AI前沿技术要闻》

⛺️ 君子慎独!

🌈 大家好，欢迎来访我的博客！
⛳️ 此篇文章主要介绍 A2A协议
📚 本期文章收录在《AI前沿技术要闻》，大家有兴趣可以自行查看！
⛺️ 欢迎各位 ✔️ 点赞 👍 收藏 ⭐留言 📝！

引言

2025年的AI领域，我们见证了太多令人眼花缭乱的模型迭代和能力突破。但在一片喧嚣之下，一个深刻的瓶颈正日益凸显：AI们正在形成一座座强大的"能力孤岛"。

想象一下，一家大型企业希望实现招聘流程的自动化。负责筛选简历的AI智能体A，由一家厂商提供；负责安排面试的智能体B，是公司内部开发的；而负责背景调查的智能体C，则来自另一家专业的服务商。尽管每个智能体在自己的领域都表现出色，但它们之间语言不通、标准各异，无法顺畅地沟通和协作。招聘经理不得不像一个翻译官，在不同系统间手动传递信息、下达指令，自动化程度大打折扣。

这便是当前多智能体协作的困境。我们拥有了越来越多强大的"个体"，却缺乏一个能让它们协同作战的"团队协议"。

正是在这个背景下，谷歌在2025年4月的Cloud Next大会上，联合Salesforce、ServiceNow、MongoDB等超过50家技术伙伴，正式推出了Agent2Agent（A2A）协议。这并非又一个AI模型，而是一套旨在打破智能体"孤岛"，让它们能够跨平台、跨厂商、跨系统进行安全、高效协作的开放标准，这是从"孤岛"到"大陆"的必然一步。

更具里程碑意义的是，仅仅两个月后，在2025年6月的北美开源峰会上，谷歌宣布将A2A协议、相关SDK及开发工具正式捐赠给Linux基金会。这一举动，清晰地表明了谷歌的雄心：A2A不仅仅是谷歌自家的解决方案，它的目标是成为整个AI行业的"通用语"（Lingua Franca），如同互联网世界的HTTP协议、容器世界的Kubernetes一样，成为构建未来智能体生态的基石。

这篇文章，将带你深入了解A2A协议的方方面面。它究竟是什么？它如何工作？它与我们听过的其他协议（如MCP）有何不同？谷歌为何要将这一战略性资产开源？以及，它将如何塑造AI应用的未来？

一、A2A协议的核心——为AI智能体建立"社交规则"

要理解A2A，我们不妨先用一个简单的比喻。

想象一个庞大的建筑工地，要盖一栋摩天大楼。工地上有各种专业的施工队：钢筋工、水电工、木工、油漆工等等。每个施工队就是一个"AI智能体"，它们各自拥有独特的技能和工具。

在没有统一标准的情况下，项目经理（用户）会非常辛苦。他需要亲自告诉水电工，钢筋工的进度如何，墙体在哪里；然后再跑去告诉木工，水电管道已经铺设完毕，可以开始吊顶了。沟通效率低下，且极易出错。

A2A协议，就是为这个工地引入的一套现代化的"协同工作系统"。它包含几个核心概念：

（1）智能体（Agent） = 专业施工队

这很容易理解，每一个独立的AI程序、服务或机器人，就是一个智能体。它有自己的逻辑和专业技能。

（2）智能体卡（Agent Card）= 施工队的"能力名片"

这是A2A协议的巧妙设计之一。每个智能体都需要对外提供一份标准化的"名片"，这份名片通常是一个放在特定网络路径下的JSON文件。它清晰地描述了：

- 我是谁：智能体的名称、版本、功能简介。

- 我能做什么：它能执行哪些"技能"（Tasks），比如"查询天气"、"预订会议室"、"分析销售数据"。

- 你需要提供什么：执行每项技能需要哪些输入信息（比如查询天气需要"日期"和"城市"）。

- 如何联系我：与它通信的技术地址（API端点）。

- 安全认证：如何验证你的身份（如API密钥、OAuth等）。

有了这张名片，任何其他智能体都能"阅读"并理解它的能力，实现了"能力的自我发现"。项目经理不再需要维护一个复杂的通讯录，新的施工队可以"即插即用"。

（3）任务（Task）= 具体的工作指令

这是A2A协作的核心单元。当一个智能体（发起方）需要另一个智能体（执行方）帮忙时，它会创建一个标准的"任务"对象，并发送过去。这个任务对象包含了唯一的ID，需要执行的技能，以及所有必要的参数。

例如，会议安排智能体需要知道天气，它就会向天气智能体发送一个任务："Task ID: 12345, 技能: 查询天气, 参数: {日期: '2025-10-01', 城市: '北京'}"。

整个任务的生命周期（提交、处理中、完成、失败）都有标准化的状态，方便发起方随时追踪进度。

（4）成果（Artifacts）= 交付的工作成果

任务完成后，执行方会返回一个标准化的"成果"包。比如，天气智能体会返回一个包含日期、温度、天气状况等结构化信息的JSON对象。这种标准化的交付物，确保了发起方能够准确无误地理解和使用结果，而不用去解析各种奇奇怪怪的文本。

（5）推送通知（Push Notifications）= 异步进度更新

对于一些需要长时间处理的复杂任务（比如"生成一份季度销售分析报告"），执行方不能让发起方一直干等着。A2A协议支持推送机制，执行方可以主动向发起方发送进度更新，例如"数据收集中"、"分析已完成50%"，实现了高效的异步协作。

通过这套精心设计的"社交规则"，A2A为原本混乱的智能体世界带来了秩序。它让智能体之间的协作，从原始的手动、定制化对接，升级为自动化、标准化、可发现的现代化通信。

二、A2A与MCP——"团队对话"与"工具使用手册"的区别

在A2A出现之前，AI社区已经有了一个广受关注的协议——由Anthropic（Claude的开发公司）推出的MCP（Model-Context-Protocol，模型上下文协议）。甚至在A2A发布后，很多人依然困惑：这两个协议是什么关系？是竞争还是互补？

谷歌给出了一个形象的比喻："如果说MCP是扳手，为智能体提供使用工具的手段；那么A2A就是技工之间的对话，让多个代理像技工团队一样交流诊断问题。"

为了更清晰地理解，我们延续建筑工地的比喻：

（1）MCP：是每个工具的《标准使用手册》。它定义了一个智能体（比如一个水电工）应该如何使用外部工具（比如电钻、扳手、测量仪）。这里的"工具"在AI世界里就是API、数据库、函数等。MCP标准化了"工具能力描述"和"调用方法"，解决了一个智能体如何与N个不同工具高效交互的问题。水电工拿到任何一个符合MCP标准的工具，都能立刻看懂说明书并上手使用。

（2）A2A：是整个工地的《协同工作流程与规范》。它定义了不同施工队之间应该如何沟通、分配任务、交付成果。它解决的是M个不同智能体之间如何协同完成一个大项目的问题。它规定了水电工如何告诉木工"我这里管线铺好了，你可以来封板了"，以及木工如何回复"收到，预计明天开工"。

总结一下核心区别：

因此，A2A和MCP并非竞争关系，而是天生的盟友，共同构成了一个更强大的智能体生态系统。一个复杂的AI应用流程可能是这样的：

（1）会议安排智能体（使用A2A）向天气智能体发出一个任务："帮我查询明天北京的天气"。

（2）天气智能体接收到任务，它需要调用一个外部的天气数据API。这个API恰好遵循了MCP标准。

（3）天气智能体（使用MCP）读取天气API的"工具说明书"，知道如何正确调用它，并成功获取了天气数据。

（4）天气智能体（使用A2A）将获取到的天气数据打包成一个标准的"成果"，返回给会议安排智能体。

（5）会议安排智能体收到成果，继续它的下一步工作。

两者各司其职，相辅相成，共同构成了构建复杂AI应用的模块化基础。

三、开源的阳谋——谷歌为何将"王牌"捐给社区？

将A2A这样一个具有巨大战略价值的协议捐赠给中立的Linux基金会，无疑是谷歌深思熟虑后的一步棋。这并非单纯的"为爱发电"，而是一次经典的"开源阳谋"，其背后的逻辑与当年谷歌开源Kubernetes如出一辙。

（1）建立信任，加速成为行业标准

在多智能体协作的早期阶段，最大的障碍是"信任"。如果A2A协议由谷歌一家掌控，那么其他科技巨头（如微软、亚马逊）和广大开发者在采用时，必然会心存顾虑：会不会被谷歌"锁定"？协议的未来发展会不会完全由谷歌的商业利益决定？

通过将其托管给Linux基金会，谷歌有效地消除了这些疑虑。基金会的中立治理模式确保了A2A将保持厂商中立、社区驱动。这极大地降低了其他厂商的采纳门槛，使其更有可能成为被广泛接受的行业标准。谷歌的目标，显然不是从协议本身收费，而是希望通过掌控下一代AI应用的基础设施标准，在未来的生态竞争中占据有利地位。

（2）汇聚社区智慧，完善协议本身

A2A虽然设计精良，但AI世界瞬息万变，新场景、新需求层出不穷。仅靠谷歌一家公司，很难预见和满足所有可能的需求。开源意味着全世界的开发者和公司都可以为其贡献代码、修复漏洞、提出改进建议。这种"集体智慧"将大大加速A2A协议的迭代速度和健壮性，使其能够适应更广泛的行业需求。

（3）避免重蹈"标准战争"的覆辙

在技术史上，旷日持久的"标准战争"屡见不鲜，往往会拖慢整个行业的创新步伐。谷歌通过主动开放A2A并联合百家厂商，试图在智能体协作领域建立一个开放、统一的"根据地"，避免市场陷入碎片化、标准林立的混乱局面。这对于整个AI应用生态的健康发展，都是有益的。

当然，也有社区声音指出了潜在的风险。比如，有开发者担忧，A2A的核心之一是"智能体发现"，而谷歌是做索引和搜索的鼻祖。未来，决定哪个智能体被优先"发现"和推荐的，会不会变成一种新的"算法竞价排名"？这确实是开源社区在后续治理中需要警惕和解决的问题。但无论如何，将A2A置于开放治理之下，是迈向一个更可信、更协作的AI未来的关键一步。

四、挑战与展望——A2A是万能药吗？

A2A协议描绘的蓝图令人兴奋，但它并非一蹴而就的万灵丹。在通往未来的道路上，它仍面临诸多挑战与现实问题。

（1）"杀鸡焉用牛刀？"——协议的必要性质疑

一些务实的开发者，比如Y Combinator的合伙人就指出，他们内部构建了许多AI智能体来辅助公司运营，但并未依赖MCP或A2A。对于一些简单的、内部的、可控的工作流，直接点对点地开发接口或许更简单快捷。

这种观点不无道理。A2A的价值主要体现在复杂、异构、跨组织的大规模协作场景。对于初创公司或小型项目，引入A2A可能会带来不必要的复杂性。协议的推广需要找到真正能体现其价值的"杀手级应用场景"，比如大型企业的复杂ERP流程自动化、跨平台的智能家居设备联动等。

（2）可靠性与ROI——企业采用的现实门槛

企业在采用一项新技术时，最关心的是稳定性和投资回报率（ROI）。正如谷歌云的A2A共同创造者所言，企业只有在相信智能体技术像现有工具一样可靠时，才会大规模采用。但目前，生成式AI的"可靠性"恰恰是其短板之一。如何监控、衡量一个由多个智能体组成的复杂系统的性能？如何定义其服务级别协议（SLA）？这些工程问题仍处于早期探索阶段。

同时，衡量AI智能体的ROI也很困难。一个AI客服每年能节约多少成本，尚可计算。但一个能让团队协作更顺畅的智能体网络，其价值如何量化？在清晰的商业价值模型出现之前，许多企业可能会持观望态度。

（3）安全性的新挑战

A2A在智能体之间打开了无数的通信端点，这也带来了新的安全风险。身份验证、授权、访问控制、数据在传输过程中的加密、防止恶意智能体的攻击……每一个环节都需要极其周密的安全设计。一个节点的疏漏，就可能导致整个协作网络的安全崩溃。