agent 養起來容易，三個月後你在維運，不是在用
我通常不太發文，頂多留個言嘴一嘴。不過最近看到 Reddit 上有人說跟 OpenClaw 的關係從「甜蜜期」走到「it's complicated」，忍不住了。
因為那個歷程太熟悉。一開始自動化跑得順，每天省好幾個小時，感覺佔到了；然後某次更新之後有個 cron job 靜靜地在背景爛掉，三天後才發現；接著你開始花時間修，修完又有新的東西壞，到後來你花在「讓 agent 維持正常運作」的時間，快要超過它幫你省的時間。
這個收支比翻轉的時間點，大部分人都沒有預期到。
我自己的系統，大概在第三個月開始，維運時間比例超過 30%。到第五個月某次大更新之後，花了兩個週末修各種奇怪狀況——tool call 的 schema 悄悄改了、某個 prompt 在新版本行為不一樣、還有一個 cron 殘留在跑舊版邏輯，沒有任何 log 告訴我這件事正在發生。「安靜地壞掉」比直接 crash 更折磨，因為你不知道它壞了多久。
所以我現在的觀點是：擴張 agent 系統之前，要先把三件事搞定。
第一是 observability。我說的不是「有沒有 log」，log 誰都有，問題是你能不能在五分鐘內回答：「過去 24 小時哪些任務失敗了？失敗原因是什麼？某個 agent 的行為跟上週比有沒有不一樣？」如果答不出來，你的系統是在靠運氣撐著。我加了 structured logging 之後，第一週就抓到兩個早就在默默失敗的任務，一個已經爛了 11 天。
第二是 升級流程。大部分人升級 framework 的方式就是直接 pip install --upgrade 然後祈禱。這在 agent 系統上特別危險，因為 agent 的行為很容易被 prompt 格式、tool schema、甚至 system message 的細節影響。要有一個測試集，讓你能在升級前後比較 agent 的行為有沒有漂移。沒有這個，每次升級就是在賭博。
第三是 故障回復。你的 agent 掛掉的時候，你有辦法快速知道並回復嗎？我以前沒有，每次發現問題都是從「誒這個任務感覺好久沒跑了」開始，然後才去翻 log，才知道它三天前就已經爛了。後來我做了一個簡單的 heartbeat 機制，每個重要任務每天至少 ping 一次，沒 ping 到就告警。大概花了半天建，之後省了幾十個小時的排查時間。
說這些不是在嚇人，只是大家太容易被「這個 agent 跑起來真的很爽」的感覺帶走，直接開始疊更多任務、接更多系統，三個月後才開始痛。
維運成本跟 token 成本不一樣。token 是線性的，多做一件事多一些錢，很直觀。維運成本是非線性的——系統複雜度翻倍，維運難度可能翻五倍，因為各個部件之間的耦合會讓問題排查難度指數上升。
所以與其問「我可以讓這個 agent 做多少事」，更好的問題是「如果這個 agent 壞掉，我能在多快的時間內知道並修好」。如果現在答不出來，先把這個搞定，再談擴張。
那篇文章裡大概的意思是，它從「這個工具改變了我的工作方式」變成了「我現在在管理這個工具」。這個轉變幾乎是必然的，差別只在於你有沒有提前為它做好準備。
作者：島民No.9527