從問 AI 到用 Agent · 🟣 開創

A2A、MCP、Hub 怎麼選

同一個 Agent 問資料,四個檔位的取捨

▶ 看影片 🎓 L6 開創 🎬 11 個段落 🀄 投影片 + 逐字稿
本集開場

假設你手上有**上百個老系統**,有的甚至跑了三十年,各自的資料庫、API、權限全都不一樣。現在你想讓 AI Agent 去問這些系統的資料 —— 問題來了:Agent 應該**直接打**,還是中間要墊幾層?很多人一聽到 A2A、MCP、Hub,就以為是三個要三選一的技術。**其實它們是同一件事、只是墊了不同層數的中介。**這一集,我用一條你其實很熟的老架構,把這三個名詞一次講到你不會再搞混,而且知道自己該用哪一個。

1

不變的底層:一切都是「Agent 問資料」

🧭
逐字稿

先記住一句話,後面全部串得起來:不管走哪一層,底層永遠是**同一件事** —— 讓一個 Agent 拿到後端的資料。A2A、MCP、Hub 看起來是三個東西,其實是同一個動作、中間墊了**不同層數的中介**。每多墊一層,你就用一點「直接跟速度」,去換一點「管理跟治理」。所以真正的問題從來不是「用哪個技術」,而是「這一次,我需要多少管理」。

2

檔位零:裸接 —— 最快,也最裸

🚀
逐字稿

**檔位零,裸接。**Agent 直接呼叫每個系統的 API 或資料庫。一個 Agent 打得動;但十個 Agent 打十個系統,就是**十乘十、一百條**整合。每個 Agent 要自己知道每個 API 長怎樣、自己帶授權、自己處理格式。改一個後端,全部要跟著改。它只適合一次性的探索,一上規模就崩。這就像把 SQL 直接寫進畫面 —— 能動,但撐不久。

3

檔位一:A2A —— 包成會自我介紹的 agent

🔌
逐字稿

**檔位一,A2A。**把每個後端**包成一個會自我介紹的 Agent**,帶一張 Agent Card。Agent 問這張卡,就知道這個怎麼用,不用事先寫死。一個 A2A 給所有 Agent 重用,**N 乘 M 就被打斷了**,醜的老系統介面被藏在後面。用老話講,這就是 **Adapter 加 Repository** —— 轉接醜介面,給你一個乾淨的存取口。代價是:你多了一層要維護,而且授權還是各自管。

4

檔位二:MCP —— 一個域的統一入口

🧩
逐字稿

**檔位二,MCP server。**它把**一組 A2A 收成一個統一的工具面**,加上最低限度的發現、授權跟限流。而且 Claude Code、Codex 這些工具原生就吃 MCP,插上就能用。為什麼說「最少要 MCP」?因為讓幾百個 Agent 各自裸打 A2A,授權跟稽核根本**無處落地**;MCP 是管理的**最小可行單位**。代價是多一跳,而且 —— MCP 會長很多個,問題只是被推高了一層。

5

檔位三:Hub —— 當 MCP 多到需要統籌

🗼
接續「把閘道當導向器」那一集 —— Hub 就是那顆無狀態閘道。
逐字稿

**檔位三,Hub。**當 MCP 從一個變二十個,你需要一顆**統籌**:單一入口、單一身分、單一授權規則、單一稽核。把授權、記錄、限流這些**橫切的事**,從每個 MCP 裡抽出來集中管。決策者只連一個地方,就能跨所有系統;新增系統只是註冊,不是又開一個要各自顧的入口。這顆 Hub,用老話講就是 **Front Controller**,也就是我另一集講的那個**把閘道當導向器**的無狀態閘道。

6

其實這就是 Agent 版的 MVC

🏛️
逐字稿

看到這裡你可能有既視感 —— 這不就是 **MVC** 嗎?沒錯,而且對得非常乾淨:舊系統的資料庫是 **Model**;A2A 是 **Controller**,負責轉接跟存取;Hub 是 **Front Controller**,單一入口集中管授權跟路由;消費端的 Agent 就是 **View**,把資料組成你要看的答案。當年我們從「把 SQL 寫進畫面」,走到 MVC、Front Controller、API Gateway;現在 Agent 存取資料,正在用新名字**重跑同一條路**。你不是在發明新東西,你是在看一集你其實看過的戲。

7

現實不是乾淨金字塔:野蠻生長

🌿
逐字稿

但我得老實跟你講:上面那張乾淨的分層,是**心智模型**,不是現實。現實是**野蠻生長**——A2A 一個資料庫就長二三十個,真實數量是幾千;MCP 沒有固定形狀,可能串一堆 API、也可能收一堆 A2A;連 Hub 都常常是**某個長官一句話**,為了一個需求就開一顆。所以真實的圖,是一團會一直長、還混在一起的網。你攔不住這種生長,也別假裝它是金字塔。

8

省工方法論:Hub 適應葉子

🪶
憑證放 Hub 出口注入;葉子用它本來的服務帳號,不知道 Hub 存在。
逐字稿

那怎麼在這團野蠻生長裡省工?一句話:**讓 Hub 適應葉子,不是葉子適應 Hub。**陷阱是——為了讓 Hub 能治理,就去逼每個 A2A 宣告格式、接身分下傳,那不是省工,是把工攤給一百個葉子。反過來:**所有適配都吞進 Hub**,葉子維持它本來的樣子、用它本來的服務帳號、根本不知道 Hub 存在。而且**授權預設粗粒度**——Hub 只管誰能連哪個系統,絕不預設逼三十年老機做逐人授權;細粒度是例外,不是預設。你省的工,是不逼一百個葉子改;你付的,是預設粗粒度——**這是唯一誠實的省工法。**

9

什麼時候才該往上爬一層?

🪜
逐字稿

重點來了:往上爬是有觸發條件的,不是無腦往上。這裡有三個。**第一,**當同一個後端要給**多個 Agent** 用,就包成 A2A,停止 N 乘 M。**第二,**當一組 A2A 需要**統一入口跟最低授權**,就上 MCP。**第三,**當 MCP 多到各自管授權、稽核已經**失控**,才上 Hub 統籌。每一步,都是被「痛」推上去的,不是為了架構好看。沒有痛,就別爬。

10

該停哪格:規模 × 必要性

🎯
規模到了還裸接=技術債;MCP 才一個就蓋 Hub=過度設計。
逐字稿

所以該停哪一格?一句話:**規模乘以必要性。**一次性探索,裸接就好;單一系統給 Agent 用,做到 A2A;一個團隊要管理性,上 MCP;集團級、很多 MCP、要治理稽核,才需要 Hub。而且**越高不是越好**,兩個方向都會出事:規模到了還在裸接,是**技術債**,遲早爆;可是 MCP 才一個就急著蓋 Hub,是**過度設計**,那套控制面的維運成本,你養不回來。

11

帶走一句話:分層是選擇,不是義務

🧳
就像你能 new 一個 Controller 直接問 DB —— 能動,規模化才知道痛。
逐字稿

最後送你一句心法:**分層是選擇,不是義務。**你當然可以直接打 A2A —— 就像你當然可以**直接 new 一個 Controller 去問資料庫**,能動。問題從來不是「能不能」,而是規模化之後:誰管授權、誰查得到是誰動了資料、上百個系統乘上一堆 Agent 的 N 乘 M,誰來收拾。MCP 是最低限度的紀律,Hub 是當 MCP 多到需要統籌時,那顆你其實很熟的 Front Controller。下次要為 Agent 接資料,先問自己一句:**這一層,我真的需要嗎?**