提高GitHub Agentic Workflows中的令牌效率

提高 GitHub Agentic Workflows 中的 token 使用效率

URL 来源: http://github.blog/ai-and-ml/github-copilot/improving-token-efficiency-in-github-agentic-workflows/

发布时间: 2026-05-07T16:00:00-07:00

GitHub Agentic Workflows 就像一支清扫街道的团队，负责清理您仓库中的小问题。这些团队显著提升了仓库的整洁度和质量，但与所有代理工作一样，成本正成为开发者日益关注的问题。由于像代理工作流这样的 CI 任务是自动调度和触发的，因此成本可能在不知不觉中累积。

值得庆幸的是，让自动化更高效比优化交互式桌面会话要容易得多。开发人员会话中的工作难以预测，而代理工作流的工作则完全由 YAML 文件定义，并且每次执行时都重复进行。

由于我们在自己的 GitHub 仓库中维护和使用 GitHub Agentic Workflows，我们对 token 的使用效率同样关注，就像我们的用户一样。因此，在 2026 年 4 月，我们开始系统地优化许多我们每天依赖的工作流的 token 使用量。本文将介绍我们如何监控、应用优化措施以及初步结果。

记录 token 使用情况

我们在仓库中依赖数百个代理工作流来进行维护和 CI。所有工作流都作为 GitHub Actions 运行，并受到真实的 API 速率限制。我们一边飞行一边建造飞机，同时消耗着大量的燃料。

在优化我们的 token 消耗之前，我们需要了解 token 是如何被使用的。我们面临的第一个挑战是，每个代理框架（Claude CLI、Copilot CLI、Codex CLI）生成的日志格式不同，并且历史运行的使用数据可能不完整。幸运的是，代理工作流的安全架构使用了一个 API 代理来防止代理直接访问身份验证凭据。这个代理使我们能够以单一标准化格式捕获所有运行中的 token 使用情况，无论使用的是哪个代理框架。

现在，每个工作流都会输出一个 token-usage.jsonl 文件，其中每条记录对应一次 API 调用，包含输入 token、输出 token、缓存读取 token、缓存写入 token、模型、提供商和时间戳。将这些数据与工作流的其余日志结合，我们可以从历史角度查看 token 的典型消耗方式，并为未来的运行进行优化。

工作流优化工作流

有了 token 数据后，我们构建了两个每日优化工作流。

每日 Token 使用审计器 会读取最近工作流运行的 token 使用工件，按工作流汇总消耗情况，并发布结构化报告。它的任务是标记任何近期 token 使用显著增加的工作流，显示最昂贵的工作流，并记录异常运行（例如，通常在四个 LLM 轮次内完成的工作流却用了 18 轮）。

当审计器标记某个工作流时，每日 Token 优化器会查看该工作流的源代码和最近的日志，创建一个 GitHub 问题，描述具体的低效问题并提出具体的优化建议。优化器发现了许多我们原本可能会忽略的低效问题。

当然，审计器和优化器本身也是代理工作流，它们的 token 使用也会出现在每日报告中，从而形成一个小的良性循环。

删除未使用的 MCP 工具

根据我们最初的审计器和优化器结果，最常见的低效问题是未使用的 MCP 工具注册。

由于 LLM API 是无状态的，代理运行时通常会在每次请求中包含 MCP 工具函数名称和 JSON 模式。实际上，这意味着完整的工具集可能成为每次调用的上下文的一部分。对于一个包含 40 个工具的 GitHub MCP 服务器，这可能为每个轮次增加 10-15 KB 的模式数据。如果代理只使用两个工具，那么剩下的 38 个工具就是每次请求的纯开销。

工作流作者自然会从完整的工具集开始，因为这是阻力最小的路径，代理可以自行决定需要哪些工具。但随着时间推移，大多数工作流依赖于一组狭窄且稳定的工具。优化器通过交叉引用工具清单和实际工具调用来识别这种模式，并建议从配置中删除未使用的工具。

在我们的烟雾测试工作流中，从 MCP 配置中删除未使用的工具减少了每次调用的上下文大小 8-12 KB，每次运行节省了几千个 token，而行为没有任何改变。

用 GitHub CLI 替代 GitHub MCP

删除未使用的 MCP 工具是一个相对简单的改进。更大的结构性机会在于用 GitHub CLI 调用替换 GitHub MCP 调用，用于数据获取操作，例如检索 pull request 差异、文件内容和评审评论。

这一更改不仅减少了未使用工具的开销，还因为 MCP 工具调用不仅仅是数据检索，还包括推理步骤。代理必须决定调用工具、制定其参数，并将其输出作为上下文的一部分接收。这是一个完整的 LLM API 往返调用，消耗了工具使用 JSON 模式的 token、参数块和响应。相比之下，调用 gh pr diff 是一个确定性的 HTTP 请求到 GitHub 的 REST API，无需涉及 LLM。

我们采用了两种策略进行迁移：

预代理数据下载。对于代理始终需要的数据，例如 pull request 差异或更改文件列表，我们在工作流中添加了设置步骤，在代理启动之前运行 gh 命令并将结果写入工作区文件。代理读取这些文件而不是进行 MCP 调用。这消除了工具调用的开销，并允许代理利用其在 bash 脚本方面的广泛训练来高效处理数据。

代理内 CLI 代理替换。在某些情况下，代理在运行时才确定要获取的内容，因此无法进行预下载。在这种情况下，我们依赖一个轻量级的透明 HTTP 代理，将 CLI 流量路由到 GitHub 的 API 服务器，而不会向代理暴露身份验证令牌。代理运行 gh pr view –json 并接收结构化数据，就像用户从终端获得的一样。这减少了令牌的使用，同时满足了代理对零秘密安全性的要求。

这些技术共同作用，将大部分 GitHub 数据获取操作移出了 LLM 推理循环。

衡量效率提升并不容易

当我们开始优化工作流时，遇到了一个更复杂的问题：如何判断某项更改是否提高了效率，或者只是让工作流做了更少（甚至更差）的工作？

这里有三个混淆因素。

并非所有令牌都同等重要。在 Claude Haiku 和 Claude Sonnet 上运行相同的工作流会产生类似的令牌计数，但成本差异很大。Haiku 每个令牌的成本大约是 Sonnet 的 1/4，因此切换模型的工作流在原始令牌计数上看似没有变化，但实际上代表了显著的成本降低。为了解决这个问题，我们使用了一个有效令牌（ET）指标，该指标为每种类型的令牌应用模型乘数：

ET = m × (1.0 × I + 0.1 × C + 4.0 × O)

其中 _m_ 是模型成本乘数（Haiku = 0.25×，Sonnet = 1.0×，Opus = 5.0×），_I_ 是新处理的输入令牌，_C_ 是缓存读取令牌，_O_ 是输出令牌。输出令牌权重为 4 倍，因为它是所有主要提供商中最昂贵的令牌类型。缓存读取令牌的权重仅为 0.1 倍，因为它们以远低于新鲜输入的成本从缓存中提供。此公式通过标准化不同模型层级的消耗，使得 10% 的 ET 减少意味着真实的 10% 成本减少，无论使用哪个模型。

工作负载是一个实时存储库。据我们所知，目前没有可用于优化我们令牌使用的代理工作流基准。当我们开始查看工作流的令牌使用情况时，发现一次运行可能处理一个五行修复，而下一次运行可能处理一个 200 行的拉取请求。第一次运行自然使用较少的令牌，但这并不是由于效率的突然变化。原始令牌计数可能会将工作负载的变化与效率波动混淆。我们尝试通过跟踪 LLM API 调用次数与令牌计数来规范化这一点；每次运行中恒定的 LLM 轮次和下降的每次调用令牌数表明了真正的效率提升。两者同时下降可能表示完成的工作量减少。

质量是否发生变化？理解输出质量是最难考虑的因素。一个较轻量的模型运行更受限的工作流可能会产生较低质量的输出。我们查看了过程级别的信号，例如每次 LLM 调用的输出令牌、每次运行的轮次计数和工具调用完成率，以近似评估质量。对于我们的优化 Smoke Copilot 工作流，在优化期间，这三个指标在整个优化过程中保持稳定，尽管令牌消耗减少。工作流在优化前后每次运行大约完成五次 LLM 轮次。当然，这些都是过程信号，而不是结果信号。由于没有绝对正确的“正确性”标准，我们无法直接观察质量是否提高、下降或保持稳定。衡量每单位正确工作的令牌消耗需要额外的工具和思考。

初步结果

在 gh-aw 和 gh-aw-firewall 存储库中的十几个生产工作流中部署审计器和优化器后，我们下载了每个工作流优化前后的令牌使用工件，并计算了每次运行的 ET。12 个工作流中有 9 个接受了优化器推荐的更改。我们仅包括优化前后至少有八次运行的工作流的结果。这些工作流是：自动分类问题、每日编译器质量、社区归属、安全卫士和 Smoke Claude。

Auto-Triage Issues 在 109 次优化后运行中显示出持续的 62% 的减少。Daily Compiler Quality 在 12 次优化后运行中显示出 19% 的改进，Daily Community Attribution 在 8 次优化后运行中显示出 37% 的改进。在 gh-aw-firewall 存储库中，审核每个拉取请求的安全敏感更改的安全卫士，以及测试防火墙 Claude CLI 路径的集成测试 Smoke Claude，具有最多的优化后运行，并分别显示出 43% 和 59% 的改进。

运行频率与每次运行的节省同样重要。Auto-Triage Issues 在每个新问题上触发（平均每天 6.8 次运行，最多 15 次），而 Daily Compiler Quality 每天最多运行一次。62% 的节省和每天 6.8 次运行迅速累积：在观察期内，假设优化前的速率，Auto-Triage 的优化总共节省了约 7.8 M ET。安全卫士和 Smoke Claude 运行得更加频繁。在优先优化哪些工作流时，运行频率与每次运行的消耗同样重要。

需要注意的是，并非代理推荐的所有优化都能转化为可测量的 ET 节省，尤其是在实时存储库上短期观察窗口中，工作负载每天都在变化。例如，贡献检查工作流的 ET 增加了 5%，我们将在下面详细讨论。

总结

基于这些结果，我们强调了三种模式。

许多代理回合是确定性的数据收集。Auto-Triage Issues 在 gh-aw 中显示出最强的持续改进（62 次修复后运行中减少了 44%），因为优化消除了结构性低效：许多代理回合被花在不需要推理的读取操作上，例如获取问题元数据和扫描标签。将这些读取操作移到代理启动前的预 CLI 步骤中，完全将其从 LLM 推理循环中移除。同样的模式推动了 Security Guard 在 gh-aw-firewall 中减少 60% 的成本：一个相关性门现在可以完全跳过不涉及安全敏感文件的拉取请求的 LLM 处理。最便宜的 LLM 调用是你没有进行的调用。

Contribution Check 展示了一个混淆因素：82–83% 的输入 token 是缓存读取（数据收集），但平均 ET 增加了 5%。这是由于工作负载的转移，而不是优化失败：在优化前的时期，41% 的运行处理小型拉取请求（ET < 100K），39% 处理大型拉取请求（ET > 300K）。而在优化后的时期，恰逢开发活动激增，工作流处理了 9% 的小型拉取请求和 65% 的大型拉取请求。输出 token（在 ET 公式中权重为 4×）增加了 14%，因为代理审查了更大的差异。优化可能提高了每回合的效率，但由于更重的工作负载转移，这种收益在总体数字中被掩盖了。

未使用的工具携带成本高昂。在被排除的 gh-aw 工作流中，Glossary Maintainer 是一个有教育意义的案例。一个单一工具——search_repositories——在一个运行中被调用了 342 次，占所有工具调用的 58%，尽管对于仅扫描本地文件更改的工作流来说，这个工具完全没必要。优化器建议将其从工具集中移除。在 gh-aw-firewall 中，Smoke Claude 的 -79% 减少部分是由于激进的 MCP 工具剪枝以及模型层级切换到 Haiku。Daily Community Attribution 工作流展示了这种方法的局限性：它配置了八个 GitHub MCP 工具，在整个运行过程中对它们中的任何一个都没有调用，但移除它们并未减少 ET。工具清单只是该工作流整体上下文的一小部分。

单个配置错误的规则可能导致失控的循环。同样在被排除的工作流中，Daily Syntax Error Quality 在优化前是项目中 ET 最高的工作流。根本原因是单行配置错误：工作流将测试文件复制到 /tmp/ 然后调用 gh aw compile *，但沙盒的 bash 允许列表仅允许相对路径的通配符模式。每次编译尝试都被阻止。由于无法使用所需的工具，代理陷入了一个 64 回合的回退循环，手动读取源代码以重建编译器本应告知的内容。对允许的 bash 模式的一个修复消除了该循环。我们没有足够的基线运行来精确量化改进，但问题的根源明确且修复方案清晰。

下一步是什么？

我们用于优化工作流的工具，包括 API 级别的可观察性、自动化审计工作流、MCP 工具剪枝和 CLI 替代，都已在 GitHub Agentic Workflows 框架中提供。另一个即将到来的优化是将单体代理重构为使用更小、更便宜模型的子代理团队。

下一步是从工作流级别的优化转向系统级别的优化。一个工作流运行实际上并不是一系列平坦的 API 调用序列。它是一系列事件链：短阶段的工作，如收集上下文、读取工件、失败后的重试或合成最终答案。一旦你能清楚地看到这些事件链，你就可以提出更好的问题。哪个事件链实际导致了高成本运行？哪些事件链主要是重复工作、阻塞工作或失败工作？哪些应该完全停止代理化并成为确定性的预步骤？

同样的逻辑也适用于组合级别。存储库不会孤立地运行一个工作流。它们运行一组经常在同一事件上触发、检查相同差异和日志并产生相邻判断的代理自动化。这意味着成本不仅仅是单个工作流的属性，也是组合中重叠的属性。我们接下来想要的分析是组合级别的：工作流在哪里重复读取，哪些工作流应该合并，以及哪些共享中间工件应该缓存而不是每次运行重新发现。

这些问题确实很难。测量有效吞吐量仍然需要尚未大规模存在的结果仪表化工具，而理解事件链和组合效率则需要比大多数系统今天收集的更丰富的血统数据。但这是重要的方向。代理级别的可观察性和优化工作流已经改变了我们开发和部署新的代理自动化的思维方式。我们从一开始就添加 token 监控，而不是事后修补，并且我们越来越多地从整个自动化舰队的可避免工作角度思考，而不仅仅是孤立的昂贵运行。

如果你在 CI 中运行代理工作流并想知道是否花费超出必要，第一步与我们相同：添加 API 代理，打开日志记录，并让数据告诉你应该关注哪里。

如果你想添加本文提到的工作流，只需使用 `gh-aw` CLI 将它们放入你的存储库：

gh extensions install github/gh-aw
gh aw add githubnext/agentic-ops/copilot-token-audit githubnext/agentic-ops/copilot-token-optimizer

将它们与现有的 CI 并行运行，可以立即获得使用情况的可见性，并帮助随着时间推移不断优化你的工作流。

我们很想知道其他人是如何解决这个问题的。请在 社区讨论 中分享您的想法，或者加入 GitHub Next Discord 的 #agentic-workflows 频道。

作者

微软研究院 高级首席研究员

高级研究工程师