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）
• 更多的模型访问与管理能力

除 Copilot Enterprise 订阅本身外，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 handler？”
• “我们的平台团队推荐使用哪款认证库？”
• “这个微服务应使用哪种部署流程？”
• “我们的后端团队遵循哪些命名规范？”

Spaces 支持的内容

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

支持的内容类型包括：

• 代码文件
• Markdown 文档
• JSON 文件
• 上传文件
• 图片
• GitHub Issues
• 拉取请求

每种内容类型的贡献方式不同。

代码文件帮助 Copilot 理解实现模式；Markdown 文件提供架构说明与入职指引；拉取请求包含评审讨论与历史工程决策。三者结合，使 Copilot 更了解您的组织开发实践。

一个重要但容易忽视的点是：Spaces 不只是附着在 GitHub 上的向量数据库。它还包含共享控制与组织治理工作流，专为企业环境设计。

Knowledge Bases 的停用

GitHub 于 2025 年 11 月 1 日停用了旧的 Copilot Knowledge Bases 功能。

Spaces 替代了 Knowledge Bases，带来：

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

您仍会看到引用 Knowledge Bases 的过时文档与博文。跟随旧教程时请谨慎，因为 2025 至 2026 年过渡期中，许多端点与工作流已发生变化。

创建与配置 Copilot Spaces

从管理角度看，创建 Copilot Spaces 相对直接。挑战在于跨团队管理数十甚至数百个 Space。

早期选择的结构往往会沿用很久。我见过不少组织因为缺乏前期的所有权规则，而在 Spaces 内部无意间造成“文档蔓延”。

任何人都可以创建 Copilot Space，我们不妨先在个人仓库中试做一个。企业级的步骤类似，只是页面有所不同。

设置 Space

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

1. 在企业管理区域中，进入 Copilot Spaces 页面
2. 创建一个新 Space

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

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

5. 此阶段可选择共享 Space 或设置共享选项

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 支持两种主要可见性模型：

• 个人 Space
• 组织范围的 Space

企业成员的个人 Space 可受企业级设置管理。企业管理员也可集中管理预览与功能可用性策略。

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

一个常见误区是过度集中化。单一且巨大的全公司 Space 容易变得嘈杂，也更难让 Copilot 有效使用。

按团队或领域组织 Spaces

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

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

每个团队一个 Space

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

示例：

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

每个产品领域一个 Space

适用于按产品而非按部门来组织的公司。

示例：

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

共享标准类 Space

许多组织会单独维护一个共享 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 使用指标仪表板示例

API 衡量的内容

Usage Metrics API 提供多类运营遥测数据。

常见指标包括：

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

这比单纯的席位数量能提供更细致的画像。

一个拥有 100 个已分配席位但仅 15 名活跃用户的团队，与一个每日稳定使用且接受率高的团队，其采用画像截然不同。

2026 年的 API 过渡

GitHub 在 2025 至 2026 年的过渡期中，停用了多个早期遥测 API（用户级功能参与度指标 API、直接数据访问 API、Copilot Metrics API），并于 2026 年 4 月彻底下线。

这些包括：

• 旧版 Metrics API
• 功能参与度 API
• 直接数据访问 API

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

这点很重要，因为许多旧博文与 GitHub 示例仍在引用已弃用的端点。使用 Usage Metrics API 时，请务必将文档与 GitHub 最新 API 参考对照，避免在过时端点上构建自动化。

查询 Usage Metrics API

既然了解了 usage metrics API 的目的，接下来讨论实际的使用方式。

身份验证与权限

GitHub Copilot Usage Metrics 端点通常需要为您的个人访问令牌（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 Tutorial 涵盖了设置与常见工作流。

构建 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 技能路径。