Agent 該多自主？用「人的角色」設計企業 agent 的核准閘門

討論 agent 時，常見的問法是「模型夠不夠聰明，可以放手讓它做」。但〈Levels of Autonomy for AI Agents〉（arXiv 2506.12469）主張，agent 的自主程度應該被當成刻意的設計決策，與它的能力和運作環境分開看待。這篇論文用使用者扮演的角色定義五個等級：L1 Operator（人下每一個指令）、L2 Collaborator（人與 agent 一起規劃與執行）、L3 Consultant（agent 主導、遇到專業或偏好問題時問人）、L4 Approver（只有在指定的風險情境才找人核准）、L5 Observer（agent 完全自主，人只能監看）。

人實際上也不是用一個全域開關來信任 agent。〈Assistant or Actor?〉（arXiv 2607.18257）觀察學生使用通用型 AI agent，發現他們的信任是逐任務校準的：找檔案、做規劃這類低風險工作願意給很大的自主空間，寄 email 則要求先確認、要能監督。這代表企業平台的權限設定應該依動作類型分層，而不是一個「允許 agent 自動執行」的總開關。

還有一個常被低估的風險：agent 也會被介面騙。CHI 2026 的〈Dark Patterns Meet GUI Agents〉測試 6 個 GUI agent 面對 16 種 dark pattern，發現 agent 因為以完成任務為優先，非常容易中招。論文舉的例子是，一個 GPT-4o 驅動的 agent 在訂閱內容創作者時被「trick question」誤導，以為同意個人化廣告是必要步驟，於是在沒有詢問使用者的情況下同意分享資料。有人在旁監督能提高避開的比例，但人與 agent 組成的團隊仍會中某些設計，而且監督本身帶來注意力窄化與認知負荷。

把這些放在一起，核准閘門的設計原則就很清楚。第一，依動作分三類：可自動執行（讀取、查詢、草擬、在沙盒內的試算），需人核准（寄出、付款、寫入外部系統、變更權限、同意任何條款），以及明確禁止。第二，核准請求要讓人在幾秒內判斷：要做什麼、對象是誰、能不能撤回、會花多少錢。第三，避免核准疲勞：低風險動作合併成一次確認，高風險動作逐一核准，否則人會開始無腦按「同意」，閘門形同虛設。

在 X Cube 上，agent runs 支援 human-in-the-loop 的核准與拒絕，目前用在平台內部的 Chat 介面；外部工具透過 connector registry 以 MCP server 的形式接入，管理員可以依角色限制哪些人能用哪些 connector。這些機制提供的是骨架，真正決定安全性的，是每個組織把哪些動作放進「需人核准」那一欄。

導入前可以先做一張動作清冊：列出 agent 可能呼叫的每一個工具與動作，標出是否可逆、是否對外、是否涉及金錢或個資，再對照 L1 到 L5 決定每一類動作要人扮演什麼角色。清冊要隨著新工具上線更新，並定期抽查核准紀錄，看是否出現大量秒核的情況。研究面要持續關注的，是 agent 對誘導式介面的抵抗力能否提升，以及監督介面能否在不增加負荷的情況下幫人抓到問題。