誰能更快找出資料之間的關聯,誰就有更多機會——因為資料的價值會隨時間衰減。AI 能加速,但真正去查資料的不是光桿 AI、也不是 ChatGPT 那種聊天,而是接上工具、有身分的「AI Agent」;你得先讓它「知道」你有哪些資料。這正是本文那層 MCP 說明書在做的事。
- MCP 是讓 AI Agent(不是光桿 AI、也不是一般聊天)即時連上公司系統/資料的標準接口,可想成「AI 的萬用插頭(USB-C)」。
- 真正的痛點不是找「我知道要找什麼」的資料,而是挖出「我根本不知道存在、卻其實有用」的資料與它們之間的關聯。
- 做法:資料市集原系統完全不動,只往外加一層 APIHUB(資料市集 MCP)當 AI 的導航/索引層——不存資料、即時轉拋、只掛機敏等級標籤;真正的授權仍在資料市集,憑 Agent 身分、逐一資料集放行。
- 成果:把「大海撈針、逐一翻 1288 個資料集」變成「問一句、AI 帶路」。
公司的資料市集裡躺著 1288 個資料集,但要用的時候得一個一個翻。這篇分享我怎麼用 MCP 幫 AI 在這 1288 個資料集裡,連我自己都不知道存在的資料都幫我挖出來——而且過程中沒有動到資料市集一根寒毛,只是往外多包了一層。
一、什麼是 MCP(先講清楚)
MCP 是讓 AI Agent 能即時連上公司系統/資料的一種標準接口,可以想成「AI 的萬用插頭(USB-C)」。這裡先強調:插上這個插頭去用資料的,是「AI Agent」,不是光桿 AI、也不是 ChatGPT 那種聊天(下一小節分清楚)。
- 沒有它:就算是 AI Agent,也碰不到你的資料,只能靠模型的訓練記憶回答,對公司自己的資料一無所知。
- 有了它:AI Agent 能實際「去查」我們自己的資料,而不是憑印象猜。
先分清楚:AI、AI Chat(ChatGPT 那種)、AI Agent 是三件事
這三個很常被混為一談,但差很多——先分清楚,才知道 MCP 是接在哪一個上面:
| 面向 | AI(模型/大腦) | AI Chat(ChatGPT 那種) | AI Agent(能行動) |
|---|---|---|---|
| 是什麼 | 會推理的模型本體 | 模型 + 對話介面 | 模型 + 工具 + 身分 |
| 怎麼用它 | 被程式呼叫 | 你打字聊天、一問一答 | 給它目標,它自己規劃多步驟 |
| 碰得到你的資料嗎 | ❌ 只有訓練記憶 | ❌ 多半只靠記憶 | ✅ 用工具(MCP)即時查 |
| 會自己動手做事嗎 | ❌ | ❌ 給你答案,動手的是你 | ✅ 串工具把事做完 |
| 跟 MCP 的關係 | 用不到 | 通常沒接 | MCP 就是給它的工具/說明書 |
二、為什麼要做(真正的痛點)
資料市集的資料集又多又零散,要用時得一個一個翻找。找「我知道要找什麼」的資料還算好辦;真正困難又最花時間的,是找出「我根本不知道存在、卻其實有用」的資料,以及它們之間的關聯。這才是痛點。
三、我們怎麼解(做了哪三件事)
- 用資料市集的匯出功能,一次匯出全部資料 API + 說明(共 1288 個資料集)。
- 以此為底做出「資料市集 MCP」——一個幫 AI 導航的索引層(不存資料、即時轉拋、只標機敏等級;真正的授權仍在資料市集端,按 Agent 身分逐一資料集放行)。
- 把這個 MCP 掛到我的 AI Agent 上。
流程長怎樣?(UML 時序圖)
與其用文字條列,直接用 UML 時序圖(sequence diagram)看一次查詢怎麼走:一句白話問題從使用者出發,經過 AI Agent、我新增的 APIHUB 導航層,最後只是「讀」原本的資料市集再一路回傳。這裡有兩個關鍵、也是最容易被誤會的地方:(1)MCP 這層只負責「找關聯 + 標機敏等級」的導航,它不決定你能不能看;(2)真正的授權在資料市集端——Agent 帶著「你發給它的身分」過去,由每個資料集各自的授權放行。最右邊那條 lifeline 全程只被讀、沒有被寫,0 改動。
用「插頭」比喻的話:資料市集是牆上的插座(沒動它),APIHUB 這層是我加的轉接頭,讓 AI 這台新設備可以直接插上去用。時序圖上四條 lifeline 裡,只有中間那條綠色的是這次新增的;最右邊的原系統從頭到尾只有被讀取的箭頭進去、回傳的箭頭出來,沒有任何寫入。
這不是「疊床架屋」——MCP 只是幫資料市集寫「使用說明書」
一聽到「再加一層」,很多人以為是疊床架屋:MCP 是不是又自己搞一套 API、一套授權、還把資料複製一份?不是。資料市集原本的 API 與授權原封不動、仍是唯一那道門;MCP 這層沒有自己的 API、沒有自己的授權、也不存資料,它做的只有一件事——幫這 1288 個資料集寫一本 AI 看得懂的使用說明書(索引)。換句話說,我搭的是一層薄薄的中間層 + 說明書;資料仍留在原地,不需要集中到我這。
四、成果
- 現在只要用白話問 AI,它就能在 1288 個資料集裡幫我找出關聯、找到我要的、甚至挖出我原本不知道存在的資料。
- 把「大海撈針、逐一翻找」變成「問一句、AI 帶路」。
最大的好處:Agent 幫你「知道你不知道什麼」
把資料分成兩軸——「你知不知道它存在」× 「它對你有沒有用」。舊搜尋只救得了左半邊(你知道要找的);真正的金礦在右上角:有用、卻多到你根本來不及一一去看,也不知道它在哪。這格靠人力永遠處理不完;而透過 Agent + 說明書這條路,才有機會及時把它挖出來。
五、一張圖看懂整體:我只做「說明書」,金礦在原系統
把前面所有重點收成一張 UML 元件圖:舊系統與它的 API 原封不動;我只在外面替它做了一本說明書(MCP);Agent 讀我的說明書,再去舊系統把「金礦」挖出來幫 User。特別注意——MCP 這層無狀態、不存資料(所以容易水平擴充、重啟);但它是每次查詢的必經入口,一樣要做高可用:它掛了,Agent 就沒有說明書、找不到路。至於真正的資料、資源與即時性,則都在既有 API 與舊系統那一側。
六、核心一句話:資料的價值在「時間」
如果整篇只留一句,就是這句:資料的價值在時間。同一筆洞察,即時拿到,你能拿它去行動;拖過了頭,就只剩「事後諸葛」。價值隨時間衰減的樣子,大概長這樣:
所以問題其實是:誰能更快找出資料的關聯,誰就抓得住還沒消失的價值。AI 能大幅加速這件事——但前提是你得先讓 AI「知道」你有哪些資料、彼此怎麼關聯(這就是前面那層 MCP 說明書)。把它跟傳統「戰情室/BI 報表」擺一起,差異就一目了然:
為什麼不乾脆把資料倒進一個資料中心、做成戰情室報表就好?因為資料的價值在「快」。傳統戰情室要先把資料抽出來、經 ETL 清洗彙總、再落地到資料倉儲——多了這一層,資料不但有延遲,還會在 ETL 的整理過程中被轉換、被扭曲(彙總掉細節、套進預設的格式)。這個做法只有一層:MCP 只是說明書,資料留在原地即時直讀——這就是它和「戰情室/戰情報表」最大的差異。
| 面向 | 傳統戰情室 / BI 報表 | 這個做法:MCP 直讀原系統 |
|---|---|---|
| 架構層數 | 多層:來源 → ETL → 資料倉儲 → 報表 | 一層:說明書指向來源,直讀 |
| 資料新鮮度 | 批次更新、有延遲(常 T+1) | 即時:直接讀來源 API |
| 資料保真度 | ETL 清洗/彙總 → 可能被扭曲、失去原貌 | 讀原始資料,不經轉換 |
| 要不要搬資料 | 複製一份進資料中心,要維護+同步 | 不搬資料、不建資料中心 |
| 怎麼查 | 報表要先定義好,才看得到 | 白話問一句,臨時關聯也能挖 |
| 最適合 | 固定 KPI 的長期監看、歷史趨勢 | 探索「你不知道要找什麼」的即時查詢 |
延伸閱讀:這層 APIHUB 背後的無狀態閘道設計,我另外寫成方法論——導向型 MCP Gateway:無狀態閘道的實戰方法論;要理解 A2A、MCP、Hub 這幾層怎麼分工,可看 Agent 版 MVC:A2A、MCP、Hub 的分層與取捨。
(資料來源:MCP 為 Anthropic 提出之開放標準;本案為內部實作。)
發佈留言