讓機台會「自己求救」：用 Little Agent × RAG × Teams 把工廠 trouble shooting 自動化

最近我把「Little Agent」（我的小型 AI Agent 架構，從 OpenClaw 縮減而來）導入幾個機台的健康監控，目標：讓設備主動找對的人，而不是再讓人去找問題。

這篇記錄我的架構、踩過的三個坑、目前看到的效益，以及接下來想做的事。

為什麼不是「再買一套監控系統」？

工廠不缺監控。缺的是「監控之後該做什麼」的判斷層。

傳統的 SCADA 或 OEE 系統可以告訴你「這台機停了」，但回答不了三個關鍵問題：

這個 alarm 是真的故障，還是已知會自動恢復的雜訊？
該叫工程師、組長，還是先查 SOP 自己試？
上次類似情況怎麼處理的？花了多久？

這三題都是「判斷與經驗」題，以前只能靠老師傅。問題是老師傅不上夜班，也不可能 24/7 待命。

Little Agent 的五層架構

我把整套任務拆成五個獨立、可替換的層，每一層只做一件事：

[ 監控層 ] → [ 判斷層 ] → [ 知識層 ] → [ 通知層 ] → [ 動作層 ]
   ↓            ↓            ↓            ↓            ↓
  poll        Agent +      RAG over     Teams       自動修復
 sensor       LLM 分類      SOP/Ticket   Webhook     OR 標記給人

1. 監控層（Sensing）

每 30 秒讀機台 status，走 OPC-UA 或自家 API。把訊號標準化（單位、時間戳）後丟進 message queue（我用 Redis Streams，輕量好擴）。

2. 判斷層（Reasoning）

Agent 拿到 alarm 後先用規則篩（已知雜訊、暫態波動忽略），再交給 LLM 分類成三種：「已知/可自動處理」、「已知/需 SOP」、「未知/須升級」。

3. 知識層（RAG）

把過去 3 年的 ticket 紀錄、SOP、設備手冊全部 chunked 進 vector DB。Agent 帶著當下狀態去問：「類似情況歷史上怎麼解的？」回來的不只是文字，還包含過去的處置時間、成功率。

4. 通知層（Action Channel）

用 Teams Incoming Webhook 推訊息到對應群組，內容包含：故障摘要、RAG 推薦處置、可一鍵執行的按鈕、@提及對應班長。重點是把「該找誰」這個判斷做掉，值班人員只要按按鈕。

5. 動作層（Execution）

能自動的就自動（重啟某個 service、清 buffer、切備援），不能自動的就「半自動」——產生工單給工程師，附上 RAG 推薦的 SOP 和歷史紀錄。

我踩過的三個坑

坑 1：LLM 不該直接做關鍵決策

最早版本我讓 Agent 判斷「要不要重啟整台機」。第一週就被打臉——LLM 偶爾把「降載警告」當成「需要重啟」，差點停掉一條 ramping 中的產線。

修正方式：用 confidence score + 動作風險分級。低風險（清快取、記 log、寄信通知）Agent 可自決；高風險（重啟、停機、切換 recipe）只能「建議 + 一鍵執行按鈕」，最後決定權在人。

坑 2：RAG 的天花板是 SOP 寫得多清楚

RAG 不會魔術。如果你的 SOP 寫的是「請聯絡相關人員」，LLM 也只會照唸一次「請聯絡相關人員」。

修正方式：做 RAG 之前，先花一週把 Top 20 高頻故障的 SOP 改寫成「步驟條列 + 條件判斷 + 截圖 + 預期回饋」格式。SOP 改寫的 ROI 比換更貴的 LLM 模型大十倍。

坑 3：假警報比想像中多很多

Polling 頻率太高、感測器雜訊、暫態波動——只看單點容易誤判。前兩週 Agent 一晚通知 30 次，最後人都選擇靜音。

修正方式：用滑動視窗 + 多點交叉驗證（三個感測器有兩個跨閾值才觸發），再交給 Agent 判斷。寧可漏報 5%，也不要每晚誤報 30 次讓人對系統失去信心。

目前看到的效益

上線約六週，初步數據：

MTTR（平均修復時間）：從 ~30 分鐘降到 ~10–15 分鐘
夜班升級資深工程師次數：下降約 40%
誤報率：從每晚 30+ 降到每晚 3–5

但更難量化、也更有感的是：夜班人員的心理負擔變輕了。原本「我該打給誰、會不會被罵」變成「Agent 已經告訴我下一步、按下按鈕就好」。這個價值我覺得比 MTTR 數字還重要——它讓夜班的人睡得比較好，留任率也會跟著上來。

接下來想做的

把 Agent 推到邊緣裝置（接續上一篇 OpenClaw 搬到 Jetson Orin Nano 的經驗），減少對雲端依賴
加入「自學」回饋迴路：工程師最後實際處置的方法回寫進 RAG，讓系統越用越準
建立 escalation matrix 自動化：不同時段、不同設備、不同故障級別自動找對的人，而不是固定群組大撒網
把同樣架構移植到家裡（家庭自動化系統的告警、家電維護、租屋管理 alarm）——畢竟家也是一台需要 uptime 的「機台」

讓設備找對的人，不要再讓人去找問題。

這句話是這個專案的核心。它聽起來像 slogan，實際做下來是把「判斷成本」從人轉移到系統的工程任務——而這正是我認為這個時代最值得做的「自動化」之一。

如果你也在工廠、IT、設備管理、甚至是家庭 IoT 場景遇到類似的痛點，歡迎留言或來信聊。也歡迎訂閱電子報，我會持續分享 Little Agent 的後續迭代與架構細節。

Rishen Lu