GitHub 用每日审计和 MCP 精简，把 Agent 工作流 Token 成本最高降了 62%

AI资讯
1

GitHub 通过 Token 审计、优化 Agent 和 MCP 精简，将部分 Agent 工作流成本最高降低 62%。

原文标题：GitHub 通过每日审计与 MCP 精简，将 Agent 工作流 Token 成本最高降低 62%

原文作者：AI前线

冷月清谈：

GitHub 针对 CI 环境中持续运行的 LLM Agent 成本问题，搭建了一套统一的 Token 可观测与优化闭环。所有 Agent 调用都会经过 API 代理，并生成 token-usage.jsonl，记录输入、输出和缓存 Token。为便于跨模型比较，GitHub 设计了“等效 Token（ET）”指标，将不同 Token 类型和模型价格差异折算到统一口径。

这套机制由两个 Agent 工作流驱动：每日审计器负责汇总消耗、发现异常和高成本任务；每日优化器则读取源码与日志，自动创建 GitHub Issue 并给出优化建议。实践中，最常见的浪费来自未使用的 MCP 工具，因为每次请求都要携带工具 Schema，导致上下文变长。GitHub 通过删除无用工具定义、将部分 MCP 调用改为 gh CLI 或代理获取数据，显著降低了多个生产工作流的 ET 消耗。

在十多个工作流中，Auto-Triage Issues 降低 62%，Security Guard 降低 43%，Smoke Claude 降低 59%。但 GitHub 也指出，MCP 精简并非总能见效，若工具清单只占上下文很小比例，收益会有限。后续他们将关注多个工作流之间的数据复用和中间产物共享。

怜星夜思：

1、如果团队已经在 CI 里大量使用 Agent，最应该先优化 Token 成本，还是先优化任务成功率？
2、MCP 工具越多，Agent 能力真的越强吗？还是会因为上下文变长反而变笨？
3、GitHub 设计的“等效 Token（ET）”指标，适合其他公司直接照搬吗？
4、把 Pull Request Diff、文件内容等数据提前下载到工作目录，会不会带来新的安全或一致性问题？

原文内容

作者 | Mark Silvester
译者 | 马可薇

这项工作对于所有在持续集成（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 实践，一次说透。

今日荐文

图片
你也「在看」吗？👇

2

这个问题有点像问外卖平台先提配送速度还是先降补贴。小团队建议先别过度工程化，先确认 Agent 真能帮你省人力；大团队就必须两条线一起做，不然 CI 里每天自动跑，月底账单能让财务先觉醒。

3 个赞
3

ET 的价值在于让跨模型、跨工作流的成本比较变得简单。比如输出 Token 更贵、Opus 比 Haiku 贵很多，这些差异如果不折算，团队很难判断到底是哪条工作流在烧钱。不过权重需要随价格表更新，否则指标会失真。

1 个赞
4

我理解 MCP 工具有点像 IDE 插件：装一堆看起来很强，但真正每天用的就几个。插件太多会卡，工具太多也会让 Agent 的提示词变臃肿。最好的状态可能是按任务动态加载工具，而不是一次性全塞进去。

1 个赞
5

我觉得这事像考试前把资料打印出来：省得考场上到处联网查，但打印错版本就完蛋。所以关键不是能不能预下载，而是要有版本锁定、权限隔离和过期清理，不然省下的 Token 可能换来排查事故的加班。

3 个赞
6

针对“MCP 工具越多越好吗”，我觉得不是。工具多只是理论能力边界变大，但每轮都塞工具 Schema，会占上下文，也会增加模型选择工具时的干扰。像 GitHub 这篇里提到的未使用工具，实际就是负资产。

1 个赞
7

这个方案的好处是减少 MCP 调用和认证 Token 暴露，但它把问题转移到了数据准备阶段。企业落地时最好做快照机制，明确 Agent 看到的是哪一版 diff、哪些文件，避免出现“它分析得很认真，但分析的是上一个版本”的尴尬。

2 个赞
8

我会把 ET 当“公司内部统一货币”。但每家公司买模型的折扣、缓存命中率、调用模式都不一样，所以直接照搬 GitHub 的 4 倍、0.1 倍、5 倍可能不准。照搬框架可以，照搬数字要谨慎。

1 个赞
9

关于 ET 指标能不能照搬，我觉得思路可以学，权重未必能照抄。不同供应商的输入、输出、缓存价格比例不一样，模型价格也经常变。企业更应该建立自己的成本归一化指标，而不是只看原始 Token 数。

1 个赞
10

关于“先省钱还是先保证成功率”，我的看法比较现实：先把账单拉出来看。如果某个 Agent 每天烧很多钱但产出一般，那成本优化本身就是成功率优化的一部分，因为它能逼你删掉无用工具、减少噪声上下文，Agent 反而更容易做对事。

2 个赞