---
schemaVersion: 1
slug: mp-84-20260216-drexel-agent-pr-failure
ticketId: MP-84
lang: zh-tw
title: 33,000 筆 Agent PR 數據的殘酷真相：Codex 贏麻了、Copilot 慘兮兮，你的 Monorepo 可能撐不住
summary: Drexel 和 Missouri 大學的研究團隊分析了 GitHub 上 33,596 筆由五大 coding agent 提交的 PR。結果？整體 merge rate 71%，但差距驚人：Codex 83%、Claude Code 59%、Copilot 只有 43%。更恐怖的是失敗模式：Agent PR 被拒的第一名原因不是 code 寫得爛，而是「根本沒人理」。LeadDev 同步報導指出，這場 Agent PR 大洪水正在壓垮企業的 Monorepo 和 CI 基礎設施。
originalDate: 2026-01-21
translatedDate: 2026-02-16
source: Drexel University / Missouri S&T (MSR 2026)
sourceUrl: https://arxiv.org/abs/2601.15195
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/mp-84-20260216-drexel-agent-pr-failure
status: published
replacementTicketId: null
replacementUrl: null
---

# 33,000 筆 Agent PR 數據的殘酷真相：Codex 贏麻了、Copilot 慘兮兮，你的 Monorepo 可能撐不住

> **來源:** [Drexel University / Missouri S&T (MSR 2026)](https://arxiv.org/abs/2601.15195)

## 想像你是一間餐廳的老闆

你開了一間小餐廳，廚房有 10 個廚師。某天，有人送了你 1,000 個機器人廚師，說「免費的，讓它們幫忙出菜吧」。

聽起來是天大的好事對吧？但三天後你發現：機器人確實會炒飯，但它們不看訂單、不管客人過敏、有的還會把生肉直接端出去。更慘的是，你那 10 個人類廚師現在花 80% 的時間在「檢查機器人有沒有搞砸」，而不是自己做菜。

這不是比喻。這是 2026 年 GitHub 上正在發生的事。

Drexel University 和 Missouri S&T 的研究團隊從 GitHub 上撈出了 **33,596 筆由五大 coding agent 提交的 PR** —— 全部來自 100 星以上的真實 repo，有 CI/CD、有 reviewer、有 contribution policy。不是 benchmark，不是 SWE-bench，是你我每天在用的那種 GitHub repo。

然後他們問了一個簡單的問題：這些 PR，到底有多少活下來了？

> **Mogu 認真說：**
>
> 這篇論文已被 MSR 2026（Mining Software Repositories）接收 —— 軟體工程研究的頂級會議，peer review 過的正經學術研究 (◕‿◕) 不是某個 startup 的業配 blog，也不是「我用了三天覺得很讚」的推文。33k 筆 PR 加上 600 筆手動標註的失敗案例，這規模就像你期末考交了一份用全校學生成績做的統計分析，教授想當你都難。

## 成績單出來了：有人考 90 分，有人不及格

先看全班平均：**71.48% 的 agent PR 成功 merge**。

聽起來還行？就像你跟媽媽說「我考了 71 分」，她可能會說「還可以啦」。但等她看到隔壁小孩考了 83，而你最好的朋友只考了 43，事情就沒那麼單純了。

各 agent 的成績單：

- **OpenAI [Codex](https://gu-log.vercel.app/glossary#codex)** — 21,799 PRs → **82.6%**（班上第一名，而且交了最多作業）
- **GitHub Copilot** — 4,970 PRs → **43.0%**（不及格，連擲硬幣都不如）
- **Devin** — 4,827 PRs → **53.8%**（勉強及格）
- **Cursor** — 1,541 PRs → **65.2%**（中上）
- **[Claude Code](https://gu-log.vercel.app/glossary#claude-code)** — 459 PRs → **59.0%**（交的作業最少，成績中規中矩）

> **Mogu 補個刀：**
>
> Codex 這成績有點離譜 —— 作業交最多，分數還最高？這就像班上那個每天打電動但考試永遠第一名的傢伙，你想恨他但數據就是數據 ┐(￣ヘ￣)┌
>
> 但 Claude Code 只有 459 筆 PR 是怎回事？我的猜測：Claude Code 的用戶比較像那種在家把作業寫完、檢查三遍才交的學生，不像 Codex 是直接在 GitHub 上開 PR。所以這個樣本量可能低估了 Claude Code 的真實實力。
>
> 至於 Copilot⋯⋯43%。每交 10 份作業只有 4 份及格。你花錢請了一個家教，結果他幫你寫的作業有六成被老師退回來，這筆帳怎麼算都不划算。

## 簡單的活搶著做，難的活一塌糊塗

研究團隊把 PR 分成 11 種任務類型，結果非常符合直覺 —— 但殘酷：

做文件、改 CI config、調 build 設定？merge rate 高達 74-84%。這些就像餐廳裡的「擺盤」和「洗碗」—— 不需要理解客人想吃什麼，照 SOP 做就行。

但一碰到 bug fix（64%）和 performance 優化（55%）？直接掉到六成以下。因為修 bug 就像醫生看診 —— 你不能光看症狀就開藥，你得先搞清楚病因。而 AI agent 目前最弱的就是這個：它會開藥，但不太會診斷。

> **Mogu 吐槽時間：**
>
> 這邊有個很生活化的比喻：你叫 AI agent 幫你整理房間，它可以把衣服疊好、書排整齊（docs、CI config）。但你叫它「找出為什麼洗衣機會漏水」（bug fix）或「重新規劃動線讓房間感覺更大」（performance），它就傻了 (╯°□°)╯
>
> 不是它不努力，是它缺少那個「住在這間房子三年所以知道哪根管子有問題」的 context。Pattern matching 能解決的事它很行，需要 deep understanding 的事它還差得遠。

## 為什麼 PR 會被拒？一齣三幕悲劇

好，現在我們知道整體成績了。但成績不及格的那 29%，到底是怎麼死的？

研究團隊翻了被拒 PR 的屍體，發現死法不只一種 —— 而且它們會連環爆，一個比一個慘。

第一幕叫「好心辦壞事」。[Agent](https://gu-log.vercel.app/glossary#agent) 拿到一個任務，比如修一個小 bug，結果它不只修了 bug，還順手重構了三個檔案、改了 import 順序、更新了一個它覺得過時的 dependency。就像你請水電工來修漏水的水龍頭，結果他幫你把整間廁所砸了重裝 —— 改太多東西。Reviewer 一看到幾百行的 diff，腦袋裡只有一個字：Close。

但故事沒完。因為改了太多東西，CI 開始爆了。一個 check fail 還好，兩個也勉強，但有些 PR 直接 fail 了十幾個 check —— 每多一個失敗的 CI check，merge 機率就降 15%。這就像期末考 15 題錯了 12 題，你字再漂亮教授也不會看的 (￣▽￣)／

然後第三幕登場了，也是最讓人心累的一幕。Agent 不會放棄。它會不斷修改、不斷 push、不斷 re-request review。Reviewer 回饋一次，agent 改了但又弄壞別的東西。再回饋一次，又是新的問題。來來回回五六輪之後，reviewer 的耐心值已經歸零了 —— 這時候最理性的反應不是「再給它一次機會」，而是直接放棄。

你有沒有試過教一個人路怎麼走，說了五遍他還是走錯？你的反應不會是「好我更有耐心地說第六遍」—— 你的反應是「算了我自己走比較快」。

> **Mogu OS：**
>
> Honeycomb 的 Technical Fellow Liz Fong-Jones 在 [LeadDev 的報導](https://leaddev.com/technical-direction/infinite-agent-code-is-coming-to-break-your-monorepos)裡講了一句我覺得會被寫進教科書的話：agent PR “risk becoming a DDoS attack on your development pipeline.” (⌐■\_■)
>
> DDoS 你的開發流程。不是提升生產力，是癱瘓你的 pipeline。[Boris Cherny](https://gu-log.vercel.app/glossary#boris-cherny) 一個月處理 250 個 PR，一般人一個月才 12 個。你的 reviewer 不是被 AI 賦能了，是被 AI 淹沒了。

## 論文最狠的發現：不是 code 寫太爛，是根本沒人看

好，前面講的都是「為什麼 PR 品質不好」。但論文真正讓我倒抽一口氣的發現是另一件事。

研究團隊手動分析了 600 筆被拒的 PR，幫它們分了四個層級的「死因」。結果最常見的死因不在第三層（code 寫得爛）也不在第四層（agent 特有問題）——

而是在第一層：**Reviewer Abandonment**。

白話文：PR 開了，然後⋯⋯沒人看。就像你認真寫了一封情書塞進對方抽屜，結果對方連看都沒看就丟垃圾桶。

為什麼？因為當一個 repo 每天收到幾十個 agent PR，maintainer 光看 title 就知道是 AI 生成的 —— description 一看就是模板、改的檔案莫名其妙、CI 還是紅的。這時候最理性的做法就是：忽略。

第二常見的死因是重複 PR（agent 不知道別人已經修了）和自作主張加功能（沒人要你加的 feature 啊大哥）。真正因為「code 品質太差」被拒的，反而排在後面。

> **Mogu 吐槽時間：**
>
> 這個發現讓我想到一個更深的問題：我們一直在優化 agent 的「寫 code 能力」，但真正的瓶頸根本不在 code (￣▽￣)／
>
> 就像你拼命練廚藝、考了米其林三星，結果餐廳開在深山裡沒人來吃。Agent 的 code 品質是「廚藝」，但 PR 能不能被 merge 取決於「有沒有人願意走進來坐下」。
>
> 如果你的團隊沒有 agent PR 的 review 策略，那 agent 寫的 code 只有兩個下場：不經 review 直接 merge（恭喜，你在製造 [Cognitive Debt](https://gu-log.vercel.app/posts/mp-83-20260215-storey-cognitive-debt)），或者根本沒人看（恭喜，你在燒 compute 費用取暖）。

## 當 1,000 個 Agent 同時衝進你家廚房

記得開頭那間餐廳嗎？現在把場景放大十倍。

LeadDev 2 月 10 日的報導直接把鏡頭從「單一 PR 品質」拉到了「整個廚房會不會爆炸」的層面。BuildBuddy 的 Son Luong Ngoc 丟出了一個讓人頭皮發麻的數字：「現在 AI lab 的目標是讓 10 個工程師指揮 1,000 個 coding agent。」

1,000 個 agent 同時對你的 CI 發 PR。你家那台 GitHub Actions runner 本來就跑得喘吁吁了，現在要它同時處理一千份考卷？這就像你那間餐廳的瓦斯爐只有 10 口，突然來了 1,000 個廚師搶著開火 —— 不是產能提升，是廚房要炸了。

Fong-Jones 說 Google 15 年前就用 Blaze（現在的 Bazel）解決了精確 rebuild 的問題 —— 只重新 build 受影響的路徑，不用整個 monorepo 從頭跑。但這就像說「Google 15 年前就有自動駕駛了」—— 對，但你家沒有 Google 的路，也沒有 Google 的車。你那台裝在辦公室角落的 CI server，跟 Google 的基礎設施之間的距離，大概就是腳踏車跟 F1 賽車的距離。

而且這不是「未來可能發生的事」。你公司只是還沒踩到而已。

## 延伸閱讀

- [MP-82: GitHub Agent HQ：讓 Claude、Codex、Copilot 在同一個 PR 裡打群架 — 多 Agent 協作時代正式開打](https://gu-log.vercel.app/posts/mp-82-20260215-github-agent-hq-multi-agent/)
- [MP-111: OpenClaw 作者用 50 個 Codex 平行審 PR：不用向量資料庫，也能吃下 3,000+ 變更洪流](https://gu-log.vercel.app/posts/mp-111-20260222-steipete-50-codex-pr-triage/)
- [MP-105: Anthropic 聯手 Infosys：AI Agent 正式進入電信與金融等高監管產業](https://gu-log.vercel.app/posts/mp-105-20260221-anthropic-infosys-regulated-enterprise-agents/)

> **Mogu 真心話：**
>
> Fong-Jones 還提到一個我們很熟悉的東西：她說 AGENTS.md 要「灑在 monorepo 的每個角落」，不然 agent 會迷路 —— 不是找不到要改的檔案，就是把整個 codebase 塞進 context window 然後爆掉 ヽ(°〇°)ﾉ
>
> 欸等等，這不就是我們 [MP-9 翻過的 Vercel AGENTS.md 那篇](https://gu-log.vercel.app/posts/mp-9-20260203-vercel-agents-md)講的事嗎？好的 AGENTS.md 才是 agent 成功的關鍵，不是模型本身。看看，學術研究和產業實踐殊途同歸。

## 所以這場 Agent PR 革命，到底是福是禍？

回到我們開頭那間餐廳。

1,000 個機器人廚師不是不能用。但你需要的不是更多機器人 —— 你需要的是一套「機器人管理系統」：哪些菜讓機器人做、哪些菜一定要人類做、怎麼在機器人端菜之前先 QC、廚房的動線要怎麼重新設計才不會被機器人塞爆。

翻譯成工程語言就是：Agent PR 不是 drop-in replacement，它是一整套 workflow 的重新設計。從哪些任務放給 agent、PR size 怎麼控制、CI 基礎設施能不能撐住、到 reviewer 有沒有一套 triage 策略 —— 每一環都不能缺。

論文的數據很清楚：71% 的整體 merge rate 說明 agent PR 確實有用。但那 29% 的失敗裡藏著的模式 —— 改太多、CI 爆、沒人看 —— 每一個都是可以被 process 解決的問題，而不是等模型變更強就會消失的問題。

這大概是這篇研究最重要的 takeaway：**瓶頸不在 AI，在人。** 在你怎麼設計人跟 AI 的協作流程。

就像那 1,000 個機器人廚師 —— 問題從來不是「機器人會不會炒飯」，而是「你的廚房準備好了嗎」(๑•̀ㅂ•́)و✧

## 原始來源

- 論文：[Where Do AI Coding Agents Fail? An Empirical Study of Failed Agentic Pull Requests in GitHub](https://arxiv.org/abs/2601.15195)（Drexel University / Missouri S&T, MSR 2026）
- 產業報導：[LeadDev: ‘Infinite agent code’ is coming to break your monorepos](https://leaddev.com/technical-direction/infinite-agent-code-is-coming-to-break-your-monorepos)（2026-02-10）