Copilot 把批准键交给了另一个模型

GitHub Copilot 动手前的那一下批准，现在可以先交给另一个模型来判断。据 GitHub Changelog 10 月 26 日的更新日志，「辅助权限」已在 Copilot 命令行工具、Copilot 应用和 VS Code 里正式可用。

Copilot 要跑命令、读写某个路径或打开网址时，先由一个大模型评估，判定明显安全的直接放行，其余再问人。

改变最大的地方在企业一侧。据 GitHub Docs 的说明页，在命令行工具里，企业为命令、读文件、写文件和网址设下的「需要确认」规则，也可以由这个模型的批准来满足。企业要是真想让人点头，靠的是关掉辅助权限这一项设置。

没人值守的流水线，多了一种放行方式

GitHub 文档里写了一个具体场景：Copilot 命令行工具在持续集成流水线或定时任务里跑，终端前没有人能回答批准提示。

过去这种场合只有两条路。一条是什么都不额外授权，凡是要批准的动作一律被拒，任务常常做不完；另一条是加上全部放行的参数，不经任何审查。新加的参数走中间：审查模型判定安全的自动放行，判定要人确认的直接拒绝，拒绝理由交回给 Copilot，让它换个做法。

交互会话里的流程是这样的：

• 企业的禁止规则和已有的放行规则先生效，已经允许的动作不经模型审查。
• 剩下符合条件的请求交给审查模型，它有把握判定安全就自动通过。
• 没把握，或者审查服务不可用，就回到普通流程，照常问人。

审查用哪个模型由 Copilot 决定，可能和对话用的模型不同；用户接入自己的模型服务时，审查就用当前会话的模型。

企业写的「必须问人」，两页文档写法不一

麻烦出在企业管理员的设置上。据 GitHub Docs 的企业托管设置参考页，它把「确认」规则的用途写成「在特定操作执行前要求一次新的人工批准」，并列出不能满足它的捷径：全部放行模式、自动批准设置、钩子和其他批准捷径，以及之前留下的授权。

辅助权限的说明页则写得很直接：在命令行工具里，企业为命令、读写和网址设的确认规则，在请求符合审查条件时可以由模型批准来满足，这些规则不一定会弹出确认。两页都在 docs.github.com 上。参考页列举捷径时没有提到模型审查，也没有说它能满足确认规则。

按说明页的写法，一家公司若给 git push 之类的操作写了确认规则，原意是每次都由人点头，在命令行里却可能由审查模型放行。由此看，管理员不能只靠确认规则保证人工把关，这是分析推断，依据是说明页那句「这些规则不一定会弹出确认」。

GitHub 给了另外两个开关。企业可以单独关掉辅助权限，参考页的写法是把对应项设为 true；关掉全部放行模式，并不会顺带关掉辅助权限。企业还能指定新会话默认用人工、辅助还是全部放行，但这只是默认，开发者仍可在政策允许的范围内另选。

VS Code 文档里，它还标着「实验」

更新日志说它在 VS Code 里正式可用，VS Code 自己的文档写法更保守。据 Visual Studio Code Docs 的审批与权限页，它仍在辅助权限旁标注「实验性，可能变更或移除」，要先打开一项设置，才会在权限选单里出现这一档。

这一档也有使用条件。按同一页面，它只在选择文件夹隔离时可用；工作树会话固定是全部放行，VS Code 自带的本地智能体模式里没有这一档。页面还写明，第一次选择时会弹出警告，要求用户确认。

所以对在 VS Code 里用 Copilot 的人，这一档要自己打开，而且只在部分会话里有。

审查模型放错了一步，GitHub 没给数

GitHub 在说明页里把责任写得很清楚：辅助权限减少弹窗，但不免除用户对 Copilot 所作所为的责任，模型可能出错、放行危险或意外的操作，它也替代不了沙盒和访问限制。

缺的是数字。GitHub 的更新日志、两页说明文档和 VS Code 文档，都没有公布审查模型放行了多少请求、拦错多少、漏放多少。站内此前写过 Anthropic 把 Claude 应用改为默认自动模式，Anthropic 当时至少公布了编程场景里的批准与漏拦比例，见这篇。

两家走到同一处：让一个模型替人批准另一个模型的动作。区别在 GitHub 把这道审查伸进了企业规则里。对管理员来说，确认规则写了多少条并不说明问题；真要每一步都由人点头，得把辅助权限这一档关掉。等 GitHub 改写其中一页文档，或公布审查模型的出错率，这个判断再改。