常駐上下文吃掉的 token，比你整個對話還多
Reddit 上最近有一篇求助文，作者說他做簡單任務的時候，平均每則訊息要燒掉 41.5K tokens。他已經試過 prompt caching，也把 user.md、soul.md、agent.md 都精簡過，甚至把 reasoning 關掉，還是降不下來，在求大家有沒有優化建議。
我之前整理過類似的觀察。這類問題最常見的診斷誤區，是預設「對話太長了，摘要一下就好」。但如果你仔細看 token 計數，通常第一輪就有幾萬 tokens，對話史根本還不存在。問題不是對話太長，是常駐上下文本身就很重。
OpenClaw 啟動時會載入一整組東西：system prompt、soul.md、user.md、agent.md、安裝的 skill 說明、記憶檔。這些在第一輪對話之前就全部進了 context window。如果這些加起來有 35K，每則訊息能用的空間就只剩 6K，而 41.5K 的帳單裡有接近 85% 其實是「還沒開始對話就定了」的成本。
補充一下，prompt caching 可以降費用，但不會降 context window 的壓力。這兩件事要分開看。Token 費用省了，但模型每次還是要處理那些內容，context 的佔用沒有消失。
真正有效的做法，是把常駐上下文分成三個層次來管。第一層是每回合都需要的：核心人格定義、安全規則、基本行為設定，這層盡量瘦，1-3K tokens 通常夠了。很多人把大量偏好都堆進 soul.md，但其實大部分是「偶爾需要」的東西，不是「每次都需要」的。第二層是按需載入：特定 workflow 的規則、工具說明、任務相關的背景，只有在相關場景才出現，skills 系統本來就是為這個設計的。第三層是真正的長期記憶：不是定期摘要對話，而是把重要事實、決策抽取出來放在外部，需要的時候精準 retrieve，而不是整包塞進去。
作者說已經精簡過那些 md 檔，但精簡如果只是「把文字縮短」，效果很有限。把 30% 的內容移到按需載入的 skill，那些 context 佔用就真的消失了，不只是壓縮。兩者的效果差異很明顯。
另外要注意的是 skill 說明本身的成本。OpenClaw 啟動時會把所有已安裝的 skill 的 metadata 都載入，讓模型知道有哪些工具可以用。如果你裝了很多 skill，這部分加起來也不少。不是說不要裝，是要意識到它也佔了 budget。
關掉 reasoning 降的是輸出端的 token，不是輸入端的。如果根本問題是 context window 壓力，這個操作只解決了一半，核心問題沒有動到。
41.5K 這個數字不一定異常高，要先知道那些 token 花在哪裡才有辦法判斷。我自己的建議是先量，把第一輪對話的 system prompt 佔比和 conversation history 佔比分開看，通常比例差異會給你很清楚的訊號，然後才知道要砍哪裡、移哪裡。
作者：承翰