OpenClaw Token 消耗太猛？这 3 招实测帮你砍掉 60% 开销

上周用 OpenClaw 接了个微信小助手的需求功能不复杂——日程管理加信息摘要。跑了三天Token 消耗直接飙到预算的 4 倍。看着后台用量曲线整个人都不好了。OpenClaw 能力确实强阿里算力加持下推理速度也快但不做 Token 优化成本会把你吃穷。核心思路就三个压缩上下文、缓存高频请求、动态切换模型。实测组合使用可以把 Token 开销降 50%-70%下面一个个拆。先说结论优化策略实施难度Token 节省比例适用场景Prompt 压缩 上下文裁剪⭐⭐30%-40%所有场景语义缓存层⭐⭐⭐20%-50%高频重复查询动态模型路由⭐⭐30%-60%多任务混合场景三个方案可以叠加我最终那个微信小助手项目综合下来 Token 消耗降了约 63%。环境准备我的开发环境Python 3.11openai SDKOpenClaw 兼容 OpenAI 协议redis做缓存层用tiktokenToken 计数pipinstallopenai tiktoken redisOpenClaw 走标准 OpenAI 兼容协议用 openai SDK 直接调。我这边统一走聚合接口方便后面做模型路由切换fromopenaiimportOpenAI clientOpenAI(api_keyyour-key,base_urlhttps://api.ofox.ai/v1# 聚合接口一个 Key 调 OpenClaw 和其他模型)方案一Prompt 压缩 上下文裁剪最简单也是回报最高的优化。很多人写 Prompt 跟写作文似的废话一大堆Token 就是这么烧掉的。1.1 System Prompt 瘦身我原来的 System Prompt 长这样别笑很多人都这么写# ❌ 反面教材178 tokenssystem_prompt_bad 你是一个非常专业的日程管理助手。你需要帮助用户管理他们的日程安排 包括但不限于创建新的日程、修改已有的日程、删除日程、查询某个时间段的日程安排。 你应该用友好、专业的语气回复用户。当用户的请求不明确时你应该主动询问更多细节。 你需要以 JSON 格式返回结构化的日程数据包含 title、start_time、end_time、description 等字段。 请注意所有时间都应该使用 ISO 8601 格式。 优化后# ✅ 优化后62 tokenssystem_prompt_good日程助手。操作创建/修改/删除/查询。 输出JSON{title,start_time,end_time,desc}时间用ISO8601。 不明确时追问。效果一样Token 少了 65%。模型不需要你用「非常专业的」「包括但不限于」这种修饰语它理解意图的能力比你想象的强。1.2 对话历史滑动窗口这才是 Token 消耗的大头。微信聊天场景下用户可能连续聊几十轮每次把完整历史全塞进去Token 会指数级增长。importtiktokendefcount_tokens(messages,modelgpt-4o):计算消息列表的 token 数enctiktoken.encoding_for_model(model)total0formsginmessages:totallen(enc.encode(msg[content]))4# 每条消息的 overheadreturntotaldeftrim_conversation(messages,max_tokens2000): 滑动窗口裁剪保留 system prompt 最近 N 轮对话 超出 max_tokens 时从最早的用户消息开始砍 system_msgs[mforminmessagesifm[role]system]chat_msgs[mforminmessagesifm[role]!system]# 从最新的消息往前保留直到塞不下trimmed[]current_tokenscount_tokens(system_msgs)formsginreversed(chat_msgs):msg_tokenscount_tokens([msg])ifcurrent_tokensmsg_tokensmax_tokens:breaktrimmed.insert(0,msg)current_tokensmsg_tokensreturnsystem_msgstrimmed# 实际使用conversation[{role:system,content:system_prompt_good},# ... 可能有 30 轮对话历史]# 裁剪到 2000 tokens 以内trimmedtrim_conversation(conversation,max_tokens2000)responseclient.chat.completions.create(modelopenclaw,# 通过聚合接口调用messagestrimmed,max_tokens500)实测 30 轮对话的场景不裁剪每次请求大概 4000-6000 tokens裁剪后稳定在 1500-2000 tokens。光这一步就砍掉了 60% 的输入 Token。1.3 摘要压缩进阶滑动窗口有个问题——早期上下文丢了。用户第 3 轮说了个重要信息到第 20 轮已经被裁掉了。解决方案对被裁掉的历史做摘要塞进 system prompt。defsummarize_old_context(old_messages):用便宜的小模型给旧对话做摘要summary_responseclient.chat.completions.create(modeldeepseek-v3,# 用便宜模型做摘要messages[{role:system,content:用50字内总结以下对话的关键信息只保留事实。},{role:user,content:str(old_messages)}],max_tokens100)returnsummary_response.choices[0].message.contentdefsmart_trim(messages,max_tokens2000):智能裁剪旧消息摘要 新消息保留system_msgs[mforminmessagesifm[role]system]chat_msgs[mforminmessagesifm[role]!system]ifcount_tokens(messages)max_tokens:returnmessages# 找到需要裁掉的部分keep_msgs[]cut_msgs[]current_tokenscount_tokens(system_msgs)200# 预留摘要空间formsginreversed(chat_msgs):msg_tokenscount_tokens([msg])ifcurrent_tokensmsg_tokensmax_tokens:cut_msgschat_msgs[:chat_msgs.index(msg)1]breakkeep_msgs.insert(0,msg)current_tokensmsg_tokensifcut_msgs:summarysummarize_old_context(cut_msgs)system_msgs[0][content]f\n[历史摘要]{summary}returnsystem_msgskeep_msgs摘要用 DeepSeek V3 这种便宜模型跑成本几乎可以忽略但保住了关键上下文。方案二语义缓存层微信小助手上线后发现一个规律40% 的请求在语义上是重复的。比如不同用户都在问「明天天气怎么样」「帮我看看明天天气」「明天天气」意思一模一样每次都调 API 太浪费了。importredisimporthashlibimportjson rredis.Redis(hostlocalhost,port6379,db0)defget_cache_key(messages): 生成缓存 key 简单方案直接对最后一条用户消息做 hash 进阶方案可以用 embedding 做语义相似度匹配 last_user_msgformsginreversed(messages):ifmsg[role]user:last_user_msgmsg[content]break# 归一化去空格、转小写normalizedlast_user_msg.strip().lower()returnfllm_cache:{hashlib.md5(normalized.encode()).hexdigest()}defcached_completion(messages,modelopenclaw,ttl3600):带缓存的 API 调用cache_keyget_cache_key(messages)# 查缓存cachedr.get(cache_key)ifcached:print([Cache HIT] 省了一次 API 调用)returnjson.loads(cached)# 缓存未命中调 APIresponseclient.chat.completions.create(modelmodel,messagesmessages,max_tokens500)result{content:response.choices[0].message.content,usage:{prompt_tokens:response.usage.prompt_tokens,completion_tokens:response.usage.completion_tokens}}# 写缓存TTL 1 小时r.setex(cache_key,ttl,json.dumps(result,ensure_asciiFalse))print(f[Cache MISS] 消耗 tokens:{response.usage.total_tokens})returnresult这个方案虽然简单粗暴纯文本 hash在我的场景下缓存命中率达到了 35%。想做得更精细可以用 embedding 算语义相似度命中率能到 50% 以上但要多一次向量计算的开销小项目可能不值得。方案三动态模型路由这是我觉得最聪明的优化——不是所有请求都需要用最贵的模型。思路很简单简单问题用便宜模型复杂问题才上 OpenClaw 或 Claude Opus 4.6。defclassify_complexity(user_message): 简单的复杂度分类器 实际项目中可以用关键词匹配 小模型判断 simple_patterns[你好,谢谢,查询,几点,天气,帮我看看]complex_patterns[分析,对比,总结,规划,建议,方案]msguser_message.lower()forpincomplex_patterns:ifpinmsg:returncomplexforpinsimple_patterns:ifpinmsg:returnsimple# 默认中等returnmediumdefroute_model(user_message):根据复杂度选择模型complexityclassify_complexity(user_message)model_map{simple:deepseek-v3,# 简单问题成本约 0.001 元/次medium:openclaw,# 中等问题complex:claude-opus-4.6,# 复杂推理}modelmodel_map[complexity]print(f[Router] 复杂度{complexity}, 使用模型{model})returnmodel# 实际调用defsmart_chat(messages):last_msgforminreversed(messages):ifm[role]user:last_msgm[content]breakmodelroute_model(last_msg)responseclient.chat.completions.create(modelmodel,messagesmessages,max_tokens500)returnresponse跑了一周数据请求分布大概是简单 45%、中等 35%、复杂 20%。算下来整体成本比全部用 OpenClaw 低了约 55%。整体架构长这样命中未命中简单中等复杂用户消息 - 微信上下文裁剪/摘要压缩语义缓存命中?直接返回缓存结果复杂度分类器DeepSeek V3OpenClawClaude Opus 4.6写入缓存返回用户DeepSeek V3、OpenClaw、Claude Opus 4.6 都通过 ofox.ai 的聚合接口调一个 API Key 切换不同模型不用分别管各家的鉴权和 SDK。ofox.ai 是一个 AI 模型聚合平台兼容 OpenAI 协议低延迟直连支持支付宝/微信付款做模型路由只需要换 model 参数代码完全不用改。踩坑记录坑 1tiktoken 不支持 OpenClaw 的 tokenizertiktoken 目前没有 OpenClaw 的编码器我用gpt-4o的编码器近似计算实测误差在 5%-10% 左右。做预算控制够用了但精确计费还是以 API 返回的 usage 为准。坑 2缓存 key 的归一化不够一开始只做了去空格转小写结果「查日程」和「帮我查一下日程」就对不上。后来加了停用词过滤命中率从 20% 提到了 35%。上 embedding 方案能更高但要多一次向量计算的开销小项目可能不值得。坑 3模型路由的分类器别用大模型做我一开始想用 LLM 来判断复杂度结果判断本身就要消耗 Token——脱裤子放屁。后来改成关键词匹配加消息长度启发式规则零成本搞定。小结三招总结Prompt 压缩 滑动窗口最简单立刻能做输入 Token 砍 30-40%语义缓存适合有重复查询模式的场景省 20-50% 的 API 调用动态模型路由把便宜模型用在简单任务上整体成本降 30-60%三个叠加起来微信小助手的日均 Token 消耗从 280 万降到了 103 万成本从每天大概 40 块降到 15 块左右。对个人项目来说这个差距就是能跑下去和跑不起的区别。OpenClaw 本身能力没问题关键是学会该省省、该花花。有问题评论区聊。