Model Context Protocol for Beginners — Host, Client, Server in 5 Minutes

語言模型能讀懂互聯網上幾乎所有文本，卻對用戶的個人世界一無所知。它的知識是靜態的，沒有任何一個月前的天氣數據、今天的日程表，也無法讀取電腦裡的文件或訪問公司數據庫。這種隔離性是語言模型的根本限制——它只能對話，不能行動。為了補救這個缺陷，工程團隊多年來採用同一種解決方案：手工編寫整合代碼。每增加一個新應用或新工具，就需要寫一份新的膠合代碼，不同應用之間的代碼也互不相同。這導致了一個經典的組合爆炸問題，專業人士稱之為「M by N 問題」：M 個 AI 應用乘以 N 個工具和數據源，就需要 M×N 個整合。以 6 個應用和 100 個工具為例，就得維護 600 個獨立的整合點，每一個都有自己的生命週期和故障點。這種混亂的局面在軟件史上出現過多次。在標準化之前，每個數據庫都需要為每種編程語言單獨編寫驅動程序；在 USB 標準出現前，每個設備都有自己獨特的連接器。歷史證明，當複雜度達到臨界點時，整個行業會聚集在某個統一標準上。

AI 生態的這個標準就是 Model Context Protocol（MCP）。它是由 Anthropic 構建的開放標準，現在得到業界廣泛支持，專門用於連接 AI 應用與外部世界的數據、工具和工作流程。MCP 的設計思想完全類似於 USB-C：在多種連接方式時代，每台設備有自己的連接器；有了 USB-C 之後，一種連接方式通吃一切。同樣地，有了 MCP，開發者只需構建一次對應協議的整合，任何應用、任何模型都能使用，從而實現真正的互操作性。

MCP 的架構由三個角色組成，理解這三個角色就理解了整個系統。第一是 Host（主機），即用戶正在使用的 AI 應用，比如 Claude Desktop、VS Code、Cursor，這是用戶直接交互的終端。第二是 Client（客戶端），Host 並不直接連接工具，而是為每個要訪問的外部系統創建一個客戶端連接。可以把客戶端想像成一位外交官，它代表 Host 與外部系統溝通協議。第三是 Server（伺服器），這是實際暴露有用功能的程序，它可能是你的文件系統、數據庫、天氣 API，既可以在本地運行也可以在云端運行，但無論如何都遵循 MCP 協議。

當用戶詢問「現在印度浦那（Pune）的天氣怎樣」時，整個流程體現了 MCP 的優雅之處。首先是發現階段，客戶端詢問天氣伺服器「你能做什麼」，伺服器回應「我有一個天氣工具，給我位置我就給你氣象數據」。然後是調用階段，模型選中了這個工具，客戶端向伺服器發送參數「位置：Pune」。最後是結果階段，伺服器進行真實工作，實際調用天氣 API，把數據返回給客戶端，模型再把這個數據折疊進一個自然語言回應：「浦那現在 28 度且部分多雲」。整個過程中，模型從不需要知道天氣 API 的實現細節，它只需要知道有一個說 MCP 語言的伺服器在那裡。這相同的三步流程（發現、調用、返回）適用於數據庫、Slack 工作區、文件系統，以及任何外部系統。正因為如此，MCP 才如此強大：為你的產品構建一個 MCP 伺服器，現在的每個兼容應用都能用到它，未來還會有更多應用支持，實現一次構建、到處集成的承諾。