图片：METAL
摘要
- 微软研究院在 9 月 14 日的 Research Focus 最新一期中介绍了一篇分析 GitHub Copilot 编码智能体生产追踪数据的论文。
- 这是该工作负载的首个生产规模研究，样本取自 2026 年 6 月第一周的 320 万用户、1300 万会话、7.61 亿次 LLM 调用和 95 万亿个 token。
- 87% 的 LLM 调用由智能体发起，轮次边界处缓存命中率下降 26 个百分点，工具失败会让计算量最多放大 4 倍。
微软研究院在 9 月 14 日的研究通讯 Research Focus 最新一期中，以一篇分析 GitHub Copilot 编码智能体真实使用记录的论文作为首条内容。论文基于 2026 年 6 月第一周收集的匿名遥测数据，抽样了 320 万用户、1300 万会话、7.61 亿次 LLM 调用和 95 万亿个 token，作者称这是对编码智能体工作负载的首个生产规模分析。METAL 通读了这篇 7 月 30 日发布在 arXiv 上、共 20 页的论文原文。
核心发现是，编码智能体是一种与聊天机器人不同的负载。据作者介绍，用户发送一条消息后，智能体平均会自行连续发起 6.6 次 LLM 调用，全部 LLM 调用中 87% 由智能体而非用户发起。LLM 调用与工具执行的比例为每会话平均 40.6 比 43.6，几乎是 1 比 1。论文写道："智能体循环强制了 LLM 与工具之间严格的 1 比 1 耦合。服务系统必须把 LLM 调用及其对应的工具调用视为相互依赖的一对，而不是独立的请求。"
会话规模极度偏斜。中位数会话有 3 个用户轮次、15 次 LLM 调用、持续 4.2 分钟，但平均值是 6.1 个轮次、40.6 次调用、62.6 分钟，前 10% 的会话超过 15 个用户轮次和 100 次 LLM 调用，持续三小时以上。token 的不对称更为悬殊：单次 LLM 调用的提示 token 中位数为 6.8 万个，而输出 token 中位数只有 247 个，输入与输出之比超过 275 比 1。提示中 48% 是对话历史，28% 是工具调用结果，系统提示只占 14%。上下文膨胀的原因不是指令，而是智能体自身此前的推理与行动。
在工程师眼中最实用的部分是 KV 缓存的生命周期。在一个轮次内，前缀缓存命中率从首次调用的 45% 跃升到第二次的 86%，第三次起稳定在 92% 到 94%。但在用户发送下一条消息的轮次边界处，命中率平均下降 26 个百分点至 55%，轮次之间的空闲时间超过 10 分钟后，命中率中位数崩至 0% 到 5%。切换模型更糟，切换后的命中率只有 8%。模型切换发生在约 6.4% 的会话中，大多是对错误或速率限制的被动反应；当用户把手动选择交给自动模式时，52% 的切换是降级到更便宜的模型。
上下文压缩是一项隐藏成本。上下文窗口填满后，智能体会总结历史并重写提示。这只发生在 7.8% 的会话中，但这些会话占全部 token 的 44.2% 和 LLM 调用的 37.1%。一次压缩会删除中位数 72.8% 的提示 token，缓存命中率中位数下降 66.1 个百分点，压缩调用本身占轮次执行时间的中位数 22%。作者将压缩归为与模型切换同等级别的缓存重置事件。最极端的会话压缩了 40 次。
工具失败会让成本成倍增加。据论文，9% 的轮次会出现工具失败，此时智能体会带着不断增长的上下文自行重试循环，计算量最多膨胀 4 倍。含失败的深循环轮次占全部的 9.1%，但 LLM 调用达 36 次，是中位数的四倍。run_command、run_build 和 edit_file 的成功率降到 73% 左右，终端命令失败时在第 95 百分位上比成功时多耗 48 倍时间。构建失败时，进入上下文的编译器诊断 token 是成功时的 7 到 8 倍。同一张表还显示，单个工具 get_file 占全部工具调用的 35%。
用户也不止一种。作者把用户分为五类：以阅读为主的占 41.7%，编码者占 30.4%，终端用户占 11.0%，深循环用户占 9.2%，纯聊天用户占 7.6%。每轮 token 从纯聊天用户的 2.3 万到深循环用户的 110 万，相差 50 倍。缓存一旦清空，深循环用户需要重新填充 110 万个 token，纯聊天用户只需 2.3 万。作者计算，对所有人套用同样的缓存过期时间，最重的用户会缴纳最高的延迟税。周末会话数量更少但更长、调用更多，作者解读为开发者在不受打扰时会交付更有野心的任务。
在这种结构中回收资源的信号是轮次边界。轮次内容器和 KV 缓存的空闲时间中位数分别只有 5.8 秒和 1.2 秒，没有回收余地；而轮次之间则拉长到 243 秒和 172 秒，长了几十倍到一百多倍，用户发送下一条消息前的空闲时间中位数为 25.2 分钟。作者构建了一个 LightGBM 模型，在每个轮次结束时以生存曲线预测会话还会空闲多久。模型整体约 2MB，推理不到 3 毫秒，预测空闲是否超过 60 秒的 ROC-AUC 为 0.73，能捕获全部空闲时间的 86% 到 90%。向 arXiv 提交论文的微软 Azure 研究院研究员 Esha Choukse 与合著者写道："即使模型无法精确指出会话会空闲多久，它也能可靠地识别出会话将空闲足够长的时间，值得回收。"
用 TPM 的语言来说，这篇论文要求把按请求设计的服务基础设施按会话重新设计。如果说聊天机器人是一位顾客走到柜台交一张表就离开，编码智能体则是一位顾客坐在柜台前来回交换十五次表格，离开 25 分钟后又回来。因此论文提出：把会话固定在一个模型上，切换不可避免时提前预热新模型的缓存，以保留前缀的方式渐进压缩，并按用户类型设定不同缓存保留优先级的分层 SLO。论文还建议，在缓存保留时间固定的 API 上，当预测的空闲时间恰好跨过该上限时，可在到期前发送一次廉价的保活请求，避免完整重算。
数据的边界在论文中写得很明白。追踪数据是 Visual Studio 和 VS Code 的客户端记录，没有 GPU 利用率等服务端指标；没有收集提示正文和代码，因此无法判断任务是否完成；样本全部来自美国地区，时区不超过三个。作者表示 1 月至 6 月的特征保持一致，同时指出工具和模型每周都在变化的工作负载需要长期追踪，并计划很快公开脱敏后的追踪数据。METAL 曾报道 GitHub 开始在 Copilot API 中单独统计智能体用量，而这篇论文首次用数字展示了这些统计背后智能体的实际运行方式。
编码智能体的成本来自结构，而不是模型。用户发出的一条消息在智能体内部膨胀为六次调用和六次工具执行，其间缓存是否存活决定了延迟和成本，一个工具失败就让计算量翻四倍。面向智能体的基础设施不是在聊天机器人基础设施上修修补补，而必须以会话为单位从头设计。
评论