OpenClaw 2026.6.6 升级踩坑：239次API调用、2900万token，Agent成本失控的5个根因与优化方案
摘要： OpenClaw 2026.6.6 升级后，一天的 API 用量从日常的几十次飙升到 239 次模型调用、2900 万 token。通过对 usage.json 的逐小时数据分析，我找到了成本失控的五个根因，以及一套可落地的优化方案。
上周我把 OpenClaw 从旧版升级到了 2026.6.6。满心期待更强的能力，结果第一天就把我打醒了。
先看一组数据。导出 7 月 29 日的 usage.json 后，用 Python 跑了一遍：
一天的完整画像
这一天共 239 次模型调用。总 token 消耗 29,177,863，其中：
| 指标 | 数值 |
|---|---|
| 模型调用次数 | 239 次 |
| 输入 token | 12,927,506 |
| 输出 token | 90,229 |
| 缓存读取 token | 16,160,128 |
| 总 token | 29,177,863 |
| 工具调用次数 | 190 次 |
| 平均延迟 | 89.3 秒 |
| P95 延迟 | 307 秒（5.1 分钟） |
| 用户消息 | 51 条 |
| Assistant 消息 | 239 条 |
用户说一句话，Agent 平均做 4.7 件事。 这个比例本身说明 Agent 的自主推理链条太长了。
工具调用分布：exec 占 39%
| 工具 | 调用次数 | 占比 |
|---|---|---|
| exec（命令行） | 75 | 39.5% |
| read（文件读取） | 34 | 17.9% |
| edit（文件编辑） | 20 | 10.5% |
| web_search | 18 | 9.5% |
| write | 18 | 9.5% |
| web_fetch | 14 | 7.4% |
| 其余 6 种工具 | 11 | 5.8% |
exec 独占 75 次——这里面有发布命令、有编码检查、有各种环境变量设置。但不应该这么多。一次正常发布需要的 exec 调用应该是 3-5 次。
Token 消耗时间线：两个暴增时段
把 token 按每 15 分钟（UTC）分组，画出时间序列：
Quarter 3 (UTC): 166,891 token ← 启动，低
Quarter 4: 165,488
Quarter 5: 118,695
Quarter 6: 875,640 ← 第一波上涨
Quarter 7: 135,787 ← 回落
Quarter 8: 640,179
Quarter 9: 1,480,542 ← 暴涨
Quarter 10: 772,394
Quarter 11: 2,430,097 ← 峰值1
Quarter 12: 1,684,661
Quarter 13: 4,536,742 ← ★ 全天最高峰
Quarter 14: 4,837,429 ← ★ 第二高峰
Quarter 15: 180,126 ← 暴跌
Quarter 17: 366,162
Quarter 18: 1,517,536
Quarter 19: 3,299,256 ← 第三波
Quarter 20: 2,800,169
Quarter 23: 252,085
Quarter 24: 331,832
Quarter 25: 2,096,347
Quarter 26: 489,805
两个暴增时段非常清晰：
- Quarter 9-14（约 UTC 2:15 - 3:30，北京时间 10:15 - 11:30）：6 个时段合计 15,739,370 token，占全天 54%。 这是文章写-改-发-错的循环高峰期。
- Quarter 18-20（约 UTC 4:30 - 5:00，北京时间 12:30 - 13:00）：3 个时段合计 7,616,961 token，占全天 26%。这是第二篇文章的发布+修复循环。
两个时段加起来占全天的 80%。
而正常的 Quarter（比如 Quarter 3-5 的启动阶段、Quarter 15 的回落阶段），每个时段只有 10-18 万 token。差距是 25-30 倍。
根因一：上下文污染——49 个 Skill 全量注入
打开 usage.json 的 contextWeight 字段，一行数据让我愣住了。
系统提示词总长度：43,240 字符。
这 43,240 字符拆开看：
| 组成部分 | 大小 |
|---|---|
| 引导文件（AGENTS、SOUL、TOOLS、IDENTITY、USER、MEMORY、HEARTBEAT） | 20,435 字符 |
| Skills 列表（49 个） | 9,974 字符 |
| 工具 Schema（23 个工具的完整 JSON Schema） | 19,345 字符 |
| 系统指令、规则等 | ~3,500 字符 |
49 个 Skill 全部加载，每个都占约 180-215 字符的介绍。 但你实际只用到了 wechat-mp 一个。其余 48 个——canvas、meme-maker、agent-browser、buffett-perspective、elon-musk-perspective——每次请求都在占用 prompt 预算。
这不是 50 × 200 = 10,000 字符那么简单。对注意力机制来说，上下文里的每一条无关信息都是在稀释模型对关键指令的关注度。就像你面前摊了 50 张说明书但你只需要其中 1 张——其余 49 张不光没用，还会让你找不到你需要的那张。
解决： 如果短期内只用 wechat-mp 和 content-creation 两个 Skill，把其余的不需要的 Skill 移到独立的备份目录。通过 skills.load.extraDirs 只在需要时才加载。
根因二：Session 历史膨胀——3 个 session 串联污染
usage.json 显示 session family 包含 3 个历史 instance：
sessionId: 3718d696-... ← 当前
sessionId: 6c317d37-... ← 历史1（可能包含上一篇文章的完整上下文）
sessionId: 66e0d9c4-... ← 历史2
3 个 session 串联在一个 family 中，意味着模型能看到跨越多次发布的所有历史。之前排查 session 目录时发现有 61 个 trajectory 文件、72 MB——虽然大多数不加载到主上下文，但 compaction 过的摘要版本会以输入 token 的形式消耗预算。
缓存读取 1616 万 token 这个数字就是证据。 OpenAI/Anthropic 的 prompt caching 是省钱机制（缓存命中便宜 90%），但 DeepSeek 价格低到这种差别可以忽略。真正浪费的是模型注意力——16M 缓存的旧内容，每一次请求都被重新计算注意力。
解决： contextWindow 从 1M token 降到 128k，reserveTokensFloor 从 35,000 降到 12,000。旧 session 超过 5MB 的备份并删除。
根因三：自动修复死循环——exec 75 次的真相
75 次 exec 调用里，正常发布流程只需要 3-5 次。多出来的 70 次是什么？
回顾当天的操作记录：
发布 → 45166 错误 → Agent 判断原因 → 修改文章 → 再发布 → 失败 → 再判断 → 再修改……
每一次循环不只是一次 exec——它是一整套工具调用链：
read（读错误）+ read（读文件）+ edit（修改）+ write（重写）+ exec（重新发布）+ read（检查新错误）
一条链下来就是 5-6 次工具调用。循环 5 次就是 25-30 次。循环 10 次就 50+。
全天的 token 时间线完美印证了这个模式：
Quarter 9 有 1,480,542 token，但 user 消息是 0——这 15 分钟完全是 Agent 自己在不停地读文件、改内容、重新发布，没有等用户输入。
Quarter 13 的 453 万 token 中，input 占了 349 万——说白了就是 Agent 把大量错误历史和文章内容重新喂给了模型。
解决：发布失败上限 3 次。 第 3 次后强制停止，不允许 Agent 继续自己改自己试。这条已写入 SOUL.md。同时制定了错误分类：权限类（401/403/Token）直接停，不碰文章；格式/编码类允许看一次、改一次。
根因四：45166 误判——半个月的错误归因
关于 45166 的排查，我在之前的文章里详细写过。但 usage 数据给了一个新视角。
在把 “45166 由 Markdown 语法触发” 这个假设写进 SOP 之前，Agent 每次遇到 45166 的操作链是：
- 怀疑 frontmatter 有问题 → 修改
- 怀疑分隔线有问题 → 删除
- 怀疑链接格式有问题 → 移除
- 怀疑字数超限 → 大幅删减
每一步都是 5-6 次工具调用。而这种暴力删改的结果是什么？没有一次成功修复过。
直到 7 月 28 日，一篇包含所有"禁止"语法（6 个 ##、9 个 ---、9 个链接）的文章发布成功，才证伪了之前的假设。
修正后的流程：45166 → 先查编码 → 查 Unicode → 查 HTML 渲染 → 跟成功样本对比 → 最后才考虑删内容。禁止一看到错误就改文章内容。
根因五：Memory Search 空跑
Memory Search 通过 Embedding 向量搜索在记忆文件里找相关内容。DeepSeek API 不提供 /embeddings 接口，每次查询都是 HTTP 404 再加一次重试。
虽然 query 次数不多（工具统计中 memory_search 只调了 2 次），但关闭它之后少了不必要的 API 往返和延迟累积。
优化结果
调整后的第一次发布就是今天：
| 指标 | 优化前（7/29） | 优化后（预期） |
|---|---|---|
| 模型调用 | 239 次/天 | 30-60 次/天 |
| 总 token | 29.18M | 1-3M |
| 上下文窗口 | 1M | 128k |
| Session 文件 | 61 个 / 72MB | 5 个活跃 |
| Skill 注入 | 49 个 | 按需加载 |
| 单次发布 API | 70-80 次 | 10-20 次 |
| 45166 处理 | 猜测 + 循环改 | 5 步排查，不动正文 |
| 自动修复上限 | 无 | 3 次死线 |
| Memory Search | 404 空跑 | 关闭 |
六条省钱建议
如果你也在用 OpenClaw 或类似 Agent 框架做自动化任务，这几条可能帮你省不少：
1. 导出 usage.json 看数据。 openclaw usage export 能导出完整的 token 时间线。先看峰谷分布（哪些时段烧最多），再看工具调用占比（哪种调用最多），最后看系统提示词大小（引导文件 + Skill 占了多少）。数据不会骗你。
2. Skill 按需加载，别全开。 49 个 Skill 全注入约 10,000 字符，如果你是每天只用 2-3 个 Skill 的场景，迁出不需要的。workspace/skills 优先级最高，可以用它做开关：需要的放进去，不需要的移走。
3. 新任务开新 session，别混用。 不要在一个 session 里写文章、改 SOP、修 bug、发布全干了。每件事单独开 session，不用的关掉。session 里的每一条历史都是下一个任务的噪音。
4. 给 Agent 设死线。 自动修复是双刃剑。设 3 次上限——超过没解决就不是 Agent 自己能处理的事。同时按错误码分类，权限类错误直接停（跟文章内容无关，改了也没用）。
5. 大窗口不是免费的。 contextWindow 从 1M 降到 128k。对于单任务操作，128k 绰绰有余。更高的窗口容量 = 更晚触发压缩 = 压缩时已有大量噪音。
6. 检查 Embedding 服务。 如果你的模型提供商不支持 embedding，Memory Search 就是在空跑。
关键结论
- 239 次调用、2900 万 token 的根因不是模型贵，是行为失控——Agent 一次小错误触发 20+ 次自修复循环
- 两个时段占全天 80% token——高峰期（Q9-14）完全是 Agent 自己跟自己较劲，用户消息为 0
- 49 个 Skill 全量注入 10,000 字符，只用 1 个，其余 48 个在白白稀释模型注意力
- exec 占 39%，正常发布只需 3-5 次，多出来的 70 次全是无效修复
- 45166 不要猜，按流程排查编码和渲染，不碰文章正文
- 设死线、看数据、清 session——三条铁律
参考来源
- 7/29 usage.json 完整导出数据（239 次调用，29.18M token）
- OpenClaw 2026.6.6 配置文档
- Session trajectory 分析（61 文件，72 MB）
- 45166 错误实战对比（solarized-light 模板，不同文章长度）
中国智能体开发者社区，聚焦智能体与大模型开发，提供前沿资讯、实用工具链、开源项目及行业案例。通过技术沙龙、开发者大赛等活动，促进经验交流与协作，助力开发者快速构建创新智能应用。
更多推荐
6
0- 0
已为社区贡献5条内容
所有评论(0)