若要在寫程式和其他任務上發揮最高生產力，代理需要具備適當的自主性。這表示它們應該能獨立運作、展現創造力，並在不必過於頻繁停下來請求許可的情況下完成工作。

然而，如果代理採取了非預期的動作，更高的自主性也會帶來安全風險。對本機代理而言尤其如此，因為它們通常會接觸到檔案、憑證、環境變數與 MCP 工具，也能存取正式環境系統。

最簡單的做法是在任何動作發生前都先詢問使用者，但過於頻繁地請求許可，本身也會帶來另一種安全問題。當重複的提示出現太多次後，人們就不再仔細閱讀，核准流程也會變得不再那麼有意義。

本週我們推出了 Auto-review，讓圍繞代理自主性的決策更像是調節旋鈕，而不是開關。核心概念是：當風險較低時，代理應能自由行動；但當下一個動作跨越關鍵界線時，就該放慢下來。

我們透過一個專門的分類器代理，在動作執行前根據上下文進行審查，以判定某個動作落在這個連續體的哪個位置。打造這個系統，意味著要把我們對「該如何管控代理自主性」的直覺，轉化為一套可運作的後果、意圖與意見回饋模型，並能用真實的代理行為來驗證。

#在上下文中判斷風險

代理動作是否會帶來風險，取決於具體情境。同一個指令在某個工作流程中可能無害，但在另一個工作流程中卻可能完全不可接受。真正關鍵的是，該動作、使用者的請求，以及判斷失誤所造成的後果之間的關係。

正是這樣的認知，促使我們開發一個「分類器」代理，用來管控代理整體的自主性。我們希望它是一個小型模型，好讓它在維持快速且低成本執行的同時，仍能細緻判斷下一個動作是否符合使用者的意圖。

我們賦予分類器的核心規則是：當安全風險較低時，它應該更寬鬆；當安全風險較高時，則應該更謹慎。在這個大原則確立後，我們開始將分類器打造為一個快速、具上下文感知能力的審查者，能直接置於代理的執行路徑中。

#建立分類器

第一個技術決策是模型選擇。分類器會在工具呼叫執行前先行運作，因此它直接位於代理循環中，不只要準確，也必須夠快。這裡多模型策略幫了很大的忙，因為我們可以嘗試各種模型和推理模式，然後選出在速度與判斷能力之間取得最佳平衡的方案。

其中一個早期的意外發現是，推理能力較低的模型不一定比較快。當模型難以理解規則或工具呼叫時，反而可能花更多時間和 tokens 來摸索，最後卻得到更差的答案。更好的取捨，是使用體量較小、但具備足夠推理能力的模型，讓它能乾淨俐落地做出判斷。

我們也讓分類器具備代理式能力，因為有些動作無法只靠指令本身來判斷。像 python script.py 這樣的指令，是否安全可能取決於檔案中的內容，因此分類器可以在做出決定前，先用 ReadFile、grep、Glob 和 ListDir 等工具檢查工作區。

我們沒有採用獨立的分類端點，因為每次額外的往返都會直接在每個經過審查的工具呼叫前增加延遲。相反地，分類器會和父代理在同一個 RPC 串流中執行，採用與子代理類似的架構。

#設計意見回饋迴路

下一個要決定的是，封鎖機制該怎麼運作。我們不希望分類器變成另一個用來產生核准提示的工具。當它封鎖某個動作時，會把說明回傳給父代理，而父代理通常能利用這些意見回饋，在不打斷使用者的情況下改走更安全的路徑。

使用者意圖正是讓這些意見回饋發揮作用的關鍵。問題不在於某個動作脫離情境單看是否有風險，而在於這個動作是否符合使用者要求代理執行的事項。這樣一來，一般的開發工作就能持續進行，而影響較大的動作則需要使用者提供更明確的訊號。

只有在分類器是針對它應該放行的動作，以及它應該攔下的動作來調校時，這套設計才行得通，因此我們需要同時涵蓋這兩類情況的 evals。

#測試分類器

第一批 evals 來自內部用量資料，用來了解代理工作的正常樣態。分類器必須在不妨礙日常開發工作的前提下攔截高風險動作，而內部工作階段正是觀察這個基準的最佳方式。我們先蒐集了約 12 小時的內部開發者工作階段，之後再進一步縮減資料量，並將常見動作去重整理成 6,122 筆已標註資料列。

我們也需要合成資料，因為最糟糕的情況在正常用量中出現得不夠頻繁。我們產生了代理可能讀取機密資訊、接觸正式環境資料、遵循不受信任的指示，或採取會帶來重大副作用之動作的案例。這些範例讓我們能涵蓋那些最希望分類器攔截的失敗情況。

隨著我們逐步學習，策略也持續調整，這使資料處理工作更加複雜。當我們更改分類器應辨識的行為類別時，就必須重新標註或重新產生 eval 集。否則，我們就是在用對問題的過時理解來測試目前的分類器。

我們透過與正式環境相同的後端分類器迴圈來執行這些 evals。這讓我們能測試完整路徑，包括工具使用、最終分類、模型覆寫，以及解析失敗。這些 evals 會檢查最終的允許或封鎖決策，以及分類器在需要先檢查工作區再做決定時所使用的上下文。

我們也會尋找結果反覆波動的情況。如果同一個案例有六次被允許、四次被封鎖，通常就表示策略或提示詞定義得不夠明確。重複執行讓我們能找出這些不穩定案例，並持續收緊分類器，直到它的行為更加一致。

#將直接封鎖降到最低

在實務上，只有一小部分代理動作需要由分類器審查。許多指令早已納入允許清單或沙箱機制的範圍，因此分類器大多只會在該動作需要結合上下文來判斷時才會執行。

當分類器確實執行時，目前大約會封鎖 4% 的動作，但封鎖不會立刻變成要求使用者確認的提示。分類器會將原因說明回傳給父代理，而父代理通常可以縮小動作範圍、改用其他工具，或完全避開這個高風險步驟。

分類器的部分封鎖最終會變成對使用者的中斷，但從整體來看，我們目前觀察到，在 Auto-review 模式下，所有對話中只有約 7% 會出現至少一次中斷。作為對照，我們合作的一些企業客戶先前在其組織內，約有 40% 的動作會被封鎖。

這些早期資料與我們想要的主要產品行為一致。分類器很少直接中斷使用者，而且在大多數遭到封鎖的情況下，父代理都能利用意見回饋，以更安全、範圍更小的方式繼續進行。

#完善代理自主性

Auto-review 仍處於早期階段，而隨著代理能力持續提升，我們對自主性連續體的理解也會不斷演進。目前，它主要聚焦於桌面應用程式中的本機代理，我們也預期，這些相同的理念將隨著時間推移，形塑我們在更多場景中管控代理自主性的方式。

我們希望代理具備真正的自主性，同時讓是否減緩其行動的決定取決於上下文，而不是單一的全域權限設定。分類器讓我們能在不讓自主性重新變成一連串核准提示的情況下提升安全性。它會找出需要進一步審查的動作、向父代理提供意見回饋，並在有更安全的方式可行時讓代理繼續運作。

Auto-review 現已成為新使用者的預設設定。對於現有使用者，你可以在 設定 > Agent 中啟用它。