">

GitHub Copilot 用量指标开始显示自建 skill、Agent 与 MCP 服务器的名称

GitHub 于 2026 年 10 月 22 日更新 Copilot 用量指标:企业与企业组织报表里的自定义项由名称替代原有的 other / custom 归类,涉及 skill、自定义 agent、MCP 服务器、斜杠命令与插件,每类每份记录最多展示 25 条。

这次发布的是什么

GitHub 于 2026 年 10 月 22 日在官方 Changelog 发布一项 Copilot 用量指标(usage metrics)更新。此前企业与企业组织报表里,团队自己做的 skill、自定义 agent、MCP 服务器、斜杠命令与插件都被笼统归到「other」或「custom」一类;现在对应的统计数组会显示每一项配置时的名称。与此同时,每类清单每份记录最多展示 25 项,此前为 5 项,超出部分合并到末尾条目。

官方把它描述为 9 月那次「命令行端定制化指标」的延续:从「知道有人在用」推进到「知道大家具体在用哪个」。

可用性与限制

  • 适用对象:面向企业所有者与账单管理员、组织所有者,以及持有带「View Copilot Metrics」权限的自定义组织或企业角色的成员。
  • 前置开关:Copilot 用量指标策略必须处于开启状态,未开启的组织在报表里看不到这部分数据。
  • 数据来源:客户端遥测。官方明确提示,在客户端版本过旧或遥测被屏蔽时会少计,因此这套数据用于看趋势与采纳度,不宜作为精确核算依据。
  • 覆盖渠道:名称上报来自 Copilot 命令行(交互会话与提示模式)、Copilot 应用、ACP(智能体客户端协议)集成(例如 JetBrains)以及 Copilot SDK;IDE 内置的聊天渠道不上报名称。
  • 版本要求:命令行 1.0.97 及以上(提示模式、应用与 ACP 集成);Copilot SDK v1.0.21 及以上。
  • 历史数据:名称只在本次更新之后处理的报表日开始出现,更早的日期仍沿用旧的归类方式。

主要功能

  • 按名称查看团队自建 skill 的使用分布
  • 按名称查看自定义 agent 的采纳情况
  • 按名称统计自建 MCP 服务器的调用
  • 每类清单从 5 条扩到 25 条,覆盖更长的尾部
  • 在按用户的 1 天 / 28 天报表与聚合报表中同步生效

技术原理

据官方说明,这次改的是指标里「条目如何标识」这件事。此前客户端上报自定义项时只打个汇总标签,服务端也就无法区分,于是全都被塞进 other 或 custom;现在把配置名称一并带上来,并在落库前做统一处理:名称按配置原样保留并截断到 128 字符以内,形似文件路径的名称仍归入 other —— 这一步是为了避免本地路径信息被写进对外报表。

计数口径没有变化:交互次数与各维度的去重使用数的计算方式与之前完全一致。所以这次更新只会让报表「看得更清楚」,不会让总量发生跳变,这正是企业账单管理员最关心的那一点。

实际体验

本文未做实测,以下是官方说明可直接核对的两点。其一,对现有报表脚本是兼容的:字段结构与总数不变,只是原本写死的 other / custom 分支需要改成按名称匹配;如果你的看板此前把自定义项合并计数,现在可以拆开展示了。其二,名称来自客户端遥测,团队里只要有人用旧版本客户端或禁用了遥测,就一定会出现漏记 —— 所以它适合回答「上周推的那个内部 agent 到底有没有人用」,不适合用来给团队做考核基数。

另外,官方建议把报表分享到组织外部之前先看一遍名称:内部项目的真实名字会随报表一起出现。

项目地址与获取方式

  • 官方更新说明:https://github.blog/changelog/2026-10-22-custom-skills-agents-and-mcp-servers-in-usage-metrics-api/
  • 用量指标接口文档:https://docs.github.com/rest/copilot/copilot-usage-metrics
  • Copilot 相关更新汇总:https://github.blog/changelog/2026/?label=copilot
  • 请通过 GitHub 官方渠道开通与调整策略,避免使用第三方脚本代采遥测数据。

适合谁用

  • 已经沉淀出内部 skill、自定义 agent 或私有 MCP 服务器的企业:终于能看出哪些资产真在用。
  • 刚推广某项自定义能力、需要看采纳曲线的团队负责人。
  • 需要给不同业务线做用量归因的企业账单管理员。
  • 不必用:个人开发者与单人账号 —— 这些报表本来只面向企业与企业组织,且需要对应的查看权限。

常见问题

更新之后,历史报表会补上名称吗?

不会。官方说明名称从本次更新之后处理的报表日开始出现,更早日期的报表仍旧沿用旧的归类方式。如果需要连续的时间序列,建议以更新日作为切分点,而不是直接拼接前后两段。

客户端版本不够会怎样?

用量仍会被计入,但名称上报缺失,相关条目会落回旧的归类。命令行需要 1.0.97 及以上,走 SDK 与 IDE 的渠道则需要 SDK v1.0.21 及以上。

内部项目名称会不会泄露?

名称按配置原样保留并截断到 128 字符,形似文件路径的名称会被归入 other 以避免暴露本地路径。但项目本身的真实名称仍会进报表,分享给外部之前建议先人工过一遍。

计费口径变了吗?

没有。交互次数与各维度去重使用数的算法与之前一致,本次只是把这些自定义项的标识从「汇总标签」改成了「具体名称」。

相关工具与内容

Related
快讯 6 小时前

MCP 官方参考服务器 2.1.0:修复 8 个安全漏洞

Model Context Protocol 官方参考服务器仓库于 2026 年 10 月 25 日发布 v2.1.0,一次修掉分布在 filesystem、everything、fetch 三个参考服务器里的八个漏洞,并给出每个包的受影响版本区间与修复版本;其中文件系统服务器的写入重定向问题在 Windows 上仍只是部分修复。

前沿快讯 18 阅读
快讯 6 小时前

Open WebUI 0.12.4:技能按需加载与上下文压缩

自托管大模型前端 Open WebUI 于 2026 年 10 月 25 日发布 0.12.4:技能支持按需加载、上下文压缩在聊天里可见且覆盖到更多场景,管理员可按角色隐藏界面控件并自动隐藏不可用的选项;同时改了三项默认行为,其中 Direct Integrations 默认关闭会让已保存的连接停止生效。

前沿快讯 14 阅读
快讯 6 小时前

Pydantic AI 2.61.0:引用结构化与新模型名入库

Python 智能体框架 Pydantic AI 于 2026 年 10 月 24 日发布 2.61.0:把引用做成结构化数据并统一多个云厂商的返回格式、能按原始产出方回放引用,新增 kimi-k3.1-pro 与 kimi-k3.1-pro-highspeed 两个模型名,同时把持久化引擎的扩展接口转为公开,并收紧了输入护栏的默认行为。

前沿快讯 20 阅读

继续阅读:NVIDIA 推出 Minerva:面向 AI 工厂的可观测性运维平台 · OpenAI Decisions API 正式可用,专做答案空间有限的小决策

关于本文:本站文章由编辑部独立撰写,评测口径与免责说明见关于我们。想继续找工具,可从分类导航按场景浏览,或回首页搜索。

链接已复制