升版踩到的坑:250kb session cache 一直在拖速度,清完才知道差這麼多
最近把 OpenClaw 從 2026.4.23 升到 2026.05.07,原本只是 routine upgrade,沒想到發現了一個我之前完全沒注意到的問題:session cache 肥到 250kb 左右,一直在拖整體的回應速度。
清掉之後體感差蠻多的。不是那種「好像快了一點」的模糊感,是明顯的——loading 那個停頓縮短了,工具呼叫的間隔也沒那麼卡。在我這種 heavy use 場景(每天大概跑 20-30 個 session、很多是跨工具的 workflow),這個差距算是有感的。
Session cache 為什麼會長這麼大
我猜大部分人跟我一樣,升版前根本不會去看 cache 狀態。OpenClaw 的 session context 預設是 persistent 的,每次 session 結束它不會自動清,會一直疊。對話短的時候沒差,但如果你常常跑長 session、context 很深、或者有很多 tool call 的 log,就很容易在不知不覺間累積到幾百 KB。
250kb 聽起來不大,但放在 agent 啟動的 critical path 上就很有感。每次 session 初始化都要 load 這包東西,如果 context 本身又長,模型處理起來也會更慢。這個問題不是 bug,是 by design 的 trade-off——persistence 換來的代價就是這個。
從 PM 的角度來看,這其實是個蠻典型的 silent performance degradation。使用者不會知道系統正在變慢,因為它是漸進式的——每次多幾 KB,你的 baseline 也跟著移動了。等你真的感覺到「怎麼最近好像比較慢」,cache 早就老肥了。
Telegram webhook vs polling 這個改動更值得講
升版的另一個改動是 Telegram 從 polling 改成 webhook。老實說這個對我影響更大。
之前 polling 模式的問題:回應有延遲、有時候 message 沒接到、需要重新觸發。在我的 use case 裡,OpenClaw 接了幾個定期跑的 workflow notification,如果 Telegram 接收不穩,整個 feedback loop 就斷掉了。我曾經有一次以為某個 pipeline 跑失敗,結果只是 notification 沒收到。
改成 webhook 之後,這個問題基本消失了。訊息到了就到了,沒有 polling interval 的 lag,也不用擔心 polling 在某些網路環境下的 timeout 問題。
Polling 的邏輯其實很簡單:每隔 X 秒問一次「有新訊息嗎?」這在 traffic 低的時候完全沒問題,但它的 ceiling 就是 polling interval。Webhook 是 event-driven,訊息進來就觸發,延遲接近 0。對 reliability 要求高的場景,差別很明顯。
對 enterprise 使用者的 implication
這兩個改動放在一起,其實指向同一件事:長期穩定運行的可預測性。
一般 demo 場景不在意 cache 有多大,因為你每次都是全新 session;但如果你是在做真正的 production 部署,session state 的管理就是一個 operational concern。我現在養成了定期清 cache 的習慣,大概每兩週看一次,避免又累積到影響效能的程度。
Telegram webhook 的改動也是。Polling 在輕量使用下看起來 fine,但到了需要可靠 notification 的場景,event-driven 才是對的架構。這種事你很難在 POC 階段發現,等你 scale 上去才會踩到。
如果你也在跑 OpenClaw 一段時間了,建議升版前先去看一下 session cache 有多大,清掉再升,比較容易判斷效能差異是真的來自版本改動還是 cache 問題。兩件事同時動,debug 起來就麻煩了。
作者:Vivian L