AWS 提出「代理覆盖层」，让传统 REST 服务接入 A2A 协议

AWS 机器学习博客近日发布与外部作者合作的技术文章，提出「agentic overlay（代理覆盖层）」架构方案，旨在帮助企业在不重写现有 REST 服务的前提下，将其接入新兴的 Agent-to-Agent（A2A）通信协议与 Model Context Protocol（MCP）工具生态。文章同时提供了参考架构与示例代码。

背景：REST 与 A2A 的范式差异

长期以来，企业架构以 REST API 与微服务为核心，胜在稳定、易测试、生产环境深度集成。然而这类接口最初并非为 A2A 通信而设计——A2A 是面向自治代理协作的新兴标准，代理之间通过结构化消息（如 JSON-RPC）发现彼此、协商能力并协调多步任务。在缺乏统一代理协议的时期，许多企业将代理实现为 REST 风格的专有服务。如今随着 A2A 标准化推进，如何让这些「非 A2A 原生」的代理融入新框架，成为新的迁移难题。

两者的核心差异可以概括为：

• REST 面向确定性、客户端驱动的请求-响应流程，HTTP 语义清晰，适合暴露 CRUD 类业务能力。
• A2A 面向推理驱动的协调，强调任务消息、能力协商与跨服务组合调用。

正因为二者基于正交互斥的范式，企业很难直接将现有服务搬到标准化代理通信体系中。

现有迁移路径的痛点

文章讨论了几种常见但代价较高的做法：

• 维护两套并行接口（如 /api/v2/... 与 /a2a/...），导致鉴权、校验、错误映射、部署流水线、可观测性全部翻倍，且容易出现同一操作在两条路径下行为不一致的风险。
• 重构共享业务逻辑，将 REST 端点抽离到共享服务层。即使外部路径不变，重构也可能引入回归与行为漂移，测试负担显著增加。

无论是「双栈并行」还是「共享逻辑重构」，都意味着额外的运维复杂度与成本，构成企业采纳 AI 代理能力的现实障碍。

核心方案：Agentic Overlay

作者提出的核心思路是引入一层「代理覆盖层」——它是包裹在现有 REST 服务之上的薄包装层，负责在代理消息与 REST 负载之间双向转换，并将 REST 端点暴露为代理任务或 MCP 工具。文章特别强调一个关键认知：

A2A 不是一套新 API，而是对已有 API 的新接口形态。

这意味着底层 REST 服务保持不变，业务逻辑无需重写，部署架构也无需并行。文章展示了在应用内部新增 /a2a/... 端点的实现路径，使 REST 控制器（如 Flask 中的 @app.route）能够同时服务于传统调用与代理调用。

价值与适用场景

Agentic overlay 的最大价值在于「复用而非重建」：

• 避免代码重复与并行基础设施，降低代理蔓延（agent sprawl）风险。
• 让企业渐进式引入 A2A 与 MCP，保留原有 REST 投资。
• 通过标准协议让遗留服务参与到多代理协作中，支持任务委派与组合编排。

文章以参考架构图与对比图示说明了不同方案在复杂度、风险与一致性方面的取舍，并指出该模式同样适用于将 REST 端点包装为 MCP 工具，从而在更广泛的代理生态中复用既有能力。对于正在评估如何把遗留系统纳入 AI 代理体系的企业架构师而言，这是一种务实、可落地的过渡路径。