樱桃小公举上个月我翻了下 OpenClaw 的 API 账单，说实话有点肉疼。明明觉得自己没跑什么大任务，就是让它定时整理文件、回回消息、偶尔帮我查点资料，结果一个月下来 Token 费用比预想的高出一大截。后来我花了一周时间，把 OpenClaw 的各种配置逐个过了一遍，做了一轮针对性调整，次月账单直接砍掉一半左右，而且该干的事一件没落下，响应速度反而还快了。
这篇文章就把我实际动过的地方、每个配置背后的逻辑、以及调整过程中踩过的坑都摊开讲清楚。如果你也在跑 OpenClaw 这类本地 AI 助手，每个月被 Token 账单追着跑，那这篇应该能帮你省下真金白银。我会从"钱到底花在哪"开始讲，因为不搞明白这个问题，后面所有配置都只是在瞎调。
1. 先搞清楚 Token 烧在哪：记账比调参更重要
1.1 本地助手和网页聊天的计费逻辑完全不同
很多人一开始没意识到一个问题：你在网页上跟大模型聊天，和让 OpenClaw 这种本地助手去干活，Token 消耗模型是完全不一样的。网页聊天每次发消息，对话上下文就存在浏览器会话里，不会每次都把一个超长前缀发给模型。但 OpenClaw 是常驻型助手，它每执行一轮操作，都要把三样东西打包发给模型：系统提示词（System Prompt）、当前可用的工具定义列表、以及目前为止的对话和工具调用记录。只要其中任何一样偏大，每一次请求的费用都会被抬高。
这就像你每天出门，不管今天是要跑一趟超市还是就在楼下遛弯，都得揣上一个塞满东西的行李箱。行李箱本身不重，但架不住你一天要开合几十次。
1.2 用日志和 API 后台把消耗拆解到"动作"级别
我在改任何配置之前，先做了一件事：把 OpenClaw 的日志级别调到 debug，开着跑了两天，然后去模型服务商的 API 后台，把每天的请求明细拉下来，按 endpoint、请求次数、输入 Token、输出 Token 做了个排序。这个过程不复杂，但特别关键，它能让你看到真实的数据而不是靠感觉猜。
看完数据我才发现，最烧钱的其实不是那些看起来很复杂的任务，而是三类被忽视的场景：
- 高频固定开销：每次请求都带上的系统提示词和工具列表。我当时的配置里挂了十来个工具，每个工具的 description 加起来足有三千多 Token，每天上百次请求全带着它跑。
- 失败重试的放大器效应：OpenClaw 调用工具偶尔会拿到格式不对的返回结果，模型需要把错误信息重新读一遍、重新生成一次调用参数，一来一回就是好几倍 Token 消耗。
- 长会话的历史包袱：同一个线程跑得越久，历史消息积压越多，每次请求都要把所有历史重新发给模型去"理解一遍"，越往后单次请求成本越高。
所以第一阶段的结论是：先把账记清楚，找出自己的消耗大头，再决定先优化哪一项。每个人的使用场景不同，大头也不同，但一般来说，从"固定开销"和"重试开销"入手优化，见效最快。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 上下文窗口这么配，长会话也不再"越聊越贵"
2.1 限制历史消息数量，而不是让对话无限膨胀
默认情况下，OpenClaw 会把一个线程里的历史对话尽量完整保留，方便模型理解上下文。这对那种需要连贯对话的场景确实好用，但也意味着只要你这个线程还活着，Token 消耗就会随着对话轮数不断膨胀。
我的方案是直接给历史消息数量设一个上限，超出部分的策略从"继续塞进上下文"改成"自动摘要压缩"。配置文件里大概是这么写的：
yaml复制context:
maxHistoryMessages: 20
compression:
enabled: true
triggerAfter: 20
instruction: >
你正在压缩一个长对话的历史记录。请保留与当前任务直接相关的决策、
用户偏好和待办事项，其余日常问答内容用一两句话概括即可。
maxHistoryMessages 这个值我试过 10、20、50，最后选 20 算是折中：既能保住最近十几轮的关键信息，又不会让上下文前缀太长。设成 10 的话省 Token 更狠，但多轮复杂对话时模型容易"失忆"，经常忘记前面已经确认过的事情。
2.2 对话摘要不是越短越好，分场景定策略
摘要压缩配置本身也有讲究。最开始我用的是"把全部历史压成三句话"，结果一段时间后发现，OpenClaw 在处理需要精确信息的任务时经常犯错，比如让我整理某个文件夹里上周生成的文件，它会含糊地给出一个不完整的答案。原因是我把摘要压得太狠，文件路径、生成时间这些关键细节全丢了。
后来我把摘要策略改成分场景处理：
- 普通问答类：历史超过 20 轮后，老的对话压成两三句话，只留主题脉络。
- 工具操作类：保留最近 5 轮工具调用原始输入输出，更早的直接丢弃，不做摘要也不保留原文。因为工具调用的结果是确定性的，下次要用可以重新执行，不需要靠"记忆"。
- 需要长期记忆的信息：不放在对话上下文里，而是让 OpenClaw 写进外部存储（比如一个专门的偏好文件），用时再读取。
这样调整之后，既保住了关键细节，又不会让上下文被大量历史堆积占满。
2.3 定时重置工作线程，别让临时任务污染长期上下文
OpenClaw 如果一直不重启，主线程里会堆积很多跟当前长期目标无关的临时操作记录。比如今天让它查了个天气，明天让它发了条定时消息，这些记录本身又没什么价值，却一直在占用上下文空间。
我加了一个每天凌晨的定时任务，直接把主工作线程的上下文做一次 reset，相当于每天开工前把桌子清干净。配置文件里大概是这样：
yaml复制schedules:
- cron: "0 4 * * *"
action: reset_context
scope: default_thread
如果你有跨天的长期任务，比如连续几天在跟进一个项目，就别对那个线程做全量重置，可以只清掉非活跃线程，保留当前活跃线程的上下文。这个细节一开始我也没注意，后来发现重置完任务断了，才改成只清理空闲线程。
3. 工具定义和 System Prompt 瘦身：固定开销才是大头
3.1 关掉不用的工具，比调模型省得还多
OpenClaw 内置了不少工具能力，比如浏览器操作、邮件收发、日历管理、文件读写、消息推送等等。只要这些工具是启用的，它们的名称和 description 就会完整出现在每一次请求的上下文里，不管这次任务用不用得到。
我之前为了"以防万一"，把能开的工具全开了。后来看请求明细发现，很多工具一次都没被调用过，但它们的描述定义却一直在幕后帮我花 Token。这就像你办了一张包含几十个频道的电视套餐，实际上每天只看了两个台，但钱是全套的钱。
我的做法是，先按过去两周的实际使用记录，把从未调用过的工具全部禁用：
yaml复制tools:
disabled:
- browser_automation
- email_client
- calendar_reader
# 只保留真正在用的
enabled:
- file_operations
- message_sender
- web_search
这一项调整完成后，单次请求的固定前缀 Token 直接从三千多降到了一千五左右。要是按每天 100 次请求来算，光这一项每天就省下约 15 万 Token。
3.2 精简工具描述：同一个工具，换个写法省一半
工具是不能随便删的，但每个工具的 description 是可以改的。OpenClaw 默认的工具描述往往写得很全，恨不得把参数说明和边界情况全列上去。但在实际使用中，模型只需要知道"这个工具是干嘛的、什么时候该用、核心参数是什么"，就够了。
我拿其中一个文件操作工具举例。默认描述可能有一两百个 Token，我改完后的版本大概只有原来的三分之一：
yaml复制tools:
custom_descriptions:
file_operations:
description: >
读取、写入、移动本地文件。当用户要求查看或修改文件内容时使用。
核心参数：path(文件路径), action(read|write|move), content(写入内容)。
改完之后效果没有变差，模型依然能准确调用这个工具。因为模型看工具描述主要就是判断"这个工具能不能解决当前问题"，过于冗长的描述反而会稀释它的注意力。这里也提醒一句，自定义描述时不要装模作样写一堆"你应该在某某条件下使用"的废话，直接说清楚用途和参数就行。
3.3 System Prompt 只留行为准则，别重复造轮子
另外一个常见浪费在 System Prompt 里。很多人（包括最初的我）喜欢在系统提示词里把各个工具怎么用、该按什么顺序调用又写一遍，生怕模型不懂。其实工具描述已经把这些信息给模型了，系统提示词里重复一遍，就是纯粹的重复计费。
我最后把 System Prompt 砍到只保留三块内容：
- 角色的基本行为准则，比如"除非用户明确要求，否则不要主动执行高风险操作"。
- 任务默认执行方式，比如"多步任务执行前先列计划"。
- 对输出格式的要求，用于适配后续解析逻辑。
删掉所有重复的功能说明后，系统提示词从两千多 Token 降到了一千以内。这里我建议你每隔一两周就重新检查一次系统提示词，因为随着使用习惯变化，提示词里很容易混入一些早已用不上的规则。
4. 模型分级与降级路由：廉价模型不是不能用，是要用对地方
4.1 按任务难度分配不同模型，而不是一律用最强模型
如果你在 OpenClaw 里配置了多个模型服务商的 Key，或者同一个服务商的不同档位模型，那"分级调度"就是省钱效率最高的一招。
我自己的使用场景里，大概只有三分之一的任务需要真正的强推理能力，比如写一段复杂代码、排查一个逻辑问题。剩下的任务，比如格式化文本、搜索关键词总结、把一段话翻译成英文，用便宜的小模型完全够用，而且速度更快。
我的配置思路是给 OpenClaw 套一层路由规则：
yaml复制model:
router:
default: claude-sonnet
rules:
- match: "翻译|润色|改写|摘要"
model: claude-haiku
- match: "文件操作|消息发送|定时任务"
model: claude-haiku
- match: "写代码|调试|分析逻辑|规划"
model: claude-sonnet
这个规则不是 OpenClaw 某个版本的固定字段，而是我通过它的事件拦截机制自己实现的，但它反映的核心思路很通用：让便宜模型处理机械性任务，让昂贵模型专注于真正需要脑子的任务。配置的时候注意，关键字匹配不要太宽泛，否则容易把真正需要强模型的请求也路由到小模型上。
4.2 模型降级链：主模型挂了别用高价模型顶上
OpenClaw 跑长时间任务时，偶尔会遇到限流或服务暂时不可用。默认配置下，它可能会在重试时调用同一个模型，如果连续失败，有些配置会直接切到备用模型。之前我没注意备用模型选的什么，直到有一天我发现它居然在用比我主模型还贵的旗舰模型做重试。
这个教训之后，我把降级链改成了"向下兼容"：主模型是 Sonnet，降级目标就是 Haiku，而不是 Opus。宁可降级到便宜模型先把任务完成，也不能因为重试把成本翻倍。说到底，降级链的设计原则就一句话：它存在的意义是兜底，不是提级。
4.3 减少无效请求：合并小任务，降低调用频次
还有一个经常被忽略的点是请求频次。Token 计费跟次数不是简单的线性关系，有些平台是每次请求固定收一笔基础费，或者有最低计费单位。频繁发起小请求，累计起来也是一笔不小的开销。
我后来把一些零散的小任务改成攒批处理。比如定时要发送的多条消息、要更新的多个文件，不再是一条一条让 OpenClaw 去处理，而是攒到一个任务里，让它在同一个请求里完成多步操作。这样既减少了请求次数，也减少了上下文被反复加载的情况。代价是任务发起的延迟变高了几秒，但对那些不追求实时响应的任务来说完全可以接受。
5. 缓存复用和批处理：把重复计算的账单直接砍掉
5.1 提示词缓存：同前缀请求的隐形折扣
如果你的模型服务商支持提示词缓存（Prompt Caching），那这基本上是最不需要动脑、但回报很高的配置。它的原理是：当多个请求使用完全相同的前缀时，服务商对缓存命中的那部分 Token 会按远低于正常价格计费，有的甚至低到十分之一。
OpenClaw 这类助手特别适合用提示词缓存，因为它天然就是"长前缀 + 短增量"的请求模式：系统提示词、工具定义、历史对话这些前缀几乎不变，每次真正变化的只有最后一小段用户输入。
我开了缓存配置后的体验是，长会话场景下输入 Token 费用明显下降。需要注意一点：不同服务商的缓存有效时间不一样，有的只有几分钟，有的长达几小时。如果你的任务间隔比较久，缓存可能早就过期了，这时再调这个配置意义不大。短时间高频使用的场景，它的收益才会真正体现。
5.2 幂等性和结果复用：别让相同任务反复执行
OpenClaw 在执行定时任务时，如果上一轮任务因为某个步骤失败而中断，重新开始往往会整个任务重新跑一遍。我之前遇到过的情况是：定时备份任务在写文件那一步失败了，OpenClaw 重试时从头开始重新做了一遍文件扫描和整理，白白多花了一轮完整调用的 Token。
解决思路是给任务加上"幂等设计"，也就是让 OpenClaw 在每步操作前先检查目标结果是否已经存在。配置上没法用一个字段直接开启，但可以在提示词和任务编排里约定：执行写操作前先读状态，如果结果已满足，直接跳过。
比如备份任务，如果目标目录下已经存在当天的备份文件，就直接标记完成，不再重新生成。这样处理后，失败重试时就不会从头再来，省下的是完整一轮任务的 Token。
5.3 外部状态存储：让长期记忆不占上下文
上文提过，很多需要长期记住的信息不应该放在对话上下文里，而应该放到外部存储中。我的做法是单独建了一个偏好记录文件，让 OpenClaw 每次需要读取用户偏好时直接读文件，而不是从历史对话里翻。
这也是一种"缓存但不过期"的思路。对话上下文是需要持续计费的，无论使用频率多高，只要在上下文窗口里就会算钱；而外部文件只在你需要读取时才产生一次性 Token。对于"用户喜欢什么格式""常用路径有哪些"这类稳定信息，把它们移出上下文、放进外部文件，是我做过的性价比最高的调整之一。
6. 前后对比与避坑经验：实测省了多少
6.1 配置调整前后的 Token 消耗对比
在我这一轮调整完成后的完整月份里，我统计了比对的数字：
| 指标 | 调整前（日均） | 调整后（日均） | 变化 |
|---|---|---|---|
| 输入 Token | 约 420 万 | 约 210 万 | 下降约 50% |
| 输出 Token | 约 55 万 | 约 42 万 | 下降约 24% |
| 请求次数 | 约 1100 | 约 850 | 下降约 23% |
| 月度费用 | 基准线 | 约为基准线的 48% | 节省约 52% |
输入 Token 的下降是最明显的，主要归功于工具裁剪、上下文限制、摘要压缩和缓存生效这四个配置的组合拳。输出 Token 下降不多，是因为该干的活还是得干，只是减少了无效重试。整体算下来，月度费用几乎砍了一半。
6.2 调整过程中踩过的几个坑
第一个坑是摘要压太狠导致任务质量下降。我一开始为了省钱把历史摘要压成三句话，结果 OpenClaw 在回答"上次讨论的某方案细节"时完全想不起来。后来改成"保留关键细节 + 压缩日常寒暄"才平衡过来。省 Token 不能以牺牲核心功能为代价，这是底线。
第二个坑是把工具全关了，结果任务链路断掉。我为了压固定开销把所有非必要工具都关了，结果有个定时任务需要调用浏览器来抓取数据，运行到一半直接报错。所以建议你在关闭工具前，先确认当前在跑的定时任务里依赖了哪些工具，尽量按"最近 30 天实际使用"来裁剪。
第三个坑是缓存配置用在不支持缓存的服务商上，白折腾。如果你的模型服务商压根不支持提示词缓存，那配置填了也没用。建议先用一个简单的测试请求看返回头里的计费明细，确认有缓存命中的标记再依赖这个配置。
6.3 从"先记账"到"定期复查"的经验总结
这套配置跑了一个多月，整体效果稳定，费用没有出现反弹。我个人的感受是，Token 省钱不是一个一劳永逸的事情，因为使用场景和模型价格都在变。我现在的习惯是每月底花十分钟看一眼 API 后台的量级数据，如果发现某个环节消耗异常增长，就针对性地检查对应的配置项。
如果非要说一个最值得优先动手的地方，我建议从"关闭无用工具 + 限制历史消息数量"开始，这两项改动最小、收益最大，而且几乎不会影响使用体验。等你适应了这套思路，再逐步去调整模型路由和缓存配置，效果会更明显。
最后分享一个小技巧：在 OpenClaw 里改配置时，尽量一次只改一个变量，然后观察两三天。不要像我一开始那样，一口气把上下文、工具、路由全部改完，结果出了问题根本不知道是哪个配置引起的。慢慢调、逐项验证，虽然过程多花点时间，但每一分省下来的钱都知道是怎么省的，后续维护也轻松。