改造而非重建：用智慧體覆蓋層改造遺留企業服務

本文表達的觀點僅代表作者個人，而非Cisco的觀點。

長期以來，企業架構一直以REST API和微服務為中心。這些系統穩定、經過充分測試，並深度嵌入生產環境。然而，它們並非為智慧體間通訊（A2A）而設計——A2A是自主智慧體透過結構化訊息進行協作、推理和協調的新興標準。在缺乏通用智慧體協議的情況下，這種架構尚能工作，但如今許多現有智慧體已脫離A2A框架。當前的挑戰不僅是為傳統服務新增A2A能力，還需要將這些基於REST的智慧體融入標準化的智慧體世界。

在AWS與作者的技術合作中，我們提出了一種實用解決方案：智慧體覆蓋層。智慧體覆蓋層是薄包裝層，可將傳統REST服務轉化為能夠參與A2A互動的智慧體，同時將REST API暴露為與模型上下文協議（MCP）相容的工具。結合使用，企業無需重寫業務邏輯、無需複製程式碼、無需執行並行基礎設施，即可為現有REST服務新增A2A能力。透過將現有服務複用為智慧體，減少了基礎設施中的智慧體氾濫。我們提供了參考架構和示例程式碼，展示如何構建智慧體覆蓋層。

背景：REST與A2A

REST API專為確定性的客戶端-伺服器整合設計。客戶端呼叫定義明確的端點、傳遞引數並接收可預測的響應，通常是遵循HTTP語義的無狀態請求-響應流。這使得REST在暴露業務能力（如建立、讀取、更新、刪除）方面表現出色，具有清晰的契約、強相容性和操作簡單性。

A2A專為自主智慧體間的互操作性而設計。智慧體透過後設資料（如智慧體卡片）相互發現，協商能力，並透過結構化訊息（通常透過JSON-RPC）交換資訊以協調多步驟任務。REST最佳化穩定的服務介面和直接執行，而A2A最佳化推理驅動的協調、面向任務的訊息傳遞和智慧體協作。結果是系統能夠跨多個服務進行規劃、委託和組合動作，而非呼叫孤立端點。

向智慧體系統遷移的挑戰

REST API和智慧體系統基於正交正規化，這使得企業難以將現有服務遷移到標準化的智慧體通訊中。然而，企業需要在不進行重大改造的情況下同時使用兩者。儘管透過A2A進行的新式智慧體通訊引入了企業系統的協調模型，但由於需要在現有企業系統旁部署和執行智慧體基礎設施，採用速度受到阻礙。這種並行執行增加了操作複雜性和成本，成為有效採用AI的障礙。

在A2A標準化之前，企業通常將智慧體部署為基於REST或專有服務，將其視為帶有嵌入智慧體邏輯的請求-響應端點。因此，許多現有智慧體並非A2A原生，這產生了新的遷移挑戰：使這些智慧體能夠使用標準化A2A協議進行互操作，同時無需重寫其核心邏輯。

解決方案方法

本節討論為遺留企業系統新增智慧體能力的幾種不同方法，並與使用智慧體覆蓋層的方法進行比較。

維護獨立的REST和A2A棧：一種方法是開發並維護兩條並行的路徑來暴露相同的能力。這意味著兩組端點、兩套認證和驗證實現、兩個部署管道、雙倍的可觀測性工作，以及更高的不一致風險。長期來看，這增加了成本和操作複雜性。

分離棧但共享業務邏輯：重構現有端點意味著改變當前REST API程式碼結構，使其能被A2A等新介面複用。即使外部REST路徑保持不變，重構也可能引入迴歸、行為漂移和大量測試負擔。

核心思想：智慧體覆蓋層

智慧體覆蓋層是一種薄包裝層，使基於REST的服務能夠參與A2A通訊。該覆蓋層將智慧體訊息轉換為REST負載，反之亦然；將REST端點暴露為智慧體任務或工具。最重要的是，A2A不是新的API，而是現有API的新介面。底層REST服務保持不變。

在應用程式內新增智慧體覆蓋層時，有兩組端點（/api/v2/...和/a2a/...），但只有一個部署管道。傳統REST API端點可以轉換為智慧體端點，無需重寫核心業務邏輯。同一主機和埠新增新路由，系統可能需要擴充套件以處理增加的流量。智慧體技能本身可用於路由，無需獨立的MCP伺服器。這種方法透過複用現有服務作為智慧體，減少了基礎設施中的智慧體氾濫，適用於需要基於REST和智慧體能力的監督智慧體。

智慧體覆蓋層示例實現

作為概念驗證，本節展示如何將使用Flask的遺留REST計算器服務透過覆蓋層移植到智慧體系統。對於覆蓋層，我們新增標準A2A元件（如智慧體卡片、智慧體訊息端點、能力、技能和健康檢查）。我們還引入了一種訊息轉換設計模式，將智慧體訊息轉換為REST API訊息，然後從智慧體發出REST呼叫。A2A訊息轉換工作流如下：

1. 接收JSON-RPC 2.0請求。
2. 將A2A任務對映到REST端點。
3. 轉發認證頭。
4. 內部呼叫REST端點。
5. 將REST響應轉換為JSON-RPC格式。

步驟0：請求-響應格式：比較REST和A2A協議的請求-響應格式。例如，REST計算器請求為{"operation": "add", "operands": [5, 3]}，A2A請求則封裝在JSON-RPC訊息中。響應方面，REST返回{"result": 8}，A2A返回結構化的JSON-RPC響應。

步驟1：設定智慧體：建立計算器智慧體示例，包含眾所周知的智慧體卡片和載入的智慧體技能。build_agent_card函式動態構建智慧體卡片。

步驟2：實現內部REST呼叫器：透過HTTP請求呼叫內部REST端點，確保中介軟體、裝飾器和頭部得到正確執行。該實現展示瞭如何透過薄層將遺留REST服務轉換為A2A相容的智慧體，同時保持現有業務邏輯不變。