GitHub 智能体工作流就像一支街道清洁队，负责清理你仓库中的各种小问题。这些团队能显著改善仓库的卫生状况和质量，但和所有智能体工作一样，成本正成为开发者日益担忧的问题。而且，由于像智能体工作流这样的 CI 任务是自动调度和触发的，成本可能会在不知不觉中累积。

幸运的是，让自动化流程变得更高效，比让交互式桌面会话变得更高效要容易。开发者在会话期间所做的工作难以预测，但智能体工作流的工作完全在 YAML 中指定，并且每次执行都会重复。

因为我们在自己的 GitHub 仓库中维护和使用 GitHub 智能体工作流，所以我们和用户一样关心模型 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 的工作流，并记录异常运行（例如，某个通常只需 4 轮大语言模型交互就能完成的工作流，却用了 18 轮）。

当审计器标记出某个工作流时，每日 Token 优化器会查看该工作流的源代码和近期日志，创建一个 GitHub Issue，描述具体的低效问题并提出针对性的优化方案。优化器已经发现了许多我们原本可能会遗漏的低效问题。

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

消除未使用的 MCP 工具

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

由于大语言模型 API 是无状态的，智能体运行时通常会在每次请求中包含 MCP 工具的函数名和 JSON 模式。实际上，这意味着整套工具都可能成为每次调用上下文的一部分。对于一个包含 40 个工具的 GitHub MCP 服务器，每次交互可能会增加 10–15 KB 的模式数据。如果智能体只使用了其中两个工具，那么剩下的 38 个工具就成为了每次请求的纯额外开销。

工作流作者通常会从完整的工具集开始，因为这是阻力最小的路径，智能体可以自行判断需要哪些工具。但随着时间的推移，大多数工作流会依赖一个狭窄且稳定的工具集。优化器通过交叉比对工具清单与实际工具调用来识别这种模式，并建议从配置中剪除未使用的工具。

在我们的冒烟测试工作流中，从 MCP 配置中移除未使用的工具，将每次调用的上下文大小减少了 8–12 KB，每次运行节省了数千个模型 token，且行为没有任何变化。

用 GitHub CLI 替换 GitHub MCP

移除未使用的 MCP 工具是一个相对简单的优化。一个更大的结构性机会在于，将用于数据获取操作（如获取拉取请求差异、文件内容和审查评论）的 GitHub MCP 调用，替换为对 GitHub CLI 的调用。

这一改动不仅减少了未使用工具的开销，因为 MCP 工具调用除了数据检索之外，本身也是一个推理步骤。智能体必须决定调用该工具、构造其参数，并将接收到的输出作为上下文的一部分。这是一个完整的往返 LLM API 调用，会消耗用于工具使用的 JSON 模式、参数块以及响应的 token。相比之下，调用 `gh pr diff` 是一个确定性的 HTTP 请求，直接发送至 GitHub 的 REST API，完全不涉及 LLM。

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

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

智能体内部的 CLI 代理替换。在智能体需要在运行时决定获取什么内容的情况下，无法进行预下载。在这些情况下，我们依赖一个轻量级的透明 HTTP 代理，它将 CLI 流量路由到 GitHub 的 API 服务器，同时不向智能体暴露身份验证令牌。智能体运行 `gh pr view --json` 并获取结构化数据返回，就像用户在终端中操作一样。这减少了 token 使用量，同时没有损害我们对智能体零密钥的安全要求。

综合来看，这些技术将大部分 GitHub 数据获取操作移出了 LLM 的推理循环。

衡量效率提升并非易事

一旦我们开始优化工作流，就遇到了一个更微妙的问题：你如何知道一项改动是让事情变得更高效了，还是仅仅让工作流做了更少（或许也更差）的工作？

这里有三个干扰因素。

并非所有模型 token 都生而平等。在 Claude Haiku 与 Claude Sonnet 上运行相同工作流，产生的 token 数量相近，但成本却大相径庭。Haiku 每 token 成本约为 Sonnet 的四分之一，因此切换模型的工作流在原始 token 数量上看似不变，实则代表显著的成本降低。为衡量这一差异，我们采用有效 token（ET）指标，对每种 token 类型应用模型乘数：

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

其中 m 为模型成本乘数（Haiku = 0.25×，Sonnet = 1.0×，Opus = 5.0×），I 为新处理的输入 token，C 为缓存读取 token，O 为输出 token。输出 token 权重为 4 倍，因为它们是所有主流提供商中最昂贵的 token 类型。缓存读取 token 权重仅为 0.1 倍，因为它们从缓存中提供，成本仅为全新输入的一小部分。该公式将不同模型层级的消耗归一化，使得 10% 的 ET 降低意味着无论使用哪种模型，都代表真实的 10% 成本降低。

工作负载是一个活跃的代码仓库。据我们所知，目前没有可用于优化 token 用量的智能体工作流基准测试。当我们开始审视工作流的 token 用量时，发现某次运行中工作流处理了一个五行修复，而下次运行则处理了一个两百行的拉取请求。第一次运行自然使用更少的 token，但这种差异并非源于效率的突然变化。原始 token 数量可能将工作负载变化与效率波动混为一谈。我们尝试通过同时追踪 LLM API 调用次数与 token 数量来归一化这一影响；若每次运行的 LLM 轮次保持恒定，而每次调用的 token 数量下降，则表明真正的效率提升。若两者同时下降，则可能意味着完成的工作量减少了。

质量会变化吗？理解输出质量是最难考量的问题。一个更轻量的模型运行更受限的工作流，可能会产生质量更低的输出。我们通过流程层面的信号来近似评估质量，例如每次大语言模型调用的输出 token 数、每次运行的交互轮数以及工具调用完成率。对于我们优化后的 Smoke Copilot 工作流，在优化期间，即使 token 消耗量下降，这三项指标也保持稳定。该工作流在优化前后，每次运行大约需要五轮大语言模型交互即可完成。当然，这些是流程信号，而非结果信号。我们无法直接观察到质量是提升、下降还是保持稳定，因为不存在一个“正确性”的基准真相。要衡量“每单位正确工作的 token 数”，还需要额外的检测手段和思考。

初步结果

在将审计器和优化器部署到 gh-aw 和 gh-aw-firewall 仓库中的十几个生产工作流后，我们下载了每个工作流优化前后运行的 token 使用记录，并计算了每次运行的 ET 值。12 个工作流中有 9 个采纳了优化器推荐的更改。我们仅纳入在优化前后两个阶段均至少有 8 次运行记录的工作流结果。这些工作流包括：自动分类问题、每日编译器质量、社区归属、安全卫士和 Smoke Claude。

“自动分类问题”工作流在修复后的 109 次运行中，显示出 62% 的显著且持续的降低。“每日编译器质量”在修复后的 12 次运行中提升了 19%，“每日社区归属”在修复后的 8 次运行中提升了 37%。在 gh-aw-firewall 仓库中，“安全卫士”（负责审计每个拉取请求是否存在安全敏感变更）和“Smoke Claude”（一项集成测试，用于测试防火墙的 Claude CLI 路径）拥有最多的修复后运行次数，分别显示出 43% 和 59% 的提升。

运行频率与每次运行的节省量同等重要。自动分类问题（Auto-Triage Issues）会在每个新 issue 上触发（平均每天运行 6.8 次，最多 15 次），而每日编译器质量（Daily Compiler Quality）最多每天运行一次。62% 的节省量与每天 6.8 次的运行频率会迅速叠加：在观察期内，假设采用优化前的速率，自动分类的优化累计节省了约 780 万 ET（执行时间）。安全卫士（Security Guard）和烟雾测试 Claude（Smoke Claude）的运行频率更高。在确定工作流优化优先级时，运行频率与单次运行消耗同等重要。

需要注意的是，并非智能体推荐的每一项优化都能转化为可测量的 ET 节省，尤其是在实时仓库的短观察窗口内，工作负载每天都会变化。例如，贡献检查（Contribution Check）工作流的 ET 增加了 5%，我们将在下文详细讨论这一点。

要点总结

基于这些结果，我们重点指出三种模式。

许多智能体调用步骤是确定性的数据收集。自动分类问题（Auto-Triage Issues）在 gh-aw（GitHub Actions 工作流）方面表现出最显著的持续改进（修复后 109 次运行中降低了 62%），因为优化消除了结构性低效：许多智能体调用步骤花费在不需要推理的读取操作上，例如获取 issue 元数据和扫描标签。将这些读取操作移到智能体启动前的预智能体 CLI 步骤中，就将其完全移出了大语言模型的推理循环。同样的模式也推动了安全卫士（Security Guard）在 gh-aw-firewall 上实现 43% 的降低：现在，一个相关性门控机制会针对不涉及安全敏感文件的拉取请求，完全跳过 LLM。最便宜的 LLM 调用，就是你不发起的那个。

贡献检查（Contribution Check）揭示了一个干扰因素：82–83% 的输入 token 是缓存读取（数据收集），但平均执行时间（ET）却增加了 5%。这是由于工作负载变化，而非优化失败：在优化前阶段，41% 的运行处理的是小型拉取请求（ET < 100K），39% 处理的是大型拉取请求（ET > 300K）。优化后阶段恰逢开发活动激增，工作流处理了 9% 的小型拉取请求和 65% 的大型拉取请求。输出 token 在 ET 公式中权重为 4 倍，随着智能体审查更大的差异，输出 token 增加了 14%。优化可能提升了单轮效率，但向更重工作负载的转变掩盖了总体数据中的这一收益。

携带未使用的工具成本高昂。在被排除的 gh-aw 工作流中，术语维护器（Glossary Maintainer）是一个具有启发性的案例。一个单一工具——search_repositories——在一次运行中被调用了 342 次，占所有工具调用的 58%，尽管对于一个仅扫描本地文件变更的工作流来说，它完全是不必要的。将其从工具集中移除是优化器的建议。在 gh-aw-firewall 中，Smoke Claude 的 −59% 缩减部分归因于激进的 MCP 工具裁剪，同时将模型层级切换至 Haiku。每日社区归属（Daily Community Attribution）工作流展示了这种方法的局限性：它配置了八个 GitHub MCP 工具，但在整个运行过程中未对其中任何一个进行调用，然而移除它们并未减少 ET。工具清单仅占该工作流整体上下文的一小部分。

一条配置错误的规则就可能导致无限循环。此外，在被排除的工作流中，每日语法错误质量是该项目优化前ET（执行时间）最高的工作流。根本原因是一行配置错误：该工作流将测试文件复制到 `/tmp/`，然后调用 `gh aw compile*`，但沙箱的 bash 允许列表只允许相对路径的通配符模式。每次编译尝试都被阻止。由于无法使用所需的工具，智能体陷入了一个64轮的回退循环，在此循环中它手动读取源代码，以重构编译器本应告知它的信息。只需修复允许的 bash 模式即可消除该循环。我们没有足够的基线运行次数来精确量化改进效果，但问题现象很明显，修复方案也明确无误。

下一步是什么？

我们用于优化工作流的工具，包括 API 级别的可观测性、自动化审计工作流、MCP 工具剪枝以及 CLI 替代方案，现在都可以在 GitHub Agentic Workflows 框架中使用。另一个即将推出的优化措施是，使用更小、更便宜的模型将单体智能体重构为子智能体团队。

下一步是从工作流级别的优化转向系统级别的优化。一个工作流运行实际上并不是一个扁平的 API 调用序列。它是一个由多个片段组成的链条：即工作的短阶段，例如收集上下文、读取工件、失败后重试，或综合最终答案。一旦你能清晰地看到这些片段，就可以提出更好的问题。是哪个片段实际导致了高成本运行？哪些片段主要是重复工作、受阻工作或失败工作？哪些片段应该完全停止使用智能体方式，而变成确定性的前置步骤？

同样的逻辑也适用于项目组合层面。代码仓库并非孤立地运行单一工作流。它们运行着一整套智能体自动化流程，这些流程常常在相同事件上触发，检查相同的差异和日志，并生成相邻的判断。这意味着成本不仅仅是单个工作流的属性，也是整个项目组合中重叠部分的属性。我们接下来想要进行的是项目组合层面的分析：哪些工作流存在重复读取，哪些工作流应该合并，以及哪些共享的中间产物应该被缓存，而不是每次运行都重新发现。

这些悬而未决的问题确实很难。衡量有效吞吐量仍然需要结果检测手段，而这种手段在智能体CI工作流领域目前尚不具备大规模应用的条件；理解回合效率和项目组合效率则需要比大多数系统当前收集的数据更丰富的谱系数据。但这是至关重要的方向。代理级别的可观测性和优化器工作流已经改变了我们开发和部署新智能体自动化流程的方式。我们从第一天起就加入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 频道。

探索 GitHub Agentic Workflows 仓库 >

编者注：本文于2026年5月13日更新，以澄清部分缩减率数据。