你是不是 Agent 的瓶頸？每月做一次人力依賴稽核

發生了什麼

@mihai673 回頭看自己 30 天的對話，「下一步呢？」問了 60 次，其中 32 次下一句就是「做吧」¹。待處理的決定一早就堆成長長一串¹；Agent 越加越多，光是管理它們就快占掉一整個工作天³。Agent 卡在登入頁等驗證碼，等不到就自己暫停了流程⁴。這幾個案例指向同一件事：瓶頸已經不是 Agent 夠不夠聰明，而是人的注意力²；程式碼寫得再快，後面還在等需求釐清和審查，整體也快不起來⁵。

Hugging Face 等單位的論文把這叫「核准疲勞」，Agent 自主程度越高，人越容易隨手核准、過度依賴，判斷能力也會退化⁶⁷。@anishmoonka 整理的案例裡，Claude Code 在一次工作階段向同一位開發者要了 47 次權限，他每次都沒讀就按了同意⁸。

常見做法

1. 每月請 Agent 盤點一次。 一段「人力依賴稽核」Prompt¹⁶ 請 Agent 回顧過去一個月，列出你一再核准、一再補資料、手動轉交的地方。兩次實際跑過的結果，都挖出十多項可改的地方，大部分也真的改了¹⁷¹⁸。

2. 依風險分級核准。 共同原則是：可撤回、影響小的放手，碰錢、寄信、刪除、對外發布的留給人¹³¹⁵。一次類似的稽核發現，大半瓶頸是一再核准早就核准過五次的事；改成常態授權後，解決的比任何 Prompt 都多¹⁹。PR 多到審不完時，可以讓 Agent 在檢查通過後依幾個風險面向替每個 PR 打分，低風險的自動核准，其餘通知人處理；最後按下合併的仍是人²³。

3. 先限制能力，再減少核准。 沙箱、限縮權限、開發和正式環境分開，能讓很多動作根本不用問人。但沙箱擋得住誤刪檔案，擋不住 Agent 拿著合法權限對正式資料庫做錯事，那種動作還是要逐次核准¹²。

4. 讓另一個 Agent 先審。 OpenAI 推出由第二個 Agent 審查動作的 Auto-review。@thsottiaux 貼出的圖表裡，10,000 個動作有 9,280 個留在沙箱內⁹¹⁰。

5. 只回報例外。 一封沒人看的續約通知導致退款，之後改成到期前提早提醒、平常只回報例外²¹。碰錢的流程，第一步可以只做「讀取、標記、準備好給人核准」²⁴。

共識

核准按鈕本身不是控制。人來不及看懂、也撤不回來，按鈕只是裝飾¹³。
核准請求要寫清楚改了什麼、檢查了什麼、哪些沒辦法確認，不然就是蓋橡皮圖章²²。
常態授權要有期限，可以撤銷，也要留紀錄²⁰。

分歧

人該不該留在迴圈裡？ 逐步核准本身就是瓶頸，違背用 Agent 的目的¹⁴；但拿自駕車來比，平常都自動、關鍵時刻突然叫人接手，人反而接不住¹⁴。
自動審查算不算監督？ 它減少的是低風險的打擾¹⁰；可是同一個模型、同一份脈絡審自己，不算獨立檢查¹³。
問題出在核准太多，還是工作切太細？ 這麼多次核准也可以看成不是介面問題，而是工作切得太細：先規劃整件事、一次問完，就不會疲勞⁸³⁰。
要不要逐項授權？ 另一種做法是把授權放在 Agent 外面，由獨立的政策層判斷，不靠 Prompt 約束¹¹。

該怎麼做

每月固定一天跑下方的稽核 Prompt。Agent 記不得過去的工作，就把上個月的對話紀錄或待辦清單一起貼上。
只處理前 5 項，一次改一條，觀察兩週再改下一條。
先動「每次都給同樣答案」的核准，改成有期限的常態授權。
付款、寄信、刪除、公開發布一律留給自己。
下個月先檢查上次開的授權該不該收回，再跑新的稽核。

通用 Prompt

貼給任何能讀到你過去工作紀錄的 Agent 都能用：

人力依賴稽核 · 25 行

人力依賴稽核
請回顧我們過去〔30〕天的合作。資料來源：〔你記得的工作／我附上的對話紀錄或工作清單〕。
只根據實際有的紀錄，記不清楚的地方直接說，不要猜。

找出所有停下來、變慢，或回來等我才能繼續的地方，特別是：
1. 不用我開口你也能開始的工作
2. 你一再等我做的決定
3. 你一再向我要、其實可以存起來的資訊
4. 我每次都給同樣答案的核准
5. 我手動在不同工具或 Agent 之間轉交的工作
6. 可以改成定時或自動觸發的重複檢查
7. 我手動分送、其實你可以直接送達的產出
8. 我每件都看、其實只看例外就夠的工作

每一項請寫：
- 分類：留給我判斷／需要教你／需要存成固定資料／可以自動化／只回報例外
- 根據：舉出具體的工作或紀錄
- 等待：大約停下來等我多久、多常發生（有紀錄才寫，不要估）
- 建議改法：如果要給你常態授權，寫出範圍、期限，以及〔30〕天後要回顧
- 風險：改了之後可能出什麼錯、能不能撤回

規則：
- 先不要改任何東西。從影響最大的開始列，之後我們一條一條談。
- 付款、寄信、刪除、以我的名義公開發布，一律歸在「留給我判斷」。
- 之後向我要核准時，請寫出：要做什麼、改了什麼、你檢查了什麼、哪些沒辦法確認。

〔〕內換成你的情況

參考 @Michael_Fenech_ 的做法整理

不同工具的差別

記憶：會跨對話記住工作的 Agent（例如 Grok Bot 的記憶存偏好、角色背景和摘要，每個 Bot 分開²⁷）可以直接回顧；不會記的工具，要自己附上紀錄。
核准機制：Claude Code 的子代理可以設定權限模式²⁵；Grok Bot 用自己的信箱寄信時，每封都要核准，排程或其他 Bot 發出的核准請求過不久就會失效²⁶²⁸；OpenAI 的 Auto-review 由第二個 Agent 先審⁹。改成常態授權前，先看你的工具能把授權設多細。
排程：能定時執行的工具（例如 Grok Bot 的 Routines，每次執行都會消耗用量²⁹）可以把稽核排成每月一次；不能排程的，就在行事曆放提醒，手動貼上 Prompt。

參考來源

@mihai673：60 次「下一步呢？」、32 次直接說好、41 個待決事項 ↩ a b
@StanleyWei4748：瓶頸是人的注意力 ↩
Jason M. Lemkin（LinkedIn）：3 個 Agent 到 22 個，每天管理時間變 8 小時 ↩
Ashish Gupta（LinkedIn）：Agent 等不到驗證碼就暫停 ↩
Kelly Waters（LinkedIn）：產出變快，等待沒變少 ↩
@rohanpaul_ai：論文〈AI Agents Push Humans Out of the Loop〉摘要 ↩
@mmitchell_ai：論文作者整理的六種監督策略 ↩
@anishmoonka：一次工作階段 47 次「允許」 ↩ a b
@thsottiaux：Auto-review 免費開放，10,000 個動作的分布圖 ↩ a b
@aakashgupta：由 guardian 子代理審查指令 ↩ a b
r/AI_Agents：授權放在 Agent 和流程程式碼之外 ↩
@vicky_grok：沙箱與憑證隔離；留言指出合法權限的風險 ↩
Junaid Ahmed（LinkedIn）：五類該留人的工作；同模型互審不算獨立 ↩ a b c
Adrian Sanabria（LinkedIn）：質疑人在迴圈裡是瓶頸；留言的自駕車比喻 ↩ a b
mindforge.iq（TikTok）：低風險可撤回多自動，高影響留人 ↩
@Michael_Fenech_：人力依賴稽核原始 Prompt ↩
@Kevin_Logan：找到 15 項、套用 13 項 ↩
@DisruptConcept：找到 15 項、做了 12 項，改成每 30 天跑 ↩
@OpsDaddyAI：重複核准改成常態授權 ↩
@YoKoSuKa929：常態授權要設期限、可撤銷 ↩
@DanielMed_2：漏看續約通知後改成只回報例外 ↩
@brandononchain：核准請求要附檢查內容 ↩
How I AI（YouTube）：依風險替 PR 打分，低風險自動核准（11:36 起講流程，15:47 起講六項風險評分） ↩
r/AI_Agents：碰錢的流程先讀取、標記、等人核准 ↩
Claude Code 官方文件：Subagents ↩
Grok Bot 官方說明：FAQs ↩
Grok Bot 官方文件 ↩
Grok Bot 官方說明：Agent email ↩
Grok Bot 官方說明：Routines ↩
@madebyoliver 回覆：47 次核准是工作切得太細的問題 ↩