讓 Agent 安全插上你的工具與資料
歡迎回到《從問 AI 到用 Agent》。進階篇我們花了好幾集,教你怎麼讓 Agent 動手用工具:查資料、開檔案、呼叫外部系統。但用久了你會發現一件很煩的事——每接一個新工具、新系統,就得為它客製一次接法。這一集,我要介紹一個把這件事標準化的東西,它的名字叫 MCP。
先把問題講清楚。你想讓 Agent 接上 GitHub,得寫一段對接的程式;想再接資料庫,又是另外一套寫法;想接公司內部的系統,再客製第三套。每接一個,都要有人去寫一段中間的「膠水」,把 Agent 和那個工具黏起來。而且這些膠水彼此不通用,換一個工具,幾乎等於從頭來過一次。
更麻煩的還在後面。假設你辛苦把十個工具都接到某個 Agent 上了,哪天你想換一個更好的 Agent 平台,這十套接法很可能沒辦法直接搬,又得重接一輪。工具那邊沒改、Agent 那邊也沒改,只是中間的接法沒有共通標準,力氣就這樣一次又一次地白花。這就是還沒有標準時的世界。
MCP 要解決的,就是這件事。它是一個開放的標準,不綁任何單一廠商,專門定義「Agent 和工具之間該怎麼對接」。最好懂的比喻,是把它想成「AI 的 USB-C」。以前每個裝置一種插頭,亂七八糟;USB-C 出來之後,一個接頭到處都能插。MCP 想在 AI 世界做的,就是這件一樣的事情。
講一下它的正式身分。MCP 的全名是 Model Context Protocol,直翻是「模型上下文協定」。它是 Anthropic,也就是做 Claude 的那家公司,在 2024 年提出、而且開源出來的一套標準。重點在「開源、公開」:它不是某一家的祕密規格,而是誰都能照著做、任何 Agent 都能支援的公共協定。
接著用白話講它怎麼運作。第一步,在工具那一邊,架一個叫做 MCP server 的東西。這個 server 的工作,是對外「宣告」自己能提供什麼:有哪些可以呼叫的動作、有哪些可以讀取的資料、還有哪些現成可用的提示範本。等於它主動把「我這邊能做什麼」寫成一份標準的清單,掛在門口讓人看。
第二步,Agent 這一邊當 client,也就是使用方。它照著 MCP 這套共同的協定,去問 server:你有哪些工具?因為兩邊講的是同一種「語言」,Agent 就不必為每個工具量身訂做接法。只要對方掛的是 MCP server、你的 Agent 又支援 MCP,插上去就能溝通,中間那層膠水就省下來了。
這樣帶來的第一個好處,是「接一次,到處通用」。工具那邊只要做成一個 MCP server,之後不管換到哪個 Agent,只要它支援 MCP,都能用同一套方式接上去。反過來也一樣:你換了 Agent 平台,原本那些 server 完全不用改,新的 Agent 直接就能接。每次都要重接的痛,就消失了。
第二個好處是生態。因為它是公開標準,現在已經有一大堆別人做好的 MCP server 可以直接撿來用:接本機檔案的、接資料庫的、接雲端硬碟的、接各種線上服務的,種類越來越多。你想讓 Agent 多一個能力,很多時候不用自己從頭寫,找到對應的 server 掛上去,馬上就能用,省掉非常多功夫。
這裡先呼應一下之後的企業篇。在公司裡,你會希望把 Agent 接進既有的系統,但又不能讓它亂碰。MCP 剛好也是這件事的好介面:你可以在 server 這一層,決定這個 Agent 能看到哪些工具、能讀哪些資料、哪些完全不開放。等於權限的邊界,是劃在你自己手上的,而不是把公司系統整個攤開給 Agent。
不過也要給你一個務實的提醒。掛上一個 MCP server,本質上就是把某一批能力開放給 Agent 使用。方便的另一面是:如果亂掛、權限開太大,Agent 能碰的東西就超出你的預期了。所以「要掛哪些 server、每一個給到多少權限」這件事,一定要先想清楚,在公司這種環境裡尤其要謹慎,不要圖方便全部打開。
如果這集只帶走一句話,那就是:MCP 讓「Agent 接工具」這件事,從每次都要客製,變成掛一個標準接頭就通。你完全不用去懂它底層的協定細節;但你要記得一個很實用的問法——以後評估任何一個 Agent 平台,問它一句「支不支援 MCP」,其實就是在問:它好不好接上你手邊的工具跟資料。我們下一集見。