一个程序员在周五下午检查CI流水线账单时，发现上个月某个自动打标签的Agent悄悄烧掉了相当于三台按需GPU实例的成本。这不是虚构场景，而是任何在持续集成里跑大模型代理的团队迟早会撞上的现实——那些按计划默默执行的作业，把成本堆在没人注意的角落。
GitHub最近公开了他们在自有仓库里运行代理工作流时削减Token用量的实战结果：通过裁剪未使用的MCP工具、用gh CLI命令替换MCP调用、以及部署每日审计和优化代理，最高记录到62%的消耗降幅。这个数字背后是一套完整的可观测性和自动化优化回路，对于同样在CI环境里部署LLM Agent的团队来说，每一步都有可复制的价值。
整套方案的第一块基石是统一度量。GitHub让所有Agent调用都经过一个API代理层，每次运行输出一份token-usage.jsonl产物文件，以单一标准化格式记录输入Token、输出Token和缓存Token，覆盖Claude CLI、Copilot CLI和Codex CLI三套执行环境。这解决了不同客户端各自上报、数据口径不一致的常见痛点。
在此基础上，团队定义了一种名为“有效Token”（ET）的指标，专门用来跨模型层级比较成本。计算规则很简单：输出Token乘以4倍权重，缓存读取乘以0.1倍权重，再乘以模型系数——Haiku为0.25、Sonnet为1.0、Opus为5.0。这套加权体系意味着ET下降10%就等于成本下降10%，不管底层换用哪个模型，管理者看到的是一个稳定映射到账单的业务指标。
指标有了，谁来盯着？GitHub部署了两个代理来驱动优化循环。第一个是“每日Token用量审计员”，按工作流汇总消耗、标记异常运行、揪出最烧钱的作业。当审计员点亮某个工作流后，第二个代理“每日Token优化器”随即启动：它读取源码和近期日志，在GitHub上开一个Issue，直接附上具体的修复方案。有趣的是，这两个代理自身也会出现在同一份日报里，构成了一个自己查自己的自指回路。
在优化器发现的所有低效模式中，最普遍的一类是未使用的MCP工具。LLM API本身是无状态的，代理运行环境必须在每次请求中携带完整的工具模式定义，而一个挂着40个工具的GitHub MCP服务器，每轮对话就要往上下文里塞进10到15KB的模式数据。在GitHub的冒烟测试工作流中，单单删掉那些从未被调用的工具条目，每次调用的上下文就减少了8到12KB。
另一种更激进的替代策略是直接绕过MCP。对于拉取PR差异和获取文件内容这类高频操作，团队换成了gh CLI命令，要么在Agent启动前把文件预下载到工作区，要么在运行时通过一个透明的HTTP代理完成，这个代理层还能把认证Token和Agent本体隔离开来，安全边界更清晰。
效果曲线可以画出来了。横跨十几个生产工作流的统计显示：Auto-Triage Issues在109次修复后运行中稳定保持62%的ET降幅；Security Guard降了43%；Smoke Claude降了59%；Daily Community Attribution改善了37%。唯一一个ET上升5%的是Contribution Check，GitHub把原因归结为工作负载结构向更大PR偏移，而不是优化策略本身出了问题。
MCP裁剪也有它的天花板。Daily Community Attribution这个工作流挂着8个从未调用的GitHub MCP工具，在全量运行中一次都没碰过，但移除这些工具后ET纹丝不动。GitHub在公开记录里写道，工具清单在这个工作流的整体上下文中占比实在太小。换句话说，当上下文的大头是业务数据本身，工具模式的KB级削减就起不了波澜。
如果把视野拉宽，Anthropic和OpenAI都在提示缓存上各自发力，LangChain也提供了基于回调的Token追踪能力。GitHub真正拿出来的增量是这套审计再优化的闭环：用代理层可观测性加上能自动提Issue的优化器代理，形成一个不停转的改进飞轮。审计员和优化器如今已经直接交付在gh-aw CLI工具里。
最让人产生紧迫感的或许是GitHub写在公开记录里的那句话——最便宜的LLM调用，就是你压根没发出去的那一次。这个朴素的道理在代理工作流里尤其扎心，因为Agent会自动产生大量中间调用，开发者往往要到月底看账单才意识到那些静默燃烧的Token到底有多少。现在，至少有一份jsonl产物的记录和两个自动开Issue的代理，帮你在成本不可控之前把问题摆到明面上。
热门跟贴