多數為 coding agent 設計的權限系統都是允許清單：讀取檔案允許、寫入檔案允許、執行測試允許，其餘的一律詢問。這種方式一直都能運作，直到有人為了不再看到提示而將 agent 標記為「完全信任」，然後 agent 在某個星期五執行了 git push --force。
我們的立場是，有四類操作每一次都應該暫停並交由人類確認，無論該 agent 或請求者有多受信任皆然。信任級別決定的是有多少其他操作需要核准。這四類操作絕不能靜默執行。
這四類操作
1. 推送至共享分支。 在 feature branch 上的 commit 只是個建議。推送至 main 或 release 則是整個團隊都必須承擔的決策，且通常還連帶著部署流程。這項操作開口詢問的成本很低，復原的代價卻極高。
2. 刪除。 檔案、分支、資料表、儲存貯體（bucket）、各類資源。刪除是唯一一種對意圖判斷錯誤後、無法靠第二次猜測挽回的操作。agent 往往過於自信，而充滿自信的刪除正是備份機制被迫接受考驗的起因。
3. 花費金錢。 呼叫付費 API、佈建資源、購買網域、發送行銷郵件活動。提出請求的人可能根本不知道該請求會產生費用。但付錢的人應該要知道。
4. 碰觸憑證。 讀取金鑰檔案、匯出環境變數、登入服務、完成雙重驗證。凡是與此相關的操作都牽涉到身分，而身分屬於機器的主人，而非身處房間內的任何人。
為什麼「完全信任」在此仍應暫停
權限模式描述的是某個人與該 agent 的關係：唯讀、可編輯但不可 push、完全信任。對於 agent 在單次工作階段中進行的數百次一般呼叫來說，這是恰當的粒度。但對於上述四類操作而言，這卻是錯誤的粒度，因為它們罕見、不可逆或代價高昂，且其成本往往落在請求者以外的人身上。
因此 muti 的規則很單純：沒有任何權限範本可以將這四類操作設定為靜默執行。即使在「完全信任」模式下，它們也會暫停並在時間線中醒目標示。這類提示出現的頻率極低，不致於令人厭煩，且分類界限分明，答案通常一目了然。
這如何對應到 Claude Code 的權限模式
Claude Code 本身就有一套階梯機制：plan（唯讀）、default（編輯與指令執行前先詢問）、acceptEdits（編輯直接執行，指令先詢問）以及 bypassPermissions（一律不詢問）。這些模式描述的是 agent 詢問你的頻率。而這四類操作描述的則是當有其他人提出要求時，有哪些動作必須向主人請示。兩者相互疊加。
最後一欄是房間新增的機制，且在每一列中皆相同。請參閱權限模式解析。
該詢問誰
這是多數設計遺漏的部分。當共享的 agent 需要人類時，到底該找哪位人類？
- 憑證問題交由主人。 登入、雙重驗證碼與金鑰存取皆攸關主人的身分。無論任務由誰發起，這類問題一律路由給主人。請求者只會看到介入接管的狀態，看不到機密本身。
- 意圖問題交由請求者。「你的意思是指 staging 資料庫嗎？」這與該人員原本的目的有關。這類問題會路由給提出請求的人。
- 雙方看到的是同一條時間線。 任何一方都不必向另一方轉述上下文；問題與其回覆都會留在同一個工作串中。
憑證與危險操作提示會路由給主人；意圖問題會路由給請求者；雙方皆可查看此交流內容。
良好核准卡片的構成
一張能讓人五秒內做出決定的核准卡片包含五個部分。
提供三個按鈕：Approve、Deny 與以唯讀方式繼續。第三個按鈕常被低估。它能讓工作繼續推展，同時讓高風險步驟維持等待狀態。
讓核准操作能在主人當前所在的任何地方完成：主控台、手機或通訊平台卡片。在單一地點做出的決定應同步套用至所有地方。請設定過期時間，以免被遺忘的卡片在一週後突然執行。
核准疲勞才是真正的敵人
每一次提示都在訓練看到它的人。一旦提示過多，他們就會找出將其關閉的設定。有三件事能在不放寬這四條規則的前提下，保持極低的提示率。
- 限制 agent 的作用範圍。 每個 agent 僅分配一個工作目錄，代表它可能碰觸的檔案變少，詢問存取檔案的提示自然也隨之減少。
- 在一般呼叫中使用一般模式。 探索時使用唯讀，多數工作使用可編輯但不 push。將「完全信任」保留給那些平時就能直接在你的鍵盤上打字的人。
- 讓預設範本名實相符。 提供唯讀、可編輯但不 push 與完全信任等具名預設集，讓任何人都不必從零開始制定政策，進而避免出錯。
稽核紀錄線
每個請求與每次核准都應產生一行可供主人匯出的紀錄：誰提出的、誰決定的、時間、觸發哪條規則、發生了什麼、使用了什麼資源。這並不是因為有人會天天查看它，而是因為出事的那一天，絕不是才剛要開始記錄的時候。
常見問題
每次都詢問不會拖慢 agent 的速度嗎？ 只會影響這四類操作，而它們在一般工作階段中極為罕見。暫停所消耗的代價以秒計算；犯錯的代價則是以數小時或金錢來衡量。
如果是主人自己使用專屬的 agent 呢？ 主人在自己的 agent 上不受權限模式約束，但這四類操作仍會記錄在時間線中，以確保歷史紀錄完整無缺。
請求者可以自行核准嗎？ 不行。核准權屬於機器的主人。請求者僅能取消、重試或補充上下文。
muti 的房間內建這些規則且無法將其關閉。如果你認為這是正確的預設做法，為你的 agent 開設一個房間吧。
發布於 · 更新於