A2A协议何时真正重要？
内容提要
A2A是用于独立代理间通信的开放标准，但多数多代理系统无需使用。判断标准是代理是否跨越所有权或信任边界。若代理在同一边界内，用MCP和编排框架即可；跨边界时A2A才必要。其安全依赖OAuth和HTTPS，但委托授权仍待完善。MCP连接代理与工具，A2A连接代理间，两者互补。Redis提供底层上下文存储支持。
延伸解读
所有权测试：判断是否需要A2A的关键
文章提出一个核心判断标准：你的代理是否跨越所有权或信任边界。如果所有代理都由你控制且在同一信任域内，使用编排框架和MCP即可，无需A2A。只有当代理由不同团队或供应商独立部署，或处于不同信任区域时，A2A才真正必要。这类似于内部API的设计原则：只有跨真实边界的调用才需要网络协议。
A2A与MCP的分工与重叠
A2A连接代理与代理，MCP连接代理与工具，两者互补。但文章指出，MCP正在增加异步长任务原语，与A2A的任务模型重叠；同时，工具调用也可能隐含代理推理，界限日益模糊。因此，实际部署中应优先用MCP建立工具访问，仅在出现真实边界时引入A2A，避免过度设计。
安全与委托授权的现实挑战
A2A依赖HTTPS和OAuth 2.0，但委托授权仍是短板。当代理将任务委托给另一个代理时，需要限制权限以避免“混淆代理”问题，而A2A本身不实现委托认证，需依赖外部身份提供商。IETF相关草案仍在制定中，团队需自行实现OAuth令牌交换。相比之下，MCP在委托授权上更成熟，这可能是A2A采用率不高的原因之一。
Q&A
A2A协议是什么？它由谁发起并维护？
A2A（Agent-to-Agent）是一个开放标准，用于独立代理之间的通信，支持不同框架、语言或供应商的代理协作。它由Google于2025年4月宣布，并于2025年6月捐赠给Linux基金会，目前由Linux基金会管理，创始成员包括AWS、Google、Microsoft和Salesforce。当前规范版本为1.0.1，发布于2026年5月。
如何判断我的多代理系统是否需要使用A2A协议？
判断标准是代理是否跨越所有权或信任边界。如果所有代理都在同一个信任边界内，由同一团队拥有和控制，那么使用编排框架和MCP即可，无需A2A。只有当代理跨越真实边界（如不同团队、不同部署或不同信任域）时，A2A才变得必要。
A2A协议的安全模型是如何工作的？
A2A的安全模型基于标准Web传输层：生产环境强制使用HTTPS，认证通过外部身份提供商（如OAuth 2.0）完成，服务器必须验证每个请求。Agent Card声明支持的认证方案（如OAuth、API密钥、mTLS），技能可受OAuth作用域保护。版本1.0还引入了签名Agent Card用于加密身份验证。但委托授权（delegation）尚未完全实现，需要依赖外部IdP和OAuth令牌交换。
A2A和MCP有什么区别？它们如何互补？
MCP（Model Context Protocol）连接单个代理与其所需的工具和数据源（如GitHub仓库或SQL数据库），而A2A连接代理之间，使它们能够跨框架协作。两者互补：工具通过MCP访问，独立部署的代理协作通过A2A。MCP的采用率更高（2026年7月月下载量超4亿），且MCP正在增加异步长任务原语，与A2A的任务模型有重叠。
A2A协议的核心原语有哪些？
A2A协议的核心原语包括：Agent Card（描述代理能力）、任务（Task）、消息（Message）、工件（Artifact）和推送通知（Push Notification）。这些原语通过标准Web传输（通常为JSON-RPC 2.0 over HTTP）进行通信，支持长时间运行的任务通过webhook推送更新。
A2A协议在生产环境中的采用情况如何？
截至2026年4月，有超过150个组织公开支持A2A，并报告了跨行业的部署，包括Google、Microsoft和AWS的集成。然而，独立验证生产采用情况很困难，因为许多所谓的“多代理”系统实际上只是单个编排器调用工具，并未跨越信任边界。因此，实际生产使用率尚不明确。
在跨边界场景中，A2A解决了哪些具体问题？
当代理跨越所有权或信任边界时，A2A标准化了代理发现（通过Agent Card）、任务生命周期管理（通过任务原语）和跨框架互操作（通过标准消息格式）。这避免了为每个合作伙伴编写定制集成代码，降低了维护成本。同时，A2A还提供了可观测性支持，尽管跨代理追踪仍具挑战。
A2A协议在委托授权方面存在哪些不足？
A2A协议本身不实现委托授权，而是依赖外部身份提供商（IdP）和OAuth令牌交换。这可能导致“混淆代理”问题，即代理可能继承过多权限。IETF正在制定相关标准（如身份链和委托范围规则），但尚未完成。因此，跨边界团队需要自行实现缩小范围的委托授权。
