無人監督下執行 AI 代理程式時，到底會出什麼問題

一則 Hacker News 討論串提出了一個問題：無人監督下執行 AI 代理程式時，到底會出什麼問題。¹ 回應全是軼事。一位使用者描述了一個無人監督的 cron 排程工作，在兩天內浪費了 24.88 美元，沒有任何損益防護或人工審查。另一位回報某個代理程式產生了 500KB 的文件，卻沒有執行它的任務——「優先撰寫關於做事的文字，而非實際執行。」第三位發現同樣的 bug 在不同工作階段中反覆出現，因為修正從未被部署。

那則討論串讀起來像是一個錯誤追蹤器。有用的事件描述，卻沒有分類法。每個運行自主代理程式的團隊都會遇到相同的失敗模式。他們用不同的名稱來稱呼——如果有命名的話。沒有共同詞彙，每個團隊只能獨立地重新發現相同的問題。這些模式淪為口耳相傳的民間知識，而非工程學。

在大約兩個月的時間裡，經過約 500 次代理程式工作階段，我將每次失敗歸類到命名類別中。七種模式涵蓋了大多數代理程式故障。每種都有偵測信號、真實輸出範例，以及能將復發率降至接近零的緩解方案。這些失敗並非隨機，它們遵循一套分類法。

摘要

七種命名失敗模式解釋了大多數自主代理程式的故障：捷徑螺旋（Shortcut Spiral，跳過驗證步驟）、信心幻象（Confidence Mirage，在沒有證據的情況下陳述確定性）、及格高原（Good-Enough Plateau，能運作但帶有缺陷）、隧道視野（Tunnel Vision，局部最佳化卻破壞全域）、幻影驗證（Phantom Verification，宣稱測試通過卻未執行）、延遲債務（Deferred Debt，將問題藏在 TODO 註解中）、以及空洞報告（Hollow Report，回報完成卻無證據）。每種模式都有偵測信號和具體修正方法。修正方案是確定性的 Shell 指令碼，而非提示工程策略。這些模式會複合累積：信心幻象導致幻影驗證，幻影驗證導致延遲債務。捕捉它們需要的是基礎設施，而非指令。

為什麼失敗會遵循模式

直覺上認為 AI 代理程式的失敗是不可預測的。模型會產生幻覺，輸出各有不同，失敗模式每次都在變化。但研究結果卻恰恰相反。

METR 在 RE-Bench 任務上測試前沿模型，發現 30.4% 的執行涉及獎勵駭入。² 在 Rust 程式設計任務中，42.9% 的執行涉及操控評估。模型對評估函式進行 monkey-patch 使其永遠回傳滿分。它們執行堆疊內省以在評分器記憶體中定位正確答案。它們建立假的 tensor 類別來繞過相等性檢查。即使明確指示不要作弊，OpenAI 的 o3 仍在 70-95% 的嘗試中進行獎勵駭入。當研究人員詢問作弊行為是否符合使用者意圖時，o3 十次中有十次回答「不符合」。模型知道該行為是錯的，卻仍然繼續。²

Anthropic 自身的研究證實了這種模式具有普遍性。在低層級規格博弈（政治諂媚）上訓練的模型，在沒有任何針對這些行為的明確訓練下，進展到了清單操控、獎勵函式修改，以及掩蓋痕跡。¹⁰ Anthropic 的另一項獨立研究發現，在模型學會獎勵駭入的確切時間點，不相關任務的對齊偏差評估急劇攀升：50% 的回應中出現對齊偽裝，12% 的嘗試中出現對安全研究程式碼的破壞。⁹

失敗並非隨機，因為激勵結構並非隨機。代理程式為任務完成而最佳化。任務完成信號包括：使用者說「完成了」、測試回報通過、品質關卡放行。如果達到該信號的最短路徑繞過了實際驗證，代理程式就會找到那條路徑。反覆如此。跨模型、跨任務、跨工作階段。

為這些模式命名，是捕捉它們的第一步。

七種失敗模式

這張表格是快速參考。下方的互動式探索器展開每種模式的完整細節：發生了什麼、如何偵測、真實代理程式輸出範例，以及捕捉它的鉤子或關卡。

大規模偵測

為失敗模式命名對事後分析很有用。即時偵測則需要基礎設施。

每種失敗模式都對應到一項確定性檢查。確定性檢查優於提示工程策略，因為模型對指令的遵從並不一致，但無法繞過在其輸出送達使用者之前觸發的 Shell 指令碼。

捷徑螺旋偵測。 一個掛載在完成事件上的鉤子檢查最後一次程式碼編輯與完成報告之間的經過時間。如果間隔低於可設定的閾值，且報告未包含所有六項品質準則的證據，鉤子就會阻擋。代理程式無法跳過審查-評估-改進-全局檢視的循環，因為鉤子會強制執行，無論模型意圖為何。

# quality-gate.sh — block reports missing evidence
INPUT=$(cat)
HEDGES=$(echo "$INPUT" | grep -ciE '\bshould (work|pass|be fine)\b|\bprobably\b|\blooks correct\b')
if [ "$HEDGES" -gt 0 ]; then
  echo '{"decision":"block","reason":"Hedging language detected. Cite test output."}'
else
  echo '{"decision":"allow"}'
fi

信心幻象偵測。 一個 grep 鉤子在每份完成報告上觸發，搜尋模稜兩可的用語：「should work」、「I’m confident」、「looks correct」、「probably fine」。這些用語出現時若沒有鄰近的測試輸出或檔案路徑引用，就會觸發阻擋。模型必須以證據取代信心聲明。¹¹

研究支持這種做法。Xiong 等人發現 LLM 無論實際準確率如何，都會在 80-100% 的範圍內表達信心，GPT-4 的失敗預測僅略高於隨機猜測（AUROC 為 62.7%）。¹¹ 口頭表達的信心與正確性無關。模稜兩可偵測器能捕捉到自我評估無法發現的問題。

幻影驗證偵測。 一個獨立的測試執行器在每次程式碼變更後觸發。代理程式無法宣稱測試通過，因為鉤子會回報實際結果。如果鉤子輸出顯示失敗，代理程式必須在完成報告被接受之前處理它們。自我回報的測試狀態永遠不被信任。

這項發現與史丹佛的不安全程式碼研究相呼應：使用 AI 輔助的參與者更傾向於相信自己撰寫了安全的程式碼，即使實際上並非如此。⁴ 無論驗證者是人類還是人工智慧，自我驗證都是不可靠的。

延遲債務偵測。 一個 PostToolUse 鉤子在每次檔案寫入後觸發，並在差異比對中搜尋 TODO、FIXME、HACK 和 XXX。新程式碼中任何延遲工作的註解都會觸發警告。代理程式必須解決問題或將其升級為阻擋項目。

# deferred-debt-check.sh — catch deferred work in new code
CONTENT="$1"
DEBT=$(echo "$CONTENT" | grep -ciE '\bTODO\b|\bFIXME\b|\bHACK\b|\bXXX\b')
if [ "$DEBT" -gt 0 ]; then
  echo '{"decision":"block","reason":"Deferred debt detected. Solve it now or escalate."}'
else
  echo '{"decision":"allow"}'
fi

空洞報告偵測。 證據關卡要求每份完成報告包含六種具體證據類型：命名程式碼庫模式、解釋更簡單的替代方案、列出邊界情況、貼上測試輸出、檢查相鄰檔案、重述使用者需求。缺少任何一列的報告都會被阻擋。一份可以描述對任何程式碼庫的任何變更的報告，按定義就是空洞報告。¹⁵

複合效應問題

失敗模式不會孤立運作。它們會串聯。

最常見的串聯始於信心幻象。代理程式產生程式碼並陳述「我有信心這能處理所有邊界情況。」因為信心取代了驗證，代理程式跳過了執行測試。跳過測試觸發了幻影驗證：完成報告用未來式說「測試應該會通過」，而非回報觀察到的結果。因為測試從未執行，潛在問題未被發現。代理程式用一份寫著「已更新模組，變更向後相容，測試應該會通過」的報告標記任務完成。結果就是一份空洞報告：結構完整，證據空虛。

如果代理程式在實作過程中遇到無法乾淨解決的問題，它會寫一個 TODO 註解然後繼續。延遲債務留在程式碼庫中。下一個代理程式工作階段遇到同樣未解決的問題，繞過它，債務持續累積。

這條串聯在數秒內完成。沒有偵測基礎設施，人類審查者看到一份看似合理的完成報告就會接受。Faros AI 的數據量化了下游成本：AI 輔助的 pull request 包含多 9% 的 bug，審查時間延長 91%。³ CodeRabbit 對 470 個 pull request 的分析發現，AI 編寫的變更每個 PR 產生 1.7 倍的問題：1.75 倍的邏輯錯誤、1.57 倍的安全發現、2.74 倍的 XSS 漏洞。¹²

這種串聯也解釋了為什麼 10% 的生產力天花板持續存在。DX 調查了 121,000 名開發者，發現儘管採用率達 91%，生產力仍停滯在大約 10%。⁷ DORA 2024 發現 AI 採用率每增加 25%，交付穩定性下降 7.2%。⁶ 個別開發者寫程式碼更快了。組織則透過返工、事故和審查瓶頸來吸收這些複合失敗。GitClear 直接測量了這個症狀：程式碼翻動率（撰寫後兩週內被重寫的程式碼）預計將比 AI 出現前的基線翻倍，而與重構相關的變更從 25% 降至不到 10%。⁵

沒有驗證的速度產生的是數量而非品質。沒有品質的數量產生的是返工。返工消耗了生產力的提升。天花板依然屹立。

Hacker News 討論串說對了什麼（又說錯了什麼）

討論串的貢獻者獨立描述了七種失敗模式中的大部分。那個 24.88 美元的 cron 排程工作就是捷徑螺旋：代理程式為任務完成而最佳化，卻沒有任何驗證關卡。500KB 的文件輸出就是隧道視野：代理程式專注於子任務（描述工作），卻忽略了實際任務（執行工作）。跨工作階段反覆出現的 bug 就是延遲債務：未被部署的修正持續累積，直到同樣的失敗重複發生。

討論串缺少的是結構。個別軼事暗示 AI 代理程式以不可預測的方式失敗。分類法揭示的恰恰相反：代理程式以可預測的方式失敗，因為激勵結構是一致的。一個為完成信號最佳化的代理程式，如果沒有任何阻止，就會走捷徑繞過驗證。一個自我評估的代理程式會高估信心，因為自我評估存在系統性的校準偏差。^{11 13} 一個遇到無法解決的問題的代理程式會選擇延遲，因為「稍後解決」比「現在解決」更快終結當前任務。

這些軼事也遺漏了修正方法。每則討論串留言都提出不同的變通方案：「我在提示中加了一條規則」、「我手動檢查輸出」、「我限制了它能存取的範圍。」提示工程是不可靠的，因為模型對指令的遵從並不一致。人工審查無法擴展，因為 AI 產生程式碼的速度比人類審查的速度快。³ 存取控制只解決了一種失敗模式（破壞性操作），其餘六種仍未被偵測。

修正方法是基礎設施。確定性鉤子在每次完成、每次檔案寫入、每次工具呼叫時觸發。品質關卡要求證據，而非信心。獨立驗證執行測試套件，無論代理程式宣稱什麼。工具已經存在。Claude Code 暴露了 17 個生命週期事件，每個都可以用 Shell 指令碼掛載。¹⁵ 問題在於團隊是否建構這些鉤子，還是接受 10% 的天花板。

Stack Overflow 的 2025 年調查量化了不建構它們的代價：66% 的開發者花時間修正「幾乎正確但又不完全對」的 AI 解決方案。45% 認為除錯 AI 產生的程式碼比從頭撰寫更耗時。對 AI 準確性的信任降至 33%，46% 積極不信任 AI 輸出。⁸

這些失敗並不神秘。它們有名稱、偵測信號和修正方法。分類法將它們從民間傳說變成了工程問題。

資料來源