1. 寫在最前面

最近有一項任務是寫舊版本遷移到新版本的支持文檔，文檔的編寫是借助于 cursor 幫忙寫的。但是實現的方式不夠優雅，因為 cursor 還不支持直接訪問公司的 confluence 文檔站，筆者只能：

• 首先，從 confluence 上下載兩個不同版本的 api 文檔說明

• 然后，將轉為 pdf 格式的文檔通過 agent 的方式，讓 cursor 可以瀏覽到

• 最后，cursor 再針對兩份文檔異同，來實現一個舊文檔遷移到新文檔的說明

這個方式雖然也能完成需求，但是總歸實現的方式還需要人工干預，不夠簡潔。最近 MCP 的概念很熱，并且借助這個功能，似乎能夠簡化筆者類似需求的實現，剛好趁著五一節前的大塊空余時間，先來理解一下基本概念。

2. 基本概念

為了避免梳理和記憶的內容同質化，在理解 MCP 的概念的時候，筆者盡量使用自己能夠理解和記憶的方式進行，故很多地方可能存在出入，如果有不準確的地方，歡迎指出！

2.1 Why MCP

2.1.1 大模型訪問的局限

在使用 cursor coding 的時候，因為只需要訪問項目內的文件，同時現在也支持運行大部分的 Terminal 命令，所以大部分的時候，是能夠滿足需求的。

但是在讓 cursor 訪問項目以為的文件，就不行了，參考下面的問答：

2.1.2 過渡階段—Function Call

• 未使用 function Call

  

• 使用 function Call

  

大模型的 function Call 功能通常指的是在使用大語言模型（如 GPT 系列）時，模型能夠調用特定的功能或接口來執行某些操作。這種功能可以增強模型的交互性和實用性，使其能夠更好地滿足用戶的需求。

注：function call 作為過渡階段的原因在于 function call 平臺依賴性強，不同 LLM 平臺的 function call API 實現差異較大。例如，OpenAI 的函數調用方式與 Google 的不兼容，開發者在切換模型時需要重寫代碼，增加了適配成本。除此之外，還有安全性，交互性等問題。

2.1.3 當前階段— MCP

MCP （Model Context Protocol，模型上下文協議）定義了應用程序和 AI 模型之間交換上下文信息的方式。這使得開發者能夠以一致的方式將各種數據源、工具和功能連接到 AI 模型（一個中間協議層）。

注：MCP 可以理解成電腦轉接頭是用來連接不同類型的接口或端口，以便于設備之間的互聯和兼容。比如

• USB-C 轉 USB-A：將 USB-C 設備連接到 USB-A 端口（如傳統電腦）。
• USB-C 轉 HDMI：將 USB-C 設備連接到 HDMI 顯示器或電視。
• USB-C 轉 VGA：將 USB-C 設備連接到 VGA 顯示器。

筆者個人的簡單理解， 「MCP」可以理解成類似于「GRPC」協議的一種協議標準，使用這個協議實現的 server 、client 可以很方便的兼容和適配到其他的大模型應用上。

大模型訪問數據的需求是天然存在的

只不過 MCP 協議將數據連接到模型的這個環節可以更智能更統一。Anthropic 基于這樣的痛點設計了 MCP，充當 AI 模型的「萬能轉接頭」，讓 LLM 能輕松的獲取數據或者調用工具。

3. 碎碎念

大概理解了一下概念，想要動手實踐，假期前的最后幾小時可能不允許了，所以就先記錄到這里吧，希望大家假期愉快吖：

• 人生下來不是為了拖著鎖鏈，而是為了展開雙翼。

• 不論世界如何，都要向著陽光野蠻生長，成為照亮世界的大人。

• 成年人的煩惱，和誰說好像都不合適，要學會自我消化，想開、看開、放開。

4. 參考資料

• Introduction - Model Context Protocol

• MCP(Model Context Protocol) ，一篇就夠了

• 回調函數 - 維基百科，自由的百科全書

• 如何使用 Function Calling 功能_大模型服務平臺百煉(Model Studio)-阿里云幫助中心

• Introduction - Model Context Protocol

• Core architecture - Model Context Protocol