A2A 协议是什么：让不同 Agent 能发现、通信和协作

A2A，全称 Agent2Agent Protocol。

它关注的不是模型如何调用工具，而是不同 Agent 之间如何发现彼此、交换消息、协同完成任务。

随着企业内部开始部署多个 Agent，一个现实问题会很快出现：销售 Agent、客服 Agent、财务 Agent、法务 Agent、研发 Agent 可能来自不同团队、不同厂商、不同框架。它们不能只在各自系统里工作，还需要互相委派任务、传递上下文、返回结果。

A2A 解决的正是这类 Agent 互操作问题。

核心判断

A2A 的价值不在单个 Agent，而在多 Agent 生态。

当系统里只有一个 Agent 时，A2A 的价值不明显。一个 Agent 自己调用工具、读数据、执行任务，MCP 或普通工具调用已经足够。

但当组织里开始出现多个 Agent，问题会变成：

• 如何知道某个 Agent 能做什么？
• 如何把任务交给另一个 Agent？
• 如何获取任务状态？
• 如何处理长时间运行的任务？
• 如何交换文本、文件、结构化数据等不同类型结果？
• 如何在不同框架和厂商之间协作？

A2A 的定位就是提供一套开放协议，让这些 Agent 能用统一方式互通。

A2A 解决什么问题

1. Agent 能力发现

A2A 引入 Agent Card 的概念。

Agent Card 可以理解为一个 Agent 的能力名片，描述它能做什么、如何连接、支持哪些交互方式。

这很重要。没有能力发现，多 Agent 系统只能靠硬编码：

如果是报销问题，调用财务 Agent
如果是合同问题，调用法务 Agent
如果是客户问题，调用 CRM Agent

硬编码在小系统里能工作，但规模一大就会失控。

Agent Card 的意义在于让 Agent 能被发现、被理解、被选择。

2. Agent 之间标准通信

A2A 基于 HTTP(S)、JSON-RPC、SSE 等已有标准，目标是降低集成成本。

它提供统一的通信方式，让一个 Agent 可以向另一个 Agent 发送任务、消息、上下文和用户指令。

这比每两个 Agent 之间单独写一套 API 更可维护。

3. 支持长任务

很多企业任务不是一次请求就能完成。

例如：

• 招聘 Agent 查找候选人并安排面试。
• 采购 Agent 询价、比价、等待审批。
• 法务 Agent 审合同并等待业务方确认。
• 数据分析 Agent 拉取数据、执行分析、生成报告。
• 研发 Agent 修改代码、跑测试、等待 Review。

这些任务可能持续几分钟、几小时，甚至几天。

A2A 把任务作为核心对象，支持任务生命周期、状态更新、实时反馈和最终 artifact 输出。

4. 支持多模态和不同输出形态

Agent 协作不一定只交换文本。

可能还包括：

• 文件。
• 表格。
• JSON。
• 图片。
• 音频。
• 视频。
• 表单。
• 可嵌入 UI。

A2A 的设计强调 modality agnostic，也就是不把 Agent 协作限制在纯文本上。

A2A 的基本结构

可以把 A2A 简化成以下结构：

Client Agent
  ↓
发现 Remote Agent 的 Agent Card
  ↓
创建 Task
  ↓
交换 Message / Part
  ↓
接收状态更新
  ↓
获得 Artifact

几个核心概念：

工程上，A2A 更像 Agent 之间的任务协作协议，而不是简单聊天协议。

A2A 和 MCP 的区别

A2A 和 MCP 的关系可以这样理解：

MCP：Agent 接工具
A2A：Agent 找 Agent

更完整一点：

两者不是竞争关系。

在真实系统里，常见组合是：

用户请求销售 Agent
  ↓ A2A
销售 Agent 委派财务 Agent 核查回款
  ↓ MCP
财务 Agent 查询 ERP / 发票系统
  ↓ A2A
财务 Agent 返回结果给销售 Agent

A2A 负责 Agent 之间协作，MCP 负责每个 Agent 访问自己的工具和上下文。

典型场景

1. 企业跨部门协作

一个企业内部可能有多个垂直 Agent：

• HR Agent。
• 财务 Agent。
• 法务 Agent。
• IT Agent。
• 销售 Agent。
• 客服 Agent。
• 数据分析 Agent。

用户提出的问题往往跨部门。

例如：

帮我确认这个客户是否可以进入企业合同审批，并安排下周 Demo。

这可能涉及：

• 销售 Agent 查询客户状态。
• 财务 Agent 检查付款和信用。
• 法务 Agent 检查合同模板。
• 日程 Agent 安排会议。

A2A 的价值是让这些 Agent 不必被塞进一个巨大的“万能 Agent”，而是可以各自保持专业边界，通过协议协作。

2. 复杂业务流程自动化

企业流程往往不是单系统操作。

例如采购：

提出采购需求 → 查询供应商 → 获取报价 → 比价 → 合规检查 → 审批 → 下单

每一步都可能由不同 Agent 或系统负责。

A2A 可以让流程中的 Agent 通过任务和状态进行协作，而不是靠一堆脆弱的点对点脚本。

3. 多框架 Agent 互操作

不同团队可能使用不同 Agent 框架：

• LangGraph。
• CrewAI。
• AutoGen。
• Google ADK。
• 自研 Agent Runtime。
• 云厂商 Agent 平台。

如果没有协议，每个框架之间都要写适配层。

A2A 的目标是让这些 Agent 即便底层实现不同，也能用统一协议交互。

4. 长时间运行任务

长任务是 A2A 的重点场景。

例如：

• 深度研究。
• 招聘筛选。
• 代码迁移。
• 合同审查。
• 数据报告生成。
• 客户工单处理。

这些任务需要状态更新、阶段性反馈、人工介入和最终产物。A2A 的任务生命周期设计更适合这种工作。

A2A 的工程价值

1. 避免“超级 Agent”

没有 A2A 时，很多团队会倾向于把所有能力塞进一个 Agent。

这会带来几个问题：

• 提示词越来越长。
• 工具权限越来越大。
• 责任边界不清。
• 调试困难。
• 安全风险集中。
• 不同业务能力难以独立演进。

A2A 提供另一种架构：多个专业 Agent 协作。

每个 Agent 只负责自己的领域，通过协议完成协同。

2. 降低集成成本

Agent 之间如果没有统一协议，集成会变成网状复杂度。

销售 Agent 接财务 Agent
销售 Agent 接法务 Agent
客服 Agent 接财务 Agent
客服 Agent 接工单 Agent
法务 Agent 接合同 Agent

每一对都需要约定接口、认证、状态、错误处理。

A2A 的意义是把这些约定标准化。

3. 支持企业治理

企业不只关心 Agent 能不能协作，还关心：

• 谁调用了谁？
• 调用了什么任务？
• 传递了哪些数据？
• 是否有权限？
• 任务是否完成？
• 结果是否可追踪？
• 人类在哪里介入？

A2A 如果和身份认证、日志、审计、权限系统结合，可以成为企业多 Agent 治理的一部分。

A2A 的边界

A2A 不是让 Agent 自动变可靠的魔法。

它不直接解决：

• 单个 Agent 的推理质量。
• 工具调用安全。
• 数据权限。
• 业务审批。
• 幻觉问题。
• 结果事实校验。
• Agent 是否应该接受任务。

A2A 只是定义 Agent 之间如何通信和协作。至于每个 Agent 的能力、权限、约束和安全策略，仍然需要业务系统设计。

尤其要避免一个误区：

Agent 能互相调用，不代表它们应该互相调用。

企业落地时，Agent 之间的协作关系必须有边界。

安全与治理

A2A 面向企业互操作，因此安全设计不能只放在模型层。

需要考虑：

• Agent 身份认证。
• 调用方授权。
• 任务权限范围。
• 数据最小传递。
• 人类确认节点。
• 审计日志。
• 任务取消和回滚。
• 输出可信度标记。
• 跨系统数据合规。

一个稳妥的设计是把 Agent 调用分级：

多 Agent 系统的问题不是“能不能连起来”，而是“连起来之后如何不失控”。

什么时候需要 A2A

适合引入 A2A 的情况：

• 组织里有多个专业 Agent。
• Agent 来自不同团队或厂商。
• 需要跨系统协作。
• 任务需要长时间运行。
• 需要任务状态和 artifact。
• 需要统一 Agent 发现和调用方式。
• 需要企业级审计和治理。

暂时不需要 A2A 的情况：

• 只有一个 Agent。
• Agent 只是调用工具。
• 任务很短，普通 API 足够。
• Agent 之间没有互操作需求。
• 系统还处在早期原型阶段。

早期项目不必为了架构完整而引入 A2A。

当系统从“单 Agent + 多工具”演进到“多 Agent + 多系统”时，A2A 的价值才会显现。

与现有工作流系统的关系

A2A 不等于工作流引擎。

工作流引擎关心：

• 步骤编排。
• 条件分支。
• 状态机。
• 重试。
• 审批。
• SLA。

A2A 关心：

• Agent 发现。
• Agent 通信。
• 任务委派。
• 状态同步。
• artifact 返回。

两者可以组合。

例如：

工作流引擎决定流程下一步
A2A 负责调用对应 Agent
MCP 负责 Agent 访问工具

在企业场景里，这种分层更合理：

Workflow：管流程
A2A：管 Agent 协作
MCP：管工具和上下文
LLM：管推理和生成

结论

A2A 是 Agent 工程化进入多智能体阶段后需要关注的协议。

它解决的核心问题是：

• Agent 如何被发现。
• Agent 如何互相通信。
• Agent 如何委派和跟踪任务。
• Agent 如何交换结果和 artifact。
• Agent 如何跨框架、跨厂商协作。

如果 MCP 是 Agent 接入外部世界的工具接口，那么 A2A 更像 Agent 之间的协作接口。

对企业落地来说，A2A 的价值不在“让 Agent 互相聊天”，而在“让不同专业 Agent 在清晰边界内协同完成真实业务任务”。

更准确地说：

A2A 不是多 Agent 的全部架构，但它可能成为多 Agent 互操作的关键协议层。

参考：

• Announcing the Agent2Agent Protocol
• A2A GitHub Project
• A2A Protocol Technical Documentation
• Google Gemini Enterprise: Register and manage an A2A agent