GitHub 在 2026-09-17 的 changelog 中说明：usage metrics API 在既有 CLI 报告覆盖（existing CLI report coverage）的基础上，增加了面向 agentic 活动的用量指标，覆盖五类对象——skills、custom agents、MCP servers、slash commands、plugins。

这五类并不在同一抽象层上。skills 和 slash commands 更接近“能力入口”，custom agents 是“执行主体”，MCP servers 是“外部依赖”，plugins 则是“分发与打包单元”。把它们放进同一套用量口径，意味着 CLI 侧的观测对象从“用了多少次”扩展到“用了哪一类定制”。

官方已经明确的接口契约

与很多只给方向的 changelog 不同，这次说明给出了可以直接落到采集层的细节。

字段出现的报告类型。 官方原文是：The fields appear in enterprise and organization per-user and aggregate 1-day reports, per-user 28-day reports, and the day_totals entries in aggregate 28-day reports. 也就是说，字段同时出现在企业级与组织级的按用户报告、聚合 1 天报告、按用户 28 天报告，以及聚合 28 天报告中的 day_totals 条目里。

两类字段。 一类是 top 5 数组：totals_by_skill、totals_by_custom_agent、totals_by_mcp、totals_by_slash_cmd、totals_by_plugin，每个数组最多列出活动量最高的五个条目，每条包含一个 interaction_count。另一类是 distinct 计数：distinct_skill_use_count、distinct_custom_agent_use_count、distinct_mcp_use_count、distinct_slash_cmd_use_count、distinct_plugin_use_count，统计被使用的不同条目数量。

计数口径。 interaction_count 的含义随类别不同：skills、slash commands 和 plugin skills 计的是调用次数，custom agents 计的是启动次数，MCP servers 计的是连接尝试次数。distinct 计数包含 top 5 之外的条目；在按用户报告中，每个用户用过的条目各计一次，在聚合报告中，企业或组织内任何人用过的条目只计一次，而不是按用户累加。

权限与开关。 报告对 enterprise owners、billing managers、organization owners，以及拥有授予 View Copilot Metrics 权限的自定义组织或企业角色的用户开放。同时，Copilot usage metrics policy 必须处于启用状态。

几个必须注意的口径陷阱

隐私处理。 官方只展示 GitHub 提供的已知条目名称。为保护隐私，客户自定义的名称不显示：skills、custom agents、MCP servers 和 plugins 统一归入 other。slash commands 因为 Copilot CLI 遥测本身就把客户自定义命令归入 custom，所以报告沿用这个标签。

MCP 计数不等于工具调用量。 对 MCP servers 而言，interaction_count 只在 Copilot CLI 尝试连接或重连服务器时增加，成功和失败都计入。对同一个已连接服务器多次调用工具，不会增加这个计数。因此它衡量的是连接行为，不是工具使用强度。

plugin 与 skill 不能相加。 plugin 指标只统计与 plugin 关联的 skill 调用。每一次 plugin 交互都会同时出现在 skill 总量里，但非 plugin 来源的 skill 交互只出现在 skill 总量中。plugin 总量是 skill 总量的子集，两者相加会重复计算。

空值与零值。 空数组和零计数表示没有匹配活动。当定制数据不可用时，这些字段为 null 或不存在。这两种情况在采集层需要区分处理。

从字段到可用指标

拿到这些字段之后，可以组织成几类可解释的指标，而不是把五个数字堆在一个面板上：

  • 采用面：用五个 distinct 计数判断五类对象中各自有多少在统计周期内出现过活动。
  • 集中度：用 top 5 数组观察活动是否集中在少数 custom agent 或 MCP server 上。高集中度通常意味着治理面收敛，但也意味着单点依赖。
  • 长尾：distinct 计数包含 top 5 之外的条目，因此 distinct 与 top 5 之间的差值可以反映长尾规模。长尾过长时，需要考虑清理或归档，而不是继续扩大定制目录。
  • 依赖面：distinct_mcp_use_count 可用于评估外部依赖广度，但要注意它统计的是连接尝试涉及的服务器数量，不是工具调用量。

需要提醒的是，distinct 计数在聚合报告中按“条目”而非“用户”去重，所以它回答的是“有多少种东西被用了”，不是“有多少人在用”。如果治理目标涉及人均渗透率，还需要结合按用户报告来推算。

三个容易踩的坑

第一个是把“配置存在”当成“被使用”。skills、custom agents、MCP servers 都是可以先定义再使用的对象，配置目录里的条目数量和实际调用量是两回事。用配置数量当采用度，会系统性高估。

第二个是把五类对象混进一个总数。custom agent 的启动、MCP server 的连接尝试、slash command 的触发，本身量纲不同，相加之后没有解释力，也无法跨团队对比。plugin 与 skill 之间还存在子集关系，更不能简单求和。

第三个是口径变更导致的时间序列断点。这次是在既有 API 上扩展字段，意味着变更之前的历史数据很可能不包含这些维度。做趋势图时需要显式标注起点，而不是让曲线看起来像“agentic 使用量从零爆发”。

边界

这次 changelog 已经明确了字段名、报告类型、计数口径、权限要求和隐私处理方式，工程团队可以据此设计采集层。但仍有需要以实际接口文档和真实响应为准的部分：字段在具体响应体中的嵌套结构、空值与缺字段在客户端解析时的具体表现、以及该能力当前的 GA 或预览状态。把这些当作接入前需要验证的工程细节，而不是把它当作已经可以直接上生产的数据源来设计，是更稳妥的路径。