git log 让你的智能体消耗了 624 个 token，但它只需要 55 个。以下是“罪魁祸首”名单

我花了一周时间记录我的编程智能体运行的每一个 shell 命令，并测量原始输出的 token 成本与智能体实际使用的 token 数量之间的差异。大多数 CLI 工具是为人类在终端中阅读而设计的，而不是为按 token 计费的 LLM 设计的。 最严重的“罪魁祸首” | 命令 | 原始 token 数 | 智能体实际需求 | 压缩后 | | :- | :- | :- | :- | | `git log` | 624 | 最近 3 次提交 + 变更文件 | 55 (-91%) | | `git diff` | 2,400+ | 变更行 + 文件列表 | ~320 (-87%) | | `npm test` (200 个通过) | 3,100+ | 通过/失败摘要 + 失败详情 | ~180 (-94%) | | `cargo build` (无错误) | 1,800+ | 仅错误/警告 | ~90 (-95%) | | `docker build` | 5,000+ | 最终镜像 + 错误 | ~150 (-97%) | | `ls -la` (大目录) | 800+ | 文件树 | ~120 (-85%) | | `git status` | 340 | 暂存/未暂存/未跟踪文件 | ~60 (-82%) | 这加起来很快。一次典型的 30 分钟会话会运行 40-60 个 shell 命令。平均每个命令产生 1,500 个 token 的原始输出，仅 CLI 噪声、冗长的构建日志、绿色对勾和下载进度条就会消耗 60,000 到 90,000 个 token。 为什么这比你想象的更重要 每一个 noisy shell 输出的 token 都会占用上下文窗口的空间。这意味着智能体无法使用这部分空间来推理你的实际代码。我曾见过智能体因为 `npm install` 在任务中途向上下文转储了 8,000 个 token 的依赖解析信息，而丢失了对多步骤重构计划的跟踪。 我对此做了什么 我为 34 个类别中的 95 多个 CLI 命令编写了基于模式的压缩器。确定性的模式匹配，相同的输入总是在微秒级产生相同的压缩输出。 规则很简单： * 剥离进度条、旋转器、下载指示器 * 合并重复的成功行（`✓ test passed` x200 → `200/200 passed`） * 保留所有错误和警告的原文 * 保持结构（文件路径、行号、退出码） 它作为一个透明的 shell 钩子运行。你的智能体像往常一样运行 `git log`，然后获得压缩后的版本。无需更改工作流。 在你的工作流中，哪些 CLI 命令消耗的 token 最多？