最近看製造業邊緣運算和 AI 執行層的產品方向，我腦中一直浮出同一個問題：如果工廠和雲端短暫失聯，現場到底還能不能正常跑？
這問題不華麗，但很現實。因為很多系統簡報裡的箭頭都畫得很順，設備資料往上拋、雲端分析、AI 訓練、企業端下指令，看起來像一條乾淨的高速公路。可是真正的工廠現場，不會因為網路、雲端服務或某個 API 暫時不穩，就乖乖按暫停鍵等工程師修好。
我越來越覺得，未來 MES、SCADA、Edge Gateway 這些靠近現場的系統，不能再只被看成「資料水管」。它們不只是把設備訊號轉成資料，再送到雲端給報表和 AI 使用。當 AI 開始進入工廠營運，現場執行層本身就會變成架構核心：它要知道哪些規則必須即時執行，哪些判斷可以延後，哪些狀態必須在斷線時保留下來，哪些動作一定要等人確認。
過去談 IT/OT 整合，很容易把重點放在資料收集。先把 PLC、感測器、工單、報工、品檢、庫存都接起來，讓管理端看得到現場。這是必要基礎，但如果只做到這裡，系統仍然偏向「觀測」。真正困難的是「執行」：當某個異常發生時，誰負責分類？誰決定要不要停線？系統要不要先暫停下一站？如果雲端模型暫時無法回應，本地端是否還有最低限度的保護規則？
這也是我看邊緣執行層時會特別在意的地方。Edge 不只是把資料放近一點、讓延遲低一點；它更像是在現場放一個有紀律的小腦。這個小腦不一定要很聰明，不一定要跑最大模型，但它要可靠。它要能在網路不穩時繼續套用基本規則，在資料回補時做對帳，在系統恢復後把現場發生過的事情完整交代清楚。
企業系統最怕的不是單純失敗，而是失敗後不知道發生什麼事。假設某段時間雲端連不上，如果現場仍然持續生產，後面一定會碰到幾個問題：哪些工單狀態是在離線期間變更的？哪些設備告警有被處理？哪些 AI 建議沒有送達？哪些人工決策需要回寫？如果這些沒有設計好，恢復連線那一刻不是結束，而是另一場資料災難的開始。
所以我會把現場執行層分成幾個責任來看。
第一是本地規則。不是所有 business logic 都應該留在雲端。像安全停機、品質隔離、關鍵告警、最低庫存限制、工單狀態轉換這類規則，如果它們影響現場即時運作，就應該有本地可執行的版本。雲端可以負責更大的最佳化與分析，但不能成為現場能不能呼吸的單點依賴。
第二是狀態日誌。現場系統不能只記最後結果，還要記過程。哪個時間點收到什麼訊號、套用了哪個版本的規則、誰做了人工覆核、哪些動作因離線而排隊，這些都應該被記錄下來。沒有這些，事後很難判斷問題到底是模型誤判、資料延遲、規則過期，還是人機交接沒有做好。
第三是回復策略。離線不是例外，而是架構必須假設會發生的狀態。系統要先定義好哪些操作可以暫存、哪些必須拒絕、哪些需要標記成待確認。恢復連線後，也不能只是粗暴地把資料全部同步上去，而要做衝突處理、版本檢查、責任歸屬和必要的人工審核。
第四是 AI 的降級模式。AI Agent 在工廠裡不應該只有「全功能」和「完全不能用」兩種狀態。比較合理的是分級：雲端可用時，它可以做跨系統分析；雲端不穩時，它退回本地規則和最近一次可用模型；資料不足時，它只能提醒與收集脈絡，不做建議；風險過高時，它必須停下來交給人。
從技術主管角度，我會覺得這些設計比 demo 裡的對話能力更重要。因為現場信任不是靠一次漂亮展示建立的，而是靠系統在不完美環境裡仍然可預期。工廠的人不會因為 AI 很會回答問題就放心把流程交出去；他們會看這套東西出錯時是不是說得清楚、斷線時是不是有保護、恢復時是不是不會亂帳。
這也是為什麼我不太喜歡把 Edge Gateway 講成單純的資料匯流排。那會低估它未來的角色。當企業 AI 往現場落地，靠近設備和人員的那一層，會越來越像「現場作業系統」：它承接資料、規則、權限、狀態、AI 推論和人工介入。它不一定最炫，但它決定整個系統能不能真的上線。
智慧工廠的核心，不只是把現場資料送到更聰明的雲端，而是讓現場在各種不完美條件下，仍然能安全、可追溯、可恢復地執行。資料水管只能讓你看見工廠；現場執行層，才是讓工廠在 AI 時代繼續穩定運轉的地方。