Token 体量审计

解决什么问题

在本地堆积了多个 Agent 技能后，上下文窗口很容易被一些「偏胖」的技能挤占，但我们往往缺乏判断依据。系统日志里的 session_usage 或 traces 都是请求级的，并没有按 skill 维度的真实 token 账本，这导致工程师很难快速回答：哪些技能单次注入的体量最大？

top-token-consuming 提供了一种静态审计的视角。它不求还原真实账单，而是通过绝对阈值帮你揪出那些大概率吃 token 的「大块头」，让上下文治理有据可依。

工作原理与核心能力

技能采用「触发 → 声明 → 授权」的严谨工作流。在获得你的显式授权前，它绝不扫描任何文件；扫描过程全程只读，不修改、不移动任何内容。

授权通过后，它会执行以下关键步骤：

• 体量估算：以单个技能目录（包含 SKILL.md、references/ 与 scripts/）的静态体量，作为单次触发的预估 token。
• 范围过滤：解析 usage-log.json，基于 recentDates 过滤并统计特定时间范围内的使用天数。
• 阈值标红：当单次预估 token 超过设定的绝对阈值时，在输出的 Markdown 排行表中标记为异常（🔴）。

你可以直接用自然语言下达指令（例如「查一下 token 消耗在 2000 的 skill」），Agent 会自动提取参数换算后传入脚本。

适用边界与注意点

• 这是体量估算，非真实账单：由于本地没有按技能维度的真实计费数据，结果仅供排查体量风险，真实消耗请以模型供应商账单为准。
• 老数据可能欠计数：usage-log.json 仅保留近期活动日期，对于过老的时间区间（如半年前），统计可能不准确。
• 只针对当前安装：已卸载的历史技能不在扫描范围内。