我审计了 73 条公开的 Agent 轨迹中的 token 浪费——74% 存在可测量的浪费（开源工具，本地运行）

我审计了 73 条公开基准测试的 Agent 轨迹，检查其中的 token 浪费情况——其中 74% 存在可测量的浪费。随后我运行了实际的 Agent 来验证。chewme-audit（MIT 许可）是我构建的一个 CLI 工具，它读取 Agent 轨迹——包括 Langfuse、LangSmith、纯 JSONL 以及 Claude Code 的转录文件——并报告 token 在哪里被浪费，按各提供商的定价计算费用，且为每种浪费模式提供可直接复制粘贴的修复方案。它完全在本地运行：不调用任何 API，不上传任何数据。安装方式：`pip install chewme-audit`，然后运行 `chewme-audit your_traces.jsonl --provider deepseek` **最典型的案例：** 一条轨迹在达到步数上限之前，重复发送了 283 次相同的格式错误的编辑命令。我应用了推荐的去重修复方案，然后用真实的模型调用重新运行：循环在下一次调用时就被打破，Agent 重新开始调查真正的 bug。该轨迹上的浪费下降了 77%（13,193 → 3,041 tokens），并附带了防篡改的 SHA-256 校验凭据来证明结果。 **随后我在一个真实任务上运行了实际的 Agent：** - **单个 Agent：** 其输入/输出中有 35% 是重复验证——同一个 "查找文件" 的脚本被重复运行了 7 次。能力不错，但过于多疑。 - **4 个相同的 Agent，执行相同任务，没有协调器：** 浪费率在 15–37% 之间。其中一个从未完成任务。另一个用 `head -3` 粗略浏览文件后，误将一个 60 行的 docstring 当作空壳文件，删除了 117 行真实文档（根本原因分析已提交到 Git 中的详细报告里） - **一次调试运行以 $0.013 的成本通过了 12/12 的测试**——但轨迹显示修复实际上是通过一次意外的 `git checkout --` 实现的（重新运行一次，以 $0.0077 的成本干净地通过了 12/12）。仅凭通过/失败结果会认定第一次运行是成功的；但轨迹不会说谎。 **诚实的局限性：** 它读取的是轨迹导出文件，因此缓存行为和推理 token 的超额消耗需要查看你的 API 日志，报告中会明确说明这一点，而不是猜测。除非你提供了日志，否则所有美元金额都标注为估算值。74% 这个数字来自基准测试轨迹；基准测试中的 Agent 比生产环境中的 Agent 更容易陷入循环，所以你自己的轨迹才是真正的检验标准。用你自己的轨迹试一下，然后告诉我结果。我特别好奇重复验证的模式是否在其他场景中也占主导地位。