OpenClaw的哪些配置能让我省一半Token烧钱开销？

前言 AI agent 好用，但跑起来 token 消耗真的肉疼。笔者用 OpenClaw 跑了一段时间之后，摸索出了几个实际有效的省 token 姿势，拿出来给老哥们参考——不是什么玄学调优，都是能直接落地的配置改动。 MEMORY.md 越短越好 这是最容易被忽视的地方。OpenClaw 每次 memory recall 都要扫描 MEMORY.md，文件越长，token 消耗越高。 笔者踩过的坑：早期把所有对话结论、临时备忘、甚至聊天记录片段都往里塞，一个月后 MEMORY.md 涨到 300 行，每次对话光 recall 就多烧几百 token。 正确做法： MEMORY.md 只存结论，不存过程 日志流水放 memory/YYYY-MM-DD.md，按需读取 定期清理过期条目，没用的直接删 对比示意： 写法 token 开销 老大喜欢简洁回答 低 2025年1月3日，跟老大聊了很久，他说他比较倾向于不那么冗长的回答风格... 高 memory_search + memory_get 组合拳 OpenClaw 提供了两个内存工具，很多人只用了 memory_search 就结束了——其实只做到一半。 正确流程： 1. memory_search("查询关键词") → 返回相关片段 + 行号 2. memory_get(path, from=行号, lines=N) → 精准取那几行 这个组合的好处是：agent 不需要把整个文件加载进 context，只取真正需要的片段。笔者实测，recall 相关内容的 token 消耗能降 70%~80%。 如果让 agent 直接读整个 MEMORY.md，一次就是几百 token 打水漂。 HEARTBEAT.md 保持轻量 心跳机制本身没问题，问题出在 HEARTBEAT.md 里堆了太多内容。每次心跳触发，这个文件的内容都会注入 context。 笔者的策略： 只放当前还没完成的检查项 完成一条删一条，不留历史 不需要定期检查的时候，文件保持空（只留注释行） # HEARTBEAT.md # 保持空 = 跳过心跳 API 调用，直接回 HEARTBEAT_OK 长期周期性任务（比如「每天早上 9 点检查邮件」）改用 cron job，和主 session context 完全隔离。 复杂任务扔给 subagent 主 session 的 context 随着对话越来越长，每一轮的 token 消耗都在涨。对于一次性的重活（分析长文档、批量处理数据、跑代码），用 sessions_spawn 起一个独立 subagent： sessions_spawn( task="分析这份报告，提取关键结论", runtime="subagent" ) subagent 有干净的 context，任务完成即销毁。主 session 只需要收一个结果摘要，来回开销大幅减少。 举个实际场景：让 agent 分析一份 50 页 PDF。直接在主 session 跑，整份内容进 context，光 input token 就爆了；扔给 subagent 处理，主 session 只拿摘要，省下的 token 可能有 10 倍差距。 工具调用一步到位 每次工具调用都有 overhead，agent 来回确认、分步操作会快速累积消耗。 几个实用原则： 批量 > 循环：Feishu Bitable 写 100 条记录，一次批量写 vs 循环 100 次，token 差距巨大 明确指令，减少确认：prompt 里写清楚「直接执行，不需要确认」，避免 agent 来回问 并行工具调用：互相不依赖的查询，让 agent 在同一轮同时调用，而不是串行等结果 按任务选模型 OpenClaw 的 cron job 支持 model 字段，不同任务没必要都用最贵的模型： 任务类型 推荐模型 心跳检查、格式转换、简单问答 doubao-seed-2.0-pro 代码生成、复杂推理、写文章 claude-sonnet / gpt-5.4 cron job 配置示例： { "payload": { "kind": "agentTurn", "message": "检查今天有没有重要邮件", "model": "litellm/doubao-seed-2.0-pro" } } 总结 省 token 的核心思路就一句话：减少无效信息进入 context。