A2A = Agent-to-Agent，智能体与智能体通信协议

简单一句话：
多个大模型智能体（Agent）之间标准化互相对话、调用任务、交换信息的通用协议，相当于 AI 智能体界的「互联网 TCP/IP」。
区分易混概念：

• LLM API：人 / 程序 → 单个大模型（单向调用）
• MCP：客户端 ↔ 模型（本地工具协议）
• A2A：Agent ↔ Agent（对等双向协作）

一、诞生背景

现在各家都在做独立 Agent：谷歌 Agent、OpenAI Agent、自研业务 Agent。
痛点：

• 甲 Agent 想委托乙 Agent 完成任务，没有统一标准。每家通信格式、鉴权、能力描述不一样，互通要单独写对接代码，孤岛严重。
• Google 最先公开推出 A2A 规范（Agent to Agent Protocol），目标实现：任意两个合规 Agent，无需定制开发就能互相协作。

二、核心设计思想：对等网络

A2A 里没有严格的客户端 / 服务器上下级，双方都是 Agent，互为对等节点：

1. Agent A 可以向 Agent B 发起任务请求
2. Agent B 可以接受、拒绝、分步执行、返回流式结果
3. 执行中双方可持续来回对话（多轮上下文）
4. B 还可以反过来，请求 A 协助完成子任务

典型场景示例：

• 用户：帮我规划河南周末旅游，顺便订餐厅
• 用户 Agent（A）→ 通过 A2A 联系旅游 Agent（B）
• 旅游 Agent（B）算出行方案 → 发现需要查询餐馆
• B 通过 A2A 主动呼叫餐饮 Agent（C）
• 多方协同完成整套任务

三、A2A 关键能力特性

能力广告（Capability Advertisement）

每个 Agent 对外声明自己能干什么（结构化元数据）：

• 我支持：行程规划、查票价；支持流式输出；支持长任务；接受哪些参数
• 其他 Agent 发现后，自动判断能不能找它干活。

结构化任务会话（Task Sessions）

一次协作建立一个会话，保存上下文，支持：

• 一次性请求
• 长时运行任务（耗时几分钟 / 几小时的复杂工作流）
• 流式增量返回结果（像打字实时推送）
• 中途暂停、取消、更新任务需求

消息标准格式

统一 JSON 消息规范，包含：

• 消息类型：任务发起、进展推送、结果返回、错误、追问
• 上下文 ID、会话 ID
• 权限凭证（鉴权、安全隔离）
• 内容：文本、文件、工具调用请求

安全模型

• 身份认证（Agent 身份校验）
• 权限控制：限定对方能调用哪些功能
• 消息加密、防止中间人、消息签名

四、A2A 和 Function Calling / MCP 区别（重中之重）

Function Calling

大模型 → 调用传统程序接口（工具）
工具是被动的，不会主动提问、无法独立思考，只能执行单一函数。

MCP（Model Context Protocol）

应用程序 ↔ 本地 / 远程模型
目的：给 LLM 提供本地文件、数据库等工具；一端是模型，一端是工具主机，不是智能体之间互通。

A2A

Agent ↔ Agent
两端都是具备独立推理能力的智能体，可以自主思考、多轮互问、任务转包。
形象类比：

• Function Calling = 你给自助售货机按按钮
• MCP = 电脑程序调用本地硬盘文件
• A2A = 两个专业顾问互相打电话协作解决问题

五、现实落地场景

1. 企业内部多 Agent 分工
   客服 Agent、订单 Agent、财务 Agent 互相协作，不用人工串联。
2. 跨厂商 AI 互通
   你的自研 Agent 可以直接调用谷歌、Anthropic 对外提供的专业 Agent 服务。
3. 复杂 AI 工作流（Agent 集群）
   研究 Agent 负责查资料，分析 Agent 负责整理，写作 Agent 负责成文，自动分工。
4. 分布式物联网 AI
   边缘端 Agent 和云端 Agent 互相协同。

六、常见误区澄清

1. 误区 1：A2A 是一个大模型
   正解：只是通信协议标准，任何开发者都可以实现，不绑定谷歌。
2. 误区 2：A2A 替代 API
   正解：A2A 建立在 HTTP/WebSocket 等网络基础之上，是更高一层的业务协议，兼容现有网络架构。
3. 误区 3：A2A 等同于多 Agent 框架（AutoGen、CrewAI）
   正解：
   AutoGen/CrewAI 是单机内多 Agent 调度库；
   A2A 是跨进程、跨机器、跨厂商 Agent 远程互通标准。
   二者可以结合：单机用 CrewAI 编排，跨机器通信走 A2A。