我们从三月底到四月七号，硬生生把OpenRouter的token用量砍掉了35%。每天少处理4000亿个token，这个成果直接支撑了四月七号OpenClaw版本的顺利发布。如果没有这次优化，新版本上线后token用量会直接爆表，用户会卡到想砸电脑。
这事儿不是靠一个骚操作搞定的。我们就像修车老师傅，把AI代理跑流程时碰到的五个坑全填了：工具结果太大撑爆内存、压缩恢复机制乱搞、后台任务偷吃上下文、子代理重复记东西、还有缓存策略跟傻子似的总失效。
团队分工：一人主要负责修“工具结果太大”这个坑；队友Vincent搞缓存边界；Boris修工具排序和压缩逻辑；Ayaan帮着优化子代理的轻量上下文。
时间线很清楚：三月底动手，四月初收工
我们从三月底开始动手优化。三月二十五号，Boris提交了第一个关键修改，让压缩逻辑优先处理最新的工具结果。这是整个优化浪潮的第一枪。
接下来两周，我们疯狂提交代码。我在四月三号、五号、六号连续提交了八个修改。Vincent在四月四号一天提交了三个缓存相关的修改。Boris在四月三号又补了两个工具排序的修改。
到四月六号晚上，所有优化代码都合并到了主线。我们通宵跑测试，确认token用量确实降下来了，缓存命中率稳定在百分之八十以上，用户响应时间从七八秒缩到了三四秒。
四月七号早上，OpenClaw版本正式发布。用户完全感觉不到背后发生了这么大的优化，他们只觉得“哎，好像比之前快了一点”。这就对了，最好的优化就是让用户觉得理所当然。
OpenClaw的每个新功能都逼我们优化
很多人一听“优化Token使用”，脑子里会自动脑补成：调个参数、换个模型、搞个压缩算法就完事了。现实完全不是这么回事。
这个项目的核心问题在于：OpenClaw系统是一个多Agent结构，每天有无数路径在跑，每条路径都会产生上下文、工具调用结果、缓存命中与否等复杂行为。说人话就是：你不是在优化一个函数，而是在优化一整座城市的交通系统。你堵一条路没用，大家会绕路继续堵。你限流一个路口，另一个地方会爆炸。你清理一点上下文，结果缓存失效，反而更贵。
所以这次的核心思路是：盯住所有“高频经过”的路径，把那些看起来无关紧要的浪费全部干掉。这不是拍脑袋想出来的，而是团队花了很多时间画流程图，找出那些每天被调用几万次的地方。
OpenClaw有个新功能叫“长时间任务跟踪”：AI可以记住用户五分钟前说过的话，不会聊着聊着就失忆。
- 但这个功能巨耗token，因为AI得把整个对话历史一直带着。
- 我们的解决办法是优化压缩逻辑：以前压缩会乱砍内容，现在只砍那些已经用过的工具结果，保留对话主线。就像你看电视剧，每集开头的“前情提要”可以砍掉，但主角的名字不能忘。
OpenClaw还有个新功能叫“多工具并行调用”：AI可以同时查天气、算数学、搜网页，不用一个一个排队等。
- 但这个功能会导致工具结果井喷，一下子涌进来三四个超大返回包。
- 我们的解决办法是优化溢出处理：提前检查上下文还剩下多少空间，空间不够就立刻截断工具结果，不等爆了再救火。就像你吃自助餐，先看看盘子多大，再决定拿多少菜，而不是拿完发现放不下再往回倒。
OpenClaw的第三个新功能叫“子代理任务委派”：主AI可以派小AI去干杂活，自己继续跟用户聊天。
- 但这个功能导致子代理回来交报告时，会把整个聊天历史再复制一遍。
- 我们的解决办法是给子代理开轻量模式：干完活只交结果，不带历史。就像你让实习生去复印文件，他只需要把复印件给你，不用把复印机的使用说明书也附上。
长时间任务跟踪这坑有多深
你跟 AI 说“我喜欢吃榴莲披萨”，五分钟后又问“那上次说的那家店在哪”。AI 要是忘了你爱吃啥，那对话就跟金鱼一样，七秒记忆。所以它必须把刚才的对话从头到尾再读一遍。你聊十分钟，它读十分钟；你聊一小时，它读一小时。每次回答都是一次全文背诵，这谁顶得住。
更坑的是，系统不知道你哪句话重要。你跟它聊了五十轮，它每次都把五十轮全带上。里边可能有“哈哈哈”这种废话，也有“我生日是5月20号”这种关键信息。但它分不清，于是一股脑全塞进去。到了后面，token 就像烧汽油一样哗啦啦流。你本来只想查个天气，结果后台在疯狂翻聊天记录，跟翻你微信聊天记录一样累。
这就好比你跟朋友聊天，朋友每隔两分钟就把你们刚才说的所有话复述一遍，还问你“我复述得对吗”。你肯定会说“大哥你正常点，我刚说的那句不重要你忘了吧”。但 AI 以前不会这招，它只会老老实实全记住。所以优化团队第一刀就砍在这里：学会忘掉那些已经完成使命的废话。
原始压缩策略是乱砍一通
最早的时候，工程师们也知道 token 会爆，所以他们搞了个压缩策略。但这个策略特别粗暴：看哪个信息块不顺眼就随机砍一块。就跟剁饺子馅似的，一刀下去，葱姜蒜全混一块，管你哪个是哪个。结果经常出现惨案。
比如你跟 AI 说“我家猫叫旺财，它最喜欢吃三文鱼”。过了十分钟你问“旺财今天吃啥”，AI 如果中间那段关于“三文鱼”的信息被随机砍掉了，它就会说“旺财啊，它吃空气吧”。这就离谱了。关键信息丢了，模型就开始瞎编，编得还挺自信，跟某些不靠谱的同事一样。
更惨的是，有时候主线对话被砍了。你跟 AI 商量周末去哪儿玩，已经定好了去动物园，然后聊了点别的。再回头问“那我们几点出发”，AI 完全不记得要去动物园，反问你“去哪儿？你刚才说要去干嘛？”这种上下文断裂就会让你血压飙升。所以老办法不行，必须换成精准外科手术，只砍那些真的没用的东西。
真正的优化只砍已经完成使命的内容
这次改动的核心思路特别接地气：优先砍掉 tool results，也就是工具返回的结果。
啥是 tool results？你让 AI 查天气，它调用天气工具，工具回来说“北京今天30度，晴天”。这条信息就是工具结果。AI 看到这个结果，用它来回答你“今天穿短袖就行”。回答完了，这条工具结果就完成了使命，跟用完的草稿纸一样，可以扔了。
但是对话主线不能扔。对话主线就是你跟 AI 之间持续的剧情设定，比如“你喜欢吃辣”“你养了一只猫”“你下周二要开会”。这些信息必须长期留着，不然 AI 就会失忆。工程师们在代码里干的事，用大白话翻译就是：工具结果是临时草稿，用完就扔；对话主线是剧情设定，必须保留。你看，多简单。
对应的工程动作有三个，名字听着挺唬人，但意思很简单。
第一个叫“compact newest tool results first”，就是先砍最新的工具结果。因为最新的工具结果往往是刚用完的，价值正在快速下降。
第二个叫“prefer recent aggregate tool-result truncation”，意思是如果有好多工具结果堆在一起，优先把最近的一批砍短一点。
第三个叫“align tool-result truncation”，就是让砍工具结果的规则统一，别东一刀西一刀。
为啥这个策略特别管用
因为工具结果有个天生的特点：它是一次性消费信息。你查完天气，知道了今天30度，这个信息就被用掉了。下次再问天气，你肯定希望 AI 重新查，而不是拿上次的结果告诉你。所以上次的工具结果留它干嘛？占地方烧钱而已。而对话主线不一样，它是持续依赖的信息。你告诉 AI“我讨厌香菜”，之后每次点菜它都得记住这条，不能忘。
所以你这么一改，会发生两件好事。
第一，历史记录还在，因为你没砍对话主线，所以 AI 的记忆功能完全正常。它知道你爱吃啥讨厌啥。
第二，垃圾信息减少了，因为工具结果被清理掉了，token 消耗自然就下降。这一步是整个长记忆功能能够活下来的关键。要是没这招，你聊半小时就得破产。工程师们相当于给 AI 装了个智能垃圾桶，知道哪些能扔哪些必须留。
多工具并行调用效率起飞但数据爆炸
第二个功能更好理解：以前 AI 干活是一个工具一个工具排队来，先查天气，查完了再算数学，算完了再搜网页，跟咱们去银行排队办业务一样，慢得要死。现在改成了多工具并行调用，就是同时开好几个线程一起干活。你问“北京天气怎么样，123乘以456等于多少，最近有啥新闻”，AI 同时调三个工具，效率直接拉满，响应快得飞起。
但问题马上就来了。三个工具几乎同时返回结果，每个结果都可能特别大。天气结果可能带一整周的预报，数学结果就是一行数字倒还好，但搜索结果可能带好几篇文章。这三个结果一瞬间全塞进 prompt 里，就像三个快递员同时往你怀里扔箱子，你根本接不住，直接把你砸趴下。专业点说，这叫瞬时爆发，token 用量在几毫秒内冲到天花板。
后果就是 prompt 被塞爆。本来 prompt 有容量上限，比如能装8000个 token，结果三个工具结果加起来12000，直接溢出。系统就傻了，不知道该怎么办。老逻辑的处理方式是：先硬塞，塞不下了再截断，截断了再重试。这就像你往盘子里拼命夹菜，菜掉桌子上了你捡起来再吃，又浪费又恶心还折腾。而且重试又要花 token，恶性循环。
这次的关键改动是先算空间再决定塞多少
对应的工程动作有两步。
第一个叫“restore reserve-based overflow precheck”，就是把以前存在过的预留空间预检功能给恢复回来。啥意思？就是在构建 prompt 之前，先拿个计算器算一下：现在还能放多少 token。如果空间够，那就正常塞；如果空间不够，那就直接动手砍。
第二个动作叫“refine overflow/compaction routing”，就是优化溢出之后的处理路径，砍哪些、怎么砍、砍完怎么走，都规定得明明白白。
核心思路就一句话：在构建提示词 prompt 之前，先算账。
这跟咱们过日子一样，月底没钱了，你花钱之前肯定先看看还剩多少。不能先刷卡再想着怎么还。系统现在学聪明了，提前算好 token 余额。如果空间不够，直接截断 tool result，而且不是乱砍，是优先保留有价值的部分。什么是有价值的部分？比如搜索结果里的标题和第一段，比后面的广告有价值；天气结果里的今天天气，比下周的预报有价值。
这里最关键的工程意识是，系统从“事后处理”变成了“事前预算”。这可不是小改动，这是思维升级。以前是出了事再救火，现在是提前把火灭在源头。就像你出去吃饭，以前是先点一桌子菜，吃不完打包；现在是先看钱包，钱包里就两百块，你自然就不会点人均五百的餐厅。这个改动带来的实际效果特别明显：不会反复溢出，不会多次重试，不会把垃圾内容塞进 prompt。结果就是 token 使用变得特别稳定，系统响应更快，你的钱包也不用频繁被割。
子代理任务委派效率提高但信息复制粘贴
第三个功能更有意思。
主 AI 可以派子 AI 去干活，就像项目经理派小弟去跑腿。你在跟主 AI 聊天，主 AI 说“你等一下，我派个手下去查资料”，然后继续陪你聊。查资料这种脏活累活交给子 agent 干。子 agent 回来之后把结果交给主 AI，主 AI 再回答你。听起来很优雅对吧？你不用等，AI 也不卡顿，效率提高了。
但真正的问题在于，子 agent 回来的时候话太多。默认行为是啥？子 agent 出去干活，干完了回来交报告，顺便把整个上下文再带一遍。
什么叫整个上下文？就是你们之前聊的所有内容，包括那些废话、重复信息、已经用完的工具结果，它全都复制一份带回来。结果就是历史记录乘二，甚至乘N。你如果一轮对话里触发了好几个子任务，那就相当于每来一个子 agent，你的 token 账单就翻一倍。
这就离谱了。
你本来只想让子 agent 查个天气，它回来给你交了一本回忆录，里面写满了你们从聊天开始到现在的每一句话。
这谁受得了。
所以优化思路特别直接：让子 agent 只交作业，不写回忆录。
对应的改动有两步，一个叫“honor lightContext in spawned subagents”，就是在生成了 agent 的时候，让它们尊重轻量级上下文模式；
另一个叫“filter heartbeat pairs before context shaping”，就是在整理上下文之前，先把那些心跳配对的心跳记录给过滤掉，心跳记录就是系统之间定期打招呼的废话，对回答用户问题一毛钱用都没有。
什么是轻量上下文lightContext
轻量上下文就是只带三样东西出门。
第一，任务是啥，比如“去查北京今天的天气”。
第二，需要的最少背景，比如“用户问的是北京，不是上海；要今天，不是明天”。
第三，最终结果，比如“北京今天30度，晴天”。
就这三样，别的全不带。
不带完整聊天历史，因为子 agent 不需要知道你们刚才聊了榴莲披萨；
不带无关日志，因为那些是给程序员 debug 用的；
不带重复信息，因为同一个事情说一遍就够了。
你可以这么理解。主 AI 是项目经理，用户是大老板。大老板说“帮我查一下北京天气，然后看看上海怎么样，顺便算一下两地温差”。项目经理派三个小弟，第一个小弟只拿一张纸条出门，上面写着“查北京天气，当天，必须用最新数据”。第二个小弟拿的纸条是“查上海天气，当天，也是最新数据”。第三个小弟拿的纸条是“等前两个回来，算温差，取绝对值”。每个小弟回来的时候，手里只拿一张纸条，写着结果，而不是把项目经理的所有邮件都背回来。
这个改动为什么特别重要
因为子 agent 是高频行为。你一轮对话里可能触发好几个子任务，甚至十几个。如果每个子 agent 都复制完整上下文，token 会指数级增长。你聊半小时，本来 token 消耗是100万，结果因为子 agent 乱复制，变成500万，你哭都来不及。一旦改成轻量模式，每次调用都变轻，子 agent 只带必需品出门，来回都轻快。整体成本直接被压住，就像给每个快递员配了一辆小电动车，而不是让他们开大卡车进城。
而且这个改动还能让系统跑得更快。因为传输的数据少了，子 agent 启动也快了，返回结果也快了。你作为用户的感觉就是“AI 反应真快，而且还记得我说过啥”。其实背后是工程师们跟 token 斗智斗勇，又是砍草稿又是预检空间又是轻量化子任务。这些活都不性感，但省下来的钱是实打实的。
把三件事串起来看你就懂为啥是百分之三十五
这三个功能，分别代表了三种典型的烧 token 场景。第一个，长时间对话，导致历史记录慢慢累积，越聊越贵。第二个，多工具并行调用，导致瞬时爆发，几毫秒内 token 冲到天花板。第三个，子代理调用，导致重复复制，一个东西复制好几份存在那儿。而对应的优化就是三种精准的节流手段。压缩 tool result，用来控制长期累积，不让历史记录无限膨胀。预检 overflow，用来控制瞬时爆发，不让并行调用把 prompt 撑爆。轻量上下文，用来控制重复复制，不让子 agent 回来时带一大堆废话。
你可以把它们理解成三道闸门。第一道闸管长期，就像你家水龙头慢慢滴水，压缩 tool result 就把滴水的速度给你压住。第二道闸管瞬时，就像有人猛地开水龙头，预检 overflow 能在水喷出来之前先把阀门关小。第三道闸管重复，就像你家有多个水龙头同时滴水，轻量上下文让每个龙头都只滴有用的水。三道闸同时关紧，token 用量自然就掉下来了。百分之三十五这个数字不是随便说的，是实测出来的。代码提交上去，跑完压测，成本曲线直接下了一个台阶。
所以下次你再用那些能记住你五分钟前说了啥的 AI 时，可以默默感谢一下这帮跟 token 死磕的工程师。他们不是在写代码，他们是在帮你省钱。而且省得还挺幽默，毕竟他们连砍草稿这种词都想得出来。不说了，我去看看我的 token 账单，希望别太难看。
没有这次优化，OpenClaw会是个灾难
我们做过一个悲观的预测。如果不做任何优化，直接发布OpenClaw版本，OpenRouter的token用量会从每天4000亿涨到每天8000亿。这意味着每月多花几十万人民币的算力费用。
更可怕的是响应时间。测试数据显示，老版本平均响应时间四秒，OpenClaw新功能加上去后变成八秒。用户等八秒才看到一个回复，早就没耐心了，直接关网页走人。
用户流失会怎么样？我们估算过，响应时间每增加一秒，用户留存率下降百分之五。八秒意味着百分之三十五的用户会消失。这对一个靠用户活跃度吃饭的产品来说是灭顶之灾。
所以这次优化不是锦上添花，是雪中送炭。我们不是在“改进”OpenClaw，我们是在“拯救”OpenClaw。就像你给一辆刹车失灵的汽车装新刹车，这不是升级，这是保命。
OpenClaw发布后的数据打了我们的脸
四月七号发布之后，我们紧张地盯着监控面板。头一个小时token用量比预期高了百分之五，我们差点吓出心脏病。后来发现是因为新功能太受欢迎，用户使用频率暴增了百分之四十。
用量降了百分之三十五，但使用频率涨了百分之四十，净效果是token总用量反而比之前高了百分之五。这听起来好像优化白做了，但其实完全不是。
你想啊，如果没有优化，使用频率涨百分之四十，token用量就会涨百分之四十乘以两倍的新功能消耗，也就是涨百分之八十。现在只涨了百分之五，说明优化实际上抵消了百分之七十五的增长。
用户响应时间的数据更漂亮。虽然新功能更复杂，但因为缓存命中率提高了，平均响应时间从老版本的四秒降到了三点二秒。用户觉得更快了，我们成本也没爆，双赢。
老板看到数据后说了句大实话：“你们这帮人真会算账，用百分之五的成本增长换了百分之四十的使用量增长，这买卖划得来。”我们表面上谦虚说“哪里哪里”，心里爽翻了。
OpenClaw发布后我们还在继续优化
四月七号只是开始，不是结束。现在我们已经盯着下一个目标，把token用量再砍百分之二十。这次的方向是更聪明的缓存预热，提前把用户可能用到的内容塞进缓存，不用等调用了再加载。
我们还发现了一个新坑。OpenClaw的记忆功能会在多个会话之间共享缓存，但缓存边界没设好，导致不同用户的缓存互相污染。Vincent正在修这个，预计月底能搞定。
另外Ayaan发现子代理有时候会陷入死循环，自己派自己，然后无限递归下去。这不但浪费token，还会把服务器搞崩。我们现在给子代理加了深度限制，最多嵌套三层，超过就强制退出。
所以这篇文章不是终点，只是一个阶段总结。OpenClaw版本的成功让我们有信心继续挖坑填坑，把token用量压到更低。毕竟省下来的钱，老板可能会用来给大家买奶茶。虽然我知道他在画饼，但有饼总比没饼强。