A2A协议（Agent2Agent）

A2A 协议（Agent2Agent Protocol，智能体对智能体协议）是一套让不同厂商、不同平台的 AI 智能体互相发现、通信与协作的开放标准。它的目标类似 TCP/IP 之于互联网：当每个企业都有自己的智能体时，需要一层公共协议把它们连成可协作的网络，而不是各自为战。

为什么需要它

智能体生态爆发后，各家的智能体运行在各自的框架与运行时里，彼此无法直接调用。而一个真实任务往往要跨多个专业角色，例如订票、行程编排、支付与报销分别由不同智能体负责。缺少统一协议时，每对接一次就要写一套定制胶水代码，成本高且无法复用。

它解决了什么

• 智能体发现：用标准描述声明自身能力与接入方式，让调用方知道谁能做这件事。
• 能力协商：交换输入输出格式、支持的内容类型与约束条件，减少对接前的反复沟通。
• 任务委托：把子任务交给合适的智能体，并持续跟踪执行状态与进度。
• 结果回传：以统一形式拿回中间产物与最终结果，便于上游整合与展示。

与 MCP 的分工

MCP（Model Context Protocol，模型上下文协议）解决模型与工具、数据源之间的连接，把外部能力标准化地暴露给模型；A2A 解决智能体与智能体之间的协作。两者互补：MCP 给智能体装上手脚，让它能用工具；A2A 给智能体配上同事，让它能分工。同一套系统里通常两者并存，边界在于交互双方是工具还是另一个自主实体。

判断该用哪一个，可以看对方是否会自己做决定。如果对方只是被动执行、返回确定结果，那是工具，走 MCP；如果对方有自己的规划与状态、可能延迟很久才回复甚至反过来提问，那是智能体，走 A2A。

生态与标准竞争

A2A 由 Google 发起并开放，随后获得多家云厂商与平台支持。与此同时，其他厂商也推出各自的智能体互操作方案，接口风格与抽象层次各不相同，标准之争仍在继续。对使用者来说，务实的做法是关注协议是否被主流框架与云平台同时支持，而不是过早押注单一方案。

实践要点

• 先梳理任务边界：明确哪些子任务值得拆出去交给独立智能体，避免为拆而拆。
• 把能力描述写清楚：输入格式、输出格式、失败语义与超时约定越明确，跨团队对接越顺。
• 设计幂等与重试：远程调用会超时或重复，任务需要可以安全重放。
• 保留可观测性：链路跨越多个智能体后，必须能按任务号追踪每一步的输入输出与耗时。

常见误区

• 把它当成模型协议：A2A 不规定模型如何推理，只管智能体之间的交互契约。
• 以为接上协议就能自动协作：语义对齐、权限控制与计费规则仍需业务层另行约定。
• 忽视安全边界：跨组织调用涉及身份认证与授权，不能默认互相信任。
• 过早追求全自动化：多智能体链路越长越难排错，关键节点保留人工确认更稳。