工業AI Agent 企業自建AI Agent，真正難的是AI還是設備？

When an AI Agent Connects to Factory Equipment, Who Gets to Decide?

內容目錄

AI Agent 分析完設備資料後，提出一個建議：「設備可能發生異常，建議立即停機檢查。」

現場的人看著畫面，問了一句：「它真的可以讓設備停下來嗎？」

這句話把問題從技術拉回了現實。

AI 能不能讀取設備資料？能不能連上系統？能不能透過 API 呼叫工具？這些當然都重要，也需要工程團隊花時間處理。但接下來那一步，才是企業真正要面對的問題：AI 的建議要不要變成設備指令？

如果 AI 說可能有異常，設備就真的停下來，誰授權的？如果它判斷錯了，停機造成的損失算誰的？如果它判斷沒錯，現場卻認為現在不能停，最後又該聽誰的？

這些問題不會因為 Agent 成功串上 PLC，就自動有答案。

一套工業AI Agent，可能長這樣：

每一層都可能負責不同工作。AI 或大型語言模型分析資訊、整理狀態；Agent 根據任務安排步驟，再呼叫可用工具；API 或 Tool 提供系統操作介面；Edge Computer 在廠內處理資料或執行部分邏輯；PLC 負責設備控制，MES 則管理生產資訊和流程。

架構畫得出來，連線也可能做得起來。真正需要小心的是，資料和指令走過這些系統後，最後會不會改變設備狀態。

讓 Agent 讀取設備資料，是一種權限。讓它提出停機建議，是另一種權限。讓它不經人員確認，直接送出停機指令，又是完全不同的權限。

但專案討論時，這幾件事常被一句「讓 AI 監控設備，異常時自動處理」包在一起。聽起來效率很高，實際上卻可能把資料分析、異常判斷、現場決策和設備控制混成同一件事。

「串得上」只能證明系統能傳遞資料或指令，不能證明 Agent 適合擁有這個控制權。

AI Agent 可能根據溫度、振動、電流或警報紀錄，判斷設備狀態有異常。可是現場是否應該立即停機，往往還要看其他條件。

設備現在正在處理哪一批產品？這個製程能不能中斷？工件能否安全退出？停機會不會造成整批產品報廢？其他設備是否可以接手？維修人員能不能立刻到場？停機後的重啟程序要多久？

這些資訊有些存在系統裡，有些在現場人員的經驗中，有些可能根本沒有被即時記錄。AI 看到的是它取得的資料，不等於它掌握了現場完整狀況。

即使設備數據真的顯示異常，停機也不一定是唯一選項。現場可能需要先降低速度、加強監測、通知維修人員，或等產品完成目前工序再處理。不同做法的風險和代價不一樣，不能只靠一句「建議立即停機」帶過。

這就是設備衝突的核心：模型看到一種風險，現場同時還要處理另一組風險。AI 可以提出訊號，卻不一定知道哪一種風險在當下更重要。

辦公室裡，AI 摘要寫錯，使用者可能看出來後改掉。但當 Agent 能影響設備，錯誤可能直接變成生產事件。

它把正常的製程變化判成異常，設備停了，產線跟著中斷；它漏掉真正的異常，設備繼續運轉，品質或設備安全受到影響；它發出重複警示，現場開始把警告當成背景噪音；它呼叫了不適合當下情境的工具，讓原本能控制的問題變得更複雜。

這些結果很難只用「模型準確率」回答。

準確率再高，也要知道測試資料涵蓋哪些設備、產品和操作條件。系統沒有資料、資料延遲，或設備通訊中斷時，會怎麼處理？模型不確定時，是停止提出建議、要求人工確認，還是硬給一個答案？Agent 呼叫工具失敗後，會不會重試到造成另一種風險？

一套系統是否適合接觸設備，要看它能不能在錯誤、未知和異常狀況下維持可控，不只是正常運作時看起來多聰明。