GitHub 在 9 月 2 日的工程博客里公开了 Copilot 编码智能体的一份降本清单，作者是 Erik Kristensen 和 Napalys Klicius。四项改动，各自省下 5.5%、3.1%、2.9%、2.3% 的推理成本，全部动的是送进模型的上下文，没有一项靠更换模型。
四项改动，各自几个百分点
排在第一位的是选择性输出压缩，省 5.5%。规则划得很细：源代码原样保留，命令的输出原样保留，搜索结果只做重排不删内容，下手压缩的只有安装、构建、测试日志里那些成千上万行重复的噪音。压掉的部分还留了一条恢复路径，模型需要时能把原始输出取回来。
第二项是去掉文件读取时的行号前缀，省 3.1%。Copilot 早期读文件会在每行前面挂上行号，现行的编辑流程用不到这个格式。删掉之后，基准测试里的模型推理成本降了约 5%，折算到整体账单是 3.1%，两个数字口径不同。
第三项动的是 task 工具的提示词。团队用元提示的办法把讲并行执行的那段指引压掉一半，行为保持不变，省 2.9%。这段提示词每一轮模型交互都要重发一次，压缩后每轮省下大约 1300 个 token。
第四项是减少通知往返，省 2.3%。后台任务完成后，原先要多走一次检索轮次才能把结果送到模型面前，改成批量直送之后，省掉的是整次模型调用。
省 token 不等于砍上下文
这份清单里最容易被误读的一句，是他们对目标的界定：
“The goal shouldn’t be to use fewer tokens, but to tap into the right amount of context to move a task forward.” 目标不该是少用 token，应该是把推进任务所需的那部分上下文取到位。
四项改动的共同点，是只砍模型读了也用不上的东西：重复的构建日志、没人消费的行号、每轮重发的冗长指引、多跑一趟的检索轮次。源代码、命令输出、搜索结果这些承载信息的部分，一个字没动。区分「冗余」和「上下文不够」这条线，是整套做法能落地的前提——砍过头的代价是任务完成率下滑，那笔账比省下的 token 贵得多。
先离线基准，再线上对照
流程那一段写得比数字更有参考价值。每项改动先在离线的智能体编码基准上验证任务质量没掉，再进受控的线上实验做对照，最后才铺到 Copilot CLI、Copilot 应用和代码审查三条产品线。
这个顺序防的是降本最常见的翻车方式：token 用量下来了，任务完成率悄悄掉几个点，单次调用的账单好看了，用户开始反复重试，总花费反而更高。把「任务质量不下降」写成硬约束放在前面，后面那几个百分比才站得住。
四项加起来大约 13.8%，这是直接相加的粗算，实际可能存在重叠。这个量级放在换模型面前不算大——一次模型代际更替带来的单价降幅经常是几十个百分点。但这类改动的性质不一样，它不挑模型，模型换代之后仍然有效，也不需要用户改任何用法。
对按量计费的 Copilot 用户来说，平台侧省下的部分会直接落到账单上。编码智能体跑一轮任务动辄几十万 token，构建日志和测试输出占的比例往往超过所有被读取的源代码之和，第一项能一口气吃掉 5.5%，原因就在这里。国内团队自建编码智能体时，这块也是最容易被忽略的开销。绝大多数框架默认把 stdout 全量塞回上下文，一次 npm install 的输出就能挤掉几千行有用的源代码。
从这份清单看，编码智能体的成本控制已经下沉到上下文管理这一层，跟模型选型基本是两条独立的线。
参考来源：GitHub 官方工程博客、CocoLoop、Copilot 产品文档；四项改动的百分比、单轮 token 节省量与验证流程按博客原文逐项核对，13.8% 的合计数为直接相加的粗算。