ParanoiaEval：當 Agent 把已解除的風險再處理一次

一個 coding agent 已經找到正確修法，測試也通過了，卻仍加上第二層備份、擴大驗證範圍，或要求使用者重做已完成的決定。這些動作看起來謹慎，卻可能把風險已被 repo 證據解除後的工作又做一遍，讓原本可用的改動變得更難審查、更慢採用。

2026 年 10 月 6 日公開的 ParanoiaEval 論文將這類行為整理成可測的 coding-agent 能力：Agent 能否依據手邊證據，選擇適量的風險處置？作者報告，在 9,600 次受控執行中，不必要的風險處置率因 agent 設定而異，落在 11.2% 到 58.7%；在 20 位開發者參與的事後研究裡，含多餘處置的完成任務滿意度低 1.27 分（五分制），直接接受率為 38%，沒有多餘處置時則為 78%。這些是作者在 benchmark 與有限研究設計下的觀察，不代表正式團隊裡的發生率，也沒有證明長期維護成本增加多少。

「更多檢查」不等於「更安全」

測試通過通常回答的是：這次任務的預期功能是否完成？它不會自動回答 Agent 為了完成任務是否做了不必要的工作。ParanoiaEval 的一個核心觀察是，作者評估中 92.7% 含多餘處置的 E+ 執行仍通過功能 oracle。只看完成率，這些額外動作很容易被算進「成功」裡。

這種失靈不一定是明顯的錯誤程式碼。它可能是為已固定版本的依賴再加一層 fallback、重跑任務已明確不需要的整套檢查，或在使用者已指定最終狀態後仍重問確認。風險本身可能合理，但證據已經說明該由其他機制處理、該風險不存在、處置幅度已有上限，或負責人已接受剩餘風險。Agent 繼續處理時，重點不是它「看起來很小心」，而是它有沒有超過證據所支持的範圍。

這和「永遠少做」也不同。風險仍存在、沒有明確責任方或尚未滿足使用者目標時，更多驗證可能完全必要。工程判斷要比較的是風險證據、負責邊界與處置幅度，不是把保守或精簡當成單一正確答案。

ParanoiaEval 如何把「多做了」變成可比較的評測

研究以軟體風險管理常用的四種回應，整理 coding agent 的行為：Avoidance（避開已消除的風險）、Transfer（將風險交由既有負責方）、Mitigation（按指定幅度降低風險），以及 Acceptance（依決策接受剩餘風險）。作者從 18,922 段去識別化的 agent 使用紀錄中，整理出 44 種情境，再將其實作到 50 個 Python 或 Go 開源 repository。

基準包含 200 組 repository 任務配對。每一組的兩個版本只改動一項與風險處置有關的事實，其餘任務目標、程式庫版本、環境及 oracle 維持相同。例如，一個版本的指令明確標示這是最後一版，另一個則沒有這項事實。如此一來，研究者可以比較 Agent 是否因為看見「已是最後版本」這項證據而停止再做備份或重新確認。兩位專家逐組檢查配對證據和任務是否成立。

作者在 Claude Code 和 Codex 各自的原生 harness 內測試 8 個模型設定，每個條件跑三次，總計 9,600 次。作者使用只讀的 agentic judge 檢視可觀察的執行記錄，並分別報告任務成功率、E+ 條件下的不必要處置率（violation rate），以及 E+ 相較 E− 能減少多少多餘處置（evidence responsiveness）。論文在 200 筆保留的人工作業標籤上報告 judge 準確率 0.965、Cohen’s κ 為 0.93；這是作者的校準結果，不能代替外部驗證。

這種成對設計有個有用的特性：它不會只因某個模型「一向不做額外檢查」就判斷它很會依證據調整。研究也看 Agent 在沒有關鍵證據時如何行動，再對照有證據時是否改變。這讓 benchmark 可以區分「一律少處置」與「會根據情境調整」兩種能力。

數字說明了什麼，又沒有說明什麼

作者報告，各模型設定在證據已明確界定處置方式的 E+ 條件中，仍有 11.2%–58.7% 的執行出現多餘處置。不同模型與 harness 組合的差距很大；同時，任務成功率高也沒有保證較低的 violation rate。這支持一個較窄、但重要的結論：任務完成與風險處置判斷是兩個需要分開觀察的指標。

20 位有經驗的開發者參與了事後評估。作者從已通過任務 oracle 的執行紀錄中分層抽出 800 筆，讓每位參與者評估 80 筆；每筆有兩人評分，且隱去模型身分、judge 標籤與配對條件。研究將滿意度錨定在程式碼可維護性、執行時間及需要修改的程度。含過度處置的紀錄平均滿意度 2.58，沒有過度處置的紀錄為 3.85，差距 1.27 分（p < .001）；直接接受率則是 38% 對 78%。

這代表在這批盲評的完成任務裡，多做處置和較低的採用意願同時出現。它沒有追蹤團隊幾週或幾個月後是否真的回退程式碼，也沒有換算成本或交付延遲；因此不應把差距改寫成「多餘檢查已被證明造成長期維護損失」。同樣地，11.2%–58.7% 是研究中的模型設定和任務組合結果，不是所有 coding agent 或公司 repo 的盛行率。

實驗將 Claude 系列放在 Claude Code、GPT 系列放在 Codex，各模型各自執行於原生工具與控制流程中。作者沒有讓相同模型跨兩種 harness 對照，因此不能從跨 harness 的差異抽出「模型本身」排名。論文的結果更適合用來檢查行為類型與評測盲點，而不是直接挑選某個模型上線。

把四種風險回應用成團隊檢查表

這套分類可以轉成 review 中一組很實際的提問。以下是依論文概念整理的工程做法，不是論文證明有效的干預措施：

1. 避開（Avoidance）：風險來源是否已不存在？例如依賴版本已釘選、呼叫已序列化，Agent 是否仍加上原本用來防止該風險的 fallback？
2. 轉交（Transfer）：是否已有 CI、release script、維護者或其他服務負責處理？Agent 是否又執行一遍相同的驗證或備份？
3. 緩解（Mitigation）：使用者是否給了測試次數、範圍或報告長度上限？額外驗證是否超過明確界線？
4. 接受（Acceptance）：負責人是否已決定接受某項剩餘風險或指定最終狀態？Agent 是否仍要求確認、擴大處置或重開決策？

在 review 中，可以把每一項防護改動都連回一段具體證據：風險是什麼、誰負責、現有措施為何不足、這次增加的操作能降低什麼風險。如果找不到清楚的連結，不表示改動一定錯，但代表它需要更好的理由，也可能只是對已處理風險重複投入。這種提問能讓 code review 同時檢查功能與變更範圍。

若要把它納入團隊評測，建議將任務完成與處置合理性分開計分，另外記錄多餘修改、額外工具操作、使用者重新確認、審查所需時間等可觀察訊號。建立案例時可成對控制關鍵證據，並請人審查哪些動作屬於最低充分工作。不要直接把 paper 的 11.2%–58.7% 當作內部基線；團隊的 repo、工具、權限與風險政策都不同。Agent 執行軌跡、工具權限和上線前的評測架構，可接著參考 AI Agent 完整指南；對照同一主題中「工具動作是否偏離授權」的評測角度，也可讀政府網站探測研究的 Agent 行為邊界與可執行安全 Probe 如何驗證主張。

證據邊界與如何閱讀 artifact

ParanoiaEval 的證據由受控 benchmark、作者設計的 judge 與小型事後人評組成。優點是任務配對能把單一事實的影響隔離出來；限制則是現實線索不一定如此集中，judge 即使經人類標註校準仍可能出錯，而且參與者來自單一區域的開發者族群，不能直接推廣到不同團隊文化與工作環境。研究也覆蓋 44 種情境、50 個開源 Python／Go repository，不能代表所有語言、封閉商用程式庫或高風險維運工作。

公開 repository 含有 200 組任務、runner、judge 與建置腳本，可用來檢查 benchmark 結構和自行設定執行環境。但作者表示結果資料與完整 trajectory 並未隨公開 repo 提供：trajectory 體積太大且需要資訊審查，作者表示會另行處理。因此目前無法只靠該 repo 完整重算論文的 9,600 次結果；我們也沒有找到獨立重跑。讀者可檢查任務和執行方法，但應把主要數字維持為「論文作者報告」。

如果要採用這個思路，下一步不是立刻設一條「禁止多做」規則，而是挑出團隊最常見的重複處置，明確記錄什麼證據足以停止；再用配對案例確認 Agent 會因證據變化而調整，而非一概省略安全步驟。ParanoiaEval 提供了一個開始拆解問題的框架，也留下了真實工作中如何處理模糊證據的研究空間。

來源

• Luo 等人，ParanoiaEval: Benchmarking Unnecessary Defensive Work in Agentic Coding — 論文、任務方法、實驗、事後人評與限制。
• 論文 HTML 全文與附錄 — judge 校準、研究抽樣和限制細節。
• ParanoiaEval_release — 公開任務、runner、judge；README 說明未含結果或完整 trajectory。