Human Gate 人類閘門

要解決的問題 #

今天的「人在迴路」要麼是無休止的彈窗，要麼什麼都沒有。Anthropic 披露，Claude Code 使用者批准了 93%–97% 的權限提示；在它的受控實驗裡，人只攔住了 13.6% 被植入的危險命令，工作階段越長越差。這是廠商為推廣自動模式做的研究，測的是識別被植入的提示，不是生產事故率，但方向很清楚。

同一份資料裡還有另一個數字：使用者對「計劃」的拒絕率是 39%，對單個權限請求只有 3%。人會認真判斷的，是計劃和合並，不是每一次工具呼叫。

工作方式 #

• 只在少數地方出現： 合併進受保護樹、受保護樹中的刪除、對外共享或釋出、出口、租約擴權、標籤降級。分支上的寫入不需要審批。
• 粒度是計劃或合併。 評審一個 PR，而不是五十個彈窗。
• Gate Card 由 NAS 渲染： 真實的差異、讀清單摘要、租約、工作階段污點，絕不使用智能體的自述。選項：批准、收窄後批准、拒絕；逾時預設拒絕。
• 批准綁定動作摘要： 綁定差異雜湊與租約，不能重放。
• 交付： 推送、聊天、郵件或 CLI；可以委派；passkey 作為可選的強認證。
• 只升不降。 可選的風險分類器（包括 LLM）只能把動作升級到閘門，永遠不能批准。模型只能收緊，不能放寬。
• 疲勞度量： 批准率與批准耗時；批准率異常高時，提示合併閘門或收緊策略。

從小處開始 #

• 受保護 main 加 PR 審閱（任何 Git 平臺都行），再加一條推送通知。
• 或者一個 CLI：nas gate approve <gate_id>。
• 先把 Gate Card 做成「真實的差異」，別急著做花哨的介面。

介面草圖 #

僅作示意。欄位名在規範 v0.3 之前可能調整。

{
  "gate_id": "gt_2Mx4",
  "run": "run_91ab",
  "action": {
    "op": "merge",
    "from": "cleo/run_91ab",
    "into": "main",
    "files_changed": 4,
    "diff_sha256": "7d2a..."
  },
  "why": "Release notes are ready for review",
  "risk": {
    "session_taint": ["external"],
    "sources": ["web:example.com/changelog"],
    "destructive": false,
    "egress": false
  },
  "options": ["approve", "approve_narrowed", "deny"],
  "default": "deny",
  "expires_at": "2026-11-12T12:00:00Z"
}

規範的要求 #

• Gate Card 必須展示由 NAS 計算出的真實差異，而不是智能體對它的描述。
• 批准必須綁定動作摘要與租約，不得可重放。
• 逾時的預設結果必須是拒絕。
• 分類器或 LLM 不得授予批准；可以把動作升級到閘門。
• 合併進受保護樹、受保護樹中的刪除、對外共享、出口、租約擴權、標籤降級，必須經過閘門。
• NAS 應當報告批准率與批准耗時。

借鑑與區別 #

下面這些都是現成的做法。真正新的部分： 把審批錨定在儲存層的合併上，並由 NAS（而不是智能體）渲染內容。審批與 PR 本身都是現成的。

• How we built Claude Code auto mode
• Anthropic: approval data behind auto mode
• CaMeL
• WebAuthn
• OpenID CIBA

坦誠的侷限 #

• 人仍然可能批准錯誤的動作；成批的審閱也會疲勞。
• 通知渠道可能被釣魚。
• 審批無法阻止它批准範圍之外的事，那是租約的工作。

開放問題 #

• 批次與分級審閱的最佳介面是什麼？
• 自動合併的門檻如何度量與調整？

常見問題 #

相關概念 #

• Capability Lease (能力租約) 發給一次執行的、有期限與預算的窄域授權；子租約只能更窄。
• Trust Labels (信任標籤) 來源與敏感度兩個小標籤，加上工作階段污點，強制執行 Rule of Two。
• Agent Branch (智能體分支) 每次執行在寫時複製的分支裡工作，經審閱的合併才進入主線。