一行行号值多少钱？在 GitHub Copilot 的成本优化清单里，它大约值 5% 的线下推理成本。这个数字看起来不算惊人，但是当工程师 Erik Kristensen 把“移除行号前缀”“压缩 task-tool 提示词”“选择性压缩工具输出”“后台任务完成后直接交结果”四件事摆在同一张桌上时，你会看到一条清晰的线索：所有动作都不是为了让单次模型调用更便宜，而是为了让整个任务完成得更省。GitHub Copilot 的成本优化没有宏大叙事，有的只是对 token 流向的精细盘查。而这份盘查背后，是一套值得所有 agent 团队抄作业的评估方法。
只看单次调用的省钱，都是耍流氓
任务视角才是真正的最小单元
一个编码 agent 的日常是长这样的：用户丢来需求，模型先读代码，找不到就搜，搜到了改，改完跑测试，测试报错再回去改。整条链路中，工具调用一轮接一轮，前一轮的输出会变成后一轮的上下文。如果压缩 token 时只盯着某一个请求，很容易出现“省了芝麻、丢了西瓜”的结局——你把这段工具输出压短了，模型少看了一行关键报错，于是它多写了一段错误代码，又多跑了两轮测试来纠错。最后的账单不但没变小，反而变得更长。
GitHub 坚持把评估单位放在整个任务上，正是看到了这类递归损失。所谓整个任务，是从用户最初意图开始，到最终代码交付结束的完整过程。在这段时间里消耗掉的所有 token 加在一起，才是真正的成本。优化任何单个环节，都必须回到这个总账本上验证收益。
选择性压缩工具输出，不是每个字节都要进上下文
四项改动中，选择性压缩工具输出是最考验判断力的一个。工具输出里既有错误堆栈、函数签名、文件路径这类高信号内容，也有大量历史状态、重复说明和无关日志。GitHub 没有把这些内容一视同仁地截断，而是基于当前任务目标做筛选：关键信息原样保留，冗余部分压缩成摘要，彻底无关的内容干脆不放入上下文。
这里要特别注意“选择性”的含义。它不是靠一个固定阈值去截断长文本，而是先判断“这段信息是否在影响下一步动作”。如果模型需要确认变量在哪里定义，那就把定义附近的完整代码给它；如果工具输出里只是几十行已经过时的编译警告，那用一句“警告已过期”代替就好。这种智能压缩的前提，是系统能理解任务当前处于什么状态。GitHub 用工程实现证明了一件事：高质量的压缩比例，不在 token 层，而在任务语义层。
两笔不起眼，但很聪明的节省
行号前缀：最贵的“格式税”
许多代码工具在返回文件内容时会自动加上行号，方便人眼定位。但在 agent 的上下文里，行号是一种昂贵的格式税：每一行都要为“123:”或者“456 |”多付几个 token。一个五百行的文件被读取时，行号可能贡献数千个额外 token；如果同一份文件在多轮任务里被反复读取，这笔开销会成倍累积。
GitHub 移除 view 工具的行号前缀后，线下推理成本下降了约 5%，线上用户日均推理成本下降了约 3%。一个字符层面的改动，能带来如此明确的成本降幅，这恰恰说明 token 浪费通常藏在那些“大家默认就该存在”的细节里。顺手删掉一个前缀，比费尽心思压缩模型输出要稳妥得多。
task-tool 提示词，一次瘦身省下 1300
task-tool 是 agent 用来启动子任务的关键工具。它的提示词越长，每一轮子任务消耗的 token 就越多。GitHub 选择对这段提示词动刀，压缩掉那些模型已经“记住”的表述，让每一轮任务调用平均节省约 1300 个 token，同时让每个活跃小时的归一化成本下降 2.9%。
1300 在动辄数万 token 的上下文中算不上大数目，但 task-tool 最大的特点是高频。一个复杂任务可能连续触发几十次子任务，单轮节省被频率放大之后，就成了可观的成本优势。更妙的是，提示词变短意味着上下文窗口里能多放一段真实代码，模型有了更多信息做判断，任务成功率并不会因为“工具怎么用”的说明减少而下降。
后台任务结束，别让对话继续空转
中间过程的“回放”是最容易忽略的浪费
代码 agent 经常会把一些耗时操作放到后台执行。过去在任务完成后，模型也许还会生成一段对执行日志的总结，或者停在“需要我继续吗”的等待状态；用户面前则会滚过一大段与最终交付无关的中间过程。这些内容不会提升任务质量，却会实实在在消耗 tokens 和 AI Credits。
GitHub 的第四项改动非常直接：后台任务完成时，直接把最终结果交付给用户，不再额外展示过程全景。这等于在交互流程中切掉了一段“为了看起来有进展”而存在的输出。任务结束的标志，从“模型说完一段漂亮话”变成了“用户拿到可用的代码结果”，这也让成本结构与用户体验同时变得干净。
AI Credits 降了 2.3%，这不是模型优化，是产品流程优化
上述改动让 AI Credits 用量下降了约 2.3%。这个降幅不算大，但它完全不需要牺牲模型能力，也不需要降低生成质量，只是把交付时机提前了。对 Copilot 这样的产品而言，AI Credits 是用户购买的算力计量单位，2.3% 的降幅意味着同一份预算能服务的任务量变多了；对 AI 应用开发者来说，它则提供了一个提醒：成本不只会出现在模型的 input/output 里，还会出现在产品流程那些“没有明确结束点”的边缘。
很多团队认为 AI 成本只有通过换模型、减参数才能降下来，但从 GitHub 的实践看，最大的成本漏洞往往来自交互流程里的过度输出。删除一层不必要的中间结果，比让模型学会“少说话”更容易落地。
可复用的评估逻辑，和几个值得记下的坑
为什么线下 5%，线上只有 3%
GitHub 公布移除行号的成本收益时，同时给出了线下和线上两组数字：线下推理成本下降约 5%，线上用户日均推理成本下降约 3%。二者之间的差距，并不是评估口径不一致，而是反映了两种环境的本质区别。
线下评估通常使用固定任务集，每个任务都会被执行到终点，工具输出占比高，行号税的影响自然明显。线上真实用户则会频繁地打断任务、更换需求、中止会话，很多会话还没来得及进行大量工具调用就草草结束。这样的场景中，省 token 的收益被用户行为中的随机性摊薄。因此，当你想评估一个压缩手段时，离线结果显示的是“能力边界”，线上结果显示的是“真实收益”，两者缺一不可。如果只参考线下 5% 而期待线上也有同样效果，产品压测时一定会失望。
每活跃小时，才是更公平的记账单位
在 task-tool 提示词压缩的评估里，GitHub 使用了每活跃小时归一化成本这个指标。相比简单地比较“调整前后总成本”，这个分母抹平了用户使用时长波动和活跃人数变化带来的干扰。一个用户在某个小时内可能只发出三个请求，但 agent 在后台把所有工具调用跑满，成本也会很高；只有用活跃小时做分母，才能看到单位时间内的真实消耗变化。
这套归一化思路可以转移到任何 agent 产品上。很多团队做 A/B 测试时只看“总成本减少 X%”，但总成本下降可能只是因为测试期用户活跃度降低。把每个活跃小时作为一个“成本切片”，对比切片内部的消耗分布，优化效果才会浮出水面。选择哪一个分母，本质上是在选择一种对业务更诚实的解释方式。
压缩的边界：质量是护栏，不是口号
在 Erik Kristensen 的分享里，“不牺牲任务质量”不是挂在末尾的原则性废话，而是贯穿所有改动的硬约束。从选择性压缩工具输出到压缩提示词，GitHub 显然没有走“先把 token 砍到最低，再通过重试弥补错误”的歪路。他们的做法是先定义一组能代表真实任务难度的任务集，记录未压缩前任务成功率、代码正确率、用户完成时间等基线；在压缩改动生效后，跑同一组任务，看质量指标是否有统计学意义上的下滑。
任何一个试图复刻这套方法的团队，都应该先搭一个这样的质量护栏。护栏不需要复杂，但必须是“任务级”的：单纯比较单轮回答的文本相似度，会被压缩后的表述变化骗过；只有看最终任务是否完成、完成的代码是否能通过测试，才能捕捉到压缩真正带来的影响。毕竟省钱的目的不是把产品做成一个便宜但难用的东西，而是让同样的资源产生更多有效结果。
回过头再看那四项改动：行号前缀、task-tool 提示词、工具输出、后台交付时机。它们没有一个触及模型的参数规模，也没有一个需要推倒重来的算法革命。GitHub 只是认认真真地把 agent 任务的每一段信息流拆开，问了一个朴素的问题：这段 token 到底帮助模型做出了什么决定？如果回答不了，就删掉。这个朴素的追问，可能才是这一次成本优化分享里最值钱的部分。
