我吃过一个很蠢的亏。
那天我只是想让 OpenClaw 帮我改一个不大的脚本，活其实很轻：看一下报错，顺手把两个配置项对齐。
结果它上来先读 AGENTS.md，又翻 MEMORY，再去扫前一天的记录，接着把我放在目录里的 API 说明也捞出来了。
还没开始改代码，token 先烧掉一截。
我当时盯着终端输出看了半天，第一反应不是"这模型真贵"，而是这家伙怎么一开工就像搬家。
所以我后来更在意的，不是你给它换什么检索后端，也不是先去抠 prompt 里那几百个字。我现在基本只看一件事：这个 agent 开始干活之前，到底往上下文里塞了多少"它以为有用"的东西。
很多人会把省 token 这件事理解成节流，说话短一点，少开几个 subagent，stderr 少打印一点。这些当然有用，但都偏后面。
前面那口子要是没堵住，后面省得很辛苦。
OpenClaw 最容易失控的地方，其实不是回答得长，而是开场太重。
尤其你用久了以后，很容易把 memory 用成资料仓库：项目背景也记，接口文档也记，昨天踩的坑也记，临时想到的一句规则也记。
看着很安心，像是给它"喂熟"了，实际上每次启动都在交重复税。
你以为自己在养一个越来越懂你的 agent，很多时候其实是在养一个越来越臃肿的启动流程。
这事我吃亏最多的一次，是把一套内部接口说明直接塞进常驻记忆。
因为那几天一直在改同一个项目，我当时觉得反正经常要用，放进去省事。
头两次确实省事，第三天开始就不对了：问它一个很小的问题，它也要先把整套背景重新背一遍，回答看着挺稳，账单也很稳，稳稳往上走。
后来我把文档挪出去，只在记忆里留一句"这个东西放在哪，碰到什么任务再去读"，整个体感立刻就轻了。
所以我现在对"系统性省 token"的判断其实挺偏的：先别急着优化检索，先把常驻上下文砍干净。记忆里只放身份、偏好、工作规则、少量高频事实。项目资料、API 文档、历史记录，默认都不该常驻。
它们应该是可读资源，不是随身背包。
这个区别挺重要。常驻上下文像你出门非得把整个工具箱背在身上；按需读取更像到了现场再开后备箱。前者给你一种"什么都有"的安全感，后者才是真的能干活。
普通人要试，其实不用一上来折腾大工程。
我现在会拿一个很小的任务测：比如让它只改一个函数，或者只查一个报错。
然后看它第一轮动作。如果它还没碰任务本身，就已经开始读一串不相干文件，或者动不动把 memory 翻个遍，这种配置先别往大项目上压。
反过来，如果它能先问清边界，只读两三个必要文件，改完也不急着把整段过程写成长篇日记，这种才值得继续养。
还有个误会，我现在基本不太信了：很多人觉得只要上了某种更强的检索、压缩、索引，token 自然就下来了。
不是这么回事。检索能救的是"找资料"这一步，但你如果默认什么都该被记住、什么都该在开局读一遍，那后端换得再漂亮，底层习惯还是重的。
说白了，不少 token 不是花在不会找，而是花在不该带。
我现在会让 OpenClaw 碰的，主要还是两类活：上下文很窄、目标很清楚的，比如改一个 bug，补一段脚本，整理一小段说明。
那种需要长期背景、还容易一路发散的活，我反而会拆开，不让一个 agent 全吞。
先把这一步跑顺了，比什么"全局最优配置"都实在。
至少在我这儿，token 先别省在话术上。先省在开工之前。只要它别一启动就把家底全翻出来，后面很多事都会顺一点。