不用每步都点头，也别直接放行：Copilot 辅助审批全面可用

__MEDIA_1__

用 Copilot 干活的人都经历过两种极端：一种是每动一下都要你点头，刚开工十分钟，确认框已经弹了二十次；另一种是图省事直接开了 Allow All，agent 一路狂奔，你坐在旁边心里发虚，不知道它刚才到底删了什么、改了什么、连了哪个网址。2026 年 10 月 26 日，GitHub 把第三条路正式推向了所有人：assisted permissions（辅助审批）进入全面可用，覆盖 Copilot CLI、Copilot 应用和 Visual Studio Code。它的逻辑很简单，也很值得认真对待：不是所有请求都需要人批，也不是所有请求都可以不经人批，中间那部分，交给模型先筛一遍。

GitHub 在更新日志里的描述只有几句话，但每句都很关键。当 Copilot 请求运行一条命令、访问一个文件系统路径、或者打开一个网址时，一个大语言模型会先评估这个请求。被判定为明显安全的请求自动放行，其他请求仍然需要你的批准。注意这里的措辞：模型评估的是“请求”，而不是“结果”；它放行的是“明显安全”的那部分，而不是“大概没事”的那部分。这个分寸感，就是 assisted 模式的全部意义——它不是帮你把审批关掉，而是帮你把明显不用操心的审批省掉。

三个客户端的开启方式各不相同，GitHub 在公告里逐个写明了。Copilot CLI 里运行 /permissions，然后选择 assisted；Copilot 应用里打开模式选择器，点击 Tool permissions，再选 Assisted；VS Code 里打开权限选择器，选择 Assisted permissions。路径写得这么细，说明 GitHub 不想让用户在设置里翻半天：这是一个会话级别的工作模式，不是一项藏在深层配置里的实验开关。选了它，你当下这个会话的审批节奏就变了；没选它，一切照旧。

配套的文档把三种模式的对比讲得更清楚。手动审批的控制最强、提示最多：任何未被已有规则放行的动作，比如运行一条非只读命令、编辑文件、访问网址，都要你点头，你可以单次批准，也可以批准到会话结束。无条件批准（也就是 CLI 里的 --allow-all 或 /yolo）则走向另一端：Copilot 可以在没有模型安全审查、也没有逐项批准提示的情况下广泛使用工具、路径和网址，控制最弱。辅助审批夹在中间：模型审查符合条件的请求，判断安全的自动批准，仍然需要你批准的再推给你。它省的是提示数量，不是监督本身。

这个“中间”不是一句口号，而是有具体的执行顺序。文档说，启用辅助审批后，已有的规则和人工批准会先于模型审查被评估；已经被权限放行的请求不需要提示，也不需要模型审查；只有那些还没被解决的、符合条件的请求——运行命令、访问路径、获取网址——才会交给模型判断，是否安全、是否在你给它的任务授权范围之内。模型有信心认为是安全的，Copilot 自动批准并继续；模型没有信心，就像手动审批一样问你。如果安全审查不可用、或者无法评估某个请求，请求就回到会话原本的权限处理流程，而不是默认放行。这个“评估不了就不放行”的默认，是一条很重要的安全线。

对企业管理员来说，这次全面可用带来的最大变化可能不是给个人用户多了一个选项，而是给了管理员一套可以分开控制的开关。公告明确说，企业管理员可以用企业托管设置，在封掉 Allow All 的同时保留 Assisted，也可以用单独的开关把 Assisted 关掉。文档里还给出了对应的设置名：用 permissions.disableBypassPermissionsMode 关掉无条件批准，并不影响辅助审批；用 permissions.disableAssistedPermissionsMode 才能单独关掉辅助审批。换句话说，“不许全放行”和“允许辅助审批”不再是绑在一起的二选一，管理员可以只禁最危险的那档，而把中间这档留给团队。

管理员还可以为新会话选择默认权限模式，开发者仍然可以选择政策允许的其他模式。如果管理员设定的默认值不可用、或者被政策禁止，会话会以手动审批启动，而不是悄悄退到更宽松的模式。CLI 的配置细节也印证了这一点：用户可以在 ~/.copilot/settings.json 里把 defaultPermissionMode 设为 assisted，作为新交互会话的首选；但管理员设定的 permissions.defaultMode 会优先于用户偏好；如果选定的默认值不可用或被政策屏蔽，CLI 会以手动审批启动并说明原因。默认值的层级，和 OpenAI 那边讲的指令层级其实是同一个道理：越上层的规则，越不能被下层悄悄覆盖。

还有一个细节，只有真正用 Copilot 跑过自动化任务的人才会立刻明白它的分量：在自动驾驶模式和非交互运行里，仍然需要你批准的请求会被拒绝，而不是挂起等你。文档说，这时安全审查要求批准的解释会传回给 Copilot，让它换个方法再试。CLI 的非交互用法也有对应的开关 --assisted-approval，以及环境变量 COPILOT_ASSISTED_APPROVAL，专门给 CI/CD、定时任务、批处理脚本这种没人坐在终端前的场景。没有这个开关，你只有两个难受的选项：什么都不给，任务常常做不完；给了 --allow-all-tools，又等于把工具权限全交出去。辅助审批在这里的价值，就是让无人值守的任务既能往前走，又不至于一路裸奔。

但文档里也有一段必须原样读出来的警告，而且这段话比公告本身更重要。GitHub 明确说：辅助审批减少了你被提示的次数，但没有解除你对 Copilot 行为的责任；模型可能会犯错，批准危险或非预期的动作；这个功能不是沙箱或访问限制的替代品；和任何自动批准选项一样，你应该检查 Copilot 采取的动作，并考虑在沙箱或其他隔离环境里运行它。这段话把辅助审批的定位钉死了：它是一个效率工具，不是一个安全保证。你把它当成“模型已经帮我审过了，所以不用看了”，就是在误用它。

这个警告还引出一个更微妙的点：企业 ask 规则的含义变了。文档说，在 Copilot CLI 里，企业针对 shell 命令、文件读取、文件写入和网址的 ask 规则，在请求符合审查条件时，可以被模型批准满足。也就是说，ask 不再必然意味着“一定会弹给人确认”。与此同时，企业拒绝规则仍然适用，辅助审批不审查那些企业规则要求你亲自批准的其他工具调用，也不审查绕过本地沙箱的请求，那些请求仍然走会话原本的权限处理。团队在制定政策时，必须把这两类请求分开想：哪些 ask 是可以交给模型代批的，哪些必须永远留给人。

还有一个容易踩坑的组合，文档里用警告框单独标出来了。在非交互运行里成功启用 --assisted-approval 后，它会优先于 --allow-all-tools，但不会改变 --allow-all-paths 或 --allow-all-urls。如果你同时传了 --allow-all 或 --yolo，即使工具请求走了辅助审批，路径和网址访问仍然可能是无限制的。更麻烦的是，如果辅助审批因为企业设置被屏蔽而无法开启，CLI 只会在标准错误输出里写一条警告，不会取消你另外传的 --allow-all-tools，工具请求仍然可能在没有安全审查的情况下被批准。所以跑自动化任务的人，检查输出里的警告和检查任务结果一样重要，别只看任务跑完了没有。

那么，到底谁应该开辅助审批？答案取决于你的工作方式，而不是你的职位。如果你在一个熟悉的项目里做边界清晰的活，改动有人复核，环境本身也有隔离，那辅助审批能帮你省掉大量重复确认，把注意力留给真正值得看的请求。如果你正在处理生产数据、外部系统凭证、或者一个你还不熟悉的代码库，手动审批的啰嗦恰恰是保护：那些提示不是噪音，而是你最后一次在动作发生之前拦住它的机会。辅助审批省掉的是“明显安全”的部分，前提是你和团队对“明显”这个词有共识；如果你们的共识是“只要能跑就是安全”，那这个模式只会让危险跑得更快。

对团队负责人来说，全面可用的真正意义在于政策可以写得更细了。以前很多团队只有两个选择：要么忍受全员手动审批带来的摩擦，要么默许一部分人开 Allow All 然后祈祷不出事。现在可以写成三档：默认给辅助审批，禁掉无条件批准，个别高风险场景再单独收紧。这个政策本身不难写，难的是配套的习惯：定期检查 Copilot 实际做了什么、复核被模型自动批准的动作里有没有异常、以及让新人明白“模型批了”不等于“人审过了”。工具给了你中间档，管理习惯如果还停留在两档思维，中间档的好处会被浪费掉一半。

从更大的图景看，辅助审批其实是 agent 时代一个绕不开的问题的阶段性答案：当 agent 每分钟能发起几十次工具调用时，人不可能逐项审批，也不能完全放手。GitHub 的答案是分层：规则先行，模型筛查，人做最后的守门员。这个答案不完美——模型会犯错，审查模型本身也可能不可用，审查用的模型还可能和你对话用的模型不是同一个——但它至少把“谁在为什么负责”说清楚了：规则负责底线，模型负责筛选，人负责最终责任。比起假装问题不存在，这个诚实的三角关系更有用。

审查用的模型本身，也值得单独说一句。文档指出，Copilot 会为安全审查选择模型，这个模型可以和你对话时选的模型不一样；如果审查模型不可用，审查可以用你会话的当前模型代替；如果你用自己的模型供应商，审查就用你会话的当前模型。这意味着“谁在审批”并不是一个固定不变的答案，它会随着模型可用性变化。对普通用户来说，这不影响日常使用；但对要把审批记录拿去审计的团队来说，就需要意识到，审查者的身份本身也是一个变量，审计时不能默认每次都是同一个模型在把关。

会话之间的边界，同样容易被忽略。文档说，在应用里为当前会话选了辅助审批，这个选择会保存为新本地会话的默认值，但不会改变其他已经打开的会话；想只改当前会话而不改默认值，可以用 /permissions assisted，想只改默认值而不动当前会话，可以去设置里改。CLI 里也有类似的区分：直接进会话改模式，只影响这个会话；改配置文件，才影响未来的新会话。这些区分听起来琐碎，实际用起来却很关键：你以为自己“已经开了辅助审批”，可能只是给某一个会话开了；你以为自己“只是试一下”，可能已经把默认值改掉了。每次改完，用 /permissions show 确认一下当前模式，是个值得养成的习惯。

把辅助审批放进更大的 Copilot 演进里看，它的位置也很清楚。GitHub 在 2026 年 10 月前后密集推了不少 Copilot 变化，从多模型路由到跨仓库协作，核心都是让 agent 能做更长、更复杂的任务。任务越长，审批负担就越重，手动逐项确认很快就会变成瓶颈。辅助审批就是在这个背景下从“可选项”变成“默认值得考虑的选项”：它不是为了让用户少动脑子，而是为了让用户的注意力花在真正需要判断的地方。一个 agent 如果每做一步都要人点头，它其实还是一个需要全程盯着的工具；一个 agent 如果从不让人点头，它又成了一个不受控的执行者。辅助审批试图在这两者之间找到一个可以长期用的平衡点。

这个平衡点能不能站住，最终取决于模型审查的质量，而 GitHub 对此没有给出量化承诺。公告没有说审查的准确率是多少、误放行的比例是多少，也没有说审查模型是怎么训练和评估的。文档只说，模型会判断请求是否安全、是否在任务授权范围之内，有信心就放行，没信心就问人。这种不给数字的做法，一方面是诚实的——审查质量本来就很难用一个数字概括，不同任务、不同代码库的表现会差很多；另一方面也意味着，用户和团队不能把辅助审批当成一个经过验证的安全控制，只能把它当成一个效率优化，然后用自己的复核、沙箱和权限规则去补上安全的那一环。

还有一个现实问题：辅助审批目前只覆盖三个客户端。公告明确列出的是 Copilot CLI、Copilot 应用和 VS Code，没有提到其他 IDE 或云端 agent。如果你平时在多个客户端之间切换，不要默认辅助审批在所有地方都一样可用、一样表现。跨客户端的工作流里，审批模式很可能是不一致的：这个客户端走了模型审查，那个客户端还在手动确认。团队在写操作手册时，最好按客户端逐个写清楚，而不是笼统地说“我们开了辅助审批”。笼统的说法在审计和排障时，几乎一定会误导人。

说到底，辅助审批解决的是“提示太多”这个问题，而不是“判断太难”这个问题。提示变少了，你的判断并没有变少，只是被集中到了更值得判断的地方。如果你发现开了辅助审批之后，自己反而更少去看 Copilot 做了什么，那说明这个工具正在起反作用：它把你的注意力省下来了，你却没有把省下来的注意力用在复核上。工具只能改变提示的数量，判断的质量，始终还是人的责任。

最后给一个可以直接照做的上手建议。先在单个会话里开辅助审批，跑一两天你熟悉的任务，留意它自动放行了什么、有没有放行你本希望它先问你的东西；确认没问题，再把它设为新会话的默认值。企业用户先和管理员确认两件事：Allow All 是不是已经被禁掉，辅助审批有没有被单独关掉。如果你在跑 CI 或定时任务，用 --assisted-approval 而不是 --allow-all-tools，并且把标准错误输出里的警告当成检查项。做完这些，辅助审批才会是你以为的那个“省事但不失控”的模式；否则，它只是换了一种方式让你放松警惕。