为了省钱而强行砍掉 Token 响应长度，结果反而让任务总成本飙升
我最近研究了 GitHub Copilot 在优化成本时的几个实际操作，他们对待“效率”的逻辑很有意思：不能看单次调用，得看整个 Task 的生命周期。
最典型的反面教材就是像 RTK (Rust Token Killer) 这种工具。这种工具的逻辑是直接截断 Shell 输出，但在 Copilot 的基准测试中发现，一旦截断的内容包含关键报错或状态，模型会触发“恢复机制”——要么重新跑一遍 ls 或 cat，要么去翻之前的历史记录。这种“局部省钱，全局浪费”的陷阱非常隐蔽。
基于这个结论，他们在 Copilot CLI 等产品里尝试了四种不牺牲质量的降本方案，我觉得最值得借鉴的是对“噪声”的定义。
一、区分“源代码类”与“构建类”输出
他们发现 install、build、test 和 lint 的输出里充满了重复的进度条、版本号等无用信息，这些可以大胆压缩。但 git diff 或者任意的命令执行结果（Arbitrary command results）如果被过度压缩，AI 很容易丢失上下文。
我在尝试优化自己的 Agent 链路时，可以参考这个策略：
- 高压缩区： 编译日志、依赖安装列表、重复的 Warning 提示。
- 低压缩区： 具体的 Error Stack Trace、文件内容、Diff 详情。
二、剔除无价值的格式化字符
很多 Tool Response 为了好看会加上大量的 Markdown 装饰符或者冗余的提示语。对于人类来说这叫“用户体验”，但对于 LLM 来说，这些字符除了占 Token 没有任何语义贡献。直接把这些去掉，对任务成功率几乎零影响，但能实打实地省钱。
三、精简指令集
这部分比较微妙，就是在不改变模型行为的前提下，缩短 System Prompt 或 Tool Description。这需要大量的 A/B Test，因为少了一个词可能导致模型在特定边缘 case 下失效。
四、预置背景工作，减少检索步数
与其让模型在执行过程中发现缺信息 → 调用检索工具 → 获取信息 → 执行，不如在启动任务前就把必要的背景上下文直接推给它，省掉一次往返。
如果你现在也在做 AI Coding Agent 的成本优化，建议不要盯着单次 API 的 usage 看，而是记录一个任务从 User Request 到 Final Result 的总 Token 消耗。
我建议的排查逻辑是这样的：
1. 统计任务失败率 → 检查是否有模型因为信息不足而重复执行相同命令的情况。
2. 如果有，说明你的压缩策略太激进，需要把相关命令（比如 git diff 或特定报错日志）加入白名单。
3. 检查 Tool Response 中是否包含大量重复的 UI 装饰符，直接在后端拦截并剔除。
总之，AI 编码的效率不等于 Token 的最少化，而应该是「上下文密度」的最大化。
