變成最小服務 + 包成 MCP

先講從腳本變服務。現在它是一支腳本,只有你在自己電腦上跑。包成服務,就是在外面套一層,讓別人透過網路就能呼叫。不用一開始做很複雜 —— 最小的服務就一個端點:丟一個問題進去,吐一個有出處的答案出來。先把這個最小可用的服務立起來,比想一堆功能重要。舉個具體的:原本你得在終端機打指令才問得到答案;包成服務之後,你同事在他自己的聊天視窗打一句話,就能查到同一套手冊。中間那層服務,幫你把「一支只有你會用的腳本」,變成「整個團隊都叫得到的東西」。

這張圖是目標。右邊黃框是你的 RAG 最小服務:檢索加生成,後面接向量庫。中間這層是 MCP 介面,注意它上面寫的:只開一個工具,叫 rag_search。左邊是各種會來叫它的人 —— 一個 agent、一個聊天前端、或別的系統。重點就在中間那層:為什麼要多包一層 MCP,而且為什麼只開一個工具。這兩個問題,是這集的核心。

先講為什麼要 MCP。你如果只做一個普通的網路 API,一個 AI agent 其實不知道怎麼用它 —— 它不曉得有這個端點、參數要傳什麼。MCP 做的事,就是把你的工具「自我描述」給 agent 看:有一個工具叫 rag_search、它是查手冊用的、要傳一個問題。agent 讀得懂這個描述,才叫得動。MCP 就是讓 agent 插得上來的那個插座。

這裡順手澄清一個超多人搞混的點。把 RAG 包成 MCP,只是給它裝了個插座,讓 agent 叫得到 —— 插座不是大腦。同一個 rag_search,agent 可以只按一次,那就是普通的一般 RAG;也可以反覆按、邊按邊判斷夠不夠,那才叫 agentic。所以是「呼叫它的那顆腦有沒有在迭代」決定 agentic,跟你有沒有包 MCP 一點關係都沒有。包了 MCP 不會自動變聰明,別誤會。

這裡是這集最重要、也最反直覺的一條:你的 RAG 服務,對外只開一個工具,就叫 rag_search。很多人會忍不住多開 —— 列出所有文件、刪除、管理設定,一口氣塞十幾個工具。不要。業界成熟的 RAG-MCP 做法,契約就是強制只暴露 rag_search 這一個,其他一律不認。你可能會想,多開幾個工具 —— 列清單、篩選、看統計 —— 不是更方便嗎?偏偏就是這個「更方便」的直覺,會把 agent 搞爛。為什麼要這麼克制?下一張告訴你,多開工具的代價,大到你想不到。

原因是這個:你開的每一個工具,它的說明都要塞進 agent 的腦袋裡。工具一多,光這些說明就吃掉大量 context,還讓它挑花眼。有一篇研究實測過,當你把一大堆工具全塞進去,agent 選對工具的準確度,可以低到只剩一成多;而改成只給它相關的少數工具,準確度直接翻好幾倍。實務上,接兩三個工具很多的 server,準確度就開始明顯下滑。所以「少工具」不是潔癖,是實測出來的正確做法。

只開一個工具,還有一個好處:通用。同一個 rag_search,不管是 agent、聊天前端、還是別的系統,接上來就會用,因為它只有一種用法。介面越單純,別人越不會接錯。這樣你的 RAG 就從一支自己的腳本,變成一塊乾淨、任何人都能重複使用的能力 —— 這正是把它包成服務的真正價值。

最後留個伏筆。一個 RAG 服務只開一個工具,很好管。但當你公司內部的工具、服務越來越多,全部掛給一個 agent,就會回到剛剛那個問題:塞爆 context、挑花眼、變笨。這時候要的,是一套「只把相關的工具挑出來給它」的機制 —— 動態發現,或者一個閘道。那是一個更大的題目,我留到後面專門講。這一集你先記住:單一個服務,工具越少越好。

這集帶走一句話:把 RAG 包成服務,先做最小的 —— 一個端點,問題進、答案出。再包一層 MCP,讓 agent 這種東西叫得到它。而最關鍵的,是克制:對外只開一個 rag_search。因為工具越多,agent 反而越笨、越容易選錯。少,才是對的 —— 這條之後你會在很多地方再遇到。