GitHub Copilot Enterprise：Spaces 与 Usage Metrics API 指南

什么是 GitHub Copilot Enterprise？

GitHub Copilot Enterprise 处于GitHub Copilot 方案层级之巅。

与 GitHub Copilot Business 或 Pro+ 相比，Enterprise 更侧重治理、组织上下文与度量能力。它面向运行大型工程环境的公司，而非个体开发者或小型团队。

实际使用中，两个能力最为关键：

1. 通过 Spaces 提供自定义组织上下文
2. 通过 Usage Metrics API 提供组织范围的遥测

这两项功能让 Copilot 从“智能自动补全”进化为更接近内部 AI 工程平台的工具。

从 GitHub Copilot Enterprise 获得最大价值的公司，会将其视作内部基础设施的关键组成部分。他们谨慎配置组织上下文，持续衡量采用情况，并基于使用数据而非假设来调整策略。

若想更全面了解 GitHub 生态系统，建议阅读我们的指南 Introduction to GitHub Products。

Enterprise 与 Business、Pro+ 的差异

GitHub Copilot Enterprise 在 Business 订阅的基础上扩展了以下功能：

• 组织级使用指标
• 扩展的治理控制
• 企业范围的策略继承
• 更大的高级请求配额（Business 等级为 300，Enterprise 为 1,000）
• 更多模型访问与管理

Enterprise 除了 Copilot Enterprise 订阅本身，还需要 GitHub Enterprise Cloud。这会为每位用户带来额外成本，因此请确保您的组织确实需要治理、遥测与企业级管理能力。

注意：Business 订阅者可在组织级访问 Usage Metrics API（/orgs/{org}/…）。Enterprise 订阅者则还可访问企业级汇总报表（/enterprises/{enterprise}/…），在一个视图中覆盖所有组织。

GitHub Copilot Enterprise 适用对象

GitHub Copilot Enterprise 面向已运行成熟 GitHub 环境的组织。

典型的 Enterprise 客户包括：

• 大型工程组织
• 受监管行业
• 多团队的平台工程组织
• 具有内部开发标准的公司
• 需要集中治理的组织

请注意，这并不会直接提升 Copilot 的性能。我认为这一点很重要，因为许多团队最初会“超配”。他们以为 Enterprise 等于“更好的 Copilot”，而事实上 Enterprise 主要增加的是治理与度量工具。

Copilot Spaces：为您的组织提供自定义上下文

Copilot Spaces 解决了通用型 AI 编码助手的一个主要短板。

开箱即用的 Copilot 能较好理解公开的编程知识。但它不会自动理解您内部的 API、架构决策、编码规范、部署流程或入职文档。

Spaces 提供经过整理的组织上下文，Copilot 可在对话与辅助编码时引用。

在实际层面，Spaces 帮助 Copilot 回答如下问题：

• “我们内部如何组织 API 处理程序（handlers）？”
• “我们的平台团队推荐使用哪一个认证库？”
• “这个微服务应使用哪种部署工作流？”
• “我们的后端团队遵循哪些命名约定？”

Spaces 支持的内容

与较早的 Knowledge Bases 系统相比，Spaces 支持更广泛的组织内容。

支持的内容类型包括：

• 代码文件
• Markdown 文档
• JSON 文件
• 上传文件
• 图像
• GitHub Issues
• Pull Requests

不同内容类型的贡献点各不相同。

代码文件帮助 Copilot 理解实现模式。Markdown 文件提供架构说明与入职指引。Pull Request 揭示评审讨论与历史工程决策。该组合让 Copilot 更加了解您组织的开发实践。

有一点微妙但重要：Spaces 并非只是附加在 GitHub 上的向量数据库。它们包含面向企业环境设计的共享控制与组织治理工作流。

Knowledge Bases 的下线

GitHub 于 2025 年 11 月 1 日下线了旧版 Copilot Knowledge Bases 功能。

Spaces 以以下改进取代了 Knowledge Bases：

• 更广泛的内容支持
• 更完善的共享控制
• 改进的管理能力
• 更灵活的组织级管理

您仍会看到引用 Knowledge Bases 的过时文档和博客文章。在参考旧教程时请谨慎，因为 2025 至 2026 年过渡期间，许多端点与工作流均已变化。

创建与配置 Copilot Spaces

从管理角度看，创建 Copilot Spaces 相对简单。真正的挑战在于如何在跨团队的几十或上百个空间中进行管理。

早期选择的结构往往会固化。我见过一些组织在 Spaces 内无意间制造了“文档扩张”，只因没人事先制定所有权规则。

任何人都可以创建 Copilot Space，我们先在个人仓库中试着创建一个。在 Enterprise 层级步骤相似，只是界面页面略有不同。

创建 Space

创建 Space 一般遵循如下流程：

1. 进入 Enterprise 管理区域中的 Copilot Spaces 页面
2. 创建一个新的 Space

3. 选择代码仓库与内容来源，包括 MCP 与其他实用工具

4. 通过右侧“+ Add sources”按钮添加来源

5. 此阶段可选择共享该空间或设置共享选项

6. 验证 Copilot 能在聊天交互中引用这些内容

给企业用户的提示：您的管理员可以关闭个人 Spaces 的共享。因此，如果您使用个人账户，可能会影响您共享未使用企业仓库的 Copilot Space 的能力。

设置完成后，管理员应使用贴近实际的提示对该 Space 进行测试。

例如：

How does our authentication middleware handle token refresh logic?

或者：

Show me an example of how our backend services structure database migrations.

如果 Copilot 无法准确回答，问题通常在于：

• 缺少必要的代码仓库
• 文档质量欠佳
• 权限配置有误
• 索引时间不足

共享与访问控制

Spaces 支持两种主要的可见性模型：

• 个人 Spaces
• 组织范围的 Spaces

企业成员的个人空间可受企业更高层设置进行管理。Enterprise 管理员也可集中管理预览版与功能可用性策略。

私有 Spaces 适合实验性团队或敏感的内部项目。组织范围的 Spaces 则适用于工程标准、入职文档或公司级的框架。

我经常看到的一个错误是过度集中。一个单一且庞大的全公司 Space 往往会变得嘈杂，难以让 Copilot 有效利用。

按团队或领域组织 Spaces

并不存在放之四海皆准的组织结构。

常见模式包括每个团队一个空间、每个产品域一个空间，或共享的标准空间。它们范围各异，但基本上以不同方式使用相同的设置空间。

每个团队一个 Space

适用于工程团队相对独立运作的情形。

示例：

• 平台工程
• 数据工程
• 移动开发

每个产品域一个 Space

适用于围绕产品而非部门进行组织的公司。

示例：

• 支付
• 分析
• 基础设施
• 客户平台

共享标准 Space

许多组织会维护一个独立的共享空间，用于：

• 安全指南
• 编码规范
• 部署工作流
• 架构标准

实践中，混合方案通常更有效。每个团队拥有自己的空间，同时共享较大的标准空间。

Copilot Usage Metrics API

Spaces 解决了上下文问题。Usage Metrics API 则解决了度量问题。它取代了 GitHub 在 2026 年 API 整合期间淘汰的若干旧遥测系统。

如果缺少清晰的度量，组织将很快失去对 Copilot 采用是否成功的可见性。管理层需要证据，证明这项投入确实改善了开发者的工作流，而不是仅仅新增了一条订阅费用。

该仪表板于 2026 年 2 月普遍可用，可通过您的企业账户 → AI Controls → Copilot → Metrics → Insights 选项卡中的 Copilot usage metrics 访问。

github.blog 中的 Copilot Usage Metrics Dashboard 示例

API 衡量的内容

Usage Metrics API 暴露了多个类别的运维遥测。

常见指标包括：

• 活跃用户
• 建议代码行数 vs 接受的代码行数
• IDE 使用模式
• 模型使用情况
• Agent 交互
• 语言分布

这比简单的席位数为组织提供了更细致的画像。

一个分配了 100 个席位但只有 15 个活跃用户的团队，其采用状况与一个日常稳定使用、接受率高的团队截然不同。

2026 年的 API 过渡

GitHub 在 2025 至 2026 年过渡期间下线了多个早期遥测 API（用户级功能参与度指标 API、Direct Data Access API、Copilot Metrics API），并于 2026 年 4 月全部停止服务。

这些包括：

• 旧版 Metrics API
• Feature Engagement APIs
• Direct Data Access APIs

自 2026 年 2 月起可用的新 Usage Metrics 端点整合了这些报表系统为更统一的模型，并在发生破坏性变更时对这些 API 进行版本化。

这点很重要，因为许多旧博客与 GitHub 示例仍引用已弃用的端点。使用 Usage Metrics API 时，在构建自动化之前请始终对照 GitHub 的最新 API 文档进行核验。

查询 Usage Metrics API

了解使用指标 API 的目的后，下面谈谈实际使用方式。

身份验证与权限

GitHub Copilot Usage Metrics 端点通常需要为您的 Personal Access Token（PAT）设置一些权限。这可通过经典 PAT 或细粒度 PAT 完成。

• 对于经典 PAT，您需要企业管理员为您授予以下权限：manage_billing:copilot 和 read:org。

• 对于细粒度访问令牌，需确保使用 GitHub 应用的用户访问令牌或安装访问令牌，并设置 Enterprise Copilot metrics enterprise permissions (read) 权限。

通常更推荐使用细粒度令牌，因为它能减少不必要的权限暴露。

组织级端点

最常见的两种组织级报表是：

• organization-1-day

• organization-28-day

单日组织级报表

单日报表适用于运维监控与短期趋势分析。历史数据可追溯至 2025 年 10 月 10 日，并可在距今一年内访问。

下面的 curl 命令会调用单日报表指标 API，并返回包含使用报表下载链接的 JSON 响应。您需要在 Bearer 鉴权中包含 YOUR_TOKEN，并以 YYYY-MM-DD 格式在 DAY 中指定需要的日期。

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
"https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-1-day?day=DAY"

download_links 中的 URL 是签名且限时有效的，这意味着它们会在检索后不久过期。您的工作流必须在同一次运行中先获取下载 URL，然后立刻拉取文件；不能将这些 URL 留作后用。

您获得的响应可能只包含 download_links 和 report_day，但完整的潜在模式如下：

{
  "type": "object",
  "title": "Copilot Metrics 1 Day Report",
  "description": "Links to download the Copilot usage metrics report for an enterprise/organization for a specific day.",
  "properties": {
    "download_links": {
      "type": "array",
      "items": {
        "type": "string",
        "format": "uri"
      },
      "description": "The URLs to download the Copilot usage metrics report for the enterprise/organization for the specified day."
    },
    "report_day": {
      "type": "string",
      "format": "date",
      "description": "The day of the report in YYYY-MM-DD format."
    }
  },
  "required": [
    "download_links",
    "report_day"
  ]
}

28 天组织级报表

28 天报表有助于识别更广泛的采用模式与长期使用变化。命令非常相似，仅对 28 天 API 做小幅调整。

示例请求：

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-28-day/latest

您将获得类似的响应，只是会包含 response_start_day 与 response_end_day。

组织级报表结构

组织单日与 28 天的 JSON 报表可能如下所示：

[
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  },
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 43,
    "slug": "backend"
  },
  {
    "user_id": 1002,
    "user_login": "hubot",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  }
]

如您所见，它为特定组织内的用户、所属团队及团队标签提供了高层概览。

用户级端点

用户级报表提供更细粒度的采用可见性。这意味着您可以在较高层面了解个人如何使用 Copilot。

常见端点包括：

• users-1-day

• users-28-day

• user-teams-1-day

这些报表帮助管理员识别：

• 高度活跃的用户
• 采用度低的团队
• 培训机会
• 部门级使用趋势

这些请求与组织级的单日与 28 天报表非常相似，只是指向了不同的 API。

单日用户级报表

users-1-day API 调用示例：

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-1-day?day=DAY"

28 天用户级报表

users-28-day API 调用示例：

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
   https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-28-day/latest

单日用户-团队级报表

还存在一个 user-teams-1-day 端点，用于将每位用户映射至其团队成员关系。本身不包含使用指标；其目的是作为联接键，以便将按用户的数据聚合到团队层级。

用户级报表结构

由于指向特定用户的使用数据，这些报表的细节程度要高得多：

[{
  "code_acceptance_activity_count": 1,
  "code_generation_activity_count": 1,
  "day": "2025-10-01",
  "enterprise_id": "1",
  "loc_added_sum": 8,
  "loc_deleted_sum": 0,
  "loc_suggested_to_add_sum": 10,
  "loc_suggested_to_delete_sum": 0,
  "totals_by_cli": {
    "last_known_cli_version": {
      "cli_version": "1.0.8",
      "sampled_at": "2025-10-01T00:01:43.000Z"
    },
    "prompt_count": 2,
    "request_count": 2,
    "session_count": 2,
    "token_usage": {
      "avg_tokens_per_request": 4400.0,
      "output_tokens_sum": 5000,
      "prompt_tokens_sum": 3800
    }
  },
  "totals_by_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_ide": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "ide": "vscode",
    "last_known_ide_version": {
      "ide_version": "1.85.0",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "last_known_plugin_version": {
      "plugin": "",
      "plugin_version": "",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_language_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "language": "unknown",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0
  }],
  "totals_by_language_model": [],
  "totals_by_model_feature": [],
  "used_agent": false,
  "used_chat": false,
  "used_cli": true,
  "user_id": 1,
  "user_login": "login1",
  "user_initiated_interaction_count": 0,
  "etl_id": "green",
  "day_partition": "2025-10-01",
  "entity_id_partition": 1
}]

这些指标最有价值的用途，在于作为团队层面的采用信号。接受率与使用次数是运维信号，而非开发者质量的度量。

关于您可能看到的完整潜在指标，请参阅 GitHub 使用指标数据文档，以获取最新的度量项。

用户级报表包含 CLI 交互数据。如果您的团队通过命令行使用 Copilot，我们的 GitHub Copilot CLI 教程涵盖了设置与常见工作流。

构建 Copilot 报表工作流

手动调用 API 有助于实验与理解模式。要转化为可执行洞见，最好构建自动化工作流。

从 Copilot Enterprise 获益最多的团队，通常会构建轻量级报表管道，将使用遥测与内部工程指标结合。

证明 ROI 的关键指标

并非所有 Copilot 指标都同等重要。最有用的通常包括：

• 活跃用户增长
• 接受率趋势
• 建议代码与保留代码的对比
• PR 周期时间的改善
• IDE 参与频率

GitHub 发布过如下基准：

• 任务完成速度提升 55%
• 代码保留率 88%

这些数字显示出显著的生产力提升。您的结果会因团队与工作流而异，这也正是 Usage Metrics API 存在的意义。后端基础设施团队与前端原型团队使用 Copilot 的方式可能截然不同。

从原始数据到团队仪表板

轻量级的报表工作流通常如下：

1. 定时调用 API
2. 将响应存入数据库或电子表格
3. 将数据转换为报表用表
4. 在现有 BI 平台中可视化指标

技术栈本身不如一致性重要。

即便是使用定时 Python 脚本与 CSV 导出的简单工作流，也能提供有用的运维可见性。

示例架构：

GitHub API

  ↓

定时 Python 脚本

  ↓

PostgreSQL / CSV / 电子表格

 ↓

Power BI / Tableau / Looker

结语

GitHub Copilot Enterprise 的核心在于为 AI 就绪的代码构建起您的基础设施。Spaces 提供组织上下文，使 Copilot 在真实工程环境中更有用。Usage Metrics API 则提供所需的遥测，帮助判断采用是否成功。

从 Copilot Enterprise 中获得最强成果的组织通常具备共同特征：

• 他们谨慎策划内部上下文
• 他们持续监测采用情况
• 他们严肃对待 Copilot 治理
• 他们用结果说话，而非想当然地认为能带来生产力提升

这种思维方式远比单纯分配席位重要。

如果您想进一步提升 Copilot 与 AI 技能，建议学习我们的 Software Development with GitHub Copilot 课程，或完整的 AI for Software Engineering 技能路径。