MCP模型上下文協定教程

如果你一直在擺弄人工智慧代理、LLM 和 副駕駛型助手 或者克勞德，我相信你肯定看過類似這樣的縮寫。 MCP無所不在，也許你並不完全清楚它是什麼。你並不孤單：這是一個相對較新的概念，它有很多技術內容，而且官方文件雖然不錯，但如果你只是想了解它如何融入你的專案中，它可能會顯得過於晦澀難懂。

本文將把所有這些概念具體化。您很快就會明白。 模型上下文協定究竟是什麼？它為何如此重要？它的內部運作原理是什麼？以及如何使用它？ 將您的語言模型與實際工具連接起來：從本地 Git 倉庫到 Google 雲端硬碟、Google 日曆、Azure 內部系統，或 Claude Desktop 等桌面應用程式。我們還將介紹其優勢、限制、安全性、實際範例，以及如何建立您自己的 MCP 伺服器。

什麼是模型上下文協定（MCP）？為什麼它如此受關注？

模型上下文協定（MCP）是一種 一種開放標準，旨在使人工智慧模型能夠與外部工具、數據和服務進行統一通訊。這個想法來自 Anthropic（Claude 背後的公司），但該協議的設計是中立的：它不屬於任何特定的提供者或模型。

最常被提及且相當準確的比較是： MCP 是軟體的什麼？ USB 或者說，USB-C 是 硬件就像您不會為每個裝置都配備不同的線纜一樣，您也不會為 AI 代理需要通訊的每個 API、CRM、資料庫或服務都進行臨時整合。 MCP 充當“通用適配器”，使模型能夠訪問真實世界的上下文。

在 MCP 出現之前，每次你想讓你的 AI 助手與你的工單系統、CRM 系統或 wiki 系統進行互動時，你都必須進行設定。 自訂集成，包含大量黏合代碼，而重用性很低。每個工具都有自己的 JSON 格式、身份驗證方法和資料回傳方式。 MCP 試圖透過提供一種標準化的方法來描述工具、資源和訊息流，從而打破這種混亂局面。

這與當前所謂的趨勢完全吻合 代理商 應用程式 或代理應用程式：其中一個或多個語言模型不僅回應訊息，還能推理、規劃、呼叫工具、查詢資料來源，並且或多或少地自主地協調任務。

MCP 基本架構：主機、用戶端、伺服器和功能

要真正理解 MCP，有必要熟悉其主要組成部分。該協定定義了一種架構，該架構包含： 三種基本角色、三種能力 從伺服器暴露出來的。

關於角色，MCP 區分如下：

• 特別來賓任何使用一個或多個LLM並希望透過MCP擴展其功能的應用程式。這可以是像VS Code這樣的IDE，像Zed或Replit這樣的程式碼編輯器，桌面應用程序，Web服務，或生產企業代理。
• 客戶代表主機與 MCP 伺服器通訊的元件。它們管理連線、發現可用工具、解析資源並處理訊息交換。
• 服務器：展現標準化 MCP 功能的流程： 工具、資源和提示在底層，它們連接到本機資料來源（檔案系統、Git 儲存庫、帶有提示符的 markdown 檔案或安裝在同一網路上的資料庫）或遠端資料來源（HTTP API、雲端服務、SaaS）。

實際上，你可以這樣想像流程： 主機運行 MCP 用戶端，該客戶端連接到一個或多個 MCP 伺服器。這些伺服器反過來又「封裝」了 API， 數據庫第三方服務或公司內部數據，將所有這些轉化為人工智慧可以使用的標準化能力。

在該架構中也出現了兩個重要的資料來源概念：

• 本地資料來源伺服器的本機資源，例如檔案系統、Git 儲存庫、帶有提示符號的 markdown 檔案或安裝在同一網路上的資料庫。
• 遠程服務：可透過網路存取的遠端服務：REST API、雲端服務（如 Google Drive、Zoom、Slack）、企業 CRM、電子病歷等。

MCP 的妙處在於，對於 AI 模型和宿主機而言， 資訊來源是本地文件、GitHub 還是公司 API 都無關緊要。它總是以相同類型的消息和相同的結構封裝到達。

MCP 功能：工具、資源與提示

MCP 的基本功能單元是該協定所稱的 能力或實力共有三種類型，每一種都涵蓋了模型與環境交互作用的不同面向。

工具 這些本質上是模型可以呼叫的函數。伺服器以結構化的方式（名稱、描述、參數）公開這些函數，然後由LLM進行決策。 他是否想調用那個工具，以及會用什麼理由來論證這一點。例如：「列出最近的提交」、「建立日曆事件」、「在雲端硬碟中搜尋文件」、「查詢 CRM」或「執行 SQL 查詢」。

資源中心 它們代表應用程式認為有用的上下文訊息，通常會將其註入到提示中。 沒有模型明確提出要求例如，資源可以是儲存庫狀態摘要、最新銷售指標、病患病史或項目描述。資源可以是靜態的，也可以根據 URI 或模板動態產生。

提示 這些是伺服器提供給主機或使用者的可重複使用指令範本。例如，它們可以定義模型應扮演的角色（例如「擔任 Git 專家」）、回應的結構，或處理特定領域的特定格式。 它們有助於規範模型的引導方式。 無需一遍又一遍地重寫相同的文字。

這種劃分具有非常強大的實際效果： 它清楚地區分了模型自行決定的內容（呼叫工具）和應用程式預先提供的內容（資源和提示）。這種分離有助於代理設計、安全性和稽核。

一個實際範例：用於瀏覽 Git 倉庫的 MCP 伺服器

理解 MCP 的一個好方法是看一個具體的例子。假設你想創建一個小型線上應用程式… 命令 你可以和一位法學碩士（LLM）聊天，他們會在需要的時候提供協助。 可以檢查本地 Git 倉庫 為了更好地回應：查看狀態、查看最近的提交、了解專案結構等。

按照一些參考教學中所描述的方法，你可以用類似這樣的東西組裝起來： MCP 伺服器已實現 蟒蛇 使用官方 SDK該伺服器將暴露以下內容：

• 一 工具 取得儲存庫的目前狀態（已修改、已新增、已刪除的檔案）。
• 另一 工具 列出最近的 N 次提交（例如 50 次），包括作者、日期和訊息。
• Un 資源 傳回儲存庫的高階文字摘要（主要資料夾、使用的技術、大致大小…），摘要由檔案系統和 Git 資訊產生。
• Un 提示 保存在一個 Markdown 文件中，該文件描述了模型應如何作為「Git 存儲庫瀏覽器」運行以及如何使用可用工具。

為了與 Git 交互，伺服器可以依賴該函式庫。 GitPython 可以輕鬆瀏覽提交、分支和狀態 無需直接調用 Git 二進位。方法註釋可用於隱式地為每個工具產生元資料：例如，工具的功能、接受的參數等等。

在這種情況下，伺服器將透過簡單的傳輸協定與主機通信，例如 標準輸入/輸出 (stdio)這是一個非常方便的測試選擇， 本地工作流程 或者將其與桌面應用程式集成，因為您只需啟動該進程並像與任何控制台程式一樣與其通信即可。

MCP客戶端，「代理」模型和應用程式的客戶端

在該範例的另一端，我們有以使用者身分在您的電腦上運行的部分：a Agentic 應用程式 它統籌一切。該應用程式通常由三個不同的部分組成。

一方面， 模特兒客戶這概括了您如何與您使用的特定 LLM 進行通訊（OpenAI（例如，使用 Claude 或其他供應商，甚至是自架模型）。此客戶端管理聊天完成調用，處理提供者格式的工具、令牌等。建議定義一個通用接口，以便將來更改模型就像更改實現一樣簡單。

另一方面， MCP 用戶端 該元件與我們剛才描述的 Git 伺服器通訊。它負責：

• 使用選定的傳輸方式（例如，stdio）連接到伺服器。
• 探索可用功能：工具、資源和提示。
• 請核實該資訊 這樣你就不用一直問伺服器一些不會改變的事情了。
• 例如，解析動態資源，從資源範本產生 URI，以取得特定儲存庫的摘要。

最後，將一切連結起來的關鍵在於… 代理人或代理人一個管理應用程式主循環的類別：讀取使用者的請求，建立上下文，將查詢傳送到模型，在 LLM 請求時執行工具，並傳回最終回應。

一個典型的周期可能是：

1. 從使用者查詢讀取使用者查詢 終端.
2. 建構埃爾 系統提示結合了 MCP 範本和資源以及儲存庫摘要.
3. 根據用戶輸入的問題建立用戶訊息。
4. 將 MCP 用戶端提供的工具清單作為附件新增至郵件。
5. 使用範本客戶端將所有內容傳送到LLM。
6. 分析回應：如果模型請求運行工具，則呼叫 MCP 伺服器，取得結果並將其轉發給模型以改善其回應。
7. 將最終答案列印給用戶，並提出下一個問題。

這個設計清楚地說明了為什麼 MCP 與 Agentic Apps 如此契合： 將編排邏輯（代理）與模型整合以及與工具整合分開。每個元件都有其作用，MCP 為所有你想添加的工具和資料來源提供了一個穩定的連接協定。

MCP 內部工作原理：請求和回應流程

雖然使用 MCP 不需要了解記憶體規格，但最好還是清楚了解一下。 經典的請求/回應流程 它遵循主機和伺服器之間的協定。

想像一下這樣一個典型場景：人工智慧助理想要查看你今天的日程安排。工作流程大致如下：

• 模型偵測到您要求的內容需要外部數據， 產生 MCP 請求 選擇合適的工具（例如，「取得今天的事件」）。
• MCP 用戶端根據協定規則請求封包，並將其傳送到關聯的伺服器。
• MCP 伺服器將請求轉換為底層 API（例如 Google 日曆、Exchange 或其他系統），執行該 API，並擷取資料。
• 伺服器以標準 MCP 格式向 MCP 用戶端回傳回應，資料已整理好，可供模型理解。
• 主機將該回應傳遞給 LLM，LLM 將其整合到其推理中，並產生最終答案給使用者。

同樣的規律也適用於更複雜的情況： Zoom 會議記錄、從 Google 雲端硬碟檢索文件、結合影像和病患記錄分析醫療數據等等。重要的是，該模型不需要了解每個 API 的任何資訊：它始終使用「MCP 語言」。

當您希望客服人員以級聯方式呼叫多個工具時，這種抽象就顯得至關重要：例如，從 CRM 系統中檢索客戶歷史記錄，使用這些資料產生銷售提案，將其儲存在雲端硬碟中，然後在日曆中安排會議進行審核。借助 MCP，所有這些都可以透過以下方式完成： 單一訊息和工具方案無需每次整合都重新發明輪子。

MCP 中的安全性、身分驗證和法規遵循

當允許人工智慧模型存取真實系統時，關鍵點之一是安全性： 你可以查看哪些數據，你可以對這些數據做什麼，以及如何進行身份驗證MCP 的設計考慮到了這些問題，並且通常依賴標準身份驗證機制。

其中最常見的有：

• 身份驗證 2.0廣泛用於 Google、Microsoft 或 Slack 等服務。 MCP 將請求委託給 OAuth，OAuth 充當「數位守門人」：使用者授予特定權限（讀取日曆、存取某些檔案等），MCP 伺服器使用這些令牌代表使用者執行操作。
• API令牌這是許多 SaaS 服務或內部 API 的典型特徵。 MCP 伺服器可能需要特定的令牌才能存取特定的後端，而主機則以安全的方式提供該令牌。
• 基於角色的訪問除了身份驗證之外，授權也很重要。 MCP 可以與基於角色的系統集成，以便： 並非所有工具都對所有使用者開放。或限制代理可以存取 API 的哪些部分。

在受監管領域（醫療保健、金融、公共部門），遵守法規也至關重要，例如： GDPR、SOC 2 或 ISO 認證雖然 MCP 本身並不「遵守」任何規則（它只是一個協議），但它的設計使得按照以下規則封裝存取變得容易：您可以審計調用、控制哪些資料離開環境、加密流量並建立清晰的存取策略。

例如，一家公司可能透過內部 MCP 伺服器公開電子健康記錄，但是 嚴格限制可用工具、傳回每筆記錄的欄位以及可以呼叫這些工具的人員。AI代理仍然看到的是一套同質的工具，但其底層卻有很多治理和控制措施。

MCP的實際應用：從開發到機器視覺

MCP理論遠非完美，它已經在實踐中被應用。 涵蓋了廣泛的真實世界場景。 這些是一些最有趣的。

在軟體開發領域，像 Zed 這樣的編輯器或像 Replit 這樣的平台開始使用 MCP，以便它們的程式碼助理可以… 讀取專案文件，即時追蹤更改，檢查 日誌 或與版本控制系統交互對於編輯來說，助手不再是“盲人”，而是開始了解你的儲存庫中實際包含哪些內容。

在商業環境中，許多公司將它們連結起來 內部維基、服務台系統、客戶關係管理系統或知識庫 透過 MCP 實現 AI 助理。這使得客服人員能夠透過始終參考最新且特定於組織的數據來回答支援問題、產生報告、提出業務建議或處理工單。

另一個正在擴張的領域是 可處理本機資料的桌面助手例如，Claude 的桌面應用程式使用 MCP 安全地存取您電腦上的文件，而無需將其上傳到雲端。這使得一些實用功能成為可能，例如文件摘要、搜尋相關程式碼片段或幫助您處理本機儲存的程式碼。

而且，儘管MCP仍處於早期階段，但將其應用於專案中已取得了相當大的進展。 具有強上下文分量的電腦視覺例如，在醫療診斷中：助手可以協調視覺模型來分析影像（X光片、視網膜等），同時查閱病史、實驗室結果和臨床試驗，所有這些都透過MCP伺服器提供的工具實現。

Google 生態系統中的 MCP：雲端硬碟、日曆和會議

MCP 的另一個完美契合領域是 Google Workspace 生態系統。其基本理念是部署一個 MCP 伺服器可作為連接 Google 雲端硬碟和 Google 日曆 API 的橋樑 這樣，人工智慧就可以搜尋文件、總結文件、對文件進行分類、建立事件、管理提醒等等。

以 Google Drive 為例，設計良好的 MCP 伺服器可以讓 AI 模型實現以下功能：

• 演出 使用自然語言進行文件搜索 （「把上一季的銷售報告拿來給我看看」）。
• 閱讀這些文件的內容，並產生摘要、行動要點或版本比較。
• 自動標記和整理文件 根據內容（​​合約、履歷、會議記錄…）存放在資料夾中。
• 管理存取權限，前提是必須有清晰且配置完善的安全規則。

典型的設定包括：在 Google Cloud 控制台中啟用 Google Drive API，建立憑證，告訴 MCP 伺服器如何進行驗證（通常透過 OAuth），以及定義允許哪些操作（只讀、讀寫等）。 設定完成後，任何相容於 MCP 的主機都可以利用該伺服器。 無需了解谷歌的任何細節。

谷歌日曆的邏輯類似。專用的 MCP 伺服器可以：

• 讀取一個或多個使用者的日曆事件。
• 尋找合適的日程表空檔 並自動建議會議時間。
• 根據代理人的決定建立、移動或取消事件。
• 根據上次會議討論的內容產生後續提醒。

從用戶體驗的角度來看，這意味著你可以告訴你的助手類似這樣的信息：“下週找半小時和瑪爾塔談談 X 項目”，而多虧了 MCP，助手會查看日程安排，提出一個時間段，並創建包含相應視頻通話鏈接的邀請。

更進一步，可以將日曆、雲端硬碟和視訊會議平台結合： AI 可以檢索先前的上下文（文件、電子郵件、筆記），在會議期間為您提供協助，並在會議結束後產生摘要和任務。所有這些都使用相同的協議，但底層使用不同的 MCP 工具。

智慧會議：與 MCP 連接的視訊通話

會議是MCP價值最快體現的領域之一，因為 有許多重複性的手工工作：做筆記、提取操作、分享摘要、更新客戶關係管理系統 (CRM)等等。整合 Zoom 等平台， 谷歌見面 o 微軟團隊 透過 MCP，幾乎可以實現整個流程的自動化。

基於 MCP 的會議代理人可以：

• 自動轉錄對話 en tiempo真實。
• 確定關鍵決策、行動事項、協議和未決問題。
• 將摘要傳送到 Slack、電子郵件、Notion 或公司的任務管理工具。
• 更新客戶關係管理系統中的客戶記錄並產生後續郵件。

其邏輯與我們之前看到的類似：有一個 MCP 伺服器與視訊會議平台的 API 通訊（以獲取錄製內容、文字記錄或其他元資料），還有一個伺服器整合了 Drive、Slack、CRM 等工具。主持人（例如，「會議助理」應用程式）協調所有這些通話。

實際上，對於大多數最終用戶而言，所有這些都隱藏在第三方創建的友善用戶介面背後。有一些工具可以 他們為你開車走MCP高速公路您只需連接您的帳戶（日曆、Zoom、CRM）並選擇四個選項，同時後台會向不同的伺服器發出多個 MCP 呼叫。

在最終形成的生態系統中，人工智慧不再局限於生成文本，而是 直接掌控你的數位環境：安排行程、記錄資訊、整理資料、牢記記憶、協調協調MCP 層使得所有這些整合能夠保持一定的秩序，而不是變成難以維護的複雜整合。

Azure 和 Foundry 中的遠端 MCP 伺服器：整合內部系統

在企業環境中，問題往往不在於連接到Google或Zoom，而是連接到… 預設不公開 MCP 的內部系統：私有 API、舊版服務、業務微服務對於這些情況，常見的策略是在雲端基礎架構上設定遠端 MCP 伺服器。

一個非常有趣的模式涉及使用 用於託管 MCP 伺服器的 Azure FunctionsAzure Functions 提供無伺服器模型，支援零規模、隨選擴展，並可輕鬆與託管身分和專用網路整合。其理念為：

1. 從 MCP 伺服器範本初始化專案（例如，使用 Azure 開發人員 CLI 或類似工具） azd init –template remote-mcp-functions-python).
2. 在函數程式碼中定義公開內部 API 的不同 MCP 工具：例如，「檢查待處理訂單」、「建立事件」、「啟動計費流程」。
3. 配置適當的身份驗證方式：角色金鑰、OAuth、託管身分等。
4. 使用以下方式部署 MCP 伺服器 azd up 並記下 MCP 端點和必要的金鑰。

您也可以選擇將該 MCP 伺服器註冊到以下位置： 使用 Azure API 中心建立私有工具目錄 在組織層面，這使得在團隊之間共用、新增管理機制（誰可以使用什麼）、附加文件以及配置集中式身分驗證策略變得更加容易。

註冊後，即可使用諸如以下服務： Microsoft Foundry 代理服務 他們可以從目錄中發現 MCP 伺服器，也可以透過手動設定（自訂 MCP 工具）發現。之後，Foundry 代理可以呼叫公開的工具。 透過標準化的MCP介面與內部業務系統進行交互.

如果連線出現問題（驗證錯誤、終端點不正確、找不到工具），診斷通常包括查看 Azure Functions 日誌、驗證金鑰，並確認 MCP 伺服器是否正確公開代理程式所需的架構和工具。

建立您自己的 MCP 伺服器：語言、SDK 和要求

如果經過這一切之後，你仍然渴望搭建一個自訂的 MCP 伺服器，那麼好消息是： 官方和社群 SDK 已經適用於多種語言其中最突出的有：

• TypeScript / JavaScript
• 蟒蛇
• Java的
• 科特林
• C#
• 以及其他一些 Go 語言的社群項目

無論你選擇哪種語言，你需要的基本要素都是：

• 一些 知識 程序設計 和 API 清楚地展示工具和資源。
• 訪問 您希望公開的 API 或資料來源 （Web API、資料庫、內部系統、文件…）
• 一種機制 身份驗證和授權 強大的功能（OAuth、令牌、內部密鑰…）可適應您的環境。
• 一個環境 穩定執行 （它可以是像 Azure Functions 那樣的無伺服器版本，也可以是 Kubernetes 中的容器、虛擬機器等等。）

工作流程通常是：定義要解決的問題（例如，集中存取客戶資料），設計代表關鍵操作的 MCP 工具，編寫伺服器程式碼，使用範例 MCP 用戶端在本地進行測試，最後將其公開，以便真實主機（例如桌面助理、企業代理或 IDE）可以連接。

同 El Temppo我們很可能會看到 MCP 上更多低程式碼/無程式碼工具 它允許技術水平較低的用戶透過拖放模組來建立簡單的伺服器：連接 API、定義工具、添加提示，就完成了。但就目前而言，幾乎總是需要編寫一些程式碼。

MCP的優勢、限制和未來

在仔細審查了這麼多細節之後，有必要總結一下MCP提供的服務及其收費標準。其中最明顯的優點包括：

• 一 將人工智慧模型與工具和數據連接起來的連貫且標準化的方法這樣可以減少臨時整合帶來的技術債。
• 市長 模塊化您可以變更工具的後端（例如，從一個 CRM 切換到另一個 CRM），而無需主機或模型變更其邏輯。
• 這使得人工智慧代理更容易真正成為 自僱人士及多工具根據其推理調用不同的工具，而不是僵化的、手工編程的流程。
• 它與現代建築風格非常契合， 法學碩士成為行動的組織者 關於業務系統。

在限制和挑戰方面，必須考慮以下幾點：

• La MCP伺服器和主機的初始配置 在現有系統上實現該協定可能非常繁瑣。許多架構需要重新設計才能充分利用該協定。
• 引入協議層涉及一些 開銷和延遲尤其是當 MCP 伺服器分佈在多個網路或雲端時。
• 有一個 學習曲線 這適用於後端團隊和代理設計人員：了解工具的建模方式、資源的管理方式以及工作流程的編排方式至關重要。

儘管如此，一切跡像都指向MCP 它將成為我們設計和部署人工智慧助理的關鍵組成部分。像 Anthropic、OpenAI 和 Google DeepMind 這樣的大型實驗室正在調整其產品以支援該協議，而像微軟這樣的供應商已經將其整合到其企業平台中。

隨著 MCP 伺服器生態系統（包括官方和社群驅動的）日趨成熟，我們將看到一個不斷增長的插件庫，這些插件能夠將代理與幾乎任何事物連接起來：從麻省理工學院的深度學習庫等教育資源庫，到銷售、醫療保健、零售或公共管理系統。而且，人工智慧也將逐漸超越抽象的回應，真正與使用者互動。 在充分了解每個使用者和每個組織的真實情況後，採取知情行動。.