Human-in-the-Loop 怎麼設計?決定哪些 Agent 動作該讓人審核的判斷框架

Human-in-the-Loop(人機協作),指的是在 agent 執行任務的關鍵節點插入人工審核閘門,由人決定該動作是否放行、修改或攔截,而不是讓模型從頭到尾自動跑完。它不是「要不要信任 AI」的哲學題,是一道工程題:把審核放在對的地方,錯的地方一個都別放。

放錯地方的代價,我們親眼看過。

審核疲勞:一個把好意做壞的真實案例

去年一家 B2B 電商找我們接手他們自建的採購對帳 agent。團隊很謹慎,agent 每執行一個步驟——讀發票、比對品項、標記異常、寫回 ERP——全部彈出一個「請確認」的視窗等人點。設計初衷是安全。

結果三週後,實際狀況是這樣:負責審核的會計每天要點掉將近 400 次確認,其中 380 次是「讀取發票」「比對金額」這種根本不會出錯、也改不動什麼的唯讀動作。人腦很誠實,重複性高、風險感低的動作點久了就會進入自動模式——閉著眼睛按 Enter。等到真正該攔的那一筆(一張多打一個零、金額差十倍的付款指令跳出來時),她也一樣反射性放行了。

這就是審核疲勞(alert fatigue)。你以為加了越多人工關卡越安全,實際上你稀釋了每一次審核的注意力,讓最重要的那次審核淹死在雜訊裡。更糟的是採用率:當一套 human-in-the-loop 人機協作 agent 讓人覺得「還不如我自己做」,它就會被靜靜關掉。上線但沒人用,等於沒上線。

所以問題從來不是「要不要人審」,而是「哪些動作值得動用人這個最貴的資源」。

判斷框架:可逆性 × 影響金額的四象限

我們給客戶的做法很土,但每次都管用:把 agent 能做的每一個動作,沿兩個軸標記位置。

第一軸是可逆性:這個動作做錯了,能不能低成本收回?寄一封還沒送出的草稿、寫進暫存區的資料,可逆;真的發出對外郵件、送出付款、刪掉生產資料,不可逆。第二軸是影響金額:做錯的最壞後果值多少錢或多少信任?讀一筆內部資料趨近於零;誤發一則客戶折扣碼可能是六位數。

兩軸一交叉,四個象限,四種對待方式:

這張表的價值不在於填得多精細,而在於它逼你承認:大多數 agent 動作根本不該勞煩人。真正需要人腦的,是右下角那一格——不可逆而且貴。把 90% 的注意力省下來,集中投在那 10%,審核才有意義。

把象限翻譯成 harness 設計

框架要能落到 loop 工程裡,才不是紙上談兵。幾個我們實際在 agent harness 裡加的機制:

閘門要放在動作邊界,不是思考邊界。 讓模型自由地讀、推理、規劃、產出草稿,這些都在「可逆」區內,一路放行;只在它要跨出去對真實世界動手的那一刻——呼叫付款 API、送出郵件、commit 到生產庫——才插入審核。很多人把 human-in-the-loop 加在 agent 每一輪 reasoning 之後,那是災難,既慢又製造疲勞。

高風險動作要附「差異視圖」,不是「是/否」。 逐筆放行那一格,你給審核者看的不能只是「要付 1,240,000 嗎?」,而要是「本次 vs 上次:金額 +10 倍、收款帳號變更、無對應請購單」。人審的價值是抓異常,你得把異常喂到他眼前。

可逆高金額那格,用「事後可回滾」換速度。 不必攔在前面等人,而是先執行、保留 undo 窗口與快照,再事後抽樣審核。這一格是採用率的甜蜜點——體感是全自動,又留了安全網。

動態升級,而非靜態分類。 同一個「寄郵件」動作,寄給內部同事是低金額,群發三萬個客戶就跳成高金額。閘門條件要看參數,不只看動作類型。信心分數低、金額超過門檻、收件人數量異常,任一觸發就升級到人審。

還有一件事值得寫進每個專案的驗收標準:量測審核否決率。 如果某個閘門連續幾百次審核、人的否決率接近零,那個閘門大概就是在製造疲勞,該降級成事後抽審或全自動。反過來,某格否決率偏高,代表 agent 在那裡不夠可靠,得回頭修 prompt 或工具,而不是靠人肉補漏。閘門不是裝上去就結束,它是一個要持續調參的旋鈕。

回到那家電商

我們把他們的 agent 重畫了一遍。唯讀與比對動作全自動、只留 log;寫回暫存區改成事後抽審;真正要寫進 ERP、產生付款指令的,才逐筆放行並附上差異視圖。每天的確認次數從約 400 掉到 30 出頭,而那 30 次,每一次會計都真的看了。上線兩個月後,那筆多打一個零的付款,被攔下來了。

在 Tenten,我們設計 agent 的 human-in-the-loop 時,不從「哪裡要人審」開始,而是從「哪裡不需要人審」開始——先把可自動的動作全部釋放,再把省下來的注意力,重重地壓在不可逆又昂貴的那一格。因為 Demo 很美不算數,能被同一群人天天用、還真的攔下該攔的那一筆,才算數。