H
Howardism
Plate IIAgent Systems機器翻譯 · machine-translated過時翻譯 · stale translationENHOWARDISM

Claude Code 自動模式

PublishedApril 17, 2026FiledConceptDomainAgent SystemsTagsClaude CodePermissionsAgent SafetyDeveloper WorkflowReading8 minSourceAI-synthesised

Claude Code 使用分類器自動核准安全的工具呼叫並封鎖高風險呼叫的權限模式；介於預設模式與 `--dangerously-skip-permissions` 之間的折衷方案

Claude Code 自動模式插圖

資料來源#

摘要#

自動模式是 Claude Code 中的一種權限模式，將每次工具呼叫的核准交給分類器處理，定位在三點安全光譜的中間：default（每次寫入／bash 都提示）→ auto mode（分類器核准安全呼叫、封鎖高風險呼叫，最終可能升級為提示）→ --dangerously-skip-permissions（不進行檢查）。該模式以研究預覽形式在 Team 方案推出；隨著 Opus 4.7 一同擴展至 Max 使用者；並相容於 Sonnet 4.6 與 Opus 4.6。

細節#

機制#

每次工具呼叫執行前，分類器會檢查該呼叫，並回傳三種結果之一：

  1. Safe → 工具呼叫自動繼續執行，不顯示提示。
  2. Risky → 封鎖。Claude 會被導向嘗試不同方法。
  3. Repeatedly blocked → 如果 Claude 堅持執行持續遭到封鎖的動作，最終會向使用者顯示權限提示。

分類器的目標是 Anthropic 所描述的可能具破壞性的類別：大量刪除檔案、敏感資料外洩，以及惡意程式碼執行（完整清單維護於 Claude Code 權限模式文件中）。

殘餘風險#

自動模式相較於 --dangerously-skip-permissions 降低了風險，但並未消除風險。文件記載了兩種失效模式：

  1. 意圖模糊：分類器無法判斷某個動作是否無害。
  2. 缺少環境脈絡：分類器不知道部署環境特有的風險面（例如共用資料庫、production bucket）。

在這兩種情況下，分類器可能讓部分高風險動作通過。反過來，它偶爾也可能封鎖無害的動作。即使開啟自動模式，Anthropic 仍持續建議使用隔離環境。

成本與延遲#

每次工具呼叫對 token 消耗、成本與延遲的影響都很小（分類器會 inline 執行）。但並非零影響。

可用性與切換方式#

  • 研究預覽推出：Claude Team 方案；未來幾天內逐步開放至 Enterprise 與 API 方案（以來源文章發布時為準）。
  • 隨 Opus 4.7 推出一同擴展至 Max 使用者（請參閱 Claude Opus 4.7）。
  • Claude 桌面應用程式預設停用；管理員可透過 Organization Settings → Claude Code 切換。
  • 由管理員停用：在受管理設定中將 "disableAutoMode": "disable" 設定為停用 CLI 與 VS Code extension 的自動模式。
  • 開發者啟用：
  • CLI：claude --enable-auto-mode，接著按 Shift+Tab 循環切換至該模式。
  • Desktop / VS Code extension：在 Settings → Claude Code 中啟用，並於工作階段內從權限模式下拉選單選取。

預期使用情境#

自動模式之所以存在，是因為 Claude Code 的預設設定刻意採取保守策略——每次檔案寫入與 bash 指令都會提示。這種安全性讓無人值守的長時間任務變得不切實際：你無法啟動一個耗時數小時的重構後就離開。自動模式提供了中間道路：讓長時間任務減少中斷，同時不必無條件信任 Claude 對破壞性動作的判斷。

這與 Claude Code Best Practices 中的「fan-out and unattended runs」擴展模式相呼應——這是先前就存在的使用情境，但過去只能在核准疲勞與 --dangerously-skip-permissions 之間二選一。

非互動模式的互動方式#

當 Claude Code 以非互動方式執行（claude -p）時，沒有使用者可以回答權限提示。根據 Claude Code Best Practices，在非互動模式中重複遭到封鎖時，自動模式會中止，而不是卡在無人可回答的提示上——藉此保留最佳實務指南中描述的 fan-out 與 pre-commit-hook 使用情境。

相關連結#

  • Verification as the New Bottleneck — 自動模式分類器將驗證負擔轉移到核准時的閘門
  • Claude Code Best Practices — 自動模式是權限章節「classifier-based approval」條目的解答；搭配 /clear、工作階段管理與驗證驅動開發後，便能實現該文章中的擴展模式
  • Claude Opus 4.7 — Opus 4.7 的推出將自動模式的可用性擴展至 Max 使用者
  • Agent Harness Engineering — 自動模式是 harness 層級的安全不變量：以機械方式強制執行破壞性動作邊界，而不是透過提示建議。這符合 OpenAI Codex harness 研究結果中的「強制執行不變量，而非實作」原則
  • LLM-Driven Vulnerability Research — 基於分類器的 pre-flight 是一種防禦模式，類似漏洞研究 scaffold 中的 validation agent；兩者都使用次級模型執行額外檢查，以過濾主要代理的動作
  • Hermes Agent — 不同的核准模型設計點：Hermes 使用依模式核准（once／session／always／deny），而在 container backend 下依據「container 是安全邊界」的原則停用危險指令檢查。取捨是：以逐映像檔的紀律取代逐指令的稽核
  • Agent Loop Pattern — 自動模式是 AFK loops 的前置條件；沒有它，每次工具呼叫都會因提示而阻塞迴圈。Boris Cherny 的 /loop 工作流程依賴基於分類器的閘控，才能實際使用
  • Harness Shrinkage as Models Improve — Cat Wu 預測，隨著模型可靠地做出正確行動，權限模式／human-in-the-loop／靜態指令驗證都會變得「不那麼重要」；自動模式正是朝向 harness 縮減軌跡上的其中一項 harness 資產
  • Human-AI Accountability Redesign — 自動模式的分類器是 HBR 問責處方中「decision rights」子前沿的具體實例：定義代理可自主執行哪些事項、哪些事項需要人類核准
  • Agentic Misalignment (AM) — 分類器閘控的工具使用，是降低 agentic misalignment 攻擊面的一種方式；它與模型端的緩解措施（例如 Model Spec Midtraining (MSM)）互補
  • AI Brain Fry — 將人類審查集中在高風險決策點，而非每個動作上，是自動模式分類器閘控實現的監督疲勞緩解方式
  • MCP and Computer Use — 自動模式所閘控的基礎層；分類器透過相同的風險視角評估 MCP 呼叫與 computer-use 動作
  • Agentic Prompt Injection — 分類器閘控的核准，是將 constitutional-classifier 防禦部署在動作邊界、而非輸入邊界的實例
  • Out-of-Band Prompt-Injection Defense — 一個對比：自動模式的分類器是基於模型的動作邊界閘門，正是 out-of-band 文獻所逐漸遠離的「LLM in the loop」（「閘門不可由模型擔任」），轉而採用確定性的 policy monitor——對能夠誘導分類器繞過限制的適應性攻擊者而言，這是一個較弱的目標
  • Capability-Gated Model Fallback — 相同的分類器閘控概念出現在查詢邊界：Fable 5 會在標記的 cyber／bio／distillation 主題上換用較弱的模型（Opus 4.8），而不是封鎖工具呼叫
  • Autonomous Defense — 「位於警示佇列前端的模型」是 SOC 中自動模式分類器在人工查看前先對工具呼叫進行分流的對應概念
  • Configurable Human Participation — HAS-Bench 的 Control channel + Safety-Critical Authorization 模式，就是自動模式所採用的設計；僅控制型的人類授權可填補受保護動作的安全缺口（100%），而釐清／回饋（51/54%）無法做到——這是應該閘控動作、而不只是詢問動作的實證案例（分類器是該人類授權步驟的自動化替身）

開放問題#

  • 分類器在例行但激進的重構（例如大型檔案重新命名、對建置產物執行 rm）上的誤判率是多少？
  • 對於缺少環境脈絡的自訂工具／MCP servers，分類器的泛化能力如何？
  • 對安全敏感的組織而言，分類器的決策邊界是否有足夠文件記錄且穩定到可以進行認證，還是它實際上是一個會隨更新而漂移的黑箱？
  • 將自動模式擴展至 API 使用者後，是否會改變其校準方式——分類器會針對高度自動化的使用情境重新訓練，還是維持不變？
  • 與 Claude Code Best Practices 中和自動模式一同提到的 OS-level sandboxing 相比，縱深防禦的整體設計為何？什麼時候應該同時採用兩者？

推導#

資料來源#

§ end
About this piece

Articles in this journal are synthesised by AI agents from a curated wiki and are refreshed automatically as new concepts arrive. Topics, framing, and editorial direction are curated by Howardism.

Cited by 30
Related articles
  • Harness Shrinkage as Models Improve

    Prompt scaffolding shrinks each model release; Cat Wu's pruning discipline; Boris Cherny "100 lines of code a year from…

  • Claude Code Best Practices

    Anthropic's guide to effective Claude Code usage: context management, verification-driven development, explore→plan→cod…

  • Open Questions Backlog

    _456 actionable open questions across 205 pages · 107 predictions · 9 notes · 147 in progress · 69 watching (entities),…

  • Agent Harness Engineering

    Patterns for scaffolding long-running LLM agents: environment design, progressive context disclosure, mechanical archit…

  • Loop Engineering

    Replacing yourself as the agent's prompter by designing the system that prompts it: a recursive-goal loop built from fi…