2026/08/20When AI Becomes a New User of Enterprise Software
人工智慧與機器學習｜約沛科技｜2026/08/20
過去二十多年，企業軟體主要服務兩種使用者：透過畫面操作系統的人，以及透過 API 呼叫功能的其他程式。AI Agent 正帶來第三種使用者。它會理解任務、探索可用工具、讀取資料，再自行決定下一步。Model Context Protocol，也就是 MCP，因此值得關注的原因，不只是它提供另一種串接技術，而是它正在讓企業第一次系統化地思考：軟體要如何把自己的能力「說給 AI 聽」。
2024 年 11 月，Anthropic 發布 Model Context Protocol 時，提出的是一個看似單純的工程問題：大型語言模型的能力快速提升，可是模型仍被困在資料孤島之外。每增加一個資料來源或企業工具，人工智慧應用就必須重新開發一次專屬整合，因此當模型、工具與資料來源同時增加時，系統會變得愈來愈難維護。Anthropic 希望用一套共同協定，讓人工智慧應用與外部資料和工具建立標準化的雙向連線。
不到多之後，這個原本由單一人工智慧公司提出的協定開始跨出原有生態系。OpenAI 在 Responses API 與 Agents SDK 中加入遠端 MCP Server 支援，使開發者可以直接讓模型連接符合 MCP 規格的工具；Google Cloud 隨後宣布提供官方 MCP Server，讓 Google 服務能透過共同協定被人工智慧應用使用。
2025 年 12 月，Anthropic 又把 MCP 捐給 Linux Foundation 旗下新成立的 Agentic AI Foundation。Linux Foundation 公布的創始與白金會員包含 Anthropic、OpenAI、Amazon Web Services、Google、Microsoft、Cloudflare 等公司。到了 2026 年，基金會持續增加金融、基礎設施、政府與企業軟體領域的新成員，顯示 Agent 互通與開放標準已經開始從單一產品功能，變成產業共同關注的基礎設施議題。
然而，企業真正應該注意的並不是「大家都在支援 MCP」這件事本身。更根本的變化是：人工智慧不再只站在系統外面讀一段貼上去的文字，而開始變成企業軟體的正式使用者。它需要知道公司有哪些工具、每個工具是做什麼的、需要哪些參數、目前的使用者有沒有權限，以及執行完成之後會得到什麼結果。
這件事情如果持續發展，企業軟體的介面可能會出現過去二十年少見的重大變化。如同網頁介面讓人類能使用軟體、API 讓其他程式能整合軟體，MCP 類型的協定正在嘗試建立第三種介面：讓 AI 能理解並操作軟體。真正值得討論的因此不是一個新的技術縮寫，而是企業系統開始必須為「非人類使用者」設計能力。
從 API 介面走向 AI Tool Interface
假設一套客戶關係管理系統提供一個 REST API：POST /customers/{id}/tasks。對傳統應用程式而言，只要工程師看過 API 文件，就能寫程式決定何時呼叫它、傳入什麼資料，以及失敗之後怎麼處理。所有「理解」都存在工程師寫好的程式碼裡。
AI Agent 的運作方式不同。使用者可能只說：「把半年沒有聯絡、今年消費超過一百萬元的客戶整理出來，檢查最近的往來紀錄，然後替需要追蹤的人建立業務任務。」Agent 必須先理解目標，再知道企業現在有哪些工具可以使用，依序查詢客戶、取得交易資料、讀取歷史紀錄，最後決定是否建立任務。它需要的已經不只是 API 位址，而是一份可以讓模型理解「這個能力可以做什麼」的工具描述。
MCP 就是在這個層次上增加了一個標準化介面。MCP Server 可以把資料、工具與提示等能力以固定方式提供給 MCP Client，讓 Agent 能先列出有哪些工具，再依工具的名稱、描述與參數決定是否呼叫。Google Cloud 對 MCP 的說明也直接把 MCP Server 定義為把 API、資料庫或服務能力透過標準介面提供給人工智慧應用的程式。
因此，MCP 並不是要淘汰 API。多數 MCP Server 的後端仍可能呼叫 REST API、GraphQL、資料庫或既有企業服務。真正的改變是，API 上面開始多了一層為 AI Agent 設計的語意與互動介面：API 告訴程式「怎麼呼叫」，MCP Tool 則進一步告訴人工智慧「這項能力是什麼，以及怎麼使用」。
重新定義企業系統的介面
如果這個趨勢持續，未來企業軟體可能需要同時管理三種介面。第一種是 Human Interface，也就是網頁、行動應用程式與其他讓人操作的畫面；第二種是 Application Programming Interface，也就是提供其他程式使用的 API；第三種則是 AI Tool Interface，讓人工智慧能理解系統提供哪些能力。
這三種介面服務的是同一套企業能力，只是使用者不同。以建立採購單為例，人類可能透過畫面填表；另一個系統可以呼叫 API；AI Agent 則可能透過 MCP Tool 理解「建立採購單」的用途、所需欄位與限制，再根據使用者要求決定是否呼叫。企業不需要重新打造三套核心商業邏輯，但需要思考三種使用者如何安全進入同一套能力。
這個變化也會重新影響企業採購軟體的方式。過去資訊主管會問供應商：「你們有 API 嗎？支援單一登入嗎？可以串 Webhook 嗎？」未來可能會多問：「Agent 可以使用哪些功能？有沒有標準的 MCP Server？每一個 Tool 可以獨立授權嗎？Agent 的操作能不能留下稽核紀錄？」就像 API 曾經從加分功能變成企業軟體的基本能力，AI 介面也可能逐步走上相同的道路。
定義 MCP 在企業架構中的位置
MCP 本身是一套通訊協定，而不是完整的企業人工智慧治理平台。因此，企業導入 MCP 時不能把「有 MCP」與「可以安全上正式環境」畫上等號。一套完整的企業架構仍然可能包含幾個不同層次：
- AI Agent 或 MCP Client：理解使用者目標、規畫工作並選擇工具
- MCP Gateway 或企業控制層：處理身分、授權、流量、憑證、紀錄與政策
- MCP Server：把企業資料與功能描述成 Agent 可以使用的標準能力
- Enterprise System：真正保存資料、執行商業規則與完成交易
這種分層的目的，是把「人工智慧怎麼思考」與「企業允許它做什麼」分開。Microsoft 在 2026 年公開自己的 MCP 安全治理方式時，甚至明確表示，會把遠端 MCP Server 放在 API Gateway 後方，再加上審查、身分管理、隔離與適當的減速機制，以避免 Agent 因為 MCP 標準化連線而直接取得無限制的企業能力。
Amazon Web Services 的 AgentCore Gateway 也採取類似方向。它不只把 MCP Server 聚合成單一入口，也負責進站與出站驗證、OAuth、憑證管理、工具選擇、稽核與觀測。這顯示 MCP 真正進入企業環境之後，協定通常只是底層標準，周圍仍然需要一整套企業控制機制。
一套企業級的 MCP 架構因此通常需要處理：
- MCP Server 與 Tool 的發現與版本管理
- 使用者與 Agent 的身分識別
- Tool 層級的存取控制
- API Key、OAuth Token 等後端憑證管理
- 使用紀錄、錯誤、效能與稽核
- 敏感操作的人工作業核准
- 不同 MCP 版本與 Agent 平台的相容性
當這些能力被抽到共同平台之後，企業就不必把每一套安全與治理邏輯重新寫進每一個 Agent。這也是 Gateway 架構開始受到注意的原因：它不是為了增加一層技術，而是為了避免 Agent 直接與大量企業系統形成難以管理的點對點連線。
成熟的 MCP 架構具備哪些特質
MCP 目前仍然是一個快速演進中的協定，因此企業不應該把架構設計成「只要符合今天的 MCP 規格就完成了」。2026 年 7 月 28 日發布的新版本就是一個很好的例子：這次更新對核心傳輸方式進行大幅調整，引入無狀態核心、正式擴充機制、授權強化與新的生命週期規則。AWS 也特別指出，這是 MCP 推出以來幅度最大的版本變動之一。
因此，一套成熟的企業 MCP 架構應該具備以下六項特質：
- 協定與商業邏輯分離：企業核心 API 與商業規則不應完全依附 MCP，MCP Server 應該是企業能力的一種介面。
- 版本可管理：MCP 規格仍會演進，企業需要能同時管理不同版本、逐步升級，而不是每次協定變化就迫使所有 Agent 同時修改。
- 身分與權限外部化：Tool 能不能被使用，應由企業身分與授權機制決定，而不是只寫在 Tool 的文字描述中。
- 模型與平台中立：同一個企業 Tool 應盡可能能被不同 Agent Client 使用。OpenAI、Google、Amazon Web Services 與其他平台加入 MCP 生態系，正讓這種可替換性逐漸具備實際基礎。
- 完整可觀測性：企業應該可以知道哪一個使用者透過哪一個 Agent 呼叫了什麼 Tool，而不只是知道某個 API 收到了一次請求。
- Gateway 化治理：當 MCP Server 逐漸增加，企業需要集中進行安全、流量、版本與政策控制，避免 MCP 又發展成另一批難以管理的點對點整合。
這些條件也說明，真正值得企業投資的是「AI 可操作的企業能力」，而不是 MCP 三個字本身。即使五年後市場又出現新的 Agent 協定，只要企業已經整理好工具邊界、身分、權限與商業能力，新的協定只是換一層介面，不需要重新整理整間公司的系統。
相反地，如果公司只是快速把每一個 API 包成 MCP Server，卻沒有思考 Tool 的邊界、權限與治理，很容易把原本 API 時代的整合混亂原封不動搬到 Agent 時代。標準可以降低連線成本，卻不能自動替企業解決架構問題。
如何導入 MCP，而不是追逐 MCP
企業現在開始研究 MCP 時，最不需要做的事情，是為了「支援 MCP」而把所有企業系統重寫一次。比較合理的第一步，是盤點哪些企業能力最有可能被多個 Agent 重複使用。例如查詢客戶、建立工單、取得庫存、搜尋文件、建立採購草稿，都可能比某一個單次專案專用的功能更值得優先標準化。
第二步，是先從低風險、讀取型的 Tool 開始。讓 Agent 查詢公司知識與取得訂單資訊，和讓 Agent 正式退款、付款或刪除資料，風險完全不同。企業可以先建立 Agent 如何被識別、Tool 如何授權、操作如何留下紀錄，再逐步增加具有寫入能力的 Tool。
第三步，是避免讓每一個部門自行建立互不相容的 MCP Server。MCP 的價值原本就是減少重複整合；如果公司裡同一個客戶關係管理系統被不同團隊包成四套 MCP Server，最後仍然回到過去的問題。MCP Server 本身也應該被視為企業可重用的產品，有負責人、版本、文件與生命週期。
第四步，是提早建立 Gateway 或共同控制層。MCP Server 少的時候，Agent 直接連線看起來最簡單；當數量增加後，身分、OAuth、Tool 清單、流量限制與稽核很快就會分散。AWS 最新的 Gateway 架構，以及 Microsoft 自己把遠端 MCP Server 放到 Gateway 後方的實務，都顯示大型部署正在往集中控制發展。
最後，企業應該把 MCP 視為長期介面策略，而不是一次性的人工智慧專案。當新的 Agent 平台出現時，不必先問「要不要重新串一次企業資源規劃系統」，而是問「這個 Agent 能不能安全地使用公司已經提供的標準能力」。當這個問題可以穩定回答，企業才真正享受到開放協定的價值。
第三種企業介面正在快速成形
MCP 是否會成為十年後唯一的 Agent 工具標準，目前沒有人可以確定。協定仍在快速調整，而且 Agent-to-Agent 等其他標準也正在發展。但 MCP 已經從 Anthropic 的單一專案走到 Linux Foundation 的中立治理，並得到多家主要人工智慧與雲端供應商支援。2026 年新版規格甚至已經開始針對企業規模部署需要的無狀態架構、授權與擴充機制進行調整。
對企業而言，這代表現在不一定需要押注「MCP 一定會贏」，卻應該開始接受更大的趨勢：AI Agent 正逐漸成為企業系統正式的使用者。未來好的企業軟體除了讓人操作方便、讓程式整合容易之外，還必須能讓人工智慧理解其能力，而且在明確權限下安全執行。
過去我們為人設計畫面，為程式設計 API；接下來，企業還需要開始為 AI 設計工具介面。MCP 真正重要的地方，不只是多了一種連接方式，而是它讓企業第一次清楚看見：當人工智慧開始真正進入企業系統，軟體本身也必須開始學會如何與人工智慧合作。
