GitHub 于 2026 年 7 月 17 日宣布，Copilot usage metrics REST API 现在支持 repository-level activity。企业和组织可以使用新的每日 API 报告，按 repository 查看 Copilot coding agent 和 Copilot code review 产生的 Pull Request 活动。
这次更新提供两个按日查询的 endpoint：enterprise 层级是 /enterprises/{enterprise}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD，organization 层级则是 /orgs/{org}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD。返回内容会列出 coding agent 创建及合并的 Pull Request，也会列出 code review 审查的 Pull Request，以及按 comment type 拆分的 suggestion count。
过去 Copilot usage metrics 主要停留在 organization 和 user 层级，管理者可以知道谁在使用，但未必知道使用集中在哪些 codebase。repository-level data 把视线拉近到实际工程环境，GitHub 认为它可以成为 repository insights 和 AI-readiness reporting 的基础，帮助团队把 enablement 投放到最需要的 repository。
这种数据粒度对 Agent 管理有两面性。一方面，团队终于可以把“使用了多少 AI”和“哪些项目真的有 Agent 产生或审查 Pull Request”联系起来；另一方面，Pull Request 数量本身不是生产力答案。要判断 Agent 是否有价值，还要一起看 review turnaround、变更失败率、安全警报、重做次数、人工审批时间，以及最终交付的质量。
GitHub 也列出权限条件：enterprise owner、billing manager、organization owner，或具备 View Copilot Metrics 权限的自定义角色可以访问报告，而且 Copilot usage metrics policy 必须已经启用。这提醒企业先处理数据范围、角色权限和保留政策，再把指标接入内部 dashboard；如果所有人都可以查看所有 repository，metrics 很快就会变成另一个数据治理问题。
对于采用 AI coding agent 的团队来说，这次更新的价值在于提供更接近工作成果的观察面。座位数、消息数和 token 用量可以作为成本信号，但 repository-level Pull Request 活动更接近流程实际发生的位置。下一步仍是把这些信号与 code review、CI、安全和人工判断放在同一个评估框架，而不是用单一数字替代工程决策。
