GitHub 于 2026 年 9 月 11 日宣布，Copilot usage metrics 已在专用的 VS Code Agents 窗口正式可用。这项更新把 AI agent 的采用情况由概念变成可查询的运营数据，让企业可以知道团队是否真的在使用代理，以及使用集中在哪些 agent 类型。
在 aggregate enterprise 或 organization 报告中，GitHub 新增可选字段 daily_active_vscode_agent_users，以及按 VS Code agent 分组的 totals_by_vscode_agent。后者包括 session_count 和 total_user_messages，能回答「有多少活跃用户」之外，再补充「开了多少 session」和「进行了多少消息互动」。
enterprise-user 和 organization-user 报告则提供用户层级的 used_vscode_agent，以及每位用户按 agent 分组的 totals_by_vscode_agent。这些字段可以用来观察采用分布和使用深度，但数据仍是使用遥测，不是对程序质量、交付速度或业务成果的直接量度。
GitHub 特别界定了统计范围：只计算专用的 VS Code Agents 窗口，不包括 editor window 的 Agent Mode，也不包括一般 Copilot rollup。字段属于 optional，历史数据未提供时可以缺少或返回 null。这种向后兼容做法，提醒报告消费者不要把空值误当成零，也不要把不同界面的数字直接相加。
访问权限由 enterprise owners、billing managers、organization owners，或具有 View Copilot Metrics 权限的 custom role 管理；同时需要启用相关 policy。企业如果要把数据接入内部 dashboard，应先确认报告层级、角色权限、字段版本和导出周期，避免在权限或 schema 改变后悄悄产生错误趋势。
采用数字本身不能证明代理有效。session 多，可能代表任务多，也可能代表反复重试；消息多，可能代表深度协作，也可能代表提示不清或输出不可靠。更完整的评估应把使用数据与 pull request 结果、review 抽样、任务完成时间、成本、缺陷和人工介入一起看，并清楚定义每一项指标的分母。
治理层面也要先讲清楚谁可以看 user-level 数据、保留多久、哪些用途获得批准，以及如何区分管理分析与员工监控。聚合数字有助于降低不必要的个人追踪，但企业仍要处理内部定义、数据保留和访问审计。尤其不能只用一个 daily active user 数字，就对外宣称生产力提升。
这次更新的意义，在于 agent rollout 开始需要像其他生产系统一样有 instrumentation。成熟做法应同时量度 adoption、workflow outcome、quality and risk，并在变更 agent、模型或权限后保留可比较的基线。GitHub 提供的是一组实用的使用入口；怎样把它变成可信的工程和管理决策，仍取决于企业自己的量度设计。
