GitHub Enterprise Cloud：企业统一许可证政策、编码智能体合规检查

1. 适用对象与政策设置

这项于 2026 年 10 月 16 日公布的功能面向 GitHub Enterprise Cloud 客户，也包括指定数据存储区域的客户，且应用该功能的仓库必须启用 GitHub Code Security。该功能在 6 月公开预览后转为正式提供。

该功能扩展了现有依赖项审查工作，引入适用于整个企业的许可证政策。这里的依赖项指项目使用的外部软件包。其方式是制定企业统一的许可标准，并将其关联到各仓库的检查中。

应用政策时，需通过汇集检查条件的规则集指定目标仓库。此时使用 Require license compliance results before merging，即要求合并前提供许可证合规结果的条件。其结构与现有代码扫描条件类似，均关联到仓库规则。

2. 违规提示与关闭请求审核

开发者发起添加或修改依赖项的拉取请求时，系统会自动检查新增或变更依赖项的许可证。每个不符合标准的依赖项都会在拉取请求中显示一条消息，开发者可在该请求中确认需要处理哪些项目。

这些消息需要处理。原文给出的方法包括移除或替换依赖项、修改许可证政策，以及创建软件包例外。因此，出现违规提示并不意味着必须无条件放弃该软件包。

负责审核和批准关闭请求的人员可获授新设的企业级预定义角色。该角色名为 Enterprise Open-Source License Manager，可分配给个人或团队。负责人会通过电子邮件收到待处理请求的通知，并可在企业管理控制台中审核。

3. 政策管理与智能体 API

公开预览之后，指定数据存储区域的客户也获得了许可证信息。这些信息不仅用于合规检查，还体现在展示软件包间依赖关系的依赖关系图和软件物料清单导出中。物料清单是列出软件所含组件的清单。

许可证政策变更时，审计日志会记录事件。这项功能记录变更情况，以便与外部记录系统集成。此外还新增了用于下载、更新或替换企业许可证政策的 API。

另外新增的软件包合规检查 API 可帮助编码智能体避免推荐或在代码中引入违反企业许可证使用政策的软件包。这意味着，除了拉取请求阶段的检查之外，智能体还可在选择软件包时用它核查政策。

4. 应区分自动检查与人工判断

采用该功能的效果在于将统一政策关联到仓库的变更审查流程。开发者添加或修改软件包时，可自动确认是否符合标准，但仍需判断是移除违规项，还是修改政策或例外。应同时考虑检查自动化的收益与政策运营、请求审核的负担。

确定适用对象时，应区分企业整体政策与通过规则集指定的仓库。原文说明的启用方式是指定目标仓库，并未表示会自动应用于企业的所有仓库。

公告附有详细设置指南和 API 文档的链接，但未提供具体的请求与响应格式或代码示例。准备实际集成时，不应仅凭公告中的功能说明确定实现方式，而应查阅链接文档。

此次变化的核心在于，不再仅依赖开发者逐一检查许可证，而是将其与企业统一政策及自动检查相结合，同时仍由负责人判断政策变更和请求审批。