GitHub 在 2026 年 9 月 11 日宣布，Copilot 使用指标报告正式纳入 VS Code Agents 窗口的活动数据。企业和组织现在可以在 1 天和 28 天报告中看到专用 Agents 窗口的活跃用户、会话数和用户消息数，也可以在用户级报告中判断某个用户是否使用过这个窗口。
这项更新对平台团队的意义，不是多了几列报表，而是终于能把“大家是否在用 Agent”拆成更具体的行为数据。不过，VS Code Agents 只是一个明确的产品入口，不能代表用户所有的 Copilot Agent 活动，更不能直接等同于代码质量或开发效率。要让这些指标真正有用，先要弄清楚它统计了什么，再决定拿它回答什么问题。
这次新增了哪些字段
新增指标同时出现在企业级和组织级报告中，并覆盖 1 天和 28 天两个时间窗口。用户级报告也会提供对应的使用标记和计数。
| 报告层级 | 字段 | 含义 |
|---|---|---|
| 企业或组织汇总 | daily_active_vscode_agent_users |
每天使用专用 VS Code Agents 窗口的去重用户数，可选字段 |
| 企业或组织汇总 | totals_by_vscode_agent |
按 VS Code Agents 汇总的 session_count 和 total_user_messages |
| 用户级报告 | used_vscode_agent |
用户是否使用过专用 VS Code Agents 窗口，可选指示字段 |
| 用户级报告 | totals_by_vscode_agent |
单个用户的会话数和用户消息数，可选字段 |
这里有两个关键词值得留意。第一，字段是可选的；如果对应数据暂时不可用，字段可能缺失或为 null。第二，统计对象是专用的 VS Code Agents 窗口，不包含编辑器窗口里的 Agent Mode，也不自动并入通用 Copilot 使用汇总。
因此，历史报表解析器不能假设这些字段永远存在，也不能把空值当成“用户没有使用”。更稳妥的做法是区分三种状态：字段存在且有数值、字段存在但为 null、字段完全不存在。它们可能分别代表有数据、当前无法提供数据，以及旧报告或不适用的报告版本。
统计入口在哪里
GitHub Copilot 使用指标 API 返回的是报告下载链接和报告覆盖的时间范围。企业级报告的入口包括：
1 | GET /enterprises/{enterprise}/copilot/metrics/reports/enterprise-1-day?day=YYYY-MM-DD |
第一类接口用于取某一天的企业报告，第二类接口用于取最近一个完整 28 天周期的报告。组织级报告和用户级报告也在同一组 Copilot usage metrics API 文档中提供，具体路径和权限应以当前文档为准。
这类接口的使用方式和普通实时监控 API 不一样。自动化程序拿到报告链接后，还需要下载并解析报告文件，再把数据写入内部的数据仓库或指标系统。建议给下载、解析和入库分别记录状态，避免“接口调用成功”被误认为“数据已经成功更新”。
权限和策略是前置条件
企业报告不是所有 Copilot 用户都能读取。GitHub 文档列出的企业侧访问者包括企业所有者、计费管理者，以及拥有细粒度 View Enterprise Copilot Metrics 权限的授权用户。组织侧则面向组织所有者和拥有 View Copilot Metrics 权限的自定义组织或企业角色。
企业级 API 还需要打开 Copilot usage metrics 策略。GitHub 文档要求企业把这项策略设置为 Enabled everywhere，否则相关接口不会按预期提供报告。
在权限设计上，可以把读取报告的服务单独放在平台数据任务中：
1 | GitHub API 凭据 |
不要把企业级指标令牌直接放进普通构建任务，也不要把用户级报告无条件暴露给所有项目负责人。用户级数据涉及员工使用行为，应该先确认组织的隐私政策、访问审批、保留期限和展示粒度，再决定是否进入团队仪表盘。
如何读懂 Agent 活跃度
单看 daily_active_vscode_agent_users，只能回答“有多少人打开并使用过专用 Agents 窗口”。它适合观察入口采用率，不适合单独证明 Agent 帮助开发者写出了更好的代码。
更有意义的分析可以分成三层：
入口采用
把活跃用户数和具备 Copilot 许可、使用 VS Code 的目标人群放在一起比较，得到专用 Agents 窗口的触达比例。如果只看活跃用户的绝对值，很容易把团队规模增长误判成产品采用率提升。
使用深度
再观察 session_count 和 total_user_messages。会话数增加，可能说明用户反复使用 Agent；消息数增加，可能说明任务更复杂，也可能只是用户在反复追问。两者都需要和任务类型、仓库范围及时间窗口一起解释。
工程结果
最后把使用数据和代码审查周期、测试通过率、返工次数、缺陷修复时间等工程指标放在同一张分析表里。这里的重点是寻找相关性和变化趋势，不是把某个团队的消息数直接换算成“生产力分数”。
一个简单的看板可以同时显示：
1 | 目标用户规模 → Agents 活跃用户 → Agents 会话数 → 工程结果变化 |
这条链路中每一层都可能掉下去。有人拥有许可但没有使用，有人使用了 Agent 但没有形成稳定的开发习惯，也有人使用频繁却没有改善交付结果。把它们拆开，平台团队才知道应该优化培训、产品入口，还是代码审查和测试流程。
1 天报告和 28 天报告应该怎么配合
1 天报告适合看发布、培训或策略调整后的短期变化，例如某个团队在启用 VS Code Agents 后的第一周是否开始使用。它的波动会比较大，不适合直接拿来做团队间排名。
28 天报告适合看一段完整周期内的采用趋势，减少单日请假、迭代节奏和节假日带来的噪声。两类报告应该使用相同的字段口径和过滤规则，否则今天看到的增长可能只是统计周期变化。
建议在数据仓库中保留这几个维度：
- 报告类型和覆盖日期；
- 企业、组织和团队标识；
- VS Code Agents 的专用字段；
- 字段缺失或为
null的原始状态； - 报告下载时间、解析器版本和数据校验结果。
特别是解析器版本。GitHub 已经声明这些字段是可选的，未来还可能增加或调整报告内容。如果只把最终数值写进数据库，不保留原始文件和解析版本，后面很难解释历史图表为什么发生变化。
这组数据不能说明什么
这次更新很容易被包装成“Agent 生产力仪表盘”，但官方公告本身只承诺活动数据。它不能直接说明：
- 生成的代码是否通过了安全审查；
- 一个会话节省了多少时间；
- 消息越多是否代表任务越复杂；
- 没有使用 VS Code Agents 的用户是否使用了其他 Copilot 能力；
- 团队之间谁的开发效率更高。
尤其要避免把用户级报告用于简单的个人排名。使用频率会受到岗位、项目类型、IDE 习惯和数据敏感性影响。更适合的用途，是发现采用障碍、评估培训效果、观察团队级流程变化，并把结论交给开发者和负责人共同复核。
给平台团队的落地清单
先让数据管道对可选字段保持兼容
将字段定义为可选，缺失和 null 原样保留，解析失败则进入重试队列。不要为了让下游图表有值而把未知状态填成零。
把专用窗口和其他 Agent 入口分开
数据模型中保留 vscode_agents 的独立维度，不要把它和编辑器窗口 Agent Mode 或通用 Copilot 汇总混成一个“Agent 使用量”。口径越清楚，后续比较越可靠。
先观察趋势，再决定是否做干预
用 1 天报告定位异常，用 28 天报告确认趋势。培训、模板和内部推广应该有明确的前后对照周期，并同时检查代码审查和测试结果有没有变化。
给用户级数据设置访问边界
用户级指标应当最小化展示，优先使用团队汇总和匿名化趋势。需要下钻时，保留审批记录、访问日志和数据保留期限。
结语
GitHub Copilot 使用指标新增 VS Code Agents 数据，让企业第一次可以更细地观察专用 Agent 入口的采用和使用深度。daily_active_vscode_agent_users 适合看入口采用，session_count 和 total_user_messages 可以帮助理解使用强度，用户级字段则适合做有边界的分群分析。
真正值得做的工作，是把这些字段接入一条可靠的数据管道，再与代码审查、测试和交付结果放在一起观察。只要记住它们记录的是活动，不是生产力本身，这次更新就能成为治理 Copilot 使用的一个实用起点。