Agent 生成程式碼的安全債務

資料來源#

• Democratizing Agent Deployment Safety: A Structural Monitoring Approach
• From Agent Behaviour to Agent-Friendly Documentation
• Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild
• The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities
• Trust but Verify? Uncovering the Security Debt of Autonomous Coding Agents

摘要#

Sakib、Banik 與 Jadliwala（University of Texas at San Antonio，arXiv 2607.12428，2026 年 7 月）以提供本文資料的同一 AIDev 語料庫系列，首次大規模描繪代理程式撰寫的提取要求（pull request）的安全狀況；這也是知識庫中其他代理程式 PR 遙測資料的來源。分析單位是安全異味——表示風險的結構模式（例如未固定版本的 actions/checkout@main、以 root 執行的容器、硬編碼金鑰）——刻意不視為已確認可利用的弱點；要確認後者，必須逐案分析其可利用性。

最醒目的發現是安全債務的量化結果：4,022 個代理程式 PR 中有 38.9% 至少包含一項異味，而且幾乎都集中在 CI 與容器定義。論文最重要的貢獻，則是第二個研究問題：研究焦點從代理程式轉向人類和審查者，發現兩者的失誤都不符合「AI 寫出不安全程式碼」這種框架的預期。

證據說明。 本研究屬於 empirical，作者明確指出四項範圍限制；以下每個數字都必須連同這些限制理解。（1）限定的語料庫：只納入符合高風險路徑集合的檔案（CI 定義、容器、IaC、含密鑰檔案、設定檔、shell 腳本、筆記本），且只檢查新增的（+）行——這是定向掃描，不是儲存庫稽核。（2）判斷器召回率為 0.775，因此漏掉了 22.5% 的異味，每個盛行率數字都是下限。（3）沒有人工 PR 對照組——本文無法證明代理程式在這方面比人類差，只能說明代理程式輔助工作流程的安全狀況。（4）開放原始碼 GitHub、五種代理程式——不涵蓋採用專有防護措施的企業儲存庫。

RQ1：異味有哪些、出現在哪裡#

六種類別依據 OWASP 安全程式設計指引（OWASP、CIS Benchmarks 與 GitHub 強化文件）整理。各類別的分布極不均勻，規模相差可達一個數量級：

類別	異味數	比例	嚴重等級
supply_chain_integrity（可變動的動作／映像標籤、未固定版本的全域安裝）	7,160	82.3%	0
over_privilege_execution（root 容器、sudo、shell 安裝程式、範圍過廣的 CI 權限）	835	9.6%	1
secrets_identity（硬編碼金鑰、權杖、私鑰、含憑證的連線字串）	294	3.4%	252
misconfig_hardening（偵錯模式、記錄密鑰、停用加密）	163	1.9%	0
permissive_network（綁定所有介面、開放 CIDR、公用存取旗標）	153	1.8%	0
cleartext_transport（明文端點、停用 TLS、弱加密套件）	96	1.1%	0

嚴重程度大多是重大（6,292／72.3%）或輕微（2,156／24.7%）；只有 253 項異味（3.0%）屬於嚴重等級——其中252 項（99.6%）是硬編碼憑證。嚴重程度分布的尾端，幾乎就是一種以單一名稱標示的失誤模式。

集中位置。 GitHub Actions 工作流程（7,054 個檔案，36.3% 有異味）與 Dockerfiles（1,775 個檔案，36.4% 有異味）合計占全部異味的 87.6%。應用程式設定檔幾乎沒有問題，異味率只有 2.2%。根據實證，代理程式 PR 的安全債務主要是建置與部署管線問題，遠多於應用程式程式碼問題——這也解釋了為何審查時容易低估它：工作流程 YAML 看起來像制式樣板。

盛行率會隨變更規模上升。 PR 層級的標記比例隨變更行數單調增加：從 1–9 行 PR 的 16.2%，升至 1,000 行以上 PR 的 53.6%，相差 37.4 個百分點。這正是 Faros 想要、卻無法從跨客戶指標得出的依 PR 規模分層證據。

依代理程式與語言分層（圖 4，語料庫平均值 38.9%）：Copilot 45.5%、Claude Code 41.2%、Cursor 40.6%、Devin 39.7%、OpenAI Codex 34.9%——相差 10.6 個百分點。Codex 被標記的比例最低，但每個被標記檔案的異味數最多（0.62）。依儲存庫語言區分：JavaScript 55.3%、Rust 與「其他」47.5%、Go 43.8%、C# 40.2%、TypeScript 38.9%、Python 31.8%。語言之間相差 23.5 個百分點，幅度大於代理程式之間的差異，顯示生態系慣例比代理程式自身傾向更能左右結果。代理程式排序只能視為弱證據：研究沒有控制儲存庫組成、任務類型或代理程式市占率。

RQ2：顛覆常見說法的兩項發現#

294 個 secrets_identity 標記中，編碼人員能判定 272 個（22 個 PR 已不存在），並確認其中 74 個是仍有效的真實憑證，而不是佔位符或誤判。

1. 其中 67.6% 是人類提交的。 74 個真實密鑰中，有 50 個由人類協作者提交，24 個由代理程式提交。在代理程式輔助工作流程中，人類是外洩憑證的主要來源。作者提出的解釋——是一項假說，而非測量結果——是開發者警覺性降低：在代理程式看似負責正確性的工作流程中，可能因審查疲勞或認知卸載而疏忽。這是監督疲勞在安全領域的具體表現，也重新指明了緩解措施的目標：若防護措施只針對代理程式產出的內容，就會漏掉這些 PR 中三分之二的有效憑證。

2. 81.1% 在整合前沒有引來任何審查留言。 安全機器人或人工審查者只對 74 個真實憑證中的 14 個留言（18.9%）——即使這 14 個案例中出現了七種不同工具（GitHub Advanced Security、GitGuardian、Qodo、Copilot、Greptile、Gemini Code Assist、Cursor bot）。明確設計來攔截外洩憑證的那一層，面對它專門防範的唯一異味類別，留言比例不到五分之一。

看清測量對象，不要只看標題。 §2.2 將審查者偵測操作化為「自動化安全機器人是否對該密鑰留言」。摘要與結論把其補數說成審查「未能偵測」81.1% 的憑證，但 §3.2 表示，另外的 60 個密鑰沒有留言便遭移除。既然已移除，便代表有某種因素發現了它們。現有資料能支持的主張應限於：81.1% 的真實憑證在沒有審查留言的情況下進入整合；至於無聲移除究竟代表無聲偵測、無關的變更，還是後續清理，本文呈現的資料無法判定。知識庫記錄的是代理指標，沒有把它升格成更強的主張。

判斷器本身也是一項發現#

偵測流程本身也提供了 LLM-as-a-Judge 作為安全閘門的實證。兩個開放權重量化模型（Qwen3.6-35B-A3B-FP8 與 Gemma-4-26B-A4B-IT-FP8）以 0.1 溫度運作，合併採聯集方式判定（任一模型標記即算有異味），並以人工標記的 376 個檔案變更進行驗證；編碼者間 κ = 0.929：

• 整體：相對於黃金標籤，精確率 0.908、召回率 0.775、F1 0.836、κ 0.789——精確率高，但召回率意味著所有盛行率數字都是下限。
• 類別層級的落差：人工檢查發現，secrets_identity 標記中只有 27.2% 是真實憑證。這與整體精確率 0.908 並不矛盾——判斷器評分的問題是「這是不是一項異味」；把看似合理的佔位符標為異味是站得住腳的判斷，但它不代表那是有效憑證。然而，若有人要把判斷器接到阻擋式閘門，應看第二個數字：此流程發出的密鑰警示，約有四分之三並非有效憑證外洩。整體精確率不能直接套用到實際設置閘門的類別。

這項研究能確定什麼，不能確定什麼#

審查涵蓋率趨同，不代表審查有效。 CMU 的非供應商遙測資料發現，沒有人工審查的已合併代理程式 PR 比例，從 2025 年年中超過 50%，逐步朝 2026 年初約 14% 的人工基準下降——組織正學習審查代理程式程式碼。本文從另一面檢視相同的開放原始碼族群，發現實際發生的審查，有 81.1% 沒有對有效憑證留下留言。兩者可以同時成立：審查者更常出現，仍然抓不到這類問題。審查涵蓋率與審查成效是兩種不同的量，因此 wiki 對趨同現象的樂觀解讀，只應視為涵蓋率的改善。

與蓋章式審查機制相符，但並未驗證它。 這項結果是在結果層級支持 Review as the Control Point 的 P1（負荷會降低審查深度）與 P4（表面合理性會解除審查者的戒心），也符合論文引用 Haider 與 Zimmermann（arXiv 2601.19287）發現的審查焦點：對 AI 撰寫程式碼的行內留言，主要關注邏輯與功能正確性，而非安全狀況。但本文沒有隔離任何機制、控制其他構念，也沒有與人類撰寫的 PR 比較，因此只能佐證這些命題的方向，無法確認任何因果關係。

「弱點率高出 2.7 倍」這個數字，在本文中沒有獲得支持。 前言引用資料稱，AI 生成程式碼引入弱點的比率約為人類撰寫程式碼的 2.7 倍——但引文來自 Docker 公司部落格文章與 Gary Marcus 的 Substack 貼文，兩者都未經同儕審查，也無法重現；而本文自身的設計（沒有人工對照組）也無法佐證此說。應將 2.7 倍視為未獲佐證；38.9% 是獨立的比例數字，不代表比較結果。

測量的另一面：要求代理程式修補安全問題（2026-07）#

本文測量代理程式在處理其他任務時留下的異味。SecureVibeBench（Chen 等人，arXiv 2509.22097）測量相反情況：刻意要求代理程式修補安全漏洞。它以來自 41 個真實開放原始碼專案、透過 OSS-Fuzz 收集的歷史弱點，建立 105 項 C/C++ 安全程式設計任務，標出弱點引入的位置，並以功能測試、靜態與動態安全分析評估代理程式產出的修補方案。在五種廣泛使用的程式碼代理程式與五種語言模型的組合中，最強的組合只有 23.8% 的時間能產出正確且安全的解答。

此研究由 Rashidi 的執行安全 SoK 引介（The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities，arXiv 2607.05743，empirical）；該 SoK 將其歸入「代理程式生成程式碼的靜態分析」，並提出與本文相關的結論：這項結果是不要依賴生成品質作為執行安全控制措施的警訊——「依據作者自己的評估，這項研究中的代理程式在安全問題上答錯的次數多於答對。」數字歸屬：23.8% 是 Chen 等人的數字，由該回顧文章轉述；回顧文章核實的是引文身分，並未重現任何受調查論文的測量結果。

這兩個數字應並列理解，而不該合併，原因有二。兩者的研究對象不同——本文分析真實合併的 GitHub PR，依結構異味判斷；另一項研究使用 C/C++ 記憶體安全修補的合成基準，依可利用性判斷——而且兩者都沒有人工對照組，因此都無法支持代理程式與人類之間的比較。兩者共同支持的結論更有限，也更實用：無論代理程式只是順帶修改 CI 管線，還是刻意修補 CVE，代理程式輔助工作流程都不能把自身安全狀況外包給代理程式。本文的 38.9% 與另一項研究的 23.8% 是同一道落差在兩個不同面向的下限，兩者都指向審查層必須承擔防線。

延伸閱讀#

• Harness Configuration Defects — 代理程式自身設定中的未固定版本依賴異味。 本文中的代理程式把可變動標籤寫入儲存庫的建置設定；另一篇則發現，9.8% 的公開程式碼代理程式設定宣告了未固定版本的 MCP 伺服器，代理程式會在每次工作階段開始時，以自身權限解析該伺服器。兩篇也都評估偵測器：本文的 LLM 判斷器召回率為 0.775；另一篇的原始規則集標記率為 25.5%，獨立重新推導後確認率為 18.4%。
• Agent Documentation Behavior — 同一份 AIDev 資料切片，使用文件分類器而非安全分類器，也可用來檢查本文所依據的語料庫是否一致：從 2,807 個星數超過 100 的儲存庫精選出 33,596 個 PR，篩選後保留 33,097 個可分析 PR（98.5%），涵蓋 278,192 個唯一路徑上的 690,260 筆非廠商檔案 × 提交資料列，其中 29,597 筆是文件。該文也提供分析這份語料庫所需的群集處理方式——光是最大的儲存庫就有 8,911 個 PR，前十大儲存庫占 44.7%，因此儲存庫群集自助抽樣法會使區間寬度最高擴大到 Wilson 方法的 14.4 倍；本文任何 AIDev 比例都需要這項校正。
• The Tragedy of the Cognitive Commons — 附有地面實況的相同模式：審查涵蓋率存在，捕獲率卻近乎零，表示表層驗證有運作，實質驗證卻沒有。
• Review as the Control Point — 對照該文機制圖的結果層級證據：符合 P1／P4，也符合其引用的發現——審查者留言關注正確性而非安全問題；同時區分審查涵蓋率（正趨於一致）與審查成效（81.1% 的有效憑證沒有留言），顯示趨同帶來的安心程度不如表面看來。
• Acceleration Whiplash — 來自非供應商 empirical 資料、沿安全面向佐證品質方面的加速反噬，另有 Faros 跨客戶遙測無法提供的依 PR 規模分層資料：異味盛行率隨 PR 規模從 16.2% 升至 53.6%，支持將 PR 規模上限視為高槓桿措施。
• AI Brain Fry — 監督疲勞在安全領域的表現：代理程式 PR 中的真實外洩憑證有 67.6% 是人類提交的；作者將此解讀為警覺性降低／認知卸載，為投入不足的失誤模式提供了具體實例。
• Agentic Technical Debt — 安全債務是架構債務的近親：它累積在 CI／容器管線中（占異味的 87.6%），任何工作階段的「架構」都不會涵蓋這些部分；它要到憑證遭利用時才會浮現，而不是到必須重寫時才出現。
• Agent Supply Chain Risk — 用詞相同，所在層級不同：本文 82.3% 的異味是代理程式把未固定版本的動作標籤與可變動映像標籤寫進儲存庫建置設定，而非代理程式使用遭污染的模型、套件或 MCP 伺服器。代理程式撰寫程式碼時的供應鏈衛生，是獨立且按數量占主導地位的攻擊面。
• Failures That Look Like Success — 審查層的實例：含有效 AWS 金鑰的 PR 順利合併、CI 通過、沒有人留言，所有表面訊號都顯示成功；只有從憑證本身，而非結果，才能看見失敗。
• LLM-as-a-Judge — 公布校準結果的實際安全閘門案例：整體精確率為 0.908，但密鑰標記中只有 27.2% 為真，因此阻擋式閘門採用的是個別類別精確率，而非整體精確率。
• AI as Primary Author — 從安全角度衡量作者身分轉移的後果；意外之處是，在代理程式撰寫的 PR 中，最嚴重問題的主要來源仍是人類協作者。
• Agent-Vendor Heterogeneity — 本文始終缺少的人類對照，出現在同一語料庫系列中，而且方向相反。 Kraishan 針對 810 個共享儲存庫建立的基準發現，彙總代理程式的異味出現率為 2.9%，低於人類的 4.6%（OR 0.63）；五家供應商的每行密度差異都微不足道——但該研究檢查的是以 regex 比對的新增 Python／JS／TS 應用程式行，而非本文使用 LLM 判斷的 CI／Dockerfile／IaC 高風險路徑，因此 38.9% 與 2.9% 回答的是不同問題，並不矛盾。兩個真正交集值得注意：依規模分層的檢查發現，彙總代理程式與人類的密度差異全都出現在 XL PR 區間；這讓本文的 16.2%→53.6% 規模梯度獲得第二種測量方式的佐證。該研究也獨立發現密鑰方面的意外結果——代理程式 PR 中有 0.9% 含硬編碼憑證，人類 PR 則為 2.2%——其依據是異味數量，而非提交者歸屬。該文對本文最重要的提醒是彙總處理：異味出現率在五家供應商之間從 1.6% 到 9.5% 不等，因此單一「代理程式 PR」異味率，是對一群彼此不同的對象取平均。
• Verification as the New Bottleneck — 衡量瓶頸下限的資料：在唯一具備專用自動化的異味類別中，七種機器人與人工審查者合計只對 18.9% 的有效憑證留言。
• Unknowns as the Agentic Bottleneck — 針對這項失誤設計的對策：Thariq 的測驗閘門要求人類以展現理解作為合併條件，而非只留下簽名；這是知識庫中唯一會對無人留言的憑證發揮作用、且經過審查的機制。
• OWASP — 為分類法提供依據（與 CIS Benchmarks 及 GitHub 強化文件並列的安全程式設計指引）。
• Risk-Tiered Auto-Approval — 這些數字從兩方面評估該文的設計。16.2%→53.6% 的規模梯度，是 StampHog 設定 <500 行／<20 個檔案自動核准上限的獨立實證依據；但其爆炸半徑拒絕清單依據的是商業風險關鍵字（驗證、密鑰、帳務、公用 API），而本文測得的異味有 82.3% 屬於供應鏈完整性問題、87.6% 位於 GitHub Actions 工作流程與 Dockerfiles——這些檔案不符合任何此類關鍵字，使留言率僅 18.9% 的審查層成為唯一剩下的檢查。具體建議：CI／容器／IaC 路徑應不受關鍵字影響而列入拒絕清單。
• Agent-Generated Test Quality — AIDev 在測試面向上的近似研究，使用同一語料庫系列與月份，目前已有兩項相關研究。兩者對照組的缺陷方向相反（本文沒有人工基準；測試品質研究的比較受到混雜因素影響；涵蓋率研究完全沒有對照），因此都無法提供本文第一項開放問題所需的配對基準；但三項研究都指向同一特徵：代理程式債務集中在環境與關係（CI 管線、容器、未模擬的檔案 I/O、測試原本應防護的差異）而非應用程式邏輯。將數字並列前，請先閱讀該文的語料庫說明：該文的 4,882 個 PR 涵蓋率研究與本文的 4,022 個 PR，是 AIDev 的不同篩選結果——本文依高風險路徑與新增行篩選；該文則選出含非註解變更的 .java／.py PR——檔案類型選擇方向相反。因此數量相近只是巧合，分母不可互換。
• Efficiency Debt of AI-Generated Code — 第三個近似面向，也是終於提供人類對照組的一項研究（352 萬筆生產變更，並測量來源）。該研究對安全問題的結論與本文框架相反：AI 生成的 C++ 在正確性與安全靜態檢查結果上是人類程式碼的 0.94 倍，生命期／所有權危險則為 0.71 倍；超出部分反而集中於效率與介面耦合。研究對象與分類法不同（clang-tidy 檢查應用程式 C++，對照 CI／IaC 安全異味），因此只能作為反向佐證，不能直接套用；但它是此語料庫中唯一配對的代理程式對人類品質比較，研究結果不支持「AI 程式碼普遍較不安全」的先驗假設。
• Same-Model Review Blindness — 本文的偵測下限未控制的一項變數。真實有效憑證的留言率 18.9%，是七種工具（包括 Greptile 自身）混合後的數字，且沒有記錄審查配對：語料庫沒有記錄撰寫 PR 的模型與審查模型之間的關係，而 Greptile 的配對資料集（case-study）顯示，高嚴重程度問題的召回率正好有 6–12 個百分點差距。這不會推翻本文的下限——6–12 個百分點遠不及 18.9%——但表示這個下限是混雜因素下的平均值，而非自動審查本身的固有特性；它也指出一項低成本的測量改善方式：依撰寫代理程式分層。
• Agent Review Comment Resolution — 自動化審查層的另一種失誤模式，也說明本文的 18.9% 衡量的是偵測，而非注意力。 該研究測量審查層確實發揮作用時的情況：54,713 則代理程式審查留言中約 71% 獲得處理；470 則按卡片分類的駁回中，只有 11 則被以低價值為由拒絕。最常見理由是代理程式看不到的專案背景（23.8%），而完全幻覺只有 4 個案例。合併來看：審查層大多沒有對憑證發出警示，但一旦發出，開發者便會採取行動。兩個數字都不支持「人類未專心」是主要限制因素。不過兩者測量的迴圈不同——該研究觀察代理程式審查 PR，本文觀察審查者對代理程式撰寫程式碼的審查。
• Telemetry vs. Survey Measurement — 說明本文持續缺少配對人工基準的原因是一項測量問題，而非單一研究的限制。DX（vendor-claim）於 2026 年 7 月表示，採用率超過 90% 後，「比較 AI 使用者與非使用者對照組已不再是可行的測量策略」——但這並非本研究受阻的原因。AIDev 類型語料庫由代理程式作者身分界定，因此不論採用率如何，都只會有一組資料；另一組資料需要每筆變更都記錄作者來源，而只有自行觀測編輯器的組織掌握這類資料（Tran 等人）。資料缺口在於儀器化，而且在程式碼撰寫之前便可修補，不必等到事後。
• The Data Wall and the Validation Commons Are One Supply Constraint — 將這些數字用作該領域的結果證據；Musk 稱此領域最接近「Stockfish level」：真實有效憑證的留言率為 18.9%，其中 67.6% 是代理程式 PR 裡由人類提交的；涵蓋率趨於一致，成效卻停留在低點。該綜合分析的提醒值得一併參考——本文測量現有驗證者的表現，從未觀察其供給量，因此只能佐證驗證繫鏈承受壓力，無法觀察共同資源的枯竭。它提出的低成本改善措施，是依審查者年資分層分析 18.9%，把表現數字轉換成供給數字。
• Structural Artifact Monitoring — 針對本文所測量情況、作用於相同表面層的強制執行方案。本文發現 38.9% 的代理程式 PR 帶有異味，其中 87.6% 位於 GitHub Actions 與 Dockerfiles；最重要的數字是81.1% 的真實外洩憑證在沒有任何機器人或人工審查者留言的情況下進入整合。Ravindra 等人則在建議的基礎架構差異上、合併前設置控制流程／資料流程監視器，並在 ControlArena 的破壞設定中回報 0／160 的聯合攻擊成功率。兩者不能合成一個數字（一者是真實合併程式碼中的規則層級異味，一者是在建構基準中捕獲隱蔽破壞），但作用於同一表面；而且各自提供了對方欠缺的資訊：本文提供現實世界的基準率，另一項研究提供成效測量。
• Prototype Fidelity After Cheap Polish — 對該文演化式原型製作兩難的一個面向：代理程式生成的程式碼是否適合逐步演化成正式產品，而非重新打造。
• Open Source Under Agent Contributions — 本文數字應予修正的維護者樂觀論：代理程式 PR 通過維護者檢查的衛生項目，但債務卻累積在沒有人審閱的 CI 與容器管線中。
• Does the Augmentation/Automation Split Govern Skill at Work? — RQ2 警覺性結果（人類提交 67.6% 的真實外洩憑證，81.1% 沒有審查留言）作為放棄履責的測量證據：審查步驟在工作量之下消失，而受監督學習實驗的自動化組不會產生這種模式。
• Experimental Learning Impact of Generative AI — 從學習角度解讀 RQ2 的警覺性發現：隨機實驗中的自動化模式使用者仍會閱讀並提交自己的輸出；因此本文測得的情況（人類提交 67.6% 的真實憑證外洩，81.1% 沒有審查留言）比該模式更進一步——原本能帶來學習的審查根本沒有發生。

衍生文章#

• Is Human Review of AI-Authored Code Still a Real Control, or Already Rubber-Stamping? — 本文更新的監督綜合分析：新增結果層級的第四層證據，支持蓋章式審查的論點；並將「100% 自動化所有機械檢查」從現況描述降為建議。

尚待解答的問題#

• 38.9% 的異味率沒有同一組高風險路徑上的人類撰寫 PR 對照組；用來支持該說法的弱點率 2.7 倍，來源則是廠商部落格與 Substack 貼文。代理程式撰寫是否提高了異味密度，還是只增加了被修改的 CI／IaC 檔案數量？若能在相同路徑集合上建立配對的人類基準，就能回答這個問題。2026-08-12 部分解答：Tran 等人（empirical，Google，arXiv 2608.06640）讓語料庫現在有了一組配對的人類基準——352 萬筆具備撰寫時間來源資料的生產變更與人類撰寫組；依該研究分類法，AI 生成程式碼的正確性與安全性低於人類基準（0.94 倍），API 誤用（0.93 倍）及生命期／所有權危險（0.71 倍）也較少；超出部分則集中在效率與介面耦合。這直接反駁本文標示為未獲佐證的 2.7 倍弱點率。但路徑集合不同：該研究以 clang-tidy 類別評分應用程式 C++，而非檢查 GitHub Actions／Dockerfiles／IaC 安全異味；該研究中的 AI 組每筆變更也觸及較多檔案（中位數 3 個，對照 2 個），而這正是本項問題尚未測量的變更量部分。因此密度與數量的問題仍未解決，但原本要檢驗的先驗假設如今方向相反。2026-09-22 再獲部分解答，且這次來自同一語料庫系列：Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild（Kraishan，Texas Tech，arXiv 2609.17598，empirical）是第一項具有人工 PR 對照組的 AIDev 研究——只保留同時包含代理程式 PR 的 810 個儲存庫中 4,027 個人工 PR，採用相同時間範圍，並在固定隨機種子下限制每個儲存庫的樣本數。在異味出現率方面，該研究發現彙總代理程式低於人類：2.9% 對 4.6%，OR 0.63 [0.47, 0.85]，χ²(1) = 8.59，p =.003。在異味密度方面——也就是本項問題真正詢問的量——相對人類而言，所有成對 Cliff's δ 都屬於微不足道的差異（Codex −.02、Copilot −.02、Cursor −.03、Devin ns、Claude Code +.05），因此作者的總結是每行密度在不同作者身分之間相近。對該研究的路徑集合而言，密度問題已有解答，但該集合並非本文使用的路徑：它以 regex 比對新增的 Python／JS／TS 應用程式行，本文則使用 LLM 判斷 CI／Dockerfile／IaC 高風險路徑，因此兩者的儀器、語言集合和檔案類型都不同，38.9% 與 2.9% 並不可比。變更數量部分仍未觸及——該研究沒有計算各群組修改多少 CI／IaC 檔案。無論如何，有兩項結果值得參考：彙總代理程式與人類的密度差異全都來自 XL PR 區間（δ = −.08，p =.025；四個較小區間都沒有差異），也就是本文測量到的規模梯度從另一方向出現；而在憑證類別中，代理程式比人類乾淨——代理程式 PR 中有 0.9% 含硬編碼憑證，人類 PR 則為 2.2%（OR 0.39 [0.25, 0.62]，p <.001）——這是本文 RQ2 經由完全不同途徑得到的同一項意外結果。兩個方向上的供應商差異都遠大於彙總效果：異味出現率從 Cursor 的 1.6% 到 Claude Code 的 9.5%，單看憑證則相差四倍。見 Agent-Vendor Heterogeneity。
• 「沒有審查留言」代表沒有偵測到嗎？74 個真實憑證中有 60 個在沒有留言的情況下被移除，但摘要卻把同一批資料解讀為偵測失敗。分析提交歷史，追查是誰、何時移除它們，即可區分無聲修補與偶然變更。
• 代理程式 PR 的審查涵蓋率正趨於一致，朝人類基準靠攏，但憑證審查成效近乎零。隨著團隊成熟，兩種趨勢會同步變化，還是各自獨立——也就是審查者出席是否能提高可測量的捕獲率？最接近的證據（2026-08-12）無法回答此問題，相似之處容易造成誤解。Cynthia 等人（empirical，arXiv 2607.21997）迄今測量規模最大的近似審查成效研究，分析 54,713 則代理程式審查留言，其中 71.4% 獲得處理；但它測量的是相反方向：由代理程式審查提取要求，再由人類決定是否採取行動，而非審查者在代理程式撰寫的程式碼中找出缺陷。其處理率是採納情況的代理指標，該研究的構念效度章節也承認「留言可能在沒有實際用處的情況下被處理，也可能雖然有價值卻未獲處理」。它能提供的是診斷的反面證據：研究樣本中的開發者有投入，並非昏昏欲睡，因此本文憑證捕獲率偏低的原因不太可能只是單純疏忽。這個問題仍需要一項在同一批 PR 上，將審查者是否出席與缺陷地面實況配對的研究。

資料來源#

• From Agent Behaviour to Agent-Friendly Documentation — Gao 與 Chen（Peking University），arXiv 2608.20195，2026-08-20，empirical。本文僅引用該研究的語料庫描述與統計處理：§3.1（AIDev 精選子集、篩選至 33,097 個 PR／690,260 筆資料列，以及 29,597 個文件路徑），以及 §3.6 與表 6（儲存庫群集自助抽樣、2,000 次重抽樣，以及相較 Wilson 方法最高 14.4 倍的區間擴寬）。該研究沒有測量任何安全數值。完整說明見 Agent Documentation Behavior。
• Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild — Obada Kraishan（Texas Tech），arXiv 2609.17598，2026-09-12，empirical。§3.1（810 個儲存庫配對的人類基準）、§3.3（八種 CWE 的 regex 分類目錄及其涵蓋 23.7% PR 的情況；揭露路徑穿越偵測器錯誤在修正前使該類別數字膨脹約 150 倍）、§4.1 與圖 2（各群組異味密度與出現率、XL 區間敏感度檢查）、§4.4 與圖 4（各 CWE 勝算比及各供應商憑證差異）。表 1 與表 2 已透過 pdftotext -layout 逐格核對；完整說明與唯一作者／無發表場地的注意事項見 Agent-Vendor Heterogeneity。
• The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities — Mohammadreza Rashidi，arXiv 2607.05743，2026-07-07，empirical。僅引用 §4.12 所述 SecureVibeBench（Chen 等人，arXiv 2509.22097）與該回顧文章對其結果的解讀。這是一份系統化回顧：23.8% 是原始論文測量結果的轉述；該回顧核對摘要頁的引文身分，並明確表示沒有重現任何受調查論文的實證主張（§9）。
• Trust but Verify? Uncovering the Security Debt of Autonomous Coding Agents — Sakib、Banik 與 Jadliwala（UTSA，arXiv 2607.12428，2026-07-14），empirical。§2（語料庫建立、六類分類法、LLM-as-judge 設定、密鑰有效性編碼規範）、§3.1（RQ1 分布、嚴重程度、檔案類別與 PR 規模分層、判斷器驗證）、§3.2（RQ2 真實密鑰、提交者歸屬、審查留言率）、§4（效度威脅）、§5（相關研究，包括 Haider 與 Zimmermann 對審查焦點的研究）。