GitHub Enterprise 纳入Copilot访问后许可管理有哪些调整

GitHub Enterprise 纳入 Copilot access 后，变化重点不是“所有用户自动获得无限 Copilot”，而是把企业的管理对象从单独购买 Copilot 席位，转成“谁通过 Enterprise 许可获得访问、哪些用量从预算中计费、哪些能力在预算耗尽后仍可用”。有 GitHub Enterprise Cloud 许可的用户不再产生单独的 Copilot 席位费；没有该许可的用户则使用 Copilot Standalone，当前公开说明为每用户每月 10 美元。

官方公告：https://github.blog/changelog/2026-10-28-github-enterprise-now-includes-access-to-github-copilot/

官方变更说明：https://docs.github.com/en/copilot/get-started/whats-changing-with-github-enterprise-and-copilot

这次调整改变的是许可和用量的分工

我看这类企业订阅变化时，通常先把“有没有访问权限”和“使用一次要不要消耗预算”拆开。GitHub 的新模型也是如此：Copilot access 为符合条件的 GitHub Enterprise Cloud 用户取消了单独的 Copilot 席位费，但并没有附送按用户分配的月度 AI credits。实际使用的模型和功能仍然受到企业策略与 spending controls 约束。

对没有 GitHub Enterprise Cloud 许可的成员，访问路径变成 Copilot Standalone，公开文档列出的费用是每用户每月 10 美元。这笔费用覆盖身份、访问、策略、安全和管理控制；计量用量仍然从第一次使用开始单独计算。两类用户可以在同一个企业的 Copilot access 模型中并存，但不要把它理解为可以同时叠加旧的 Copilot Business 或 Copilot Enterprise 席位。

管理员要从席位表转向预算表

原来更容易问“我们买了多少 Copilot 席位”，现在还必须问“每种功能会消耗多少企业预算”。官方说明把 AI usage 从第一笔请求开始计量，并沿用企业已有的 policies、alerts 和 attribution。也就是说，管理员要把用量归因和预算上限放到日常运营里，而不是只在月底看一张席位账单。

预算耗尽后的能力边界也需要单独记下来：

先按 Enterprise 许可把人分成两组

成本估算的第一步不是直接套一个人均价格，而是把用户按是否持有 GitHub Enterprise Cloud 许可分组。持有许可的用户不产生单独 Copilot 席位费；没有许可的用户则按 Copilot Standalone 计算席位部分。然后，两组用户的 AI 用量都要按照实际请求量进入企业预算。

这个分组会影响采购部门、平台管理员和开发团队之间的协作：采购看席位费用，平台团队看预算和策略，开发团队则更关心代码补全、Chat、代码评审等功能是否会因为预算不足而出现差异。

对照官方文档，Copilot Business 和 Copilot Enterprise 仍然保留按席位收费并带有共享的月度额度；Copilot access 则没有包含额度。做切换判断时，应使用同一个月度周期、同一批用户和同一套预计用量，把现有席位费、当前被额度覆盖的使用量、超额使用量，以及新模型下的全部计量使用量放在一起比较。只比较“旧模型目前的超额账单”会低估新模型的真实成本。

切换前要检查四个管理动作

第一，确认可用阶段。与 GitHub 或 Microsoft account team 合作的企业，从 2026 年 10 月 28 日起可以咨询设置新模型或迁移已有企业账户；自行管理订阅的客户目前仍在分阶段开放，现有订阅不受影响。不要因为公告已经发布，就把“可咨询”当成“所有自助客户马上可用”。

第二，重新分配席位。Copilot access 不会因为用户持有 GitHub Enterprise Cloud 许可就自动赋予 Copilot。企业所有者仍需把席位分配给具体成员、企业团队或组织，分配对象和许可对象要分别核对。

第三，先设预算再放量。检查 AI Controls 中的 AI credits paid usage policy，并设置用户级、成本中心级或企业级预算。若启用到达上限即停止使用的 spending limit，预算才会成为真正的硬边界；否则用量可能继续产生计量费用，具体还取决于企业策略。

第四，检查网络 allowlist。如果现有防火墙只允许 *.business.githubcopilot.com，官方迁移说明要求同时加入 *.enterprise.githubcopilot.com，否则通过 Enterprise Cloud 或 Copilot Standalone 的访问可能被网络策略打断。

什么情况下保留旧订阅更稳妥

我的判断是，Copilot access 更适合已经拥有较多 GitHub Enterprise Cloud 许可、愿意按实际用量管理预算、并且能接受没有月度包含额度的企业。它的优势是把 Enterprise 许可和 Copilot 访问放在一个管理模型里，减少一部分重复席位成本；代价是预算预测需要更细，重度使用者的波动会更直接地反映到账单上。

如果企业更看重包含额度带来的成本可预测性，或者自助订阅尚未获得资格，继续使用 Copilot Business 或 Copilot Enterprise 反而更容易安排。切换是自愿的，不会自动发生；已有订阅也不会因为公告发布就被强制迁移。已确认可迁移的企业还应和 account team 确认生效日期，因为官方说明要求迁移在某个月的第一天生效。

一张表完成最后判断

常见问题

GitHub Enterprise 用户会自动拥有 Copilot 吗？

不会。即使用户持有 GitHub Enterprise Cloud 许可，企业所有者仍需把 Copilot 席位分配给成员、企业团队或组织。

预算用完后 Copilot 会全部失效吗？

不会。代码补全和下一步编辑建议仍可用；Copilot Chat、代码评审和 Copilot in the cloud 等需要预算的功能可能无法继续使用，席位本身不会因此被移除。

可以在一个企业里同时用 Copilot access 和 Copilot Enterprise 吗？

不可以。官方说明允许在 Copilot access 内同时覆盖有 Enterprise Cloud 许可和没有该许可的用户，但同一个企业不能把 Copilot access 与 Copilot Business 或 Copilot Enterprise 两种旧席位模型混在一起。