Agent-Generated Test Quality

資料來源#

• Beyond Test Presence: Assessing the Quality and Robustness of Agent-Generated Tests in Open-Source Projects
• ExecCritic: Learn to Test, Test to Improve for Coding Agents
• Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild
• Test Coverage Analysis of Agentic Pull Requests
• Uncle Bob on Software Fundamentals in the Age of AI

摘要#

Jhanglani、Desai、Kansara 與 AlOmar（Stevens Institute of Technology，arXiv 2607.12068，2026 年 7 月）提出一個像 SWE-bench 這類通過率基準在結構上無法回答的問題：不是代理程式的測試是否通過，而是測試品質如何。他們從同一份 AIDev 語料解析 204,673 個 Python 測試檔（24,941 個由人類撰寫、179,732 個由代理程式撰寫）為 AST，並以靜態方式評分三個面向：斷言強度（RQ1）、邊界案例涵蓋度（RQ2），以及不穩定性潛勢（RQ3）。

結果顛覆了預期的說法。原先的假設是代理程式只會寫出淺薄、打勾交差的測試。數據呈現的卻是一種取捨：代理程式涵蓋的邊界條件比人類多，斷言強度也不相上下，但它們寫出會碰觸磁碟、呼叫非決定性 API 的測試比例明顯較高。作者稱之為**「隱形技術債」**——測試套件今天執行時能通過、提供實際的涵蓋廣度，卻可能在日後悄悄降低 CI 可靠性。

證據說明。 本文標記為 empirical，測量也確有其事，但儀器有三項缺陷（如下），因此只有 RQ2 和 RQ3 的方向性發現值得延續；RQ1 則應視為尚未證立——作者自己在效度威脅一節也得出相同判斷。作者指出的範圍限制：僅限 Python、僅限開放原始碼，而且代理程式模型只涵蓋 AIDev 蒐集期間的版本（所以研究描述的是比目前部署版本更早一代的代理程式）。

標題表格#

Table VI 涵蓋全部四個群組。A-Sliced 是最初的 24,941 個代理程式檔案；A-Sliced-Rand 是隨機抽取的 24,941 個——兩者都是為了讓樣本規模與人類群組相同。摘要引用的是 A-Sliced-Rand 欄，因此廣受引用的不穩定性數字是 0.41，而非全體樣本的 0.44。

指標	人類	代理程式（全部）	A-Sliced	A-Sliced-Rand
總檔案數	24,941	179,732	24,941	24,941
含可解析斷言的檔案	1,730 (6.9%)	29,353 (16.3%)	3,412 (13.7%)	4,046 (16.2%)
弱斷言	11.92%	14.30%	13.90%	14.63%
強斷言	88.08%	85.70%	86.10%	85.37%
未知斷言	1.46%	10.93%	9.22%	11.58%
可能不穩定的比例	0.30	0.44	0.46	0.41
邊界案例多樣性	0.32	0.61	0.58	0.62

粗體列是左右其他所有結果的關鍵：分析只涵蓋 6.9% 的人類檔案和 16.3% 的代理程式檔案。 其下每個百分比都是以這個篩選後的子集計算，並非以標題所示的 204,673 個產物為分母。

RQ2：代理程式涵蓋更多邊界（穩健的發現）#

以呼叫引數傳入的字面邊界值，各類別所占比例：

邊界案例	人類	代理程式
零輸入	11.2%	27.7%
空集合	8.1%	15.0%
Null 輸入	8.3%	13.0%
空字串	4.1%	5.7%
負值輸入	0.0%	0.0%

代理程式在所有有測得數值的類別都領先，綜合多樣性分數也大約是兩倍（0.61–0.62，相較於 0.318）。有意思的是作者提出的機制，而且讀來合情合理：LLM 的機率式列舉就像低成本模糊測試器，會為每個參數機械地列出 null／零／空值；人類開發者則會依照領域模型判定哪些案例不可能發生，進而略過。這不是代理程式比較聰明——而是代理程式缺乏人類用來篩除案例的隱含假設。論文明確表示，不判定多出的案例究竟是保護還是雜訊。

負邊界列是程式錯誤，不是研究發現。 四個群組都是 0.0%，並非人類和代理程式共同忽略了這類情況，而是偵測器根本不可能觸發。Table III 將規則寫成 ast.Constant(value=-1)，但 CPython 會把 f(-1) 解析為 UnaryOp(USub, Constant(1))——從不會得到負值的 Constant。這條規則從設計上就匹配不到任何內容。論文將 0.0% 當成實質結果報告（「值得注意的盲點」），但它其實是儀器缺陷；這也表示多樣性指標對兩個群組都對稱地少算了五個類別中的一個。

除此之外，作者也承認，管線只能偵測字面值：f(0) 會計入，empty = []; f(empty) 則不會，因為系統沒有做資料流分析。因此，這項指標衡量的是對字面邊界案例的認知，並會系統性低估較常使用變數驅動、測試夾具驅動測試的群組。考量人類比代理程式更可能使用測試夾具和參數化，這項差距很可能被誇大，讓代理程式看起來更有利。

RQ3：代理程式寫出的測試較不穩定（方向上有支持，尚未確認）#

靜態不穩定性指標的出現比例：

模式	人類	代理程式
非決定性（random、datetime.now）	3.1%	5.2%
檔案 I/O（open）	3.5%	4.6%
非同步等待（time.sleep）	1.9%	1.3%
網路 I/O	0.1%	0.2%

差距有限且明確，因此比「代理程式比較差」這種籠統說法更可信：代理程式並非在每個面向都較差——人類使用固定等待時間的比例稍高——但代理程式較常在沒有模擬或清理的情況下碰觸磁碟，並使用隨機值或時鐘值。作者診斷為缺乏環境認知：代理程式能推理受測函式，卻無法理解測試將執行的 CI 沙箱。他們建議的解法是在沙箱中自行執行（從「生成並祈禱」改為「生成、執行、精修」），這與驗證成為新瓶頸所說的左移思維一致，只是應用到代理程式自己的輸出上。

動態階段從未報告。 §II 和 §III.C 指定了兩階段流程：先靜態篩選出候選，再從每個群組抽樣 1,000 個測試，在隔離環境中重跑 N=100 次，以得到確認不穩定率。第二階段只以未來式出現（「我們將執行……」），結果中完全沒有確認後的比率。 作者自己的建構效度一節指出，靜態指標「單獨來看是薄弱的建構」，而且「只有作為兩階段流程的第一階段才有效」——因此依照他們自己的標準，論文發布的不穩定性發現正是這種薄弱建構。實際測到的是測試包含與不穩定性相關模式的比例。應將 0.44 對 0.30 視為風險代理指標差異，而非不穩定率。

RQ1：依作者自己承認，尚未證立#

報告中的差距很小——強斷言為 88.08% 對 85.70%——更有意思的數字是「未知」：代理程式 11.58%，人類 1.46%，約為 8 倍。作者稱之為斷言漂移：代理程式使用專案專屬、拼錯或自行編造的斷言方法。他們描述的可維護性成本是真實且值得保留的：審查者遇到 assertIsLess，就得停下來判斷這是巧妙的專案輔助函式，還是幻覺；這種摩擦會在整個程式碼庫中累積。這是測試套件版本的合理表面成本，與 Faros 衡量資深審查者所付出的成本相同。

但這個比較的根基站不住腳。§IV 直言，分析器「無法解析 pytest 風格的斷言」，使它「對 Human-PR 群組中的『測試品質』而言是個糟糕的代理指標，因此無法進行直接比較」。Python 測試生態系分成 unittest 的 assertX 方法與 pytest 的裸 assert 陳述式；TestAnalyzer 只辨識 ast.Call 節點，因此只能看到前者。這解釋了人類檔案 6.9% 的解析率，也很可能解釋了方向相反的未知斷言差距：完全使用 pytest 風格撰寫的人類檔案不會有任何可辨識的斷言，因此會從分母中剔除，而非記為未知；如此一來，通過篩選的群組就只剩下不具代表性的少數 unittest 撰寫者。8 倍的斷言漂移差距，正好繼承了作者說會使 RQ1 無效的缺陷。 差距方向值得參考，幅度則不可採用。

另外還有兩處內部不一致，雖然不大，但值得記錄，因為關係到研究的嚴謹度：§III.A.a 說斷言是用 tree-sitter 解析，但 §II 和白箱流程圖則說使用 Python 原生 ast 模組；Pipeline C 的輸出定義為 len(rq3_flakiness_indicators)——也就是數量——但 Table VI 的「Cand. Rate」卻呈現為 [0,1] 之間的比率。§IV 還引用「每個群組 N=29491」，與兩個群組的數量都不相符。

哪些結果站得住腳#

剔除儀器無法支持的內容後，剩下的發現如下：

1. 代理程式比人類更機械地列舉字面邊界值。 在所有四個群組和所有有測得數值的類別中都穩健。其機制（以機率式列舉進行模糊測試；人類依領域模型篩除）合理且可測試。
2. 代理程式測試使用未模擬 I/O 和非決定性操作的比例，約為人類的 1.3–1.5 倍。 方向性明確、範圍有限，只涉及兩種模式；但它是風險代理指標，因為作者從未報告用來確認的重跑結果。
3. 兩個群組的斷言品質都沒有顯著差異，但人類的測量方式有嚴重缺陷，這是必要的保留條件。
4. 這是取捨，而非缺陷。 代理程式是高產量的測試生成器，需要人類監督其環境隔離——涵蓋廣度足夠，穩定深度不足。這與「AI 寫出糟糕的測試」大不相同，也是論文證據真正支持的主張。

同一份語料的另一種切法：代理程式的程式碼究竟有沒有被測試？（Dipongkor 等人，2026-07）#

上述內容都是拿測試檔案與它自己相比。Dipongkor、Baral、Lam 與 Moran（UCF／George Mason，arXiv 2607.18057，ICSME 2026，empirical）則以隨同測試發布的差異內容為基準衡量測試，涵蓋 4,882 個 AIDev v3 PR（532 個 Java、4,350 個 Python，五種代理程式）：代理程式新增的程式碼行，是否有任何測試執行到——無論是專案既有測試套件，還是代理程式自己寫的測試？同屬一個語料家族，使用相反的測量工具，兩者的結果能互相補充，而非相互矛盾。

有無測試：半數程式碼變更 PR 沒有測試變更#

4,882 個 PR 中，有 4,387 個修改受測程式碼檔案（530 個 Java、3,857 個 Python）；其餘 495 個只碰觸測試檔案。在這 4,387 個 PR 中，2,176 個（49.6%）包含測試變更，2,211 個（50.4%）沒有。 代理程式若有碰測試，新增多於修改：1,983 個新增測試、1,500 個修改既有測試、812 個兩者皆做。

分母切換未標示。 標題的 49.6%／50.4% 以 4,387 個程式碼變更 PR 為分母，但按語言呈現的句子（「53.0% 的 Java、44.3% 的 Python PR 修改受測程式碼檔案，卻沒有任何測試變更」）悄悄改用全部 PR為分母（532 和 4,350）。以程式碼變更 PR 為分母，這兩列應為 Java 53.2%、Python 50.0%。這些數字是從 Figure 1 的文氏圖還原而來，並能與本節所有文字總數互相核對。

圖中還有一項文字沒有提到的拆分：Java 代理程式有 46.8% 的程式碼變更 PR 包含測試（248/530），Python 代理程式則為 50.0%（1,928/3,857）。 Python 代理程式碰測試的頻率稍高，涵蓋率卻低得多，因此測試有無的差距並非下文涵蓋率差距的成因。兩種語言中未測試的 PR 也各有不同特徵：Java 以 docs（37.6%）、fix（34.4%）和 feat（15.2%）為主；Python 則以**feat（40.5%）**、fix（30.3%）和 refactor（11.8%）為主。只碰到 .java 檔案的 Java 文件 PR，可能幾乎沒有需要測試的內容；Python 的 feat PR 則是未經測試就交付功能。一個標題涵蓋兩種不同群體。

既有測試安全網的代價#

需要有一個能執行的測試套件才能計算涵蓋率，因此子集遠小於整份語料：只計入合併的 PR，且來自含有 ≥10 個代理程式 PR 的儲存庫（14 個 Java、55 個 Python）；其中10 個 Java 和 34 個 Python 儲存庫能夠建置並加上儀器——最終涵蓋 213/532 個 Java PR（40%）和 1,664/4,350 個 Python PR（38%）。以下所有數字都來自這個子集，使用 JaCoCo 和 pytest-cov 收集整個儲存庫測試套件的行涵蓋率。

• 既有測試執行了代理程式所修改可執行行數的 Java 61.5%、Python 27.0%。
• Java PR 的中位數有 71.1% 的變更行受到涵蓋；其中 34.3%（73/213）獲得完整涵蓋。
• Python PR 的中位數是零，而且 64.8%（1,079/1,664）沒有任何變更行被既有測試執行。
• 以檔案為單位，比例則反過來：259 個 Java 檔案中有 50.2% 完全涵蓋、18.5% 未涵蓋；2,696 個 Python 檔案中有 24.5% 完全涵蓋、54.2% 未涵蓋。
• 兩種分布在 0% 和 100% 都呈雙峰（Figure 2）；單是 Python 的零涵蓋率區間，就約有 1,130 個 PR，占 1,664 個 PR 的多數。

作者提出的實務建議值得引用：「使用代理程式 PR 的團隊，不應假設測試通過就代表變更已經受測。」 對 Python 代理程式 PR 而言，測試套件顯示綠燈，幾乎無法說明差異內容是否真的受過測試。

代理程式撰寫的測試：平均而言有顯著效果，但多數 PR 沒有受益#

配對設計很乾淨——在 head commit 上反向套用只改測試的修補程式（git apply -R），重跑測試套件，再計算兩次執行的差異。這項設計適用於 64 個 Java 和 605 個 Python Code+Tests PR。Java 涵蓋率從 70.5% → 86.1%（+15.6 個百分點），Python 從 24.8% → 34.5%（+9.6 個百分點），兩者 p < 0.001；但只有 35.9%（23/64）的 Java、22.5%（136/605）的 Python Code+Tests PR 有任何提升。 平均值幾乎全由功能工作帶動（Java feat 在 17 個 PR 上 +47.3 個百分點，其中 14 個提升；Python feat 在 364 個 PR 上 +13.0 個百分點，其中 99 個提升），fix 只有小幅顯著提升（Java +5.0、Python +6.6），其他類別都沒有提升。

Python 的 test 類別 PR 呈現負差異——25.7% → 23.5%，−2.2 個百分點，36 個 PR 中有 3 個提升，結果不顯著。目的明確標為測試的 PR，反而略微降低了自身變更行的差異涵蓋率。樣本數極小且不顯著，頂多只能視為方向性結果，但這是以下目標錯置現象最鮮明的單一例子。

未改善的 PR 有兩種不同原因，兩者都值得保留：

• Java——42.2% 的 PR 原本就已由既有測試達到 100% 差異涵蓋率，這是上限問題，不是失敗。至於其他 PR，代理程式刪除的測試比新增的多：刪除 82 個、新增 31 個，比例為 2.6 倍；另有 51.2% 只修改既有測試的本體，改變行為，卻沒有新增能針對變更的測試。
• Python——只有 8% 的 PR 觸及上限，只有 12.4% 含有刪除；然而 74.8% 新增了測試，卻依然沒有涵蓋代理程式自己新增的變更行。

這是本頁先前沒有的發現：代理程式寫了測試，測試執行並通過，卻測到了 PR 所引入內容以外的東西。

各種結構的漏測率——請留意分母#

Table II 的順序是先 Python、再 Java，解析後的表格很容易看錯。Total 是代理程式新增的該類別可執行行數；Miss% 是沒有任何測試涵蓋的比例。

類別	Python 總數	Python 漏測率	Java 總數	Java 漏測率
方法呼叫	4,516	73.6%	403	36.7%
指派	9,472	63.1%	671	16.1%
If	3,094	62.5%	308	13.3%
Return	2,189	71.4%	367	39.8%
Try-Catch	1,356	81.0%	43	86.0%
Throw	536	82.3%	80	67.5%
定義	3,062	54.1%	35	22.9%
For / While	710 / 94	54.1% / 69.1%	31 / 21	19.4% / 9.5%

錯誤處理是兩種語言最薄弱的環節，而 Java 的 Try-Catch 是唯一一個絕對漏測率高於 Python 的類別——但它只有 43 行新增程式碼，Python 則有 1,356 行。論文在摘要、結果與兩段討論中四度重複「Java 為 86.0%」，卻從未重述分母；同樣的小樣本也使 Java 的 Switch（n=1）和 Continue（n=2）出現不合理的 0.0% 數字。真正具有代表性的，是 Python 常見結構——指派的 9,472 行中有 63.1% 未涵蓋，方法呼叫的 4,516 行中有 73.6%，Return 的 2,189 行中有 71.4%——「代理程式只測到成功路徑」的說法正是建立在這些數據上。

跨語言差異部分來自抽樣偏差#

作者自己的限制一節削弱了他們一開始主打的比較。分析的 10 個 Java 儲存庫明顯小於、也較不知名於 Java 語料（LOC 中位數 29K 對 102K，星數 437 對 745，fork 數 116 對 254），只有提交數和歷史長度相當——因此「Java 涵蓋率結果可能主要反映較小型專案的測試實務」。分析的 34 個 Python 儲存庫，在所有測得指標上都與 Python 語料沒有差異。較漂亮的數字來自不具代表性的樣本，令人擔憂的數字則來自具代表性的樣本。 Python 的數值應視為設計所支持的結果，Java／Python 對照則只適合視為線索。

兩項研究如何相互補充#

表面上有個張力值得化解，而不是取平均：本頁說代理程式涵蓋更多邊界案例，另一項研究則說代理程式的測試大多沒有涵蓋代理程式自己的變更。兩者都成立，因為分母是不同的對象——以測試檔案本身評斷測試，對照以差異內容評斷測試。 而且一種機制可以同時解釋兩者。以機率方式列舉 null／零／空值（本頁稱為低成本模糊測試）能普遍而周全地測試所針對的函式，卻完全不在乎這個 PR 新增了哪些行。廣度是測試的內在屬性，目標關聯性則是相對屬性；只有相對屬性才構成安全網。 Python 的 74.8%——新增測試、測試通過、代理程式自己新增的行卻完全沒碰到——直接呈現了這項差異。

兩項限制讓這項結果只能視為水準測量。研究沒有人工基準——在 50.4% 的 PR 沒有測試變更的情況下，無法判斷人類在匹配 PR 上做得比較好或比較差。這是一篇 6 頁的 ICSME「初步結果」論文：儀器確實存在，樣本流失也誠實報告，但全文沒有任何受控比較。

與其他 AIDev 結果的關係#

三組 PR 數量並非同一批 PR。 本頁的 204,673 個測試檔、安全性論文的 4,022 個 PR，以及涵蓋率論文的 4,882 個 PR，是 AIDev 家族語料經過三種不同篩選的結果，而非同一組資料的三次快照。安全性語料保留路徑符合高風險模式的檔案（CI 定義、容器、IaC、含密鑰檔案、設定、Shell 腳本、筆記本），且只看新增行——16,370 項檔案變更分布於 4,064 個 PR，判定器對其中 16,112 項、橫跨 4,022 個 PR 回傳標籤。涵蓋率語料則保留至少碰到一個 .java 或 .py 檔案、且修改內容並非全是註解或文件字串的 PR；資料來自 AIDev 版本 3（篩選前有 1,278 個 Java 和 7,191 個 Python PR）——532 + 4,350 = 4,882。兩者篩選的是相反檔案類型：一者是建置與部署管線，另一者是應用程式原始碼。只有涵蓋率論文說明資料集版本，因此不能排除快照不同；但光是篩選條件就足以解釋數字，兩者數量接近只是巧合。沒有任何理由能把其中一項的比率與另一項的分母配在一起。

檢視三種切法——測試品質（本頁）、安全態勢與涵蓋率——沒有任何矛盾站得住腳。 三者衡量不同面向，而在有所交集之處也彼此一致：代理程式的債務落在代理程式程式碼與周遭環境之間的關係（CI 沙箱、容器、測試原本應防護的差異內容），而不是游標所在程式碼的局部品質。三者也有共同弱點——都沒有人工對照群組；只有Tran 等人（完全不同的語料）有。(2026-09-22 補充：如今有了第四項 AIDev 研究——Kraishan只保留同時含有代理程式 PR 的 810 個儲存庫中的人類 PR，使用固定隨機種子並限制每個儲存庫的數量，讓同一批儲存庫中有 4,027 個人類 PR 對上 9,750 個代理程式 PR。這證明在這份語料中可以建構基準。但它沒有修正此處三項研究的說法，因為研究衡量的是安全性異味、結構可維護性、變動量、還原與審查行為，完全沒有任何測試相關數值——AIDev 現在有了人類群組，只是沒有本頁需要的面向。)

本頁是代理程式產生程式碼的安全債的品質姊妹篇——同一語料家族、同一個 2026 年 7 月時間區間，探討互補面向。有兩項對比值得一併看待：

• 對照群組各有不同缺陷。 安全性論文沒有人工基準，因此只測得水準（38.9% 的代理程式 PR 有安全性異味），無法支持代理程式對人類的差異值。本論文有人類群組，但比較受到 pytest 解析率差距干擾。因此兩者都不是知識庫開放問題所要求的匹配基準研究——但缺陷方向不同，而且兩者一致之處（代理程式較不擅長處理環境問題：CI 管線、容器、檔案 I/O、隔離）並非任一缺陷造成的假象。
• 兩者都在管線而非邏輯中找到債務。 87.6% 的安全性異味集中在 GitHub Actions 和 Dockerfile；測試不穩定則集中在檔案 I/O 和非決定性 API。兩種情況下，代理程式都能勝任正在處理的程式碼，卻錯誤處理程式碼執行的環境。這比「代理程式寫的程式碼品質較差」更精確，也更能指引行動。

能補上測得差距的儀器（Martin，2026-08）#

上述兩項研究都測量代理程式測試是否觸及程式碼——變更行涵蓋率、有無測試變更、各種結構的漏測率。兩者都沒有測量觸及程式碼的測試是否真的對程式碼形成約束；涵蓋率也無法做到：即使測試執行某一行時完全沒有對它做任何斷言，那一行仍然算是受測。

Robert C. Martin在他的管線中把這項儀器設為必經階段，正好能補上這個差距（Uncle Bob on Software Fundamentals in the Age of AI，2026-08-19，practitioner-opinion）。變異測試會在原始碼中翻轉各種運算子，並要求測試套件在每次翻轉後都失敗；若套件在某次翻轉後仍能通過，那就是存活變異——一行程式碼雖然受到涵蓋，卻沒有受到約束。他的強化階段會持續執行，直到沒有存活變異，並且「絕不手軟」。

這與本頁數字有三點關聯：

• 它將本頁的涵蓋率發現轉為下限，而非估計值。 如果 Java 有 61.5%、Python 有 27.0% 的變更行會被執行，真正受到約束的比例至多如此，而且很可能遠低於此。沒有人在 AIDev 語料上執行過變異分數；這是加入任一研究最便宜的一項測量。
• 錯誤處理結果最可能受它影響。 錯誤處理結構最多有 86.0% 完全未被執行。錯誤路徑也最常出現「有涵蓋、無斷言」的情況——測試觸發例外，卻沒有檢查拋出的內容或例外後保留下來的狀態。變異閘門會同等看待這兩種失敗。
• 它是閘門，不是指標。 Martin 使用這項技術不是為了測量，而是為了強制執行：代理程式持續迴圈，直到沒有變異存活。這與代理程式程式碼審查的決定式工程所主張的形式相同，也與重振不切實際的品質工具所解釋的技術普及原因一致——這項技術在 2000 年就已成熟，卻因為必須由人類殺死變異而負擔不起。

他也提出一項本頁有證據支持的說法：不論如何指示，代理程式都不會做 TDD，最後仍會回到先寫函式再測試（施加價值，而非紀律）。他的做法是不再規定順序，而是強制落實結果；如果有人曾經測量過，這正是上方數據會建議的替代方式。

同一問題的因果版本（ExecCritic，2026-09）#

上述兩種切法都是以觀察方式衡量測試品質——廣度、目標關聯性、涵蓋率——只觀察已合併 PR 中發布的測試，沒有人為此操弄任何變因。ExecCritic（Tao、Peng、Wang 等人，Microsoft Research／UW-Madison，arXiv 2609.09133，empirical）則進行受控版本的實驗：固定 SWE-bench Verified 上的 Repair 代理程式，只替換它接收測試回饋的來源。結果為「測試品質很重要」提供觀察性涵蓋率數字無法提供的方向與幅度：未訓練的 Qwen Test 代理程式所產生的測試，讓解決率低於不使用測試的基準（61.2% → 57.3%）；GPT-5.6-sol 產生的測試則讓解決率升高（→ 65.3%），Oracle fail-to-pass 測試又進一步提升（→ 69.4%）。接著，角色專屬 RL 將 Test 代理程式自身的可靠性（以 Base-to-Gold 成功率衡量，是「這項測試是否真的表達出問題」在儲存庫層級的對應指標）從 22.2% 提升到 62.2%；將訓練過的 Test 和 Repair 代理程式組合後，即使評估時沒有更強模型或 Oracle 回饋，也能達到 72.6%。

這為「廣度是內在屬性，目標關聯性是相對屬性」再加入第三個面向：可靠性——測試的通過／失敗判定是否對應真正的缺陷，而非對問題的錯誤或不完整解讀；可靠性而非廣度，才決定下游修復迴圈能否從測試中受益。這也為上文「兩項研究都沒有人工基準」的保留條件提供訓練階段的對應例子：ExecCritic 同樣沒有人工測試品質組，但它缺少的是另一項更關鍵的比較——研究沒有測量 ExecCritic 式角色分離是否會改變 Jhanglani 等人和 Dipongkor 等人所描述的涵蓋率或不穩定性概況，只測量測試判定是否能協助修復。

延伸閱讀#

• ExecCritic: Learn to Test, Test to Improve — 上述因果性、訓練階段的互補研究：固定 Repair 代理程式並替換 Test 來源，將「代理程式測試品質有差異」轉化成對解決率方向明確、經過測量的效應，並提供改善可靠性而非只觀察其缺失的機制（獨立生成、fail-closed harness、角色專屬 RL）

• 重振不切實際的品質工具 — 變異測試是如今可負擔、能衡量約束而非涵蓋率的儀器

• 施加價值，而非紀律 — 說明 Martin 為何強制落實結果，而非要求代理程式不會遵守的先測試後寫程式順序

• Robert C. Martin (Uncle Bob) — 實際執行這道閘門的實務工作者

• 代理程式產生程式碼的安全債 — 同一 AIDev 語料在安全面向的姊妹研究；對照群組缺陷相反，但都發現代理程式債務集中在環境／管線，而非應用程式邏輯。加上上方的涵蓋率研究，如今有三項研究從三種面向檢視同一語料家族——請參閱數量核對說明，因為 4,022 和 4,882 是不同篩選結果，並非同一批 PR

• Failures That Look Like Success — 驗證層本身的典型案例：不穩定測試在你查看的那次執行中通過，因此套件顯示綠燈，訊號卻悄悄減弱。涵蓋率研究補上更直接的情況——64.8% 的 Python 代理程式 PR 中，既有套件完全沒有執行任何變更行，因此綠燈對差異內容不是弱訊號，而是沒有訊號。失敗發生在驗證器中，這是最糟糕的地方

• Risk-Tiered Auto-Approval — 另一種合併閘門判準的代價已經量化。 StampHog 以關鍵字拒絕清單和差異大小上限為閘門；「既有測試套件涵蓋這項變更」是明顯的第三種代理指標，而上方數字顯示了它的價值：Java 有 61.5% 的變更行受到測試，Python 有 27.0%，64.8% 的 Python PR 完全沒有任何變更行受測。不過，與關鍵字拒絕清單不同，差異涵蓋率可從差異內容直接計算——具有決定性、可稽核，因此符合決定式優先層級，而非交由 LLM 否決

• 審查作為控制點 — 有測量支持的流程調整建議，而該理論的第三個調節因子大多缺乏這類證據：將審查注意力分配給錯誤處理路徑，因為無論代理程式有沒有新增測試，Try-Catch 和 Throw 的漏測率都達 81.0–86.0%。這也符合該頁現在提出的缺陷類別開放問題——未測試的錯誤處理正是注意力仍能觸及的類別，不像曾讓該方法失效的缺失 move constructor

• Agentic Technical Debt — 「隱形技術債」是本頁對同一累積機制的描述：通過的測試套件沒有透露日後需要重跑多少次，正如可運作的功能不會透露其背後建立的架構前提

• 加速反噬 — 在測試套件上測得的撰寫品質主張：斷言漂移和未模擬 I/O 都是出現在審查階段的缺陷，不穩定的套件則是 Faros 所見吞吐量上升轉為 CI／建置壅塞的具體途徑；這也部分修正了該頁對 Ng 的否定——代理程式確實拓寬了涵蓋範圍，只是也讓執行器變得不穩定

• Unproductive Self-Verification — 模型側的對應情況：Opus 5 傾向建立繁複的驗證管線，反而擠壓任務本身。兩者都是代理程式過度產出驗證產物，產量超過了可靠性

• 驗證成為新瓶頸 — 不穩定的代理程式測試是 Fung 對 CI／建置系統在新吞吐量下壅塞的警告所指的機制；她提出的「左移」建議與論文中的「生成、執行、精修」是同一項做法，都應用於代理程式自己的輸出。本頁現在也補上本頁暗示、但從未估價的成本面：CircleCI（vendor-claim）將重跑計為 Merge Efficiency Ratio（將變更合併到 main，中位數需要 3.9 個驗證週期；菁英群組則為 1.3 個），並估算 50 人開發團隊每年約有 ~$900K 的交付成本，包含代理程式在 CI 等待期間閒置所付出的「token 重新載入懲罰」——因此不穩定套件會帶來雙重帳單：測試執行器分鐘數，以及每次等待後代理程式重建脈絡所耗費的 token。本頁的機制是 empirical 且非廠商提供；那一頁的價格是廠商模型估值，兩者從未在同一群體上結合

• 在高雜訊驗證器下停止 — 說明套件品質如何成為迴圈控制參數。在程式碼驗證與修復迴圈中，測試套件就是驗證器，因此其屬性會成為 ρ₀ 和 ρ₁；不穩定測試在某次執行中拒絕正確程式碼，又在有人觸發、讓套件轉綠的重跑中放過錯誤程式碼。該頁的結果說明低區辨力驗證器會造成什麼下游代價：修復到套件通過為止的迴圈，最後可能比開始時更差，而且整個過程的接受率都在上升。這也重新詮釋了本頁「取捨，而非缺陷」的結論——廣度提高了抓到缺陷的機率，但不穩定性差異（0.44 對 0.30）降低了套件所作每項判定的區辨力，而只有後者會影響停止決策。涵蓋率研究則提供同一形式架構的極端案例：在沒有測試執行的行上，套件的誤接受率為 1，區辨力 J 為 0，因此其通過判定對這些行完全不含任何資訊——整個 Python 代理程式 PR 中有 64.8% 都是如此

• 可驗證性論題 — 這是論題遭侵蝕的案例：Karpathy 的論題認為 LLM 能自動化你可驗證的事，而測試套件是軟體的驗證器。代理程式撰寫的測試範圍廣卻不具決定性，擴大了驗證表面，同時削弱了其上的驗證訊號

• AI 生成程式碼的效能債 — 第三個姊妹研究面向，也是本頁缺乏對照群組的唯一一項：3.52M 個正式環境變更具備位元組層級的作者來源標記，也有人工撰寫的基準；研究發現 AI 帶來的額外負擔集中在資源使用和介面耦合，而非正確性。它也提供本頁主題的採用背景——Google 的 Figure 3 顯示，在研究期間大多數時間裡，AI 在測試程式碼所占比例都高於正式環境程式碼，之後才在約 63% 附近趨同，因此代理程式撰寫的測試可說是這波轉變的前鋒，而非落後者

• 遙測與問卷測量 — 這裡指出，兩項研究都缺少的人工基準不再只是單篇論文的限制，而是測量設計的問題。DX（vendor-claim）宣稱 AI 對非 AI 的對照群組在採用率 >90% 時已不再可行；AIDev 研究沒有對照群組的原因卻不同，而且能修正——以代理程式作者身分定義的語料，從建構方式上就只有一組，而採用率與此毫無關係。真正有區辨力的條件是逐項變更記錄作者來源，這也正是為何 Tran 等人在飽和採用率的人口中同時擁有兩組，而這些研究沒有

• Prototype Fidelity After Cheap Polish — 同一問題的第二個面向：原型程式碼是否具備足以演化為正式系統的測試品質

• Post-Acceptance Edit Behavior — 從管線另一端看分母問題。本頁測量進入 PR、卻沒有受測的 AI 程式碼；DECODE 測量的是完全沒有進入 PR 的 AI 程式碼——31% 的 IDE 編輯軌跡包含移除編輯，其餘內容的保留率呈雙峰分布。兩者共同涵蓋從建議到合併但未測試的存活路徑，也有本頁已指出的結構性缺口：兩者都沒有人工撰寫的對照群組，因此描述的是 AI 輔助工作的態勢，而非 AI 對人類的差異

• 從執行回饋進行 RL（RLEF） — 測試品質不再是安全網，而成為訓練訊號。RLEF 的全部獎勵都來自隱藏測試套件的判定；本頁指出代理程式撰寫的測試實際執行到的差異內容極少，這也解釋了為何該獎勵在 CodeContests 上便宜，在儲存庫中卻代價高昂

• 代理程式與廠商間的異質性 — 第四項 AIDev 研究，也是終於建立了這三項研究都缺少的人類基準的研究——810 個共用儲存庫、同一時間區間、使用固定隨機種子限制每個儲存庫的數量。它把這個基準用於安全性異味、可維護性、變動量、還原與審查行為，沒有觸及任何測試指標；測試比較仍未執行，但所需方法如今已經發表。另一項結果直接影響本頁的說法：代理程式結果的廠商間差異，大於代理程式和人類之間的差異；而本頁兩項研究都把所有代理程式合併成一個群組——因此「代理程式寫出的測試較不穩定」和「代理程式測試漏掉 86% 的錯誤處理結構」都是對一個已證明並非同質群體的整體陳述

• 代理程式貢獻下的開放原始碼 — DHH 所說受過指示的代理程式勝過中位貢獻者，談的是流程遵循（有沒有寫測試、是否說明原因），而非本頁測量的管線缺陷

開放問題#

• 論文自己的兩階段流程從未完成：0.44 對 0.30 的候選率差距在動態確認後是否仍然存在？還是代理程式測試雖包含不穩定性指標，但重複執行後並沒有顯示出更不穩定？指定的實驗（每個群組抽取 1,000 個測試，每個測試跑 100 次）可以直接釐清。
• 邊界案例廣度優勢在資料流分析後仍然成立嗎？只能辨識字面值的偵測器可能測到的是「代理程式傳入字面值、人類傳入測試夾具」，而非真實的涵蓋率差異；以變數解析或支援 pytest 的匹配解析器重跑，就能分辨兩者。
• 代理程式撰寫測試的存活率是多少？論文未來工作列出缺少的數量：後續幾個月裡，有多少代理程式測試會被刪除、重寫或標記為 @skip？如果涵蓋廣度的代價是讓人們逐漸忽略整個套件，那就毫無價值；但本研究完全沒有測量維護面向。問題尚未回答，但 2026-08-12 出現了相近的第一項刪除數字： Dipongkor 等人發現，在未改善的 Java Code+Tests PR 中，代理程式刪除的測試比新增的多——刪除 82 個、新增 31 個，比例為 2.6 倍；另外有 51.2% 只修改既有測試本體。這和本項問題的方向相反（代理程式在單一 PR 中移除既有測試，而非代理程式測試隨時間衰退），樣本也只有 64 個 Java PR，但它是這份語料首次以任何形式測量代理程式測試刪除，也讓縱向研究更容易進行：相同儲存庫已經有可用歷史記錄。
• 兩項 AIDev 研究都沒有人工基準，而且現在兩項都缺少同一種比較。 代理程式在 49.6% 的程式碼變更 PR 中加入測試變更，而它們的測試只讓 22.5–35.9% 的 Code+Tests PR 提升差異涵蓋率——但沒有人能證明同一批儲存庫中的人類 PR 表現較好。任何已合併 PR 的差異涵蓋率都能追溯計算，因此在相同 44 個有儀器支援的儲存庫中建立匹配的人類群組，是可執行的研究，而非空想；同時也能判定本頁 0.62 對 0.32 的邊界案例差距能否在考量目標關聯性的指標下維持。2026-09-22 只在方法層面獲得部分回答。 Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild（Kraishan，arXiv 2609.17598，empirical）是第一項真正建立匹配人類群組的 AIDev 研究，也公布了做法：人類 PR 只取自同時含有代理程式 PR 的 810 個儲存庫，限制在人類代理程式的活動期間（2024-12-24 至 2025-07-30），並使用固定隨機種子限制每個儲存庫的數量，避免單一專案主導結果——最終得到同一批儲存庫中的 4,027 個人類 PR 和 9,750 個代理程式 PR，其餘約 24K 個代理程式 PR 則用來保留代理程式內部的統計力。因此，這份語料的基準不再是空想：它有已發表的建構方式，也有相應成本。研究完全沒有測量測試相關指標——指標類別是安全性異味、結構可維護性、合併後變動量、還原與審查行為——因此測試存在與否的差距、差異涵蓋率差距、邊界案例差距都完全沒有變化。這項研究能為進行測試研究的人提供一項注意事項：靜態分析只涵蓋23.7% 的 PR（新增行數少於 5,000 的 Python／JS／TS 差異），而限於有儀器支援儲存庫的差異涵蓋率群組會更小。請參閱「代理程式與廠商間的異質性」。

資料來源#

• 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 中作為相同篩選成本的 23.7% 靜態分析涵蓋率。研究沒有報告測試相關指標；完整討論與唯一作者／無發表場合的來源脈絡限制請見代理程式與廠商間的異質性
• Beyond Test Presence: Assessing the Quality and Robustness of Agent-Generated Tests in Open-Source Projects — Jhanglani、Desai、Kansara 與 AlOmar（Stevens Institute of Technology，arXiv 2607.12068，2026-07-13），empirical。§II（AIDev 擷取、AST 管線、Tables III–IV 的啟發式規則）、§III.A–C（RQ1–RQ3 結果、Tables VI–VIII）、§IV（效度威脅——RQ1 的 pytest 解析承認與 RQ3 的兩階段建構論證）、§VI（未來工作：沙箱執行、以 RAG 為依據的斷言、自動模擬、縱向存活情況）
• Test Coverage Analysis of Agentic Pull Requests — Dipongkor、Baral、Lam 與 Moran（University of Central Florida／George Mason，arXiv 2607.18057，2026-07-20，ICSME 2026 初步結果），empirical。§II（AIDev v3 語料、兩種篩選條件、≥10 個代理程式 PR 的涵蓋率子集）、§III（修補程式重建、只含測試的修補擷取與反向套用、JaCoCo／pytest-cov 儀器、srcML 行分類、建置與儀器設定後樣本流失至 213／1,664 個 PR）、§IV.A + Figure 1（測試納入文氏圖）、§IV.B + Table I + Table II + Figure 2（既有測試的差異涵蓋率、成對的有／無測試比較、各結構的漏測率）、§V（實務工作者與代理程式開發者建議）、§VI（Java 小型儲存庫抽樣偏差限制）。解析狀態：docling verify: ok，沒有合併／位移／canary 旗標——但仍以本機 PDF 核對兩張表（在 上執行 pdftotext -f 4 -l 5 -layout）。Table II 的每個儲存格都相符。Table I 在 docling 格線中只有外觀受損——標題重複出現 Java／Python 欄，% Improved 分數和 p 值分散到多個額外儲存格——但沒有任何數值歸屬錯誤；每一列都與 PDF 相符，Overall 列也能由文字重現。請注意 Table II 的欄位順序是先 Python、再 Java。依照圖像雙階段規則直接檢視了 Figures 1 和 2；Figure 1 的文氏圖區域與 §IV.A 的每項文字總數一致，並提供文中未出現的各語言測試納入率（Java 248/530、Python 1,928/3,857）。有兩處內部不一致是論文自身的問題，而非解析造成： §IV.A 在 49.6%／50.4% 標題數字（以 4,387 個程式碼變更 PR 為分母）與「Java 53.0%、Python 44.3%」句子（以全部 532／4,350 個 PR 為分母）之間切換，卻沒有說明；§I 引用 Watanabe 等人 [15] 說「近三分之一合併的代理程式生成 PR 後續需要錯誤修復或重構」，§VI 對同一參考文獻則改稱「45.1% 的合併 PR 需要人工修訂」，兩者從未調和
• Uncle Bob on Software Fundamentals in the Age of AI — Robert C. Martin 與 Matt Pocock，2026-08-19（practitioner-opinion；自動字幕逐字稿）：將變異測試作為必要管線閘門，以及代理程式在接受 TDD 指示後仍會回到先寫函式再測試的觀察