編碼代理供應商異質性

資料來源#

摘要#

這個知識庫先前的每一項測量都在問：代理程式程式碼是否有別於人類程式碼。Kraishan（arXiv 2609.17598，2026 年 9 月）把問題往下一層，並發現那才是更大的效應：在還原、安全氣味、註解密度、審查延遲上，兩種商業編碼代理程式之間的差距，大於代理程式整體與人類之間的差距。論文對此的說法——「最佳與最差代理程式之間的差距（相對於相同基準的勝算比為 0.50 與 1.31）遠大於任何合併計算的代理程式與人類差距」——是關鍵主張，也直指這個知識庫幾乎每項研究都採用的合併計算方式，包括本頁相鄰的文章。

能得出這項結論，關鍵在於研究設計。37,623 個 PR 帶有來自 AIDev 語料庫的供應商標籤——33,596 個代理程式 PR（OpenAI Codex、Devin、GitHub Copilot、Cursor、Claude Code）和 4,027 個人類 PR——涵蓋 2024 年 12 月 24 日至 2025 年 7 月 30 日間的 2,807 個儲存庫，並與 58,792 筆快取的 GitHub REST 回應合併，以便進行合併後追蹤。26,283 個已合併 PR 有完整的 90 天維護觀察期。

配對的人類基準，以及它的價值#

這一點超越供應商結果也很重要，因為這是本知識庫其他 AIDev 頁面所沒有的對照組。人類樣本不是「GitHub 上所有人類 PR」：只納入同時包含代理程式 PR 的 810 個儲存庫中的人類 PR，限制在代理程式的活動期間，並且以固定種子設定每個儲存庫的上限，避免單一專案占據過大比重。這樣就從同樣的 810 個儲存庫中取得 4,027 個人類 PR，與 9,750 個代理程式 PR 並列；其餘約 24K 個代理程式 PR 只用來提升代理程式間分析的統計檢定力。

這個基準有三項限制，以下都會影響部分結果：

**靜態分析涵蓋 23.7% 的 PR。**只有 Python/JS/TS 差異檔會納入氣味分析（8,933 個 PR，新增 1,348,822 行），新增行數超過 5,000 行的差異檔會排除，以免納入自動產生的內容。
審查指標完全沒有對應的人類組別。AIDev 的審查／留言／時間軸表格只涵蓋代理程式 PR，因此 RQ5 比較的是代理程式彼此之間，各組 PR 的涵蓋率從 **5.4%（Codex）到 51.2%（Copilot）**不等。
**代理程式並非隨機分配任務。**儲存庫與使用者會自行選擇要用哪個代理程式、用於哪些任務，因此每項「供應商」差異都混合了程式碼品質與任務組成。同儲存庫基準與大小分組檢查能減輕這個問題；作者也明確指出，這些方法無法將其消除。

語料庫組成（表 1，已對照 PDF 查核）#

組別	PR 數	已合併	豐富化	分析	變更行數中位數
OpenAI Codex	21,799	18,004	17,761	4,570	63
Devin	4,827	2,595	2,186	1,224	61
GitHub Copilot	4,970	2,139	3,459	1,102	76
Cursor	1,541	1,005	946	571	96
Claude Code	459	271	456	241	495
人類	4,027	3,076	3,038	1,225	52
總計	37,623	27,090	27,846	8,933	—

有兩點可以從表中讀出，論文卻未提及。合併比例從 43.0%（Copilot）到 82.6%（Codex），人類則為 76.4%——但此欄合併了 2,807 個儲存庫中全部 33,596 個代理程式 PR，而人類列則是從 810 個儲存庫抽取並設上限的基準；論文也沒有對它進行檢定，因此這只是語料庫的描述性特徵，不是受控的合併率比較。另一點是，Claude Code 的 PR 變更行數中位數為 495，其他各組則為 52–96——約為其他組的八倍；這項混淆因素在下方三項不同結果中再次出現。

還原：各供應商明顯分歧（表 2，已查核）#

人類基準為 11.5%，觀察合併後 90 天內的情況。BH 調整後的 p 值。

代理程式	n	還原率	OR [95% CI]	p
OpenAI Codex	17,756	6.1%	0.50 [0.44, 0.57]	<.001
Devin	2,185	14.5%	1.31 [1.11, 1.54]	.004
GitHub Copilot	2,094	12.5%	1.10 [0.93, 1.31]	.457
Cursor	946	11.4%	1.00 [0.79, 1.25]	1.00
Claude Code	267	10.5%	0.90 [0.60, 1.36]	.878

在測量中成本最高的結果上，兩家供應商與人類有方向相反的差異，另外三家則毫無差異。論文沒有提供合併後的代理程式還原率；將表 2 各列加權後得出 代理程式合併還原率約為 7.7%，人類為 11.5%，OR 約為 0.64（本頁自行計算，非論文數據）——而這個合併數字中有 76% 來自 Codex，正是論文所反對的平均化做法。

此處的「還原」定義。以 PR 中變更最多的檔案在 90 天內的提交訊息標記還原形式的提交。作者指出其後果：這種方法會漏掉未明確標記的重寫。實質上被還原、但提交訊息沒有標示的變更，會被計為仍然存在。

安全氣味：代理程式整體低於人類，但一家供應商遠高於人類#

新增行中出現任何氣味的比例：代理程式合併值為 2.9%，人類為 4.6%（χ²(1) = 8.59，p =.003，OR 0.63 [0.47, 0.85]）。按組別列出如下（圖 2——Devin 與 Copilot 的數值只出現在圖中，依圖讀取）：

組別	至少有 1 項氣味的 PR 比例
Cursor	1.6%
OpenAI Codex	2.5%
GitHub Copilot	2.7%
Devin	4.1%
人類	4.6%
Claude Code	9.5%

各供應商的比例相差六倍，分布跨越人類基準。以每行密度來看，結果就平淡得多——H(5) = 52.5，p <.001，但 ε² =.005，所有相對人類的成對 Cliff's δ 都是可忽略的（Codex −.02、Copilot −.02、Cursor −.03、Devin 在 p =.60 時不顯著、Claude Code +.05）。作者給出的坦誠摘要是：*「PR 進入公開儲存庫後，不同作者來源的每行氣味密度相近。」*依大小分層的檢查發現，代理程式與人類整體密度差異完全出現在 XL PR 組別（δ = −.08，p =.025），較小的四個組別則沒有差異。

依 CWE 類別區分（圖 4，代理程式合併值與人類相比），只有兩類通過 BH 校正，且兩者都有利於代理程式：硬編碼憑證（CWE-798，0.9% 對 2.2%，OR 0.39 [0.25, 0.62]，p <.001）以及 eval/exec 注入（CWE-95，0.2% 對 0.8%，OR 0.25 [0.11, 0.56]，p =.006）。沒有任何類別在代理程式程式碼中比例過高；較偏向代理程式的兩類——弱式加密（OR 1.59）與 XSS（1.47）——未通過校正，且計數偏少。按供應商來看，同一類別的比例相差四倍：Claude Code 的分析 PR 中有 3.3% 帶有硬編碼憑證氣味，高於人類的 2.2%；Codex 與 Cursor 則都只有 0.5%。

偵測器以 regex 掃描差異行，並映射到八個 CWE 類別。作者將結果稱為氣味，而非漏洞，它只是模式出現與否的上限，不代表可利用性；作者也披露，早期的路徑遍歷模式會將相對匯入字串誤判，令該類別數量膨脹約 150 倍，之後已收緊規則，只在檔案開啟呼叫內觸發。開發期間發現一個偵測器錯誤，提醒我們每個類別的計數都取決於分析工具的設計。

可維護性與合併後變更#

六組的結構性指標全都不同（差異最大的註解比例：H(5) = 868.5，ε² =.097）。以中位數來看，**Copilot（.065）、Claude Code（.076）與 Cursor（.042）會在新增程式碼中加入註解；Codex、Devin 和人類的差異檔中位數則完全沒有註解行。**Claude Code 撰寫的程式碼在結構上最複雜（巢狀層級中位數為 4 層，其他組為 3 層；分支密度為每行 .063）——這與其 495 行的 PR 變更行數中位數一致。Dunn 成對比較：**60 項成對檢定中有 44 項達到調整後 p <.05；每個代理程式至少在一項指標上與其他兩個代理程式不同。**沒有任何代理程式在四個面向全面勝出。

合併後變更量依 PR 大小正規化（變更最多檔案上的後續提交數 ÷ 變更行數 × 100）：

Claude Code 的變更量為所有組別最低——相對人類 δ = −.33（中等，p <.001），中位數為 0.5，而人類為 5.3。
Copilot δ = −.16（小），Cursor δ = −.08，Codex 和 Devin 與人類同一水準。
若看原始後續提交數（未依大小正規化），排序便不同：Copilot 的數值低於所有組別，包括人類（δ = −.20）；Codex 則略高於人類（δ = +.03，p =.020）。

正規化在此確實影響結果，而且有利於 Claude Code：除以 495 個變更行數，才令其結果反轉。變更量也只根據變更最多的單一檔案測量，這是為了控制成本而採用的整體 PR 變更量代理指標。

綜合變更量與還原結果，作者的結論是：在 90 天內、超過 100 星的儲存庫中，這五種代理程式都沒有造成可測量的、逐行高於同一儲存庫人類貢獻者的維護負擔。

審查投入依供應商集中，而非依作者來源#

五項審查指標在代理程式間的差異都達到 p <.001，其中效應最大的兩項是每個 PR 的人工審查數（ε² =.116）與機器人審查數（ε² =.119）：

Copilot 引來最密集的審查——平均每個 PR 有 3.6 次人工審查、0.43 次變更要求，此外也有最多機器人審查（4.0 次）。論文認為這反映它與 GitHub 自身審查介面的緊密整合。
Claude Code 等待首次人工審查的時間最長：中位數 12.6 小時，其他組則為 1–4 小時，可能是因為它的 PR 大了一個數量級。
Devin 與 Codex 的 PR 「通常只會派出一至兩次快速人工審查。」

這項發現的證據基礎最薄弱，原因在於涵蓋率：只有 5.4% 的 Codex PR 與 51.2% 的 Copilot PR有審查紀錄。用一組中二十分之一和另一組一半的 PR 計算同一指標，等於比較經過不同方式篩選的樣本，而且沒有對應的人類組別可作為基準。

這項研究推翻了哪些看法，哪些沒有#

**在這些指標、這段觀察期間與這群樣本中，預期的合併後債務並未出現。**在超過 100 星的公開儲存庫中，代理程式 PR 出現安全氣味的比例低於人類 PR；每行所需的後續處理並未增加，而且有數種情況下還更少。作者提出兩種無法區分的機制：代理程式撰寫的程式碼比較保守、像範本，或者引導代理程式的人類會分派範圍明確、規格完善的任務。無論何者，這都不是早期評論所預測的變更量爆炸——而且要注意，第二種機制根本不是代理程式本身的特性。

**值得關注的混淆因素是大小，在這份資料中它也有明確標記。**Claude Code 較高的氣味盛行率、較繁重的結構，以及較慢的首次審查，全都伴隨著 PR 大小約為其他組中位數的 8 倍。每行密度與大小分層檢查可限制混淆，卻無法消除糾纏；作者表示，若有每個代理程式的任務組成資料，才能排除此因素。在那之前，本文中的「供應商」部分其實是「人們交給這項產品的任務」的標籤——而 459 個 Claude Code PR 對上 21,799 個 Codex PR，也代表離群供應商所在的樣本格最稀疏。

延伸閱讀#

封閉迴路 AI 審查——**同一項發現從審查端得到印證，語料庫規模大 75 倍，使用的資料集也不同。**本頁檢視 37,623 個 AIDev PR 的合併後結果差異；Selvanayagam 與 Ghaleb 檢視 248,641 個 CodAGE PR 的審查設定本身——Copilot 撰寫的 PR 有 95.7% 由 Copilot 審查，而 Cursor 與 Google Jules 撰寫的 PR 自我審查率為 0.0%，因為這些產品根本沒有隨附審查工具——也檢視審查者的輸出，其中 CodeRabbit 的 refactor 占比會只因 PR 的作者不同，就從 9.7% 變到 35.0%。研究也獨立重現本頁對 Copilot 的解讀：同產品審查組有 80% 是 Copilot，與此處所提的整合介面機制一致，即 Copilot 引來最多機器人審查。兩份語料庫彼此不同，數值不可相互比較——AIDev 是從 2,807 個超過 100 星的儲存庫中精選的 33,596 個 PR；CodAGE 則是涵蓋整個 GHArchive 事件串流，並對作者端隔離 38.0%；兩者都有相同盲點，論文也明言：標籤指的是產品，不是模型
代理程式的文件行為——此頁的 PR 層級設計不受其影響，任何後續軌跡層級研究卻會遇到的供應商比較風險。Gao 與 Chen 報告各代理程式在工作階段層級的文件產生率（Claude Code 62.6%、Codex 37.2%、Cursor 0/11），接著告訴讀者不要將其解讀為行為差異：一個代理程式家族透過 shell 指令執行檔案操作，因此在擷取器學會從 apply_patch heredoc 中解析路徑之前，文件事件都不可見；在此之前，它記錄為零。他們在 §6.3 將此推廣為一般原則——任何以工具名稱為依據的語料庫分析，都會系統性低估以 shell 為核心的代理程式；跨代理程式比較量測到的是擷取涵蓋率，而非行為。本頁依據的供應商標籤加產物設計沒有同類型的風險；軌跡層級的供應商比較則會
由人類治理的技能維護——人類與 AI 軸線上同樣的合併警告：五個技能儲存庫的 AI 共同撰寫率為 62%，但按儲存庫分別是 93%／92%／16%／5%／0%；該文將其解讀為揭露及合併文化，而非 AI 使用情況。兩篇論文都引用合併後預告訊號的 Simpson 反轉結果，作為應按單位分別報告的理由
代理程式生成程式碼的安全債務——該頁第一個開放問題所要求、方向卻相反的人類對照組。Sakib 等人發現 38.9% 的代理程式 PR 帶有至少一項氣味，但沒有對應的人類組別；本研究則發現代理程式為 2.9%、人類為 4.6%。兩者差異來自分析工具與範圍，不是互相矛盾：前者研究以 LLM judge 分析 CI/Dockerfile/IaC 的高風險路徑；本研究則以 regex 分析 Python/JS/TS 的新增應用程式程式碼行。兩項研究在憑證問題上的結果也不同，值得一併保留：前者發現人類提交了 67.6% 的確實外洩憑證；此處則發現人類 PR 帶有硬編碼憑證氣味的比例為 2.2%，代理程式合併值為 0.9%——這是兩種不同測量，卻都得到同一個令人意外的方向
AI 生成程式碼的效率債務——**該文提出的閘門對程式碼辨別問題，在 monorepo 以外進行檢驗。**Google 的還原比例約為人類的 0.9 倍，研究對象是有成熟預先提交檢查、以審查為閘門的 C++ monorepo；其開放問題是，低於人類的還原比例究竟是 AI 程式碼的特性，還是 Google 閘門的效果。公開 GitHub 的閘門較弱且各不相同，並以提交訊息偵測還原：代理程式合併比例約為 0.64，各供應商範圍 0.50–1.31，Google 的 0.9 落在兩端之間。這項特性在更換樣本群體後依然存在；新資訊是供應商差異，而 Google 看不到它，因為它把所有 AI 作者來源都合併計算
加速反噬——部署後影響方面的直接反例。Faros 報告事故／PR +243%，變更量 +861%；本研究則報告代理程式合併還原率低於人類基準，五家供應商中有四家的逐行變更量不高於人類。這是第二個非供應商 empirical 來源得出這個方向的研究，也是第一個不在企業 monorepo 之外的案例。Faros 在 2026 年 9 月的後續報告讓合併計算問題更加嚴重（速度陷阱：最新 AI 工程研究的 8 項啟示，vendor-claim）：它同樣未指明工具，也未報告組成，其數據是兩個時段間的變化量——因此無論代理程式組成為何，兩個時段間的組成變化都不可見，並會被計入採用深度的效果。在該報告所述的領先前沿，有代理程式開啟 13–14% 的 PR；未測量的組成對訊號的影響，遠大於本頁已比較的那份報告
審查作為控制點——**審查端的新調節因子：PR 作者來自哪個供應商，可預測它會引來多少審查。**Copilot 每個 PR 有 3.6 次人工審查；Claude Code 首次審查的等待時間中位數為 12.6 小時。這與 Greptile 和 Goldman 在審查端的結果形狀相同——自動審查者能力取決於程式碼作者及程式碼所在的程式碼庫——如今則出現在人工審查投入上。其適用範圍受到涵蓋率（5.4%–51.2%）與缺少人類對照組嚴格限制
Risk-Tiered Auto-Approval——最直接的實務後果。依大小設定的閘門（PostHog 的 500 行／20 檔上限），按照此分布，實質上就是供應商篩選器：會放行 Codex／Devin／Copilot／Cursor 的中位數 PR，並擋下幾乎所有 Claude Code PR。這樣做是否合理，正是大小混淆因素尚未解決的問題
代理程式貢獻下的開放原始碼——維護者角度的解讀。DHH 認為代理程式貢獻是一條可免費取用、也可不理會的支流；這項研究首次提供受控數據，指出接受貢獻的代價，並表示答案取決於 PR 是由哪個代理程式撰寫
Agent-Generated Test Quality——AIDev 的姊妹分析，也兩度指出缺乏基準的問題。本研究在 AIDev 上建立配對的人類基準，並展示其成本（810 個共用儲存庫、每庫上限、固定種子）；但完全沒有測量與測試相關的量，因此測試涵蓋率比較仍未進行，不過所需方法已可參考
Same-Model Review Blindness——審查端也發現相同的「模型身分才是變數」結果。Greptile 發現高嚴重度召回率會隨審查者的模型家族變動 6–12 個百分點；本研究發現合併後結果的勝算會隨撰寫產品相差 2.6 倍。兩者都從審查的不同端主張，不應把「一個 LLM」視為單一群體
驗證成為新的瓶頸——論文結尾的建議正適用於此：「這個迴圈中的稀缺資源是人類注意力，因此研究應著重於路由和排序代理程式 PR，而不只是生成 PR。」

開放問題#

論文本身承認供應商與任務組成相互混淆——儲存庫與使用者會自行選擇使用哪個代理程式及其用途。**依任務類型調整後，Codex 與 Devin 的還原差距（OR 0.50 對 1.31）還存在嗎？**判別依據是每個 PR 的任務組成標籤，而 AIDev 沒有這類資料；作者也將其列為缺少的變數。在資料出現之前，對本頁任何「哪個代理程式比較好」的解讀，都是在解讀產品及其使用者的整體組合。
以提交訊息判斷還原會漏掉未明確標示的重寫，論文也如此指出。**有多少代理程式 PR 在功能上已被撤銷，卻沒有類似還原的提交？**可根據相同的快取資料，逐差異檔檢查合併 PR 新增程式碼在 90 天後的留存比例，以判斷低於人類的還原率究竟代表真正的留存優勢，還是代理程式程式碼被撤銷方式造成的假象。
Claude Code 的 PR 變更行數中位數是 495，而其他組為 52–96；其三項異常結果（9.5% 氣味出現率、最繁重的結構、12.6 小時審查等待）都與此同時出現。**配對 PR 大小之後，供應商間還有任何結果差異嗎？**在現有語料庫內依大小配對後重新抽樣，即足以檢驗；若結果為零，這頁大部分內容就可濃縮為 PR 大小的說明。

資料來源#

From Agent Behaviour to Agent-Friendly Documentation — Gao 與 Chen（Peking University），arXiv 2608.20195，2026-08-20，empirical。本文僅引用 §4.4.1 與表 9（各代理程式工作階段層級的文件產生率，以及作者拒絕將其解讀為行為差異）、§3.4（shell 內嵌路徑擷取錯誤），以及 §6.3（對資料集與工具建置者提出的一般警告）。依作者指示，知識庫中沒有任何地方引用其代理程式個別數據作為供應商研究結果。完整說明見代理程式的文件行為
Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild — Obada Kraishan（Texas Tech University 媒體與傳播學院），Not All Agents Are Equal，arXiv 2609.17598 v1，2026-09-12，9 頁，empirical。§3（語料庫建構、配對基準、豐富化、regex 氣味目錄、非參數設計）、§4.1 與圖 2（氣味密度與出現率）、§4.2（結構性可維護性）、§4.3、表 2 與圖 3（變更量與還原）、§4.4 與圖 4（CWE 類別）、§4.5 與圖 5（審查行為）、§6（效度威脅）。解析狀態：乾淨。表 1 與表 2 已逐格對照本機 PDF 的 pdftotext -f 3／-f 4 -layout，結果完全一致；canary-recall 20/20，沒有合併、位移、黏合或列切分標記。依圖片兩階段規則檢視了全部五張圖，並逐一對照圖說——本頁的圖片與圖說配對正確，不同於同日整理的 Goldman 解析結果。兩項來源內部註記，均非解析問題：（1）圖 5 圖說寫著「每個 PR 的平均人工審查數（右）」；但該面板繪出的是整數點（Codex 1、Devin 2、Copilot 2、Cursor 1、Claude Code 2），並加上四分位距誤差線——顯示的是中位數，而非平均數。文字中提到 Copilot 平均值 3.6，在圖中完全找不到，因此右方面板的圖說「平均」有誤。本頁沒有引用該面板的數據。（2）Devin 的 4.1% 與 Copilot 的 2.7% 氣味出現率僅見於圖 2，正文沒有提及。**來源可靠性註記，影響對整體論述的信任程度：**唯一作者來自媒體與傳播學院，而非軟體工程實驗室；這是尚未發表於會議或期刊的 arXiv 預印本，沒有期刊引用。empirical 分級仍予保留，因為資料集（AIDev）、研究設計（配對的同儲存庫基準、非參數檢定、Cliff's δ 與 bootstrap CI、FDR 0.05 的 BH 校正、已發布 63 變數的資料字典與重製流程）和統計報告都符合標準且彼此一致——但這項研究未經同儕審查，也沒有第二位作者發現圖 5 的圖說錯誤
AI-to-AI Code Reviews of GitHub Pull Requests — Selvanayagam 與 Ghaleb（ÉTS Montréal／Trent），arXiv 2608.21311，2026-08-21，15 頁，ESEM 2026 Emerging Results track，empirical。本文僅引用語料庫界線與供應商標籤的論點：§3.4 強調「產品」指可識別的代理程式 harness，而非母公司（Google Jules 與 Gemini Code Assist 分開計算；45,269 個跨產品 PR 中有 117 個屬於這類同一供應商的跨產品案例）；§4.3 與表 2 的作者代理程式同產品／跨產品組成；§5.1 與表 3 在固定審查者條件下的審查輸出差異。語料庫一致性檢查於整理時完成：本研究使用 CodAGE，不是 AIDev——資料來自整體 GHArchive 事件串流，包含 2,830,284 個以簽章歸屬的代理程式撰寫 PR；本頁則是來自 2,807 個超過 100 星儲存庫的 37,623 個 AIDev PR——因此本研究數據都不可與 Kraishan 的數據相比，也沒有任何數據被當作供應商研究結果引用。其五個表格皆已用 pdftotext -layout 核對。完整說明見封閉迴路 AI 審查