Token 浪费审计

要解决什么问题

在 QClaw / OpenClaw 上跑长会话、挂多个 Skill 时，账单往往只告诉你「用了多少 Token」，却很难回答：浪费发生在哪一类上下文、哪一段会话、哪份指令里。重复灌入的大段 Skill 提示、缓存命中率差的长上下文、未压缩的巨型会话、中途截断的生成，都会把 input/cache 成本悄悄拉高，而人工翻 .jsonl 或逐份量 SKILL.md 既不系统，也容易漏掉跨 Skill 的重复块。

技能如何工作

Token 浪费审计把三类零额外 API 成本的数据源对齐到同一套浪费维度上：

• openclaw gateway usage-cost --json：按日的 input / output / cache 汇总
• 本地 Session .jsonl：逐条消息与 tool-call 粒度
• 各 Skill 的 SKILL.md：提示词体积与跨文件重复检测

报告按维度给出可操作的判定逻辑，例如：

| 维度 | 含义（简述） |
|------|----------------|
| W01 | 缓存效率低：cacheRead / total 失衡，上下文相对产出过大 |
| W03 | Skill 提示臃肿：单份 SKILL.md 超过约 20KB |
| W04 | 跨 Skill 提示冗余：多份文件中出现重复块 |
| W05 | 会话膨胀：单会话超过约 100K tokens 且近期未压缩 |
| W06 | 异常中止：助手消息在生成中途被截断 |

输出为匿名化报告：技能名、Agent、会话标识会被哈希或替换为通用标签，并附带针对上述维度的优化量级估算，便于你按优先级改 prompt、拆 Skill 或做会话压缩策略。

边界与注意点

• 只读：不修改会话文件、Skill 文件或系统配置。
• 隐私：报告仅含 Token 指标与浪费估计，不抽取、不复现对话正文。
• 判定阈值（如 20KB、100K、cache 比例）来自技能内置规则，适合作为审计起点；落地前仍需结合你的业务上下文与模型定价自行校准。