GitHub 在 2026 年 10 月 19 日的 changelog 中宣布，Copilot 模型策略的 REST API 正式可用（GA）。此前企业管理员主要通过管理界面调整模型可用性，现在可以通过 GET 与 PATCH 端点，在四个层级上检索和更新模型策略。对于需要把 AI 编程工具纳入统一治理体系的企业，这是一项值得关注的基础设施变化。

四个层级的端点结构

官方给出的端点路径如下：

  • 企业级：/enterprises/{enterprise}/copilot/model-policies
  • 企业团队级：/enterprises/{enterprise}/teams/{team_slug}/copilot/model-policies
  • 企业应用级：/enterprises/{enterprise}/copilot/apps/model-policies
  • 组织级：/orgs/{org}/copilot/model-policies

四个层级共用同一套 GET/PATCH 语义：GET 用于读取当前生效的模型策略，PATCH 用于更新策略。路径中的 {enterprise}、{team_slug}、{org} 是占位符，调用时需要替换为实际标识。

这种设计的关键点在于层级而非端点数量。企业、团队、应用、组织四类对象各自拥有独立的策略入口，意味着模型可用性可以按治理单元分别表达，而不是只能做一次全局开关。

策略委派：企业模式与团队/应用模式

官方资料明确说明，企业策略可以把模型控制权下放：在 organization mode 下委派给组织，在 enterprise teams mode 下委派给团队和应用。

这实际上定义了两条治理路径。第一条是集中式：企业层直接决定模型可用范围，组织和团队只做执行。第二条是委派式：企业层设定边界后，把具体模型选择权交给组织，或交给团队与应用。

从工程角度看，委派模式的价值在于减少企业级策略的变更频率。模型迭代速度快，如果每一次模型上下线都需要企业管理员操作，治理成本会迅速上升。把选择权下沉到离使用场景更近的层级，可以让团队根据任务类型调整可用模型，同时企业层保留模式开关这一总闸。

需要注意的是，官方资料只说明了委派机制的存在，并未给出策略冲突时的具体优先级规则。落地前应查阅 REST API 文档中 ai-controls 相关章节，确认实际生效逻辑，不要基于假设设计继承关系。

权限边界：谁可以 PATCH

PATCH 是写操作，权限设计比 GET 更敏感。官方 changelog 没有逐条列出各端点所需的 token 权限范围，因此这里只能给出原则性建议：

第一，企业级端点应只授予企业管理员或专门的安全治理角色。它是委派模式的起点，一旦被滥用，下游所有层级的策略都可能被重置。

第二，团队级和应用级端点应绑定到对应的团队维护者或应用负责人，避免跨团队越权修改。

第三，组织级端点在委派模式下承担实际选择职责，应明确组织管理员与安全团队之间的职责划分。

第四，所有 PATCH 调用应通过服务账号或 GitHub App 发起，而不是依赖个人 token，以便在人员变动时保持审计连续性。

这些属于工程实践建议，具体权限范围需以官方 REST API 文档为准。

策略继承与审计实践

在策略继承方面，官方资料只提供了模式层面的描述：企业可以委派给组织，或委派给团队和应用。这意味着企业需要先明确自己处于哪种模式，再决定在哪一层写入策略。一个可执行的顺序是：先通过企业级 GET 读取当前模式与策略，确认委派方向；再对目标层级执行 GET，比对现状；最后才发起 PATCH。

审计方面，由于四个层级都可写，变更来源可能分散。建议把每次 PATCH 的调用者、目标层级、变更前后策略快照记录到企业自有日志系统，并与 GitHub 审计日志交叉核对。GET 端点本身也可以作为巡检手段：定期拉取各层级策略，检测是否存在未预期的模型开放。

边界与取舍

这套 API 解决的是模型可用性治理，不涉及用量配额、成本控制或代码补全质量评估。企业如果希望把模型策略与预算、合规审批联动，仍需在外部系统完成编排。另外，GA 意味着接口稳定，但官方文档仍是权限范围和继承细节的唯一权威来源，落地前应以其为准。

对于已经将 Copilot 纳入企业开发平台的企业，建议先把四个端点接入配置管理流水线，用 GET 做基线、用 PATCH 做受控变更，再逐步把委派模式开放给组织或团队。