如果你在企业里负责 Agent 平台、系统集成或数字化项目，最近可能会遇到一个问题：不同团队、不同厂商做出来的 AI Agent，怎样互相交接任务？A2A 协议就是为这件事出现的。它的全称是 Agent2Agent Protocol，中文常称为 Agent to Agent 协议。简单说，它是一套开放通信标准，让独立构建、可能由不同框架或不同厂商提供的 AI Agent，能够发现彼此的能力、委派任务并交换结果，协作时不需要开放各自的内部提示词、记忆或工具实现。
这篇文章从定义、工作机制、与 MCP 的边界、适用场景和企业接入前的判断几个方面，把 A2A 协议讲清楚。读完你应该能判断，自己的多 Agent 协作场景需不需要 A2A，以及接入时要先看哪些条件。
A2A 协议是什么
用一句话概括，A2A 是一套让 Agent 与 Agent 通信的开放标准。A2A 官方规范给出的定义是，它用于促进独立、可能不透明的 AI Agent 系统之间的通信与互操作。这里的两个关键词值得展开。
独立，意味着两个 Agent 可以由不同团队开发，运行在不同云上，使用不同框架，甚至属于不同公司。不透明，意味着双方不需要把内部推理过程、记忆、工具实现暴露给对方，只按照公开声明的能力和交换的信息完成协作。
A2A 属于 Agent 之间的通信层。 模型负责推理，Agent 框架负责构建和运行，MCP 负责连接工具与数据，A2A 负责让一个 Agent 把任务交给另一个 Agent。支持 A2A 协议的 Agent，在企业语境里常被称为 A2A 智能体。它既可以作为客户端 Agent 发起请求，也可以作为远程 Agent 接收任务。
这里要区分 A2A 和普通 API 调用。普通 API 通常返回结构化数据，调用方需要自己决定怎么使用。A2A 把对方当作一个有状态、能多轮沟通、能自行调用工具和推理的 Agent。 调用方交出的是任务目标和必要上下文，远程 Agent 自己决定怎么完成，最后返回任务产物。这个差别决定了 A2A 更适合处理跨系统、跨组织的复杂任务，而不是一次性的数据查询。
为什么多 Agent 协作需要 A2A
企业里常见的 Agent 建设路径是先解决单点问题。客服团队做一个客服 Agent，财务团队做一个报销 Agent，供应链团队做一个询价 Agent。单点运行没问题，一旦要让它们共同完成一个跨部门任务，集成成本就上来了。
过去的做法通常是点对点开发。A 系统对接 B 系统，B 系统再对接 C 系统，每多一个 Agent，就多一套接口、认证、字段映射和异常处理。另一种做法是把远程 Agent 包装成工具，由主 Agent 按固定参数调用。这种做法能解决一部分问题，但会丢掉 Agent 的多轮沟通、状态保持和自主决策能力。
A2A 想解决的是这一层重复集成。 它提供一套共同的交互模型，让 Agent 先声明自己能做什么，再按任务需要发起协作。对不同厂商和不同框架来说，这减少了为每个组合单独开发适配器的需要，也让企业更容易替换或新增 Agent。
从治理角度看，A2A 还把跨 Agent 协作中的任务状态、上下文和产物变成可描述的对象，方便后续做权限控制、审计和效果分析。这一点对企业级项目很重要，因为多 Agent 协作进入生产环境后，能不能定位问题、能不能追责、能不能控制成本，往往比能不能跑通更关键。
把时间线拉出来，A2A 的治理路径比较清晰。2025 年 4 月，Google 发布 A2A 协议，并联合多家技术合作伙伴推进。2025 年 6 月 23 日，Linux 基金会宣布启动 Agent2Agent 项目，Google 把协议规范、SDK 和开发者工具迁移过去，当时已有 100 多家企业支持。2026 年 3 月 12 日，A2A 1.0.0 发布，协议进入稳定版本阶段。 2026 年 8 月 17 日，A2A 转入 Linux 基金会旗下的 Agentic AI Foundation，与 MCP 等项目放在同一个基金会下治理。截至 2026 年 11 月，官方规范已进入 1.0 系列，企业评估时可以直接以 1.0 为基线。
A2A 如何工作
A2A 的交互可以拆成四个核心对象：Agent Card、Message、Task 和 Artifact。理解这四个对象，基本就能看懂 A2A 的运行方式。
Agent Card 是远程 Agent 的名片，通常是一个 JSON 文档，放在 https://{agent-server-domain}/.well-known/agent-card.json。它描述 Agent 的名称、提供方、服务地址、支持的协议能力、认证方式，以及一组可调用的技能。客户端 Agent 读取这张名片，判断对方能不能完成任务，再决定要不要发起请求。
Message 是一轮通信，包含角色和内容。内容可以是一段文本、一个文件引用，或者结构化数据。Task 是有状态的工作单元，有唯一 ID，会经历提交、处理中、需要补充输入、需要授权、完成、失败、取消等状态。远程 Agent 在执行过程中可以暂停并向客户端提问，这让 A2A 能处理多轮任务，而不是一次请求一次响应。
Artifact 是任务产生的输出，例如报告、图片、表格或一段 JSON 数据。它和对话消息分开返回，方便客户端把结果交给后续流程。A2A 还定义了流式传输和推送通知。长任务可以通过 Server-Sent Events 持续回传状态，也可以在任务完成时通过 Webhook 通知客户端。对于需要几分钟甚至几小时的任务，这比一直保持连接更现实。
在协议绑定上，A2A 1.0 支持 JSON-RPC 2.0、gRPC 和 HTTP+JSON。企业可以沿用现有的网关、负载均衡、认证和监控体系来接入，不需要为 Agent 通信单独造一套基础设施。1.0 版本还加入了多租户、签名 Agent Card 和版本协商等能力，目的是让跨组织协作更容易通过安全与合规审查。
图：A2A 的典型协作流程。客户端 Agent 发起任务并读取 Agent Card，发送 Message 后由远程 Agent 执行 Task，最后把 Artifact 返回客户端。
A2A 与 MCP 的边界
讨论 A2A 时，MCP 协议经常被一起提到。两者都解决 Agent 生态的连接问题，但连接的对象不同。
MCP 主要解决 Agent 与工具、数据源之间的连接。它把数据库、API、文件系统等能力描述成工具，让 Agent 按需调用。A2A 主要解决 Agent 与 Agent 之间的连接。它让一个 Agent 把任务委派给另一个 Agent，由对方自己推理、调用工具并返回结果。
可以用一个简单的分工来理解。一个客服 Agent 接到用户的账单争议，需要查询账单系统。它通过 MCP 调用账单数据库，拿到这笔订单的记录。如果争议需要人工复核，它可以通过 A2A 把任务转给计费团队自己的 Agent，带上对话上下文和已查到的记录。计费 Agent 在自己的权限范围内继续处理，最后把结论返回给客服 Agent。
| 对比维度 | MCP | A2A |
|---|---|---|
| 连接对象 | Agent 与工具、数据源 | Agent 与 Agent |
| 交互特征 | 结构化、相对无状态，通常是一次工具调用 | 有状态、多轮，可委派完整任务 |
| 能力发现 | 工具清单或服务描述 | Agent Card |
| 典型场景 | 查数据库、调用 API、读取文件 | 跨团队、跨厂商、跨组织的任务协作 |
| 关系 | 可以同时使用 | 可以同时使用 |
MCP 让单个 Agent 更有深度，A2A 让多个 Agent 之间的协作更有广度。企业做多 Agent 系统时，两者经常同时出现。一个 Agent 对外通过 A2A 接任务，对内通过 MCP 调工具，这样的组合并不矛盾。
哪些场景适合 A2A
判断一个场景要不要用 A2A，可以看四个信号。对方是不是一个独立的 Agent，是否运行在不同平台或不同组织，任务是否需要多轮沟通，任务是否可能持续较长时间。四个信号越齐全，A2A 的价值越明显。
几个典型场景。
- 跨企业供应链协作。采购方的 Agent 向供应商的 Agent 询价、确认库存和交期，双方不需要开放内部报价模型和库存系统。
- 客户服务升级。一线客服 Agent 把复杂问题转给计费、物流或售后 Agent，交接时保留用户上下文和历史处理记录。
- 出行与本地服务。主助手协调航班、酒店、当地游等多个专业 Agent，最后把结果整合成一份行程。
- 招聘与金融服务。多个专业 Agent 分别处理简历筛选、背景核验、风险评估，整个链路需要权限隔离和审计。
也有不适合的情况。只是查询一个数据库、调用一个固定 API，用普通接口或 MCP 更直接。单个 Agent 内部的步骤编排，用 Agent 框架自带的工作流能力就够了。需要精确控制每一次工具调用和返回结果时，MCP 更合适。对方只是一个服务，没有自主推理和任务执行能力，也不需要套 A2A。
当你要把一件完整的任务交给另一个有自主能力的 Agent，并且希望保留多轮沟通、状态和结果交接时，A2A 才有明显价值。
企业接入前要判断什么
A2A 协议本身不复杂，难的是把它放进企业的 Agent 治理、数据和运维体系。接入前可以先看五个问题。
第一，版本和绑定是否匹配。对方支持 1.0 吗，使用 JSON-RPC、gRPC 还是 HTTP+JSON，是否支持流式传输和推送通知。版本不一致时，需要确认兼容策略。
第二，身份和授权是否清楚。Agent Card 是否签名，调用方如何认证，权限范围有多大，令牌如何过期和回收。跨组织协作时，身份验证和授权链路要比内部系统更严格。
第三，数据边界是否可控。哪些数据可以传给外部 Agent，是否需要脱敏，任务产物存在哪里，保留多久。A2A 不要求开放内部实现，但任务消息和产物仍然可能包含敏感信息。
第四，任务治理是否完整。长任务如何设置超时和重试，失败后谁来接管，哪些动作需要人工审批，取消任务后如何清理资源。这些规则要在接入前定好，不能等生产环境出问题再补。
第五，可观测和成本是否跟得上。建议为跨 Agent 的任务建立统一的 trace，能看清请求经过了哪些 Agent、在哪一步失败、消耗了多少 Token 和调用次数。没有这层观测，多 Agent 协作很难持续优化。
ThinkingAI 在企业级 Agent 平台的实践中，把 A2A 通信与任务协作放进 Agent 底座。HMAF 2.0 提供意图与 Skill 化、Agent Framework Kit 以及 A2A 通信与任务协作等能力，Agentic Engine 支持企业创建和管理多个 Agent，实现多 Agent 协作。目前 ThinkingAI 已服务全球超过 1500 家企业，接入产品超过 8000 款。接入 A2A 的重点，是把跨 Agent 的任务边界、权限和观测接进现有治理体系，减少重复建设。
常见问题
A2A 协议是 Google 的吗？
A2A 由 Google 在 2025 年 4 月发起。2025 年 6 月，Google 把协议规范、SDK 和工具迁移到 Linux 基金会下的 Agent2Agent 项目。2026 年 8 月，A2A 又转入 Linux 基金会旗下的 Agentic AI Foundation。现在它由中立基金会治理，不属于某一家厂商。
A2A 会取代 MCP 吗？
不会。MCP 连接 Agent 与工具、数据源，A2A 连接 Agent 与 Agent。两者解决不同层面的问题，可以同时使用。一个 Agent 可以对外用 A2A 接任务，对内用 MCP 调工具。
A2A 只能跨公司使用吗？
A2A 也适用于同一家公司内部的不同团队、不同平台和不同框架。跨组织协作是它价值比较明显的场景之一。内部使用时，身份、权限和审计同样需要设计。
A2A 协议安全吗？
A2A 复用 HTTPS、OAuth 2.0 等 Web 安全机制，1.0 版本支持签名 Agent Card，并对多租户场景做了支持。协议提供了安全协作的基础，企业仍然需要自己做身份、权限、数据脱敏和审计。跨组织场景下，建议先用低风险任务做小范围验证。
企业现在就要接入 A2A 吗？
看场景。如果企业已经有多个 Agent，并且需要跨团队、跨平台或跨组织交接任务，可以开始评估 A2A。如果当前只是单个 Agent 调用工具和数据库，先把 MCP 和内部工作流做好，收益更直接。接入时优先选择边界清楚、结果可验证、失败可回滚的任务做试点。
