OpenClaw 每月 Token 开销太高？这 5 个优化帮你省一半
如果你也在自建 AI 助手，大概率会遇到同一个问题：Token 消耗比预期高。 这不是因为你用得多，而是因为默认配置往往不是为成本优化设计的——它追求的是开箱即用和功能完整。这两个目标之间有天然的张力：功能完整意味着所有能力默认开启、所有配置走高规格。在你刚上手的时候这是好事，但一旦跑稳了，就有了优化的空间。 一旦你开始认真审视每一次 API 调用的 token 组成，就会发现大量可以省下来的消耗——不是省在功能上，而是省在不必要的重复和冗余上。下面的 5 个优化点就是我从自己的消耗数据中提炼出来的。 我在亚马逊云科技 Bedrock 上跑 OpenClaw 大约三个月后，做了一次系统性的配置优化。花了大约一周时间分析消耗分布、调整配置、对比效果。结果是 Token 消耗降低了约 50%，使用体验基本无感知变化。 为什么默认配置下消耗偏高？因为默认配置的设计目标是"开箱即用"和"功能完整"，不是"成本优化"。这两个目标之间是有冲突的——功能完整意味着所有选项默认开启、所有配置默认走高规格。这在你刚上手的时候是好事，但一旦跑稳了，就值得花时间把不必要的消耗降下来。 我把消耗拆解后，发现浪费主要集中在四个方面：所有场景用同一个贵模型、thinking 模式常开、system prompt 太长、心跳太频繁。下面把 5 个核心优化点展开讲。 这是投入产出比很高的一项优化。 大多数人配置 OpenClaw 时只设一个模型，所有交互都走同一个。但实际上，日常 70-80% 的对话——查个信息、格式化文本、简单问答——用轻量模型就能很好地完成，而且响应延迟更低，体验反而更好。 亚马逊云科技 Bedrock 上的 Nova Lite，价格大约是 Claude Sonnet 的几十分之一。不是几倍的差距，是几十倍。在简单任务上，两者的输出质量差异几乎感知不到。 配置方式： 哪些场景适合轻量模型？ 日常问答、信息查询、文本格式化和编辑、简单翻译、shell 命令提示、文件内容总结等。这些任务 Nova Lite 处理得很好，响应速度还更快。 哪些场景需要高端模型？ 多步推理、复杂代码生成和调试、长文档分析、架构设计讨论等。这些场景切到 Claude Sonnet 才有明显的质量提升。 一个实际体验： 我让两个模型分别处理同一个简单任务——"帮我把这段 YAML 转成 JSON"。结果几乎一样，但 Nova Lite 的响应时间更短。而当我让它们分析一段有 bug 的异步代码时，Sonnet 的分析明显更深入、更准确。这就是模型分级的意义——大部分时候便宜的就够了，偶尔需要好的再上。 效果： 约 30-40% 的费用节省。这个数字取决于你的使用模式——简单交互占比越高，省得越多。 Claude 的 extended thinking 功能会让模型先生成一段内部推理过程再给出答案，质量提升显著。但代价是 token 消耗平均增加 30-50%。 为什么增加这么多？因为 thinking 模式下，模型会先输出一段"思考链"——可能是几百到几千个 token 的推理过程。这些 token 虽然你不一定看得到（取决于配置），但都在计费。让模型"深度思考"一个查天气的请求，或者"认真推理"怎么排个序，纯属浪费。 需要时通过命令临时启用： 完成后关闭： 我的判断标准： 如果问题需要"想一想"才能回答好（多条件决策、复杂 debug、架构分析），就开 thinking；如果是随手一问的事情（查个命令用法、格式化个文本），不需要开。 我统计了自己的使用数据，大约只有 15-20% 的请求真正受益于 thinking 模式。其余 80% 的请求开着也是白花钱。 一个常见的误解： 有人觉得"开着 thinking 也没坏处，模型如果觉得不需要深度推理会自动跳过"。实际上不是这样——只要 thinking 模式处于开启状态，模型就会生成推理链，不管任务有多简单。所以"默认开着以防万一"其实是一个代价不小的策略，建议改为"默认关闭，需要时开启"。 与模型分级的协同： 如果日常用的 Nova Lite 本身不支持 extended thinking，那日常对话自然不会产生额外的 thinking token。两项优化叠加效果更好。 这是一个容易被忽视但影响持续的优化点。 OpenClaw 的 system prompt 由多个配置文件拼接： 如果这些文件加起来有 5000 字（约 2500 tokens），每次请求就先消耗 2500 个 token 在 system prompt 上——还没开始处理你的问题呢，2500 个 token 已经花出去了。每天 50 次交互，一个月就是 1500 次 × 2500 tokens，光 system prompt 就是一笔可观的开销。 优化策略： 单次看不明显，但这是一个会在每次请求中复利的优化。而且这些删掉的内容大多是"正确的废话"，删了也不影响 AI 的表现。 注意定期审查： system prompt 文件会随着使用逐渐膨胀——你今天加一条规则，下周加个笔记，不知不觉又胖回去了。建议每个月花几分钟看一眼，保持精炼。 具体哪些该留，哪些该删？ 留下的应该是真正影响 AI 行为的具体指令——比如"用中文回复""代码块用 markdown""保护用户隐私"。删掉的是通用废话（"你是一个有帮助的 AI"）、重复出现的规则、以及过度详细的解释。直觉上，如果某句话删了你觉得 AI 的表现不会有任何变化，那就大概率该删。 OpenClaw 的 heartbeat 机制让 AI 助手定期主动检查是否有待处理的事务。每次心跳是一次完整的 API 调用，包含完整的 system prompt 和上下文。 这意味着每次心跳的成本跟你手动问一个问题差不多。如果心跳间隔太短，一天累积下来的调用次数相当可观——而且很多时候心跳的结果就是"没事"，也就是白花了钱检查了一下发现什么都不用做。 大多数个人用户并不需要那么高频的主动检查。你有事的时候大概率会主动找 AI，而不是等它来找你。 为什么选 45 分钟？ 这是我在"及时性"和"省钱"之间找到的平衡点。如果你对实时性要求更高（比如依赖心跳做邮件提醒），可以设 30 分钟。如果你几乎不依赖主动通知，甚至可以设 60 分钟或更长。关键是根据自己的实际需求来，而不是用默认值。 同时精简 不要在 HEARTBEAT.md 里堆一长串检查清单。每多一项检查，每次心跳的 token 消耗就多一点。只保留真正需要定期自动检查的，其他的手动触发就好。 效果： 心跳从默认高频调到 45 分钟一次，次数减少约 67%。配合内容精简，这部分 token 消耗减少 70% 以上。心跳是 24 小时不停的，这个节省日积月累很可观。 这一项不是减少 token，而是从计费层面优化。 一些第三方 API 服务有月费或保底消费。对于使用量波动较大的个人开发者——某天用得多、某天几乎不用、周末放假、出差一周——这种固定成本模式不太划算。 亚马逊云科技 Bedrock 的按需模式则是纯按量计费： 配合 IAM 角色认证，配置很简洁： EC2 实例绑定 IAM 角色后，OpenClaw 自动通过角色获取临时凭证，无需在配置文件中存放明文密钥。认证过程对应用透明，由底层 AWS SDK 自动完成。 对个人开发者的好处： 如果你的使用量有明显的波动（工作日用得多、周末少、出差期间不用），按需模式意味着你只为实际使用付费。没有"这个月用不完"或者"超了得加钱"的心理负担。对于还在评估 AI 助手价值的人来说，这种零承诺的模式也更友好——试用成本就是你实际用掉的那些 token，不多不少。 前四项叠加后，我的实际 Token 消耗降低了约 50%。第五项的按需计费进一步优化了实际支出。 需要注意：每个人的使用模式不同，以上数字是基于我的场景（以日常对话和简单任务为主，偶尔有复杂编程和分析需求）。如果你的场景以复杂任务为主，模型分级带来的节省会相对少一些；如果你的场景以简单交互为主（比如纯粹当个信息助手用），省的比例可能更高。 供快速参考： 建议从模型分级开始，几分钟改完就能见效。每一项独立，不用一次全做。如果你只做一件事，就做模型分级——投入产出比高得离谱。 推荐顺序： 模型分级 → 关 thinking → 调心跳 → 精简 prompt → 评估 Bedrock。前三步十分钟搞定，效果能覆盖总节省的大部分。 成本优化不是一次性的事情。随着使用习惯的变化、新模型的发布、功能的迭代，定期回顾一下配置和消耗分布是有意义的。 以上 5 个优化点互相独立，可以按需选择实施。核心思路就是：让每一个 token 都花在有价值的地方。 不需要牺牲功能，不需要降低体验，只是把默认配置中的冗余消耗挤掉。 这些思路也不仅限于 OpenClaw。任何基于 LLM 构建的应用——无论是 AI 助手、聊天机器人还是内容生成工具——都面临类似的成本挑战。模型匹配任务、减少不必要的 token 生成、精简固定开销、控制调用频率，这些原则是通用的。 如果你正在为 LLM 应用的运行成本发愁，不妨从分析消耗分布开始，找到你场景下的浪费点，然后对症下药。优化也不是一劳永逸的——每隔两三个月回头看看消耗数据，你可能会发现新的浪费点，也许是 prompt 又膨胀了，也许是有新的更便宜的模型上线了。保持这个习惯，长期受益。 你的 Token 账单长什么样？评论区见 👋OpenClaw 每月 Token 开销太高？这 5 个优化帮你省一半
OpenClaw 是一个开源的 AI 助手框架，可以连接大语言模型来构建个人化的 AI 助手。本文针对其运行成本（主要是 Token 消耗）做了一次系统优化，记录 5 个可复用的配置方案，实测综合节省约 50%。
问题背景
1. 模型分级：按任务复杂度选模型
{
"agents": {
"defaults": {
"model": {
"primary": "amazon-bedrock/amazon.nova-lite-v1:0",
"fallbacks": ["amazon-bedrock/anthropic.claude-sonnet-4-20250514-v1:0"]
}
}
}
}default 是日常模型，处理绝大部分交互；thinking 是高端模型，在需要深度推理、代码生成或复杂分析时使用。2. Extended Thinking 默认关闭
{
"thinking": "off"
}/reasoning on/reasoning off3. System Prompt 精简
AGENTS.md（行为规则）、SOUL.md（人设）、USER.md（用户信息）、TOOLS.md（工具说明）等。关键点在于：这些内容在每次 API 请求中都会完整发送。 不是发一次就缓存了，是每一次请求都带上完整的 system prompt。优化前：~5000 字 → ~2500 tokens/次
优化后：~1800 字 → ~900 tokens/次
每次节省：~1600 tokens
月度节省（50 次/天）：~240 万 tokens4. Heartbeat 频率调整
{
"agents": {
"defaults": {
"heartbeat": {
"every": "45m"
}
}
}
}HEARTBEAT.md，只保留真正需要定期执行的检查项：<!-- HEARTBEAT.md -->
- 检查待处理的提醒
- 按需添加其他项目，不要贪多5. 选择合适的计费模式：Bedrock 按需
{
"agents": {
"defaults": {
"model": {
"primary": "amazon-bedrock/amazon.nova-lite-v1:0",
"fallbacks": ["amazon-bedrock/anthropic.claude-sonnet-4-20250514-v1:0"]
},
"heartbeat": {
"every": "45m"
}
}
}
}综合效果评估
优化项 预估节省比例 模型分级策略 30-40% thinking 模式控制 10-15%（与分级叠加后的增量） system prompt 精简 5-10% heartbeat 频率调优 5-10% Bedrock 按需计费 弹性节省，因人而异 操作清单
default 用轻量模型，thinking 用高端模型"thinking": "off" 默认关闭 extended thinkingHEARTBEAT.md结语