辦公室 AI Agent 怎麼導入？從 Shadow Mode 到人工確認的 7 步驟
第一版可以先讓 Agent 在 Shadow Mode 處理真實 Email、文件或 CRM 任務，但不改正式系統；輸出穩定後進入 Draft-only，再讓低風險且可回復的 action 經人工確認執行。付款、刪除、正式承諾與高影響決策，不應因為模型表現變好就自動取得權限。
先釐清：Shadow Mode、Read-only、Draft-only 不是同一件事
最容易混淆的是這三個名詞。
Shadow Mode
Agent 對真實工作跑一遍，但結果暫時不影響 Production。
例如：
客戶 Email
↓
人工照原流程處理
│
└──────────────→ 正式結果
同一封 Email
↓
Agent 處理
↓
Shadow Result
↓
只拿來比較
目的在取得真實證據。
Read-only
Agent 可以查資料，但不能修改。例如讀 Email、查 CRM、搜尋文件、查 Calendar 或查訂單。
Draft-only
Agent 可以建立新的中間成果，但不能讓它正式生效。例如 Email 草稿、CRM 更新建議、報價草稿、會議邀請草稿或週報草稿。
所以一個 Agent 可以同時是 Shadow Mode + Read-only，也可以是 Shadow Mode + Draft-only。這兩個維度應分開設計。
辦公室 Agent 可以用三個軸管理
1. Deployment Mode
目前工作在哪個環境？
Shadow Preview Limited Live Production
2. Permission
Agent 可以做什麼？
Read Draft Write Send Delete Payment
3. Approval Policy
什麼時候需要人？
Auto Conditional Approval Always Approval Forbidden
OpenAI 目前的企業 Workspace Agents 也採類似控制：app 可以限制為 read-only action、要求 write action 確認，也能限制 action parameters；管理者還能設定 RBAC、approval checkpoints 與 audit logs。
第 1 步：先列出所有可能產生副作用的 Action
不要先問「Agent 能不能用 Gmail？」先列動作。
| Action | 副作用 | 第一版 |
|---|---|---|
read_email |
無 | 可開 |
search_drive |
無 | 可開 |
create_email_draft |
低 | 可開 |
send_email |
對外 | Approval |
update_crm_note |
可回復寫入 | Approval |
change_price |
商業承諾 | 禁止／高層 Gate |
refund_order |
財務 | 禁止／人工 |
delete_record |
不可逆 | 禁止 |
這張 Action Inventory 會比「Agent 有 Gmail 權限」更有用，因為 Gmail 裡同時存在 Read、Draft、Send、Delete 四種完全不同的風險。
第 2 步：建立真正的 Permission Matrix
權限至少要有五個欄位。
| 欄位 | 問題 |
|---|---|
| Data | 能看什麼？ |
| Tool | 能用哪個工具？ |
| Action | 能做哪個動作？ |
| Parameter | 動作允許哪些範圍？ |
| Identity | 以誰的身分執行？ |
例如：
Tool: CRM Action: update_note Allowed: customer_id = current_case.customer_id Forbidden: price credit_limit account_owner
這比只設定「CRM write = true」安全很多。OpenAI Workspace Agents 目前也支援限制 app action parameters；這種限制本質上就是把「能使用工具」再縮小成「只能在指定範圍使用工具」。
第 3 步：先跑 Shadow Mode
Shadow Mode 的目標不是展示 Demo，而是觀察：如果真的讓這個 Agent 工作，它會做對多少？
例如 Email 客服，人工照原流程完成；Agent 同時：
分類 ↓ 查 FAQ ↓ 查訂單 ↓ 找缺件 ↓ 產生處理建議 ↓ 產生草稿
但：
不 Send 不 Update 不 Refund
每天記錄：
- classification correctness；
- required fields completeness；
- source correctness；
- draft acceptance；
- review minutes；
- exception rate；
- tool failure；
- retry；
- high-risk action attempts。
Shadow Mode 最重要的結果，是找出：Agent 在什麼條件下不應繼續。
第 4 步：從 Shadow 進入 Draft-only
當 Shadow Mode 已經證明 Agent 能穩定處理主要案例，可以讓成果真正進入員工工作區。
例如：
Agent ↓ 建立 Gmail Draft ↓ 員工開啟 ↓ 修改 ↓ 人工 Send
或者：
Agent ↓ 產生 CRM Update Proposal ↓ 業務確認 ↓ 人工寫入
這一階段最重要的指標不再只有「答案正不正確」，要開始看：
Accepted without edit Accepted with edit Rejected Escalated Review minutes
如果 Agent 每件只花 10 秒，但員工仍要花 8 分鐘重查，Draft-only 還沒有產生足夠價值。
第 5 步：Approval Gate 要批准「具體 Action」
Approval Gate 最常見的錯誤是「允許這個 Agent 寄 Email？」這個授權太大。
真正應批准的是：
Action: send_email To: customer-183@example.com Subject: 詢價資料補充 Attachment: none Source: Case #19382 Expires: 14:15
OpenAI Agents SDK 目前的 HITL 就是以具體 tool call 為單位：run 在需要批准時暫停，保存 tool、arguments 與 call ID，批准或拒絕後才繼續。
這可以避免人看到的 Action 是 A，Agent 真正執行時參數已經變成 B。
一筆 Approval Request 至少應顯示什麼？
| 欄位 | 用途 |
|---|---|
| Action | 要做什麼 |
| Target | 影響誰／什麼 |
| Parameters | 實際參數 |
| Current State | 現況 |
| Proposed Change | 會改什麼 |
| Source | 依據 |
| Risk | 為什麼需要批准 |
| Expiry | 批准多久有效 |
| Approver | 誰能批准 |
批准後最好再保存：
approval_id tool_call_id approver approved_arguments approved_at executed_at execution_result
第 6 步：只對低風險工作開 Limited Write
通過 Approval Gate 之後，也不應把所有 write action 全部解鎖。
比較合理的是挑一個可回復、範圍小、失敗容易發現的 action。
可以先測
- CRM 新增 internal note；
- 建立內部待辦；
- 建立 Calendar draft；
- 加入低風險標籤；
- 更新可還原的內部狀態。
先不要
- 正式寄出合約；
- 修改價格；
- 退款；
- 付款；
- 刪除；
- 權限提升；
- 對外正式承諾。
Limited Write 還需要三道控制
Parameter Constraint
discount <= 0 external_recipient = false
Idempotency
同一個 Action 重跑時不能寫兩次。
Read-back Verification
執行後重新讀一次正式系統。
例如：
update_crm() ↓ API says success ↓ get_crm() ↓ 確認欄位真的正確 ↓ PASS
這也是工作流架構中 Output 與 Outcome 的差異。
第 7 步：建立 Monitoring、Revocation 與定期重新授權
權限不是升級一次後永久有效。
至少要持續追：
- Agent 執行多少 Action；
- Approval rate；
- Reject rate；
- Exception rate；
- Retry rate；
- 越權嘗試；
- Tool errors；
- 人工 override；
- Read-back failure；
- 每件成本。
另外要能隨時：
停新任務 取消 Pending Action 撤回 Tool 撤回 OAuth 停 Schedule 撤銷 Agent Access
更深入的 Decision Right、Revocation、Kill Switch 與 Delegation Level，可以另外閱讀 AI Agent 決策主權怎麼保留？
Approval 不是越多越安全
如果每一筆都要：
讀 Email → Confirm 查 CRM → Confirm 查訂單 → Confirm 產生 Draft → Confirm
使用者最後很可能只會一直按批准。
所以低風險操作應預先建立清楚 Mandate。
例如：
可以： 讀指定客服信箱 查目前案件的 CRM 讀核准 FAQ 需要批准： 寄 Email 修改 CRM 禁止： 退款 刪除 改價
把人留在真正需要判斷的位置。
Office Agent 四個實際案例
Read Email → Auto Create Draft → Auto Send External Email → Approval
Calendar
Read Availability → Auto Suggest Time → Auto Create Internal Draft → Auto / Conditional Invite External Person → Approval
CRM
Read Customer → Auto Recommend Stage → Draft Write Internal Note → Limited Write Change Price / Credit → Forbidden / High-risk Gate
Excel／週報
Read Sheet → Auto Analyze → Auto Create Report → Draft Overwrite Source Data → Approval / Forbidden
這種 Action-level Matrix 比「這個 Agent 可以用 Excel」更容易管理。
Approval 後還要能 Pause／Resume
企業工作不一定會在 30 秒內獲得批准。
可能：
Agent 14:00 提出請求 ↓ 主管 17:30 批准
或者：
今天提出 ↓ 明天才回覆
這意味著 workflow 必須能保存狀態。
OpenAI Agents SDK 目前可以將暫停的 run 轉成可序列化的 RunState，批准／拒絕後再從原本 top-level run 繼續；Microsoft Agent Framework 也把 HITL 做成 workflow request／response 並搭配 checkpoint。
Approval 是 workflow state transition，不只是 UI event。
哪些 Approval 設計容易出錯？
1. Action 已執行才問批准
順序顛倒。
2. 人批准 A，最後執行 B
批准後參數變更就應重新批准。
3. 一次批准永久開放整個 Tool
「這次允許寄信」不能自動變成「從此所有 Email 都可自動寄出」。
4. Approval 沒有期限
昨天批准的價格、收件人或資料，今天可能已經改變。
5. 拒絕後 Agent 自己換另一條路完成同一副作用
Reject 應有明確 fallback。
6. Shadow Mode 實際仍呼叫 Production Write Tool
Shadow 必須在執行層阻止副作用，而不能只在 Prompt 寫「請不要修改」。
什麼情況可以從 Approval-required 再往前？
至少要有：
- 真實案例反覆使用；
- Action 範圍穩定；
- Failure mode 已知；
- Parameter constraint 可強制；
- Retry 不會重複副作用；
- Read-back 可以驗證結果；
- Override／Revocation 可用；
- Owner 清楚；
- Logs 能追查。
這時才考慮 Limited Action，仍不等於全面 Autonomous。
辦公室 Agent 的建議演進路徑
Shadow ↓ Read-only ↓ Draft-only ↓ Approval-required ↓ Limited Write ↓ 低風險自動 Action
這裡要注意：Shadow 是測試模式；Read／Draft／Write 才是權限。
所以實際上更像：
Shadow + Read Shadow + Draft ↓ Live + Draft ↓ Live + Write + Approval ↓ Live + Limited Write
這樣描述會比單一路徑更準確。
常見問題
Shadow Mode 和 Read-only 一樣嗎？
不一樣。Shadow Mode 表示 Agent 的結果不影響正式流程；Read-only 表示 Agent 沒有修改資料的權限。一個 Shadow Agent 仍可能具有 Draft capability，但正式 Action 應被阻止。
有 Human Approval 就安全了嗎？
不一定。批准前仍需要 schema validation、permission check、parameter constraints、data validation 與 risk policy。人工 Gate 不應成為所有安全檢查的替代品。
Agent 什麼時候可以直接寄 Email？
低風險、範圍固定、已經有足夠真實使用證據，而且收件人、內容類型與失敗處理都有強制限制時，才值得評估。正式報價、法律承諾、客訴與敏感內容仍應保留人工。
Approval 可以隔天再按嗎？
可以，但 workflow 必須保存等待狀態；批准本身也應有有效期限，若資料或 action parameters 已變更，就應重新批准。
MCP Tool 可以要求人工批准嗎？
可以。OpenAI Agents SDK 目前的 local 與 hosted MCP integrations 都支援 tool approval 設定。
要怎麼避免員工一直無腦按批准？
把低風險操作預先限制在明確 scope，自動完成；只把風險真正升高的 Action 放進 approval queue。Decision Right 與 Approval Fatigue 的深入問題，可以另外閱讀「AI Agent 決策主權怎麼保留？」。
下一步
如果還沒找到候選流程：
如果已經準備跑完整 PoC：
如果正在設計完整 Agent 系統：
AI Agent 工作流怎麼設計？7 層架構與驗收 Gate
如果已有具體工作，但不知道該開多少權限：
主要參考
- OpenAI Workspace Agents：企業 Agent 的 RBAC、app action controls、approval checkpoints 與 audit logs。
- OpenAI Agents SDK Human-in-the-loop：特定 Tool Call 暫停、批准／拒絕、RunState 與 MCP tool approval。
- Microsoft Agent Framework Human-in-the-loop：workflow request／response、等待外部批准與 checkpoint。
分享此文：
KEEP READING
接著讀什麼？
從同一主題繼續閱讀，或回到 YOLO LAB 的完整文章索引，找到下一個值得投入時間的問題。
發表迴響