ブログ一覧

2026.08.27

MCP協定如何讓企業 AI 工具整合更可靠

當 AI 助理能讀取文件、查詢庫存、建立工單，甚至協助起草回覆時，真正困難的往往不是模型會不會回答，而是能否安全、可控且可維運地連上正確工具與資料。MCP協定正是為此而生：它把模型與外部系統之間零散的客製串接，整理成一致的溝通方式，讓團隊更容易將 AI 從展示用對話框推進到可落地的業務場景。

企業導入生成式 AI 時，常同時面對 ERP、CRM、資料庫、雲端文件與內部 API；每增加一個模型或系統，串接關係就迅速膨脹。MCP 由 Anthropic 於 2024 年 11 月創建，並在 2025 年 12 月捐給 Linux Foundation 旗下的 AAIF，代表它正朝跨供應商的開放生態發展，而不只是單一產品的附屬功能。

本文會從 MCP 的架構與工具呼叫機制開始，說明它和 AI Agent、AI工作流程、AI 系統整合及 RAG 技術的實際關係；接著整理權限、版本、擴展與監控的治理要點。最後也會用 PoC 思維，帶你建立可量測、可判斷 Go／No-Go 的驗證計畫，避免尚未釐清需求就投入大規模開發。

MCP協定是什麼：先理解它解決的整合問題

MCP Host、Client 與 Server 的企業 AI 整合架構示意圖

MCP 的定位是模型與外部能力之間的共同語言

MCP 的直接價值，是讓 AI 應用以一致介面發現並使用外部能力，而不是為每一個模型、每一套系統重寫一次專屬連接器。它可被理解為模型端與資料、工具、提示資源之間的協定層；模型負責推理，Server 則以清楚的描述公開可用功能，讓應用程式能在適當時機提出工具呼叫。

若企業有 5 個 AI 模型要連 10 個內部系統，點對點串接可能形成 50 條整合線；採用共同協定後，設計可收斂為 M + N，也就是 15 條主要連接關係。這不代表整合工作自動消失，而是把驗證、授權、錯誤處理與文件規格集中，降低未來替換模型或新增系統時的改造範圍。

MCP 的生態成熟度也值得關注。AAIF 成員已從去年 12 月成立時的約 40 家，成長到如今的 240 家；核心維護者橫跨 Anthropic、微軟、OpenAI、Google 與 Amazon 五大科技公司。對企業而言，這表示協定相容性與治理討論不再只由單一廠商決定，但正式導入仍應先驗證自身情境。

  • 將工具與資料存取能力標準化，而非只標準化聊天介面
  • 降低多模型、多系統環境中的重複串接成本
  • 讓權限、稽核與版本策略能集中設計

Host、Client、Server 各自負責不同邊界

MCP 的基本架構可直接拆成三個角色：Host 是使用者操作的 AI 應用或執行環境，Client 負責在 Host 內維持與 Server 的協定連線，Server 則公開工具、資源或提示能力。這樣的分工讓聊天介面、桌面應用、IDE 或內部入口網站，都能以相近方式接上後端服務。

實務上，Host 應掌握人機互動、使用者身分與是否需要人工確認；Client 應處理協商、請求傳遞與連線生命週期；Server 應把資料庫查詢、CRM 搜尋、檔案讀取或工單建立封裝成可授權的能力。將三者混在同一服務雖然起步快，卻會讓存取控管、測試與橫向擴展變得困難。

開發時可從官方 SDK 快速開始，例如 Python 可使用 `pip install mcp`，JavaScript 則可使用 `npm install @modelcontextprotocol/sdk`。不過套件安裝只是第一步；更關鍵的是為每一項工具定義明確輸入、輸出、錯誤碼與權限邊界，避免模型用模糊的自然語言觸發不可逆的業務操作。

這張表可快速看出三個角色的責任邊界。
角色 主要責任 企業範例
Host 互動與授權確認 內部 AI 入口網站
Client 協定連線與請求傳遞 應用程式連接模組
Server 工具與資料能力公開 ERP 查詢服務
實際部署可依資安與網路分區，將角色配置在不同服務中。
  • Host 管理互動與使用者決策
  • Client 管理協定通訊與連線
  • Server 封裝業務工具、資源與存取規則

工具、資源與提示不是同一種能力

MCP Server 應先區分工具、資源與提示範本。工具適合執行動作或即時查詢，例如建立採購草稿、讀取訂單狀態；資源適合提供可被定位的內容，例如文件、設定或資料集；提示則適合封裝重複使用的任務指令。分類清楚後，模型較容易理解何時要讀取、何時要呼叫，以及何時需請使用者確認。

工具設計的核心不是功能越多越好，而是輸入越明確、結果越可驗證。例如「查詢客戶」應要求客戶編號或明確篩選條件，回傳資料也應限制必要欄位；「建立訂單」則應採兩階段操作，先產生草稿再確認送出。這可減少模型猜測參數、誤用工具及越權處理敏感資料的風險。

若使用 Azure 相關開發環境，可透過 `pip install azure-ai-projects azure-identity` 安裝相應套件；部署工具則需 azd，1.25 或更新版本。協定相容性同樣不能憑感覺判斷，測試封包可明確記錄 `protocolVersion”:”2025-03-26`，並依文件追蹤 Version 2026-07-28 (latest) 的行為差異。

  • 工具應採小而明確的業務動作設計
  • 讀取與寫入操作要分開授權與確認
  • 協定版本必須納入測試與部署紀錄

AI Agent透過 MCP 從回答問題走向執行任務

AI Agent 的關鍵是觀察、規劃、行動與回饋循環

AI Agent 的直接特徵，是不只生成一段文字，而是能根據目標觀察上下文、規劃步驟、選擇工具、執行行動並檢查結果。模型本身提供語言理解與推理能力，但 Agent 還需要提示策略、記憶、工具清單、狀態管理與評估機制；MCP 則能讓工具接取層以較一致的方式被納入這個循環。

以採購異常處理為例，Agent 可先讀取待審核訂單，再查詢供應商交期與庫存，最後產生建議草稿。此時最安全的做法不是讓它直接送出採購單，而是將寫入動作停在需要人員確認的節點。這種「建議—核准—執行」設計，通常比追求完全自主更適合剛開始導入的企業。

市場調查也提醒團隊應聚焦可控任務：62% of respondents were experimenting with agents，但 no more than 10% in any business function had scaled them。換言之，多數組織已在試驗，能跨過試驗階段的卻不多；應先把成功定義為準確率、完成時間、人工覆核率或例外案件比例，而不是只看展示效果。

  • 模型負責推理，Agent 負責任務循環與狀態
  • 高風險寫入操作應保留人工核准點
  • 先以可量測的單一流程驗證，再擴大範圍

工具設計決定 Agent 能否穩定完成工作

讓 Agent 穩定工作的直接方法，是把複雜流程拆成可觀察、可重試、可稽核的工具。與其提供一個名為「處理客訴」的大型端點，不如拆成查詢訂單、取得物流紀錄、建立回覆草稿、建立退款申請等小型能力；每次呼叫都能留下輸入、輸出、操作者與授權依據，方便後續追查。

工具描述必須寫出限制條件，而不只是功能名稱。例如退款工具要揭露金額上限、可退款原因與是否需要主管核准；查詢工具則要限制可讀取的客戶範圍。若 Server 回傳權限不足，Client 應能將錯誤導向正確流程，例如 `-32006` → 需取得 OAuth 同意，而不是讓模型持續嘗試或以不安全方式繞過控管。

評估也不能只看「有沒有成功呼叫」。可建立測試案例，從工具選擇正確性、參數完整性、結果引用正確性到拒絕越權要求等面向評分；部分評估框架會使用 scores from 0.0-1.0，使團隊可觀察每次提示、模型或工具版本調整後的品質變化，並設定是否可進入下一階段的門檻。

  • 將大任務拆成具備單一責任的小工具
  • 每項寫入工具都要定義授權與可逆性
  • 用量化評估追蹤工具選擇與執行品質

自主程度應隨風險逐步提高

企業應把 AI Agent 的自主程度視為分級設計，而非一次到位的開關。初期可讓 Agent 僅彙整資料和產出草稿，中期可在明確規則下執行低風險操作，成熟後才考慮跨系統協調。當工作涉及付款、合約、個資、醫療或生產排程時，人工覆核、權限分層與完整日誌應是預設條件。

導入者尤其不該把自主性誤認為商業價值。Gartner 曾預測，more than 40% of agentic AI projects will be canceled by the end of 2027；常見原因包括成本高於效益、資料品質不足、流程沒有真正改造，或團隊無法建立治理機制。因此，先找到高頻、規則相對明確且能量測的工作，比追逐全能型 Agent 更務實。

技術版本也應固定在可重現的基準上。例如開發團隊若評估 Deep Agents v0.7，應把模型版本、提示、工具 Schema、測試資料與權限設定一併記錄。只有在相同條件下比較，才知道效能差異源自 Agent 規劃策略、MCP Server 行為，還是資料來源本身已經改變。

  • 先從建議型 Agent 起步，再擴展到受控執行
  • 高風險決策保留人員最終責任
  • 將版本、測試與權限設定視為同一份交付物

用 MCP 串起可觀測的 AI工作流程

AI 工作流程應先定義觸發、判斷與例外處理

AI工作流程的直接目的，是將資料輸入、模型判斷、工具操作、人工核准及結果回寫串成可重複執行的業務流程。它與單次聊天不同，必須明確定義誰或什麼事件觸發流程、每一步需要哪些資料、失敗後如何處理，以及何時由人員接手。MCP 在其中扮演工具與資料能力的統一介面，而非取代流程編排本身。

採用率已說明企業關注度正在上升：2024 年有 72% 的組織採用了 AI，65% 的組織採用了生成式 AI，相較 2023 年的 55% 和 33% 皆有所提升。真正的挑戰不在於是否使用模型，而在於能否讓模型結果安全進入既有作業，例如把客服摘要正確寫回 CRM、把庫存建議送到審核流程，而非只停留在個人使用。

一個可落地的流程通常至少包含資料準備、推論與決策、執行或交接、回饋與改善 4 大階段。建議先以單一觸發事件試行，例如收到特定類型的客服信件後，自動擷取案件資訊、查詢訂單、產生回覆草稿並建立待辦；每一步都應能被重播、檢查與關閉，避免錯誤一路傳遞。

  • 先設計觸發條件與例外路徑，再選擇模型
  • 以 MCP 統一工具介面，以流程引擎管理順序
  • 每個節點都需保留輸入、輸出與處理責任

先比較工具成本，再決定是否要自行開發

選擇 AI工作流程平台時，直接判斷標準是：它能否滿足資料主權、權限、審計與既有系統連接需求，而不是功能清單最多。市場上常見的起始方案可能是 $9／人／月、$15／月、$19.99／月或 $99／月；這些價格可作為小型驗證的參考，卻未包含企業真正需要的身分整合、資安審查、客製連接器與長期維運成本。

若流程只是將表單資料搬移到通知工具，低程式碼平台可能足夠；若流程需要跨 ERP、CRM、內部資料庫與複雜權限，則應評估自建 MCP Server 或由工程團隊建立受控中介層。前者追求快速驗證，後者追求可靠性與治理；許多企業會先用前者梳理流程，再將已證實有價值的部分產品化。

選型時也不要只問「能不能串」。應要求供應商或內部團隊展示失敗重試、逾時處理、版本回退、敏感欄位遮罩、執行日誌匯出與人工介入方式。這些能力決定流程在每天大量使用後，是否仍能被營運與稽核團隊理解；若無法回答，低月費很可能換來後續更高的修正成本。

這張表可協助依流程風險選擇合適的實作方式。
方式 適合情境 主要限制
低程式碼平台 通知與表單自動化 複雜權限受限
MCP Server 自建 核心系統串接 需工程與維運
混合式架構 先驗證後產品化 需清楚責任分工
實際選擇仍須以資料敏感度、流量與既有架構評估。
  • 訂閱價格只反映入口成本，不等於整體擁有成本
  • 低程式碼適合驗證，關鍵流程仍需工程化治理
  • 選型展示應包含失敗處理與稽核能力

可觀測性讓流程問題能被定位而非猜測

要讓流程可維運，直接做法是為每次執行建立端到端追蹤識別碼，串起觸發事件、模型輸入摘要、工具呼叫、回應、人工修改與最終結果。當使用者反映「AI 為何做錯」時，團隊才能分辨是來源資料過期、模型理解錯誤、工具 Schema 不清楚，還是下游 API 逾時，而不是只靠對話紀錄猜測。

儀表板應同時追蹤成功率、平均處理時間、工具錯誤率、人工接手率、成本與業務 KPI。若客服草稿採用率低，問題可能在語氣或知識不足；若工具呼叫常失敗，問題可能在欄位驗證或權限。把營運指標和技術日誌放在一起，才能避免模型品質看似提升、實際工作量卻沒有下降的假象。

研究資料中提到超過 70% 的 Netic 客戶採用特定自動化做法，以及 75% 與 91% 等不同調查比例；這類數字可作為市場訊號，卻不能直接當作自家公司 ROI。每個流程都應以自身基準線比較，例如原本每件案件耗時、每週例外量及人工覆核工時，才有能力判斷擴大部署是否合理。

  • 以追蹤識別碼串起模型與工具的完整執行軌跡
  • 同時監控技術指標與業務成果
  • 外部比例只能參考，ROI 必須由自身基準驗證

RAG 技術與 MCP 如何讓回答可追溯又能採取行動

RAG 解決知識取用，MCP 解決系統能力取用

RAG 技術與 MCP 的直接差異是：RAG 先從文件或知識庫檢索相關內容，補足模型當下所需的上下文；MCP 則讓應用程式能標準化地存取外部工具、資源與動作。前者著重「回答依據在哪裡」，後者著重「下一步可以安全做什麼」，兩者結合後才能支援從查詢規範到建立業務草稿的完整任務。

例如人資助理先以 RAG 技術找出公司請假規定、員工手冊與表單說明，再透過 MCP Server 查詢剩餘假別與假期衝突。系統應在回答中區分檢索到的政策內容與即時系統資料，並在送出申請前請使用者確認。這能降低模型把舊文件、推測內容或不具權限的資料當成事實的機會。

關鍵原則是把知識庫與交易系統視為不同信任層。文件檢索結果可以支援解釋與建議，但不應自動授權寫入；相反地，交易系統的 API 必須以最小權限公開操作。若將所有內容直接塞進提示，既增加成本，也會讓資料更新、權限判斷與來源追溯變得模糊。

  • RAG 處理知識檢索與引用，MCP 處理工具與動作
  • 政策文件與即時交易資料必須清楚區分
  • 檢索內容不應自動轉化為寫入權限

知識品質必須用來源與更新機制維持

要提高 RAG 技術品質，直接做法是先整理文件擁有者、更新頻率、權限、版本與適用範圍，而不是一開始就大量匯入檔案。過期的制度文件、重複的簡報與沒有上下文的表格，會讓檢索結果互相矛盾。每一份知識內容都應能回答：誰維護、何時更新、適用哪個部門，以及失效後如何下架。

檢索後的回應應附上可供人員開啟的來源標示，並讓使用者能回報「資料已過期」「答案不適用」或「缺少文件」。這些回饋不是單純的滿意度調查，而是知識治理的輸入。高頻被質疑的文件應被優先修訂，常找不到答案的問題則可能需要補建內容或新增受控工具。

當知識庫需要查詢即時數據時，可讓 RAG 負責縮小問題範圍，再由 MCP 工具取得權威資料。例如使用者詢問「這張訂單能否取消」，文件可說明取消規則，但最終判斷仍須查詢訂單狀態、出貨進度與權限。這種分層設計比讓模型自行推論更容易測試，也較符合企業風險控管。

  • 知識文件需要擁有者、版本與失效規則
  • 回覆應能連回來源並收集錯誤回饋
  • 即時判斷應由受控工具讀取權威系統

避免提示注入要從信任邊界開始設計

防範提示注入的直接原則，是把外部文件、網頁與工具回傳內容視為不可信資料，而非可直接執行的指令。即使檢索內容出現「忽略規則」「傳送機密資料」等語句，Agent 也不應改變系統權限或工具政策。Host 的系統指令、MCP Server 的授權規則與使用者確認流程，必須優先於任何外部內容。

Server 端應採最小權限、參數驗證與允許清單。查詢工具不應接受任意 SQL；檔案工具不應能跨越指定目錄；發送與寫入工具則應限制目標、金額、筆數或環境。對高風險請求，可要求再次驗證身分或改由人員完成，並將拒絕原因記入日誌，讓資安團隊能持續調整規則。

企業也應將測試案例納入惡意文件、越權提問、偽造工具回應與過量呼叫等情境。若只在正常問題上測試，正式環境一旦遇到含有攻擊文字的 PDF、Email 或網頁，就可能暴露資料。安全並非在模型外加一條規則就結束，而是要落實到資料、工具、身分與監控的每一層。

  • 將檢索內容與網頁內容視為不可信輸入
  • 以最小權限和參數驗證限制工具行為
  • 把攻擊情境納入上線前與持續測試

AI 系統整合的 PoC 與正式部署治理方法

PoC 應驗證商業假設，不只是做出聊天展示

AI 系統整合的 PoC，直接目的應是回答「這個場景是否值得正式開發」，而不是只做出能展示的介面。建議先選擇一項可量測的流程，例如需求預測、客服案件分類或內部知識查詢，設定成功門檻、資料範圍、可使用工具與人工覆核規則；完成後以真實工作資料驗證精度、耗時、例外率及現場可用性。

ALION 的做法是從現場調查與訪談開始，將目的與 KPI、驗證範圍、原型實證及投資判斷拆成四個階段。這種小規模起步的方式特別適合 MCP 場景，因為團隊可先驗證一個 Server 是否能安全連接特定資料與工具，再決定是否擴展到更多部門，而非一開始就全面打通所有系統。

需求預測是典型案例：先用過往銷售與庫存資料比較多個預測模型，再將結果放進下單與生產計畫的示範流程，試算缺貨與庫存過剩改善的效益。若 MCP 工具需要讀取庫存或產生建議，也應先限制為唯讀與草稿輸出；驗證使用者是否採納後，才評估是否開放更高風險的寫入操作。

  • PoC 必須預先設定 KPI、資料範圍與停止條件
  • 先驗證單一 MCP Server 與單一業務成果
  • 用真實資料與現場回饋做 Go／No-Go 判斷

版本與相容性政策是長期維運的基礎

正式部署後，最直接的治理要求是把工具 Schema、協定版本、模型版本與權限政策納入變更管理。若 Server 任意更改欄位名稱或回傳格式，原本可運作的 Agent 可能在不易察覺的情況下做出錯誤判斷。因此每次變更都應有測試環境、相容性驗證、發布紀錄與回退方案，並指定服務負責人。

對外公布的工具不應突然移除。較穩健的作法是提供新舊版本平行期、明確標示棄用日期，並至少間隔 12 個月通知重大遷移；若出現資安或重大營運風險，硬底線是 90 天內處理。這樣能兼顧使用端調整時間與平台治理責任，也讓跨部門系統不會因單次更新而全面中斷。

部署策略可先採 Stateful 連線以簡化會話與除錯，再依流量和可用性需求評估 Stateless 架構、負載平衡與橫向擴展。無論哪一種方式，身分驗證、授權決策與稽核日誌都不應只留在單一應用伺服器記憶體中；否則擴展節點後，容易出現權限不一致與事件難以追蹤的問題。

  • Schema、模型與權限都需納入版本控制
  • 以平行版本與棄用通知維持相容性
  • 擴展架構時保留一致的身分與稽核紀錄

從小規模交付，建立可持續的內部能力

最務實的導入路徑，是先選一個跨系統但風險可控的任務，交付可用原型與完整決策證據，再擴大到下一個流程。ALION 的 AI 上游工程訂閱服務月費 20 萬日圓起，包含每週一次定期會議、需求定義、設計文件與示範製作；對尚未確定是否需要全面開發的團隊而言，這比一開始承擔大型專案範圍更容易建立共識。

成本比較也應看見不確定性的代價。資料顯示，聘僱 CTO 級人才的月薪可達 80〜150 萬日圓，委託外包開發的啟動費約 300 萬日圓起；若以 1,000 萬日圓規模的開發案估算，上游工程約需 3 個月（約 60 萬日圓）。先做小範圍驗證，能讓企業在投入正式預算前確認資料、流程與使用情境是否成立。

真正可持續的 AI 系統整合，不是把責任完全交給模型或外包團隊，而是讓業務、資訊、資安與管理者共同擁有流程規則。PoC 應留下可延續的架構圖、工具定義、測試案例、權限矩陣與 KPI 報告；這些資產能減少正式開發時的交接損耗，也使日後替換模型或擴增 Server 時仍保有主導權。

  • 以小規模原型降低需求不明造成的投資風險
  • 評估成本時應計入上游規劃與後續維運
  • 把設計、測試與權限文件沉澱為可延續資產

總結

MCP協定的核心價值，不是單純增加一個新名詞，而是替模型、工具與企業資料建立可治理的連接方式。當它與 AI Agent 的任務循環、AI工作流程的編排、RAG 技術的知識檢索結合後，企業才能把 AI 從單點回答推進到可追溯、可控制、可評估的實際作業。

重點整理

  • 先用 Host、Client、Server 劃清互動、通訊與業務能力的責任邊界。
  • 先驗證唯讀查詢與草稿產出，再開放具風險的寫入工具。
  • 將來源、權限、版本、日誌與人工覆核視為正式功能，而非事後補強。
  • 以 PoC 的 KPI 和真實資料判斷價值，避免只根據展示效果擴大投資。
  • 參考來源：MCP 規格與文件 https://modelcontextprotocol.io/ ｜ Anthropic 官方公告 https://www.anthropic.com/news/model-context-protocol ｜ Linux Foundation AAIF https://www.linuxfoundation.org/press/linux-foundation-launches-agentic-ai-foundation ｜ McKinsey AI 調查 https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai

若你正規劃讓 AI 讀取內部知識、查詢 ERP／CRM 或協助跨系統作業，建議先挑選一個具明確 KPI 的流程，盤點資料權限與人工確認點，再以最小 MCP Server 原型驗證。先釐清「是否值得做、怎麼做才安全」，才能讓後續的正式部署更快取得內部信任。

常見問題 FAQ

Q1. MCP協定是否等於 API？

不是。API 是系統提供功能的介面；MCP協定則是讓 AI 應用以一致方式發現、描述與呼叫工具、資源及提示能力的協定層。企業通常仍會在 MCP Server 後方使用既有 REST API、資料庫或 SaaS API。

Q2. 導入 MCP 是否一定要建立 AI Agent？

不一定。MCP 可先用於一般聊天助手或 IDE，讓它受控地查詢資料與使用工具。AI Agent 則是在此基礎上加入規劃、記憶、循環執行與結果評估；是否需要採用，取決於任務是否真的需要多步驟自主處理。

Q3. RAG 技術和 MCP 可以一起使用嗎？

可以，而且兩者功能互補。RAG 技術提供文件檢索與來源依據，MCP 提供即時查詢及受控操作能力。建議將文件知識、即時交易資料與寫入權限分層設計，並對任何高風險動作保留人工確認。

Q4. 企業第一次驗證 MCP 時應從哪裡開始？

先選擇一個高頻、資料範圍清楚且風險較低的流程，例如唯讀查詢、文件摘要或草稿建立。定義 KPI、權限、測試案例與人工覆核點，再以小型 PoC 驗證工具穩定性、使用者採用率及實際節省的工時。

Q5. 本文的參考資料有哪些？

可優先查閱 Model Context Protocol 官方文件：https://modelcontextprotocol.io/；Anthropic MCP 公告：https://www.anthropic.com/news/model-context-protocol；Linux Foundation Agentic AI Foundation 資訊：https://www.linuxfoundation.org/press/linux-foundation-launches-agentic-ai-foundation；以及 McKinsey 的 AI 採用調查：https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai。



ブログ一覧へ戻る