Copilot用模型预审代理操作权限

GitHub Copilot 的权限选择多了一条中间路线：让模型先审核代理的操作，判断安全且没有超出任务授权就放行，拿不准再交给人。原文称，这项 Assisted permissions 已于 2026 年 10 月 26 日正式开放，覆盖 Copilot CLI、Copilot app 和 VS Code。

它值得关注的地方，是减少确认弹窗的同时，保留逐次审核。但接入脚本和团队流程前，有几个边界必须看清：无人值守时如何拒绝、旧参数是否仍然放宽权限，以及企业的 ask 是否还代表人工确认。

模型审核的，是这次操作有没有越过授权

手动审批要求人不断确认；--allow-all、--yolo 则提前给整场会话放行。Assisted permissions 的区别在于，每次符合条件的请求都要重新判断：操作是否安全，是否在用户为当前任务授予的权限内。

有把握就批准，没把握就询问。

原文这里有一处信息缺口：它声称有三类符合审核条件的请求，却只列出了「访问文件系统路径」。因此，不能根据这份材料补齐另外两类。

这层审核也不会覆盖所有操作。已经获准的请求直接执行，不再经过模型；拒绝规则和企业限制继续生效。需要突破本地沙箱的请求，以及其他按企业规则必须走常规审批的工具调用，仍按会话原有权限流程处理。审核不可用或无法评估时，也退回原流程。

审核模型由 Copilot 选择，未必是聊天时使用的模型；它不可用时，可以回退到当前会话模型。使用自有模型提供商时，审核始终使用会话当前模型。

所以，辅助权限是一层授权判断。它的可靠性仍取决于模型能否正确理解操作和任务边界。

开关不难找，但交互会话与 CI 要分开配置

CLI 交互会话里，/permissions assisted 只为当前会话启用辅助权限，/permissions manual 切回手动审批，/permissions show 查看当前模式，单独输入 /permissions 则打开选择列表。

要让新建交互会话默认启用，可以在 ~/.copilot/settings.json 中加入：

{
  "defaultPermissionMode": "assisted"
}

注意 defaultPermissionMode 控制的是默认模式；改成 "manual" 可以恢复手动审批默认值。

脚本、CI 等非交互执行使用下面的命令：

copilot -p "Fix the failing tests" --assisted-approval

注意 --assisted-approval 只用于非交互执行，用它启动交互会话会报错退出。另一种配置方式是环境变量 COPILOT_ASSISTED_APPROVAL=true。

Copilot app 可以通过模式菜单中的 Tool permissions → Assisted 启用，并保存为新建本地会话的默认值；只改当前会话，则在输入框使用 /permissions assisted。

VS Code 的限制更具体：在聊天权限选择器中选 Assisted permissions，但使用 Local harness 的会话不支持；隔离方式必须选 Folder，因为 Worktree 会话始终使用 Allow all。首次选择需要确认警告，新会话默认权限由 chat.permissions.default 控制。

在 autopilot 和非交互执行中，拿不准的请求会被拒绝。

此时没有人接收确认，审核解释会返回 Copilot，让代理尝试其他路径。对自动化任务来说，这能阻止存疑操作继续执行，也可能让原本需要人工确认的任务无法完成。

企业可以禁用 --yolo，但要重新理解 ask

原文认为，团队管理是这项功能的重要价值：管理员可以禁止无条件批准，同时保留辅助权限，给需要连续工作的开发者留一个选项。

相关托管配置包括：

• permissions.disableBypassPermissionsMode: "disable" 禁止 allow-all，但保留辅助权限。
• permissions.disableAssistedPermissionsMode: true 禁用辅助权限。
• permissions.defaultMode 设置新会话默认模式，优先于个人的 defaultPermissionMode。

开发者仍能切换到政策允许的其他模式。如果配置的默认模式不可用或被禁止，会话退回手动审批。

但企业需要检查现有审批要求。在 CLI 中，针对 shell 命令、文件读取、文件写入和 URL 的企业 ask 规则，可以由模型批准来满足。若团队把 ask 理解成「必须有一个人看过」，启用辅助权限后，这个理解就不再成立。

参数叠加还有两个容易遗漏的地方。

第一，--assisted-approval 会覆盖 --allow-all-tools，却不会取消 --allow-all-paths 和 --allow-all-urls。如果继续混用 --allow-all 或 --yolo，路径和 URL 访问仍可能没有限制。

第二，如果辅助权限因企业政策等原因无法启用，CLI 会向 stderr 输出警告，而传入的 --allow-all-tools 仍然生效。自动化流程若只看任务有没有继续跑，很容易漏掉权限模式没有按预期启用。

我的判断

逐次审核比整场会话提前放行更容易控制授权范围，尤其适合那些频繁弹窗、又不希望全面开放权限的工作流。原文对非交互拒绝、参数叠加和企业规则的提醒，也比单纯介绍开关更有实用价值。

但它没有提供作者实测的误批率、漏批率、耗时或任务完成率，也没有手动审批与辅助权限的对照实验。「少打断且能控制风险」在这里主要是产品机制与经验判断，不能直接当成效果已经验证。

辅助权限应该放在隔离环境里使用，不能替代沙箱和访问限制。

模型可能批准危险或不符合用户意图的操作。沙箱负责限制实际能碰到什么，权限审核负责判断这次该不该做，两者承担不同职责。对必须由人负责的操作，团队也需要明确保留人工环节。

还有一个采购层面的空白：按原文发表时的信息，changelog 和文档都没有说明哪些 Copilot 套餐包含这项功能，不能仅凭正式开放就推断所有套餐都能使用。

能拿来做什么

• 在本地前端或 Node 仓库中，先用 /permissions assisted 为单次会话启用，观察哪些请求仍需要确认，再决定是否修改默认配置。
• 把 Copilot 接进测试修复脚本时，检查启动参数里的 --allow-all、--yolo 和路径、URL 放行项，并检查 stderr，确认辅助权限确实启用。
• 团队统一权限政策时，逐条核对现有 ask 规则；凡是要求人工审阅的操作，都要确认流程还能保证由人确认。
• 在 autopilot 或 CI 中，把权限拒绝视为任务可能无法完成的原因之一，保留审核解释，方便判断代理是在尝试其他路径，还是需要人工接手。