Google A2A协议：Agent间通信新标准

可视化演示

展示Google A2A协议：多Agent(A1-A5)Mesh网络互连，通过Disc（发现）→Neg（协商）→Task（任务分配）→Sec（安全）四层协议栈协作。

诞生背景：AI 世界的“货运孤岛”

在没有万国邮政联盟的年代，纽约的邮局想把包裹寄到深圳，得先跟几十家船运公司、内陆车队挨个签合同，而每家的单据格式还不一样。今天的 AI Agent 世界正是这副景象：一个智能体能写代码，另一个擅长查数据库，第三个长于写报告——可让它们协作完成“先查数据、再写报告”的活儿，工程师得手工写大量胶水代码把各家拼在一起，接口一多就变成蜘蛛网。

Google 在 2025 年 4 月发布 A2A（Agent2Agent）协议，目的就是拆掉这些“货运孤岛”。A2A 是一套开放、厂商中立的通信标准，让不同框架（LangChain、AutoGen、CrewAI 等）开发的智能体能够互相发现、协商并协作完成复杂任务。它的设计出发点很朴素：就像万国邮政联盟让天下快递互联一样，让智能体说同一种“交接语言”。

从成本角度看，没有标准时，N 个智能体两两对接需要写 N(N-1)/2 套定制接口；有了 A2A，每个智能体只需实现一次协议，就能和所有支持它的智能体对话。生态扩张从“平方级痛苦”变成“线性接入”，这正是它能快速获得厂商支持的根本原因。

就像万国邮政联盟一纸协定让天下快递互联，A2A 让智能体第一次有了“通用交接单”，也第一次让“让天下智能体互联”从口号变成工程现实。

设计理念：门口的“营业公示牌”

万国邮政联盟要求每家邮局在门口挂一块公示牌，写明自己开通哪些国际线路、什么时间营业、哪些物品禁寄。别家邮局送货过来，不用打电话反复确认，抬头一看便知能不能把包裹交给你。这种“信息公开”带来的信任与便利，是整个联盟运转的起点。

A2A 的核心设计正是这样一块公示牌，名字叫 Agent Card（智能体卡片）。每个支持 A2A 的智能体都要暴露一个“卡片端点”，返回一份标准 JSON 文档，自报家门：我是谁、能做什么、有哪些技能、任务请求应该发到哪个地址。其他智能体只要 HTTP 请求一下这个端点，就能拿到对方完整的能力画像。

这种“能力自我声明”天然是去中心化的——没有中心注册表，也不需要某个权威机构审核。任何智能体只要知道你的卡片地址，就能读取你的能力并决定是否协作。这相当于每家快递公司自定义营业范围，但用统一格式公示出来，既能百花齐放，又能彼此兼容。

有了这张卡片，两个素不相识的智能体“见面三秒”就能决定是否合作——这正是 A2A 打开生态的第一块基石，也是它区别于传统点对点接口设计的关键创新。

通信机制：统一的“国际运单”

不同国家的快递单据五花八门，填法各异，货到了边境常常要重新录入。万国邮政联盟统一了运单格式：寄件人、收件人、重量、件数，各国邮政一看就懂。A2A 也做了同样的事——把智能体之间的消息格式统一为 JSON-RPC over HTTP(S)。

具体来说，每个请求都是一个标准 JSON 对象，包含协议版本、方法名、参数和请求 ID。方法包括发送任务消息、查询任务状态、取消任务等。响应也遵循同样结构，通过 ID 把应答和请求一一对应起来。

选 HTTP 作为传输层是个很聪明的决定：不引入特殊依赖、不需要长连接，任何能发 HTTP 请求的语言和框架都能接入。用行话说这叫“无状态请求”，服务器不用记住你是谁，每次请求自带完整信息——就像国际运单上写清楚所有字段，运到任何一站都能单独处理。

一张标准运单让任何两国的邮局都能交接，一条标准消息让任何两个框架的智能体都能对话——这就是“标准”二字的分量。

任务协作：可追踪的“包裹旅程”

你寄出一件国际包裹后会拿到运单号，在官网输入就能看到“已收件→运输中→派送中→已签收”。这种全程可见的体验让人安心。A2A 的任务生命周期，就是智能体世界的“包裹追踪系统”。

发起方（client）通过消息任务把“工作包裹”交给处理方（server），任务会经历一组标准状态：已提交（submitted）、处理中（working）、需要更多信息（input-required）、已完成（completed）、失败（failed）。处理方中途发现资料不够，可以回一条“需要更多信息”，发起方补交后再继续——这就是多轮交互。

这种任务导向的设计非常关键：A2A 不是让两个智能体像聊天机器人一样闲聊天，而是围绕一个明确的“待办事项”协作。每个状态都可查询、可恢复，发起方随时可以轮询任务进度，就像查快递物流一样简单。

从交件到签收全程可追踪，是让智能体协作“靠谱”的核心体验——也是企业愿意把真实业务交给多智能体系统的信任前提。

安全信任：实名制与“授权委托书”

万国邮政要求寄件实名、跨国件要报关，贵重物品必须声明价值——信任是包裹能一路通行的保障。同样，A2A 如果只解决了“能连通”而不管“谁能连、能连到什么程度”，就永远进不了企业的大门。因此协议内置了安全层。

A2A 支持基于 OAuth 2.0 的认证与授权。智能体在协作前先验证对方身份，再按任务所需的最小权限范围（scope）放行，而不是把全部能力敞开。比如只让对方调用“查天气”技能，就没必要暴露“读数据库”的能力。

在企业落地时，管理员可以配置哪些外部智能体能访问哪些内部服务，配合审计日志追踪每一次跨 Agent 调用。这相当于给每个包裹贴了“仅限本人签收”的标签，还全程录像。安全设计让 A2A 有底气走进企业防火墙，而不是只停留在技术 demo 阶段。

信任不是一句口号，而是从实名认证到授权管控、再到审计留痕的每一步具体设计，这正是企业级协议与玩具 demo 的分水岭。

与MCP互补：对内管工具，对外搞协作

万国邮政联盟管的是“国家与国家之间的包裹交接”，但包裹到了中国境内，用什么货车、进哪个分拣中心，由国内物流标准决定。两者压根不在一个层级，也从不冲突。A2A 与 MCP 的关系正是如此。

MCP（模型上下文协议）解决的是智能体“内部调用工具”的问题——让大模型连接数据库、API、文件系统，相当于智能体自己的“手和工具”；A2A 解决的是“智能体之间”的问题——让不同的智能体协作，相当于“同事与同事”。一个管内，一个管外，垂直正交。

实际操作中，一个智能体内部用 MCP 调用工具处理数据，同时通过 A2A 把结果“快递”给另一个智能体。两套协议在同一系统里各司其职：MCP 让单个智能体变强，A2A 让一群智能体变协同。理解这个分工，就不会再纠结“谁取代谁”了。

明白了这层分工，你就能在架构图上果断地画两条线：一条横线连同事，一条竖线连工具——清晰、自洽、可落地。

生态与场景：联盟成立之后

万国邮政联盟成立后，全球信件从“几个月运气好能到”缩短到几天。A2A 发布后也迅速聚拢起一个联盟：Google 联合 50 多家生态伙伴（包括 Salesforce、Cisco、LangChain 等）共同支持，并提供了协议开源实现与 Agent Card 开发套件，让开发者半天就能把自家智能体“接入邮路”。

典型应用场景已经清晰成形：企业内混合智能体平台统一调度不同厂商的 Agent；供应链上采购智能体与物流智能体跨公司协作；客服智能体遇到搞不定的专业问题，直接通过 A2A 转派给理赔智能体。这些场景的共同点是“异构、跨域、多轮”，正是 A2A 的主场。

展望未来，A2A 正在迭代多点协作（群体智能）、离线任务和更细粒度安全机制。它不会解决所有问题，但补上了 Agent 互操作性的关键一环——就像联盟成立之后，剩下的就是每个国家把自家邮局装修好、把邮路跑顺了。

联盟的威力不在于单次交接，而在于“每多一家入会，所有人一起变强”的复利效应——这正是 A2A 作为生态基础设施的价值本质。

AI 应用场景

Python 演示

"""A2A 协议核心机制模拟：Agent Card 发现 + 任务交接"""import jsonimport timefrom dataclasses import dataclass, field  @dataclassclass AgentCard:    """Agent 的"挂牌营业"信息：对方只需读这张卡即可对接"""    name: str    skills: list    endpoint: str  @dataclassclass TaskMessage:    """一次任务交接的包裹：带任务号、内容、当前状态"""    task_id: str    payload: dict    status: str = "submitted"  class A2ANode:    """模拟一个支持 A2A 协议的 Agent 节点"""     def __init__(self, card):        self.card = card        self._task_map = {}     def fetch_card(self):        """供其他 Agent 发现本节点的能力"""        return {            "name": self.card.name,            "skills": self.card.skills,            "endpoint": self.card.endpoint,        }     def send_task(self, target, payload):        """A 方把任务包裹交给 B 方"""        msg = TaskMessage(            task_id=f"{self.card.name}-{time.time():.0f}",            payload=payload,        )        target._task_map[msg.task_id] = msg        return msg.task_id     def poll_status(self, target, task_id):        """轮询对方任务状态，模拟 submitted / working / completed 流转"""        msg = target._task_map[task_id]        if msg.status == "submitted":            msg.status = "working"        elif msg.status == "working":            msg.status = "completed"            msg.payload = {"result": f"{target.card.name} 已处理: {msg.payload['data']}"}        return {            "task_id": task_id,            "status": msg.status,            "result": msg.payload.get("result"),        }  if __name__ == "__main__":    # 两个不同"厂商"的 Agent，只靠 A2A 约定就能协作    courier_a = A2ANode(        AgentCard(name="快递A", skills=["揽收", "分拣"], endpoint="http://a.local")    )    courier_b = A2ANode(        AgentCard(name="快递B", skills=["派送", "签收"], endpoint="http://b.local")    )     print("A 方发现 B 方能力:",          json.dumps(courier_b.fetch_card(), ensure_ascii=False))     task_id = courier_a.send_task(courier_b, {"data": "一份合同"})    for _ in range(3):        print("A 方询问:",              json.dumps(courier_a.poll_status(courier_b, task_id),                         ensure_ascii=False))        time.sleep(0.3)

1. def fetch_card(self)模拟 A2A 的“营业公示牌”：返回该 Agent 的名称、技能和端点，供其他智能体发现。
2. def send_task(self, target, payload)模拟发起方把“工作包裹”交给处理方，并生成唯一的任务号（类似运单号）。
3. poll_status模拟发起方轮询任务状态，状态依次从 submitted 流转到 working、completed。
4. @dataclass class AgentCard用数据类定义标准的卡片结构，保证不同“厂商”实现同一套字段。
5. target._task_map[msg.task_id] = msg处理方把收到的任务登记在案，就像邮局给包裹建档。
6. time.time()用时间戳生成任务编号，确保每次任务的 task_id 唯一可追踪。

常见误区

面试题