在今天這一期，我們將一起學習一種基于 MCP 提高大模型檢索外部知識精度的新思路，實測比 RAG 效果要好很多。

目前市面上講 MCP 的教程比較多，但大多數都是一些概念性的講解，最近我對 MCP 的體驗也比較多，我也切實體驗到了 MCP 確實是一項很有意義的技術標準，能幫助我們解決很多之前難以解決的問題，所以在今天的教程里，我從這樣一個實際的案例出發來跟大家聊一聊 MCP，整體的學習路徑如下：

在開始學習之前，我們先了解一下，RAG 技術目前的局限性。

一、背景：RAG 的局限性

RAG，即檢索增強生成（Retrieval-Augmented Generation），是目前大模型領域的一個熱門方向。它將信息檢索技術與生成式模型相結合，解決大模型在知識準確性、上下文理解以及對最新信息的利用等方面的難題。

在之前的教程中， 我們一起學習了如何在本地部署模型并且引入知識庫。

但是很多小伙伴可能對 RAG 有點誤解，覺得我們只要將一些額外的知識通過 RAG 導入，模型就能完美的掌握并且回答這些知識相關的問題。但事實和想象還是有差距的，大家在實際嘗試后可能會發現，RAG 的精準度似乎沒有那么好。

從 RAG 本身技術原理的角度出發，目前存在著以下問題：

• 檢索精度不足 ：首先，RAG 最核心的就是先將知識轉換成 “向量“ ，導入 “向量數據庫“，然后在將用戶輸入的信息也轉換成 “向量” ，然后再去向量數據庫匹配出相似的 “向量“，最后再由大模型去總結檢索到的內容。

從這個過程中我們看出，大模型僅僅起到了總結的作用，而檢索到信息的精準度大部分情況下取決于向量的相似度匹配，檢索結果可能包含無關內容（低精確率）或遺漏關鍵信息（低召回率）。

• 生成內容不完整 ：由于 RAG 處理的是文檔的切片，而切片的局部性注定了它無法看到整篇文檔的信息，因此在回答諸如“列舉XXX”“總結XXX”等問題時，一般回答是不完整的。

• 缺乏大局觀 ：RAG 無法判斷需要多少個切片才能回答問題，也無法判斷文檔間的聯系。例如，在法律條文中，新的解釋可能覆蓋舊的解釋，但 RAG 無法判斷哪個是最新的。

• 多輪檢索能力弱 ：RAG 缺乏執行多輪、多查詢檢索的能力，而這對推理任務來說是必不可少的。

盡管近期也有些新出現的技術，如 GraphRAG、KAG 等能夠在一定程度上解決這些問題，但都還不成熟，目前的 RAG 技術還遠遠達不到我們預期想要的效果。

下面，我們將介紹一個新的方案，通過 MCP + 數據庫來提高結構化數據的檢索精準度，基本上能夠實現 text to SQL 的效果，實測的檢索效果也要比 RAG 好很多，例如我們有這樣一份學生列表的信息：

我們用一個稍微復雜一點問題（身高 180-190cm 之間的女生有哪些？）來測試：

二、理論：了解 MCP 的基礎知識

在開始學習 MCP 之前，有一個繞不開的話題，就是 Function Call，我們先來回顧一下。

2.1 Function Call

以前的 AI 大模型就像一個知識豐富但被困在屋子里的人，只能依靠自己已有的知識回答問題，無法直接獲取實時數據或與外部系統交互，比如不能直接訪問數據庫里的最新信息，也不能使用一些外部工具來完成特定任務。

Function Call 是 OPEN AI 在 2023 年推出的一個非常重要的概念：

https://openai.com/index/function-calling-and-other-api-updates/

Function Call（函數調用） 本質上就是提供了大模型與外部系統交互的能力，類似于給大模型安裝一個 “外掛工具箱”。當大模型遇到自己無法直接回答的問題時，它會主動調用預設的函數（如查詢天氣、計算數據、訪問數據庫等），獲取實時或精準信息后再生成回答。

比如，我們在 Coze 這種零代碼 Agent 搭建平臺上看到的插件，其實都是基于 Function Call 的思路來封裝的：

https://www.coze.cn/store/plugin

這個能力確實是挺好的，給了大模型更多的可能性，但是它有一個比較大的缺點，就是實現成本太高了。

在 MCP 出現之前，開發者想實現 Function Call 的成本是比較高的，首先得需要模型本身能夠穩定支持 Function Call 的調用，比如我們在 Coze 中選擇某些模型時提示，選擇的模型不支持插件的調用，其實就是不支持 Function Call 的調用：

在之前的數據集教程 中，我們也提到了，在標準的 sharegpt 風格的數據集中就提供了專門用于 Function Call 訓練的特殊字段。

[   {     "conversations": [       {         "from": "human",         "value": "人類指令"       },       {         "from": "function_call",         "value": "工具參數"       },       {         "from": "observation",         "value": "工具結果"       },       {         "from": "gpt",         "value": "模型回答"       }     ],     "system": "系統提示詞（選填）",     "tools": "工具描述（選填）"   } ]

這也就意味著模型本身需要進行過專門的 Function Call 調用微調才能穩定支持這種能力。

另外還有一個比較大的問題，OPEN AI 最開始提出這項技術的時候，并沒有想讓它成為一項標準，所以雖然后續很多模型也支持了 Function Call 的調用，但是各自實現的方式都不太一樣。

這也就意味著，如果我們要發開一個 Function Call 工具，需要對不同的模型進行適配，比如參數格式、觸發邏輯、返回結構等等，這個成本是非常高的。

這也大大提高了 AI Agent 的開發門檻，所以在以前我們大部分情況下只能通過 Dify、Coze 這些平臺來構建 Agent。

核心特點

• 模型專屬：不同模型（GPT/Claude/DeepSeek）的調用規則不同

• 即時觸發：模型解析用戶意圖后直接調用工具

• 簡單直接：適合單一功能調用（如"查北京溫度"→調用天氣API）

痛點

• 協議碎片化：需為每個模型單獨開發適配層

• 功能擴展難：新增工具需重新訓練模型或調整接口

類比

• 不同品牌手機的充電接口（Lightning/USB-C），設備間無法通用

2.2 MCP

MCP（Model Context Protocol，模型上下文協議）是一種由 Anthropic 公司（也就是開發 Claude 模型的公司）推出的一個開放標準協議，目的就是為了解決 AI 模型與外部數據源、工具交互的難題。

通過 Function Call ，每次要讓模型連接新的數據源或使用新工具，開發者都得專門編寫大量代碼來進行對接，既麻煩又容易出錯。而 MCP 的出現就是為了解決這些問題，它就像是一個 “通用插頭” 或者 “USB 接口”，制定了統一的規范，不管是連接數據庫、第三方 API，還是本地文件等各種外部資源，都可以通過這個 “通用接口” 來完成，讓 AI 模型與外部工具或數據源之間的交互更加標準化、可復用。

最開始推出的時候，只有 Claude 客戶端支持，大家也沒把它當回事，但是后續由于 Cursor（Cursor 和 Claude 的關系大家都懂） 的支持，各種插件和工具也開始陸續提供支持；再加上最近 AI Agent 被 Manus 這個 “概念” 工具給炒的非常火熱，讓 MCP 逐步開始走進大眾視野，直到最近，OPEN AI 也宣布對 MCP 提供了支持：

這讓我真正的感覺到，MCP 真的做到了，它已經成為 AI 工具調用的 “行業標準”。

MCP Host，比如 Claude Desktop、Cursor 這些工具，在內部實現了 MCP Client，然后 MCP Client 通過標準的 MCP 協議和 MCP Server 進行交互，由各種三方開發者提供的 MCP Server 負責實現各種和三方資源交互的邏輯，比如訪問數據庫、瀏覽器、本地文件，最終再通過 標準的 MCP 協議返回給 MCP Client，最終在 MCP Host 上展示。

開發者按照 MCP 協議進行開發，無需為每個模型與不同資源的對接重復編寫適配代碼，可以大大節省開發工作量，另外已經開發出的 MCP Server，因為協議是通用的，能夠直接開放出來給大家使用，這也大幅減少了開發者的重復勞動。

比如，你如果想開發一個同樣邏輯的插件，你不需要在 Coze 寫一遍，再去 Dify 寫一遍，如果它們都支持了 MCP，那就可以直接使用同一個插件邏輯。

核心特點

• 協議標準化：統一工具調用格式（請求/響應/錯誤處理）

• 生態兼容性：一次開發即可對接所有兼容MCP的模型

• 動態擴展：新增工具無需修改模型代碼，即插即用

核心價值，解決三大問題

• 數據孤島 → 打通本地/云端數據源

• 重復開發 → 工具開發者只需適配MCP協議

• 生態割裂 → 形成統一工具市場

類比

• USB-C 接口：手機/電腦/外設通過統一標準互聯

2.3 MCP 對比 Function Call

注：調用方式這里反了。

從上面 MCP 的架構圖中我們可以看到，想要使用 MCP 技術，首先就是得找到一個支持 MCP 協議的客戶端，然后就是找到符合我們需求到 MCP 服務器，然后在 MCP 客戶端里調用這些服務。

3.1 MCP 客戶端（Host）

在 MCP 官方文檔中，我們看到已經支持了 MCP 協議的一些客戶端/工具列表：

https://modelcontextprotocol.io/clients

從表格里，我們可以看到，MCP 對支持的客戶端劃分了五大能力，這里我們先簡單了解即可：

• Tools ：服務器暴露可執行功能，供 LLM 調用以與外部系統交互。

• Resources ：服務器暴露數據和內容，供客戶端讀取并作為 LLM 上下文。

• Prompts ：服務器定義可復用的提示模板，引導 LLM 交互。

• Sampling ：讓服務器借助客戶端向 LLM 發起完成請求，實現復雜的智能行為。

• Roots ：客戶端給服務器指定的一些地址，用來告訴服務器該關注哪些資源和去哪里找這些資源。

目前最常用，并且被支持最廣泛的就是 Tools 工具調用。

對于上面這些已經支持 MCP 的工具，其實整體劃分一下就是這么幾類：

• AI 聊天工具：如 5ire、LibreChat、Cherry Studio

• AI 編碼工具：如 Cursor、Windsurf、Cline

• AI 開發框架：如 Genkit、GenAIScript、BeeAI

MCP Server 的官方描述：一個輕量級程序，每個程序都通過標準化模型上下文協議公開特定功能。

簡單理解，就是通過標準化協議與客戶端交互，能夠讓模型調用特定的數據源或工具功能。常見的 MCP Server 有：

• 文件和數據訪問類 ：讓大模型能夠操作、訪問本地文件或數據庫，如 File System MCP Server；

• Web 自動化類 ：讓大模型能夠操作瀏覽器，如 Pupteer MCP Server；

• 三方工具集成類 ：讓大模型能夠調用三方平臺暴露的 API，如 高德地圖 MCP Server；

下面是一些可以查找到你需要的 MCP Server 的途徑：

第一個是官方的 MCP Server 集合 Github 倉庫（https://github.com/modelcontextprotocol/servers），里面包含了作為官方參考示例的 MCP Server、被官方集成的 MCP Server 以及一些社區開發的第三方 MCP Server：

另外一個是 MCP.so（https://mcp.so/）：一個三方的 MCP Server 聚合平臺，目前收錄了 5000+ MCP Server：

其提供了非常友好的展示方式，每個 MCP Server 都有具體的配置示例：

• 
  

  MCP Market（https://mcpmarket.cn/），訪問速度不錯，可以按工具類型篩選：

我們先來嘗試一個最簡單的 MCP 接入示例，這里我們選擇 Cherry Studio。

Cherry Studio 對于小白用戶還是比較友好的，可以讓你在客戶端一鍵完成必備環境（這些環境是什么意思我們后面會講）的安裝：

在很多其他工具中，需要用戶手動在自己的電腦上安裝這些環境，比如 Windsurf：

所以對小白用戶，我建議先使用 Cherry Studio 上手嘗試。

打開 Cherry Studio 客戶端，我們到「設置 - MCP 服務器」把上面提示的兩個環境完成安裝：

然后，我們在搜索框搜索 @modelcontextprotocol/server-filesystem，這里我們接入一個簡單的文件系統 MCP：

點擊 + ，它會幫我們默認創建好一些 MCP Server 的配置，這里我們要補充一個參數，你允許讓它訪問的文件夾路徑，比如 ~/Desktop：

然后我們點擊保存，如果服務器的綠燈亮起，說明配置成功：

下面，我們到聊天區域選擇一個模型， 注意這里一定要選擇帶扳手圖標的模型，只有這種工具才支持 MCP（因為 Cherry Studio 其實本質上還是基于 Function Call 實現的 MCP，所以只有部分模型支持）

然后我們發現下面工具箱多了 MCP 的開關，我們把它打開：

然后我們嘗試讓他訪問我桌面上有哪些文件：

調用成功，這就是一個最簡單的 MCP 調用示例了。

但是，因為 Cherry Studio 是剛剛支持的 MCP，在實際測試中，我發現體驗并不是那么好，支持調用的模型種類比較少，而且在調用過程中不是很穩定。所以在后續的實戰章節，我們使用 VsCode + Cline 來調用 MCP。

不過這里用什么工具大家不用太糾結，目前 MCP 的發展勢頭非常迅猛，從最開始只有 Claude 支持，到現在已經有幾十個工具提供了支持，后續生態一定是會更加繁榮，各種工具也會越來越成熟，所以大家核心是掌握使用的思路。

首先，為了方便給大家進行演示，我們先來構造一個簡單的數據庫案例。

4.1 Mongodb

這里我們選擇的數據庫是 MongoDB：一款流行的開源的文檔型數據庫。MongoDB 使用文檔型數據模型，數據以 JSON 格式存儲。

為什么選擇 MongoDB 而不是 sqlite 之類的關系型數據庫呢，主要還是因為在關系型數據庫中，表結構是固定的，若要添加新字段或修改表結構，往往需要進行復雜的遷移操作。而 MongoDB 的文檔型數據模型，允許在同一個集合中存儲不同結構的文檔，應用程序可以根據需要靈活地添加或修改字段，無需事先定義嚴格的表結構，這對于我們想構建一個持續補充的結構化知識庫的場景，是非常友好的。

大家可以直接在官方文檔下載安裝 MongoDB Community Server（MongoDB 的免費開源版本）：

https://www.mongodb.com/try/download/community

安裝完成后，其會默認監聽我們本地的 27017 端口：

然后，為了可視化查看數據，我們還需要安裝 MongoDB Compass (MongoDB 提供的本地 GUI 可視化工具)

https://www.mongodb.com/try/download/compass

安裝完成后，我們通過 MongoDB Compass 客戶端鏈接到本地的 MongoDB Server：

隨后，大家就可以通過客戶端將自己的數據導入 MongoDB 數據庫，在后面的例子中，我們將使用一個學生信息的數據來進行演示，假定我們的數據是這樣的：

如果你不知道怎么導入 MongoDB ，可以借助 AI 來幫你編寫導入腳本，然后根據 AI 提示進行導入即可：

提示詞：幫我編寫一個腳本，可以將當前表格中的數據導入我本地的 MongoDB 數據庫，數據庫的名稱為 studentManagement

然后根據 AI 提示運行腳本進行導入即可，成功導入后的效果：

學生信息表：

學生分數表：

4.2 VsCode + Cline

通過對幾個支持了 MCP 的客戶端進行測試，我覺得 Cline 對 MCP 的兼容效果還是不錯的，也是開源、免費、國內都可以直接使用的，但是相對于 Cherry Studio 這種客戶端，Cline 的使用對于小白用戶還是有點成本的，因為它本質上是一個基于 VsCode 的 AI 編碼輔助插件。

Cursor、Windsurf 這種付費的 AI 編程客戶端，其實都是基于微軟開源的編程 IDE VsCode 二次開發、包裝出來的，在其中內置了一些 AI 代碼編輯能力，一般都需要按月付費，并且走海外的支付渠道。

而 Cline 則是完全開源，并且直接作為 VsCode 插件提供，并且支持配置各種三方的 AI API，非常靈活，所以如果你是 AI 編程小白，也是推薦使用 VsCode + Cline 來進行入門。

Cline 的安裝也比較簡單，直接在 VsCode 插件市場搜索，Cline 找到后點擊安裝即可（注意這里還有很多非官方的版本，直接安裝那個下載量最大的就好）：

安裝完成后，我們在左側工具欄找到 Cline 的圖標，點擊打開設置，然后進行模型配置：

這里支持了多種模型提供商，大家按需選擇即可：

模型配置完成之后，我們可以在聊天窗口進行測試，如果正常輸出則說明配置成功：

4.3 在 Cline 中配置 mcp-mongo-server

接下來，我們需要找到一個支持 MongoDB 的 MCP Server，本來想自己開發一個，但是簡單搜了一下，發現已經有幾個了：

https://github.com/modelcontextprotocol/servers?tab=readme-ov-file

這里我們選擇使用 mcp-mongo-server：

https://github.com/kiliczsh/mcp-mongo-server

下面我們開始在 Cline 中配置 MCP Server，首先點擊上方工具欄的 MCP Server 圖標，可以發現這里內置了一批 MCP Server 列表，并且也支持一鍵安裝：

但是搜了下我們選擇的 MCP Server 并沒有在這個內置列表里，所以我們選擇手動配置，其實手動配置也非常簡單，我們點擊 installed tab，然后點擊下方的 Configure MCP Servers，然后發現打開了一個 JSON 文件，這就是 Cline 用于存放 MCP 配置的地方，里面只有一個空對象：

每個 MCP Server 都會提供這份配置的寫法，比如我們選擇的 mcp-mongo-server，這里所說的在 Claude Desktop 中使用，其實在任何支持了 MCP 的客戶端中都可以這樣配置：

配置看著挺復雜的，但實際上它支持提供了三種配置不同的寫法，其實每個配置中只包含兩個關鍵參數：

• command：指定在命令行中通過什么命令進行執行，在這個例子中，所有配置都使用 npx 命令（也就是 Node.js 環境）。

• args：是一個數組，包含傳遞給 command 的參數。

這三個配置的意思分別是：

• mongodb ：運行 mcp-mongo-server npm 包，并且使用指定的 MongoDB 連接字符串，默認是讀寫模式。

• mongodb-readonly ：同樣運行 mcp-mongo-server npm 包，使用相同的 MongoDB 連接字符串，但增加了--read-only 參數，意味著這個配置會以只讀模式運行。

• mongodb-github ：從 GitHub 上的 kiliczsh/mcp-mongo-server 倉庫獲取包來運行，而不是 npm 包，使用相同的 MongoDB 連接字符串，并且也設置了只讀模式。

這里我們直接使用其最簡單的配置，本地 mongo 一般不會設置用戶名密碼，我們可以直接到客戶端查看這個數據庫的連接地址：

然后配置如下：

{     "mongodb": {       "command": "npx",       "args": [         "mcp-mongo-server",         "mongodb://localhost:27017/studentManagement?authSource=admin"       ]     }   } }

講這個配置粘貼到 Cline 的 MCP 配置文件，然后我們發現左側的 mongodb 綠燈亮起，說明配置成功：

注意，這里我們需要使用到的是 npx 命令，前提是你電腦上需要有 Node.js 環境，可以到 Node.js 官方網站下載一鍵完成安裝：

安裝完成后，可以通過 npx -v 來測試環境是否配置成功：

然后我們測試一下效果（注意在 Cline 里是幾乎所有模型都可以支持 MCP 的，原理我們后面會講）：

我們問一個關于統計學生數量的問題，目前一共有多少名學生？：

然后我們發現聊天窗口自動識別到了這個問題需要調用 MCP，并且詢問我們是否允許調用 mongodb MCP，我們點擊允許：

然后 MCP 準確從數據庫中查詢出了結果，然后給出了回答。

然后我們再問一個更復雜一點的問題：有多少身高大于 180、姓李的男同學？

模型依然給出了準確的結果。

我們再上點難度，穩點更模糊的問題：求張老師的聯系方式

我們繼續上難度，有哪些同學期末考試比平時的考試成績好？

這時候，模型并不知道期末考試、平時成績對應的字段是什么，所以模型先嘗試去在 scores 表下查詢了一列，然后看到了所有字段：

然后模型生成了一個非常詳細的查詢條件：

然后從檢索結果中準確的給出了答案：

4.4 通過 Prompt 優化查詢效果

MCP Server 為模型提供了訪問數據庫的能力，但是數據庫的表結構對于模型還是完全黑盒的，所以模型只能靠猜，或者去先獲取一下表結構，再進行后續操作，猜還是有可能會出錯的，多獲取一次表結構也會讓回答速度變慢，以及消耗更多的 Token。

所以這里有個優化技巧，我們直接在全局提示詞里將表結構的關鍵信息，和我們的明確要求告訴模型，就能讓模型更準確、高效的響應了，關于表結構的說明大家可以去用 DeepSeek 來生成：

使用中文回復。 當用戶提問中涉及學生、教師、成績、班級、課程等實體時，需要使用 MongoDB MCP 進行數據查詢和操作，表結構說明如下： # 學生管理系統數據庫表結構說明 ## 1. 教師表 (teachers) | 字段名 | 類型 | 描述 | 約束 | 示例 | |--------|------|------|------|------| | _id | String | 教師ID | 主鍵 | "T001" | | name | String | 教師姓名 | 必填 | "張建國" | | gender | String | 性別 | "男"或"女" | "男" | | subject | String | 教授科目 | 必填 | "數學" | | title | String | 職稱 | 必填 | "教授" | | contact.phone | String | 聯系電話 | 必填 | "13812345678" | | contact.office | String | 辦公室位置 | 必填 | "博學樓301" | | contact.wechat | String | 微信(可選) | 可選 | "lily_teacher" | | isHeadTeacher | Boolean | 是否為班主任 | 可選 | true | ## 2. 班級表 (classes) | 字段名 | 類型 | 描述 | 約束 | 示例 | |--------|------|------|------|------| | _id | String | 班級ID | 主鍵 | "202301" | | className | String | 班級名稱 | 必填 | "2023級計算機1班" | | grade | Number | 年級 | 必填 | 2023 | | headTeacherId | String | 班主任ID | 外鍵(teachers._id) | "T003" | | classroom | String | 教室位置 | 必填 | "1號樓302" | | studentCount | Number | 學生人數 | 必填 | 35 | | remark | String | 備注信息 | 可選 | "市級優秀班集體" | ## 3. 課程表 (courses) | 字段名 | 類型 | 描述 | 約束 | 示例 | |--------|------|------|------|------| | _id | String | 課程ID | 主鍵 | "C001" | | courseName | String | 課程名稱 | 必填 | "高等數學" | | credit | Number | 學分 | 必填 | 4 | | teacherId | String | 授課教師ID | 外鍵(teachers._id) | "T001" | | semester | String | 學期 | 格式"YYYY-N" | "2023-1" | | type | String | 課程類型 | "必修"或"選修" | "必修" | | prerequisite | String | 先修課程ID | 可選,外鍵(courses._id) | "C003" | ## 4. 學生表 (students) | 字段名 | 類型 | 描述 | 約束 | 示例 | |--------|------|------|------|------| | _id | String | 學號 | 主鍵 | "S20230101" | | name | String | 學生姓名 | 必填 | "王強" | | gender | String | 性別 | "男"或"女" | "男" | | birthDate | Date | 出生日期 | 必填 | new Date("2005-01-15") | | enrollmentDate | Date | 入學日期 | 必填 | new Date(2023, 8, 1) | | classId | String | 班級ID | 外鍵(classes._id) | "202301" | | contact.phone | String | 聯系電話 | 必填 | "13812345678" | | contact.email | String | 電子郵箱 | 必填 | "20230101@school.edu.cn" | | contact.emergencyContact | String | 緊急聯系人電話 | 必填 | "13876543210" | | address | String | 家庭住址 | 必填 | "北京市海淀區中關村大街1棟101室" | | profile.height | Number | 身高(cm) | 必填 | 175 | | profile.weight | Number | 體重(kg) | 必填 | 65 | | profile.healthStatus | String | 健康狀況 | 必填 | "良好" | ## 5. 成績表 (scores) | 字段名 | 類型 | 描述 | 約束 | 示例 | |--------|------|------|------|------| | _id | String | 成績記錄ID | 主鍵 | "S20230101C001" | | studentId | String | 學生ID | 外鍵(students._id) | "S20230101" | | courseId | String | 課程ID | 外鍵(courses._id) | "C001" | | score | Number | 綜合成績 | 0-100 | 85 | | examDate | Date | 考試日期 | 必填 | new Date(2024, 5, 20) | | usualScore | Number | 平時成績 | 70-100 | 90 | | finalScore | Number | 期末成績 | 0-100 | 80 | ### 補考成績記錄說明 補考記錄在_id后添加"_M"后綴，如"S20230101C001_M" ## 表關系說明 1. **一對多關系**:    - 一個班級(classes)對應多個學生(students)    - 一個教師(teachers)可以教授多門課程(courses)    - 一個學生(students)有多條成績記錄(scores) 2. **外鍵約束**:    - students.classId → classes._id    - courses.teacherId → teachers._id    - scores.studentId → students._id    - scores.courseId → courses._id    - classes.headTeacherId → teachers._id

然后我們到 Cline 設置中找到 Custom Instructions ，把這段提示詞粘貼進去，點擊 Done：

然后我們開一個新的聊天窗口，重新來問這個問題：

有哪些同學期末考試比平時的考試成績好？

有了全局提示詞指引后，模型直接給出了一個非常全面的思路：

在最后的結論中，按課程進行分組，給出了具體的各個科目期末考試大于平時考試的情況：

我們最后再來問一個更復雜的問題：

有個學計算機的周同學，他老師的聯系方式給我一下

在這個查詢中，模型先找到了所有姓周的同學，然后根據這些通過的班級過濾除了計算機相關班級，最后根據班級關聯的 teacherId 找到了教師信息。

4.5 對比知識庫

然后，我們將同樣的數據集導入知識庫，這里我們使用 Coze 進行演示，先來試試一張表的情況：

效果還可以，然后換上我們剛剛復雜一點的問題：

這個結果有點無語。。我們換個問題來測試：

模型依然無法分析出準確信息，這個對比就很明顯了，在這種數據的檢索場景下，MCP + 數據庫明顯優于傳統 RAG 的方式。

4.6 目前的局限性

由于 MCP 技術才剛剛爆發，很多技術還不成熟，目前這個方案還存在一定局限性：

• 切忌讓 AI 檢索過大的數據，因為這種方式不像 RAG，每次只檢索一小部分需要的內容，它是真正的會執行 SQL，你要多少數據，就查多少數據，如果一次查詢數據量過大，會讓你消耗大量 Token，甚至讓 MCP 客戶端卡死；

• 很多 MCP 客戶端是依靠大量系統提示詞來實現與 MCP 工具的通信，所以一旦使用 MCP，Token 的消耗量一定會大幅增長。

但是，未來可期，在這之前，其實就有一些基于 Function Call + Text2SQL 實現的類似能力，我也有過嘗試，但由于開發成本以及恢復準確性的問題，沒有得到普及。

而今天我們一起學習的這種 MCP + 數據庫的方式真正的降低了開發成本，甚至是零代碼，而且準確性也非常高，我相信未來一定會成為一種非常熱門的查詢方式，在智能客服、倉儲管理、信息管理這些結構化數據檢索場景下應該會替代掉傳統的 RAG 方式。

，讓開發者可以借助 AI 助手直接訪問代碼倉庫，讀取文件內容、查看 PR 變更、理解 Issue 描述，甚至直接操作代碼管理任務，比如創建 PR、合并分支、發布版本等。

簡單來說，Gitee MCP Server 讓 AI 不再是「代碼的旁觀者」，真正成為了參與軟件開發過程的智能助手。

開源地址：
https://gitee.com/oschina/mcp-gitee