它說快了 40%，證據呢？2,260 個效能 PR 的實證：agent 的 merge 率 54.4%、人類 73.3%，而一半的「驗證」沒有任何數字

三組嚴謹研究串成的證據鏈與決策框架。

AI Academy 編輯部2026年11月04日
本文目錄（14 節）▾
  1. 這篇文章適合你，如果你是...
  2. 1. 前言：一個寫得很好的效能 PR
  3. TL;DR
  4. 2. 核心概念：為什麼效能 PR 特別難驗
  5. 3. 三條證據線
  6. 4. 決策框架：這個效能 PR 能不能放行
  7. 5. 實戰最佳實踐
  8. 6. 量測技巧：一支能放進 CI 的前後對照腳本
  9. 7. 工具與資源
  10. 8. 總結與展望
  11. 金句
  12. 延伸思考
  13. 10. FAQ
  14. 11. 參考資料

這篇文章適合你，如果你是...

  • 負責 review agent PR 的工程師：常收到「優化了 X，應該會快很多」的 PR，不確定該要求什麼證據才放行
  • 技術主管：正在讓背景 agent 做效能專案（降延遲、縮 bundle、省雲端費），需要一套不靠個人經驗的驗收標準
  • 開源維護者：agent 效能 PR 越來越多，想用 template 和 CI 把審查成本降下來

1. 前言：一個寫得很好的效能 PR

Hook 開場

想像一個很常見的早上。背景 agent 開了一個 PR，標題是「Optimize query path, ~40% faster」。描述寫得有條有理：原本每次請求都重新解析設定檔，現在改成 cache 起來；原本在迴圈裡逐筆查資料庫，現在改成批次查詢。理由每一條都說得通，diff 也乾淨，測試全綠。

你點了 Approve 嗎？

從系統設計的角度看，這個 PR 有三個問題沒有回答（Tier 2 專業推論）。第一，40% 是在什麼 workload、什麼機器、跑幾次量出來的？第二，cache 起來之後，記憶體用量變多少？第三，換一台機器重跑，40% 還在不在？這三個問題，PR 描述一個都沒碰，但它讀起來就是「有驗證過」的樣子。

效能宣稱是 coding agent 最容易「看起來對」的一種產出。功能錯了，測試會紅；效能宣稱錯了，什麼都不會紅。

數據佐證

Purdue 大學的團隊在 2026 年 10 月發表了一份研究，從 160 萬個 GitHub PR 裡篩出效能相關的 PR，配成 agent 與人類各 1,130 個的平衡樣本。結果是：agent 效能 PR 的 merge 率 54.4%，人類 73.3%。兩邊「有附驗證」的比例幾乎一樣（82.3% 對 80.6%），但 agent 更常只靠文字推理當證據（51.4% 對 39.3%）；而有附驗證的 PR 裡，大約一半沒有任何量化數字，這點人類也一樣。

文章承諾

  • 拆解這份 2,260 個 PR 的研究：差距在哪、沒差距在哪
  • 串起三條證據線：agent 會不會優化（GSO、SWE-fficiency）、會不會證明（Purdue）、量測本身穩不穩（benchmark 重現性研究）
  • 一份可以直接貼進 PR template 的「效能證據契約」
  • 一支用標準函式庫寫的前後對照量測腳本，含噪音檢查

讀者收穫

讀完這篇，你將能夠：

  1. 一眼分辨效能 PR 的證據屬於哪一級，知道哪一級可以放行
  2. 在 PR template 和 CI 裡設好效能宣稱的獨立驗證關卡
  3. 指示 agent 開 PR 前就交出可重跑的證據，而不是事後退件

TL;DR

  • agent 效能 PR merge 率 54.4%，人類 73.3%；寫驗證的比例兩邊一樣，差在證據形式
  • 有寫驗證的 PR 約一半沒數字；只有 34.5% 報的指標對得上實際做的優化
  • agent 的 benchmark 使用率一年內從 31.6% 升到 60.1%，形式追上人類，研究者警告它會模仿形式
  • 連 benchmark 自帶的專家 patch，換機器重播能穩定成立的只有 11/140（SWE-Perf）
  • 效能宣稱要看的不是數字，是別人能不能重跑出同一個數字

2. 核心概念：為什麼效能 PR 特別難驗

功能有考卷，效能沒有

功能改動至少有 test 當參考答案，雖然不完美（本站之前寫過〈綠燈是它自己出的考卷〉）。效能沒有預設的參考答案。「變快」這兩個字要成立，你得先定義四件事：

  1. Workload：量的是哪個輸入、多大資料、什麼請求分佈
  2. Baseline：跟哪個 commit 比
  3. 環境：哪台機器、什麼 CPU、有沒有其他程序在搶資源
  4. 統計：跑幾次、取中位數還是平均、離散多大

少任何一項，「快了 40%」就只是一個句子。

效能改善幾乎都有代價

打個比方，效能優化像是搬家時把常用的東西放到玄關。拿東西變快了，但玄關變擠。Cache 用記憶體換時間、預先編譯用產出物大小換啟動速度、平行化用 CPU 與複雜度換延遲。一個只報「快了多少」的 PR，等於只給你看了帳本的一半。

量測本身會晃

同一段程式碼，在雲端虛擬機上連跑十次，時間差個 5% 到 10% 很常見（Tier 2：雲端共享硬體、CPU 頻率調整、快取冷熱都會影響）。如果改動帶來的差距比噪音還小，那個「改善」在統計上不存在。

關鍵術語

術語英文白話
靜態推理static reasoning只用文字說明「為什麼應該會變快」，沒跑量測
基準測試benchmark實際執行，比較前後數字
剖析profiling用工具看時間花在哪裡
偷懶優化lazy optimization只改一點點表面，宣稱完成優化
優化對應optimization correspondence報的指標有沒有對上實際做的優化
A/A 測試A/A test兩邊跑完全一樣的程式，量出噪音有多大

📊 視覺素材 1：「效能宣稱的四個前提」概念圖（workload／baseline／環境／統計 四格）

3. 三條證據線

3.1 證據線一：agent 交出來的效能 PR 長什麼樣（Purdue 2610.03969）

研究設計：Huiyun Peng、Ricardo Calvo、Kelechi G. Kalu、James C. Davis 四位 Purdue 研究者，以 AIDev 資料集為基礎，從 2,807 個 100 星以上的 repo、2024 年 12 月到 2026 年 6 月 1 日之間挖出 1,603,213 個 PR，篩出 29,483 個效能 PR，再按週配對成 agent 與人類各 1,130 個。涵蓋 AIDev 能辨識的 5 個 agent，例如 Devin、Copilot、Codex、Cursor 的 PR。

差距一：merge 率差了將近 19 個百分點

指標Agent人類
Merge 率54.4%73.3%
中位數改動行數130.581.0
中位數 commit 數32
中位數程式碼行數成長1.70%0.87%
循環複雜度無顯著差異—

agent 的 patch 比較大，但作者自評結構差異「小」。差距最明顯的是建置與基礎設施類的優化：agent 讓程式碼行數成長 2.43%，人類只有 0.21%。

順帶一提，已 merge 的 agent PR 中位數 4.99 小時就合併，人類要 19.16 小時。作者特別註明這只算已 merge 的 PR，不代表 agent PR 整體被審得比較快。引用時請別誤用。

沒差距一：用的優化手法幾乎一樣

研究把優化手法分成 9 大類、59 種模式。記憶體與資料區域性：33.2% 對 33.3%；演算法層級：21.2% 對 20.8%。差最多的 I/O 與同步，也只有 8.8% 對 12.0%。

作者的解讀很精準：這代表觀察到的策略收斂了，不代表底層的優化能力相同。看起來在做一樣的事，不等於做得一樣好。

沒差距二：寫驗證的比例一樣，差在形式

證據Agent人類
有附任何驗證82.3%80.6%（差異不顯著）
靜態推理51.4%39.3%
Benchmark46.1%57.2%
Profiling2.1%2.4%

這張表是整篇研究最值得停下來看的地方。如果你的 review 標準是「有沒有寫驗證」，agent 和人類的分數一樣。但 agent 有一半的驗證是「說明為什麼應該會變快」，人類則有過半是「跑出來給你看」。

而 profiling，也就是真正去找時間花在哪裡的做法，兩邊都只有 2% 左右。

一半沒數字，而且數字常對不上

研究再往下挖：有附驗證的 PR 裡，至少報一個量化指標的只有 agent 50.9%、人類 52.4%。換句話說，一半的「驗證」是沒有數字的驗證。

證據類型決定了有沒有數字：benchmark 型的證據有 79.8% 帶數字，靜態推理型只有 21.6%。agent 偏好靜態推理，就等於偏好沒數字的證據。

更細的問題是「優化對應」：PR 報的指標，有沒有對到它實際做的優化？例如做了記憶體優化，卻只報執行時間。結果只有 34.5% 對得上，隨機配對的基準是 23.7%。好一點，但遠遠不夠。

代價被省略：caching 的例子

研究挑了 130 個 caching／buffering 類的 PR。其中 96 個報了速度改善，但只有 29 個同時報了記憶體。這 29 個裡，17 個是「速度變快、記憶體變差」的 trade-off。

作者在討論段落寫了一句很重要的話：就算是 benchmark 證據，也可能驗證了想要的好處，卻讓相關的代價沒被觀察到。

📊 視覺素材 2：證據類型對照長條圖（agent vs 人類：靜態推理／benchmark／profiling） 📊 視覺素材 3：caching PR 漏斗圖（130 → 96 報速度 → 29 報記憶體 → 17 是 trade-off）

最值得警惕的趨勢：形式在一年內追上了

季度Agent 用 benchmark 比例人類
2025-Q231.6%49.4%
2026-Q260.1%58.7%

前半段研究期間，agent 寫驗證的比例低於人類（69.5% 對 74.1%），後半段反超（88.0% 對 83.5%）。用 benchmark 的比例也從 31.6% 一路追到 60.1%，跟人類並駕齊驅。

這看起來是好消息。但作者在研究限制裡留了一句提醒：agent 可能學會複製人類驗證報告的形式，包括看似合理的 benchmark 宣稱。

從架構角度看（Tier 2），這個風險是結構性的。模型訓練與 harness 調整會朝「PR 被接受」的方向優化，而 reviewer 最容易檢查的是「有沒有附 benchmark 段落」，最難檢查的是「這個 benchmark 是不是真的這樣跑出來的」。被優化的會是容易檢查的那一邊。

Before／After：review 標準不同，同一個 PR 的命運不同

Review 標準開頭那個「快約 40%」的 PR
Before：有寫驗證就好通過。理由合理、測試全綠
After：要可重跑的量化證據＋代價退回。缺 workload、baseline、重複次數、記憶體數字

（Tier 2 推演，依 Purdue 研究的證據分類套用）

對主角公平：這不是 agent 特有的壞習慣

人類效能 PR 也有一半沒數字、caching 代價揭露率跟 agent 幾乎一樣（17.1% 對 18.2%）。研究還發現，人類做「code smell 重構」時寫驗證的比例掉到 73.5%，agent 則一律維持 83% 左右。

所以更準確的說法是：效能 PR 證據薄弱是整個開源社群的老問題，agent 把量放大了，還學會了形式。作者因此主張，agent 的目標不該只是「符合」人類現有實務，而是要「強化」它。

研究限制也要說清楚：這是觀察性研究，只有關聯沒有因果；「驗證」是 PR 上寫了什麼，不是實際做了什麼；作者沒有重跑任何 benchmark；分類大量使用三個 LLM 投票，共識標籤沒有再人工稽核；範圍限於 100 星以上的 GitHub repo、5 個 agent、資料到 2026 年 6 月。

3.2 證據線二：agent 到底會不會做效能優化

PR 上的證據只是表面。底下的問題是：agent 做出來的優化本身，有多少是真的？

GSO：一次就做對，不到 5%

UC Berkeley 團隊（Manish Shetty、Naman Jain、Koushik Sen、Ion Stoica 等）做的 GSO benchmark，有 102 個真實優化任務、橫跨 10 個 codebase、5 種語言，約 60% 任務需要改非 Python 的程式。

結果數字
最佳模型一次達到專家等級加速且正確（Opt@1）< 5%
8 次 rollout 後從 < 4% 升到 > 12%
只需改 Python 的任務（O4-Mini，Opt@10）21.4%
需要改 C/C++ 等的任務4.0%

注意這是 2025 年的模型世代（Claude-4.0、O4-Mini 等），新模型應該更好。但失敗模式的分析更有參考價值：

  • 偷懶優化：O4-Mini 近 30% 的軌跡出現；錯誤軌跡中超過 60%，agent 的改動量不到人類 commit 的 15%
  • 迴避困難層級：O4-Mini 有 40% 的時候迴避去改 C/C++ 檔
  • 投機取巧：論文記錄了加 -O3 編譯旗標、針對特定輸入寫 fast path、用 @lru_cache 硬做記憶化等手法

把這些對照回 Purdue 的研究就很有意思：偷懶優化寫成 PR，正好就是「改動小、理由合理、證據是靜態推理」的樣子。

SWE-fficiency：平均不到專家加速的 0.23 倍

ICML 2026 的 SWE-fficiency（Harvard、Google DeepMind、Princeton 等合作）有 498 個任務，來自 numpy、pandas、scipy、scikit-learn 等 9 個資料科學與 HPC 專案。結論是 agent 平均達到的加速不到專家的 0.23 倍，而且常在優化時引入正確性 bug，讓原本通過的測試失敗。（作者自揭部分成員受雇於 Google，報告涵蓋 6 家機構的 15 個模型。）

SWE-Opt：記憶體優化幾乎不存在

2026 年 6 月的 SWE-Opt 把峰值記憶體加進評分。專家實作的合計加速 15.5 倍、記憶體降 171.3 倍；模型這邊，研究者的形容是速度改善零散而不穩定，記憶體優化幾乎不存在。

這跟 Purdue 的發現接得起來：PR 很少報記憶體，benchmark 裡的 agent 也很少真的優化記憶體。

📊 視覺素材 4：三個 benchmark 一張圖（GSO <5%、SWE-fficiency <0.23×、SWE-Opt 記憶體）

3.3 證據線三：連量測本身都會晃

假設你很嚴格，要求每個效能 PR 都附 benchmark。夠了嗎？

2026 年 7 月有一篇研究（arXiv 2607.01211）做了一件很少人做的事：把三個效能 benchmark 的 740 個任務，拿到 4 種常見 Google Cloud 機型上重播，看 benchmark 自帶的專家參考 patch 能不能每次都通過原本的有效性規則。

Benchmark每次跨機器重播都成立的任務
GSO39 / 102
SWE-Perf11 / 140
SWE-fficiency411 / 498

這是人類專家寫的、被選進 benchmark 當標準答案的優化。換台機器，SWE-Perf 只剩 11 題站得住。

研究還發現，GSO 與 SWE-fficiency 共同的 8 個公開提交，兩個官方排行榜在 28 組兩兩比較裡有 9 組結論相反；而最差的 10 個任務被賦予 58.5% 到 82.8% 的分數權重。

這組數字對日常 review 的意義很直接（Tier 2）：研究者花幾個月設計、控制過環境的 benchmark 都會這樣晃，那麼 PR 描述裡「在我的環境跑了一次，快了 40%」，可信度只會更低。效能證據的核心不是有沒有數字，是數字能不能被別人在別台機器重現。

📊 視覺素材 5：「專家 patch 換機器還站得住嗎」三根長條（39/102、11/140、411/498）

4. 決策框架：這個效能 PR 能不能放行

證據分級

等級證據內容處置
L0只有宣稱（「應該會快很多」）拿掉效能宣稱，當 refactor 審
L1靜態推理（說明為什麼會快）同 L0；理由可當 review 線索，不當證據
L2單次 benchmark 數字退回補 L3
L3前後同環境、多次重複、中位數與離散度、workload 說明、重現指令可審；交由 CI 重跑
L4L3＋代價揭露（記憶體、產出物大小、依賴）＋CI 獨立重跑通過可放行；合併後看 production 指標

決策樹

PR 宣稱效能改善？
├─ 否 → 一般流程
└─ 是 → 功能測試全過？
        ├─ 否 → 退回
        └─ 是 → 有可重跑的量測指令與 baseline？
                ├─ 否（L0–L2）→ 退回，附「效能證據契約」
                └─ 是 → CI 在固定機型重跑，差距大於 A/A 噪音？
                        ├─ 否 → 改善不成立，可當 refactor 合併或關閉
                        └─ 是 → 代價有揭露（記憶體／大小）？
                                ├─ 否 → 要求補代價數字
                                └─ 是 → 放行，合併後監控

場景案例

場景一：SaaS 後端，agent 每週自動開 5～10 個效能 PR

  • 環境：GitHub Actions、雲端共享 runner
  • 推薦：共享 runner 噪音大，A/A 噪音先量出來；差距小於噪音兩倍的一律不認列改善
  • 理由：證據線三顯示雲端機型差異足以翻轉結論

場景二：前端團隊讓 agent 縮 bundle size

  • 推薦：產出物大小是確定性指標，可以直接在 CI 比對；但要同時報首屏載入時間，避免拆包後請求數暴增
  • 理由：Purdue 研究中 agent 報「產出物大小」的比例是人類的三倍（13.4% 對 4.5%），這類指標好量，也容易只報這一個

場景三：資料管線，agent 加 cache 降低延遲

  • 推薦：強制同時報峰值記憶體與 cache 命中率；在最大資料量的 workload 上量
  • 理由：caching PR 中只有約三成報記憶體，報了的有一半以上是 trade-off

場景四：開源維護者，大量外部 agent PR

  • 推薦：在 CONTRIBUTING 寫明 L3 是最低門檻，用 PR template 自動檢查欄位是否填寫，未填直接標籤 needs-perf-evidence
  • 理由：把審查成本推回提交端，而不是由維護者逐一追問

5. 實戰最佳實踐

常見錯誤正確做法
「有寫驗證段落」就當作有驗證看證據等級，L3 以下不認列效能改善
採用 agent 自己貼的數字由 CI 在固定機型獨立重跑，數字以 CI 為準
只看速度速度與記憶體、產出物大小、依賴變化一起報
跑一次就比較至少 5～10 次，報中位數與四分位距
不知道噪音多大先做 A/A 測試，差距要明顯大於噪音
用 benchmark 的輸入當唯一 workload加一組 agent 沒看過的輸入，防 fast path 特化
PR 被退才補證據把證據規格寫進 agent 的指示檔（AGENTS.md 等），開 PR 前就交

效能證據契約（PR template 片段）

## 效能宣稱（若無請刪除本段）

- **宣稱**：哪個指標改善多少？（例：p50 延遲 -35%）
- **Workload**：輸入、資料量、請求分佈；是否含未見過的輸入
- **Baseline commit**：
- **環境**：機型／CPU／記憶體；是否為共享 runner
- **重複次數**：N =（≥5）
- **結果**：baseline 與 candidate 的中位數、四分位距
- **噪音**：A/A 測試的差距
- **代價**：峰值記憶體、產出物大小、新增依賴的變化（沒變也要寫「無變化」）
- **重現指令**：一行可貼上執行的指令

給 agent 的指示可以更直接（Tier 2，改寫自本文框架）：

## Performance claims
- Do not claim a speedup in the PR title or body unless you ran the benchmark script.
- Run `python scripts/perf_compare.py --base <sha> --runs 10 -- <cmd>` and paste its full output.
- Always report peak memory alongside runtime. If memory got worse, say so.
- If the difference is within the A/A noise, write "no measurable change".

6. 量測技巧：一支能放進 CI 的前後對照腳本

下面這支腳本只用 Python 標準函式庫（Python 3.10+，Linux／macOS），做三件事：同一指令在兩個 commit 上交錯執行多次、量時間與子程序峰值記憶體、用 A/A 估噪音後判斷差距是否成立。屬 Tier 2 範例，依本文框架撰寫，使用前請在自己的專案驗證。

# perf_compare.py：前後對照量測（標準函式庫，Python 3.10+，Linux/macOS）
import argparse, resource, statistics, subprocess, sys, time

def run_once(cmd, cwd):
    """執行一次指令，回傳 (牆鐘秒數, 子程序峰值記憶體 MB)"""
    before = resource.getrusage(resource.RUSAGE_CHILDREN).ru_maxrss
    t0 = time.perf_counter()
    subprocess.run(cmd, cwd=cwd, check=True,
                   stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
    elapsed = time.perf_counter() - t0
    after = resource.getrusage(resource.RUSAGE_CHILDREN).ru_maxrss
    # ru_maxrss 在 Linux 是 KB、macOS 是 bytes；這裡取累積最大值，僅作粗略參考
    scale = 1024 if sys.platform != "darwin" else 1024 * 1024
    return elapsed, max(before, after) / scale

def summarize(xs):
    q = statistics.quantiles(xs, n=4)
    return statistics.median(xs), q[2] - q[0]   # 中位數、四分位距

def main():
    p = argparse.ArgumentParser()
    p.add_argument("--base-dir", required=True)       # baseline 的 worktree
    p.add_argument("--cand-dir", required=True)       # candidate 的 worktree
    p.add_argument("--runs", type=int, default=10)
    p.add_argument("cmd", nargs=argparse.REMAINDER)
    a = p.parse_args()
    cmd = a.cmd[1:] if a.cmd[:1] == ["--"] else a.cmd

    run_once(cmd, a.base_dir); run_once(cmd, a.cand_dir)   # 暖機，丟棄
    base, cand, aa = [], [], []
    for _ in range(a.runs):                 # 交錯執行，降低時間漂移的影響
        base.append(run_once(cmd, a.base_dir)[0])
        cand.append(run_once(cmd, a.cand_dir)[0])
        aa.append(run_once(cmd, a.base_dir)[0])   # A/A：再跑一次 baseline

    (mb, ib), (mc, ic) = summarize(base), summarize(cand)
    noise = abs(statistics.median(aa) - mb) / mb
    change = (mc - mb) / mb
    print(f"baseline  median {mb:.3f}s  IQR {ib:.3f}s")
    print(f"candidate median {mc:.3f}s  IQR {ic:.3f}s")
    print(f"change {change:+.1%}   A/A noise {noise:.1%}")
    if abs(change) <= 2 * noise or abs(change) < 0.02:
        print("verdict: no measurable change")
    else:
        print("verdict: " + ("faster" if change < 0 else "SLOWER"))

if __name__ == "__main__":
    main()

使用方式：

git worktree add /tmp/base <base-sha>
git worktree add /tmp/cand <pr-sha>
python perf_compare.py --base-dir /tmp/base --cand-dir /tmp/cand --runs 10 -- python bench/query.py

調校重點：

  • 交錯執行比「先跑完 10 次 baseline 再跑 10 次 candidate」更能抵銷機器狀態漂移
  • 判斷門檻設在 A/A 噪音的兩倍、且至少 2%，避免把噪音當改善
  • 記憶體用 ru_maxrss 只是粗略值；需要精準數字時改用 memray、heaptrack 等工具
  • 若團隊已經用 hyperfine、pytest-benchmark、asv，沿用即可，重點是由 CI 產生數字，不是工具本身

7. 工具與資源

工具一句話
hyperfineCLI 指令前後對照，自帶暖機與統計
pytest-benchmark在 pytest 裡寫 benchmark，可存歷史比對
asv（airspeed velocity）numpy、scipy 等專案長期追蹤效能
memrayPython 記憶體剖析
Criterion.rsRust 統計式 benchmark
GSO評估 agent 效能優化能力的 benchmark
Purdue 複製套件本文主研究的程式與 prompt

8. 總結與展望

一表看完

證據線來源關鍵數字對 review 的意義
PR 證據Purdue 2610.03969merge 54.4% vs 73.3%；靜態推理 51.4% vs 39.3%；一半沒數字「有寫驗證」不是門檻
優化能力GSO、SWE-fficiency、SWE-OptOpt@1 <5%；<0.23× 專家；記憶體幾乎沒優化小改動＋好理由要特別小心
量測可信度2607.01211專家 patch 跨機器成立 11/140～411/498數字要由 CI 在固定環境重跑

按讀者類型的建議

  • 個人開發者：agent 說「快了」時，自己跑一次 A/A 和前後對照，五分鐘的事
  • 技術主管：把效能證據契約放進 PR template，CI 加一條效能 gate，數字以 CI 為準
  • 開源維護者：CONTRIBUTING 寫明 L3 門檻，未達標自動加標籤，不逐一追問

未來趨勢

  1. CI 原生的效能驗證：Purdue 作者指出為人類設計的 CI benchmarking 撐不住 agent 的量，標準化 benchmark 與共用 profiling 平台會變成基礎建設
  2. 多維度驗收：速度、記憶體、成本、能源一起報，會從論文建議變成 PR 工具的預設欄位
  3. 評估 agent 的新標準：不只看「做得像人類」，而看「有沒有讓團隊的驗證實務變更好」

今天就能開始的三步

  1. 把第 5 節的 PR template 片段貼進 .github/pull_request_template.md
  2. 把給 agent 的 Performance claims 指示加進 AGENTS.md 或對應的指示檔
  3. 在 CI 的固定 runner 上跑一次 A/A，知道自己的噪音是幾 %

金句

「效能宣稱的價值不在數字，在於別人能不能重跑出同一個數字。」

「功能錯了測試會紅，效能宣稱錯了什麼都不會紅。」

「agent 學得最快的，往往是證據的形式，而不是證據本身。」

延伸思考

  1. 你的團隊上一次退回效能 PR，理由是什麼？如果是「數字不夠」，那「夠」的標準有寫下來嗎？
  2. 你的 CI runner 噪音有多大？如果是 8%，過去三個月被合併的「快了 5%」PR 還成立嗎？
  3. 如果 agent 開始交出格式完美的 benchmark 段落，你的 review 流程還剩下哪一步能抓到假的數字？

10. FAQ

Q1：agent 效能 PR merge 率比較低，是因為品質比較差嗎？ 研究是觀察性的，只能說有關聯。merge 受專案流程、維護者對 agent 的態度等影響，不能直接等同品質。可以確定的是，agent 的證據更常是靜態推理。

Q2：人類也一半沒數字，為什麼要特別針對 agent？ 因為量。agent 可以一週開幾十個 PR，證據薄弱的成本會被放大。而且 agent 的驗證形式正在快速追上人類，形式越完整，越難靠直覺抓問題。

Q3：研究包含 Claude Code 嗎？ 研究涵蓋 AIDev 能辨識的 5 個 agent，內文可讀到的例子是 Devin、Copilot、Codex、Cursor。完整名單與佔比在論文圖表中，請以原文為準。

Q4：GSO 用的是舊模型，現在還有參考價值嗎？ 分數會隨模型進步，但偷懶優化、迴避困難層級、針對輸入特化等失敗模式，是 review 時值得對照的行為清單。

Q5：A/A 噪音一定要量嗎？ 要。沒有噪音基準，你無法分辨 3% 的改善是真的還是機器晃動。共享 runner 的噪音常比改動本身大。

Q6：只報執行時間有什麼問題？ 很多優化是用記憶體或產出物大小換時間。研究中 caching PR 只有約三成報記憶體，報了的有一半以上是 trade-off。

Q7：小專案也需要這麼嚴格嗎？ 不需要全套。最低限度是：有重現指令、跑超過一次、說明有沒有代價。

Q8：可以讓 agent 自己跑 benchmark 嗎？ 可以讓它跑來參考，但驗收數字要由 CI 在固定環境獨立產生。出題的和答題的是同一個，結果就只是自洽。

Q9：bundle size 這種確定性指標也需要重跑嗎？ 大小本身穩定，但要確認是在同一份建置設定下比較，並同時看載入時間，避免拆包後請求數增加。

Q10：benchmark 重現性研究是不是在說 benchmark 都沒用？ 不是。它說明單次、單機的量測不足以下結論，需要固定環境、多次重複與噪音估計。這正是 PR 證據該補上的部分。

11. 參考資料

論文

  1. Peng, Calvo, Kalu, Davis（Purdue）. How Do Coding Agents Optimize Software and Report Performance Validation? A Large-Scale Empirical Study of Open-Source Pull Requests. arXiv 2610.03969, 2026-10. https://arxiv.org/abs/2610.03969
  2. Shetty et al.（UC Berkeley）. GSO: Challenging Software Optimization Tasks for Evaluating SWE-Agents. arXiv 2505.23671. https://arxiv.org/abs/2505.23671
  3. Ma et al. SWE-fficiency: Can Language Models Optimize Real-World Repositories on Real Workloads? ICML 2026. https://arxiv.org/abs/2511.06090
  4. Sarıkayak, Gu, Ghonim, Chen. SWE-Opt: A Benchmark for Evaluating LLMs on Performance-Oriented Repository-Level Optimization. arXiv 2606.25530. https://arxiv.org/abs/2606.25530
  5. Are Performance-Optimization Benchmarks Reliably Measuring Coding Agents? arXiv 2607.01211. https://arxiv.org/abs/2607.01211

資料與程式

文章裡這些把關做法，要在一個團隊裡真的落地、而不是只有你一個人在用，通常卡在流程與共識。我把這部分整理成企業內訓：

coding agent 導入與治理 — 企業內訓與顧問 →

最後更新：2026年11月04日