这项工作对于所有在持续集成（CI）环境中运行大语言模型（LLM）Agent 的团队都具有参考价值，因为定时执行的自动化任务往往会在不易察觉的情况下持续累积成本。GitHub 会将所有 Agent 调用统一通过一个 API 代理转发，并为每次运行生成一个 token-usage.jsonl 文件，以统一格式记录输入 Token、输出 Token 和缓存 Token 的使用情况，适用于 Claude CLI、Copilot CLI 和 Codex CLI。
为了能够跨不同模型进行成本比较，团队设计了一项名为“等效 Token（ET）”的指标。该指标将输出 Token 按 4 倍权重计算，将缓存读取 Token 按 0.1 倍权重计算，然后再根据模型类型应用不同的系数：Haiku 为 0.25 倍，Sonnet 为 1.0 倍，Opus 为 5.0 倍。按照这种计算方式，无论使用哪种模型，ET 下降 10% 都对应着约 10% 的成本下降。
整个优化闭环由两个 Agent 工作流驱动。“每日 Token 使用审计器”负责按工作流汇总资源消耗、标记异常运行情况，并找出成本最高的任务。当审计器发现某个工作流值得关注时，“每日 Token 优化器”会读取相关源码和近期日志，自动创建 GitHub Issue，并提出具体的优化建议。这两个 Agent 本身的消耗情况也会被纳入同一份日报统计。
优化器发现的最常见低效来源是未被使用的 MCP 工具。由于 LLM API 本质上是无状态的，每次请求都需要携带工具 Schema，因此一个包含 40 个工具的 GitHub MCP Server，每轮交互可能会额外增加 10 KB 至 15 KB 的 Schema 内容。在 GitHub 的冒烟测试工作流中，仅仅删除未使用的工具定义，就能让每次调用的上下文减少约 8 KB 至 12 KB。
团队还将获取 Pull Request Diff 和文件内容等操作，从 MCP 调用改为直接使用 ghCLI 命令。这些数据要么在 Agent 启动前预先下载到工作目录中，要么通过透明 HTTP 代理在运行时获取，从而避免将认证 Token 暴露给 Agent。
在十多个生产环境工作流中，优化效果十分明显。Auto-Triage Issues 在修复后的 109 次运行中持续实现了 62% 的 ET 降幅，Security Guard 降低了 43%，Smoke Claude 降低了 59%，而“每日社区归因”也实现了 37% 的改善。唯一出现反向变化的是 Contribution Check，其 ET 增加了 5%。GitHub 认为，这并非优化失效，而是因为工作负载发生变化，处理的大型 Pull Request 数量有所增加。
不过，团队也指出了 MCP 精简策略的局限性。以“每日社区归因”为例，该工作流包含 8 个未使用的 GitHub MCP 工具，并且整个运行过程中从未调用过这些工具，但即便将其移除，ET 指标也没有下降。GitHub 对此解释道：“在这个工作流中，工具清单只占整体上下文中很小的一部分。”
目前，Anthropic 和 OpenAI 都提供 Prompt 缓存功能，而 LangChain 也支持基于 Callback 的 Agent Token 追踪机制。GitHub 的创新点则在于构建了一套“审计——优化”闭环，将代理层的可观测性与能够自动创建 Issue 的优化 Agent 结合起来。目前，Auditor 和 Optimiser 已经作为 gh-awCLI 的组成部分提供给用户使用。GitHub 在文章中写道：“最便宜的一次 LLM 调用，就是根本不发生的那一次调用。”
GitHub 表示，下一阶段的重点将转向工作流组合层面的分析，寻找代码仓库内多个工作流之间重复读取的数据和可共享的中间产物，从而进一步降低整体 Agent 工作流的运行成本。
原文链接：
GitHub Slashes Agent Workflow Token Spend up to 62% with Daily Audits and MCP Pruning - InfoQ(https://www.infoq.com/news/2026/05/github-agentic-token-savings/)
会议推荐
企业级 Agent 落地，绕不开 4 个真实的工程问题！如何在 Agent 安全性和可用性之间找到平衡点？Agent 需要什么样的记忆系统才能真正理解上下文？如何通过算法压榨实现智力增量与成本控制的极致平衡？多 Agent 协作，如何做到可观测、可治理、可控制？6.26-27 AICon 上海站，国内头部公司的 Agent 实践，一次说透。
