GitHub Copilot 如何降低 AI 编程成本

与 AI 编码智能体协作时，输出质量至关重要，但真正的效率来自于快速、高效地完成工作，并获得正确的上下文。

这就是为什么单独计算每次交互的 token 数量并不是衡量效率的有意义指标。目标不应该是使用更少的 token，而是获取适量上下文以推进任务。有时一个简洁的工具响应如果遗漏了智能体需要的信息，反而会导致额外的调用或工作，最终使任务变得更慢、更昂贵。

这就是为什么我们要优化的是结果而非工具调用本身。本文探讨了 GitHub Copilot 中的四项变更，践行这一原则：

保留有用上下文，同时减少重复输出。

移除对任务毫无价值的格式。

在不改变有用行为的前提下缩短指令。

交付已完成的后台工作，无需额外的检索步骤。

候选变更通过智能体编码基准测试进行离线评估。最有希望的变更再通过受控在线实验验证后才发布。本文中的示例来自 GitHub Copilot CLI。其他多款 Copilot 产品（如 GitHub Copilot 应用和 Copilot 代码审查）使用相同的底层测试框架，也因这些改进而提升了效率。

图 1：四项独立 A/B 实验，使用相同的 AI 配额指标。各分段并列展示以供比较；其效果不一定是严格可叠加的。

局部指标的陷阱

一种常见的降低智能体成本的方式是缩短每次工具调用的输出。RTK（Rust Token Killer）是一个在智能体读取前压缩 shell 输出的工具。我们用智能体编码基准测试评估了它对 GitHub Copilot 的影响。

在我们的测试框架和基准配置下，RTK 缩短了一些响应，但当被省略的文本重要时，模型有时会重新打开原始输出或重新运行命令来恢复所需内容。

这些恢复步骤增加了对话轮次，并携带了更多上下文向前推进。单独的工具响应变短了，但平均而言，任务消耗了更多 token 并花费更长时间。我们在本地节省了 token，但在全局花得更多。

图 2：当缺失细节迫使智能体重新读取输出、重新运行命令并携带更多上下文时，更短的工具响应反而会使完成任务的成本更高。

这一结果适用于我们测试的集成和工作负载，而非适用于 every RTK configuration or to output compression in general. 这意味着每个工具调用的 token 数是一个错误的目标。效率变更必须从用户的请求到最终结果，在整个任务中评估。

更有意义的做法是看我们能移除什么而不会让模型重复工作。

压缩噪音，保留有用信息

目标是缩短重复输出，同时保留智能体完成任务所需的上下文，避免重复步骤。

基准测试运行的分析表明，安装、构建、测试和 lint 的输出通常包含重复的噪音，而类似源代码的输出和任意命令结果更可能包含智能体需要的信息。这项分析催生了一个选择性输出压缩器，部分借鉴了 RTK 和类似方法。

原型在智能体编码基准测试和一系列开源仓库上进行了评估，触发了它们的构建、测试和 lint 系统。

早期版本过于激进。它们导致模型重复工作或读取完整的已保存输出，增加了端到端成本并降低了任务成功率。例如，我们最初压缩了 git diff，但在基准测试任务显示智能体会重新打开原始输出来恢复缺失信息后，移除了该过滤器。

这些早期失败促使我们制定了三部分策略：

保留类似源代码的输出和任意输出。cat、git diff、git show 和任意脚本等命令返回不变。

重组搜索结果而不丢失内容。grep 等工具的匹配结果和文件列表可以更高效地分组，同时保留每条结果。

选择性压缩重复噪音。安装、构建、测试和进度输出仅在节省显著时才会被压缩。

发货版本经过反复评估和打磨。它是保守的，不是因为我们的目标是构建一个保守的压缩器，而是因为评估结果支持这样做。

当输出被压缩时，智能体仍可通过直接恢复路径检索完整的原始内容。

图 3：发货的压缩器保留类似源代码的输出，重组搜索结果而不丢失任何匹配项，仅压缩可预测的重复噪音，同时保留完整原始内容。

这条恢复路径既是安全机制也是评估信号。我们追踪智能体是否打开了保存的原始输出、重新运行命令、重复探索、缩小搜索范围或进行了额外轮次。频繁的恢复操作表明压缩器移除了有价值的内容。

在触发输出压缩的离线任务中，未检测到统计学上显著的任务成功率回归，智能体极少打开保存的原始内容。在线实验中，平均成本略有下降，追踪的质量指标未检测到实质性回归。

在移除信息之前先移除格式

一个干净的 token 优化来自 view 工具，智能体用它将文件内容读取到上下文中。

此前，view 在向模型展示内容前会在每一行前加上数字。前期的文件编辑工具使用这些数字来定位变更，但当前工具改为匹配周围代码，不再使用行号。行号前缀仍然保留，尽管正常工作流不再使用它们。

每个前缀都很小。然而，当贯穿每个文件读取的每一行累积时，那些未使用的格式就在整个会话中不断积累。因此，我们移除了它们。

图 4：移除行号前缀精确保留源代码，同时消除了每次文件读取时重复的格式。

行号在 diff 和短代码片段中仍然有用。它们在这里是浪费的，因为它们被附加到每次文件读取中，却没有服务于当前的编辑工作流。

移除它们后，线下智能体编码基准测试中的模型推理成本下降了约 5%。成功率保持在预期的运行间方差范围内，编辑失败也没有增加。

我们随后对 Copilot CLI 用户测试了这一变更。在线实验将每位用户每日平均模型推理成本降低了约 3%，追踪的质量或满意度指标未检测到实质性回归。

对开发者而言，这意味着更多上下文窗口可用于工作本身，而非智能体不使用的格式。

这是理想的变更：无需向模型新增指令，无信息来源需要恢复，也无需额外决策。文件内容原封不动地到达模型。

压缩提示词而不压缩意图

提示词携带指导智能体工作的指令，每轮都会发送给模型。只有在智能体保持开发者依赖的行为时，缩短提示词才能提高效率。

在 GitHub Copilot 中，任务工具为并行工作启动专门的智能体。其指导在工具描述、schema、智能体定义、系统指令和配套工具中累积。

一个元提示循环（Copilot 迭代地自行编写提示词）将提示词减少了大约一半。Copilot 生成并精炼较小的候选项，而目标行为测试则检验我们想要保留的需求。

第一个在线实验发现了一个离线评估未能捕捉到的回归问题。元提示循环将谨慎的并行性指导重写为硬调度策略，导致独立的自定义 AI 智能体顺序运行。

我们停止了实验。在再次更改提示词之前，我们为用户暴露的行为编写了一个回归评估。最终的修复用一句话替换了显式的白名单和黑名单：

独立的 AI 智能体可以并行运行；请考虑副作用。

这句话更短且限制更少；它将是否并行运行子智能体的选择权交给了模型，而非之前的显式指导。有了它，我们的新行为测试通过了，且没有导致任何现有行为测试失败。

提示词行为需要测试。如果一个行为没有被测试，更短的提示词可以在无人察觉的情况下移除它。

图 5 提示词压缩只有在回归测试暴露了串行化 AI 智能体问题、并用一句话修复恢复了并行性之后才变得安全；由此带来的 token 节省在每次模型调用中都会生效。

交付的提示词每次调用移除约 1,300 个任务工具提示词 token，相当于每次会话总提示词 token 减少约 1.8%，每次活跃小时标准化成本降低 2.9%，在测量的评估中未检测到质量回归。

在不增加额外检索轮次的情况下交付已完成的后台工作

AI 智能体经常在后台独立运行工作，例如与子智能体调查并行的长时间运行的 shell 命令。通知让 AI 智能体持续运行直到该工作准备好，而无需花费工具调用来等待。

如果 AI 智能体没有明确等待任一任务，harness 会唤醒模型，并在 shell 命令或子智能体完成时通知它。

此前，该通知不包含已完成的结果，因此 AI 智能体必须再花费一个轮次来检索 Copilot 已收到的输出。当几个任务几乎同时完成时，这种绕路可能会重复。Copilot 现在将符合条件的完成通知批处理，并在现有工具结果格式中直接交付完成的结果。AI 智能体可以继续使用所需的信息，而无需再花费一个额外的轮次来请求它。对仍在运行的工作的显式读取行为与之前相同。

图 6 之前，每个后台完成都可能唤醒仅用于检索的模型轮次。之后，harness 批处理相关的完成并发出合成工具事件，使后台工作能够在等待时继续；两个结果在单次 LLM 调用中一起处理。

![前后对比的序列图，比较编排行为。

之前：模型等待单独的 shell 和子智能体完成，导致检索绕路和处理两个结果需要四次 LLM 调用。 之后：harness 批处理相关完成并发出合成工具事件，使后台工作能够在等待时继续；两个结果在单次 LLM 调用中一起处理。 视觉效果强调减少延迟和更少的模型往返。](https://cos.poetries.top/aiMonitor/1788399425032.png)

在此变更之前，每个已完成的任务需要一次模型调用来请求其结果，再花一次调用来处理它。对于上面显示的 shell 命令和子智能体，这意味着工作继续前需要四次模型调用。

现在，harness 批处理两个完成并一起提供结果，因此单次模型调用就可以处理两者。移除这些检索绕路也避免了通过不必要的调用携带完整的会话上下文。

通过直接交付完成的结果，不压缩、不总结、不保留任何内容，harness 按 AI Credits 衡量的平均 token 相关使用量减少了约 2.3%。

在上下文中衡量变更

在一个 Copilot 工作流中节省 token 的变更可能在另一个工作流中增加成本。

例如，一套更紧凑的文件工具指令受到了 Copilot 代码审查中积极结果的启发。在 Copilot CLI 在线实验中，它增加了成本，因此我们没有交付它。

相比之下，移除行号前缀和有选择地压缩输出在大量使用生产模型的 Copilot 代码审查任务的独立评估中，将每次审查的平均提示词 token 减少了约 5%。我们在追踪的审查质量指标中未检测到实质性变化。

这些发现独立于此前 Copilot 代码审查迁移到共享文件工具的工作，后者与审查指令调优相结合，将代码审查成本降低了约 20%。

每个变更都需要在其运行的工作流中测量。

构建高效 AI 编码 AI 智能体的五条经验教训

优化已完成的任务，而非工具调用。如果 AI 智能体花费更多轮次来恢复被移除的内容，更短的输出并不会更便宜。

优化编排，而不仅仅是模型输出。消除模型执行 harness 可以确定性完成的工作所需的模型轮次。

按输出代表的内容进行压缩。保留精确内容，优先使用无损转换，并测量 AI 智能体使用恢复路径的频率。

提示词重写有时会产生意想不到的后果。验证预期行为是否被保留。

证据是特定于工作负载的。在离线基准、在线实验以及它们交付的每个产品表面上重新评估变更。

这些变更都没有让模型变得更聪明。它们移除了模型从未需要做的工作。

本文描述的变更正在使用相同底层 harness 的 GitHub Copilot 体验中交付。

使用 GitHub Copilot CLI 将 AI 智能体工作流带到您的终端

GitHub Copilot 代码审查

Erik Krogh Kristensen 是 GitHub 的一位Staff Software Engineer，在 AI、编码和安全的交叉领域构建产品。在 GitHub 工作的近几年中，他参与了各种 AI 产品的工作，如 Copilot Autofix、Copilot Code Review，最近还有 Copilot CLI。他是关于如何让 AI 编码产品更好、更高效的可信赖来源。

Napalys Klicius 是 GitHub 的一位 Software Engineer，构建 AI 智能体系统。他的职业生涯从模型检查到低级 C++ 无人机系统和静态分析，最近转向教 AI 智能体如何检查代码而不迷路。

解读新的 AI 行话：循环、harness、队列、爬山……我的天！

从循环工程到 harness、队列和开放权重，GitHub Podcast 分解了出现在开发者对话中的 AI 术语。

面向初学者的 GitHub Copilot 应用：自动化 Dependabot 拉取请求分类

管理库更新有时会很繁琐。了解 GitHub Copilot 应用如何处理这类重复性任务。

生产前如何评估 LLM

这些是我们为真实世界的密钥扫描评估 LLM 时学到的经验教训。