TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
GitHub Copilot 輔助權限正式上線，讓模型先替你審代理操作
GitHub 於 10 月 26 日宣布 Copilot 輔助權限正式版，CLI、app 與 VS Code 三介面由語言模型評估代理的命令、檔案與網址請求：明顯安全自動通過，其餘交回人工；無人值守場景另提供 --assisted-approval 參數，企業管理員可獨立停用 Allow All 或 Assisted，並設定新工作階段的預設模式。
用 AI 摘要這篇文章：
GitHub 在 2026 年 10 月 26 日宣布，Copilot 的輔助權限（assisted permissions）在 Copilot CLI、Copilot app 與 Visual Studio Code 正式提供。一句話講完這次改變：當代理要求執行命令、存取檔案路徑或開啟網址時，改由一個語言模型先評估這項請求，判定明顯安全就自動繼續，其餘在互動工作階段交回給使用者核准。它填上的，是「每個動作都停下來問你」和「全部直接通過」之間由模型逐案判斷的中間選項。
把公告和官方文件一起讀，會發現這個功能的重心和多數人以為的不同。互動時少按幾次確認只是表面，文件裡寫得最詳細的兩塊，一是無人值守場景的專用參數與它的優先序警告，二是企業管理端能把「無條件核准」和「模型審核」當成兩個互相獨立的開關。正在用 Copilot 代理跑任務的開發者，以及管理組織 Copilot 政策的管理員，是這次更新直接的影響範圍。
中間那層補上了：三種模式的階梯
官方文件把核准選項整理成三層，對應你想參與代理動作的程度：
| 模式 | 行為 | 互動成本 |
|---|---|---|
| 手動核准（manual） | 未預先允許的動作都要問你，可單次同意或整個工作階段同意 | 提示最多、掌控最高 |
| 輔助權限（assisted） | 模型評估有資格審核的請求，判定安全就自動通過，不確定的仍要問你 | 提示變少，保留個別動作把關 |
| 無條件核准（unconditional） | 工具、路徑與網址全部直接執行，不做模型安全審核 | 零提示、無模型審核 |
第三層在 CLI 早已存在，就是 –allow-all（或別名 –yolo）參數與 /permissions allow-all 指令帶來的行為。輔助權限補的是中間：模型只在三類請求上做判斷，涵蓋執行命令、存取檔案路徑、開啟網址，其他都不在它的審核範圍。
三個介面的開法各自一行就能說完。CLI 在工作階段內輸入 /permissions 再選 assisted，輸入 /permissions manual 可以退回手動，/permissions show 則查詢目前模式；Copilot app 打開模式選單，點 Tool permissions 後選 Assisted；VS Code 則在權限選擇器裡選 Assisted permissions。app 端有個範圍細節值得記住：在模式選單裡的選擇會套用目前工作階段，並存成之後新本機工作階段的預設，但不會改動其他已開著的工作階段；想只改預設、不動目前工作階段，要走設定裡的 Sessions 頁面調整。雲端工作階段則完全沒有工具權限控制可用，遠端主機上的可用模式取決於該主機支援什麼。
規則先跑，模型才上場
官方文件對評估順序有一段明確描述：既有規則和人工核准先完成評估，模型審核排在後面。你的權限已經允許的操作直接執行，不再跳出提示，也不需要模型再看一次；拒絕規則和企業限制在輔助模式下照樣有效。換句話說，開啟輔助權限不會覆寫團隊已經寫好的政策，模型只在規則沒有定論的縫隙裡表態。模型判斷的標準也有官方定義可引：這個動作是否安全，以及是否在你授權這項任務的範圍內。審核服務無法使用、或某個請求無法評估時，該請求回到工作階段正常的權限流程，不會硬給答案。
企業規則與模型審核的互動還有一個容易漏看的細節。企業管理設定文件寫明，受管理的 ask 規則不能用無條件核准模式、自動核准設定、hook 或其他核准捷徑、先前留下的同意紀錄來滿足；CLI 的說明卻寫著，企業針對 shell 命令、檔案讀寫和網址設下的 ask 規則，在請求符合審核資格時，可以由模型核准來滿足。兩段話並讀的意思是：模型審核在 GitHub 的設計裡是一個獨立機制，不在那些禁用的捷徑清單上。看到 ask 不代表每次都必須人來按，在 CLI 的這四類請求上，模型審核可以代勞。
邊界同樣清楚。輔助權限不審核企業規則要求核准的其他工具呼叫，也不審核繞過本機沙箱的請求，這兩類照正常權限流程走。這也解釋了它和 10 月 7 日剛正式提供的本機沙箱是兩件事：沙箱限制的是執行環境能碰到什麼，輔助權限處理的是某個請求要不要人批准，一個管邊界、一個管核准，可以同時用，誰也不能取代誰。對沙箱概念還不熟的讀者，可以先看我們先前的 AI 代理沙箱部署與安全設定教學再回來讀這段。
至於由哪個模型來審，官方的答案很誠實也很有限：模型由 Copilot 挑選，可能和你對話用的模型不同；審核模型無法使用時，退回工作階段目前作用中的模型；如果你帶自己的模型供應商，審核就用你工作階段的模型。GitHub 沒有公布審核模型的具體名稱。
無人值守場景才是重點：被拒的請求會帶著原因折返
文件裡篇幅最大的一段，留給了沒有人盯著螢幕的場景。在 autopilot 模式和非互動執行裡，仍需要人工核准的請求會直接拒絕，但拒絕不是終點：安全審核要求核准時的說明會回傳給 Copilot，讓它換一條路再試。這個設計把「等不到人」轉成「帶著理由改道」，代理不會卡死在提示上。官方對這個參數的定位講得很直白：非互動執行沒有人能回答提示，不帶任何權限選項時，Copilot 需要核准的動作一律拒絕，任務常常做不完；帶 –allow-all-tools 則是無條件核准所有工具權限、沒有模型安全審核。–assisted-approval 站在中間，文件建議的適用場景是 CI/CD、排程工作與批次腳本這類想要真正做完事、又不想給代理無限制命令權限的無人值守執行。
CLI 為此提供專用參數。用 -p 或 –prompt 跑非互動任務，或在 CI/CD 這類沒有終端機的環境裡，加上 –assisted-approval 就能啟用輔助權限；不方便改指令的環境可以改設 COPILOT_ASSISTED_APPROVAL 環境變數。這個參數只給非互動執行用，在互動工作階段使用會直接報錯退出，互動場景請改用 /permissions assisted 或設定檔裡的預設。
優先序的警告值得逐字看。文件寫明：成功啟用時，–assisted-approval 優先於 –allow-all-tools，但不會改變 –allow-all-paths 和 –allow-all-urls；如果同時給了 –allow-all 或 –yolo，工具請求走模型審核，路徑和網址的存取卻可能完全不受限。更需要注意的情況是輔助權限開不起來，例如企業設定封鎖了它：CLI 只會在標準錯誤輸出寫警告，不會取消你同時指定的 –allow-all-tools，工具請求於是可能在沒有安全審核的情況下獲得核准。文件直接建議，自動化執行的輸出裡要檢查這則警告。
個人的預設設定也在這次文件裡補齊。CLI 使用者可以在 ~/.copilot/settings.json 把 defaultPermissionMode 設成 assisted 或 manual，管理員設的 permissions.defaultMode 優先於使用者的偏好；回復的工作階段會保留上次儲存的模式，–allow-all 在政策允許時仍蓋過兩種預設。有一個官方措辭上的模糊點要留意：文件說你和管理員都沒設預設時，新工作階段「可能以手動或輔助模式開始」，建議用 /permissions show 確認當前狀態。
企業管理：無條件核准和模型審核是兩個獨立開關
企業端的設計是這次公告裡結構性最強的部分。三個受管理的設定鍵，對應三種治理姿態：
- permissions.disableBypassPermissionsMode 設 “disable”：只關無條件核准。CLI 的 –yolo、–allow-all 和 –allow-all-tools、–allow-all-paths、–allow-all-urls 全部失效，/permissions allow-all 與其別名一併擋下，但不影響 /permissions assisted 和 /allow-all auto；VS Code 的全域自動核准設定（chat.tools.global.autoApprove）關閉且無法重開；Copilot app 的工作階段不能選 Approve all。這個設定明確寫著「不阻止輔助權限」。
- permissions.disableAssistedPermissionsMode 設 true：獨立停用輔助權限，無條件核准不受影響。兩個開關可以任意組合，管理員可以只留手動，也可以禁止無條件核准但保留模型審核。
- permissions.defaultMode：為新工作階段選預設模式，值可為 manual、assisted 或 allow-all。預設不是鎖定，開發者仍能在政策允許內換模式；選的預設不可用或被政策擋住時，工作階段以手動核准開始。
兩個防呆設計顯示這套機制按失敗安全的方向設計。disableBypassPermissionsMode 收到 CLI 認不得的值時，會記錄問題並直接當成 disable 執行，寧可擋過頭；多層政策來源並存時，最嚴格的值獲勝，下層不能把任何一層已經關掉的無條件核准再打開。多來源的允許清單也取交集而非聯集，只要有任何一個來源宣告了允許清單，沒列入的操作一律回到要求核准。
規則本身的顆粒度也高一級。企業可用 Shell(…)、Read(…)、Edit(…)、Domain(…) 等選擇器分別比對命令、讀檔、寫檔與網域，例如 Shell(git push *) 比對的是指令前綴，優先序固定為拒絕大於詢問大於允許。VS Code 端有個適用範圍的註記：這類細部規則在 VS Code 只作用於使用 Agent Host 的工作階段，disableBypassPermissionsMode 的支援面則更廣，不限於 Agent Host。十月在福斯集團那種等級的大規模 Copilot 部署裡，這類規則會直接決定代理能自動做到哪裡，輔助權限給了管理員一個不必在「問到煩」和「全開」之間二選一的選項。
GA 前兩週，VS Code 先把相容性磨平
把時間軸排開，這次正式版不是憑空出現。VS Code 1.142 在 10 月 14 日（UTC）標記發布，版本說明已經出現「管理員可以允許 Assisted 同時擋掉 Allow All」的獨立管理模式，但當時留了一條重要但書：輔助權限與 permissions.allow、permissions.ask、permissions.deny 的細部規則不相容，文件建議混用這些規則的團隊把 disableAssistedPermissionsMode 設為 true，並承諾下一版讓兩者並行。同一份說明還點名一個舊政策陷阱：舊版 ChatToolsAutoApprove 設 false 會同時擋掉 Allow All 和 Assisted，除非管理員明確改用新的管理模式設定，只設 defaultMode 不能取代舊限制。10 月 22 日標記的 1.143 收斂了行為：輔助權限核准過、符合資格的受管理工具請求不再重複提示，一次性限制、受管理的拒絕與沙箱限制照舊。10 月 26 日 changelog 刊出三介面正式提供，隔天 10 月 27 日上午（台北時間）統一說明文件在 GitHub docs 倉庫建立，changelog 條目也在同時段做了最後更新。
還有兩個時間軸事實幫你判斷資訊新鮮度。changelog 上沒有獨立的預覽公告，搜尋整份更新日誌只找得到這一筆輔助權限條目；docs 倉庫的提交紀錄裡，第一個提到 assisted permissions 的提交就是這次正式版的文件建立。想長期追蹤的讀者，把 VS Code 每月版本說明和企業管理設定文件放進回查清單就夠了，規則互動的行為在 1.142 到 1.143 之間就改過一次。
官方文件沒有給的答案
有三個問題官方沒有回答。哪些付費方案、哪些地區能用輔助權限，公告和文件都沒有載明；模型的誤判率、能省下多少次確認，也沒有任何數字。文件反而主動潑了一盆冷水：模型會出錯，可能核准危險或非預期的動作，這個功能不能取代沙箱或存取限制，重要工作仍建議在沙箱或隔離環境裡跑。換句話說，輔助權限降低的是提示次數，不是你的責任。
導入的路徑可以照這個順序走：先在測試儲存庫確認組織政策允許哪些模式，再用短任務觀察哪些請求自動通過、哪些仍回到人工；無人值守管線加上 –assisted-approval 後，把標準錯誤輸出的警告檢查排進腳本。最後一步的警告檢查是官方文件明文建議，前兩步則是照同一份文件的原則排出的順序。代理權限的把關位置從人移向模型，和 GitHub 近期把 Teams 通知接進代理、讓研究預覽的工程師改審規格而由證明系統審程式，走的是同一條線：核准這個動作本身，正在重新分配。
