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