從壓力錶到 AI Agent：AWS IoT 如何打造下一代智慧工廠？

「AI Agent」這個詞這兩年被談得很熱，但對工廠來說，它到底是什麼？是不是又是一個聽起來很潮、實際上跟現場毫無關係的行銷詞彙？這篇文章要拆解一件事：AI Agent 不是憑空出現的黑魔法，它的判斷力來自底層感測數據的品質。從一顆壓力錶開始，經過 AWS IoT 的資料匯集，最終才能讓 AI Agent 做出「值得信任」的自主決策。我們會誠實說明這條路徑上，感測器製造商能提供什麼、雲端與 AI 平台商該提供什麼，避免各位工程與採購人員被過度包裝的說法誤導。

先講清楚：AI Agent 到底是什麼，跟傳統自動化差在哪

在深入架構之前，有必要先釐清一個常被混用的概念。工廠自動化領域長期以來就有「自動控制」——PLC 讀取感測器數值、依照預設邏輯（例如壓力超過某個值就跳警報或關閉閥門）執行動作，這件事已經存在數十年，不是新東西。

AI Agent（AI 代理）指的是更進一步的系統形態：它不只是執行預先寫死的 if-then 規則，而是具備一定程度的「推理」與「規劃」能力——能根據當下情境、歷史數據與多個資料來源，自主判斷「現在該做什麼」，並且能連續執行多個步驟的任務，而不只是觸發單一動作。例如，傳統自動化系統偵測到壓力異常會觸發一個固定的警報；而 AI Agent 架構下的系統，理論上可以綜合壓力、溫度、歷史維修紀錄與生產排程等多方資訊，判斷這次異常是否需要立即停機、可以延後到排程保養、還是只是感測器本身需要校正，並自主生成後續處理建議或直接執行預先授權範圍內的動作。

為什麼「AI Agent 打造智慧工廠」不能跳過感測層直接談

近年討論智慧工廠、AI Agent 的文章，很多是從雲端與軟體視角出發——模型怎麼訓練、代理框架怎麼設計、多代理協作怎麼運作。這些內容很重要，但有一個常被忽略的前提：AI Agent 的判斷力，完全建立在它接收到的數據之上。如果最源頭的感測數據本身不準、反應遲鈍、或者根本沒有數位化輸出可以被收集，再精密的 AI 決策邏輯也只是在錯誤的資訊上做出看似合理、實則錯誤的判斷——這在機器學習領域有個常見說法：垃圾進，垃圾出（garbage in, garbage out）。

換句話說，工廠要導入 AI Agent，不能只看軟體層，必須從感測層開始盤點：現場的壓力錶、溫度計是否具備數位化輸出？訊號更新頻率夠不夠支撐即時決策？精度是否足夠讓 AI 判斷「這是真的異常」還是「只是正常誤差範圍內的波動」？這些問題如果沒有先解決，AI Agent 專案很容易在資料品質這一關就卡住，甚至做出誤導管理層的錯誤建議。

SDPT-3100 智能型壓力傳送器：HART 協議通訊，具環境溫度自動補償——這類具備數位化輸出的感測器，是 AI Agent 決策鏈路最源頭的資料來源

完整鏈路拆解：從感測器到 AI Agent 自主決策

把「壓力溫度監測 + AWS IoT + AI Agent」拆成五個層級來看，能更清楚每一層該由誰負責、彼此如何銜接。

這張表最重要的訊息是：第①層是唯一不可替代的物理環節。第②到第⑤層雖然各自有其技術門檻，但本質上是資料處理與運算——只要資料存在，這些層級可以用不同廠商、不同工具重新組合。但第①層如果沒有可靠的感測器把真實世界的物理量轉換成數位訊號，後面四層完全無法運作，因為根本沒有數據可以處理。

第④、⑤層目前的技術現況（誠實說明）

值得說明的是，「AI Agent」在工業現場的實際落地，目前多數仍處於試點（pilot）與早期導入階段，尤其是具備「自主執行動作」能力的代理層。多數已上線的工廠應用，實際上是「推論層」（第④層）較為成熟——也就是用機器學習模型做異常偵測、趨勢預測，並將結果以警報或建議的形式呈現給人員決策，而非讓 AI 完全自主執行高風險的實體動作（如自動關閉閥門、停止產線）。這是合理且穩健的現況：工業現場的任何自主動作都牽涉安全風險，AI Agent 在能被賦予更高自主權之前，需要透過大量真實案例證明其判斷可靠度。

感測層怎麼選？AI Agent 需要什麼樣的數據品質

如果貴公司正在規劃導入 AI Agent 架構，以下是感測層選型時，特別需要注意的幾個面向。

1. 數位化輸出：AI 完全無法處理類比指針讀數

這是最基本卻常被忽略的前提。純機械式壓力錶沒有電訊號輸出，AI 系統完全無法讀取其數值，除非額外加裝影像辨識設備讀取錶盤（增加成本與誤差來源）。要串接 AI Agent 架構，感測器必須具備 HART、4-20mA、RS485 Modbus 或藍芽等數位化輸出。

STT HART智能型溫度傳送器：通用型一體化設計，支援遠端組態與診斷，數位化輸出可直接供上層系統擷取數據

2. 數據更新頻率：AI Agent 的「即時性」取決於感測層

AI Agent 若要做到「即時」判斷與建議，前提是它接收到的數據本身夠新。如果感測器或閘道器的上傳頻率是每小時一次，AI Agent 再怎麼精密，也只能做到每小時更新一次的決策，無法做到真正的即時反應。規劃時需要依照應用場景的風險等級，決定感測層的數據更新頻率需求。

3. 精度與穩定性：避免 AI 把雜訊當異常

感測器精度不足或訊號漂移，容易讓 AI 模型把正常的量測誤差誤判為異常，產生大量誤報，長期下來會讓現場人員對 AI 建議失去信任（這在機器學習領域稱為 alert fatigue，警報疲勞）。選用精度穩定、具備溫度補償等機制的智能傳送器，能降低這類誤判的機率。

LTPT-410RS系列 溫度液位傳送器：同時測量溫度與液位，適合需要多變量輸入的 AI 決策場景，如冷鏈或儲槽監控

4. 多變量整合：AI 決策通常需要不只一種數據

AI Agent 若要做出接近人類工程師的判斷，通常需要同時考量多種變量，而非單一數值。例如判斷冷凍系統是否異常，同時需要溫度、壓力甚至液位數據交叉比對，才能提高判斷的可靠度。這也是為什麼複合式傳送器（同時測量溫度與壓力/液位）在 AI Agent 架構下，比單一變量感測器更有整合價值。

AWS 上的 AI Agent 參考架構：一般業界做法

以下說明業界常見的 AWS 服務組合方式，協助工程與採購人員理解一般的技術路徑，供規劃專案時參考。

這套架構的關鍵設計理念是：AI Agent 不是取代人類工程師，而是把工程師從「持續盯著儀表板」的重複性工作中解放出來，改為在 AI 篩選過、標註優先級的資訊上做最終判斷。特別是在工業現場，涉及安全與高成本設備的最終決策，目前業界普遍的穩健做法仍是「AI 建議、人類確認」（human-in-the-loop），而非完全無人監督的自主執行，這也是多數企業導入 AI Agent 時採取的漸進式路徑。

Bedrock Agents 概念示意：工具調用如何運作

以下是一個概念性示意，說明 AI Agent 框架如何透過「工具調用」（Function Calling）機制，讀取感測數據並生成建議——這不是可直接部署的完整程式，僅用於說明運作邏輯：

{
                          "agent_task": "評估冷凍庫溫度異常是否需要立即處理",
                          "available_tools": [
                            {
                              "name": "get_sensor_reading",
                              "description": "讀取指定感測器最近N小時的歷史數據"
                            },
                            {
                              "name": "get_maintenance_history",
                              "description": "查詢該設備過去的維修紀錄"
                            },
                            {
                              "name": "check_production_schedule",
                              "description": "查詢是否為排程停機時段"
                            }
                          ],
                          "agent_reasoning_steps": [
                            "1. 呼叫 get_sensor_reading 取得溫度趨勢，判斷是瞬間波動還是持續上升",
                            "2. 呼叫 get_maintenance_history 確認是否為已知的設備老化問題",
                            "3. 呼叫 check_production_schedule 確認當下是否適合安排維修",
                            "4. 綜合三項資訊生成建議：立即處理 / 排程處理 / 持續觀察"
                          ]
                        }

各產業應用情境：AI Agent 架構如何對應實際需求

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

導入前的三個現實問題

問題一：貴公司的感測層準備好了嗎？

在討論任何 AI Agent 框架選型之前，先盤點現場有多少比例的儀表已具備數位化輸出。如果多數儀表仍是純機械式指針錶，第一步應該是感測層升級，而不是急著導入 AI 軟體——沒有數據來源，再好的 AI 架構都無用武之地。

問題二：需要的是「自主執行」還是「輔助建議」？

如前文所述，工業現場涉及安全與高成本的自主動作，目前業界普遍仍採取人機協作模式。規劃專案時，建議先從「AI 輔助建議、人類最終確認」的模式開始導入，累積足夠的信任基礎與真實案例後，再評估是否擴大 AI 的自主執行範圍，而非一開始就期待全自動化。

問題三：內部是否有能力維運 AI Agent 系統？

AI Agent 系統上線後需要持續監控其判斷品質、調校模型、處理邊界案例，這需要一定的內部技術能力或穩定的外部合作夥伴支援，不是建置完成就一勞永逸的專案。建議在導入前，先確認後續維運的人力與預算規劃。

人機協作的漸進式分級：多數工廠現在走到哪一階段

「AI Agent 自主決策」聽起來是全有或全無的兩極選項，但實務上業界普遍採取的是漸進式分級路徑。理解這個分級，有助於工程與管理團隊評估貴公司現階段適合走到哪一步，而不是被「全自動化」或「完全不用」的二分思維綁住。

多數已經導入 AI 技術的工廠，目前落在第二級到第三級之間——AI 負責篩選與初步分析，人員負責最終判斷。這不代表 AI Agent 技術「還不成熟」，而是工業現場對安全與可靠度的要求，本來就需要透過分級授權、逐步驗證的方式建立信任，而非一步到位。規劃專案時，建議明確定義貴公司現階段要走到哪一級，並設定好晉級到下一級所需的驗證標準（例如連續多少次判斷正確率達到多少），而不是含糊地說「要導入 AI Agent」卻沒有具體的階段目標。

自建 vs. 委外：AI Agent 這一層該怎麼規劃

感測層之外，AI Agent 與雲端架構這一層，企業常見有三種規劃模式，各有不同的適用情境。

無論選擇哪一種模式，有一個原則是共通的：感測層的選型與驗收，應該由企業自己或熟悉工業儀表的顧問把關，不要完全交給不熟悉工業現場的軟體或 AI 廠商決定。這是因為 AI/軟體背景的團隊，通常更熟悉資料處理與模型層面的工作，但不一定了解 HART 協議、防爆認證、介質相容性這類工業儀表領域的專業眉角，如果感測層規格沒選對，後續整條鏈路的投資都可能建立在不穩固的基礎上。

導入前的三個現實問題

問題一：貴公司的感測層準備好了嗎？

在討論任何 AI Agent 框架選型之前，先盤點現場有多少比例的儀表已具備數位化輸出。如果多數儀表仍是純機械式指針錶，第一步應該是感測層升級，而不是急著導入 AI 軟體——沒有數據來源，再好的 AI 架構都無用武之地。

問題二：需要的是「自主執行」還是「輔助建議」？

如前文所述，工業現場涉及安全與高成本的自主動作，目前業界普遍仍採取人機協作模式。規劃專案時，建議先從「AI 輔助建議、人類最終確認」的模式開始導入，累積足夠的信任基礎與真實案例後，再評估是否擴大 AI 的自主執行範圍，而非一開始就期待全自動化。

問題三：內部是否有能力維運 AI Agent 系統？

AI Agent 系統上線後需要持續監控其判斷品質、調校模型、處理邊界案例，這需要一定的內部技術能力或穩定的外部合作夥伴支援，不是建置完成就一勞永逸的專案。建議在導入前，先確認後續維運的人力與預算規劃。

常見問題 FAQ

延伸閱讀

本文技術架構說明參考 AWS 官方文件公開資訊（IoT Core、SageMaker、Bedrock）之通用工作原理，AI Agent 相關概念參考業界公開技術文獻對代理式 AI（Agentic AI）架構的一般性描述。文中程式碼與訊息格式為說明架構邏輯的示意範例，非可直接部署之完整解決方案。產業應用情境為說明系統設計邏輯，非特定客戶實績或效益保證。ATLANTIS 昶特有限公司為壓力、溫度感測器製造商，不提供 AI Agent 軟體、AI 決策平台、AWS 官方認證服務或代管雲端服務，文中 AWS 相關服務商標權利均屬 Amazon 所有。