A2A

獨立的 AI 代理如何協同運作：面向 Hermes Agent 的 A2A 橋接

作者：IdeaBosque最後更新：2026年7月24日

這對你的業務意味著什麼

你的代理無須重寫即可協同。 Agent2Agent Protocol（A2A）是一個開放標準，讓 AI 代理彼此發現、相互委派工作並串流回傳結果。一層輕薄的橋接讓既有代理在不改動其內部的情況下講這套標準語言——你保住了既有的投入。
沒有供應商鎖定。 由於橋接位於標準與代理之間，你日後可以更換底層的代理框架，而不會破壞建立在其上的整合。其他團隊仍然呼叫同一個標準端點。
一套系統服務眾多客戶或業務單位——且資料嚴格隔離。 租戶隔離在資料庫層面強制執行，而非僅在應用程式碼中，因此一個編碼錯誤無法把一個客戶的資料外洩給另一個。這正是能通過安全稽核的關鍵差別。
人類始終掌控敏感操作。 當代理需要核准時——一次採購、一項資料存取決定、一份報價審批——該請求會以標準的「等待審批」狀態出現，並一路回傳給發起該鏈條的人或代理，即便跨越框架邊界也是如此。
它是真實且經過測試的，不是一張投影片。 整套內容打包為一個開源部署（docker-a2a-hermes-agent-gateway），並配有自動化測試套件，在你依賴每項能力之前先加以驗證。

問題所在：無法彼此對話的代理

多數組織並非採用「一個 AI 代理」，而是逐步累積出好幾個。這裡一個報價代理，那裡一個目錄查詢代理，還有一個歸屬於另一團隊的庫存代理——常常基於不同框架，有時來自不同供應商，在不同時期建置。單獨看它們都能運作，瓶頸在於讓它們協同：把工作交給另一個、等待結果、再交還控制權。

用手工方式把每個代理與其他所有代理逐一連線來解決，既緩慢又脆弱，而且每新增一個代理就更糟。它還會悄悄造成鎖定：一旦整合被硬編碼到某一供應商的介面，更換該供應商就意味著全部重做。

**Agent2Agent Protocol（A2A）**就是消除這一瓶頸的開放標準。它定義了一套共同語言，讓代理彼此發現、委派任務、串流傳輸進度並回報完成，無論各自基於什麼建置。採用一次標準，此後每個新代理都與其餘代理講同一種語言。

難點在於：你既有的代理並不原生講 A2A。以 Nous Research 的 Hermes Agent 為例，它公開的是自有介面。為了新增一個協定而重寫一個能正常運作的代理，恰恰是團隊想要避免的那種昂貴且高風險的專案。

答案是一層橋接——一個小小的翻譯層，對外講 A2A，對內用代理自己的語言與之交流。代理本身從不改變。docker-a2a-hermes-agent-gateway 專案正是這層橋接的一個可執行的開源範例，打包為單一可部署單元。

各部分如何組合

一共有三個活動部件，而只有其中一個會暴露給外部世界：

前門（閘道）。 一切都透過單一的受控入口進入。它決定誰可以進入、一個請求屬於哪個客戶、呼叫方可以多快、以及如何串流回傳即時進度。其他一切都無法直接存取。
翻譯器（橋接）。 它以開放的 A2A 標準接收請求，轉換為你的代理真正能理解的形式，再把答覆轉換回來。這是唯一了解具體代理的部件，也正因如此，代理日後才可被替換。
代理及其工作記錄。 你既有的代理負責真正的推理。它所做的一切都被記錄下來——每個任務、每則訊息——並按客戶嚴格隔離。

由於前門與記錄都獨立於代理本身，你可以把閘道保留在自己的雲內，並讓它指向執行於別處的代理，或指向你所選的託管資料庫。沒有任何東西強制這三者置於同一處。

無須重寫代理即可採用標準

這裡最有價值的特性是你的代理從不改變。 翻譯器代替它完成講標準語言的全部工作。

這帶來兩點直接的業務影響：

保護你既有的投入。 建置報價代理的團隊不必停下來為一個新協定重新改造它，只需加上一層橋接便可繼續前行。
雙向避免鎖定。 呼叫方只依賴開放標準，而非你的代理供應商。若你日後更換代理——更好的模型、更便宜的供應商、自研實作——只需更換翻譯器，建立在其上的所有整合都無須改動即可繼續運作。反過來，一個閘道可以同時面向多個不同代理：推理密集的工作路由到一個，日常流程步驟路由到另一個，而在呼叫方看來它們完全一致。引擎的選擇成為你可掌控的實作細節，而非把你套牢的承諾。

服務眾多客戶或業務單位——資料隔離經得起稽核

同一套部署可以從單一執行系統服務眾多租戶——不同客戶，或不同的內部業務單位。每一方都擁有各自的代理、各自的任務歷史與各自的訊息儲存。

讓這一切安全而不僅僅便利的，是隔離在何處強制執行。每個請求都被標記它所屬的客戶，而資料庫本身拒絕把一個客戶的記錄回傳給另一個——這一控制施加在資料層，位於應用程式碼之下。實際上這意味著軟體中的一個缺陷或一處遺漏的過濾條件無法跨客戶外洩資料，因為兜底的是資料庫，而非應用。這正是安全或合規審查者所尋找的區別，也讓你能夠把多個客戶放在共享基礎設施上而不危及其資料。

讓人類掌控敏感操作

只有當人可以在關鍵時刻介入時，自主才是可接受的。當代理到達一個需要簽核的步驟——授權一次採購、核准一份報價、放行敏感資料——它不會逕自繼續，而是暫停並拋出一個標準的「等待審批」狀態。

關鍵在於該狀態會傳遞。一個在若干代理之前發起的請求——可能位於完全不同的框架、歸屬於另一團隊——會收到同樣的、未經改動的「需要輸入」訊號。人做出核准（或拒絕），工作隨之恢復。治理不會止步於單個代理的邊界；開放標準把審批關卡貫穿整條鏈條。對於任何涉及資金、合約或受監管資料的工作流，這種端到端的控制正是讓代理委派站得住腳而非魯莽的原因。

在資料必須駐留之處執行

該部署是一個單一、自足的軟體套件，既可綑綁執行——代理、資料庫與閘道一體——以便快速起步，也可拆分以用於生產。你可以把受控前門保留在自己的網路內，並讓它指向一個託管資料庫（這樣備份、加密與合規由你的雲端服務商處理），以及一個執行於獨立硬體上的代理。

對於有資料駐留或主權要求的企業，這一點很重要：每一次代理互動的記錄都可以保留在你的政策所要求的邊界之內，而非放在你無法掌控的第三方雲中。

在你依賴之前先經驗證

一項你無法驗證的能力就是一項負擔。該部署附帶一套自動化測試套件，端到端地演練真實執行中的系統——確認代理可被發現、請求能夠完成、即時進度能夠正確串流、錯過一次即時更新的客戶仍能取回完整結果，以及故障與取消是否按預期表現。測試對每一項檢查給出明確的通過或失敗結果，並被設計為可作為自動化關卡執行，從而使有缺陷的變更在抵達生產之前被攔截，而非之後。

其現實價值在於降低風險：你不必聽信任何人說整合能用。它會在每次變更時被可重複地加以證明。

在生產中執行它究竟需要什麼

對營運成本坦誠以待，是商業論證的一部分。有幾點現實值得規劃：

它被設計為先輕量執行，再有意識地擴展。 預設是單一、簡單的部署。以多副本服務極高流量是受支援的，但那是一個有意為之的步驟，而非偶然：它需要共享基礎設施以使各副本保持一致。請規劃擴容，別以為它是免費的。
保持更新是例行事務，而非重寫。 各建構區塊從其開源來源拉取，因此保持最新是你的團隊按計劃執行的一項標準更新操作。
安全姿態由你設定。 該軟體套件附帶佔位密碼與寬鬆的預設值，以便開箱即用地輕鬆起步——它們本就是要在面向網際網路之前替換掉的。可選的內建代理功能強大，只應執行在你信任的基礎設施上。這些都不稀奇；它們是任何生產系統都需要的常規強化，理應列入上線檢查清單。

這些都不是攔路石。它們是執行一個真實系統的日常職責，而提前把它們說清楚，正是避免上線後意外的方式。

這帶來了什麼

綜合起來，橋接模式帶來三樣憑一己之力確實難以拼裝的東西：

1. 基於標準的協同，無須重寫。 任何講 A2A 的代理都能立即與你既有的代理協作——發現它、向它委派、追蹤其進度——而無須改動那個代理。你在保留既有可用之物的同時採用了一個開放標準。

2. 具備真正隔離的多租戶服務。 單一部署服務眾多客戶或業務單位，資料隔離在資料庫層面強制執行。這正是讓你能夠在不削弱安全的前提下向共享基礎設施整併的原因。

3. 跨邊界的受治理自主。 人工審批關卡隨工作一同傳遞，因此無論請求經過多少代理——或多少框架——敏感操作都會有人參與其中。

該功能實作為開源且文件完備：橋接及其整合指南位於 a2a_daemon_engine 程式庫（參見 Hermes 整合指南），受控前門的文件見 SilvaEngine Gateway 程式庫。完整部署打包於 docker-a2a-hermes-agent-gateway。