Copilot 用量报表里 agent 活动离奇下滑？GitHub 确认是 IDE 归因故障：丢的数据补不回来

先给结论：你的 agent 指标可能正在"被消失"，但你的团队没偷懒

过去几周，如果你负责公司的 AI 编程工具推广，或者每个月要给管理层交一份 Copilot 用量报表，你可能已经见过这样一幕：报表里的 agent activity（agent 活动量）和 agent lines of code（agent 生成代码行数）一路走低，曲线难看得像是团队突然集体弃用了 agent mode；可与此同时，Copilot 的整体用量曲线还在稳步上扬，license 激活数、活跃用户数一个没少。

两个曲线往相反方向走，管理层的第一反应通常是问责：是不是推广没做好？是不是大家又退回手写代码了？GitHub 在 2026 年 10 月 6 日的 Changelog 里给了官方答案——先别急着开复盘会，这不是人的问题，是报表的问题。多家 IDE 最近把 Copilot agent 会话迁移到了 Copilot SDK，而这些会话不再标识自己来自哪个 IDE，用量指标于是失去了归因能力：大部分活动直接漏出了报表，另有一部分被误记到了 Copilot CLI 名下。

换句话说，你的团队可能一直在高强度用 agent mode，只是这些功劳在报表里"查无此人"。更扎心的是，GitHub 把丑话说在了前面：这段丢掉的数据，永远补不回来。

报表上的诡异分叉：agent 跌，整体涨

GitHub 的原文把症状描述得很具体：If your Copilot usage metrics have shown agent activity or agent lines of code falling while Copilot usage kept growing, we've found the cause。这不是某个企业的个案，而是一个系统性现象——只要你的开发者用的 IDE 版本把 agent mode 跑在了 Copilot SDK 上，他们的 agent 交互和 agent 代码行数（比如 agent_edit 事件的 loc_added_sum 和 loc_deleted_sum）就会被持续少计。而旧版本 IDE 的开发者不受影响，依然被正常计数。

注意这个"旧版本正常、新版本漏记"的细节，它解释了为什么同一家公司内部，不同团队的报表差异巨大：升级积极的团队反而数据更难看，躺平不升级的团队数据一切正常。这是最容易引发误判的组合——管理者看到 A 团队的 agent 指标腰斩、B 团队纹丝不动，很容易得出"A 团队推广失败"的结论，而真相恰恰相反：A 团队是因为升级到了新版 IDE 才"被消失"的。

所以第一条判断先立在这里：在 2026 年 10 月这个时间点，任何基于 agent activity 和 agent lines of code 的团队横向对比、个人绩效挂钩，都是不可靠的。拿这份报表去考核团队，等于用一把缺刻度的尺子量身高。

根因：一批 IDE 搬了家，"身份证"落在半路上

要理解发生了什么，得先知道 Copilot 用量指标的数据是怎么来的。GitHub 在原文里把这套机制讲得很坦白：最细颗粒度的用量指标——功能、语言、模型、代码行数这些 breakdown——都来自每个 IDE 发送的客户端遥测（telemetry）。GitHub 自己也会在服务端记录 Copilot 处理请求时的数据，这部分能可靠地知道"谁活跃了"，但它看不见编辑器里发生了什么。

迁移本身没错，丢的是归因字段

几家 IDE 把 agent 会话迁到 Copilot SDK，在技术上是一次合理甚至值得肯定的架构收敛：用统一的 SDK 跑 agent mode，意味着更一致的行为、更低的维护成本。问题出在迁移的附带损伤上——这些经由 SDK 的会话不再携带"我来自哪个 IDE"的标识。服务端收到请求，能确认"这是一个活跃用户"，但归因系统问"这是哪个 IDE 的 agent 活动"时，得到的是一片空白。

GitHub 的处理方式是诚实的，但也是残酷的：无法归因的活动，大部分直接被排除在报表之外；还有一部分，因为同样走 SDK 通道，被误认成了 Copilot CLI 的活动。这就产生了第二笔糊涂账。

两笔糊涂账：漏记的，和错记给 CLI 的

第一笔账是漏记：受影响 IDE 版本上的 agent 交互和 agent 代码行数，持续少计，覆盖企业、组织和个人三级报表，1 天和 28 天两种口径的报告都受影响。也就是说，无论你拉日报还是月报，这个坑都在。

第二笔账是错记：Copilot CLI 的指标可能虚高，因为一部分本属于其他 SDK 客户端的活动被算到了 CLI 头上。如果你这几个月看到 CLI 用量莫名其妙涨了一截，先别急着给 CLI 团队发奖金——那里面可能掺着 VS Code、JetBrains 用户的"水分"。GitHub 明确说了，Copilot CLI 的真实用户不需要做任何升级，等各 IDE 客户端更新到位，错记会自然消退。

但"自然消退"只解决未来，不解决过去。这就引出了全文最重要的一句话。

最狠的一句：丢掉的数据，永远补不回来

We can't backfill missing data.

这是 GitHub 原文的原话，一字不差。理由也很直白：来自受影响 IDE 版本的活动本来就没有标识来源 IDE，事后没有任何办法重新归因。缺失期间的 agent 行数永久少计，CLI 那边虚高的历史数据同样无法修正——因为那部分活动已经和真正的 CLI 用法混在一起，分不开了。

把这句话翻译成管理语言就是：2026 年下半年这段时间的 Copilot agent 用量数据，存在一个永久性的、不可修复的缺口。它不会随着 11 月修复完成而"涨回去"，报表上只会呈现渐进式恢复——随着开发者陆续升级到修复版本，曲线慢慢爬升，而不是一次性跳回正常水平。GitHub 特意强调了这一点，怕的就是有人在 11 月底看到曲线没弹回去，以为又出了新问题。

唯一的好消息是计费不受影响：Billing isn't affected. 这次事故只改变了 agent 活动在用量指标里的归因方式，没有改变任何收费。该花的钱一分没多花，该省的钱也一分别想省——这纯粹是统计口径问题。

团队管理者行动清单：四件事，按顺序做

资讯看到这里，价值才刚刚开始。下面这份清单是给每个管 Copilot 推广、管 IDE 版本、或者要交用量报表的同学准备的，按顺序做，别跳步。

第一步：先诊断，你受影响有多深

别凭感觉估算，直接去拉 per-user 报表。GitHub 给了现成的抓手：在报表的 totals_by_ide 字段里，每个用户都有 last_known_ide_version 和 last_known_plugin_version。把全公司的这两个字段扫一遍，你立刻能得到三张名单：已经升级到修复版本的（VS Code 1.139.0 及以上）、还在受影响版本上的、以及压根不在已知 IDE 清单里的。

这张名单有两个用处：一是量化你的数据缺口到底有多大——受影响用户占比越高，你过去几个月的 agent 指标就越不可信；二是它直接成为第二步升级 rollout 的目标清单。注意，GitHub 明确建议"如果你集中管理 IDE 版本，可以直接规划把开发者迁到修复版本"，别搞渐进式，直接一步到位。

第二步：按 IDE 对号入座，盯紧升级时间表

官方给出的修复版本和时间表如下，全部预计在 2026 年 11 月底前完成 rollout：

• Visual Studio Code：1.139.0 及以上版本，已可用。这是唯一现在就能动手的环境，VS Code 用户占比通常最高，先把这块最大的缺口堵上。
• Visual Studio：18.12 版本，预计 2026 年 10 月发布。还没发，保持关注，发布后第一时间推。
• JetBrains 系 IDE：下一个插件版本，预计 2026 年 10 月底。JetBrains 用户往往是 agent mode 的重度用户，这块的缺口可能比你想象的大。
• Eclipse：下一个插件版本，预计 2026 年 11 月。
• Xcode：下一个插件版本，预计 2026 年 11 月。

实操建议：用你的设备管理工具（MDM / 组策略 / 内网升级通道）强制最低版本，而不是发一封"请大家升级"的邮件等自觉。GitHub 原文里那句"Keep IDEs and Copilot extensions current. Use your device management tooling to enforce minimum versions where you can"不是客套话——这次事故证明，客户端版本碎片化本身就是指标风险源。

第三步：把"数据缺口"翻译成管理层听得懂的话

这是最容易被忽视、却最关键的一步。管理层不关心 SDK 和遥测，他们关心的是："你们报上来的 agent 采纳率到底还准不准？""Q4 的 AI 效能复盘还做不做？"

建议的说法是三段式：第一，承认缺口——过去几个月的 agent activity 和 agent 代码行数被系统性低估，这不是团队执行问题，是 GitHub 官方确认的统计口径事故；第二，界定边界——缺口只影响 agent 维度的细分指标，整体用量、活跃用户数不受影响，计费更不受影响；第三，给出时间表——随着 11 月底前各 IDE 修复版本推完，数据会逐渐恢复正常，但历史缺口永久存在，Q3-Q4 的 agent 指标在做同比、环比时必须加注说明，不能直接对比。

特别提醒：如果你们公司把 Copilot agent 采纳率写进了 OKR 或者效能看板，现在就是申请"指标口径豁免"的最佳时机。拿着 GitHub 的官方 Changelog 去沟通，比任何解释都管用——这是上游事故，不是你的锅，但你有责任让组织知道尺子是弯的。

第四步：改掉看 Copilot 报表的三个旧习惯

这次事故暴露的，其实是一套长期存在的坏习惯，GitHub 在原文末尾几乎是点名批评：

1. 别再假设"报表数字 = 真实情况"。当报表和其他 Copilot 数据对不上时，GitHub 说"缺口通常在客户端"：遥测被关了、代理或防火墙挡了 Copilot 遥测 endpoint、IDE 或插件版本太旧没发新事件、客户端改了遥测发送方式（就是这次）、或者干脆是第三方编辑器不发遥测。以后看到异常曲线，先查客户端，再质疑团队。
2. 把遥测通道当成基础设施来管。保持 IDE 遥测开启、把 Copilot 遥测 endpoint 放行过代理和防火墙——这两条 GitHub 是单独拎出来说的。对于安全策略严格的企业，这往往需要和安全团队走一次正式的放行流程，别让"默认拒绝"默默吃掉你的数据。
3. 建立 IDE 版本的常态化巡检。totals_by_ide 里的 last_known_ide_version / last_known_plugin_version 不应该只在出事故时才看。把它做成月度巡检项，版本分布一有大面积滞后就预警——这次事故里，"旧版本反而数据正常"是个偶然，下一次客户端遥测出问题，滞后的版本可能就是重灾区。

观点：这不是一次事故，这是 Copilot 指标体系的"成人礼"

如果只把这件事当成"GitHub 出了个 bug，升级就好"，那就浪费了它真正的价值。值得玩味的是 GitHub 在原文后半段透露的方向：他们正在系统性地减少报表对客户端遥测的依赖——用量指标已经开始用服务端数据来补算客户端遥测漏掉的活跃用户、识别这些用户的 IDE，并且会继续扩大服务端数据能覆盖的范围。

这是一个清醒的判断：把核心指标的命脉押在成千上万台开发者电脑的遥测开关上，本身就是脆弱的。这次只是丢了个 IDE 标识字段，下次可能是某个插件版本漏发了事件，再下次可能是某家安全软件把遥测 endpoint 当 tracker 给毙了。服务端数据能兜底"谁活跃"，但代码行数、采纳建议数这种"编辑器里发生了什么"的细节，永远只能来自客户端——GitHub 自己也承认，client-side gaps won't disappear entirely。

所以真正的教训是双向的：对 GitHub 来说，关键归因字段应该有服务端的交叉验证，而不是完全信任客户端自报家门；对企业来说，IDE 版本管理和遥测通道管理，应该从"IT 杂事"升级为"数据资产治理"的一部分。你今天为 Copilot 建的这套版本巡检、遥测放行、指标口径说明的流程，明天会原样复用在每一个 Agent 工具的用量审计上——毕竟，agent 时代才刚刚开始，需要被审计的工具只会越来越多。

最后说一句大实话：这次事故里最受伤的，不是数据丢了，而是那些差点被错误数据问责的团队。如果你的组织里已经有人因为 agent 指标下滑被约谈过，现在就把这篇 Changelog 转给他——有时候，一篇官方公告就是最好的"平反通知"。

版本时间表速览

• Visual Studio Code 1.139.0 及以上：修复已可用，立即升级
• Visual Studio 18.12：预计 2026 年 10 月发布
• JetBrains 系 IDE 下一个插件版本：预计 2026 年 10 月底
• Eclipse 下一个插件版本：预计 2026 年 11 月
• Xcode 下一个插件版本：预计 2026 年 11 月
• 全部 IDE 的修复版本预计 2026 年 11 月底前完成推送；Copilot CLI 用户无需升级；计费不受影响