重點摘要：
AI 中的 MCP 代表 模型上下文協定。這是一項開放標準，協助 AI 應用程式透過通用介面連接外部工具、資料來源與工作流程。MCP 不會取代 API、函式呼叫或 RAG，而是為 AI 應用程式提供更一致的方式來探索及使用這些能力。
Michael Johnson2026-07-21
AI 中的 MCP 代表什麼？模型上下文協定解析
AI 中的 MCP 代表模型上下文協定。了解主機、用戶端與伺服器如何將 AI 連接至工具和資料，以及 MCP 與 API 的比較和主要安全風險。
目錄
AI 中的 MCP 代表什麼？
MCP 代表 模型上下文協定。
這是一項開放原始碼標準，用於將 AI 應用程式連接至檔案、資料庫、搜尋工具、行事曆、程式碼儲存庫及商業軟體等外部系統。官方 MCP 文件將其比喻為 USB-C 連接埠：不同裝置可以使用同一種連線標準，而不必為每種組合準備新的線材。
這個比喻很有用，但也可能讓 MCP 聽起來比實際情況更簡單。
MCP 不是 AI 模型、應用程式，也不是 API 的替代品。它是由相容的 AI 應用程式與伺服器使用的通訊標準。應用程式仍需要語言模型來理解使用者的請求，而連線的服務通常仍會在底層依賴既有的 API。
更精確的定義是：
MCP 將 AI 應用程式探索、連線及與外部工具和資料來源交換資訊的方式標準化。
「上下文」一詞很重要。語言模型只知道訓練資料中包含的內容，或目前互動期間提供給它的資訊。當需要額外資訊時，MCP 可以讓 AI 應用程式存取額外的上下文—例如最新的資料庫記錄、本機檔案，或即時 API 請求的結果—。
為什麼會建立模型上下文協定？
在 MCP 出現之前，開發人員通常必須針對 AI 應用程式與外部服務的每種組合，分別建立整合。
假設有一個 AI 助理需要與 Google Calendar、GitHub、客戶資料庫及內部計費系統協作。每個整合可能都有自己的 API 格式、驗證流程、函式定義與錯誤處理規則。
現在再想像一次：要為另一個 AI 助理重新建立相同的連線。
MCP 嘗試減少這些重複的整合工作。服務可以透過 MCP 伺服器公開其能力，而相容的 AI 應用程式則可透過共用協定進行連線。
這並不表示開發人員可以停止建立整合。仍然需要有人實作 MCP 伺服器、將其連接至底層服務、管理憑證、驗證請求並維護系統。其好處在於重複使用：一項能力遵循該協定後，可能更容易連接至多個相容的 AI 主機。
當工具、資料來源及 AI 用戶端的數量開始增加時，MCP 最有價值。若只有一個應用程式連接至一項穩定服務，直接整合 API 可能仍是更簡單的選擇。
MCP 的運作方式：主機、用戶端與伺服器
MCP 採用用戶端—伺服器架構，但由於涉及三個部分，相關術語可能令人困惑。
MCP 主機
主機是使用者互動的 AI 應用程式。它可以是聊天助理、程式設計環境、桌面應用程式或自訂 AI 代理。
主機負責協調對話、與語言模型通訊、管理權限，並決定哪些 MCP 連線可用。
MCP 用戶端
MCP 用戶端是主機內部的元件，負責維持與 MCP 伺服器的連線。
根據官方 MCP 架構，主機通常會為每部伺服器建立獨立的用戶端連線。如果應用程式連接檔案系統伺服器與行事曆伺服器，就會管理兩個 MCP 用戶端。
MCP 伺服器
MCP 伺服器是一個向 MCP 用戶端提供特定能力的程式。它可以在使用者的裝置本機執行，也可以在另一部伺服器上遠端執行。
MCP 伺服器可以公開三種核心能力：
- 工具：可執行的函式，例如查詢資料庫、建立行事曆活動或傳送訊息。
- 資源：應用程式可以讀取的資訊，例如檔案、資料庫記錄或 API 回應。
- 提示：協助建立模型互動結構的可重複使用範本。
主機與伺服器首先會協商雙方都支援的協定功能。接著，用戶端可以請求可用能力的清單。當模型判斷某項工具相關時，主機會透過 MCP 用戶端，將結構化請求路由至正確的伺服器。
結果會回傳至 AI 應用程式，成為模型產生下一個回應時的額外上下文。
一個真實的 MCP 範例：從請求到工具結果
假設開發人員向內部 AI 助理提出要求：
“檢查我們本月的 API 支出。如果超出預算 20% 以上，請為工程團隊建立警示。”
簡化後的 MCP 工作流程可能如下：
- AI 應用程式收到請求，並將其傳送至語言模型。
- 其 MCP 用戶端發現，連線的財務伺服器提供
get_api_usage與get_budget_limit。 - 模型選取這些工具，並提供所需的日期範圍。
- MCP 伺服器呼叫公司的計費 API，並回傳目前支出與預算。
- 模型計算支出是否超出上限 20% 以上。
- 如果需要發出警示，應用程式會找出已連線的訊息工具，例如
create_alert。 - 由於此動作會變更外部系統，應用程式可以要求使用者確認。
- 獲得核准後，訊息伺服器會呼叫底層的訊息 API。
- 模型會告知使用者查到的結果及採取的動作。
MCP 將此流程的中間部分標準化：探索工具、描述其輸入需求、呼叫工具，以及回傳結構化結果。
它本身不會執行計算、不會提供語言模型，也不會取代計費與訊息 API。
MCP vs API vs 函式呼叫 vs RAG
這些術語經常被描述為彼此競爭的技術。實際上，它們運作於不同層級，且經常會出現在同一個應用程式中。
| 概念 | 解決的問題 | 與 MCP 的關係 |
|---|---|---|
| API | 讓一個軟體系統向另一個系統請求資料或執行動作 | MCP 伺服器通常會在底層呼叫既有的 API |
| 函式呼叫 | 讓模型為預先定義的工具產生結構化請求 | 主機可以將 MCP 工具定義轉換成模型可選取的函式 |
| RAG | 在模型回答前，擷取相關的外部資訊 | MCP 伺服器可以公開擷取工具或資源，但 MCP 本身不是 RAG |
| MCP | 將相容 AI 應用程式連接及互動工具與資料的方式標準化 | 作為連線與互通性層 |
MCP 會取代 API 嗎？
不會。MCP 與 API 解決的是相關但不同的問題。
API 定義特定服務的呼叫方式。例如，計費 API 可能會定義一個回傳帳戶使用量的端點。
MCP 定義 AI 應用程式如何探索及使用相容伺服器公開的能力。該伺服器可能會呼叫計費 API 來取得實際資料。
換句話說：
API 將軟體連接至服務；MCP 則協助 AI 應用程式透過通用協定與多項服務協作。
當應用程式只需要一項固定功能時，直接整合 API 仍可能更快、更簡單。當開發人員希望在多個 AI 用戶端間重複使用工具，或允許可用能力動態變更時，MCP 會更具吸引力。
MCP 與函式呼叫相同嗎？
不相同。函式呼叫通常是模型的一項能力。開發人員描述一個或多個函式，而模型在判斷應使用某個函式時，會產生結構化參數。
MCP 作用於這個流程周圍。它可以協助應用程式從已連線的伺服器探索工具定義，而不必將每項工具硬式編碼至應用程式中。
模型仍可能依賴函式或工具呼叫來選取 MCP 提供的工具。
MCP 是 RAG 的一種嗎？
不是。檢索增強生成（RAG）是一種在模型回答前擷取相關資訊，並將其加入模型上下文的方法。
MCP 伺服器可以公開文件搜尋工具，作為 RAG 系統的一部分。然而，MCP 不會決定文件如何建立索引、結果如何排序，或擷取的文字如何加入提示。
MCP 可以傳遞請求與結果，搜尋工作則由檢索系統執行。
MCP 能做什麼、不能做什麼
MCP 可以讓工具在相容應用程式之間更容易重複使用，也能讓應用程式探索可用工具及其必要輸入，而不必完全依賴硬式編碼的連線。
但有些常見說法太過誇張。
MCP 不會：
- 在應用程式沒有 MCP 用戶端支援時，讓其自動相容。
- 消除底層 API 或商業邏輯的需求。
- 自動處理所有驗證與權限要求。
- 保證模型會選取正確的工具。
- 保證工具會回傳準確資料。
- 讓第三方伺服器預設安全。
- 消除監控、更新及維護整合的需求。
- 自動在連線系統之間分享所有資料。
它也不會讓模型不受限制地存取每個已連線的服務。主機控制連線的伺服器，而伺服器能力與使用者權限則決定可讀取或變更的內容。
開發人員何時應使用 MCP？
當應用程式必須連接多個工具或資料來源，尤其是這些能力可能在不同 AI 主機之間重複使用時，MCP 值得考慮。
常見情境包括：
- 搜尋文件、資料庫及支援工單的內部助理。
- 與程式碼儲存庫、問題追蹤工具及監控系統協作的程式設計代理。
- 查詢多個即時資料來源的研究應用程式。
- 讀取記錄並在其他軟體中執行核准動作的商業代理。
- 希望服務能與多個 MCP 相容用戶端協作的工具供應商。
當應用程式只有一個狹窄的工作流程、只使用一項服務，或需要精確控制每個請求的底層細節時，直接整合 API 可能是更好的選項。加入 MCP 伺服器會引入另一個需要部署、保護、測試及觀測的元件。
MCP 可以減少部分重複的整合工作，但不會消除架構上的取捨。
MCP 安全嗎？
MCP 並非自動安全或不安全。安全性取決於主機、伺服器、底層服務、驗證流程，以及授予各項動作的權限。
已連線的伺服器可能會從 AI 應用程式接收敏感資訊。具有寫入權限的工具也可能變更檔案、傳送訊息、建立記錄或觸發其他外部動作。
官方 MCP 安全性指南涵蓋的風險包括權杖傳遞、伺服器端請求偽造、工作階段劫持、遭入侵的本機伺服器，以及混淆代理人攻擊。這些是實作風險，不會因系統採用標準協定就消失，也不是使用標準協定所能自動帶來的理論優勢。
開發人員應採取幾項基本控制措施：
- 只連接信任且能夠驗證的伺服器。
- 為每部伺服器提供其所需的最低權限。
- 將唯讀工具與會變更資料的工具分開。
- 對敏感或破壞性動作要求確認。
- 驗證工具的輸入與輸出。
- 不要將憑證放入提示或工具描述中。
- 記錄工具呼叫，以便調查與稽核。
- 檢視哪些資訊可能會傳送至遠端伺服器。
OpenAI 同樣警告，自訂 MCP 伺服器可能會接收資料並執行外部動作，並建議只連接信任的伺服器。目前的實作要求 ChatGPT 對話中的寫入動作先取得確認，但開發人員不應假設每個 MCP 用戶端都採用相同政策。OpenAI 的 MCP 文件
2026 年 MCP 有哪些變化？
截至 2026 年 7 月，最新的穩定 MCP 規範仍是 2025 年 11 月 25 日發布的版本。官方專案表示，自此之後尚未發布其他規範版本。2026 MCP 路線圖描述的是計畫中的工作，而不是穩定協定中已獲保證的功能。
目前規範定義了兩種標準傳輸方式：
stdio，用於與本機程序通訊。- Streamable HTTP，用於遠端 MCP 伺服器。
Streamable HTTP 已取代較舊的 HTTP+SSE 傳輸方式，但用戶端與伺服器仍可保留向後相容性。目前的傳輸規範也包含涵蓋驗證、來源驗證、本機網路繫結及工作階段處理的要求與建議。
MCP 的治理也有所變化。2025 年 12 月，該協定成為 Linux Foundation Agentic AI Foundation 的創始專案。該基金會表示，目前已發布超過 10,000 部 MCP 伺服器，並已在 ChatGPT、Claude、Gemini、Microsoft Copilot、Cursor 及 Visual Studio Code 等產品中獲得採用。Linux Foundation 公告
2026 年路線圖聚焦於四個領域：傳輸擴充性、代理通訊、治理及企業就緒度。稽核軌跡、整合 SSO 的驗證、設定可攜性及閘道行為，都是仍在解決的企業問題。
最後一點很重要。MCP 已不再只是本機開發人員工具的實驗，但其企業安全性與營運模型的部分內容仍在成熟中。
GPT Proto 在 MCP 應用程式中的定位
GPT Proto 與 MCP 屬於 AI 應用程式的不同層級。
MCP 將應用程式連接至外部工具與上下文。應用程式仍需要模型來理解請求、選擇動作並產生最終回應。
該模型可以透過模型 API 供應商存取。使用 GPT Proto 模型目錄的開發人員，可以為推理層選擇文字與推理模型，而 MCP 伺服器則負責處理與外部系統的連線。
簡化的設定可能包含：
- 作為 MCP 主機的 AI 應用程式。
- 透過 GPT Proto 存取、用於推理與生成的語言模型。
- 由主機管理的一個或多個 MCP 用戶端。
- 公開外部工具與資料的 MCP 伺服器。
- 這些伺服器在底層使用的既有 API。
這兩個層級相輔相成。共用的模型 API 可以讓應用程式更容易測試或替換其背後的模型；MCP 則能在將應用程式連接至多個工具時，減少重複工作。
常見問題
AI 中的 MCP 代表什麼？
MCP 代表模型上下文協定。這是一項開放標準，用於將相容的 AI 應用程式連接至外部工具、資料及工作流程。
什麼是 MCP 伺服器？
MCP 伺服器是一個向 MCP 相容應用程式公開工具、資源或提示範本的程式。它可以在本機執行，也可以作為遠端服務執行。
MCP 會取代 API 嗎？
不會。MCP 伺服器經常使用既有 API 來執行工作。MCP 將 AI 應用程式探索及互動這些伺服器所公開能力的方式標準化。
MCP 是否代表開發人員不再需要撰寫整合？
不會。開發人員仍需要連接服務、實作商業邏輯、設定驗證、驗證資料並運作伺服器。MCP 可以讓最終形成的能力更容易重複使用。
MCP 只適用於 Claude 嗎？
不會。MCP 起源於 Anthropic，但現在已成為 Agentic AI Foundation 旗下的開放專案，並獲得多個 AI 應用程式與開發人員工具支援。例如，OpenAI 的文件說明了如何在 ChatGPT Apps 與 API 整合中使用遠端 MCP 伺服器。
每個 AI 模型都支援 MCP 嗎？
嚴格來說，MCP 支援通常屬於 AI 應用程式或主機，而不只是語言模型本身。主機會連接 MCP 伺服器，並向模型提供合適的工具或上下文。
使用 MCP 安全嗎？
在適當控制措施下可以安全使用，但該協定不會讓每部伺服器都值得信任。開發人員應驗證伺服器、限制權限、保護憑證、驗證請求，並要求對敏感動作進行核准。
相關文章
更多部落格
2026 年開發者最佳 AI API：10 個平台比較
TL;DR Best direct APIs: OpenAI is the safest general-purpose default; Anthropic Claude is strongest for coding and long-running agents; Gemini suits low-cost multimodal prototyping; and DeepSeek leads on text-token price. Best multi-model options: OpenRouter is the clearest choice for testing many LLMs. GPTProto is the stronger fit when one product needs text, image, and video models under one API key and shared balance. Best infrastructure choices: Amazon Bedrock fits AWS-governed enterprise deployments, while Replicate, fal.ai, and Together AI are better suited to open-model or generative-media inference. There is no universal winner. Compare workload fit, model coverage, real billing units, production controls, and switching cost. Prices and availability were checked on July 14, 2026; verify live provider pages before deployment.
Tiffany Layne | 2026-07-15
GLM-5.2 與 Kimi K3 程式設計比較：2026 年哪個更適合開發者？
TL;DR： 當任務困難、執行時間長或涉及視覺內容時，Kimi K3 是更強的程式設計模型。在 Moonshot 公開的程式設計比較中，它全面領先 GLM-5.2，並可透過其託管服務接受圖片與影片。對於日常的儲存庫工作，GLM-5.2 仍是更好的預設選擇：成本低得多、運行規模較小，且採用寬鬆的 MIT 授權。Kimi K3 現在也已釋出權重，但其 1.56 TB 儲存庫、建議使用 64 個以上加速器的部署要求，以及自訂授權，意味著自行託管需要投入更多資源。當能力是瓶頸時選擇 Kimi；當成本與日常運營簡易性更重要時選擇 GLM。 GLM-5.2 與 Kimi K3 程式碼比較中有趣的地方，不在於兩個模型都能撰寫 React 元件或解決簡短演算法。這個層級的模型早已具備這些能力。真正有用的問題是，當任務變得複雜時會發生什麼：儲存庫稽核、多檔案遷移、只會在螢幕截圖中出現的錯誤，或必須讓多個系統保持一致的可遊玩 Three.js 原型。 這也是價格差異開始產生影響的地方。Kimi K3 在最困難的公開測試中表現較佳，但其官方輸出價格超過 GLM-5.2 的三倍。每天執行數千次普通審查的團隊，使用 GLM 可能能以每美元完成更多工作。試圖挽救一個棘手視覺專案的開發者，則可能很樂意為 K3 買單。
Tiffany Layne | 2026-07-28
如何使用 AI 繪製兒童書籍插圖（可直接印刷且角色一致，成本約 1 美元）
我看過許多人生成一張精美的 AI 插圖，興奮不已，卻在第 4 頁左右悄悄放棄。第一張圖片從來不是問題，問題在於第 4 頁的狐狸看起來仍然像第 1 頁的同一隻狐狸，而且每一頁都必須清晰到足以實際印刷。大多數「AI 兒童書籍製作工具」網站會用一個友善的按鈕掩蓋這兩個問題，最後交給你一張 1024 像素的圖片，印刷機一接觸就變得模糊不堪。 本指南採用另一種方式：由你自行執行的小型、可重複 API 流程。它適合想要以程式控制批次生成、讓同一角色貫穿 24–32 頁，以及產出符合印刷規格檔案的人，而不是只想使用一鍵玩具工具的人。如果你只想為手機製作一張睡前圖片，無程式碼工具確實更快，你應該使用它。如果你想製作完整書籍，同時控制成本與品質，請繼續閱讀。 完成後，你將擁有一套流程，能使用一個 GPTProto API 金鑰，透過兩個模型，以約 1 美元的生成成本輸出印刷解析度（300 DPI）、角色一致的內頁與封面。
Katherine Lawrence | 2026-06-12
如何在不浪費 1M 上下文的情況下將 GLM-5.2 用於您的程式碼代理
將 GLM-5.2 連接至程式碼代理只需幾分鐘。讓它取得足夠的上下文來修復儲存庫，同時避免它漫無目的地探索，才是較困難的部分。 這項區別很重要。模型可以在聊天視窗中撰寫乾淨的函式，卻仍可能因為修改了錯誤層級、破壞 API 合約、跳過測試套件，或花費一半上下文閱讀產生檔案，而無法完成真正的工程任務。GLM-5.2 是為較長時間、以工具驅動的程式碼工作而設計，但模型周圍仍需要嚴謹的代理工作流程。 本指南涵蓋三種實用方式：使用 GLM-5.2 搭配 Claude Code、從相容 OpenAI 的代理呼叫 GPTProto 上的 GLM-5.2 API ，以及在本機執行開放權重版本。接著，我們將說明如何界定儲存庫層級的任務、管理 1M token 上下文、驗證變更，以及估算實際 token 成本。 重點摘要 如果您已經在使用該終端機代理，請搭配 Z.ai 的 Anthropic 相容端點使用 Claude Code。 對於 Cline、OpenCode、自訂代理，或已使用 OpenAI SDK 的應用程式，請使用 GPTProto 的 OpenAI 相容端點。 不要因為 GLM-5.2 接受最多 1M token，就預設傳送整個 monorepo。請先從儲存庫地圖、相關檔案、限制條件與測試指令開始。 一般調查使用 High 推理；對於計畫錯誤代價高昂的模糊、多檔案工作，使用 Max。 在代理的變更通過儲存庫的建置、lint、型別檢查與測試之前，請將其視為不受信任。 只有在隱私、控制權或持續使用足以 оправ justify 嚴格的基礎架構時，才在本機執行。「開放權重」不代表「適合筆記型電腦」。
Schuyler Stacy | 2026-07-17