假設你手上有上百個老系統——有的甚至是跑了三十年的主機(像 AS/400 那種綠幕),各自的資料庫、輔助 API、使用者權限全都不一樣。現在你想讓 AI agent 去問這些系統的資料,問題來了:agent 要「直接打 A2A」、「經過 MCP server」、還是「走一個 Hub」?這篇把 A2A、MCP、Hub 這三層的用意與取捨一次講清楚——你會發現它們不是三個對立的東西,而是同一件事的四個管理檔位,而且這條路,軟體工程早在 MVC 時代就走過一次了。
- 裸接 → A2A → MCP → Hub 是同一個「Agent 問資料」動作的四個管理檔位,不是四選一,agent 可以從任一格進入。
- 往上一格:+治理、+可規模化,同時 −直接、−簡單。
- 對應軟體分層的老 pattern:A2A = Adapter + Repository、Hub = Front Controller / API Gateway。
- 該停哪格 = 規模 × 必要性。規模到了還裸接 = 技術債;MCP 才一個就蓋 Hub = over-engineering。
一個問題:上百個老系統,怎麼讓 agent 問到資料?
最原始的做法,是讓 agent 直接呼叫每個系統的 API 或資料庫。一個 agent 打得動,那一百個 agent 打一百個系統呢?那是 N×M 條整合:每個 agent 要自己知道每個 API 的長相、自己帶授權、自己處理格式。沒有發現機制、沒有統一授權、沒有稽核——改一個後端,所有 agent 跟著改。能動,但不可規模化。這就是為什麼「直接打」在單機 demo 很爽、一上規模就崩。
要解這題,關鍵不是「用哪個技術」,而是先看清楚:不管走哪一層,底層永遠是同一個動作。
不變的底層:一切都是「Agent 問資料」
A2A、MCP、Hub 表面上是三個不同的東西,但如果你從 agent 的角度看,它們做的是同一件事:讓一個 agent 拿到後端系統的資料或能力。差別只在中間隔了幾層「中介」,以及每一層幫你多管了什麼。整個設計,就是在「agent 直接裸接資料」這條線上,一層層加中介——每加一層,你用一點「直接與速度」,換一點「管理與治理」。
把這句話記住,四個檔位就串起來了。
四個檔位:裸接、A2A、MCP、Hub
這不是四選一,而是同一條「速度 ↔ 治理」光譜上的四個停靠點。往右一格,多一分可規模化,少一分直接:
| 檔位 | 你站在誰的角度 | 換到什麼 |
|---|---|---|
| 裸接 raw API/DB | 最原始 | 最快、最裸,只適合一次性 |
| A2A | Agent 角度(要快) | 自描述標準介面,一問就懂 |
| MCP server | 管理角度(最低限度) | 一個域的統一入口 + 發現/授權 |
| Hub | 治理角度 | 統籌:單一身分/policy/目錄/稽核 |
關鍵洞見:越高不是越好。每往右一格都有代價,該停哪格取決於你的規模,而不是「越治理越安心」。下面逐格看用意與取捨。
每個檔位的用意與取捨
檔位 0:裸接(Agent → raw API/DB)
用意:零基建、最快。一次性 spike、概念驗證,這樣做最划算,別為它蓋基礎建設。取捨:得到「立刻能動、零成本起步」,付出「N×M 整合、無發現、無授權、無稽核,改一個後端全部要改」。老 pattern 就是「把 SQL 寫進畫面」——能動,一到多人多頁就崩。
檔位 1:A2A(把後端包成自描述的 agent)
用意:讓後端「標準化 + 自我描述」。每個後端包成一個 A2A agent,帶一張 Agent Card——agent 問 Card 就知道怎麼用,不必預先寫死。一個 A2A 給所有 agent 重用,終結 N×M。取捨:得到「標準介面、自描述、可重用,醜的 legacy 被 Adapter 藏起來」;付出「多一層 wrapper 要建與維護、授權還各自管、agent 仍要自己知道有哪些 A2A、在哪」。老 pattern:Adapter + Repository——轉接醜介面,給乾淨的資料存取口。
檔位 2:MCP server(把一組 A2A 收成工具面)
用意:給 agent「一個域的統一入口」加上最低限度的管理——發現、授權、限流終於有個落點,而且 Claude Code、Codex 這類工具原生支援 MCP,插上就用。為什麼「最少要 MCP」?因為讓幾百個 agent 各自裸打 A2A,授權與稽核根本無處落地;MCP 是「管理」的最小可行單位。取捨:得到「一個連線點拿一整組能力」;付出「多一跳,而且 MCP 會長很多個——問題只是被推高一層,變成很多入口各自要管」。
檔位 3:Hub(統籌很多 MCP)
用意:當 MCP server 從一個變二十個,你需要一顆統籌——單一入口、單一身分、單一 policy、單一目錄、單一稽核,把授權、log、限流、發現這些「橫切關注」從每個 MCP 裡抽出來集中。決策者只連一個地方就能跨所有系統;新增系統只是註冊,不是又開一個要各自管的入口。取捨:得到「唯一真相、跨系統、可治理可稽核」;付出「又一跳、Hub 變成新的單點要做高可用、還要建整套控制面與憑證保管庫」。老 pattern:Front Controller / API Gateway——單一入口集中處理授權、路由、記錄。這顆 Hub,其實就是我在《導向型 MCP Gateway:無狀態閘道的實戰方法論》裡談的那個閘道。
這是軟體分層史的重演(Agent 版 MVC)
看到這裡你可能有既視感——這不就是 MVC 那套嗎?沒錯,而且對應關係非常乾淨。你不是在發明新東西,你是在用新名字重跑一條走過的路:
| Agent 時代 | 古典 pattern | 它負責什麼 |
|---|---|---|
| 舊系統 / 資料庫 | Model | 資料本身(很多異質後端 = 很多 Model) |
| A2A | Controller(Adapter + Repository) | 轉接醜介面、給乾淨存取口(很多 A2A = 很多 Controller) |
| MCP server | 一組 Controller 的路由/模組 | 把一個域的能力收成統一工具面 |
| Hub | Front Controller / API Gateway | 單一入口、集中授權/路由/記錄 |
| 消費端 AI agent | View / Client | 把資料組成使用者要看的答案 |
當年我們從「把 SQL 寫進畫面」→ MVC → Front Controller → 微服務 / API Gateway;現在 agent 存取資料,正在用 A2A、MCP、Hub 這些新名字跑同一條路。那「什麼時候該往上爬一層」呢?看觸發條件,不是無腦往上:
現實不是乾淨的分層:野蠻生長
上面那套乾淨的四檔位,是心智模型,不是現實。現實是野蠻生長——層界會糊掉、東西會一直長,而且常常是被組織需求(某個長官一句話)推出來的。
省工方法論:讓 Hub 適應葉子,不是葉子適應 Hub
陷阱:為了讓 Hub 能治理,就去逼每個 A2A 宣告憑證格式、接身分下傳、配合 Hub 的規矩——那不是省工,是把工攤給一百個葉子。反過來才對:把所有不對稱的適配都吞進 Hub 這一層,讓葉子維持它本來薄薄的樣子。
② 宣告在 Hub,不在葉子。「這個端點要什麼憑證、給誰用」是上架時記進 Hub 目錄,不是叫 A2A 自己寫卡。Hub 一次學會門檻,不用每次跳下去問。
③ 預設粗粒度,細粒度 opt-in。Hub 只管「哪個大佬能連哪個 A2A」;連上後 A2A 用本來的服務帳號回。絕不預設逼老系統做 per-user 身分下傳。
④ 把代價講白:粒度 = 工,你按系統挑。沒有「又省工又細粒度」——那需要葉子天生支援身分,30 年老系統多半沒有。
| 授權粒度 | 葉子要做的事 | 你換到什麼 |
|---|---|---|
| 粗(service,預設) | 零改動,用本來的服務帳號 | 省工;但連上就看得到整個系統 |
| 細(obo,opt-in) | 要接身分下傳、跑 row-level 授權 | 對得起內稽;但很貴、只有支援身分的系統做得到 |
那每層實際寫什麼 code?
很多人卡在「Hub / MCP 到底要寫什麼」。答案會讓你安心:每層要寫的東西是反過來的——真功夫全在 A2A,上面兩層本來就幾乎不用你寫 domain code,這正是省工的來源。
| 層 | 你實際寫什麼 | 性質 | 每系統要重寫嗎 |
|---|---|---|---|
| A2A | Agent Card + 查詢 handler + 對後端服務帳號 auth | 真 domain code | ✅ 每系統一份(真功夫在這) |
| MCP | 薄殼 + list/describe/find/query 四個通用工具 + 註冊表 | 殼寫一次;加系統=加資料 | ❌ 殼共用,只加註冊資料 |
| Hub | 身分聯邦(信任各家 SSO)+ policy 規則 + 目錄 DB + 憑證庫 + 稽核 | 設定+規則+資料,近乎零 domain code | ❌ 用「組」的,加系統=登記一筆 |
真實案例:16 家上市公司怎麼聯邦
情境:一個集團 16 家上市公司、4 套 ERP、30 個 WMS、10 個 HR,長出上千個各有 domain 的 API。集團長要快速跨公司看資料。最容易做錯的一步,就是「把一個 SSO 放 Hub 上」——16 家是獨立法人、各有各的 SSO,你逼不動、法遵也不會過。
├─ B 公司 MCP → B 的 SSO / API / A2A
└─ … 共 16 家,各留各的身分,不搬家
該停哪格?規模 × 必要性
整條線的取捨,一句話:每往右一格,+治理、+可規模化,同時 −直接、−簡單。所以「該站哪一檔」不是越高越好,而是由你的規模與必要性決定——頻次 × 必要性決定架構,避免過度設計。對照著挑:
| 你的情況 | 該停的檔位 |
|---|---|
| 一次性 spike / 探索 | 裸接 |
| 單一系統要給 agent 用 | A2A |
| 一個域 / 團隊要管理性 | MCP |
| 集團級、多個 MCP、要治理稽核 | Hub |
兩個方向都是錯:
一句話心法與延伸閱讀
把分層當成「選擇」而不是「義務」,你就不會在該簡單的地方過度設計,也不會在該收斂的地方欠技術債。延伸閱讀:
發佈留言