嗨，我係 Lena——只係一個花咗好多時間坐喺 AI 系統隔籬，睇住佢哋點樣運作嘅人。
讀我文章嘅人，多數都唔係嚟搵一個現成答案。佢哋喺度砌 agent、debug 成日喺同一個位斷嘅 workflow，想令系統穩陣啲，又唔想成日守喺隔籬。佢哋其實夠聰明，只係想有人陪住，一齊慢慢諗清楚。
呢篇文章想講一個詞：MCP。
最近佢幾乎周圍都見到。開發者論壇、工具文件，凡係講 AI agent 點樣連去外部世界嘅地方，幾乎都會提到 MCP。但我一路留意到一件事：好多人都識用呢個詞，卻好少人真係坐低，講清楚佢實際上喺做乜。
咁。MCP 到底係咩？佢解決咗咩問題？佢嘅邊界又喺邊？
我由佢啱啱推出開始就一路留意呢個協議。有啲位，而家我覺得已經清楚咗。亦有啲位，我仲喺度繼續諗。但有樣嘢我幾肯定：如果你做緊任何同 AI agent 有關嘅嘢，MCP 都唔係可以直接跳過去嘅一樣嘢。
由頭講起。
呢篇文會講呢幾樣：MCP 係咩、佢點樣運作、邊啲人已經支援、而家個生態有咩，同埋佢真正嘅限制喺邊。唔預設你有技術背景，但亦唔會刻意講到太淺。
MCP 係咩？
MCP — Model Context Protocol 由 Anthropic 提出，目標係標準化 AI 系統同外部工具點樣互動。落到實際開發，開發者會用 MCP server 將檔案存取、API 呢類能力 expose 畀 Claude 呢類 agent。呢個係技術答案。真係講返佢喺現實入面代表咩，大概係咁：
喺 MCP 出現之前，每次你想個 AI 助手去掂某樣嘢——資料庫、日曆、GitHub repo、網頁搜尋——你都要自己寫一套 connector。由零開始。每個工具一套，每個平台又一套。如果你一邊喺 Claude 上面整，一邊又用 GPT-4，基本上等於所有嘢都要寫兩次。
MCP 當初想解決咩問題
你可以將呢件事諗成 USB-C 出現之前嘅充電線。每部裝置都有自己嘅專有插頭。你有三部機，就要三條唔同嘅線。單睇每條線都用得，但成個系統其實亂晒。
喺 MCP 出現之前，開發者成日都要為每個 data source 或工具各自砌一套 connector，最後就變成 Anthropic 所講嘅 “N×M” 數據整合問題——如果你有 N 個 AI 系統同 M 個工具，理論上就要做 N 乘 M 種唔同整合。重複勞動非常多。
MCP 喺 2024 年 11 月由 Anthropic 公布，定位係將 AI 助手連接去數據系統嘅開放標準，涵蓋內容倉庫、業務管理工具同開發環境等場景。佢由第一日開始就係 open source，而呢一點後來證明咗好重要——亦都因為咁，佢先會擴散得咁快。
MCP 點樣運作：基本架構
講到底，MCP 建立嘅係一種共同語言。佢畀應用一套標準方式去讀檔、執行 function，同埋處理帶 context 嘅 prompts。
呢個協議建基於 JSON-RPC 2.0——一個好成熟、好輕量嘅 remote procedure call 標準。佢仲借咗 Language Server Protocol（LSP）嘅訊息流思路，亦即係令 VS Code、Vim 呢啲編輯器入面嘅 code intelligence 可以喺唔同工具之間保持一致嗰套協議。如果你覺得呢個架構有啲似曾相識，係因為佢真係證明過 work：一套標準，多種實作。
最重要嘅 mental model 係：MCP 唔會改變 AI model 能夠 諗 到乜——佢改變嘅係佢哋能夠 掂 到乜。
altexsoft 繪製嘅 MCP 架構圖
MCP Servers 同 MCP Clients
一旦你搞清楚 MCP 兩邊分別做咩，後面好多嘢就會自然對得上。
MCP server 做咩
一個 MCP server 係一段用標準方式 expose 能力——tools、data 同 resources——嘅軟件。邊個擁有嗰項能力，就由邊個去整個 server。GitHub 為 GitHub 整咗 MCP server。Stripe 整支付相關嘅。Figma 整設計檔相關嘅。
**server 會決定 expose 啲咩。**佢會定義 AI 可以 call 邊啲 tools、讀到咩 data、畀唔畀做某啲動作。access control 就喺呢一層。
MCP client 做咩
一個 MCP client 就係你實際同佢對話嗰個 AI 應用。Claude.ai 係 MCP client。ChatGPT desktop app 係 MCP client。Cursor（嗰個 AI code editor）都係 MCP client。當你叫佢去「睇下我嘅 GitHub issues」或者「check 下我個 database 有啲咩」，真正發起呼叫嘅就係 client 呢一層，佢會去搵對應嘅 server。
呢個分層最重要嘅地方係夠乾淨：client 唔使知 GitHub 個 API 內部究竟點樣運作。佢只要識講 MCP；真正將請求翻譯成 GitHub 系統語言嘅，係 server。
發現同連線係點樣發生
呢一塊仲喺度繼續成熟。如果你而家想知一個 MCP server 做得到啲乜，多數都要先連上去。咁一嚟，client 就好難瀏覽有咩 server 可用，而 registry 呢啲系統都好難自動幫能力做目錄。
MCP 團隊而家正喺度推進呢件事。佢哋嘅 roadmap 包括俾 server 透過 .well-known URL 主動做自我介紹——某程度上，就好似每個 server 會有張對外嘅「名片」，等 client 唔使真係連上去，都可以先讀到基本資料。就好似網站會公開 metadata，俾搜尋引擎唔使完整載入頁面都先理解到一部分內容。
而家嘅 discovery 過程大多數都仲係手動：你先喺 MCP client 入面配置 server URL，做完認證，然後 client 會喺連線建立嗰一刻學到邊啲 tools 可用。MCP 用 OAuth 2.1 做認證，即係你會明確授權 AI 可以做乜、唔可以做乜。冇你許可，佢唔會直接喺你個帳戶上面幫你郁手。
邊個支援 MCP，生態入面又有咩
模型供應商（已確認）
呢度嘅採用速度，不論用邊個標準去睇都算快。MCP 公布之後，OpenAI 同 Google DeepMind 呢啲主要 AI 供應商都陸續採用咗呢個協議。
Anthropic 喺 2024 年 11 月推出 MCP，而且同一日就 open source。到 2025 年 1 月，Cursor、Windsurf 呢類 AI 開發工具已經加咗支援。2025 年 3 月，OpenAI 正式採用；Google DeepMind 隨後跟上。Microsoft 亦都宣布咗 Windows 層面嘅 MCP 支援，仲將佢整合入 Azure 同 Semantic Kernel。
去到 2025 年 12 月，治理層面又有咗一個幾大嘅變化。Anthropic 將 MCP 捐咗畀 Agentic AI Foundation——呢個係 Linux Foundation 下面嘅定向基金，由 Anthropic、Block 同 OpenAI 共同發起。呢個動作好重要：佢令 MCP 由 “Anthropic 嘅協議” 變成 “成個 AI 行業嘅協議”。
到 2026 年初，2025 年 11 月發布嘅現行規格，已經成為各大供應商共同對齊嘅穩定基線。SDK 亦都已經覆蓋 Python、TypeScript、C# 同 Java。
社群 MCP server 生態
呢部分好快就開始變得有意思。到 2026 年 3 月，MCP 嘅 SDK 月下載量已經去到 9,700 萬，社群構建嘅 server 超過 5,800 個。
你去睇一眼 官方 MCP server registry，就會好直觀咁感受到佢有幾闊：GitHub（repo 管理、issues、PRs）、Stripe（支付同客戶）、Figma（設計 context）、PostgreSQL（資料庫查詢）、Slack（團隊溝通）、AWS 服務、Kubernetes 管理、Elasticsearch，仲有更多更多。
MCP steering group 維護嘅 reference server repo，目標只係放少量參考實作，用嚟展示 MCP 特性同 SDK 嘅用法——佢更加似係畀開發者參考嘅教學樣例，而唔係可以直接拎去 production 嘅方案。真正熱鬧嘅地方，仲係社群 server，同埋各大平台自己嘅官方整合。
一個幾現實嘅安全提醒：MCP spec 要求 tools 真正執行之前要經過用戶批准，但早期並唔係每個 host 都將呢一步做啱。由惡意 server 回應引發嘅 prompt injection 係真風險——如果某個 MCP server 被入侵，佢完全可能透過輸出內容去操控 AI 嘅行為。所以，連任何新嘅 MCP server 之前，尤其係社群項目，一定要先睇清楚你到底授權咗啲咩。
MCP 解決到乜，又解決唔到乜
呢一段成日都被人輕輕帶過，但老實講，最有意思嘅問題反而都喺呢度。
連上去，唔等於能力會留低
MCP 解決嘅係 連線。而且佢解決得幾優雅，可擴展，又得到咗幾廣泛嘅行業認同。呢一點的確重要。
但 MCP 解決唔到嘅，係一次成功連線之後會發生咩事。你諗下典型嘅 agent workflow：AI 連去某個工具，發起呼叫，拎到結果，再用個結果生成輸出。然後對話完——又或者 context window 滿咗——session 就結束。
tool call 確實發生過，結果亦都確實用過。但嗰次互動究竟係點樣走通，並唔會用一種可持久、可重用嘅形式留低。
到你下次再開一個新 session，同一個 agent 對上次邊樣有效、邊樣失敗、邊一串 tool calls 得到最好結果，統統都冇記憶。佢會由頭開始。可能又再犯同一個錯，亦都可能重行一次差唔多嘅搜尋路徑。呢個唔係 MCP 本身嘅缺陷——只係唔喺佢嘅職責範圍入面。
點解一次成功嘅 tool call 變唔成可重用知識
講個更具體嘅例子。假設你叫一個 AI agent 去 debug 代碼庫入面反覆出現嘅問題。佢連到 GitHub MCP server，讀咗幾份檔，跑咗幾次搜尋，來回試咗幾輪，最後搵到 root cause，仲提出一個修復方案。呢次佢成功咗。
兩個禮拜之後，同一類問題又出現，只係版本有少少唔同。agent 再次透過 MCP 連到 GitHub——協議冇變，標準冇變，連線依然可靠。但佢對上次點樣諗出答案，係完全冇記憶。嗰條成功排障嘅路徑，冇被結構化咁存低。另一個 agent 都冇辦法直接繼承佢。呢個解法最後只係困喺一段已經關閉咗嘅對話入面。
呢個唔係喺度否定 MCP。佢確實完成咗自己要做嘅事：為 AI 系統同外部工具之間提供一個標準化、可靠嘅介面。MCP 早就唔只係本地工具接線嗰套嘢——而家佢已經喺大大小小嘅公司入面跑喺 production 環境，亦都真係支撐緊 agent workflow。呢個係實打實嘅進步。
但「連接基建」同「能力持久化」本身就係兩個唔同問題。MCP 解決嘅係前者。後者，先至係下一代 agent 基礎設施真正聚焦嘅地方。
局限同取捨
一路睇住呢個協議成熟，我有幾點幾坦白嘅觀察。
有狀態嘅 server 要 scale，仲係麻煩。 而家好多實作都要喺 request 之間記住一啲嘢，咁就令你好難將佢哋橫向擴到多個 server instance。雖然 Streamable HTTP transport 已經提供咗一部分無狀態支援，但 server 啟動同 session 處理呢兩塊，痛點仲喺度。2026 年 roadmap 已經正面處理緊呢個問題，如果你打算做大規模 production 部署，呢點值得早啲知道。
企業級認證仲喺度補課。 規格已經支援基於 OAuth 嘅授權，OAuth 2.1 嘅企業整合亦都喺 2026 年 roadmap 入面。但對嗰啲身份提供方要求好嚴、合規邊界好重嘅行業嚟講，空白位仍然有一啲。企業已經開始大規模部署 MCP，而佢哋亦都真係喺撞緊同一批問題：審計鏈路、SSO 整合認證、gateway 行為，同埋設定可攜性。
安全責任更多落喺 implementer 身上。 MCP 自身冇辦法喺協議層面強制執行安全原則——implementer 必須自己將 consent 同 authorization flow 做紮實，講清楚安全影響，再加上合適嘅 access control。呢個設計選擇本身唔算離譜——協議因此可以保持輕量——但代價就係，生態入面唔同實作之間嘅安全質素差距可以非常大。
Discovery 而家仍然主要靠手動。
正如前面講過，你通常都要先知道自己想連邊啲 server，先至去連佢哋。registry 預覽同 .well-known URL 會幫到手，但就眼下嚟講，呢樣依然係新用戶探索個生態時最明顯嘅摩擦位之一。
社群 server 嘅質素差距非常大。 5,800+ 個 server，跨度當然非常大。有啲係公司自己維護——例如 GitHub 嘅 server、Stripe 嘅 server——安全同維護都有人睇住。亦都有一啲只係社群實驗項目。對待陌生 server，最好同對待任何第三方代碼一樣：先睇清楚你到底準備交畀佢咩權限。
FAQ
MCP 係咪淨係畀開發者用？
又唔完全係，但你今日大多數都仲係會喺開發者工具入面遇到佢——例如 Cursor、Windsurf 呢類 code editor、AI IDE，又或者 agent framework。隨住愈來愈多應用將 MCP support 內嵌入去，一般用戶之後好可能喺完全冇意識到嘅情況下，其實已經用緊佢。
用咗 MCP，係咪就代表 AI 可以喺我部電腦或者帳戶入面乜都做？
唔係。每個 MCP server 只會 expose 佢個開發者揀咗 expose 嘅嗰部分能力，而你會明確授權存取。連線建立之後拎到嘅唔係無限權限，而係嗰個 server 定義好嘅具體能力。話雖如此，連任何新 server 之前，先檢查你準備授權乜，始終都係一個好習慣。
MCP 同普通 API call 有咩分別？
普通 API call 嘅前提，係 AI 系統必須被專門寫到識得呼叫嗰個 API——自訂代碼、寫死嘅 endpoint、獨立處理認證。MCP 將呢啲都標準化咗，所以任何兼容嘅 AI client 都可以同任何兼容嘅 server 對話，雙方都唔使再為彼此寫一次性代碼。你可以將佢諗成：唔使為每個 USB 裝置都重新寫一次 driver，而係大家共享同一套 USB 協議。
MCP 可唔可以跨唔同 AI 模型運作？
可以。呢個正正就係佢最重要嘅屬性之一。MCP 提供嘅係一層通用介面——企業將一個 MCP server 搭好之後，只要某個 AI assistant 識講 MCP，無論係 Claude、ChatGPT 定係其他模型，都可以連上去。
MCP 同 function calling 有咩唔同？
Function calling（有時亦都叫 tool use）係某個特定 model 調用工具嘅機制。MCP 就係再上面嗰層標準協議——佢定義嘅係 tools 點樣被發現、點樣被描述，以及點樣喺唔同 system 之間通信。你可以將 function calling 理解成某一個 AI 內部嘅調用機制，而 MCP 係成個生態共享嘅嗰套語言。
MCP 而家算唔算正式穩定？
MCP 當前呢版規格發布於 2025 年 11 月。官方規格 已經被視為可以穩定構建嘅版本。2026 年嘅 roadmap 更加關注企業可用性、擴展能力同 discovery 機制，而唔係去改協議嘅根。對大多數 use case 嚟講，而家呢版已經可以上 production。
喺邊度可以搵到可用嘅 MCP server？
MCP Registry 係官方目錄。社群維護嘅 awesome-mcp-servers 都收錄得幾全。如果你想睇參考實作，Anthropic 喺 GitHub 上面維護咗 modelcontextprotocol/servers 呢個 repo。
我仲會繼續睇佢點樣演化。連接問題大概已經解決咗——真正有意思嘅，係能力呢一層之後會發生咩事。
