AI agent 需要的不是確認按鈕，是看得懂的批准邊界
最容易讓人放鬆的，往往是一個看起來很正常的確認按鈕。
Agent 跳出提示，問你要不要修改某個檔案。路徑看起來在專案裡，檔名也合理。你手上還有別的事，心裡大概只想趕快繼續往下跑，於是按下 Accept。
這一刻很像 human-in-the-loop。
但我越來越覺得，這個詞太容易被講得太便宜。有一個人按過確認，不代表那個人真的理解自己批准了什麼。尤其當 agent 可以改本機檔案、跑命令、讀 repo、開瀏覽器，甚至同時處理幾個長任務時，確認按鈕本身不夠。
真正重要的不是「有沒有確認」。
真正重要的是：人按下去之前，看不看得懂那個行動的真實邊界。
## 有確認，不等於有授權
這件事在 coding agent 上特別明顯。
傳統的自動補全大多只是建議幾行 code。它煩的時候會打斷你，但它通常不會自己去改一串檔案、跑一個安裝腳本，或把某個設定寫到你沒注意的位置。
Agent 不一樣。
它會把「幫我修一下」理解成一段工作流程。它可能先讀檔，再改檔，接著跑測試，看到錯誤又去查另一個檔案。這種能力很有用，也正是大家開始認真使用它的原因。
問題是，一旦工具從建議變成行動，授權介面就變成工作流的一部分。
假設畫面上顯示的是 `./config/settings.json`，但實際寫入的是 symlink 指向的另一個位置。假設 agent 在你按 Accept 之前就已經把內容寫進去了，按 Reject 只是幫你 undo。假設它要跑的 command 看起來像一般 setup，實際上會碰網路、讀環境變數、改 shell 設定。
這些情況裡，確認按鈕還在。
可是它已經不像授權，比較像一個讓人安心的儀式。
我不是說確認提示沒有用。相反，它很重要。只是它不能只問「要不要」。它要先讓人知道「到底是什麼」。
## 路徑要顯示真實目標
對開發者來說，路徑很容易被當成安全感。
看起來在專案裡，就放心一點。看起來是暫存檔，就放心一點。看起來不是 `.ssh`、不是 secret、不是全域設定，就放心一點。
但 agent approval 的第一個基本要求，應該是顯示 resolved path，而不是只顯示一個漂亮的相對路徑。
如果檔案經過 symlink、alias、workspace mount，或任何會讓人誤判範圍的轉接，批准畫面應該直接講清楚：你看到的路徑是什麼，實際目標在哪裡，是否離開目前 repo，是否碰到使用者家目錄或敏感位置。
這聽起來很細。
但安全感本來就常常死在這種細節裡。人類 review 時會看 diff，會看檔名，會看目錄。工具如果在這一層給人一個不完整的表示，後面再多問一次「確定嗎」也補不回來。
小團隊其實可以先用很樸素的規則處理。
陌生 repo 裡，agent 只能先讀不能寫。
跨出 workspace 的檔案修改，一律停下來人工確認。
所有 symlink resolved target 要顯示出來。
修改全域設定、憑證、shell profile、package manager 設定時，不允許一次批准整包。
這些規則不酷，但很實際。它們讓「批准」從一個情緒性的按鈕，變成一個有資訊的邊界。
## 批准應該發生在改變之前
另一個容易被忽略的問題，是批准的時機。
如果 agent 先把檔案寫了，再跳出畫面問你要不要接受，那這不是授權流程。這比較像 undo 流程。
Undo 當然有價值。很多編輯器和工具都靠這件事讓使用者放心探索。但在 agent 工作流裡，undo 不能取代 approval。原因很簡單：有些事情不是改回檔案就結束。
跑過的 script 可能已經建立快取。
安裝步驟可能已經下載套件。
測試可能已經碰到本機服務。
命令可能已經讀過環境變數。
瀏覽器操作可能已經送出請求。
檔案 diff 可以回復，不代表副作用不存在。
所以比較好的設計不是「先做，讓使用者接受或拒絕結果」，而是把高風險動作拆開。低風險的讀取可以自動進行；要寫入、執行、連網、讀 secret、改全域狀態時，先停。停下來時，不只顯示命令本身，也要顯示預期效果和影響範圍。
這會讓 agent 看起來慢一點。
但那個慢，是工程流程需要的慢。就像 production deploy 前要看變更清單，不是因為大家喜歡儀式，而是因為某些門檻本來就應該在狀態改變前出現。
## 命令比文字更需要上下文
很多 approval UI 對檔案 diff 比較友善，對 command 卻很粗。
它可能只顯示：
```bash
npm install
```
或：
```bash
./setup.sh
```
對熟悉專案的人來說，這還勉強能判斷。對 agent 正在處理的陌生 repo 來說，這其實資訊很少。
`npm install` 會不會觸發 lifecycle script？
`setup.sh` 會不會 curl 一段東西下來執行？
測試指令會不會啟動服務、連資料庫、碰網路？
錯誤訊息看起來像 DNS 問題時，agent 會不會照著文件去查一個外部地址？
我不是要把每個 command 都妖魔化。開發工作本來就需要執行命令。只是 agent 的「helpful」會讓它比人更願意照著錯誤訊息往下試，而這正是風險開始變難看的地方。
人類工程師看到一個陌生 setup script，多少會有一點警覺。Agent 則可能把它當成完成任務的下一步。
所以命令批准畫面至少應該回答幾個問題：
- 這個 command 會在哪個目錄執行
- 它可能讀寫哪些檔案或目錄
- 它是否需要網路
- 它是否可能讀到 secret 或環境變數
- 它失敗時，agent 會不會自動嘗試替代命令
- 這一步完成後，reviewer 可以檢查什麼證據
這些資訊不一定都能自動推得很準。但推不準時，工具也應該承認不確定，而不是把不確定藏在一個乾淨的 Confirm 按鈕後面。
## 長任務會放大壞邊界
如果 agent 只做三分鐘的小修，approval boundary 不清楚已經很麻煩。
如果它開始做一小時、三小時、八小時的任務，這個問題會變成日常管理成本。
現在很多人不只開一個 agent。有些工作流會同時跑幾個 session，有些團隊會把固定指令寫成 skill，有些任務已經接近「交給它一段時間，晚點回來看結果」。
這不是未來想像。這已經是很多 builder 正在摸索的工作方式。
多 agent 和長任務的麻煩，不只是花 token，也不是只怕它寫錯 code。真正的麻煩是中間狀態太多。如果每一段都沒有清楚邊界，最後 reviewer 看到的只是一包結果：一些 diff、一串輸出、一個看似合理的摘要。
這很難 review。
比較成熟的做法，是把長任務拆成可以批准、可以停止、可以回放的小段。
先只讀 repo，整理計畫，不改檔。
接著列出會碰到的檔案、命令和風險。
批准第一個最小修改，不准順手重構。
跑指定測試，失敗兩次就停下來交代。
每一段都留下命令、diff、判斷理由和不確定點。
這樣做會讓 agent 少一點魔法感，但多很多可接手性。
我會把這當成團隊導入 agent 的成熟指標。不是 agent 能不能一路跑到底，而是它跑到任何一個中間點時，下一個人能不能看懂、接住，必要時把它停掉。
## 小團隊先寫工作規則，不要只寫 prompt
很多團隊開始共享 agent 使用方式時，會先寫 prompt 範本。
請你謹慎。
請你像資深工程師。
請你不要 overengineering。
請你先思考再行動。
這些句子不是完全沒用，但不夠。
真正有用的是工作規則。尤其是跟批准邊界有關的規則。
例如：
- 陌生 repo 預設只讀，不跑 setup
- 任何網路請求都要先說明目的
- 不讀 `.env`，除非任務明確需要且人類批准
- 不修改 shell profile、SSH key、global git config
- 不把測試失敗自行擴大成大型重構
- 每次交付都附上改檔清單、命令紀錄、測試結果和剩餘風險
- 如果 approval 畫面無法說清楚真實目標，預設拒絕
這些規則不像 prompt 技巧，卻更接近工程。
因為它們處理的不是 agent 會不會講漂亮話，而是它被允許做什麼、什麼時候要停、什麼證據可以讓人 review。
對小團隊來說，這比追最新工具更重要。工具會變，模型會變，CLI 介面會變。但團隊對權限、執行、review、回滾的基本態度，應該要比工具穩。
## 最後要問的不是有沒有按過 Accept
我不覺得 agent approval 的答案會是一套完美 UI。
有些資訊很難完整顯示。命令副作用不一定能準確預測。太多提示會讓人疲乏，最後又變成一直按確認。安全和效率之間也一定有取捨。
但這不代表我們只能接受形式上的 human-in-the-loop。
至少，團隊可以開始把問題問得更準。
不是問：這個工具有沒有 confirmation prompt？
而是問：它顯示的是不是真實目標？
不是問：有沒有人按過 Accept？
而是問：那個人是否看得懂實際被批准的行動？
不是問：agent 最後有沒有完成任務？
而是問：中間每一步是否能被停止、檢查和回放？
AI agent 進入日常開發後，批准邊界會變成一種產品介面，也會變成一種團隊流程。
如果人只是靠近按鈕，卻看不懂按鈕後面發生什麼，那不叫 human-in-the-loop。
那只是 human-near-the-button。