提高 GitHub 代理工作流中的令牌效率

GitHub 的代理工作流（Agentic Workflows）就像一组街道清洁工，负责清理仓库中的小杂乱。这些工作流显著改善了仓库的卫生和质量，但与其他代理工作一样，成本已成为开发者日益关注的问题。由于 CI 作业会自动调度和触发，成本可能会在无形中累积。

幸运的是，使自动化更高效比优化交互式桌面会话更容易。开发者会话期间的工作难以预测，但代理工作流的工作完全在 YAML 中指定，并且每次执行都会重复。

GitHub 在自己的仓库中维护并使用 Agentic Workflows，因此与用户一样关心令牌效率。在 2026 年 4 月，他们开始系统性地优化许多日常依赖的工作流的令牌使用。

首先，他们需要记录令牌使用情况。每个代理框架（Claude CLI、Copilot CLI、Codex CLI）以不同格式输出日志，历史运行数据可能不完整。但代理工作流的安全架构使用 API 代理来防止代理直接访问身份验证凭据。这个代理使得能够以单一的标准化格式捕获所有运行的令牌使用。现在，每个工作流都会输出一个 token-usage.jsonl 工件，包含每条 API 调用的输入令牌、输出令牌、缓存读取令牌、缓存写入令牌、模型、提供者和时间戳。

有了令牌数据后，他们构建了两个每日优化工作流：每日令牌使用审计员和每日令牌优化器。审计员读取近期工作流运行的令牌使用工件，按工作流聚合消耗，并标记异常。优化器则查看被标记工作流的源代码和日志，创建 Issue 描述低效问题并提出优化建议。

根据初步结果，最常见的低效问题是未使用的 MCP 工具注册。由于 LLM API 是无状态的，代理运行时通常会在每个请求中包含 MCP 工具函数名称和 JSON 模式。对于包含 40 个工具的 GitHub MCP 服务器，每次交互可能增加 10–15 KB 的模式。如果代理只使用两个工具，其余 38 个就是纯粹的额外开销。在烟雾测试工作流中，移除未使用的工具将每调用上下文大小减少了 8–12 KB，每次运行节省了数千个令牌。

一个更大的结构性机会是将数据获取操作（如检索拉取请求差异、文件内容和审查评论）从 GitHub MCP 调用替换为 GitHub CLI 调用。MCP 工具调用除了数据检索外，还是一个推理步骤，消耗额外的令牌。而调用 'gh pr diff' 则是一个确定性的 HTTP 请求，无需 LLM 参与。他们采用了两种迁移策略：代理前数据下载和代理内 CLI 代理替换。这些技术将大多数 GitHub 数据获取移出了 LLM 推理循环。

衡量效率提升并不容易，存在三个混杂因素：并非所有令牌都同等重要（不同模型成本不同），工作量变化（仓库是实时的），以及输出质量是否改变。为了标准化模型差异，他们使用了有效令牌（ET）指标：ET = m × (1.0 × I + 0.1 × C + 4.0 × O)，其中 m 是模型成本乘数，I 是输入令牌，C 是缓存读取令牌，O 是输出令牌。输出令牌权重为 4 倍，缓存读取令牌权重为 0.1 倍。该公式将不同模型层的消耗标准化。

初步结果显示了显著的成本节约。在 gh-aw 和 gh-aw-firewall 仓库中的十二个生产工作流中部署后，Auto-Triage Issues 工作流在 109 次修复后运行中显示出 62% 的减少，Daily Compiler Quality 改善 19%，Daily Community Attribution 改善 37%。在 gh-aw-firewall 仓库中，Security Guard 和 Smoke Claude 分别改善了 43% 和 59%。运行频率同样重要，Auto-Triage Issues 平均每天运行 6.8 次，其优化累计节省了约 7.8 M ET。

基于这些结果，他们强调了三个模式：许多代理轮次是确定性的数据收集；未使用的工具成本高昂；单个错误配置的规则可能导致循环失控。例如，Daily Syntax Error Quality 工作流因一行配置错误导致代理陷入 64 轮的回退循环。

下一步计划包括将单体代理重构为子代理团队、从工作流级优化转向系统级优化，以及分析工作流组合中的重叠。他们强调，第一步是添加 API 代理、开启日志记录，让数据指引优化方向。