升版踩到的坑：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