★ FEATURED ARTICLE OpenClaw 这玩意儿刚上手的时候我是真觉得“智能”这词儿没白叫。帮我抓数据、回消息、调度各种脚本能顶半个助理。但用了不到一周我一看账单差点没把咖啡喷屏幕上——Token 消耗比预期快了不是一点半点简直像开了水龙头。后来我花了两天时间把任务日志翻了个底朝天对上下文构造、工具返回、任务规划三个方向做了针对性的调整。实测下来开销直接砍掉了 60% 左右而且任务完成质量几乎没有肉眼可见的下降。这 3 招不是什么花哨的魔法全是工程实操里能落地的细节。先别急着琢磨高大上的模型微调绝大多数人 Token 烧得快根本原因就俩字浪费。要么是喂给模型的无用上下文太多要么是模型自己在那儿反复横跳、干重复活儿。搞清楚这个事你也能省下一大笔。1. 先搞清楚 Token 到底烧在哪儿在动手改配置之前我建议你先做一件事把 OpenClaw 的会话日志打开找个耗时最长、步骤最多的任务跑一遍然后仔细看看 Token 的消耗曲线。不看不知道一看吓一跳。我当时的任务只是“整理本周项目周报并提炼关键风险”结果模型硬生生给我跑了 40 多步。其中一半以上的步骤都是在反复读取同一个文件的内容而且前几步积累下来的对话历史在后半程一直在被重复计算。这就是典型的“上下文膨胀”问题。OpenClaw 这类 Agent 框架有个特点它会把你和它之间的所有对话、工具返回结果一股脑塞进下一次请求的上下文里。一旦任务链条拉长早期塞进去的那些原始数据就会像滚雪球一样越滚越大。你每一次调工具都是在上一次全量上下文的基础上继续追加Token 自然是成倍往上翻。我做了个简单统计在一段 20 步的任务里光是历史消息占用的 Token 比例就超过了 55%。真正对当前决策有用的信息可能只占其中 15%。也就是说你花的钱里有将近一半是给模型“复习”早已不重要的旧闻。所以省 Token 的第一件事不是压提示词字数而是重新设计上下文的管理方式。2. 第一招给上下文装上“紧身衣”——主动瘦身2.1 别让历史消息无限滚下去OpenClaw 默认配置里消息历史窗口给得相当宽松目的可能是为了保持上下文的连贯性。但在实际的长任务里“连贯性”这个东西是伪需求。一个任务拆成 20 步之后第 18 步需要的上下文通常只是第 17 步的结果和第 1 步的原始目标中间那些步骤的中间状态早就没用了。我当时做的第一个动作就是开启了“历史消息压缩”策略。OpenClaw 支持在连续对话次数超过某个阈值后触发一次摘要总结。简单说就是让模型自己把前面几百行对话提炼成一段 200 字以内的摘要然后把它放进后续的上下文里。这个做法的核心在于阈值设置。我实测下来的经验是不要设太大也不要设太小。设太大压缩就失去了意义设太小每两三轮就触发一次压缩模型频繁做总结反而多消耗不少 Token。我最终定的是 12 轮也就是每 12 次工具调用或消息交互后触发一次摘要压缩。这个参数下单次任务的 Token 总量下降了 25%而且模型的回答逻辑没有出现明显断档。2.2 裁剪工具返回结果只留“结论”不要“过程”另一个大坑在工具返回。我让 OpenClaw 调用一个 Shell 脚本去读取系统日志文件这哥们儿直接给我返回了 400 多行的原文。就是这 400 多行日志后面每次请求都要被反复计算。问题在于模型根本不需要看 400 行日志它只需要知道“哪几个地方出现了异常关键字”。所以第二件事就是给工具返回加上裁剪逻辑。在 OpenClaw 的 tool 配置里可以对输出做 max_tokens 限制也可以自定义一个返回处理函数。我当时是写了一个简单的后处理脚本对返回内容做截断只保留包含“error”“warn”“timeout”这些关键字的行其余全部丢弃。你可能担心万一模型需要看完整日志做判断怎么办我的策略是分层返回默认只给摘要和异常行同时生成一个完整的日志文件路径告诉模型“完整版本存在 /tmp/debug.log 里需要的话再调用 cat 查看”。这样既不影响判断又把常态返回量缩到原来的十分之一。2.3 关键参数速查表配置项默认参考值瘦身建议值省 Token 效果历史消息压缩触发轮数无/较大10~12 轮降低 20%~30%工具返回最大截断长度不限制800~1200 字符降低 10%~15%顶级回复 max_tokens模型默认按任务需求收窄 20%降低 5%~8%系统提示词长度经常堆一堆背景精简为核心目标输出格式每次请求省 100~300这套参数不是死的不同任务类型有不同最优解。但方向很明确能少给的就别多给能截断的就别完整返回。3. 第二招给任务规划戴上“缰绳”——限制自主发挥3.1 模型太“勤快”反而是灾难OpenClaw 默认的规划模式是“尽量自主”。我在跑“批量重命名文件夹内 100 个文件”这个任务时发现它每重命名一个文件就要单独调用一次工具然后停下来给自己输出一段“当前进度”的思考再去重命名下一个。30 个文件跑下来Token 消耗是正常情况的 3 倍。问题是这些“思考”有什么用呢模型是不需要思考的它只是在机械地把每一步都记录到对话流里。这就是 Agent 的“自我对话”成本。每执行一步模型都会生成一个“Thought”片段这个片段虽然是内部推理但它同样要计入 Token。如果不对规划模式做限制它就会养成凡事都要“想三步再做一步”的习惯。3.2 用批处理替代单步执行解决思路很直白把模型需要反复决策的环节变成一次性的脚本指令。还是那个重命名的例子我没有让 OpenClaw 自己去循环重命名而是让它写一个 Python 脚本脚本里一次性处理全部 100 个文件然后把执行结果返回给我。任务从“30 次工具调用 30 段思考”变成“1 次写脚本 1 次执行脚本 1 次返回结果”。这个改动非常凶Token 直接少了 40%。而且当场就把我那 100 个文件全处理完了任务耗时也从十几分钟缩短到几十秒。你可能会说那我直接用 Shell 不就完了还搞啥 OpenClaw话不是这么说。OpenClaw 的价值在于它能理解自然语言需求、拆解任务、处理异常。我们追求的不是让它变成一个纯脚本工具而是让它在“规划意图”和“执行动作”之间找到平衡点。能用代码完成的重复动作就交给代码只有需要判断和决策的节点才交给模型。这就像你请了个助理不应该让他每个字都亲自写而是告诉他“这个报告模板你拿去把数据填了有问题再问我”。3.3 限制工具的递归调用层数还有一个容易被忽略的参数是递归深度。OpenClaw 在遇到“找文件→读文件→分析内容→再找相关文件”这类连环任务时会不断地把新发现加到待办列表里。如果你不限制深度一个简单的“找找有哪些配置文件包含数据库地址”请求它能给你把整个项目目录遍历一遍顺带再读上十几个文件。我当时在配置里把 max_iterations 从默认值 20 调到了 8同时给“文件读取”这个工具单独设置了次数限额。超了次数就强制进入总结收尾阶段。这样模型就没法无限深挖任务粒度会被强制收敛到一个可控范围内。对比下来这类探索性任务的开销下降了 30% 左右。3.4 使用“阶段性目标任务”代替“全量目标”给模型的 prompt 也要做手术。不要一上来就甩给它一个宏大目标“帮我把这个项目看一遍列出所有问题。”这种目标隐含的 Token 成本极高因为模型会把它理解成“我需要检查每一个文件”。正确姿势是把它拆成阶段性子任务。比如第一步“扫描项目根目录下的 README提取项目模块划分”第二步“根据模块划分定位 src 目录下与用户登录相关的代码文件”第三步“只针对这些文件检查是否存在密码明文存储的问题”。每一步的边界都清晰模型就不会越界去读无关文件Token 自然就省下来了。4. 第三招让模型“少做阅读理解” —— 精简系统提示词与工具定义4.1 系统提示词不是论文很多人喜欢把系统提示词写成长篇大论动辄几百上千字把背景、目标、注意事项、示例全部塞进去。OpenClaw 本身功能已经很复杂了你再给它叠加一堆无效背景它每次请求都要基于这些字词做注意力计算Token 消耗是持续性的。我当时把系统提示词里一大段“项目背景描述”给删掉了这些内容对于完成单次工具调用没有任何帮助。删完之后模型也没有变笨反而执行意图更聚焦了。原则很简单系统提示词只保留角色定义、必须遵循的硬性规则和输出格式要求其余背景性、解释性内容一律去掉。4.2 用函数定义代替长描述OpenClaw 支持自定义工具函数。如果你把每个工具的 description 写得天花乱坠模型每次都要花 Token 去解析这些描述。我见过有人给一个“读文件”工具写了 200 字的描述描述里还把各种使用场景、注意事项都写了。这些东西对模型理解当然有帮助但代价是每次调用都要带着这 200 字一起计算。更聪明的做法是用函数名和参数定义来表达。把“read_file_with_encoding_detection_and_fallback”改成一个带参数的文件读取函数然后通过 arg_schema 去约束参数比写一大段描述有效得多。函数名本身就能传递语义模型看图说话的能力比你想象的强。描述只留一句“读取文件内容参数 path 为文件完整路径”足够用。4.3 减少无效的默认工具集合OpenClaw 默认会加载一整套工具集包括浏览器操作、代码执行、文件系统、网络请求等等。这些工具只要挂在列表里模型就可能在决策时把它们考虑进去每次请求多多少少都会产生 Token 开销。你可以根据任务类型动态指定启用的工具白名单。跑数据分析任务就别挂浏览器工具了跑网页抓取任务就别挂代码解释器了。我当时为不同任务场景建了三套工具配置数据处理场景只启用 python 执行和文件读写资讯收集场景只启用网络请求和文本解析系统运维场景只启用 shell 命令和日志读取这样一方面是省 Token另一方面还减少了模型误用工具的概率。同一套配置跑下来单次请求的平均 Token 量下降了 12%~15%链路越长的任务效果越明显。5. 实测数据三招叠加的真实效果光说不练假把式。我把这三招组合到一起在几个典型任务上做了前后对比。任务类型分别是多文件信息提取、批量格式转换、系统日志异常检测。每个任务都跑同一条输入只改配置参数排除模型版本差异带来的干扰。任务类型调整前 Token 消耗调整后 Token 消耗降幅任务完成度多文件信息提取12 个文件186,00071,20061.7%完整批量格式转换50 个文件94,50033,40064.6%完整系统日志异常检测1,200 行日志62,30027,80055.4%完整三招叠加的降幅不是加法是乘法。因为上下文瘦身减少了每次请求的基础 Token工具返回裁剪减少了请求的增量规划收敛又减少了请求的总次数。三层漏斗下来损耗就抹平了大半。需要说明的是我没有对模型能力做任何降级用的还是同一个模型版本。所以这个结果不是靠牺牲推理质量换来的而是把原本浪费在无效信息上的 Token 全部挤了出来。提示不同任务类型对 Token 缩减的极限不一样。如果你跑的是开放式的创意任务比如从零写长文、深度分析这种任务的 Token 消耗更多是在生成端压缩空间相对小一些。但凡是涉及“读取-判断-操作”的工具型任务这个套路基本都管用。6. 常见问题与排查技巧实录6.1 压缩摘要后模型“失忆”了怎么办有朋友按照我上面的做法调整后反馈说开起摘要压缩任务跑到后半程模型忘了最初的目标。这个问题十有八九是摘要写得太干。我建议在压缩 prompt 里专门加一个字段“保留原始用户目标的逐字摘要”。也就是说压缩时不光要总结过程性内容还必须把最初的需求原文重新抄一遍放进后续上下文。实测下来这招能保证模型从头到尾不跑偏而且只增加了几十个 Token 的成本完全划得来。6.2 工具返回被截断后数据不全怎么办这是另一个高频问题。日志文件太大截断后只保留了 error 行结果模型判断“正常”其实里面有几处 error 只是排查用的辅助信息并非真正故障。我后来给截断策略增加了一个“级别提示”在返回的摘要开头加一句“以下为全部 error/warn 行共 12 条另有 300 条 info 行已省略”并把完整文件路径放在最后。模型一看到这个结构就明白了哪些信息可能存在误判空间、需要进一步核查就不再傻乎乎地下结论了。6.3 任务规划收敛后模型变“懒”了限制 max_iterations 之后遇到复杂度高的任务模型可能只完成前面几步就提前收尾。这不一定是你参数设得太小更可能是模型发现迭代次数不够选择提前“交差”。我的排查思路是先看日志里模型的最后一段推理如果它明确说了“任务未完成因为迭代次数不足”那就是把阈值调大一些如果它根本没有表达任何不完整的意思那是模型理解有偏差应该优化子任务拆分方式。6.4 省了 Token但耗时反而变长了有个别场景会出现这种情况主要是摘要压缩和模型推理之间的平衡没抓好。压缩动作本身是一次额外的模型调用会引入几秒到十几秒的延迟。如果任务本身不长压缩的频率又设得太高就可能出现“省了 Token费了时间”的尴尬。针对这个情况我一般建议把触发轮数从 12 改成 20减少压缩次数让短任务一次跑完不压缩。症状可能原因解决方案任务中途跑偏摘要未保留原目标压缩时强制包含用户需求原文误判数据正常截断导致关键信息丢失增加省略行数和文件路径提示模型提前交差迭代次数限制过严拆分子任务或调大 max_iterations耗时增加压缩触发太频繁调大压缩轮数阈值工具误用工具集合太宽泛按任务场景配置白名单7. 实操中的一点额外心得写到这儿还想多说一句。Token 优化这件事最忌讳的就是一把梭。我见过有人为了省 Token把系统提示词压到只有一句话结果模型完全不知道输出格式生成了一堆没法解析的内容返工的成本比省下的 Token 还高。我的经验是先量化再优化。找一个稳定的测试任务把调整前的 Token 消耗记录下来每改一个配置就重新跑一遍对比结果。不是所有参数都调到最激进就是最好的合适永远是第一原则。OpenClaw 配置文档里给出的默认值通常是一个“兜底”水平。我们要做的是在默认值和极限值之间找到一个最优工作点。比如历史消息压缩我最终用 12 是结合了我自己的任务类型得出的结论你的任务如果上下文更小可能 20 更合适。还有个小技巧如果你用的是按量计费的方式记得设置一个每日消耗上限或单次任务的预算阈值。OpenClaw 支持这类预算控制参数一旦达到阈值就自动暂停避免某次异常任务把预算一次性吃完。这个机制平时像不存在一样但遇到那种模型陷入死循环的极端情况它就是救命稻草。最后再说一个细节。很多人在自定义工具返回处理时会忽略“返回结果的去重”。当时我那个日志检测任务日志里同一个错误重复出现几十次模型每次都把它当作新信息去思考。后来我在返回处理里加了一个简单的去重步骤只保留错误签名和出现次数。这个改动单次任务就能省下上万 Token而且模型的判断结果反而更准确了——它终于能看出哪些错误才是真正高频的。这些都是纸面上看不出来的坑只有自己跑过一遍任务、盯着 Token 数字一点点往下掉才会真正有感觉。希望我这三招能帮你把账单里的水分挤一挤让每一分 Token 都花在刀刃上。
阅读完成 · 觉得有帮助？
