人類在迴路：給 Agent 自主權，也給它煞車——批准閘門實作課

前言

Agent 能做的事情越多，一個錯誤動作的代價就越貴。寄出一封不該寄的信、退掉一筆不該退的款、改掉一個不該改的生產資料庫——這些都不是模型「智商不夠」的問題，而是系統設計沒給它裝上煞車。

2026 年業界的方向已經很明確：目標不是「完全自主」，而是「選擇性自主」（selective autonomy）。Agent 把無聊、重複、高上下文的苦力活全包下來，但在需要判斷力的地方，準時把方向盤交回人類手上。這篇文章談的就是那隻煞車怎麼做：人類在迴路（Human-in-the-Loop，HITL）。

一、自主性不是開關，是三層光譜

最常見的失敗治理長這樣：企業把「唯讀摘要 Agent」和「會寄信改設定 Agent」用同一套管制，結果要麼把無害的掐死，要麼讓危險的裸奔。實務上的主流做法是分三層放行（如圖一）：

第一層：自主執行＋記錄（act & log）。可逆、低風險、大批量動作放行：分類工單、產出草稿、內部標註。重點不是「不用管」，而是「記錄下來，人類事後看」——每筆動作都要記下輸入、決策、證據，方便回查。

第二層：抽樣審查（sampling）。每週固定抽查 N 件，核對「人類會怎麼做」，記下 miss rate。這個數字是活的：miss rate 高，動作就升級到第三層；長期漂亮，才考慮下放到第一層。抽查量本身就是設計參數，每週檢討一次。

第三層：事前批准（approve before）。不可逆、對外、花錢、涉隱私的動作：退款、寄信、改生產資料庫、對外發佈。流程是：暫停 → 人類批准 → 才執行。沒人點頭，什麼都不發生。

分層前先問四個問題：這個動作可逆嗎？它是對外的嗎？它花錢或費資源嗎？模型對這件事有把握嗎？四個答案決定動作住哪一層——不是憑感覺，也不是一次定終身。

真實世界的數據支持這個形狀。Anthropic 在 2026 年 2 月公布的 Claude Code 使用遙測顯示：真實的 agent 動作中只有約 0.8% 是不可逆的（例如寄出無法收回的訊息）；約 80% 的 tool call 本來就至少帶著一個防護（權限限制或人類批准要求）；約 73% 的動作有某種形式的人類在迴路。更有趣的是信任的曲線：新用戶用全自動批准的比例約 20%，用了 750 個 session 的老用戶爬到 40% 以上——但老用戶反而更常中斷 agent（約 9% 的回合 vs 新用戶的 5%）。信任不是一次給足的，是用出來的；而且越信任，越知道什麼時候該介入。

二、「全部都要批准」是反模式

聽到「人類把關」，很多團隊的第一反應是每個動作都加人工審核。這通常是最糟的選項，原因有二：

第一，它製造摩擦，卻不一定製造安全。人類的注意力是稀缺資源，幾百個低風險動作一個個點過去，點到最後就是機械式「同意」——批准疲勞（alert fatigue）比沒有批准更危險，因為它給了「有人看過」的假象。

第二，很多人把審查放在整趟流程的最後面。這同時犯了兩個錯：低風險工作被無謂拖慢，而高風險決策早就發生在流程前段、審查的人根本看不到。正確的審查對象是「決策」，不是「整趟執行」。不要叫人去看 agent 產出的每一串 token，叫它只回答一個問題：這個動作該不該執行。

三、批准閘門的實作：三個元件

一個紮實的批准閘門有三個元件（如圖二）：

1. Trigger（觸發器）：什麼條件下暫停。實務上就是上一節的風險分級：不可逆、對外、超過金額門檻、碰到敏感資料範圍，自動進第三層。

2. Review package（審查包）：人類做決定需要的全部資訊，一次給齊——提議的動作、參數、agent 拿到的證據、預期影響範圍。人類批准的是「這個決策」，不是盲簽。

3. Resume policy（恢復策略）：批准不是一張「好人卡」發完就結束。恢復執行時要重載最新狀態、重驗政策與參數，再執行或重新申請批准。批准應該被當成一個可恢復生命週期的一部分，而不是一封孤立的 yes/no 訊息。

實作上，LangGraph 把這個模式做成了一等公民。三行程式碼就能在寄信節點前加一個批准閘門：

from langgraph.graph import StateGraph

builder = StateGraph(AgentState)
# ... 加入 agent / send_email 等節點 ...
app = builder.compile(
    checkpointer=checkpointer,
    interrupt_before=["send_email"],  # 到這裡就停，等人批准
)

圖走到 send_email 節點前會存檔、暫停；你的應用層把待審查的草稿秀給人類看。批准就 app.invoke(None, config) 繼續；想改內容就先 app.update_state(config, values={...}) 再繼續。更細的控制可以用節點內的 interrupt()，暫停點可以帶任意結構化的審查包，人類回傳的 Command(resume=...) 直接變成恢復時的輸入。記得配一個資料庫-backed 的 checkpointer（SqliteSaver 或 Postgres），狀態才能跨暫停、跨重啟存活。

人類的決定有四種，不是兩種：批准（照原樣執行）、拒絕（不執行，把理由丟回流程）、修改（改參數、內容、金額或範圍）、升級（轉給更有權限或更專業的人）。注意：修改本身要寫進審計軌跡——「誰改了什麼」跟「誰批准了」一樣重要。

四、三個常見錯誤

錯誤一：把批准寫在 prompt 裡。在 system prompt 寫「寄信前一定要先問我」只是對模型的一個請求。OWASP 在 agent 威脅模型裡把「過度授權」（excessive agency）列為破壞性行動的三大根因之一，緩解措施寫得很白：高影響動作的人類批准，要做在下游系統或執行工具裡，而不是靠模型自己決定要不要遵守。白話說：寄信按鈕的設計就該是「等人按才會動」，不管模型被交代了什麼。

錯誤二：有日誌沒限流。日誌和速率上限是同一組防線：每種動作記完整日誌，也給每種動作設每小時上限。agent 開始做錯事時，上限讓它在第十次就被擋下，而不是做到第二百次才被發現。監控要在傷害變大之前抓到模式。

錯誤三：信任一次給足。從嚴開始是對的，但「永遠嚴」會逼死使用者。正確的鬆綁路徑是抽樣審查的 miss rate：數據漂亮，動作逐層下放；出一次事，整類動作升級。批准的對象從來不是「這個 agent」，而是「這個動作在這個上下文」。

結論

把自主性想成一個可調的參數，而不是一個要達成的里程碑。可逆的放行、抽樣的盯著、不可逆的等點頭——三層各就各位，agent 才能既跑得快又摔不重。Anthropic 的數據給了一個很實際的結論：要求每個動作都要批准，只會製造摩擦而不一定帶來安全；真正的功課是把審查放在決策發生的地方，用系統強制執行，而不是用 prompt 拜託模型。

下一次設計 agent 流程時，先畫出它的副作用地圖，再決定每一格住哪一層。煞車裝對地方，油門才敢踩到底。