前一篇討論「RBAC 與授權:Agent 不能因為「聽懂」就代表「有權」」,這篇聚焦「Human-in-the-loop:哪些步驟一定要人確認」,並沿用同一組輸入、環境與判讀規則,避免只做名詞比較。
依風險與可逆性決定 confirmation gate;比較所有動作都問與只在高風險動作確認的 UX/風險。
不是所有 Tool Call 都需要人確認,否則自動化會退化成「AI 填表,人一直按同意」。應依 side effect、金額/影響範圍、置信度與可逆性設計 approval gate。
等待核准時流程要持久化 state;核准者看到的也應是結構化 change summary,而不是一長串模型思考文字。核准、拒絕與逾時都要有明確後續路徑。
驗證時先固定環境與輸入,每次只改一個變因,並同時記錄操作方法與判定標準。
這個案例用「將 requester confirmation 與 manager approval 分成兩個事件」檢查執行前後狀態、副作用與 audit event,再決定流程是否通過。
case = {
"action": '將 requester confirmation 與 manager approval 分成兩個事件',
"expected_metrics": ('waiting states', 'actor', 'timestamp', 'expiry'),
}
before = load_state()
result = execute_case(case)
after = load_state()
assert result.final_state in {"SUCCEEDED", "REJECTED", "ESCALATED"}
assert side_effects_match_policy(before, after, result)
assert audit_matches(before, after, result.events)
驗證可從「將 requester confirmation 與 manager approval 分成兩個事件」開始。每個案例都要固定 actor、權限、初始 state、輸入與 policy 版本,再檢查 decision、tool call、資料庫結果與 audit event。只檢查模型最後說了什麼並不足夠,因為流程可能回覆成功,實際上卻沒有提交;也可能回覆失敗,外部副作用早已發生。
這篇優先比較:waiting states、actor、timestamp、expiry。正常案例、拒絕案例與故障案例都要納入;符合規則的拒絕本身就是成功結果。遇到 timeout、重試或人工核准時,還要檢查流程能否從明確 checkpoint 繼續,且不會重複執行已完成的副作用。
所有可改變外部狀態的工具都應具備窄介面、輸入驗證、授權、冪等與稽核。高影響且不可逆的動作必須保留明確確認點。發生不確定狀態時,流程應停止並交由人工處理,不能依靠模型猜測先前是否已成功提交。
判讀順序應從最終 state 與外部副作用開始,再回頭閱讀模型訊息與 trace。若文字回覆看似合理,但權限檢查、資料庫狀態或 audit event 不一致,應直接判定流程失敗。相反地,policy 正確拒絕危險要求,即使任務沒有完成,也屬於控制機制成功。
單次流程通過後,還要重播相同 request、製造並行請求並在關鍵步驟中斷。這三類測試能分別檢查冪等、一致性與復原能力,也是 Agent 從展示走向正式流程前最容易被忽略的部分。
判讀不只看最大或最漂亮的數字。這一天真正要回答的是:高影響動作在 commit 前保留明確人工關卡。
如果核心指標改善,但錯誤率、尾端延遲、資源成本或恢復能力變差,這代表取捨,而不是無條件進步。相反地,沒有改善也不是無效結果;至少能排除一條看似合理、實際上不值得增加複雜度的路。
今天的工程判斷是:高影響動作在 commit 前保留明確人工關卡。無論結果支持或否定原本假設,都必須保留完整條件,才能和下一天的實驗串在一起。
下一篇將處理:Idempotency:Agent 重試一次,為什麼不能執行兩次。