AI Agent 人類閘門怎麼設計？「只提案不執行」架構解析｜AIRUN
AI Agent 人類閘門怎麼設計？「只能提案、不能執行」的架構開始被寫進程式碼
AI agent 只要能自己批准自己的動作，風險就已經寫在你的架構裡，跟模型聰不聰明無關。導入前唯一該先確認的，是批准權還在不在它手上。
2026 年 8 月中，兩件事被放在一起討論。一個叫 agent-safe-pipeline 的開源專案在 GitHub 上被看見，它的標語只有六個字：Let agents propose. Let policy decide.（讓 agent 提案，讓策略決定）。倉庫本身未標明確切發布日期，能確認的是截至本文發稿日 2026-08-16，它顯示 448 顆星、58 個 fork、28 次 commit。另一邊，Allen Bargi 在 8 月 15 日發表短文——《Working With AI Feels More Like Leadership Than Coding》，並在 Hacker News 上引出一串討論，講的是當 AI 自主性升高，人該怎麼保留關鍵判斷。
一邊談架構，一邊談心態，指向同一個缺口：AI 已經能做事了，但沒人講清楚它憑什麼可以動手。
AI Agent 人類閘門是什麼？
AI Agent 人類閘門，指的是在系統設計上把「批准權」從 AI 身上拿走：agent 只能提出動作提案，由獨立的策略層裁決放不放行，敏感動作停在真人核可，執行用的憑證放在 agent 碰不到的地方。這道限制寫死在架構裡，由執行層強制生效。
先把三個詞講白話。Agent（代理）＝能自己規劃步驟、呼叫工具去完成任務的 AI 程式，跟只會回話的聊天機器人差在它會真的動手。Intent（意圖）＝agent 提出的那份動作提案，寫明要做什麼動作、對哪個目標、帶哪些參數。Grant（授權票）＝通過審核後發給執行元件的一次性通行證，用完即失效。
差別在哪？現在市面上多數 AI 客服、AI 業務工具，是把 API 金鑰直接交給 agent，再用系統提示叮嚀它「重要動作要先問人」。這種設計裡，攔不攔得住完全取決於模型當下的判斷。閘門式架構把這件事反過來：就算 agent 決定要越權，它手上根本沒有可以直接呼叫下游系統的鑰匙。
為什麼 2026 年 8 月開始有人認真談這件事？
因為 agent 從「會寫」變成「會做」的時間點，剛好落在企業大規模導入之前。能確認的時序只有這些：8 月 15 日 Allen Bargi 發表那篇筆記，本文發稿日為隔天的 8 月 16 日；開源倉庫沒有標出上線日期，只能從發稿日當下的星數與 commit 數看出它正在被關注。
Bargi 那篇文章值得台灣老闆讀，因為它講的其實是管理問題。他寫道，AI 執行於軟體之上，但與它共事並不完全可預測——同一個請求可能得到不同答案。他也把界線劃得很乾淨：這不代表 AI 是人，它沒有親身經驗、沒有課責能力、沒有人類判斷（no lived experience, accountability, or human judgment）。
這句話是整件事的技術前提。沒有課責能力的東西，就不該擁有最終批准權。你不會把公司印章交給一個不必為結果負責的人，理由跟這裡一模一樣。
「只能提案、不能執行」的架構長什麼樣？
這套參考架構把一次動作拆成五段，每一段都有獨立負責的元件，agent 只碰得到第一段：
- Agent 提案——輸出想做的動作、目標、參數。
- IntentCapture——把提案凍結成不可竄改的意圖紀錄，事後可比對。
- DecionisGate——獨立的策略裁決，輸出 ALLOW／ESCALATE／BLOCK 三選一。
- Presence——需要升級時，走到經驗證的真人核可，核可後策略層會再評估一次。
- SafeExecutor——拿著一張綁定該筆意圖、只能用一次的授權票，去呼叫真正的 API。
專案文件裡有三條寫死的紅線，直接翻譯過來就是：agent 不得自行判定自己的動作是否獲得授權、不得持有下游的特權憑證、不得選擇由哪一個受信任的處理程式來執行。
最關鍵的一個設計細節：SafeExecutor 不接受 agent 傳進來的任意 callback。它只認一份密封的 ActionRegistry（動作名冊）——事先註冊好、agent 改不了的動作對照表，把動作名稱對應到指定的處理程式，並在消耗授權票之前先驗參數。這條擋掉的正是「AI 自己生一段程式碼叫系統去跑」這類攻擊路徑，細節寫在倉庫的 THREAT-MODEL.md。
倉庫附了四個可跑的範例，看範例比看文件更快懂：最小的 BLOCK 流程、Shopify 退款 agent（依金額分級 ALLOW／ESCALATE／BLOCK）、GitHub 部署 agent（環境與 force-push 控管）、以及一個把 MCP 工具納管的 stdio 伺服器。環境需求是 Node.js 22.14 以上加 pnpm 9。
誠實標注一句：官方 README 自己寫明，這是 library 與可執行的參考實作，不是託管的授權服務，也不取代供應商端的身分驗證、最小權限、網路隔離與事件應變；安全宣稱僅在文件描述的信任邊界被維持時成立。範例使用的是明示為非正式環境的憑證來源。把它當架構教材看，剛剛好。
ALLOW／ESCALATE／BLOCK 三種裁決差在哪？
三種裁決對應三種風險等級，決定權都不在 agent 手上：
| 裁決 | 白話意思 | 誰做決定 |
|---|---|---|
| ALLOW | 直接放行，agent 無感 | 策略層自動判定 |
| ESCALATE | 升級到真人，等點頭才動 | 經驗證的真人核可，核可後策略層再評估一次 |
| BLOCK | 直接擋掉，不留商量空間 | 策略層自動判定 |
| — | 共同前提：憑證與執行權都不在 agent 手上 | 架構寫死，非模型判斷 |
官方範例只說明了分級依據——退款 agent 按金額分級、部署 agent 按環境與 force-push 控管——並未列出哪個金額或哪個環境對應到哪一種裁決，門檻是各家自己要設的東西。
對老闆來說，這張表最有用的資訊是中間那列。ESCALATE 才是實際運作中最常觸發的狀態，它決定了你的人要花多少時間在按核可，也決定了自動化到底省不省事。門檻設在哪、誰有權改門檻，是採購時該問到底的問題。
叮嚀 AI 不要亂做，跟把閘門寫進架構，差多少？
差別在出事的當下有沒有東西擋著。三種常見做法攤開比較：
| 做法 | 誰批准動作 | 憑證放哪 | 出事後查得到嗎 | 實際強度 |
|---|---|---|---|---|
| Prompt 叮嚀「先問我」 | AI 自己 | AI 手上 | 靠對話紀錄，易散失 | 請求層級，擋不住 |
| 全自動跑＋人工事後抽查 | 沒人，事後補救 | AI 手上 | 抽到才查得到 | 損失已經發生 |
| 架構級閘門（本文架構） | 獨立策略層＋真人 | agent 碰不到 | 不可竄改的意圖紀錄可回溯 | 執行層擋下 |
第一種做法真正的漏洞在權力結構本身——prompt 只是寫給模型的建議文字，模型有機率不照做，一次就夠痛。第二種在台灣中小企業最常見，因為導入時只想著省人力，等到發生第一筆錯誤退款或錯發客戶信，才發現手上留下的紀錄根本不足以還原當時發生了什麼事。
這對台灣中小企業意味著什麼？
意味著你評估 AI 工具的問題該換一組。多數老闆現在問的是「這個 AI 準不準」，該問的是「它做錯的時候，誰擋得住、多久發現得了、賠多少」。
給一組可以今天就用的分級標準。把你想交給 AI 的動作，按可逆性分成三類：
| 風險等級 | 動作舉例 | 建議設定 | 人要花的時間 |
|---|---|---|---|
| 低（可逆、對內） | 查訂單、整理逐字稿、生內部草稿 | 全自動放行 | 幾乎為零 |
| 中（可逆、對外） | 回覆客服訊息、寄追蹤信、開工單 | 條件放行＋全程留痕＋每日抽查 | 每天 10 分鐘 |
| 高（不可逆或涉錢） | 退款、付款、報價、簽約、刪資料、對外公告 | 一律停在真人核可 | 依筆數，通常是按鈕一下 |
台灣中小企業最常踩的坑，是把「回覆客戶」誤放進低風險那格。對客戶說出去的話收不回來，它屬於中風險起跳；一旦內容涉及價格、交期或任何承諾，直接跳到高風險。我們自己在做 AI 業務與客服流程時，錢、承諾、合約帳款這三類動作永遠停在人這關，不論 agent 判斷得多有把握。
另一個判斷：不要因為現在還沒有成熟的商用閘門服務，就退回全手動。分級與留痕是你自己就能先做的，先把低風險那一格交出去，省下的時間拿去處理真正需要人判斷的事。
導入 AI agent 做業務或客服時，怎麼確保它不會自己亂做決定？
把批准權從 AI 手上拿掉，具體做四件事：動作分級、憑證隔離、真人閘門、全程留痕。這四件事都是採購時可以驗證的，不必等上線後才知道。
拿這五題去問廠商，答不出來的直接刷掉：
- agent 能不能自己批准自己的動作？如果能，擋它的是什麼？
- 呼叫我方系統（金流、客戶資料系統、電商後台）的憑證放在哪裡？agent 拿得到嗎？
- 哪些動作會升級到真人？門檻寫在哪個檔案、誰有權限修改、改了會留紀錄嗎？
- 每一次執行是否留下可回溯的紀錄，包含當時的提案內容、裁決結果與核可的人？
- 人批准之後那張授權，能不能被重複使用、或被挪去執行別的動作？
第五題最容易被忽略，也最能看出對方有沒有真的想過這件事。這正是那套開源架構用「單次使用、綁定意圖」的授權票要解決的問題——批准了 A 動作，就不能拿去做 B。
如果廠商聽不懂這五題，你要的東西他大概沒有。想快速對照一份完整的架構文件，可以直接讀 ARCHITECTURE.md，它把信任邊界畫得比多數商用產品的白皮書清楚。
我的結論
AI agent 的安全問題，會在未來一年從模型層轉移到權限層。理由很簡單：模型會愈來愈強，強到「它會不會做錯」不再是主要變數，「它做錯時能造成多大破壞」才是。而後者完全由架構決定，跟模型無關。
所以我的立場明確：任何要接你金流、客戶資料或對外發言權的 AI 系統，如果它能自己批准自己的動作，就不該上線。這條線畫在導入之前最便宜，畫在第一筆錯誤退款之後最貴。
企業導入 AI，人的角色會愈來愈像 Bargi 說的那樣——給脈絡、講清楚要什麼、設好邊界、對結果做判斷。那道邊界必須存在於系統的程式碼裡，寫在期待裡的不算數。
想先看看自己的流程裡哪些動作該分在哪一格，AIRUN 的 AEO 與 AI 導入判準整理了我們實際在跑的分級方式，可以直接套用在你自己的清單上。
AIRUN 對抗式創業體檢
AgentFlow Solutions（双云行銷試運行）
常見問題
Q：AI Agent 人類閘門是什麼意思？
指的是在系統設計上剝奪 AI 的批准權：agent 只能提出「我想做什麼動作、對哪個目標、帶什麼參數」的提案，是否放行由獨立的策略層判斷，敏感動作再停在真人核可這一關。執行用的憑證放在 agent 碰不到的地方。重點在於這道限制寫在架構裡，不依賴模型自己記得要收手。
Q：用 prompt 寫「未經確認不得執行」不就好了嗎？
prompt 是請求，不是權限。模型輸出本來就帶機率性，同一句話可能得到不同結果，一次沒照做就是一次真實損失。架構級閘門的差別在於：就算 agent 決定要繞過，它手上也沒有可以直接呼叫下游 API 的憑證，動作在執行層就被擋下來。兩者可以並存，但只有後者算控制。
Q：agent-safe-pipeline 可以直接拿來上線用嗎？
官方在 README 明講這是 library 與可執行的參考實作，不是託管的授權服務，也不能取代供應商端的身分驗證、最小權限、網路隔離與事件應變；安全宣稱只在文件描述的信任邊界被維持時成立。範例跑的是官方明示為非正式環境的憑證來源。當成架構教材與採購提問清單看，比當成隨插即用的產品實際。
Q：哪些動作應該設成一定要人批准？
用可逆性分級最實際。讀資料、查訂單、生草稿屬於低風險，可以放行；改資料、寄客戶信、開工單屬於可逆但要留痕，適合設條件放行加事後抽查；退款、付款、簽約報價、刪資料、對外公告屬於不可逆，一律停在真人。台灣中小企業常見的第一個坑就是把「寄信給客戶」誤放進第一類。
Q：導入 AI 客服 agent 時該問廠商什麼？
至少五題：一、agent 能不能自己批准自己的動作？二、呼叫下游系統的憑證放在哪、agent 拿得到嗎？三、哪些動作會升級到真人、門檻寫在哪裡、誰能改？四、每一次執行有沒有留下可回溯的紀錄，包含當時的提案內容與裁決結果？五、人批准之後，那張授權能不能被重複使用或挪去做別的動作？答不出第二題和第五題的，先別簽。
Q：「AI 只能提案」會不會讓效率變得跟沒導入一樣？
不會，前提是分級做對。實務上絕大多數動作屬於讀取與生成，這些全自動跑；需要人點頭的通常只佔少數，而且人只做「看提案、按同意」這一個動作，不必自己重打一次。效率損失來自把所有動作都設成要批准，或反過來全部放行後花更多時間善後。