上个月底对账，发现 AI 助手的 Token 开销比我预期高出不少。花了一周做了轮配置优化，费用直接腰斩。这篇记录下我的具体操作。
起因：一张账单引发的优化
事情是这样的——我用 OpenClaw 搭了个 AI 助手，跑在亚马逊云科技的 Bedrock 上，日常干点查资料、写代码、整理文档之类的活。用了几个月一直没怎么关注费用，毕竟按量付费嘛，感觉应该还好。
直到上个月我打开 Bedrock 的用量面板，仔细一看……怎么说呢，不至于肉疼，但绝对有优化空间。
我把消耗拆解了一下，发现问题出在几个地方：简单的闲聊在用贵的模型、thinking 模式一直开着、system prompt 写了篇小作文每次都重复发、心跳检查跟心电图似的太频繁了。这些加在一起，浪费比我想象的大得多。
说白了，就是"默认配置"和"省钱配置"之间有很大的差距。默认配置追求的是功能完整和开箱即用，不是成本优化。这就像你买了一台高配笔记本，然后用它来写文档——能用，但很多性能在空跑。AI 助手也一样，很多"能力"在大部分时间里是闲置的，但你在为它们持续付费。
于是我给自己定了个目标：在不降低使用体验的前提下，把 Token 消耗砍一半。
结果？还真做到了。下面是我的 5 个具体优化点。
招式一：模型分级 — 大事用好刀，小事用快刀
这是性价比很高的一招。
OpenClaw 默认用一个模型处理所有请求。但你想想，让 Claude Sonnet 帮你查个天气、回个"收到"，是不是有点大材小用？
亚马逊云科技 Bedrock 上的 Nova Lite 模型，价格大概只有 Claude Sonnet 的几十分之一。简单任务用它完全够了，响应还更快。这个差价不是百分之几十的差距，是数量级的差距。
配置很简单，改 openclaw.json：
{
"agents": {
"defaults": {
"model": {
"primary": "amazon-bedrock/amazon.nova-lite-v1:0",
"fallbacks": ["amazon-bedrock/anthropic.claude-sonnet-4-20250514-v1:0"]
}
}
}
}
逻辑就是：
default（日常模型）：Nova Lite，处理闲聊、简单查询、格式化、翻译等thinking（深度模型）：Claude Sonnet，只在需要推理、写代码、做分析时上场
我统计了下自己的使用习惯，70-80% 的交互其实都是简单任务。也就是说，大部分请求走了便宜模型。你可能会问：便宜模型质量行不行？我的体感是，对于日常问答、信息查询、文本编辑这些场景，Nova Lite 和 Sonnet 的回答质量几乎没有体感差别。只有到了多步推理、复杂代码生成这个级别，才能明显感受到差距。
一个实际的例子： 我经常让 AI 帮我查 Linux 命令的用法、格式化 JSON、总结一段文字。这些任务 Nova Lite 处理得又快又好。但偶尔我需要它帮我分析一段复杂的代码逻辑，或者讨论一个系统架构方案，这时候切到 Sonnet 才有明显的质量差异。区分清楚这两类场景，钱就花对地方了。
效果： 单这一项就省了约 30-40% 的费用。如果你之前所有场景都用的高端模型，这个比例可能更高。
第二招：关掉 thinking 模式的"常开"
Claude 系列的 extended thinking 是个好功能——开启后回答质量确实更好，特别是复杂推理场景。但代价是什么？它会生成一大段"思考过程" token，这些都计费。
说得更具体一点：开启 thinking 后，模型会先在内部跑一遍推理链（你可能看不到），然后基于这个推理链给出最终回答。这段推理链少则几百 token，多则几千。全部都算钱。
在我的使用中，开 thinking 模式单次请求的 token 消耗平均涨 30-50%。而大多数日常对话根本不需要这个深度——"帮我把这个列表排个序"需要深度推理吗？显然不需要。
解决方案： 默认关掉，需要时手动开。
{
"thinking": "off"
}
需要深度推理时：
/reasoning on
搞定后关掉：
/reasoning off
什么时候开 thinking？ 我的判断标准是：如果这个问题你自己想清楚了才来问 AI 的（比如"帮我分析下这个架构的优劣"），就开；如果是随手一问的（"这个命令怎么用"），就不用开。
回顾一下我的使用记录，真正需要 thinking 的场景大概只有 15-20%。也就是说 80% 以上的请求白白多花了 30-50% 的 token。
补一个容易踩的坑： 有些人会觉得"开着 thinking 总比不开好"，因为万一模型自己判断不需要深度推理，它会自动跳过推理链。实际上不是这样——只要 thinking 模式开启，模型就会生成推理过程，不管任务多简单。所以"默认开着以防万一"是一个代价不小的策略。
和模型分级叠加的好处： 如果你日常用 Nova Lite（招式一），它本身不支持 extended thinking，所以日常对话天然不会产生 thinking token。两招配合，效果加倍。
第三招：给 System Prompt 减肥
这个坑我踩得比较深。
OpenClaw 的 system prompt 由 AGENTS.md、SOUL.md、USER.md、TOOLS.md 等文件拼接而成。重点来了——这些内容每次 API 调用都会完整发送。不是首次发一次就缓存了，是每次都发。
我刚开始用的时候特别兴奋，在 AGENTS.md 里写了一堆详细的行为规则，SOUL.md 里搞了很长的人设描述，TOOLS.md 里记了一大段笔记。加起来超过 5000 字。
算笔账：每天交互 50 次，每次带 5000 字的 system prompt（约 2500 tokens），一个月就是 1500 次 × 2500 tokens。光 system prompt 就是一笔不小的开销，而且这些是"重复的钱"——每次请求都在为同样的内容付费。
我的做法：
- 总量控制：所有 prompt 文件加起来不超过 2000 字
- 砍废话："你是一个乐于助人的 AI"——这种话模型不需要你告诉它，删
- 去重复：三个文件里都强调"保护隐私"，留一处就行
- 用短句：一句话能说清的不写一段
优化前：~5000 字（约 2500 tokens/次）
优化后：~1800 字（约 900 tokens/次）
每次省：~1600 tokens
每次省的看起来不多，但乘以每月 1500 次调用就是 240 万 tokens。这个数字就相当可观了。
一个提醒： system prompt 文件会随着使用慢慢膨胀。你今天加一条规则，下周加个笔记，不知不觉又回到了 5000 字。建议每个月花 10 分钟审查一下这些文件。就像代码要重构，prompt 也要定期"瘦身"。
哪些内容该保留？ 真正影响 AI 行为的具体规则（比如"回复用中文""代码块用 markdown 格式"），以及用户特定的上下文信息（比如时区、偏好）。这些是有实际效果的。
哪些该删？ 通用描述（"你是一个乐于助人的助手"）、过度详细的解释（为什么要保护隐私——直接说"保护用户隐私"就行）、重复出现在多个文件中的相同规则。
第四招：心跳别太勤
OpenClaw 的 heartbeat 机制会定期唤醒 AI 检查待办事项——查邮件、看日历、执行定时任务等。每次心跳 = 一次完整的 API 调用（带完整 system prompt + 上下文）。
很多人可能没意识到，每一次心跳的成本跟你手动问一个问题是一样的——完整的 system prompt 要发一遍，上下文要加载一遍，模型要跑一遍推理。如果心跳间隔太短，一天光心跳就能消耗不少 token。
优化： 拉长间隔到 45 分钟。
{
"agents": {
"defaults": {
"heartbeat": {
"every": "45m"
}
}
}
}
反正我有事会主动找 AI，不需要它每隔几分钟就"看看有什么事"。45 分钟的延迟对我来说完全可以接受。
进一步优化： 精简 HEARTBEAT.md，只保留真正需要定期检查的项目。不要在里面堆一大堆检查清单，每多一项，每次心跳的 token 消耗就多一点。其他任务在需要时手动触发就好——成本一样，但频率低得多。
<!-- HEARTBEAT.md 精简版 -->
- 检查待处理的提醒
- 其他按需添加
效果： 心跳频率降低约 67%，再加上每次心跳内容精简，这部分 token 消耗减少 70% 以上。别小看这个数字——心跳是 24 小时不停的，日积月累很可观。
关于 heartbeat 和 cron 的选择： OpenClaw 也支持 cron 定时任务，专门用于精确时间的需求。如果某个检查项需要在特定时间执行（比如"每天早上 9 点检查邮件"），用 cron 比 heartbeat 更合适。Heartbeat 适合"定期看看有没有事"这种模糊的检查需求。把两者区分清楚，也能避免在 heartbeat 里塞太多东西。
第五招：Bedrock 按需计费 — 选对计费方式也是省钱
这条不是直接省 token，而是优化计费模型。但对总体费用的影响可能比你想象的大。
用第三方 API 有时候会有月费、保底消费之类的门槛。而亚马逊云科技 Bedrock 的按需模式：
- 纯按量：用多少算多少，不用不花钱
- 零保底：不用不花钱，周末休息就是零成本
- 弹性好：月度波动大也没关系，没有"用不完浪费"的情况
配合 IAM 角色认证，连 API Key 都不需要配：
{
"agents": {
"defaults": {
"model": {
"primary": "amazon-bedrock/amazon.nova-lite-v1:0",
"fallbacks": ["amazon-bedrock/anthropic.claude-sonnet-4-20250514-v1:0"]
},
"heartbeat": {
"every": "45m"
}
}
}
}
在 EC2 上跑的话，绑好实例角色就行。没有明文 Key 在配置文件里躺着，更安全；按需付费，更灵活。IAM 角色用的是临时凭证，自动轮转，不用你操心密钥管理。
为什么说按需比包月好（对个人开发者）？ 我的使用量一周内就有不小的波动——工作日可能交互上百次，周末可能只用几次甚至不用。如果按包月，那些不用的日子就是白花钱。按需模式下，不用就是零成本。特别是如果你还在评估要不要长期用 AI 助手，按需模式让你没有任何承诺压力。
我的感受： 特别是结合模型分级之后，按需计费的优势更明显了。忙的月份多花点，闲的月份自然就少了。比起预付费或包月方案，心里舒服很多。
汇总：5 招叠加效果
| 优化项 | 预估节省 |
|---|---|
| 模型分级 | 30-40% |
| thinking 模式控制 | 10-15%（叠加后增量） |
| system prompt 精简 | 5-10% |
| heartbeat 频率调优 | 5-10% |
| Bedrock 按需计费 | 弹性节省，因人而异 |
前四项叠加，我的实际 Token 消耗降了约 50%。Bedrock 按需计费让实际费用的降幅可能还要更大些。
当然每个人使用模式不同，效果有差异。复杂任务为主的话模型分级省得少一些，简单交互多的话省得更多。关键是先分析清楚自己的消耗分布——知道钱花在哪了，才知道从哪省。
快速上手 Checklist
-
openclaw.json配模型分级（default = 轻量，thinking = 高端） - 设
"thinking": "off"默认关闭 - 精简
AGENTS.md/SOUL.md/USER.md，合计 ≤ 2000 字 - heartbeat 间隔调到 30-60 分钟，精简
HEARTBEAT.md - 考虑迁移到 IAM 角色 + Bedrock 按需模式
从模型分级开始改，几分钟搞定，见效很快。每一项都独立，不用一次全做。
我的建议顺序： 先改模型分级（效果大），再关 thinking（一行配置），然后调心跳频率（也是一行配置），接着花半小时精简 system prompt，有空了再评估要不要迁移到 Bedrock。前三步加起来十分钟搞定，效果能覆盖总节省的大部分。
收尾
省 Token 的核心思路就一个：把钱花在刀刃上。简单任务用便宜模型，复杂任务才上好模型；不需要深度思考时别开 thinking；system prompt 不要写成小作文；心跳不用那么频繁。
这些都不是什么高深的技巧，但叠加起来效果确实明显。而且这些优化思路不仅适用于 OpenClaw——任何基于 LLM 的应用都可以参考类似的逻辑来控制成本。关键是意识到"默认配置不等于优化配置"，然后花点时间分析一下自己的消耗分布，对症下药。
希望这篇能帮你省下一些不必要的开支，把预算花在更有价值的地方。
最后一个建议：优化不是一次性的。每隔两三个月回头看看消耗数据，你可能会发现新的浪费点——也许是 prompt 又膨胀了，也许是使用习惯变了，也许是有新的更便宜的模型可以替代。保持这个习惯，长期来看能省下不少钱。
有更省钱的招数？评论区交流 💬
