Maintenance burden 本身就是 AI 產品成本
看到 Reddit 上有人抱怨，自架 OpenClaw 幾個月後，更新、config、gateway、channel、daemon 和 container 一直要修，最後花在 maintenance 的時間比自動化省下來的時間還多。
我在看 enterprise pilot 時，會把 maintenance burden 直接放進 product cost。很多團隊算 ROI，只算 license fee 和 API cost，卻把查 log、重連服務、修 integration 當成「大家順手處理」。demo 看起來成功，production 卻變成別人的 full-time job。
我的 take 是先定義兩個數字。Useful automation hours 是 agent 沒有人介入下，完成且能被業務採用的時間。Maintenance hours 包含 incident triage、config repair、版本升級、人工重跑和確認資料沒有漏掉的時間。公式：Net automation hours = useful automation hours - maintenance hours。客服 agent 一週處理 40 小時工單，但 PM、IT 和主管合計花 18 小時救火，淨收益只有 22 小時。若原流程只需 15 小時，ROI 就不成立。
場景：公司讓 agent 每晚整理 CRM 新客戶，早上推摘要到 Slack。Pilot 第三週平台更新後 token scope 失效，摘要兩天沒送出，業務卻以為今天沒有新客戶。Pilot 開始前就要寫 SLO，例如每週 99% 排程成功率、失敗後 30 分鐘內告警、資料異常都有 audit log。SLO 沒達標，不能用「平均來說有跑」帶過。
Ownership 要寫名字，不要只寫 team。誰負責 connector，誰能 rollback，誰收到 alert、誰判斷資料要不要重送，都放進 runbook。否則 maintenance cost 只是被藏起來。
我會給 pilot 三個 exit criteria。第一，連續四週達到 SLO。第二，maintenance hours 不超過 useful automation hours 的 25%，incident 能在既定時間 recover。第三，換一位沒參與建置的人，照 runbook 能完成日常操作和 rollback。三項有一項不過，就縮小 scope 或停掉，不急著 rollout 到 10K users。
Agent 能不能做事只是第一關。Enterprise 真正要買的，是有人 ownership、有成本上限、壞掉時知道怎麼恢復的 service。否則買到的是需要被持續照顧的新系統，demo 結束後才開始收費。
作者：Vivian L