AI 智能体之间怎么"对话"?
一文看懂 Google 的 A2A 协议

一句话导语:当 AI 不再只会"听你指挥",而是能彼此商量着把事办完,背后靠的就是 A2A 这套"通用语言"。这篇文章帮你彻底搞懂它。

◆ 先看一个生活场景

想象你要办一场婚礼。

你不会自己一个人从头忙到尾——你会请一个婚礼策划师。策划师又会去联系摄影师、花艺师、酒店、主持人。这些人来自不同的公司,用着不同的工具,说话方式也各不相同。但神奇的是,只要大家约定好一套"行话"——比如"几月几号、几点、在哪、要拍多少张、预算多少"——整件事就能顺顺当当地办成。

策划师不需要懂摄影师怎么调相机,摄影师也不用管花艺师怎么插花。每个人只负责自己擅长的部分,通过一套大家都听得懂的沟通方式协作。

现在,把"人"换成"AI 智能体(AI Agent)",你就理解了 A2A 协议要解决的问题。

小科普:AI 智能体(Agent),简单说就是"能自己动手干活的 AI"。它不只是聊天,还能查资料、调用软件、连续做好几步任务,像一个会思考的小助理。

随着这两年 AI 智能体越来越多,一个新问题冒了出来:这些来自不同公司、用不同技术造出来的 AI,彼此之间怎么沟通、怎么配合干活?

A2A 协议,就是为了回答这个问题而生的。

上面这张图里,每个 Agent 来自不同"公司",但它们能互相喊话、分工、回传结果。让这件事成为可能的"通用语言",就是 A2A。

◆ A2A 到底是什么?

A2A,全称 Agent2Agent(智能体对智能体),是一套开放的通信协议。 它由 Google 在 2025 年 4 月正式发布,并联合了 50 多家科技公司一起推动。到了 2025 年 6 月,Google 把这个项目捐给了 Linux 基金会(Linux Foundation),交由一个新成立的中立组织来维护,任何人都可以参与贡献。代码以 Apache 2.0 开源许可证开放。

小科普:协议(Protocol) 这个词听起来很高级,其实就是"约定好的规矩"。比如打电话,你说"喂",对方也说"喂",这就是一种约定。再比如全世界的网页都能在浏览器里打开,是因为它们都遵守一个叫 HTTP 的协议。A2A 就是 AI 智能体之间的"通话规矩"。

用一句大白话总结:

A2A 让不同来源、不同技术造出来的 AI 智能体,能够安全地互相发现、对话、分工、协作,共同完成一件复杂的事。

注意这里几个关键词:

• 不同来源:你公司的 AI 和别人公司的 AI,本来八竿子打不着,现在能对话了。
• 互相发现:一个 AI 能"看到"另一个 AI 会干什么活,就像在通讯录里找到合适的人。
• 安全:对话过程有身份验证和权限控制,不是谁都能随便指挥别人。
• 协作:不只是问一句答一句,而是能把一个大任务拆开、分给不同 AI、再把结果汇总回来。

为什么以前做不到?

在 A2A 出现之前,如果你想让两个 AI 智能体协作,基本只能"手工对接"——程序员得专门为这两个 AI 写一段"翻译代码",让 A 的输出能被 B 看懂。

问题是:如果你有 5 个 AI 要互相配合,排列组合下来就要写一大堆这样的对接代码,而且每次有新 AI 加入,又得重写。这就像一个国际会议上,如果没有统一的工作语言,那 10 个国家的代表就得准备 90 种"两两互译"的翻译方案,乱成一锅粥。

有了 A2A 这套统一标准,所有 AI 只要"会说 A2A 这门语言",就能直接和其他任何"会说 A2A"的 AI 协作,不用再为每一对关系单独写对接代码。新 AI 加入,即插即用。

◆ 它和你常听到的 MCP 是什么关系?

如果你关注 AI,可能听过另一个热词:MCP(模型上下文协议,Model Context Protocol)。很多人会把 A2A 和 MCP 搞混,觉得它们是竞争对手。其实它们俩是好搭档,各管一段。

打个比方,把一个干活的 AI 智能体想象成一名工人:

• MCP 解决的是"工人怎么用工具":让 AI 能去查数据库、调用某个软件接口、读取一份文档。它连接的是 AI 和工具/数据。
• A2A 解决的是"工人之间怎么协作":让一个 AI 能把活儿派给另一个 AI,大家分工合作。它连接的是 AI 和 AI。

看上面这张图就很清楚了:

• 横向的箭头(A2A)负责让两个智能体之间通话、协作。
• 每个智能体内部那些向下的箭头(MCP)负责让智能体去操作各种工具。

官方的说法也是如此:A2A 是 MCP 的补充,而不是替代。 一个成熟的 AI 应用,往往是 A2A 和 MCP 一起用——智能体用 MCP 干自己的活,用 A2A 和同伴沟通协作。

一句话记住:MCP 管"AI 和工具",A2A 管"AI 和 AI"。

◆ A2A 是怎么运作的?核心概念拆解

理解 A2A,只需要搞懂几个核心概念。我们继续用"找人办事"的比喻来讲,这样最容易懂。

1. Agent Card(智能体名片)——"你会干什么活?"

每个支持 A2A 的智能体,都会公开一张"名片",官方叫 Agent Card。

这张名片是一份结构化的文件(技术上是一个 JSON 文件),通常放在一个固定的地址,比如网站的 /.well-known/agent.json 路径下——就像每家公司都把"业务介绍"挂在官网的固定位置,谁想找你合作,去那儿看一眼就知道你能干嘛。

名片上一般写着:

• 我是谁:智能体的名字、提供方、简介。
• 我会干什么:具体的技能(Skill)列表,比如"翻译""订机票""做数据分析"。
• 怎么找我:服务地址(URL)。
• 怎么跟我打交道:支持哪些通信方式、需要什么身份验证。

有了名片机制,智能体之间就能互相发现彼此的能力——这是协作的第一步。就像你要找翻译,先翻通讯录看谁会外语。

2. Task(任务)——"这件事交给你了"

当一个智能体决定让另一个智能体帮忙时,它会发起一个 Task(任务)。

Task 是 A2A 里最核心的工作单元,代表"一件需要被完成的事"。它有自己的唯一编号和状态,就像你网购时的一个订单号,你能随时查它到了哪一步:

• submitted(已提交):任务刚发出去。
• working(处理中):对方正在干。
• input-required(需要补充信息):对方卡住了,反过来问你要点东西,比如"请问出发城市是哪?"
• completed(已完成):干完了,结果给你。
• failed / canceled(失败 / 取消):出岔子了或被取消。

这个"任务有状态、可追踪"的设计非常重要。因为 AI 干的活有的几秒就完事,有的(比如"分析一整年的财报")可能要跑好几分钟甚至更久。有了状态机制,发起方就能随时知道进度,而不是傻等着或者干脆失联。

3. Message(消息)与 Part(片段)——"我们具体聊点啥"

智能体之间一来一回的沟通内容,装在 Message(消息) 里。一次任务过程中,双方可能要互相发好几条消息(比如对方问你要信息、你回复)。

而每条消息又由一个或多个 Part(片段) 组成。Part 是内容的最小单位,它聪明的地方在于:内容不止是文字。Part 可以是:

• 文本片段:普通的文字,比如"帮我订一张明天去上海的机票"。
• 文件片段:一张图片、一个 PDF、一段音频。
• 数据片段:结构化的数据,比如一段表格或 JSON。

这样设计的好处是:智能体之间不仅能"打字聊天",还能直接传文件、传数据,像同事之间发微信一样自然——发段文字、甩个附件、再贴张表,一条消息全搞定。

4. Artifact(成果物)——"活干完了,这是交付物"

任务完成后,干活的智能体会产出 Artifact(成果物)——也就是最终的交付结果。

Artifact 和 Message 的区别在于:Message 是过程中的沟通(像聊天记录),Artifact 是最终的产出(像交付的成品)。比如你让一个智能体写报告,中间它和你确认需求的对话是 Message,最后交给你的那份 PDF 报告就是 Artifact。

Artifact 同样可以包含文字、文件、数据等多种形式,而且可以分批、流式地传回来——长报告可以写一段传一段,你能边写边看。

把四个概念串起来看

现在我们把 Agent Card、Task、Message、Artifact 这四个核心概念串成一条完整的协作流程:

这就是 A2A 的完整工作闭环:看名片 → 派任务 → 来回沟通(必要时补充信息)→ 交付成果。是不是和你在公司里把活儿交给同事的流程一模一样?

◆ 底层是怎么传数据的?(可以略读)

这一节稍微技术一点,看不懂可以跳过,不影响理解 A2A 的核心思想。

A2A 在设计上很务实,它没有发明全新的技术,而是站在已经被全世界验证过的成熟技术之上:

• 传输靠 HTTP:就是你浏览器打开网页用的那套协议,全世界的服务器都支持。
• 格式用 JSON-RPC 2.0:一种简单标准的"远程喊话"格式,让一个程序能调用另一个程序的功能,数据用 JSON 表示,清晰易读。
• 实时进度靠 SSE(服务器推送事件):当任务要跑很久时,服务端可以像直播弹幕一样,把进度一条一条实时"推"给发起方,不用反复去问"好了没"。
• 超长任务靠推送通知:有些任务可能要跑几个小时,发起方总不能一直挂着等。A2A 支持用"推送通知"的方式,等任务完成后主动通知发起方,就像快递到了给你发条短信。

选择这些成熟技术的好处是:企业现有的系统几乎不用大改就能接入。它们本来就在用 HTTP、用 JSON,现有的网络安全设施(防火墙、身份认证体系)也都能直接复用。这大大降低了大公司采用 A2A 的门槛。

◆ A2A 能用来干什么?几个典型场景

讲了这么多原理,我们来看看 A2A 到底能解决哪些实际问题。

场景一:企业里的"AI 流水线"

设想一家公司的招聘流程,全交给一群 AI 智能体协作完成:

招聘主管智能体像个总指挥,把"筛简历""排面试""做背调"分别派给三个各有所长的专门智能体,最后汇总结果。这些智能体甚至可能来自不同的软件供应商,但因为都讲 A2A,就能无缝配合。

场景二:跨公司、跨平台的服务协作

你对自己手机里的私人助理说:"帮我订下周去三亚的家庭旅行。"

你的私人助理智能体,就可以通过 A2A 去联系航空公司的订票智能体、酒店的预订智能体、租车平台的智能体,分别谈好机票、酒店、用车,再把方案汇总给你确认。这些智能体分属完全不同的公司,但 A2A 让它们能跨越公司边界对话。

场景三:专家智能体的"会诊"

一个复杂问题,可以让多个领域的"专家智能体"一起会诊。比如分析一家上市公司值不值得投资:一个智能体专看财务报表,一个专看行业趋势,一个专看新闻舆情,各自给出判断,最后由一个"主智能体"综合成一份投资建议。术业有专攻,A2A 让专家们能坐到一张桌子上讨论。

◆ 几个常见疑问

问:A2A 会不会让 AI 之间"私下串通",不受控制?

不会。A2A 内置了身份验证和权限机制,一个智能体不是想指挥谁就能指挥谁,得有合法的身份和授权。而且每个任务都有明确的发起方、状态和记录,整个过程是可追踪、可审计的。

问:我的智能体支持了 A2A,是不是就要把内部秘密都公开?

不是。A2A 有一个很重要的设计原则叫"不透明执行"——一个智能体只需要对外公布"我能干什么活"(名片上的技能),但不需要暴露"我内部是怎么干的"。就像你请翻译,你只关心他能不能把中文翻成英文,不需要知道他脑子里怎么转换的。这保护了各家公司的核心技术和数据。

问:A2A 现在成熟了吗?能用了吗?

A2A 还很年轻(2025 年才发布),正处在快速发展期。但它一出生就有 Google 和五十多家大公司背书,又进了 Linux 基金会成为中立的开放标准,生态在迅速壮大。可以把现在的 A2A 理解成"AI 智能体互联网"的早期阶段——就像 90 年代初的互联网,框架已经立住,精彩还在后面。

问:普通人需要懂 A2A 吗?

作为普通用户,你不需要直接和 A2A 打交道,就像你上网不需要懂 HTTP 协议一样。但了解它,能帮你看懂未来 AI 产品的一个大趋势:AI 正在从"一个个孤立的助手",走向"能互相协作的智能体网络"。 未来你的一句话,背后可能是一群 AI 在分工合作地为你办事。

◆ 一张图回顾全文

◆ 一句话总结

A2A 是 Google 牵头、现归 Linux 基金会维护的开放协议,它给所有 AI 智能体定了一套"通用对话语言",让来自不同公司的 AI 能彼此发现能力、分派任务、交流成果,从而协作完成复杂的事。如果说 MCP 让 AI 学会了"用工具",那 A2A 就是让 AI 学会了"找同事搭伙干活"。

AI 的下一站,不是某一个更聪明的超级助手,而是一张会互相协作的智能体网络。而 A2A,正是把这张网络连起来的那根线。

📚 参考来源:A2A 官方文档(a2a-protocol.org)、GitHub 开源项目(a2aproject/A2A,Linux 基金会 / Apache 2.0)、以及多篇 A2A 协议技术解析。文中事实(2025 年 4 月发布、2025 年 6 月捐赠 Linux 基金会、与 MCP 互补、核心概念等)均经多源交叉核实。