AI Agent決策主權怎麼保留？Delegation Level、Human Gate、Default與Revocation

AI Agent決策主權怎麼保留？Delegation Level、Human Gate、Default與Revocation

先講結論：AI Agent替人完成越多中間步驟，越需要區分Decision Right與Execution Right。本文整理Inform、Recommend、Draft、Approval、Limited Action與Autonomous Mandate六級委派，並處理Default、Automation Bias、Consent Fatigue、Override、Appeal與Kill Switch。

AI Agent決策主權怎麼保留？Delegation Level、Human Gate、Default與Revocation在講什麼？ AI Agent替人完成越多中間步驟，越需要區分Decision Right與Execution Right。本文整理Inform、Recommend、Draft、Approval、Limited Action與Autonomous Mandate六級委派，並處理Default、Automation Bias、Consent Fatigue、Override、Appeal與Kill Switch。

先記住哪個結論？ 核心是把「AI Agent決策主權怎麼保留？Delegation Level、Human Gate、Default與Revocation」放回完整脈絡，區分已知資訊、背景與可延伸的判斷。

文中整理了哪些重點？ 文章依序整理：AI Agent替人完成越多中間步驟，越需要區分Decision Right與Execution Right。本文整理Inform、Recommend、Draft、Approval、Limited Action與Autonomous Mandate六級委派，並處理Default、Automation Bias、Consent Fatigue、Override、Appeal與Kill Switch。，並補充相關背景、影響與讀者可查證的線索。

讀者最容易忽略什麼？ 不要只看標題；請同時確認時間、人物、作品或事件名稱，以及資訊的原始來源。

這個主題和台灣讀者有何關係？ 對台灣讀者而言，清楚的中文脈絡、關鍵字與可延伸閱讀入口，能讓後續查證更有效率。

哪些資訊需要再核對？ 涉及日期、名單、票價、健康、政策、交通或產品規格時，仍應以文章列出的一手來源與最新公告為準。

如果只看一段，建議看哪裡？ 可先讀這個答案區與文章開頭，再依需求回到正文的背景、分析與常見問題。

這篇內容適合誰？ 適合想快速掌握「AI Agent決策主權怎麼保留 Delegation Level Human G…」並需要延伸閱讀入口的讀者。

一句話總結？ 一句話：AI Agent替人完成越多中間步驟，越需要區分Decision Right與Execution Right。本文整理Inform、Recommend、Draft、Approval、Limited Action與Autonomous Mandate六級委派，並處理Default、Automation Bias、Consent Fatigue、Overrid…

AI Agent影響決策主權的方式，通常不是突然取代人類，而是逐步接管搜尋、排序、推薦、填寫、發送和執行。人最後只看到一個已經整理好的選項，卻不知道哪些替代方案被排除、哪些預設值影響了結果。

保留主權需要區分Decision Right與Execution Right。人可以把低風險執行交給Agent，仍保留目標、預算、資料、例外和高影響結果的決定權。每一項委派都應有Scope、期限、Evidence、Override和Revocation。

• Decision Right決定做不做；Execution Right決定如何執行。
• Agent委派可分為Inform、Recommend、Draft、Approval後執行、限制內執行與Mandate內自主。
• 可回復、低成本和可驗收工作適合較高自動化。
• 不可回復、高影響和涉及權利的決定要保留Human Gate。
• Default、Ranking與Recommendation會改變人的選擇，即使沒有直接執行。
• Approval太多會造成Consent Fatigue和Automation Bias。
• Material Change應重新取得同意，不能沿用舊授權。
• 使用者要能查看、Override、Appeal、Correct和Revoke。
• Kill Switch需要真的停止Token、Scheduled Task和Pending Action。

AI Agent 的決策主權與人類閘門

AI Agent 決策主權怎麼保留，應把 Delegation Level、Human Gate、Default 與 Revocation 變成明確權限模型。文章不把自動化等同授權，而是逐層定義代理可以建議、執行、送出或必須停下的動作。

主權如何留在人手上

• Delegation Level：區分讀取、建議、可逆執行、外部送出與不可逆決策。
• Human Gate：付款、刪除、公開發佈、法律／醫療／高風險行動需人工確認。
• Default：權限不明時採取保守預設；Revocation 要能即時撤回 token／工具權限。

本文以「AI Agent 的決策主權與人類閘門」為主線，補回人物、作品、制度、技術、場景與它們之間的關係，讓讀者能從具名實體一路追到實際流程與文化語境。

Decision Right與Execution Right

權利	問題	例子
Decision Right	是否要採取行動	是否購買、發布、退款或部署
Execution Right	如何完成已決定的行動	填表、安排時間、執行命令
Review Right	誰能檢查和推翻	主管、法務、帳戶Owner
Revocation Right	誰能停止未來行動	撤銷Token、停用Agent

很多系統只顯示「允許Agent使用工具」，卻沒有說它是否能替使用者做出決定。授權介面應分開顯示讀取、建議、草稿和執行。

六級Delegation Ladder

級別	Agent角色	例子
1 Inform	整理資料，不做建議	彙整Email和來源
2 Recommend	提出選項和理由	推薦三個供應商
3 Draft	準備可修改成果	Email、報告和合約草稿
4 Act after Approval	人確認後執行	寄信、建Event、更新CRM
5 Act within Limits	在金額、品類或規則內行動	固定耗材補貨
6 Autonomous within Mandate	在明確Mandate內持續執行	低風險巡檢與修復

能力升級不代表Delegation Level應自動提高。每一級都需要證據、風險評估和回退。

Human-in-the-loop、On-the-loop與In-command

模式	人類角色	適合
Human-in-the-loop	每次高風險Action前批准	付款、發布和權限
Human-on-the-loop	Agent執行，人監控和介入	可回復、低風險大量工作
Human-in-command	人設定目標、政策和停止權	所有持續性Agent系統

即使使用On-the-loop，人仍需要能理解狀態、快速介入和真正停止系統。

可回復與不可回復Action

• 草稿、標籤和內部排序通常可回復。
• 寄信和發布部分可回復，但外部已經看見。
• 付款、刪除、解僱和法律承諾難以回復。
• 資料外洩即使刪除也無法完全收回。
• 長期訂閱和合約具有延後成本。

不可回復性越高，Approval需要顯示更多Evidence、影響和替代方案。

High-impact Decision

• 就業、升遷和薪資。
• 信用、保險和金融資格。
• 醫療、照護和安全。
• 法律權利和政府服務。
• 教育錄取和紀律。
• 大額採購和資產處分。

這類決定不應只提供Model Score。受影響者需要知道資料、理由、如何修正錯誤和如何申訴。

Default和Choice Architecture

設計	可能影響
預設勾選	使用者可能未真正選擇
單一推薦	其他方案被隱藏
排序	第一名獲得不成比例注意
自動續訂	惰性轉成長期成本
Confirm文案	框架影響風險感受

• 顯示Default由誰設定。
• 提供替代方案和排序依據。
• Sponsored或平台利益清楚揭露。
• 高影響設定不使用模糊Opt-out。
• 使用者能保存自己的Preference。

Automation Bias

Automation Bias指人過度依賴系統建議，尤其在介面看起來權威、時間壓力大或需要連續批准時。Agent說明完整，仍可能建立在錯誤資料上。

• 顯示Source和Uncertainty。
• 高風險案例要求人主動填寫理由。
• 提供反例和第二方案。
• 抽樣檢查Approved Action。
• 不能用「AI建議」轉移責任。

Consent Fatigue與Approval Fatigue

• 過多Permission Popup讓人習慣直接同意。
• 模糊摘要讓使用者無法判斷影響。
• 批次操作被拆成大量小確認。
• 低風險和高風險使用相同介面。
• Approval在數小時後才執行，Context已改變。

應將低風險Action放入明確Mandate，高風險Action則顯示完整Preview、差異和有效期限。

Material Change需要重新同意

• 新增資料來源或Connected App。
• 從Draft升級為自動Send。
• 提高金額、地區或品類。
• 更換Model或第三方Provider。
• Retention或訓練政策改變。
• 新增Scheduled或Background Action。

舊授權不能自動覆蓋新的重大能力。系統要顯示改了什麼，以及不接受時會怎樣。

Scope、Budget、Time和Data Limit

delegation:
  purpose: schedule internal meetings
  data: calendar availability only
  actions: draft and create after approval
  people: company domain
  budget: none
  valid_until: 2026-08-31
  excluded:
    - external invitations
    - travel booking
    - deleting events

委派範圍應能被系統強制執行，不只寫在Prompt中。

Evidence與Explainability

• 使用哪些資料和版本。
• 依照哪些規則篩選。
• 有哪些替代方案。
• 哪些條件不確定。
• Action會修改什麼。
• 失敗如何回復。

說明不必展示完整Chain of Thought，應提供能讓人做決定的Evidence、Rule和Impact。

Override、Appeal和Correction

權利	用途
Override	立即改變或取消Agent建議
Appeal	要求另一個人或流程重新審查
Correction	修正錯誤資料和Preference
Explanation	取得可理解理由和來源
Deletion	移除不必要的Activity與Memory

人工覆核者必須有時間、資料和推翻系統的權限，不能只是替AI背書。

Revocation與Kill Switch

1. 停止新Task。
2. 取消Pending和Scheduled Action。
3. 終止In-flight操作或轉人工。
4. 撤銷OAuth、Token和Payment Credential。
5. 保留必要Audit與Receipt。
6. 顯示哪些外部結果無法撤回。

關閉介面上的Agent開關，不一定撤銷第三方Session和Background Job。Kill Switch需要涵蓋完整執行鏈。

個人Agent控制頁

• Connected Data和Account。
• 已授權的Read、Draft、Send、Delete和Payment。
• 月度Budget和交易限制。
• Scheduled與Recurring Task。
• Pending Approval。
• 最近Action和Receipt。
• Model、Provider和Retention。
• 一鍵Revoke和Export。

團隊Decision Rights Matrix

決定	Agent	Owner	Approver
客服草稿	Draft	Support Agent	依風險
退款	Recommend	Support Lead	Finance／Policy
公開內容	Draft	Editor	Brand／Legal
Production Deploy	Prepare	Engineer	Code Owner／SRE
招聘決定	Inform	Hiring Manager	Human Panel

Agentic Commerce的交易授權可閱讀Agentic Commerce是什麼？；辦公室逐級放權可閱讀辦公室AI Agent怎麼導入？。

常見問題

AI Agent會奪走人的決策權嗎？

取決於Delegation設計。人若保留目標、限制、Approval、Override和Revocation，Agent可以只承接執行。

哪些Action一定要人工確認？

付款、刪除、公開發布、權限、法律承諾、正式部署和高影響個人決定。

如何避免Approval Fatigue？

低風險行動使用明確Mandate，高風險行動顯示完整Preview和期限，並定期Review授權。

決策主權不要求人親手完成每一個步驟，而是確保人知道自己委派了什麼、能理解系統如何選擇，並在關鍵時刻有能力停止、修正和承擔。

YOLO_DEPTH_IMAGE_37331_20260817

AI Agent 越能替人完成中間步驟，越不能只問「它能不能做」，還要問「誰有權決定做不做、誰有權執行、誰能撤銷，以及出錯後誰能提出異議」。很多 Agent 產品把工具呼叫成功當成自動化成功，卻沒有分開 Decision Right 與 Execution Right：模型提出一個付款、刪除、發布或封鎖的選項，系統便直接執行，最後再用一個「使用者已同意」的模糊設定替整條鏈背書。這種設計讓責任、風險和使用者意圖都混在一起。

保留決策主權的核心，不是讓人手動批准每一個微小步驟，而是把委派拆成可理解的層級，為每一層設定適合的資訊、建議、草稿、批准、執行和撤銷權限。低風險、可逆、規則明確的工作可以自動化；涉及金錢、公開承諾、個資、不可逆刪除或他人權利的工作，應把決策點留在明確的 Human Gate。Agent 可以準備證據、比較選項和產生草稿，但「替誰做出哪一個承諾」不應被藏在一個看不見的 prompt 裡。

先把 Decision Right 和 Execution Right 分開

Decision Right 是選擇目標、政策或結果的權利，例如決定是否接受退款、是否發布文章、是否把某筆交易標記為高風險；Execution Right 是在決策已成立後，呼叫工具把它落實的權利，例如寫入資料庫、寄出郵件、轉帳或刪除檔案。兩者可以由不同角色持有。人可以決定「批准這筆款項」，Agent 或受限服務才執行「依已批准的 ID 發送」，而且執行器不能自行改變金額、收款人或範圍。

若兩種權利未分開，Agent 一次工具呼叫就可能同時完成推理、選擇與副作用。之後即使發現錯誤，也很難知道是資料錯、政策錯、模型選擇錯，還是工具執行錯。比較穩健的流程是：Agent 先提出結構化 decision proposal；policy engine 檢查條件；需要時交給人批准；execution service 只接受帶有決策版本、範圍和有效期的 command；完成後再由 verifier 讀回實際結果。這樣每一個環節都有自己的責任邊界。

決策提案不能只是一段文字。至少應包含候選行動、理由與來源、受影響對象、預期副作用、風險等級、不可改變的欄位、所需批准者、有效期限、撤銷方法和 fallback。若 Agent 沒有足夠資訊，合法輸出應該是 needs_information 或 blocked，而不是硬選一個看起來完整的答案。結構化提案也讓介面可以清楚顯示「你正在批准什麼」，降低使用者在長對話中誤把建議當成已執行的風險。

六級委派：從 Inform 到 Autonomous Mandate

可以把委派分成六級，但它們不是固定的產品標準，而是一個協助設計與溝通的尺。第一級是 Inform：Agent 只整理資訊、標出不確定性和來源，不能替人選擇。第二級是 Recommend：Agent 可以排序選項並提出理由，但最後決策必須由人做。第三級是 Draft：Agent 可以產生郵件、程式碼、文章、退款說明或設定變更的草稿，但草稿不等於提交。

第四級是 Approval：Agent 可以把完整提案送到批准流程，人確認後才進入下一步；批准畫面必須顯示範圍、版本、期限和不可逆後果。第五級是 Limited Action：在金額、對象、頻率、時間或資料欄位都受限的情況下，Agent 可以自動執行，超出限制就升級。第六級是 Autonomous Mandate：人在明確範圍內授予一段時間的自主權，Agent 可依規則持續判斷與執行，但仍要有監控、審計、撤銷、到期和人工接管。

六級不是越高越先進。委派級別應由傷害幅度、可逆性、外部性、決策頻率、資料敏感度和使用者意圖共同決定。同一個 Agent 可以在「整理每日報表」使用 Limited Action，在「對外發布公司聲明」退回 Draft 或 Approval。不要用「這個使用者已經信任 Agent」作為永久升級理由；信任是情境性的，授權應有範圍、時間、用途和可撤銷性。

Default 不是中立選項

當介面提供「自動處理」或「稍後再確認」，預設值本身就在影響決策。忙碌的使用者可能連續點擊下一步，最後在沒有真正理解內容的情況下完成授權；也可能因為通知太多而形成 consent fatigue，把所有批准都視為例行操作。設計 default 時，不能只看轉換率或流程速度，還要看使用者是否能辨識風險、是否有足夠時間撤回、以及低摩擦是否把重要決策偽裝成一般設定。

低風險的 default 可以讓 Agent 自動整理、排序或草擬；高風險操作應預設為不執行，直到範圍和批准者都明確。對長時間 mandate，預設應該是短期限、最小權限和超限即停，而不是永久有效。每次重新授權要顯示與上次不同的範圍，例如新增資料來源、提高上限、增加外部收件人或改變不可逆行為。把變化說出來，比在設定頁藏一個總開關更能保留實際知情同意。

Default 還要考慮例外情況。若批准服務暫時不可用，不能把「無法確認」自動解讀成「批准」；若模型沒有回覆，不能把空值當成同意；若政策 engine 版本改變，舊 mandate 也可能需要重新評估。對每個 default 都寫明 fail-open 或 fail-closed 的理由，並把例外結果記錄成可查詢的事件。這樣團隊才知道自動化是在哪些條件下停下來，而不是只在事故後猜測。

Human Gate 要能真正判斷，而不是形式批准

Human Gate 的品質取決於人看到什麼。若畫面只有「Agent 建議執行」和一個大大的確認按鈕，使用者很難檢查推理與副作用。好的批准介面至少要顯示：目標資源、即將改變的欄位、來源與時間、模型的不確定性、預期影響、不可逆部分、替代方案、有效期限，以及批准後如何撤銷。對批次操作，還要顯示總數、抽樣細節、例外項目和是否全部遵守相同規則。

批准不是把責任推給使用者。系統仍要先做 schema、權限、政策、敏感資料和風險檢查；人只應處理需要語境或價值判斷的部分。若 Agent 提交的提案缺少來源或把不確定內容寫成確定事實，介面應先阻擋，而不是要求人替模型補漏洞。OpenAI Agents SDK 的官方文件把 guardrails 描述為可對輸入、輸出或工具呼叫做檢查的機制，也提供 human-in-the-loop 相關能力；這些能力可以協助建立 Gate，但應用程式仍需自己定義什麼叫做足夠證據和誰有批准權。

批准必須綁定版本。人批准的是某個提案 hash、資料快照和有效期限，不是「這個 Agent 現在想做的任何事」。若 Agent 在批准後重新計算出不同金額、不同收件人或不同檔案集合，原批准應失效並重新進 Gate。這個看似麻煩的版本鎖，是避免「批准畫面看到 A，實際執行 B」的基本控制。批准事件也應留下批准者、時間、理由、顯示版本和使用的 policy 版本，讓日後可以還原決策脈絡。

Revocation、Appeal 與 Kill Switch

撤銷不是把介面上的開關設為關閉而已。若 Agent 已取得短期 token，撤銷服務要能讓 token 立即失效；若外部工作已排入佇列，撤銷要能取消尚未執行的工作；若副作用已發生，系統要提供補救或回滾，而不能假裝把歷史刪掉。每個 mandate 都應有 subject、scope、issued_at、expires_at、policy_version、revocation_id 和目前狀態，工具執行前重新檢查它是否仍有效。

Kill switch 是最後一道停止路徑，不能依賴同一個出問題的 Agent 自己配合。它應由較低層的 execution gateway、權限服務或佇列控制器執行，能阻斷新工具呼叫、凍結尚未提交的工作並標記未完成的 run。啟動 kill switch 後，要知道它影響哪些租戶、工作和服務，誰能解除、解除前要重新驗證什麼。若停止本身會造成資料不一致，也要有安全的 drain 或 recovery 流程。

Appeal 則處理「系統做了決定，但人認為決定不合理」。申訴不應只把原本的錯誤 prompt 再交給同一個 Agent；要保存原始輸入、政策版本、工具事件、批准資料和真實結果，讓獨立 reviewer 可以重建當時的狀態。申訴結果可能是維持、撤銷、補償、修正政策或重新訓練，但每一類都要有明確的狀態和責任人。只有能被追查和處理的異議管道，才算真正保留決策主權。

委派策略要依風險而非依模型能力

模型越強，不代表可以自動處理所有風險。風險評估至少要看五個維度：行動是否可逆、是否影響第三人、是否涉及敏感資料、錯誤是否能被及時發現、以及損失上限是否可控制。可逆的檔案重新命名，和對外發送法律承諾，不能因為使用同一個模型就套用同一個 autonomy level。模型能力只影響它能否提出較好的方案，不應直接決定它擁有多少外部權限。

可以用分數或規則先做初步分流，但不要把單一風險分數當成最後答案。任何涉及刪除、付款、公開發布、身份驗證、醫療或法律判斷的操作，都應有領域政策和人工升級路徑。若多個中等風險因素同時出現，例如新收件人、金額變大、資料來源不完整和模型不確定性升高，系統應合併升級，而不是讓每一項各自低於門檻便通過。

工具 guardrail、Agent guardrail 與 policy engine

Agent guardrail 通常檢查輸入或輸出是否符合內容、格式、範圍和安全規則；tool guardrail 則在工具執行前後檢查具體參數與結果。兩者都重要，但不能取代一個掌握授權狀態的 policy engine。輸出看起來安全，不代表該 Agent 有權修改目標；工具參數符合 schema，也不代表它可以對這位使用者執行。權限、政策、版本和批准狀態應在靠近副作用的位置再次檢查。

OpenAI Agents SDK 的 guardrails 文件區分 input、output 和 tool guardrails，並指出不同 guardrail 介入的時間點不同。這對設計有兩個啟示：第一，若要在昂貴模型呼叫前阻擋輸入，必須選擇真正能在前置階段執行的檢查；第二，完成輸出檢查不等於完成工具權限檢查，工具本身仍要有自己的邊界。不要只在最後驗證一段自然語言回覆，因為高風險副作用可能早已在中間工具階段發生。

Policy engine 的結果要可解釋。回傳 allow、deny、ask_human 或 needs_more_evidence，並附上命中的規則、政策版本、有效期限和需要補充的欄位。Agent 可以根據結果整理下一步，但不能自行把 deny 改寫成 allow。若規則衝突，系統要有優先級和安全的預設處理，不能讓模型用語意猜測哪條政策比較重要。

審計與 tracing：留下決策鏈，不只留下聊天紀錄

一條可稽核的決策鏈要能連起 user intent、Agent proposal、policy decision、human approval、tool command、external effect 和 verification result。OpenAI Agents SDK 官方說明 tracing 可以記錄模型生成、工具呼叫、handoff、guardrail 和自訂事件；在產品設計上，這些 trace 應再與任務 ID、提案版本、批准 ID 和外部資源 ID 關聯。單看一段對話，往往看不到工具實際送出的參數，也看不到哪一個 policy 讓它通過。

審計資料要區分可讀內容與敏感內容。保存完整 trace 可能包含個資、商業機密或 token 片段，因此要有資料最小化、遮罩、存取分級、保留期限和刪除政策。若為了除錯需要原始 payload，可以放在受限 artifact store，trace 只保存 reference、hash 和摘要。另一方面，不能因為隱私要求就把所有決策證據刪到無法申訴；應事先定義哪些欄位必須保存、哪些欄位可匿名化、誰能在何種理由下查看。

常見錯誤：把 autonomy 當成一個總開關

第一種錯誤是設定一個全域「允許 Agent 自主」開關，讓所有工具共享同一份權限。這會把低風險整理工作和高風險外部操作綁在一起。第二種是把使用者一次同意解讀成永久授權，忽略時間、情境和資料範圍的變化。第三種是只要求人批准結果摘要，卻沒有把批准版本綁到實際 command。第四種是只在 UI 顯示撤銷，但底層佇列與 token 仍可繼續執行。

第五種是把「模型有引用來源」當成決策正確。來源可能過期、互相矛盾或只支持其中一個前提；驗證應檢查主張與行動的對應關係。第六種是讓同一個 Agent 產生提案、批准提案、執行提案和替自己寫通過報告。角色分工未必需要四個模型，但至少要讓權限和驗收不被同一個不受約束的流程完全控制。第七種是忽略預設和例外，把超時、缺資料、policy service 故障都當成可以繼續。

從設計到發布的實作順序

第一步先列出每一個可能的外部副作用，為它標記可逆性、影響範圍、敏感度和最大損失；沒有清單就無法設計委派。第二步為每種副作用建立 command schema、scope、idempotency key、有效期和撤銷方法。第三步把 Agent 輸出改成 decision proposal，而不是直接呼叫高權限工具。第四步加入 policy engine 和 Human Gate，先在 dry-run 中記錄它會如何分流，再逐步啟用受限 action。

第五步建立獨立 verifier，從外部讀回真實狀態，並測試批准後內容改變、重試、逾時、部分成功、撤銷競態和 policy 版本漂移。第六步開啟 tracing 與成本、延遲、拒絕、升級、撤銷和人工退回監控。第七步用 feature flag 或小範圍 mandate 做 canary，保留原本手動流程作為 fallback。每一個 autonomy level 都應有自己的停止條件，不能因為低級別測試通過就直接放大到高級別。

決策主權驗收清單

1. Decision Right 與 Execution Right 是否由不同邏輯邊界持有？
2. 每個 Agent 是否只拿到完成當前工作所需的最小工具與資料？
3. 委派級別是否明確區分 Inform、Recommend、Draft、Approval、Limited Action 與 Autonomous Mandate？
4. 高風險行動是否預設停下，並在批准畫面顯示實際範圍、版本、期限和不可逆後果？
5. 批准是否綁定提案 hash、資料快照和 policy version，而不是只綁一段對話？
6. 超出金額、對象、頻率、時間或資料範圍時，是否一定升級或拒絕？
7. 撤銷是否能讓 token、佇列工作和後續工具呼叫真正停止？
8. 是否能在不依賴原 Agent 的情況下啟動 kill switch、回滾或人工接管？
9. trace 是否連接意圖、提案、政策、批准、工具、副作用和驗證結果？
10. 測試是否涵蓋空值、服務故障、部分成功、版本漂移、重試競態與申訴？

來源與分析邊界

本文以OpenAI Agents SDK Agents 官方文件核對 Agent、tools、handoffs、guardrails 與 runtime 行為的組件邊界；以OpenAI Agents SDK Guardrails 官方文件核對 input、output 與 tool guardrail 的介入方式；以OpenAI Agents SDK Running agents 官方文件核對 runner、run config、tracing、human-in-the-loop 與長時間執行相關的官方說明；並以OpenAI Agents SDK Tracing 官方文件核對模型生成、工具、handoff、guardrail 與自訂事件的 trace 範圍。官方文件說明的是 SDK 能力，不等於替任何組織的授權政策或安全結果背書。

本文提出的六級委派、Decision／Execution 分離、default 設計、policy engine、approval binding、revocation、appeal、kill switch、獨立 read-back 與發布順序，是 YOLO LAB 的架構分析與工程建議，不代表 OpenAI 或 Agents SDK 規定的唯一治理模型。圖中的階梯、人工節點、權限 token、撤銷開關、停止槌與審計資料流是概念化原創示意，不是官方 UI、產品截圖、實際 trace 或安全認證結果。

AI Agent 的決策主權，不是把所有決定都留給人，也不是把所有決定都交給模型，而是讓每一個決定都有可理解的委派級別、可檢查的證據、可限制的執行權、可追蹤的批准、可立即的撤銷和可實際運作的申訴路徑。當 Agent 只能在明確範圍內提出與執行，當超限會停下而不是猜測，當系統能把真實副作用讀回並交給獨立驗證，自治才會從「方便的黑盒」變成「可負責的協作工具」。

增量：AI Agent 的決策主權，要用可撤回的授權層級設計

Delegation Level 不是把 Agent 分成「聰明」或「不聰明」，而是把它能替人做的事分級。讀取資料、提出方案、修改工作區、對外發送與不可逆寫入，應該是不同權限，而不是同一個自動化開關。

Human Gate 也不應只出現在流程最後。更有效的做法是把人工閘門放在風險跳升的位置：即將對外發布、改動共享資料、使用敏感資料、超出預算，或準備執行無法回復的動作。閘門前必須顯示意圖、範圍、差異與回復方式。

Default 與 Revocation 是常被漏掉的兩面。Default 決定不確定時 Agent 會停下來還是繼續；Revocation 則決定人是否能在執行中撤回 token、工具或工作階段。若沒有這兩項，所謂 human-in-the-loop 很可能只是事後背書。

驗收可以用四個問題：授權是否最小化、升級條件是否可觀測、拒絕後是否安全收尾、每個決策是否留下可追蹤的理由。好的 Agent 不是替人消滅判斷，而是把判斷點變得更早、更清楚、更容易撤回。