GitHub Copilot 10 月 22 日起默认开启未配置功能，企业管理员只剩不到三周

发生了什么：一个默认值，两种哲学

9 月 24 日，GitHub 在官方 Changelog 上发布了一则看似 boring、实则影响深远的公告：为 Copilot Business 和 Copilot Enterprise 引入新的全局默认策略——"Default policy for new features"（新功能默认策略）。从公告当天起，管理员有 28 天时间配置这个策略；10 月 22 日起，它正式生效：所有仍处于"未配置"（Unconfigured）状态的 GA 功能，将自动遵循这个全局默认值。

策略有三档可选：Enabled（启用）——当前和未来的合格功能默认对用户可用；Disabled（禁用）——保持不可用，新功能需要管理员逐个审批；Let organizations decide（由组织决定）——把决定权下放给企业下的各个组织管理员。关键细节藏在文档里：这个策略的默认值是 Enabled。也就是说，如果你什么都不做，10 月 22 日之后，你没配过的 Copilot 功能会被自动打开。

适用范围比想象中广：企业"AI Controls → Copilot → Features & clients"页面上的所有策略，外加"Agents"页面的 Copilot code review 策略和"MCP"页面的 MCP servers in Copilot 策略。好消息是：预览（preview）功能依然需要显式 opt-in，不会被默认开启；你已经显式启用或禁用的功能，GitHub 承诺不会覆盖。但"未配置"这个中间状态——过去大量管理员随手一放就再也没管过的状态——从此有了明确的含义：跟随默认值，而默认值是"开"。

理解这次变化的份量，需要一点历史感。2025 年 11 月，GitHub 曾修复过一个企业/组织策略交互的 bug：当时修正后的规则是，企业策略为 Unconfigured 时，对应的组织策略默认视为 Disabled——"没配"意味着"关"，这是一种"默认拒绝"的安全哲学。而今年 7 月 29 日，GitHub 已经在"模型"侧做过同样的事：引入模型的默认启用策略，8 月 26 日开始执行，未配置的模型被自动打开。现在，轮到"功能"了。从"默认拒绝"到"默认允许"，GitHub 用一年时间完成了一次治理哲学的反转。

为什么这次不一样：MCP 与"默认允许"的风险叠加

如果只看"新功能自动可用"，这似乎只是方便管理员的效率优化。但把适用范围里的另一项拎出来看，味道就变了："MCP servers in Copilot"也被纳入了默认策略。MCP（Model Context Protocol）是 agent 调用外部工具和数据源的通道。默认开启 MCP server 策略，意味着 agent 可以连接的外部服务范围，可能在管理员没有显式审批的情况下扩大。在 agent 能读文件、跑命令、调 API 的今天，"默认允许"外部工具接入是一个需要认真对待的安全决策，而不是一个"省点 clicks" 的便利功能。

时间线上的巧合更值得玩味。就在这则公告前后，GitHub 密集发布了三波模型退役通知：9 月 3 日宣布 10 月 2 日退役 Gemini 3.5 Flash、Gemini 3.6 Flash、Kimi K2.7 Code、Claude Opus 4.7；9 月 18 日宣布 10 月 19 日再退役 GPT-5.5、GPT-5.4、GPT-5.4 mini、GPT-5 mini、Grok 4.5、Gemini 3.7 Flash。替代方案清一色是更新的模型（Gemini 3.8 Flash、Kimi K3、GPT-5.6 Sol/Luna、Grok 4.6、Claude Opus 5）。结合"默认启用"策略一起看，GitHub 的意图很清晰：用"默认"这只手，同时完成两件事——把用户推向更新的模型，把新功能推向更广的启用面。这是一种非常"平台"的做法：不强制、不弹窗，用默认值的重力让生态朝自己期望的方向流动。

把视角拉高，这其实是整个行业的同一主题在不同公司的变奏。JetBrains 在 9 月 22 日发布 Air，把"治理"做成产品卖给企业；GitHub 则选择把"治理"做成"默认值"，直接写进平台规则。一个是"给你工具去管"，一个是"替你设好默认值"。两种路线没有高下，但都指向同一个判断：agent 正在从"个人玩具"变成"组织基础设施"，而基础设施的默认配置，就是权力的形状。当 GitHub 把默认值设为 Enabled 时，它实际上在替几十万个组织的管理员做了一个价值判断：新功能的收益，大于"没审查就开启"的风险。管理员可以改，但"不改"本身就成了一种选择。

管理员现在该做什么：三份清单

如果你是 Copilot Business 或 Enterprise 的管理员，10 月 22 日之前有三件事值得做。第一，盘点"未配置"存量。去 AI Controls 页面看一眼横幅——GitHub 会显示当前有多少合格策略处于未配置状态。对每一项问自己：如果它在 10 月 22 日被自动打开，我能接受吗？特别是 Copilot code review（agent 自动 review 代码）和 MCP servers（agent 可调外部服务）这两项，它们的"自动开启"和其他 UI 功能的"自动开启"不是一个风险等级。

第二，决定你的默认哲学。三档没有标准答案，但有适用场景：对安全敏感、强合规的行业（金融、医疗、政务），Disabled 是更负责任的选择——新功能逐个评审，虽然慢，但每一次开启都是显式决策；对追求速度的研发组织，Enabled 配合定期的策略审计可能更合适；Let organizations decide 适合集团型企业，让各业务线按自己的风险偏好决定。最差的选择是"没想好"——因为"没想好"的默认结果就是 Enabled。

第三，把模型退役和功能策略放在一起看。10 月 2 日和 10 月 19 日的两波模型退役，意味着你的团队正在用的模型选择器会在未来几周内发生变化；如果你的某些内部文档、prompt 模板、评估基线里写死了旧模型名（比如 Gemini 3.6 Flash 或 GPT-5.5），现在是清理的时候。在"默认启用"的新世界里，模型和功能的变更都会以更快的速度、更少的显式通知到达你的用户——治理的节奏，必须从"审批制"切换到"巡检制"。

最后说一句给普通开发者的：10 月 22 日之后，如果你发现 Copilot 里突然多了几个没见过的功能，先别惊讶，去问问你的管理员——大概率不是 GitHub 偷偷上线的，是你们组织的"未配置"在那一天变成了"开"。默认值是平台写给所有人的信，只是大多数人从来不读。

更深一层：默认值的权力，以及"巡检制"时代

行为经济学里有个经典概念叫"默认效应"：人们倾向于接受默认选项，不是因为深思熟虑，而是因为懒得改。GitHub 对"默认开启"的选择，就是一次大规模的默认效应实验，只不过实验对象是几十万个组织的管理员。GitHub 赌的是：大多数管理员不会在 28 天内逐项审查，结果就是新功能的启用面自然扩大。这不是阴谋论，这是平台运营的常识——手机系统的默认搜索引擎、浏览器的默认隐私设置，玩的都是同一套逻辑。

但 Copilot 的默认效应有一个特殊变量：这里的"用户"不是个人，而是企业。企业管理员和个人用户的决策逻辑完全不同：个人为便利让渡隐私，企业为便利让渡的是合规风险。当"默认开启"的对象从"UI 小功能"变成"agent 自动 review 代码""agent 可调外部 MCP 服务"时，默认效应的代价就从"多一个按钮"变成了"多一个攻击面"。GitHub 把 MCP servers in Copilot 纳入默认策略，说明它认为这个风险是可接受的——但"GitHub 认为可接受"和"你所在行业认为可接受"之间，隔着一整套合规要求。金融、医疗、政务的管理员，这 28 天最好别偷懒。

还有一个很少被讨论的角度：默认策略是 GitHub 对"功能发布节奏"的加速器。过去，每上一个新功能，GitHub 都要面对"企业管理员还没配"的长尾——功能上线了，但大企业的用户半年后才用上。有了默认启用，新功能的到达速度不再取决于最慢的那个管理员。这对 GitHub 的竞争态势是利好：当 Cursor、JetBrains、Devin 都在按周发布 agent 新能力时，"你的企业用户能不能第一时间用上"成了平台竞争力的直接体现。默认开启，本质上是 GitHub 把自己从"等管理员点头"的被动方，变成了"不等了先上"的自动方。

这就引出了"巡检制"的概念。传统企业 IT 治理是"审批制"：任何变更先申请、再评审、再上线。但在 agent 时代，变更的来源太多了——模型每周退役、功能按默认开启、MCP 生态每天新增 server。审批制跟不上这个速度，只能切换到"巡检制"：设定好默认哲学（Enabled 还是 Disabled），然后定期巡检"实际开了什么、有没有异常"。GitHub 在 AI Controls 页面放的那个"未配置横幅"，就是巡检制的第一个工具。未来我们会看到更多这类工具：策略漂移告警、异常启用通知、按团队的风险分级默认。JetBrains 的 Air Governance 和 GitHub 的默认策略，看似两条路线，其实都在回答同一个问题：在 agent 时代，企业如何"管得住"又"不拖慢"。

顺带一提，这次变化也给"影子 AI"治理提了个醒。很多公司的 Copilot 使用现状是：管理员配了一次就再也没看过，开发者自己开着各种 preview 功能和第三方 MCP server。默认策略生效后，"没配过"不再等于"没开"，而是等于"按默认开"。这意味着过去那种"靠不配置来实现的软禁用"彻底失效了。如果你所在的组织曾经用"不配置"来冷处理某些敏感功能（比如 code review agent），现在必须显式设为 Disabled。沉默不再是立场，沉默就是同意。

最后给个人开发者一句提醒：10 月 22 日之后，如果你在 Copilot Chat 里看到模型选择器变了（比如 Gemini 3.6 Flash 没了、多了 Kimi K3），或者 agent mode 突然能调你没配过的 MCP 服务，先别慌，也别急着关——先去看一眼你们组织的 AI Controls。理解"默认值"从哪里来，是你在这个时代保持掌控感的最低成本方式。平台不会为你的"没注意"负责，它只为你的"显式选择"负责。

再补充一个实操细节：GitHub 文档里明确写了，这个默认策略是"enabled by default"——很多管理员会误以为"新策略"默认是"不生效"，但这里的"默认启用"有两层含义：策略本身默认取 Enabled，且 10 月 22 日后未配置项跟随该值。如果你打算选 Disabled 或 Let organizations decide，记得在 10 月 22 日之前就去 AI Controls 页面显式设置，不要等到生效后再补——因为生效那一刻，未配置的功能会按当时的默认值一次性翻转，事后补救比事前设置麻烦得多。

一句话收尾：10 月 22 日不是"世界末日"，而是一次"默认值的成人礼"——从那天起，你的 Copilot 治理策略里不再有"没想好"这个选项。想清楚，显式配，定期查，就这么简单。