A2A 协议如何让不同框架的代理跨组织协作：从 Agent Card 发现到双向回调

跨组织的多代理系统面临一个具体约束：两家机构各自构建和运行代理，它们需要发现彼此、交换任务，但不能暴露内部实现，也不能要求双方使用同一框架。没有标准化协议时，每增加一个客户或框架组合，ISV 就要编写一套定制集成代码。A2A 协议试图用单一接口替代这些路径。

AWS 机器学习博客给出的参考架构在两个独立 AWS 账户中运行三个代理。企业侧的编排器基于 LangChain，调用 Anthropic Claude Sonnet 4.6 做推理路由；SaaS 侧的合规代理基于 Strands Agents SDK，部署在 Amazon Bedrock AgentCore 上。两者使用完全不同的框架和 SDK，但通过 A2A 的 JSON-RPC over HTTP 通信。编排器不依赖 Strands SDK，合规代理也不依赖 LangChain——这是协议级互操作的实际含义：只要双方都讲 A2A 并发布兼容的 Agent Card，框架可以各自更换。

Agent Card 是这套机制的核心发现层。它在 /.well-known/agent-card.json 路径发布一份 JSON 文档，描述代理的名称、能力和技能。编排器在启动时拉取这张卡片，为卡片上每个技能创建一个 LangChain 工具，之后由大语言模型根据用户问题决定调用哪个工具。这意味着 ISV 添加或修改能力时，只需更新 Agent Card，编排器下次重启自动获取新技能，两个团队无需协调代码变更。

关键的设计决策在于卡片发布什么。合规代理内部有三个工具（列出账户、执行扫描、获取修复步骤），但 Agent Card 只发布一个策展技能：「扫描你的 AWS 账户，按严重性返回发现项和修复步骤」。调用方的模型看到的是产品做什么，不是怎么做的。这层抽象让 ISV 可以重构内部架构——换模型、换工具、换实现——只要卡片描述的技能不变，客户集成就不受影响。

双向回调是这套方案超出典型代理演示的地方。大多数代理间通信展示的是单向请求-响应：客户端调用服务端代理，等待结果。但当被调用的代理需要只有调用方才有的信息时，这个模式就失效了。在这个架构中，合规代理在扫描前需要企业上下文——哪些账户是生产环境、适用哪些内部策略、向谁升级——这些信息只有企业侧知道。合规代理通过 A2A 回调到企业上下文代理，使用自己账户的身份提供方获取令牌，向客户在入驻时注册的回调地址发送消息。这使两个代理成为真正的对等体，而非客户端和服务端。

认证方面，每个账户有自己的 Amazon Cognito 用户池，双方各自从自己的池获取令牌，接收方只信任对方池发出的令牌。入驻时双方交换的只有公开值——身份提供方 URL、客户端 ID、作用域和端点 URL——不共享任何密钥。每个 A2A 任务请求携带 JWT，接收方验证签发方、客户端和作用域。唯一不需要认证的端点是上下文代理的 Agent Card，因为它只发布描述性元数据。

端到端测试验证了整条链路：编排器发现合规代理、路由请求、合规代理回调上下文代理获取账户元数据、执行扫描、返回包含两个代理数据的富化报告。测试通过的条件是回复中包含合规发现、包含只有上下文代理知道的值班轮换代码，且合作伙伴 API 访问日志记录了回调客户端的 200 响应。随后七项信任边界检查确认每个令牌只在被信任的位置有效，错误、缺失或伪造的令牌均被拒绝。

这套参考实现的适用边界值得注意。它使用合成数据模拟合规发现，未展示生产环境下的延迟、吞吐或故障恢复表现。双向回调模式要求双方各自维护身份提供方配置和回调注册，运维复杂度高于单向调用。博客本身也列出了生产化建议：按客户拆分运行时、用密钥认证替代客户端密钥、启用 PrivateLink 和 KMS 加密、配置 VPC 流日志等。这些说明当前架构是模式验证，不是可直接投产的成品。

对读者的实际意义在于：如果组织正在构建需要跨团队或跨公司协作的代理系统，A2A 的 Agent Card 发现加双向 OAuth 回调提供了一种替代定制集成的路径。它不要求双方使用同一框架，不要求共享密钥，能力扩展通过更新卡片而非修改调用方代码完成。但这条路径的前提是双方都接受协议约束并各自维护身份基础设施——这本身是一项运维承诺。