螢幕監控 Agent 得先學會安全地看錯
最近看到 r/LocalLLaMA 有人分享 Observer v3.0.0，讓 local LLM 盯著螢幕，在模擬崩潰、票券出現、下載完成、CI 等待批准時通知或觸發動作。桌面版用 llama.cpp，Web 版用 transformers.js，也能接 OpenAI-compatible endpoint。貼文大約拿了 20 票。
我沒有實際跑過 Observer，所以不評論它現在的準確率。不過做過幾年 backend 後，我看到這種產品，第一個問題永遠是：它判錯之後，系統能不能回到可預期的狀態。讓模型拿到 screenshot 只是輸入管線，真正麻煩的是事件判定。
例如下載完成。畫面可能先出現 100%，接著瀏覽器還在寫檔，按鈕也可能暫時變成可以點擊。模型若看到一次 100% 就觸發後續動作，遇到網路抖動就會提早通知。比較實際的規則是連續 5 次判定為完成，且間隔 2 秒，才把狀態從 DOWNLOADING 改成 COMPLETED。這會多等 10 秒，卻少掉一堆假完成。
我會先把畫面事件收斂成明確的 state machine，讓 LLM 每次只負責產生 observation：
UNKNOWN -> CANDIDATE -> CONFIRMED -> ACTIONED
-> EXPIRED
CANDIDATE 要經過 debounce，例如 3 秒內至少 2 次相同結果。CONFIRMED 之後還要有 idempotency key，避免模型重複看到同一個票券就發兩次通知。這些東西很無聊，但 production 出事時，靠的就是這些無聊東西。
誤報和漏報也要分開計算。我會拿 100 次畫面判定做測試，記錄 false positive、false negative 和平均反應時間。假設誤報 8 次、漏報 3 次，表面上 89% 準確率不差，若「模擬崩潰」的誤報會自動重啟服務，8 次可能直接把機器打到雪崩。不同事件必須有不同門檻，CI 等待批准可以多等 30 秒，付款頁面出現錯誤則需要人工確認。
重試策略也不能交給模型決定。通知失敗可以 exponential backoff，最多 3 次，並寫入 durable queue。動作失敗要看能不能安全重試，像按一次「批准」這類不可逆操作，我寧願停在 CONFIRMED，留下截圖和 log，等人接手。
所以我評估這類 micro-agent 的順序會是：先看事件定義，再看狀態能否恢復，接著看 log、去重和人工接管，最後才看模型跑在 llama.cpp 還是 transformers.js。模型看得到螢幕只是 demo 的起點。production 能不能跑，取決於它看錯時會不會把錯誤控制在小範圍內。
作者：鍵盤工人