TOPIC COLLECTION
GitHub Copilot模型策略API上线：企业、组织、团队怎么用REST批量开关模型，和网页后台比省在哪
GitHub在2026-10-19宣布Copilot模型策略REST API正式可用：企业、企业团队、企业应用、组织四个层级都能用GET读取、PATCH修改模型可用性。适合管理多个组织的管理员把模型开关写进脚本、做配置审计，赶上模型退役时批量迁移。
资料更新：2026-10-20
依据GitHub Changelog（2026-10-19）。本站没有企业版测试环境，文中请求示例只演示读取接口，PATCH请求体字段以GitHub官方REST文档为准。核查2026-10-20（新加坡时间）。
主题标签：GitHub Copilot、Copilot模型策略、REST API、企业管理、AI编程
管过几十个GitHub组织的人应该都有过这种经历：Copilot上了个新模型，或者某个老模型要下线，你得一个组织一个组织点进设置页去改开关。点到第十几个的时候，基本已经记不清哪个改过、哪个没改。
10月19日（美国时间）GitHub在Changelog里发了一条不太起眼的更新：Copilot模型策略的REST API正式可用了。原来只能在网页后台点的那些「允许哪些模型」，现在能用接口读、用接口改。新加坡时间是10月20日清晨发出来的，同一天GitHub还发了一批模型退役公告，两件事放在一起看会更明白它的用处。
这次到底开放了什么
官方给了四个层级的接口，每个层级都有GET（读取）和PATCH（修改）两种方法：
| 层级 | 接口路径 | 谁会用到 |
|---|---|---|
| 企业 | /enterprises/{enterprise}/copilot/model-policies |
企业所有者，定全局规则 |
| 企业团队 | /enterprises/{enterprise}/teams/{team_slug}/copilot/model-policies |
按团队分配Copilot的企业 |
| 企业应用 | /enterprises/{enterprise}/copilot/apps/model-policies |
需要单独控制某些Copilot应用模型的企业 |
| 组织 | /orgs/{org}/copilot/model-policies |
组织所有者，在企业允许的范围内细调 |
状态是GA（正式可用），不是预览。这一点对企业来说挺关键，很多公司的规定是预览接口不能进生产脚本。
两种委派模式，先搞清楚自己是哪种
官方原文里有一句容易被跳过的话：企业策略可以把模型控制权委派给组织（组织模式），也可以委派给团队和应用（企业团队模式）。
换成大白话：
- 如果你们公司是「一个企业账号下面挂很多组织」，每个组织自己买Copilot座位、自己管，那就是组织模式。企业层定上限，组织层在上限里挑。
- 如果你们是用企业团队来分配Copilot，那控制权会落到团队和应用这一层，组织层的开关就不是主要入口了。
写脚本之前一定先确认模式。一个常见的坑是：管理员在组织层改了半天，结果企业是团队模式，改动根本不是生效的那一层。用GET把四个层级都读一遍，看哪一层返回的才是真正在管事的配置，这一步别省。
和网页后台比，好处在哪
| 对比项 | 网页后台手动改 | 用REST API |
|---|---|---|
| 改10个以上组织 | 一个个点，容易漏 | 一个循环跑完 |
| 留痕 | 靠审计日志翻 | 配置JSON放进仓库，每次改动有PR记录 |
| 巡检 | 人工抽查 | 定时GET对比，发现有人私改就报警 |
| 模型退役迁移 | 收到邮件后挨个处理 | 脚本批量切换到替代模型 |
| 门槛 | 会点鼠标就行 | 需要令牌、权限和一点脚本能力 |
小团队、只有一两个组织的，其实没必要折腾，后台点一下更快。这个API真正的用户是那种组织数两位数起步、有专门平台团队的公司。
为什么偏偏是现在
同一天GitHub还宣布了一批Copilot模型在多数体验里停用，站内写过迁移清单：10月19日Copilot模型下线怎么迁移。更早公布的11月16日那一批也还没到期，详情见Copilot三款模型11月16日退役。
模型更新越来越频繁，一年下来要处理好几轮「新模型要不要开、旧模型什么时候关」。每轮都靠人工点，迟早出错。GitHub把这个口子打开，等于默认大企业以后会用配置即代码的方式来管Copilot。
落地步骤：我会这么做
第一步：先只读，摸清现状
用有足够权限的账号生成令牌（企业层需要企业所有者，组织层需要组织所有者，具体权限范围看官方文档），先跑GET：
curl -s
-H "Accept: application/vnd.github+json"
-H "Authorization: Bearer $GH_TOKEN"
https://api.github.com/orgs/你的组织名/copilot/model-policies把每个组织、每个层级的返回都存下来。令牌放环境变量，别写进脚本文件，更别提交到仓库。
第二步：把结果放进一个私有仓库
按层级建目录，一个组织一个JSON。以后谁要改策略，就改这个仓库里的文件、开PR、让安全或平台负责人审核。合并之后再由脚本推送。
第三步：改之前先在测试组织试
PATCH写错的后果是整个组织的开发者突然用不了某个模型，或者反过来，开放了公司没批准的模型。请求体的字段名和取值，务必照官方REST文档来，最稳的办法是拿GET的返回结构做模板，只改需要改的那一项。
第四步：改完再读一遍
PATCH返回成功不等于你想要的效果生效了，尤其是存在委派的时候。改完立刻GET核对，再让一两个开发者在IDE里看看模型列表有没有变化。
第五步：加一个定时巡检
用GitHub Actions每天跑一次GET，和仓库里的期望配置对比，不一致就开issue或者发到团队频道。这样有人绕过流程在后台手改，第二天就能发现。
几个容易踩的点
令牌权限给太大。能改企业级模型策略的令牌，权限通常也很高。建议单独建一个只做这件事的令牌，设置过期时间，存在密钥管理里。
只改组织层，忘了企业层上限。企业层没允许的模型，组织层开了也没用。排查「为什么开了还是看不到」，先看上一层。
把API当成审批流程。接口只负责执行。哪些模型能开，涉及数据合规、成本和供应商协议，这些判断还是要人来做。
个人版用户别找了。这套接口针对企业和组织。个人订阅Copilot的，模型选择还是在自己的设置和IDE里。
对国内团队有什么用
在国内用GitHub企业版的公司不算多，但外企研发中心、出海团队里很常见。这类团队经常还要回答总部的问题：「你们中国区开了哪些模型？」有了这个接口，一次GET就能给出准确答案，不用截一堆后台截图。
如果你们同时在用Cursor或者GitHub Copilot CLI这类工具，模型策略最好统一一张表来管，避免IDE里能用的模型和CLI里不一致，开发者问起来解释不清。
相关工具和延伸阅读
工具入口：GitHub Copilot、GitHub、GitHub Docs。企业合规相关可以顺便看GitHub开源许可合规正式版，微软那边的同类做法见Copilot Studio代理账号。更多工具在AI编程分类、代码托管分类和AI代码审查分类。
常见问题
要额外付费吗？
Changelog没有提任何新增费用，接口是管理已有的Copilot订阅。Copilot座位本身怎么收费不变。
Copilot Business能用吗？
组织层接口面向有Copilot订阅的组织，企业层、团队层、应用层需要企业账号。具体套餐要求以官方文档为准。
能不能顺便控制代码补全用哪个模型？
接口管的是模型可用性策略，也就是「允许哪些模型」。开发者在允许范围内具体选哪个，还是在客户端里切换。
来源与核查日期
- GitHub Changelog：Copilot model policy API for enterprise, orgs, and teams（2026-10-19）
- GitHub Changelog 2026年10月汇总（同日模型停用公告）
核查日期：2026-10-20（新加坡时间）。请求体字段与权限范围以GitHub REST API文档为准。
