2026 年 8 月 17 日，Agentic AI Foundation 宣布 Agent2Agent，也就是 A2A，作为托管项目加入 AAIF。这个新闻看起来像开源治理圈的常规项目流转，但对 agent 开发者来说，它标志着一个更重要的变化：agent 协议栈正在从“各家 demo 都有自己的接口”进入“中立组织托管、分层标准协作”的阶段。
今天的 agent 生态已经不缺框架。LangGraph、AutoGen、CrewAI、Semantic Kernel、Google ADK、OpenAI Agents SDK、各种公司内部 harness，都能编排工具、记忆、计划和多 agent 角色。真正的问题是：当一个 agent 要调用另一个团队、另一个供应商、另一个权限域里的 agent 时，双方如何发现能力、表达任务、交换上下文、处理失败、记录审计？
A2A 的定位正好在这个位置。AAIF 官方介绍里把它描述为 agent 之间通信、协作、任务交换和能力发现的开放协议。它不是另一个 agent 框架，也不是另一个 prompt 模板库，而是尝试定义跨平台 agent 如何互相工作。
协议栈的四层
现在可以把开放 agent 协议栈粗略分成四层。
第一层是仓库约定，例如 AGENTS.md。它告诉 coding agent 在某个代码库里如何构建、测试、提交、遵守风格和安全边界。它服务的是“agent 进入一个工作空间之后该怎么做”。
第二层是工具连接，例如 MCP。MCP 解决的是模型应用如何发现工具、读取资源、调用外部能力。它把原本散落在插件、函数调用、私有 API wrapper 里的连接方式统一起来。
第三层是 agent 对 agent，例如 A2A。它解决的是一个 agent 如何发现另一个 agent 的能力，如何委托任务，如何交换工作状态，如何协同完成跨系统流程。
第四层是流量治理，例如 agentgateway。它关注身份、路由、授权、观测、限流、审计和跨协议代理。没有这一层，协议越开放，风险扩散越快。
这四层不是线性替代关系。一个企业级工作流可能同时使用它们：代码仓库里有 AGENTS.md，agent 通过 MCP 访问 Jira 和 GitHub，通过 A2A 委托财务 agent 生成报价，再由 agentgateway 统一记录调用和授权。
为什么中立治理重要
协议在早期往往由单一厂商推动，这并不奇怪。厂商有产品压力、客户场景和工程资源，能把抽象协议快速拉成可运行实现。但一旦协议承担跨供应商基础设施角色，治理就变得重要。
企业最担心的不是协议今天能不能跑，而是三年后会不会被某家云厂商绑定，会不会突然改变许可证，会不会被产品路线绑架，会不会只优先支持某个框架。AAIF 作为 Linux Foundation 下的中立组织，至少提供了一个更清晰的治理场所：商标、规范、贡献流程、兼容性讨论和项目路线不再完全依赖单一公司。
这不会自动让 A2A 成熟，但会降低采用者的战略焦虑。很多企业在开放标准上的决策逻辑很现实：技术可以有缺陷，只要治理可预期，就能试点；技术再漂亮，如果治理不稳定，也很难进核心系统。
A2A 和 MCP 的边界
开发者最容易问：既然有 MCP，为什么还需要 A2A？
答案在通信对象不同。MCP 的典型关系是 agent 或 LLM 应用连接工具和数据源。比如一个 coding agent 通过 MCP 调用 GitHub、数据库、浏览器、文档系统。工具本身通常不拥有长期目标，也不主动协商任务。
A2A 的对象是 agent。另一个 agent 可能有自己的模型、工具、权限、记忆、任务队列和审批流程。你不是调用一个简单函数，而是在委托一个具备自主工作流的系统。
举个企业例子。销售 agent 收到客户需求，需要技术可行性、法律条款和报价。它可以通过 MCP 查询 CRM 数据，但技术评估可能要委托给工程 agent，法律条款要委托给法务 agent，报价要委托给财务 agent。这些 agent 背后有不同 owner 和权限。A2A 关心的是这类委托关系。
如果把所有 agent 都包装成 MCP tool，短期也能跑，但会丢掉很多语义：任务生命周期、部分进度、异步结果、能力声明、责任边界、拒绝理由、跨 agent 审计。这正是 A2A 试图补的层。
生产落地的真正难点
协议定义消息格式只是第一步，生产难点在边界。
身份是第一关。一个 agent 代表谁？代表某个用户、某个服务账号、某个团队，还是某个自动化系统？如果销售 agent 调用财务 agent，财务 agent 应该按销售本人权限、销售 agent 权限，还是某个系统权限执行？
授权是第二关。能力发现不等于能力可用。一个 agent 可以公开“我能生成报价”，但不同调用方应该看到不同参数、不同上限和不同审批要求。
数据最小化是第三关。跨 agent 委托时，最简单的做法是把完整上下文都发过去。这也是最危险的做法。协议层应支持只传任务必要片段，网关层应记录实际流出的字段类别。
失败语义是第四关。人类协作里，拒绝、部分完成、需要补充信息、等待审批、超时、撤销都很常见。agent 协议如果只有 success 和 error，会迫使业务在 prompt 里塞流程状态。
审计是第五关。跨 agent 调用必须能回答：谁发起，哪个 agent 接收，使用什么能力，传了哪些数据类别，产生什么输出，是否触发工具，是否有人审批。
不要把协议当编排器
A2A 加入 AAIF 后，市场上很容易出现一个误读：既然有开放协议，就可以把多 agent 编排交给协议本身。这个判断太粗。
协议负责共同语言，编排器负责策略。A2A 可以让 agent 发现和委托，但什么时候委托、委托给谁、失败如何重试、预算如何控制、结果如何合并，仍然是应用架构问题。MCP 也是一样：它让工具可调用，但不决定工具是否应该被调用。
这一区分对生产系统很关键。否则团队会把“接入协议”误认为“完成治理”，最后只是把点对点混乱升级成协议化混乱。
推荐架构
一个保守的企业架构可以这样设计。
user intent
-> primary agent
-> policy router
-> agentgateway
-> A2A remote agents
-> MCP tools and data
-> audit log and eval replayprimary agent 负责理解用户目标和产出最终回复。policy router 根据任务类型、权限、预算和风险选择是否委托。agentgateway 做身份、限流、日志、协议转换和策略执行。远端 agent 通过 A2A 暴露能力。每个 agent 内部再通过 MCP 访问工具和数据。
这样做的好处是职责清晰。A2A 不直接暴露到所有内部工具；MCP 不承担跨 agent 协作语义；网关不写业务推理；primary agent 不绕过策略层。
开发者现在该做什么
第一，整理你的 agent 能力清单。哪些能力只是工具调用，哪些能力是真正的可委托 agent。不要把所有函数都升级成 agent。
第二，定义 agent card 或能力描述的最小字段：能力名、输入 schema、输出 schema、权限要求、数据分类、SLA、owner、失败类型。
第三，把跨 agent 调用放进网关。即使只是内部试点，也要记录 caller、callee、task id、数据类别和结果状态。
第四，准备 replay 集。协议升级或 agent 替换后，用相同任务重放，比较输出、调用链、成本和失败模式。
第五，限制自动链式委托。一个 agent 调另一个 agent，另一个 agent 再继续调第三个 agent，成本和权限都会失控。至少在早期设置最大委托深度。
结论
A2A 加入 AAIF 的价值，不在于宣布“agent 互联时代已经完成”，而在于把互联这件事放进更可治理的开放协议栈。MCP、A2A、AGENTS.md、agentgateway 这些项目开始形成分层关系：工作空间约定、工具连接、agent 协作、流量治理。
对开发者来说，正确姿势是试点而不是追捧。把 A2A 用在跨团队、跨厂商、跨权限边界的真实协作点上，同时保留网关、审计、数据最小化和失败回退。协议让互操作成为可能，工程纪律决定它是否可上线。
参考来源：A2A joins AAIF、Agent2Agent project、Google A2A announcement、OpenAI co-founds AAIF。