MCP（Model Context Protocol）如何讓 AI 自己讀取工廠壓力資料？

2024 年底，Anthropic 開源了一個叫做 Model Context Protocol（MCP）的標準，目的是解決一個工程師都懂的痛點：每接一個新的資料來源，AI 應用就要重寫一次串接程式碼。這個協議現在被拿來問一個很自然的問題——工廠裡的壓力、溫度數據，能不能透過 MCP 讓 AI 直接讀取？這篇文章會誠實拆解 MCP 的真實運作原理、它與傳統 API 串接的差異，以及要讓 AI「自己讀懂」工廠感測數據，實際上需要哪些環節到位——包含哪些部分是感測器製造商能提供的，哪些不是。

MCP 到底是什麼？先從官方定義講起

根據 Anthropic 官方於 2024 年 11 月 25 日發布的公告，Model Context Protocol 是一套開放標準，目的是讓開發者能在自己的資料來源與 AI 應用之間，建立安全的雙向連接。官方的架構描述很直接：開發者可以透過「MCP 伺服器」（MCP Server）將資料開放出來，或是建構能連接這些伺服器的「AI 應用程式」（MCP Client）。

官方文件用了一個很貼切的比喻：把 MCP 想像成 AI 應用的 USB-C 埠——就像 USB-C 提供了一種標準化的方式連接各種電子裝置，MCP 提供了一種標準化的方式，讓 AI 應用連接到各種外部系統，不需要為每一種資料來源重新寫一套客製化的串接程式碼。

MCP 的三個核心元件：Tools、Resources、Prompts

要理解 MCP 如何應用在工廠感測數據，需要先認識 MCP 伺服器能對外提供的三種核心元件——這是 MCP 規格中定義的標準化介面。

對工廠應用而言，最常被使用到的是前兩種——Tools 讓 AI 可以主動「查詢」目前的感測數值，Resources 讓 AI 可以「讀取」一段時間範圍的歷史數據，兩者結合起來，AI 就能同時掌握「現在的狀態」與「近期的趨勢」，這是做出合理判斷的基礎。

「AI 自己讀取工廠壓力資料」實際上長什麼樣子

回到題目本身的問題：MCP 要讓 AI「自己」讀取工廠壓力資料，中間仍然需要幾個環節到位，並不是把感測器插上電就自動發生的事。以下拆解完整的鏈路。

為什麼「感測層」仍然是整條鏈路無法跳過的起點

這裡呼應一個在其他資料整合情境中也成立的原則：MCP 解決的是「AI 怎麼連接到資料」的標準化問題，但它不會無中生有創造資料。如果最源頭的壓力錶是純機械式指針錶、沒有任何電訊號輸出，那麼不管 MCP 伺服器架構設計得多完善，都沒有數據可以提供給 AI 讀取。MCP 是這條鏈路中間到後段（③④⑤）的標準化橋樑，感測層（①）的數位化程度，決定了這座橋樑另一端有沒有東西可以連接。

用一個簡化的 MCP 伺服器示意，理解實際運作邏輯

以下是一個概念性示意，說明 MCP 伺服器如何把「查詢壓力數據」這個功能，包裝成 AI 可以呼叫的標準化工具——這不是可直接部署的完整程式，僅用於說明架構邏輯：

{
              "mcp_server": "factory-pressure-data",
              "tools": [
                {
                  "name": "get_current_pressure",
                  "description": "取得指定設備目前的即時壓力讀數",
                  "input_schema": {
                    "device_id": "string"
                  }
                },
                {
                  "name": "get_pressure_history",
                  "description": "取得指定設備過去N小時的壓力歷史數據",
                  "input_schema": {
                    "device_id": "string",
                    "hours": "number"
                  }
                }
              ],
              "resources": [
                {
                  "uri": "factory://devices/list",
                  "description": "工廠所有已註冊感測裝置的清單"
                }
              ]
            }

當 AI 應用（MCP Client）連接上這個伺服器後，它會知道自己可以呼叫 get_current_pressure 或 get_pressure_history 這兩個工具。當使用者問「設備A現在壓力正常嗎」，AI 可以自主決定呼叫 get_current_pressure 取得即時數值，並可能進一步呼叫 get_pressure_history 比對近期趨勢，綜合這兩項資訊生成回答——這就是「AI 自己讀取資料」的實際運作方式：不是 AI 憑空知道工廠狀況，而是它透過 MCP 定義的標準化工具，主動去查詢。

工業現場最在意的問題：MCP 的資安與權限控管機制

對工廠與製造業採購人員來說，「讓 AI 自己讀取資料」聽起來方便，但第一個浮現的疑慮通常是：這樣安全嗎？誰能決定 AI 可以讀取哪些資料？以下根據 MCP 官方規格說明其資安設計。

MCP 的授權機制建立在業界標準 OAuth 2.1 之上

根據 MCP 官方規格文件，MCP 在傳輸層提供授權能力，讓 MCP 客戶端能夠代表資源擁有者向受保護的 MCP 伺服器發出請求。具體而言，MCP 客戶端扮演 OAuth 2.1 客戶端的角色，受保護的 MCP 伺服器則扮演 OAuth 2.1 資源伺服器的角色——這是網頁服務業界行之有年的標準授權框架，而非 MCP 自創的專屬機制，意味著企業 IT 或資安團隊如果已熟悉 OAuth 2.1，可以用既有的知識框架來評估 MCP 部署的安全性。

授權在 MCP 規格中是「選用」的，但生產環境強烈建議啟用

值得注意的是，官方規格明確指出授權機制在 MCP 實作中是選用（OPTIONAL）的，這在本機開發、測試階段或許可以接受，但業界資安從業者的共識非常明確：一個沒有身分驗證機制的 MCP 伺服器，等於是網路上任何人都能呼叫的伺服器，這對於本機開發測試或許無妨，但對於任何會接觸真實工廠營運數據的正式環境，都是不可接受的風險。規劃導入時，務必將授權機制列為正式上線的必要條件，而非選配項目。

企業級部署：集中式權限管理已成為業界擴充方向

隨著 MCP 在企業環境的採用增加，社群也發展出因應企業規模的擴充機制——例如讓組織能透過既有的身分識別提供者（Identity Provider），集中管理員工對多個 MCP 伺服器的存取權限，避免每個員工都要對每一個 MCP 伺服器個別完成一次授權流程的繁瑣情境。這類擴充機制正在被主要 AI 廠商與企業身分管理服務商採納，顯示 MCP 生態系正在往符合企業資安治理需求的方向發展，而非停留在單機、個人使用的層次。

MCP vs. 傳統 Function Calling：該選哪一種？

對於已經接觸過 AI 應用開發的技術人員，可能會想到一個問題：在 MCP 出現之前，AI 模型本來就有「Function Calling（函式呼叫）」機制可以呼叫外部功能，兩者的差異是什麼？以下整理幾個關鍵差異點，協助評估專案該採用哪一種方式。

簡單來說，Function Calling 更像是「這個 AI 應用專屬的客製化功能」，而 MCP 更像是「任何 AI 應用都能使用的標準化服務」。如果貴公司只需要串接一套內部系統、給單一 AI 應用使用，Function Calling 可能已經足夠，開發也相對單純；但如果預期未來會有多個 AI 應用（例如不同部門使用不同的 AI 工具）都需要讀取同一份工廠數據，或是需要串接多個不同的資料來源做整合分析，MCP 標準化的架構能減少重複開發的成本，長期維護也更有彈性。

導入前的現實檢查：哪些工廠適合現在評估 MCP

檢查一：現場數據是否已經數位化、集中化？

MCP 伺服器包裝的是「已經存在的資料來源」，如果工廠的壓力、溫度數據目前分散在各台設備的機械錶盤上，還沒有集中到資料庫或雲端服務，第一步應該是先完成數位化與資料匯集（前文表格的①②層），而不是直接跳到討論 MCP 伺服器架構。

檢查二：是否有明確的 AI 應用場景，而非為了 MCP 而 MCP

MCP 是一套整合協議，本身不會產生商業價值，價值來自於它連接的 AI 應用實際解決了什麼問題——是讓值班工程師能用自然語言查詢設備狀態？還是讓 AI 定期彙整多點位數據生成日報？建議先明確定義具體的使用情境，再評估 MCP 架構是否是達成該情境最合適的技術路徑。

檢查三：內部是否有能力開發與維護 MCP 伺服器？

建置 MCP 伺服器需要一定的軟體開發能力，雖然官方資料指出主流 AI 模型已具備快速產生 MCP 伺服器程式碼的能力，降低了開發門檻，但上線後的維護、資安權限控管、與既有系統的整合測試，仍需要內部技術團隊或穩定的外部合作夥伴支援。

從試點專案開始：一個務實的評估路徑

如果貴公司評估後認為現階段適合嘗試 MCP 架構，比起一開始就規劃全廠導入，更務實的做法是從小規模試點開始，逐步驗證可行性。以下是一個常見的階段性路徑，供規劃參考。

第一階段：選定單一、低風險的試點場域

建議挑選一個數據已經數位化、且業務重要性適中（不是最關鍵但也非無關緊要）的監測點位作為起點，例如某一條產線的溫度監測，而非直接從最核心、風險最高的製程開始。這個階段的目標是驗證「感測數據 → MCP 伺服器 → AI 查詢」這條鏈路技術上是否走得通，而非追求立即的營運效益。

第二階段：定義最小可行的 Tools 與 Resources

不需要一開始就把所有可能用到的查詢功能都包裝進 MCP 伺服器，建議先定義最核心的 1 到 3 個工具（例如「查詢即時數值」「查詢近期歷史趨勢」），確認 AI 應用能正確呼叫並取得預期結果後，再逐步擴充其他功能，例如跨點位比對、異常標記等。

第三階段：邀請實際使用者參與驗證

技術上能運作，不代表現場人員會願意使用。建議在試點階段就邀請實際會用到這套系統的工程師或值班人員參與測試，蒐集他們對於「AI 回答是否準確」「查詢方式是否符合工作習慣」的回饋，這些真實使用回饋往往比技術指標更能決定專案最終能否被現場採用。

第四階段：評估擴大規模的資源需求

試點驗證可行後，擴大到更多點位或更多資料來源，涉及的不只是技術複製，還包括資安權限管理是否能隨規模擴大、維運人力是否足以支撐更多伺服器與工具、以及是否需要更完善的監控機制掌握 AI 查詢的使用狀況與異常。建議在試點階段就同步評估這些擴大規模時會遇到的資源需求，避免試點成功後才發現擴大規模的成本遠超預期。

各產業可能的應用情境

以下情境說明 MCP 架構在不同產業的可能應用邏輯，用於說明系統設計思路，並非特定客戶實績。

常見問題 FAQ

延伸閱讀

本文 MCP 技術定義與架構說明引用 Anthropic 官方公告（2024年11月25日發布，https://www.anthropic.com/news/model-context-protocol）及 Model Context Protocol 官方文件（https://modelcontextprotocol.io）之公開內容。程式碼示意為說明架構邏輯之概念性範例，非可直接部署之完整程式。產業應用情境為說明系統設計邏輯，非特定客戶實績或效益保證。ATLANTIS 昶特有限公司為壓力、溫度感測器製造商，不提供 MCP 伺服器開發、AI 應用整合服務，文中 MCP、Claude、Anthropic 相關名稱與標準之權利均屬 Anthropic PBC 所有。文中商品圖片位置標示為待補，請於發布前至官方商品目錄確認並替換為正確圖片網址。