有一個由五個問題組成的框架，能將值得在財務總監面前辯護的 AI 基礎建設決策，與十八個月內就會被重新替換的決策分開。這個框架圍繞著一個大多數董事會尚未聽聞的開放標準，但 Anthropic、OpenAI、Google、AWS 和 Microsoft 都已悄悄承諾支持。這項標準稱為 Model Context Protocol，簡稱 MCP。以下是每位香港 IT 總監在下一場供應商簡報前必須掌握的內容。
什麼是 MCP 模型上下文協議？
模型上下文協議是一項開放標準，讓 AI 系統能透過單一、一致的介面，連接企業內部資料、工具與應用程式。Anthropic 於 2024 年 11 月發布 MCP，用一個通用協議取代每家 AI 供應商過往各自打造的客製化連接器。你的系統只需學會說一次 MCP 語言。
可以把它想像為企業 AI 的 USB-C 介面。在 USB-C 出現以前，每款裝置都附上不同的線。在 MCP 出現以前，每家 AI 供應商要讀取你的 CRM、查詢資料倉儲、或觸發內部流程，都需要不同的整合模式。MCP 移除了這層摩擦。
此協議定義了一套標準方式，讓 AI 客戶端（例如 Claude、ChatGPT Enterprise 或內部代理）能發現 MCP 伺服器提供什麼能力、向其請求資料、並透過它執行動作。伺服器對外開放你的業務系統，客戶端負責協調 AI 行為，兩者之間的合約無論背後是哪一個 AI 模型都保持一致。
為什麼 MCP 對 2026 年的企業 AI 策略至關重要？
MCP 重要的原因是它終結了 AI 整合中單一供應商鎖定的時代。根據 Anthropic 公布的採用數據，截至 2026 年第一季，78% 的企業 AI 團隊已在生產環境部署至少一個 MCP 代理，較一年前的 31% 大幅提升。Forrester 預測 2026 年將有 30% 的企業應用供應商推出自家 MCP 伺服器。
這個策略意義相當深遠。你的團隊在 2023 年為了將 AI 工具連接 ERP、Salesforce 或文件系統而打造的每一項客製整合，都是綁定特定供應商的沉沒成本。若該供應商在採購評估中落敗，整合就必須重做。有了 MCP，整合存在於協議層，更換 AI 模型變成設定調整，而非重新建置。
對於在金融服務或醫療等受監管行業營運的香港企業而言，這一點更為重要。自金管局於 2023 年發布外判監管通函以來，供應商集中風險已是長期議題。MCP 為你提供了在架構上可以辯護的答案。
MCP 在企業環境中如何運作？
MCP 透過三個元件運作：MCP host（你的 AI 應用）、MCP client（該應用內的連接函式庫），以及 MCP server（你的業務系統對外開放的閘道）。Host 要求 client 取得上下文，client 用 MCP 與 server 通訊，server 回傳結構化資料或執行已定義的動作。
一個實際情境：觀塘一家區域物流公司希望 Claude 能回答貨件狀態查詢。沒有 MCP 時，公司需聘工程師撰寫專屬於 Claude 的整合。若日後想在 Gemini 上測試同一流程，整合必須重寫。有了 MCP，公司只需透過一個 MCP 伺服器將貨件資料庫對外開放，Claude、Gemini、OpenAI 與任何合規的內部代理都能用相同呼叫方式查詢。
MCP 伺服器負責執行存取邊界。它控制哪些欄位可以暴露、哪些動作允許執行、哪些稽核記錄需被保留。這就是治理團隊應該寫一次規則、不再為每位供應商重複撰寫的架構層。
MCP 實際解決了哪些企業層級的問題？
MCP 解決了四個讓 AI 專案變得昂貴且脆弱的企業級問題。第一是整合擴散，每個新 AI 工具都需要為相同內部系統重做連接器。第二是整合層的供應商鎖定。第三是稽核紀錄分散於多個供應商主控台。第四是安全政策被重複實作。
根據麥肯錫 2024 年 State of AI 報告，整合成本是企業 AI 預算中最大的隱性支出項目，通常佔總專案花費的 40 至 60%。MCP 將這條成本線壓縮為一次整合，足以服務你組織現在與未來部署的每一個 AI 客戶端。
對於要向財務總監簡報的 IT 總監而言，這是真正重要的那張投影片。MCP 之前的架構，三家 AI 供應商計價為三項整合。MCP 之後的架構，三家 AI 供應商計價為一項整合加三個設定檔。五年總持有成本的形狀因此改變。
MCP 為企業帶來哪些新風險？
MCP 帶來了過去封閉、特定供應商整合中並不存在的新風險。最立即的是存取控制漂移，意指 MCP 伺服器對外暴露了超出業務原意的能力。第二是提示注入升級，即使用者資料中的惡意指令說服 AI 觸發不安全的 MCP 動作。第三是社群打造之 MCP 伺服器的供應鏈風險。
緩解模式已相當成熟，但必須從一開始就納入設計。每個 MCP 伺服器都應以最小權限憑證連接底層系統，每一項透過 MCP 對外開放的工具都應通過與生產 API 相同的變更控制流程，每一個你組織內運行的 MCP 客戶端都應將每一次動作完整記錄到中央稽核儲存。
新成立的 Agentic AI Foundation 已在 Linux Foundation 之下接手管理 MCP，並陸續發布參考治理模式。你的資安團隊應在簽下第一份啟用 MCP 的供應商合約之前，就先讀完這些參考文件。
香港 IT 總監應如何在 2026 年依 MCP 評估 AI 供應商？
香港 IT 總監應在簽約前以五個問題評估每一位新的 AI 供應商。這五個問題測試的是：供應商會加速組織的 MCP 策略，還是悄悄再建立另一個整合孤島，成為日後的遷移成本。
五個問題很直接。第一，產品扮演 MCP host、MCP server，還是兩者皆是？第二，支援哪幾種 MCP 傳輸模式，供應商在驗證機制上是否與你整體技術棧一致？第三，供應商是否公布 MCP 功能與自家專屬整合達成同等功能的路線圖？第四，團隊能否完全透過 MCP 操作該供應商，或需平行運行專屬連接器才能取得完整功能？第五，供應商對 Agentic AI Foundation 治理路線圖的承諾為何？
任何一題上猶豫的供應商，等於是要你重複市場已標準化掉的採購錯誤。供應商的回答，是你判斷這份合約是長期投資或未來遷移成本的最佳前瞻指標。
企業導入 MCP 時最常見的陷阱有哪些？
常見陷阱可預測。第一是將 MCP 視為單一工程團隊的技術決策，但它其實是觸及資安、採購與資料治理的企業架構決策。第二是未經安全審查就急於部署社群 MCP 伺服器。第三是允許每個團隊各自開設 MCP 伺服器，缺乏中央目錄。
香港一家擁有 300 名員工的專業服務公司，最近就在第三項陷阱上付出了代價。三個部門各自架設了指向同一客戶資料庫的 MCP 伺服器，存取範圍不同、稽核記錄不一致。當公司試圖整合時，發現沒有任何部門能證明過去一季哪些 AI 代理存取了哪些客戶紀錄。事後補救耗費的時間，比原本部署更長。
可以辯護的模式，是建立由 IT 治理職能擁有的單一內部 MCP 註冊中心，並對每一個新 MCP 伺服器訂定明確的上線流程。每個伺服器進入生產環境時，必須有指定負責人、存取控制矩陣，與經過測試的稽核管線。沒有這些，MCP 只會變成影子 IT 的另一種樣貌。
結語：MCP 已是採購問題，不再是技術趨勢
模型上下文協議在不到兩年內，從 2024 年底 Anthropic 的一次發表，演變為基礎性的企業架構標準。董事會層級在 2026 年要問的不是「組織要不要採用 MCP」，而是「我們今年採購的 AI 供應商、內部平台與代理系統是否符合 MCP 規範，以及我們的治理框架是否涵蓋 MCP 整合所帶來的新風險」。
提早面對這道問題的 IT 總監，未來兩年將把時間花在擴張能力上。沒有面對的，則會花在重建平台上。懂AI的冷，更懂你的難 — UD 同行28年，讓科技成為有溫度的陪伴。
與 UD 邁出下一步
你已掌握策略框架，下一步是依 MCP 成熟度盤點現有 AI 供應商，並設計團隊所需的治理層。UD 擁有 28 年服務香港企業的經驗，手把手帶你完成每一步，從架構檢視、供應商評分卡，到 MCP 伺服器試點部署。
