技术速递｜如何在不牺牲任务质量的前提下，让 AI 编码更具成本效益

作者：Erik Kristensen & Napalys Klicius

排版：Alan Wang

为什么更短的输出反而可能成本更高，以及 GitHub Copilot 如何在完整的编码任务过程中减少无效工作。

在使用 AI 编码智能体时，输出质量固然重要，但真正的效率来自于快速、高效地完成工作，并为模型提供恰当的上下文。

因此，仅凭单次交互的 Token 数量，并不能真正衡量效率。目标不应该是使用更少的 Token，而是提供推进任务所需的恰到好处的上下文。一个简短的工具响应，如果遗漏了智能体完成任务所需的信息，反而可能导致额外的工具调用或重复工作，最终让整个任务耗时更长、成本更高。

这也是为什么，我们优化的是任务结果，而不是单次工具调用。本文介绍 GitHub Copilot 中四项围绕这一原则实施的优化：

• 保留有价值的上下文，同时减少重复输出。

• 去除对任务没有价值的格式信息。

• 缩短指令，而不改变有用的行为。

• 直接提供后台已完成的工作结果，无需额外检索步骤。

所有候选优化都先通过智能体编码基准进行离线评估，再通过受控在线实验验证效果，最终才正式发布。本文中的示例来自 GitHub Copilot CLI。GitHub Copilot App、Copilot Code Review 等多个 Copilot 产品共享同一套底层运行框架，因此也同样受益于这些效率优化。

局部指标陷阱

一种常见的优化思路，是缩短每一次工具调用的输出，以降低智能体的成本。RTK （Rust Token Killer）就是一个会在智能体读取 Shell 输出之前，对输出内容进行压缩的工具。我们使用智能体编码基准测试评估了它在 GitHub Copilot 中的效果。

在我们的运行框架和基准配置下，RTK 确实缩短了部分工具响应。但当被省略的内容恰好是模型需要的信息时，模型有时会重新打开原始输出，或者重新执行命令，以找回缺失的信息。

这些恢复操作增加了新的交互轮次，并让更多上下文持续保留在上下文窗口中。单次工具响应虽然变短了，但平均来看，整个任务消耗了更多 Token，也花费了更长时间。我们在局部节省了 Token，却在整体任务中付出了更多 Token。

需要说明的是，这一结果适用于我们测试的集成方式和工作负载，并不代表所有 RTK 配置或所有输出压缩方法都会如此。这说明，每次工具调用消耗多少 Token，本身并不是正确的优化目标。一次效率优化，必须放到完整任务中评估------从用户提出请求，到最终完成结果。

真正更有价值的问题是：哪些内容可以删除，而不会让模型重复工作？

压缩噪声，保留有用信息

我们的目标，是缩短重复性的输出，同时保留智能体完成任务所需的上下文，让它无需回头重复探索。

基准测试分析发现，安装、构建、测试以及代码检查的输出中，往往包含大量重复噪声；而源码类输出，以及任意命令产生的结果，更有可能包含智能体真正需要的信息。基于这一分析，我们设计了一套选择性输出压缩器，其中部分思路参考了 RTK 等类似方案。

这一原型在智能体编码基准以及多个开源仓库上进行了测试，覆盖了它们的构建、测试和代码检查流程。

早期版本压缩得过于激进。模型因此不得不重复执行操作，或者重新读取完整保存的输出，导致端到端成本增加，任务成功率下降。例如，我们最初压缩了 git diff 的输出，但基准任务发现，智能体频繁重新打开原始输出找回缺失内容，因此最终移除了这一压缩规则。

这些失败经验促成了最终的三项策略：

1. 保留源码类和任意输出 。 cat、git diff、git show 等命令，以及任意脚本输出，保持原样返回。

2. 重组搜索结果，但不删除任何内容 。 对 grep 等工具返回的匹配结果和文件列表重新组织，提高紧凑度，同时保留所有结果。

3. 仅选择性压缩重复噪声。 安装、构建、测试以及进度输出，仅在能够带来显著节省时才进行压缩。

最终发布的版本，是经过多轮评估和迭代形成的。它之所以采取保守策略，并不是因为目标是设计一个保守的压缩器，而是因为实验结果支持这样的设计。

即使输出被压缩，智能体依然可以通过一条直接的恢复路径，获取完整的原始输出。

这条恢复路径不仅是一项安全机制，也是一个评估信号。我们持续跟踪智能体是否会打开保存的原始输出、重新执行命令、重复探索、缩小搜索范围，或增加额外交互轮次。如果恢复行为频繁发生，就说明压缩器删除了有价值的信息。

在线下任务中，当输出压缩生效时，没有检测到任务成功率出现统计学意义上的下降，智能体也极少重新打开保存的原始输出。在线实验中，平均成本略有下降，同时监测的质量指标没有出现明显回归。

删除格式，而不是删除信息

另一项非常直接的 Token 优化，来自 view 工具------智能体通过它读取文件内容并放入上下文。

过去，view 会在返回给模型之前，为文件中的每一行添加行号前缀。早期的文件编辑工具依赖这些行号定位修改位置，但现在的编辑工具已经改为通过周围代码进行匹配，不再使用行号。因此，这些行号前缀虽然仍然存在，却已经不再服务于当前的编辑流程。

每一个前缀都很小，但它们会出现在每一行、每一个被读取的文件中，在整个会话过程中不断累积。因此，我们移除了它们。

行号在 Diff 或少量代码片段中仍然有价值，但在这里，它们附着在每一次文件读取上，却没有服务当前编辑流程，因此成为一种纯粹的 Token 开销。

在线下智能体编码基准测试中，移除行号前缀使模型推理成本下降了约 5%。任务成功率保持在正常波动范围内，编辑失败率也没有增加。

随后，我们在 Copilot CLI 用户中进行了在线实验。结果显示，用户平均每日模型推理成本下降约 3%，同时质量和满意度指标没有检测到明显回归。

对于开发者而言，这意味着更多上下文窗口可以用于真正的代码和任务，而不是浪费在模型并不会使用的格式信息上。

这是一次理想的优化：无需为模型增加新的指令，没有需要恢复的信息，也没有新增的决策成本。文件内容保持原样传递给模型，只是去掉了无意义的格式。

压缩 Prompt，而不是压缩意图

Prompt 承载着决定智能体如何工作的指令，并且会在每一次模型交互中发送给模型。只有在智能体依然保留开发者所依赖的行为时，缩短 Prompt 才能真正提升效率。

在 GitHub Copilot 中，task 工具负责启动专门的智能体来执行并行任务。随着功能不断演进，它的指导内容逐渐分散在工具描述、Schema、智能体定义、系统 Prompt，以及配套工具等多个位置。

GitHub Copilot 使用了一套 Meta Prompting 循环，让 Copilot 反复重写自己的 Prompt，最终将这一 Prompt 压缩了约一半。Copilot 会不断生成、更精简的候选版本，并通过针对性的行为测试，验证我们希望保留的行为是否依然存在。

第一次在线实验发现了一个离线评估没有捕捉到的问题。Meta Prompting 循环把原本关于谨慎并行的指导，改写成了一条硬性的调度策略，导致原本可以独立运行的自定义智能体，被串行执行。

我们立即停止了实验。在再次修改 Prompt 之前，我们先为用户暴露出的这一行为编写了一项回归测试。最终的修复，只用一句话替代了原先显式的允许列表和禁止列表：

独立的智能体可以并行运行；请考虑它们可能带来的副作用。

这句话更短，也更少限制。它把是否并行运行子智能体的决策交给模型，而不是通过 Prompt 强制规定。有了这句话，新的行为测试通过了，同时现有行为测试也没有出现失败。

Prompt 的行为同样需要测试。如果某种行为没有测试覆盖，一个更短的 Prompt 可能会悄悄把它删掉，而没有人注意到。

最终发布的 Prompt 每次调用 task 工具时可减少约 1,300 个 Prompt Token，相当于每个会话的 Prompt Token 总量减少约 1.8%，每活跃小时的归一化成本降低约 2.9%，同时没有检测到质量回归。

直接返回后台任务结果，无需额外检索一次

智能体经常会在后台同时执行多个独立任务，例如一边运行耗时较长的 Shell 命令，一边启动子智能体进行代码分析。通知机制允许智能体继续执行其他工作，而无需为了等待结果消耗一次工具调用。

如果智能体没有显式等待这些任务完成，运行框架会在 Shell 命令或子智能体完成时主动唤醒模型，并发送通知。

过去，这条通知并不包含任务结果本身，因此智能体还需要再花一轮交互，把 Copilot 已经收到的结果重新取回来。如果多个后台任务几乎同时结束，这种绕路检索会重复发生。

现在，Copilot 会将符合条件的完成通知进行批处理，并直接以现有工具结果的格式附带完成结果。智能体无需再额外请求一次，就可以继续使用所需的信息。而对于仍在运行中的任务，显式读取结果的行为保持不变。

在这项优化之前，每个后台任务通常需要一次模型调用请求任务结果，和再一次模型调用处理结果。以上图中的 Shell 命令和子智能体为例，总共需要 4 次模型调用 才能继续执行。

现在，运行框架会将两个任务的完成通知合并，并一次性提供结果，因此模型只需 1 次调用 就能处理两个结果。同时，这也避免了为了检索结果而反复携带整个会话上下文。

通过直接返回完成结果，而不是压缩、总结或隐藏任何内容，运行框架将以 AI Credits 衡量的平均 Token 使用量降低了约 2.3%。

在上下文层面衡量优化，而不是局部指标

一种能够节省 Token 的优化，在不同 Copilot 产品中，未必都会带来收益。

例如，一套更加精简的文件工具 Prompt，最初来源于 Copilot Code Review 中的积极实验结果。但在 Copilot CLI 的在线实验中，它反而增加了成本，因此没有正式发布。

相比之下，在使用生产模型的大规模 Copilot Code Review 任务中，两项优化都取得了稳定收益：去除行号前缀，使每次 Review 的平均 Prompt Token 减少约 5%；选择性压缩输出，同样使平均 Prompt Token 减少约 5%。同时，没有检测到 Review 质量指标出现明显变化。

这些结果与此前 Copilot Code Review 迁移到共享文件工具的优化相互独立。那次迁移结合 Review Prompt 调优，使代码 Review 成本整体降低了约 20%。

因此，每一项优化，都必须在它实际运行的工作流中重新验证。

构建高效 AI 编码智能体的五个经验

1. 优化整个任务，而不是一次工具调用。 如果更短的输出导致智能体需要额外几轮交互找回信息，那么它并不更便宜。

2. 优化编排，而不仅是模型输出。 能由运行框架确定完成的工作，就不要额外消耗模型交互。

3. 根据输出所代表的信息进行压缩。 保留精确内容，优先采用无损转换，并持续衡量智能体使用恢复路径的频率。

4. 重写 Prompt 往往会带来意料之外的行为变化。 必须验证预期行为是否仍然存在。

5. 证据只对具体工作负载成立。 每项优化都需要在线下基准、在线实验，以及发布到的每一个产品场景中重新评估。

这些优化并没有让模型变得更聪明，它们只是去掉了模型原本就不需要做的工作。

本文介绍的这些优化，正在陆续应用到所有共享同一套底层运行框架的 GitHub Copilot 产品体验中。

借助 GitHub Copilot CLI，你也可以把智能体工作流带到终端中。