「下週要去東京拜訪客戶，幫我安排三天行程。」
如果這句話交代給一位熟悉主管工作的資深秘書，通常不是太困難的任務。
秘書掌握主管的行程習慣，熟悉公司的差旅規定與預算上限；安排差旅的過程中，他知道該去哪裡查航班、挑飯店、安排交通，也知道哪些事情可以自行處理、哪些環節需要主管確認，甚至能在授權範圍內使用公司信用卡完成付款。
許多人可能會問： 「現在的 AI 不是也會查資料、排行程嗎？」
沒錯 ! 問題就在這裡。
AI 能告訴你「東京三天兩夜可以怎麼安排」，不代表它已經能讀取主管真正的行事曆、取得公司差旅預算、查詢即時航班與房價，更不代表它有權限替公司送出訂單或付款。
從「回答問題」到「實際完成工作」，AI 還需要能與真實世界中的資料、系統與工具溝通。
這正是 MCP（Model Context Protocol，模型上下文協定） 開始受到企業關注的原因。
如果把 AI Agent 想成一名能獨立作業的「數位員工」，MCP 就是讓它能以標準化方式使用不同系統工具的共通語言。
AI Agent 已經會思考、會規劃，為什麼還需要 MCP？
AI Agent 和一般聊天型 AI 最大的差別，在於它不只是回答問題，而是能根據目標規劃下一步，並透過不同工具逐步完成任務。
例如主管交代了一句：
「幫我安排下週三到週五的東京出差。」
AI Agent 接到任務後，需要逐步確認哪些事情？
- 主管可出發的時段？
- 公司差旅規定？
- 這次出差有多少預算上限？
- 有哪些航班符合時間與艙等？
- 哪些飯店符合公司補助標準？
- 當地的交通與拜訪行程如何銜接？
- 方案排定後是否需要主管核准？
- 最後由誰完成訂票與付款
問題是，這些資訊並不全部存在 AI 模型裡。
主管的時間在企業行事曆，預算可能在 ERP 或財務系統，差旅規定存在企業文件或知識庫，即時航班與房價則來自外部服務。
所以，AI Agent 知道下一步該做什麼，不代表它已經擁有完成下一步所需要的工具。
這也是企業導入 AI Agent 時很重要的一道分水嶺：
AI 能不能回答是一件事；AI 能不能取得正確資料、使用正確工具並參與真實工作流程，是另一件事。
而 MCP 要處理的，正是 AI 應用程式與這些外部工具、資料來源之間的標準化溝通問題。
MCP 是什麼？讓 AI Agent 有方法使用不同工具
MCP 英文全名是 Model Context Protocol（模型上下文協定）。
簡單來說，MCP 是一套開放標準，讓 AI 應用程式可以用較一致的方式連接外部資料來源、系統與工具。
它不是 AI 模型，也不是一個裝滿企業資料的資料庫，更不是讓 AI 自動取得所有系統權限的萬能外掛。
用一句話來理解：MCP 解決的是「AI 應用程式如何用標準化方式理解與使用工具」的問題。
例如：
AI Agent 想查航班，需要使用航班查詢工具；想確認預算，需要存取 ERP 或財務系統提供的能力；想確認主管時間，需要使用企業行事曆。
過去每個系統都有自己的 API、資料格式與串接方式，開發者往往需要針對不同服務分別處理整合邏輯。
MCP 的價值不是讓這些整合工作全部消失，而是建立一套共同的溝通標準，降低 AI 應用程式面對不同工具時，各自客製串接的複雜度。
MCP讓企業系統串接有了解決方式 ! 藍星球資訊AI導入專家
如果 AI Agent 是哆啦A夢，MCP 就是「道具的統一使用說明書」
如果用大家熟悉的哆啦A夢來比喻：
- AI Agent 就是哆啦A夢本人，負責思考、理解大雄的需求，並想辦法解決問題。
- 各個系統工具（ERP、CRM、航班服務、行事曆），就是百寶袋裡來自不同製造商的各種神奇道具（竹蜻蜓、任意門、時光機）。
- MCP：比較像能讓哆啦A夢理解「我有哪些道具、每個道具能做什麼、該提供哪些參數」的共同規格。
但百寶袋裡的道具千奇百怪，哆啦A夢怎麼知道每一項新道具該怎麼操作？
假設今天多了一個「航班查詢工具」。
AI Agent 至少需要知道：
- 這個工具能做什麼
例如：查詢特定日期、出發地與目的地的航班。 - 使用時需要提供什麼資料
例如：出發地、目的地、日期與其他必要條件。 - 這個工具會回傳什麼結果
例如：航班時間、票價、艙等或其他資料。
透過標準化的工具描述與輸入方式，AI 應用程式比較容易理解不同工具的用途，以及該如何正確使用它們。
如果把這些工具比喻成哆啦A夢的各種「道具」，MCP 就像一套共通的使用規格：讓 AI Agent 知道有哪些道具可以使用、每項道具能做什麼，以及使用時需要提供哪些資訊。
當企業能使用的工具越來越多時，MCP 的價值也會更加明顯——不必讓 AI 面對每個工具時，都重新學習一套完全不同的溝通方式。
MCP 和傳統 API 有什麼不同？
這是企業第一次接觸 MCP 時最常出現的問題之一，API 可以想成某個系統對外提供資料或功能的「接口」。例如訂房服務提供 API，其他應用程式就可以按照規定的格式查詢房價、房型或建立訂單。
那為什麼，有了 API，為什麼還需要 MCP？
MCP 不是要取代 API，而是解決不同層次的問題
- API：提供某個系統的資料或功能。
- MCP：提供 AI 應用程式與工具、資料來源溝通的一套標準方式。
很多情況下，企業原本的 API 不需要全部推翻重做，而是可以透過 MCP Server 將既有能力提供給支援 MCP 的 AI 應用程式使用。
因此，MCP 的價值並不是「API 從此沒有用了」，而是讓 AI Agent 面對不同系統與工具時，可以有更一致的整合方式。
一趟商務出差，MCP 會怎麼幫助 AI Agent 運作？
回到文章一開始的情境。
主管只交代了一句話： 「下週去東京拜訪客戶，幫我安排三天行程。」
AI Agent 接到任務後，不需要把所有系統都「砍掉重練成 AI」。它只需要在正確的時間點，使用完成任務所需要的工具。透過下面這張表，能清楚看出傳統做法與導入 MCP 協定後的差異。
一趟東京出差背後，AI Agent 可能需要使用這些系統
| 任務環節 | 需要使用的工具／資料 | 傳統整合方式 | 透過 MCP 後的角色 |
|---|---|---|---|
| 1. 確認差旅制度 | 企業差旅規章／知識庫 | 人工查閱，或另外設計資料查詢方式 | 可將規章查詢能力標準化提供給 AI Agent 使用 |
| 2. 確認可用預算 | ERP／財務系統 | 依 ERP API 或既有介面個別整合 | 可將既有系統能力封裝成 MCP 工具，供 AI Agent 在授權範圍內查詢 |
| 3. 查詢即時航班 | 航空公司／票務服務 | 依不同服務商 API 個別串接 | 若服務提供 MCP Server，或既有 API 被封裝為 MCP 工具，AI Agent 可透過標準方式使用 |
| 4. 篩選合格飯店 | 訂房服務／住宿資料 | 分別處理 API、資料格式與驗證 | 可將訂房查詢能力提供為工具，再由 AI Agent 結合預算與地點條件篩選 |
| 5. 對齊主管空檔 | 企業行事曆 | 個別處理 API、OAuth 與排程邏輯 | 可將行事曆能力提供給 AI Agent，實際可讀、可寫範圍依授權設定 |
| 6. 綜合規劃方案 | AI Agent 推理與工作流程 | 人工彙整不同系統的零散資訊 | AI Agent 可整合各工具回傳結果，整理出數套出差方案 |
| 7. 遞交審批簽核 | BPM／企業簽核系統 | 人員登入系統填寫並送件 | 若企業開放相應能力，AI Agent 可建立簽核草稿或送入指定流程 |
| 8. 授權出票付款 | 具交易能力的授權系統 | 通常由人員確認並完成交易 | MCP 可提供工具溝通方式，但付款權限、身分驗證與人工審批仍由企業另外控管 |
有了 MCP，跨系統工作更像一場有共同規則的接力賽 ：
查差旅規定 → 確認預算 → 查航班 → 查飯店 → 比較方案 → 整理結果 → 送主管簽核。
主管看似只交代了一句話，背後其實是一場跨越七、八個系統的接力賽。過去工程團隊需要理解每一套系統的介面，再分別處理串接方式；當工具數量增加，整合與維護成本也會跟著增加。
MCP 的價值，就在於為 AI 應用程式與這些工具之間建立一套共同的溝通標準。
但要特別注意：MCP 標準化的是「怎麼溝通與使用工具」，不代表企業原本的 API、身分驗證、權限控管與系統整合工作全部消失。 這個差別對企業導入 MCP 非常重要。
MCP 可以連接外部服務嗎？
答案是可以，但前提是外部服務本身具備適合的整合方式。這也是 MCP 在企業 AI Agent 應用中很重要的一環。
以商務出差為例，它可能同時需要：
外部服務系統：
- 航班與票務服務
- 訂房服務
- 地圖與交通
- 天氣資訊
企業內部系統：
- ERP／財務系統
- CRM
- 員工行事曆
- 差旅規章
- 簽核系統
但這裡必須先釐清一項常見迷思：MCP 可以連接外部服務，不等於「能隨意連上任何網站」。
許多人常誤以為裝了 MCP，AI 就能在網路上像真人一樣，隨便打開任何網站自動點擊與抓取資料。事實上，MCP 既不是萬能爬蟲，更不是開了外掛的瀏覽器。
MCP 的真正價值，不是讓 AI「任意連網」。如果外部服務要成為 AI Agent 可以使用的工具，仍需要具備適合的整合方式，例如服務本身提供 MCP Server，或透過既有 API 建立 MCP Server。
外部服務接進來之後，企業要建立的管理機制
工具接進來之後，企業仍需要自行決定 AI Agent 可以使用哪些資料與功能，並建立相應的安全管理機制。
至少包括：
- 身分驗證：誰正在使用這項服務？
- 存取權限：AI 可以使用哪些工具與功能？
- 資料範圍：AI 可以取得哪些資料？
- 操作權限：只能查詢，還是可以建立、修改或送出？
- 人工審批：高風險操作是否需要真人確認？
- 操作紀錄：重要行為是否留下可追蹤的紀錄？
所以 MCP 比較像替 AI Agent 建立「標準化的工具通道」，而不是把公司的系統與資訊全部打開。
導入AI技術實戰經驗豐富 – 藍星球資訊幫企業釐清需求
MCP把工具接上後，誰決定 AI Agent 能做什麼？
回到文章開頭。過去的私人秘書之所以可以查閱主管行程、處理差旅，甚至在授權範圍內經手公司信用卡，是因為企業制度已經賦予他明確的職務範圍、資料存取權、工具使用權，以及相應的核銷責任。 AI Agent 也是如此。
AI Agent 的權限可以依風險分級
以出差任務為例：
- 查詢公開航班：可開放查詢
- 比較不同出差方案：可由 AI 自動處理
- 讀取內部差旅預算：依身分與任務授權
- 建立預訂或簽核草稿：可在限定流程內執行
- 最終付款或交易：提高權限門檻，視企業政策加入人工確認
這正是企業導入 AI 時不能只看單一能力的原因。MCP 解決的是「工具怎麼接、AI 怎麼使用」；企業治理決定的則是「AI 有多少權限、哪些事情可以執行，以及哪些操作必須由人確認」。兩者處理的是不同問題，不能混為一談。
MCP 串得越多，AI Agent 就越強嗎？
答案是不一定。工具的數量，從來不等於解決問題的品質。
如果企業一次把數十個甚至上百個工具全部開放給 AI Agent，不只會增加工具選擇與工作流程的複雜度，也會增加權限管理、測試、監控與維護的負擔。
例如一個專門負責安排差旅的 AI Agent，真正需要的可能只有：
- 差旅規章
- 預算系統
- 航班服務
- 訂房服務
- 行事曆
- 審批流程
它沒有必要同時取得公司所有 CRM 客戶資料、人事資料或其他與任務無關的系統權限。
企業看 MCP，真的不是把手邊有的工具通通接上就叫厲害。更合理的做法是先從簡單的小任務開始練兵：先定義 AI Agent 要完成什麼任務，再決定完成這項任務最少需要哪些工具與權限。
從低風險起步：四階段落地路徑
MCP 解決工具連接與標準化溝通的問題，但企業的資安、權限與治理仍然需要另外設計。實際導入時，可以從低風險工作逐步增加 AI Agent 的操作能力。
「查詢 → 建議 → 草稿 → 執行」
第一階段（查詢）：先讓 AI Agent 查詢公開航班、企業規章或其他低風險資料，確認資料取得與工具使用是否正確。
第二階段（建議）：讓 AI Agent 結合差旅規定、預算與航班資訊，整理出 2～3 套方案供人員選擇。
第三階段（草稿）：讓 AI Agent 建立行程、申請單或簽核草稿，但尚未真正執行高風險操作。
第四階段（執行）：當流程、權限與驗證機制都成熟後，再評估哪些工作可以讓 AI Agent 在授權範圍內執行。
涉及付款交易、刪除資料、異動核心系統等高風險操作，企業則可以依風險政策設計 Human-in-the-Loop（人工介入／人工確認） 機制。
這不是因為 MCP 本身不安全，而是企業原本就應該清楚管理誰可以使用什麼工具、取得哪些資料、執行哪些動作，以及出了問題如何追蹤。
MCP、RAG、提示、情境、駕馭工程，到底差在哪？
當企業開始研究 AI Agent，常會同時看到 Prompt Engineering、Context Engineering、MCP、RAG、Harness Engineering 等名詞。其實它們處理的是不同問題。
如果把 AI Agent 想成一名剛進公司的數位員工：
- 提示工程（Prompt Engineering）：告訴 AI 這次要完成什麼任務，以及希望如何回應。
- 情境工程（Context Engineering）：替 AI 準備完成當下任務所需要的背景、狀態與相關資訊。
- MCP（Model Context Protocol）：建立標準化的連接方式，讓 AI 應用程式能與外部工具和資料來源溝通。
- RAG（檢索增強生成）：讓 AI 在回答或執行任務前，從指定知識來源檢索相關內容，再把這些內容提供給模型。
- 駕馭工程（Harness Engineering ）：設計 AI Agent 實際運作所需要的工作環境，包括工具、權限、流程、驗證、監控與錯誤處理等機制。
它們不是互相取代，而是可能共同出現在一套完整的企業 AI Agent 架構裡。有了 MCP，就像替這名數位員工建立了一套使用工作工具的共通方式，讓它有機會連接外部服務，也能在企業允許的範圍內使用內部系統。
接下來的問題是：AI Agent 要怎麼在企業累積了幾年甚至幾十年的文件、制度、產品資料與專業知識中，找到這次任務真正需要的內容？
這就是 RAG 要處理的問題。
下一篇，我們繼續聊 RAG：有了會用工具的雙手之後，怎麼幫 AI 裝上企業專屬的知識庫？
宋浩 博士
藍星球資訊總經理
企業評估 AI Agent 時，不能只看模型有多聰明。模型知道下一步該做什麼，與它真的能取得資料、使用工具並完成工作，是兩件不同的事。
MCP 的價值，在於建立 AI 應用程式與外部工具之間較一致的溝通方式。當企業需要串接的系統越來越多，標準化的工具介面，能降低每一項能力都必須重新設計整合方式的複雜度。
因此，企業導入 MCP 時，真正該盤點的不是「能接多少工具」，而是每一個工作任務需要哪些資料、哪些系統，以及工具之間如何以一致方式被 AI Agent 理解與使用。先把任務與工具關係定義清楚，再談權限與治理，會比一次把所有系統接上更有價值。
MCP 模型上下文協定常見問題 FAQ
Q1 MCP 是什麼？
MCP（Model Context Protocol，模型上下文協定）是一套開放標準，讓 AI 應用程式能以較一致的方式連接外部工具、資料來源與服務，讓 AI Agent 更容易理解並使用完成任務所需要的工具。
Q2 為什麼 AI Agent 需要 MCP？
AI Agent 即使能理解任務、規劃步驟與進行推理，也不代表它能直接使用 ERP、CRM、行事曆、航班或其他外部系統。MCP 提供標準化的溝通方式，讓 AI 應用程式可以理解與使用提供給它的工具。
Q3 MCP 和 API 有什麼不同？
API 是系統對外提供資料或功能的介面；MCP 則提供 AI 應用程式與工具、資料來源溝通的標準方式。MCP 並不是 API 的取代品，既有 API 也可以透過 MCP Server 提供給支援 MCP 的 AI 應用程式使用。
Q4 MCP 可以連接企業內部系統嗎？
可以。ERP、CRM、行事曆、資料庫、知識庫與審批系統等，都可以透過適當的整合方式提供給 AI Agent 使用。但實際可以讀取哪些資料、執行哪些功能，仍取決於企業的系統架構與權限設定。
Q5 MCP 可以連接外部網站或服務嗎？
可以連接外部服務，但不代表任何網站都能直接透過 MCP 使用。外部服務需要具備適合整合的能力，例如提供 MCP Server，或透過既有 API 建立 MCP Server，並搭配必要的身分驗證與授權機制。
Q6 MCP 和 RAG 有什麼不同？
MCP 主要處理「AI 如何連接與使用工具」；RAG 主要處理「AI 如何從指定知識來源檢索這次任務需要的內容」。兩者可以同時存在於一套 AI Agent 工作流程中。
Q7 MCP 會不會造成企業資料外洩？
MCP 本身不是完整的企業資安或權限管理機制。企業仍需要搭配身分驗證、資料權限、工具權限、人工審批、操作紀錄與既有資安政策，決定 AI Agent 可以取得哪些資料，以及能執行哪些動作。
Q8 企業導入 MCP 應該從哪裡開始？
建議先選擇低風險、規則明確的工作，從「查詢 → 建議 → 草稿 → 執行」逐步增加 AI Agent 的能力與權限，而不是一開始就讓 AI Agent 存取或操作所有企業系統。
延伸閱讀 :
LLM是什麼？與生成式AI差在哪？大型語言模型原理與模型比較
