跨 Agent 协作过去很容易停留在演示层：一个 Agent 叫另一个 Agent 做事，看起来很热闹，但真正落到企业系统里，就会遇到身份、权限、状态、结果格式和责任边界的问题。Google 的 Agent2Agent 协议，也就是 A2A，值得关注的原因就在这里。
这篇可以和站内的 SAP Joule Agents、IBM watsonx Orchestrate 控制平面、ServiceNow AI Control Tower 放在一起看。它们都在把 Agent 从单点助手推向可治理的协作网络。
事实梳理
Google 在 2025 年 4 月发布 A2A 时，把它定位为开放的 Agent 互操作协议，强调不同供应商、不同框架构建的 Agent 可以通过标准方式沟通、交换信息并协调动作。官方说明里提到，A2A 和 MCP 是互补关系：MCP 更偏工具和上下文，A2A 更偏 Agent 之间协作。
随后 Linux Foundation 在 2025 年 6 月宣布 A2A 项目，强调开放治理和厂商中立。Google Cloud 又在 2025 年 7 月介绍 0.3 版本，提到更稳定的接口、gRPC 支持、安全卡签名、Python SDK 客户端能力扩展，以及在 ADK、Agent Engine、Cloud Run、GKE、Agentspace 和评估服务中的配套支持。
影响分析
A2A 的信号意义，不只是“又多了一个协议”。它把跨 Agent 协作拆成更具体的工程问题：Agent 如何声明能力，任务状态如何同步，长任务如何保持进度，结果 artifact 如何交付，安全身份如何校验，用户界面能力如何协商。
这些问题一旦标准化，企业就可以少一点一次性集成，多一点可替换、可评估、可治理的 Agent 组合。它也会让 Agent 市场、行业 Agent 和内部 Agent 之间有更清晰的连接方式。
老达点评
我更关注 A2A 把“协作”变成接口这件事。多 Agent 系统最怕的是口头承诺式集成：A Agent 说自己会叫 B Agent，但没人知道 B 的能力范围、任务状态和失败边界。协议不一定解决所有问题，但至少把讨论对象从概念拉回到字段、状态和权限。
对小团队来说，现在不必急着追每个协议细节。更实际的是先把自己的 Agent 做到可描述、可调用、可审计。也就是接上 运行日志、最小权限 和 回放测试。
总结
Google A2A 的发布、开放治理和 0.3 升级，说明跨 Agent 协作正在从概念演示走向接口、生态和治理。未来真正有价值的 Agent，不只要会完成单个任务，还要能在清楚边界下和其他 Agent 协同。
