能跑起來只是開始。維運責任落在使用者身上，才是 AI agent 難以主流化的根本問題。
Reddit 上有一篇在問 OpenClaw 為什麼還沒主流化，提到的原因包括 setup friction、reliability、security、value clarity，大方向是對的，但我覺得這些討論都停在比較表面的地方。
補充一下我自己從 SRE 角度觀察到的狀況，可能和一般使用者的感受有些不一樣。
安裝其實不是主要障礙
老實說，OpenClaw 的安裝流程對有一點基礎的人而言並不算難。我第一次裝大概花了 40 分鐘，主要時間在設定 API key 和調整 config，核心功能跑起來沒什麼障礙。
但能跑起來跟穩定能用之間，差的不是安裝步驟，是維運心態。這個差距，很多教學文章完全沒有提到。
六種失敗模式，我整理過清單
我自己用 AI agent 一段時間後，整理過一份失敗類型清單，大概分成這幾類：
- Context 超限，agent 在長對話後開始「忘事」，輸出開始漂移
- 工具呼叫失敗，沒有 fallback，agent 卡住或繞圈跑
- 外部 API 連線中斷，沒有 retry 機制，整條 pipeline 直接停掉
- 輸出格式不一致，後端 parser 爆掉，但 agent 本身看起來還在跑
- Prompt regression，改了 prompt 之後行為悄悄改變，沒人發現
- 循環呼叫，某些條件下進入無限 loop，吃光 token 才停
六種，不是邊緣案例，是我實際跑過之後整理出來的常見失敗點。要注意的是，其中有幾種屬於「看起來還在跑，但其實已經出問題」的類型，最難偵測，也最難跟別人解釋。
維運責任轉嫁到了使用者身上
傳統企業軟體出錯的時候有 vendor support，有 SLA，有人協助你寫 runbook。AI agent 出錯的時候，維運責任幾乎完全落在使用者這邊。
你要自己決定：
- 每個任務要不要加 timeout？
- 工具失敗要 retry 幾次？
- 輸出格式驗不了的時候怎麼 fallback？
- Agent 行為突然改變，是 prompt 的問題還是 model 的問題？
- 要怎麼在不影響生產的情況下做 prompt 改版？
這些問題在傳統軟體裡都有成熟解法，監控、log、rollback、canary 部署。在 AI agent 的世界裡，答案還很不成熟，而且每個人的架構都不同，沒有標準 playbook 可以直接套用。
更關鍵的是，這不只是工具成熟度的問題，也是思維框架的問題。多數使用者沒有 SRE 背景，不會自然地去想「這個 agent 的 observability 要怎麼設計」，他們只知道「agent 有時候怪怪的」，然後因為說不清楚問題出在哪，就放棄了。
「看起來能用」是最危險的狀態
AI agent 的失敗模式裡，最難處理的不是「完全壞掉」，是「大部分時候可以用，偶爾出錯但說不清楚為什麼」。這種狀態在傳統軟體裡叫做 flaky，工程師遇到都很頭痛。但在 AI agent 裡，flaky 幾乎是預設狀態，因為 LLM 的輸出本來就帶有不確定性。
要從「看起來能用」到「穩定能交付」，需要的不只是把 agent 裝起來，還需要：
- 每個關鍵輸出步驟的格式驗證
- 失敗的告警和完整 log
- 足夠的 regression test，能抓到 prompt 改版的副作用
- 明確的 rollback 策略
這份清單不算長，但每一項都需要額外的工程投入，而且幾乎不在任何一篇「AI agent 入門教學」的範疇裡。
主流化真正卡在哪
回到那篇 Reddit 的問題，setup friction 是真的，但它不是根本原因。根本原因是：AI agent 把維運複雜度轉嫁到了使用者身上，而大部分使用者沒有準備好承接這份責任，工具也還沒有把這件事簡單化到開箱即用的程度。
什麼時候 AI agent 的 observability 和 reliability 能做到跟一般 SaaS 產品一樣成熟，才是真正主流化的時機。在那之前，能穩定使用 AI agent 的人，基本上都需要有一定的 SRE 思維，或是非常能接受不確定性的使用情境。
另外，我之前也整理過一份部署 AI agent 之前的 checklist，如果有人想要的話可以在留言說一下，我找時間整理一下再貼出來。
作者：承翰