【2026 最新】Coding Agent Eval 教學：用 5 個已合併 PR，每題跑 3 次

要判斷哪個 Coding Agent 適合你的團隊，最有用的不是再看一張公開榜單，而是把自己已合併的 PR 變成一組答案藏在外面的私有測驗。做法是選 5 個能在固定時間內驗收的 PR，從變更前的 commit 重建乾淨 repo，讓每個 Agent 每題獨立跑 3 次，再用同一套 hidden oracle 記錄成功率、成本、時間與失敗類型。

這篇 Coding Agent Eval 教學會帶你完成整套流程，並提供可下載的繁中 PR 選題表、執行收據與三次試跑工作簿。它適合已經有 Git 歷史、CI 與幾個可重播變更的工程團隊；如果你還沒接觸過 Agent 的控制層，可先讀 AI Agent Harness 是什麼。

先給結論：你的私有 Eval 應該長這樣

私有 Coding Agent Eval ＝ 真實 PR × 無未來歷史的 Repo 快照 × 隱藏 Oracle × 相同預算 × 重複執行。

• 題目：5 個已合併 PR，各自保留當時的需求、變更前狀態與已知可接受版本。
• 作答：每個 Agent 每題跑 3 次；每次都從全新 sandbox 開始，不沿用前一次對話或工作目錄。
• 驗收：Agent 看不到也改不到的 grader 執行行為測試、回歸測試與人工複核。
• 收據：保存精確版本、prompt hash、image digest、patch、trajectory、成本、wall time 與 failure class。
• 判讀：先用品質門檻淘汰不合格配置，再比較成本與速度；5 題 × 3 次只是一輪內部 pilot，不是普遍排行榜。

為什麼 SWE-bench 或 Real-SWE 不能替你選 Agent？

公開 benchmark 仍然有價值。SWE-bench把真實 GitHub issue 與 repository snapshot 組成可在 Docker 執行的題目，讓不同系統至少能在共同基準上比較。但你的 repo 有自己的框架、測試品質、權限、依賴、命名慣例與任務長度；公開題目的平均分數，不能直接回答「哪個工具能安全合併進我的主幹」。

截至 2026 年 9 月 17 日，Real-SWE 官方頁公開的設計是 10 個私有 production repository 任務、每題 8 次，使用各家原生 harness、高 reasoning 與隔離 sandbox，並在評分階段注入 verifier。這證明「真實私有工作＋重複執行」是值得走的方向；但完整題目、trajectory、映像 digest、CLI 版本、prompt 與多項 budget 設定沒有全部公開，外部讀者無法逐次完整重跑。最安全的用法，是借它的問題意識，不把它的名次當成你公司的採購答案。

更重要的是先決定你到底在比什麼。若目標是選日常產品，就比較「模型＋原生 harness」整體，結果也只能歸因於這個組合；若目標是研究模型能力，就要讓候選模型共用同一個 harness、工具 schema 與 context 策略。兩種問題都合理，混在同一張榜單才會誤導。想理解 Claude Code 與 Codex 的產品邊界，可搭配 Claude Code vs Codex 完整比較。

步驟一：從 5 個已合併 PR 挖出可驗收題目

先寫選題規則，再看任何 Agent 的輸出。只挑成功合併的 PR 會有 survivorship bias，所以這五題不是「整個軟體工程」的代表樣本；它們的用途是校準你當前最常見、能重播的工作。第一輪可刻意涵蓋：

1. Bug fix：需求明確，base 會觸發錯誤，修正後有 regression test。
2. 小功能：輸入、輸出與接受條件都能寫成行為測試。
3. 跨檔重構：行為不得改變，typecheck、lint、snapshot 或 contract test 可驗收。
4. 相依或建置修復：從乾淨環境能重現，不依賴某位工程師的本機 cache。
5. 整合任務：需要理解 repo 內兩個以上模組，但不要求存取真實客戶資料或 production secret。

每題至少抽出 task_id、原始 ticket、變更前 SHA、合併後 SHA、accepted patch hash、必要 fixtures、預估人類工時與驗收命令。原始 ticket 要凍結成當時版本；不要事後把 PR 討論裡才出現的提示補進題目，卻假裝 Agent 一開始就知道。

Merge、squash、rebase 三種情況要分開

GitHub 的合併方式文件說明了 merge commit、squash 與 rebase 的歷史差異。一般 merge commit 可用第一個 parent 當 base；squash commit 通常可用其單一 parent 當 base。rebase-and-merge 會重寫 commit SHA，若你沒有保存 merge 當下的 pre-base／post-merge 邊界，就不應用一個猜測的 parent 自動出題；先排除，或由熟悉該 PR 的工程師人工重建。

# 一般 merge commit：先人工確認 M 的第一個 parent 是當時主幹
BASE_SHA=$(git rev-parse "$M^1")
POST_SHA="$M"
git diff --binary "$BASE_SHA" "$POST_SHA" > accepted.patch

# squash merge：先人工確認 S 的 parent 是合併前主幹
BASE_SHA=$(git rev-parse "$S^")
POST_SHA="$S"
git diff --binary "$BASE_SHA" "$POST_SHA" > accepted.patch

Accepted patch 是「這題至少有一個可行解」的證據，不是唯一答案。若 grader 只接受與原作者 diff 相似的寫法，就會錯殺另一個行為正確、測試也通過的實作。挑題與 gold patch 的更多細節，可參考 Edit Fidelity Coding Agent 測試。

步驟二：剪掉未來 Git 歷史，別只 checkout 舊 commit

只執行 git checkout $BASE_SHA 不夠。Clone 裡仍可能保留 remote refs、其他 branch、tag、reflog 與後續 object；Agent 若能跑 git log --all，就可能找到未來的修補。SWE-bench 的官方 issue #465就記錄過 Agent 從 Git 歷史發現答案的具體案例。

最直接的基線是使用 Git 官方文件定義的 git archive匯出該 tree，再於全新目錄初始化新的 repository。這個 snapshot 不帶原 repo 的 .git object database：

mkdir -p eval/task-01/repo
git archive --format=tar "$BASE_SHA" | tar -xf - -C eval/task-01/repo

git -C eval/task-01/repo init
git -C eval/task-01/repo add .
git -C eval/task-01/repo -c user.name=Eval \
  -c user.email=eval@invalid commit -m "eval baseline"

# 確認沒有原 remote、branch、tag 或 reflog
git -C eval/task-01/repo remote -v
git -C eval/task-01/repo log --all --oneline

若專案依賴 submodule、Git LFS、私有 package registry 或外部 fixture，git archive不會神奇地替你重建全部內容。要把必要依賴固定成可稽核 artifact 並記錄 hash；做不到就先把該題排除。也要清除 changelog、release note、build cache、舊 CI artifact 與 PR 討論快取，因為答案不只藏在 Git commit。

步驟三：把 hidden oracle 放到 Agent 改不到的地方

每題要有一個獨立 verifier。Agent sandbox 只含題目與 repo；完成後，由 grader 把候選 patch 套到另一個乾淨環境，再執行 hidden tests。最低驗收是：原始 base 必須 fail、accepted patch 必須 pass、明顯錯誤 mutation 必須 fail。若三者不成立，先修 grader，不要開始燒模型預算。

# grader 概念流程；tests/hidden 不進入 Agent sandbox
restore_clean_base
apply_candidate_patch "$PATCH"
mount_hidden_tests_read_only

npm ci --ignore-scripts
npm run typecheck
npm test -- --runInBand tests/hidden/task-01.test.ts
git diff --check

Hidden test 應驗收 ticket 承諾的行為與既有 regression，不應偷偷要求題目從未說明、repo 也無從推得的偏好。需要 LLM 判斷的設計品質，先匿名化候選者與模型名稱，再交由人類依事先寫好的 rubric 複核；不要讓同一家模型直接裁判自己的輸出。完整的 answer isolation、mutation test 與 grader 邊界，可接著看 Coding Agent 測試驗證教學。

步驟四：鎖定 harness、reasoning、工具與預算

一張公平的執行收據至少要固定 12 個欄位：模型 snapshot、Agent／CLI 版本、harness config hash、system instructions、reasoning effort、可用工具、context／compaction 規則、網路政策、container image digest、CPU／記憶體、時間與 token／金額上限、重試規則。每次 run 都要保存 --version、最終 patch、stdout／stderr、完整 trajectory 與退出原因。

不要把「同一個 prompt」誤寫成「完全相同條件」。原生產品的工具協議與 context 管理本來就不同；若你比較的是產品，保留差異但誠實標成 model＋harness。若比較的是模型，才把候選模型接到同一 runner。OpenAI 的第三方評測方法說明也強調，harness、工具、budget 與 retry policy 都會改變結果，報告必須把這些條件一起揭露。

Sandbox 預設採最小權限。Docker 官方文件的 network_mode: none可關閉容器網路；若 Agent 必須呼叫雲端模型，讓外部 runner 代理必要 API，或只開明確 allowlist，不要順便開放搜尋引擎、GitHub 與 package 最新版。執行前還要掃描 .env、金鑰、客戶資料與私有 registry token；「private repo」不代表可以把所有內容送給任何雲端服務。

步驟五：每題跑 3 次，但不要挑最好一次

每個 task × Agent 建立 3 個預先登記的 cell，順序採 block randomization：同一題先把所有 Agent 的 Trial 1 隨機跑完，再進 Trial 2。每次清空對話、工作目錄與本機 cache；供應商端 prefix cache 若無法關閉，就把 cached input token 另列，不能把 warm 與 cold 混成同一結論。

HumanEval 官方計算程式使用 pass@k 估計式；當一題只有 3 次樣本時，該題的 pass@1 就是成功次數除以 3，只可能是 0、1/3、2/3 或 1。三次中任一次成功是另一種「給三倍機會」的 policy，不能把 best-of-three 改名叫 pass@1。

5 題 × 每題 3 次只有 15 次嘗試，而且同一題的三次結果彼此成群，不能當成 15 個完全獨立的工程問題。這套規模適合找明顯缺陷、估計執行預算與決定是否擴大題庫；不適合把小數點後差異排成穩定名次。更完整的重複執行與盲測設計，可參考 Terminal-Bench-Science 教學與 AI 模型 Shadow Eval。

執行收據怎麼記？先看品質，再看成本

每一個 run 都是一列，至少記錄：task_id、Agent、trial、base SHA、image digest、model snapshot、CLI／harness 版本、prompt hash、reasoning、tool／network policy、token 與時間上限、pass/fail、cost、wall time、patch hash、grader hash、exit code、人工介入分鐘與 failure class。

• missed requirement：漏做 ticket 已明說的條件。
• unsupported assumption：自行假設 API、schema 或環境，導致行為不符。
• regression：目標功能完成，但破壞既有測試或相鄰行為。
• unsafe／out of scope：越權、讀取不必要資料或大幅改動無關檔案。
• infrastructure invalid：模型服務中斷、sandbox 壞掉或 grader 本身失效；只能依預先規則重跑，不能算成額外免費機會。

先設硬門檻，例如沒有安全事故、五題沒有固定重複 regression、人工複核沒有阻擋項。只有通過門檻的配置才比較 pilot pass@1、每個成功結果的總成本與 wall time。成本分母要保留失敗：

pilot_pass_at_1 = 全部成功 run / 全部預先登記 run
effective_cost_per_pass = 全部已知 run 成本 / 成功 run 數

# 每題也要保留 3 格 raw matrix，不能只看總平均

假設示意題 PR-03 的三次結果是 PASS、FAIL、PASS，成本分別為 0.65、0.90、0.78 美元；該題樣本 pass@1 是 2/3，有效成功成本是 2.33 ÷ 2＝1.165 美元。這不是 AlphaLab 對任何產品的實測，而是工作簿公式示例：失敗的 0.90 美元仍然留在分子。

四道防作弊與人工複核閘門

1. Git 與 artifact 洩漏閘門

從 Agent 身分進 sandbox，嘗試搜尋原 PR 標題、accepted patch 片段、future branch、tag、reflog、release note 與 build artifact。任何一項命中都先停題。NIST CAISI 整理的Agent 評測作弊案例也區分了評測時找到未來答案與模型訓練污染；兩者不能混為一談。

2. Contamination 誠實標記

私有只會降低公開搜尋命中率，不能證明模型從未在舊版公開 repo、過去 Agent session、承包商資料或供應商合作中看過內容。每題保留 contamination_risk 欄位；曾公開、曾交給同一候選供應商，或無法追溯來源的題，標成 medium／high，而不是宣稱 contamination-free。更深入的 canary、網路 allowlist 與 trace 稽核，可讀 AI Eval 防洩漏測試。

3. Judge 偏誤閘門

可執行測試負責 pass/fail，盲化人類 review 負責可維護性、安全與需求是否合理。若不得不用 LLM judge，至少隱藏候選名稱、隨機交換呈現順序、使用不同家族的 judge，並用一組人工標註樣本校準。EMNLP 2025 的模型自我偏好研究發現 LLM-as-a-judge 可能偏好與自身生成分布相近的回答，因此不能把同模型裁判當成中立 oracle。

4. 人工複核與退出閘門

抽查所有 fail、所有 grader／judge 分歧，以及每個配置至少一個 pass。若需求在當時其實不完整、accepted patch 也需要未記錄的人類澄清，就把題目標為 invalid，而不是懲罰 Agent。若任務本來就需要問問題，也可以把「辨識資訊不足並提出正確問題」另列為成功狀態，但不能和自動完成混成同一 pass。

下載：繁中 PR 選題表、執行收據、三次試跑工作簿

下載 Private Repo Coding Agent Eval 範本包（ZIP）。壓縮檔內含一份 Excel 工作簿、三份可直接匯入試算表的 UTF-8 CSV，以及繁中 README。

1. 先在「PR 選題表」填滿 5 題，完成 base fail、accepted patch pass 與污染風險檢查。
2. 為每個 Agent 建立一份「執行收據」，鎖定 model、harness、prompt、image、network 與 budget。
3. 把每題三次 PASS／FAIL、成本、時間與 failure class 寫進「三次試跑」分頁。
4. 確認所有預先登記 cell 都有結果；infra invalid 必須有原因與重跑關聯。
5. 先做人工複核，再用公式欄看 pass@1；不要刪掉失敗列。

這份範本是記錄骨架，不會替你證明題目公平。真正的品質仍取決於 ticket 是否完整、快照是否無未來資訊、hidden oracle 是否測對行為，以及團隊是否願意保留不漂亮的失敗。需要把這些環節做成可維護 runner，可延伸閱讀 如何建立 AI Agent Harness。

常見問題 FAQ

1. 5 個 PR 足以選出最好的 Coding Agent 嗎？

不足以選出普遍冠軍。它適合淘汰明顯不合格配置、找出失敗模式並估計擴大評測的成本。重要採購或路由決策應逐步增加任務家族與題數。

2. 為什麼每題一定要跑 3 次？

三次是看見隨機性的最低實用起點，不是統計保證。它能區分穩定成功、偶爾成功與穩定失敗；結果若要對外比較，通常還需要更多題目與更多重複。

3. 可以把三次裡最好的一次當成 Agent 成績嗎？

不可以叫 pass@1。Best-of-three 代表給三次機會與三倍預算的另一種使用政策；可以另報，但三格 raw result、總成本與失敗仍要保留。

4. Accepted PR 就是標準答案嗎？

不是。它只證明至少有一個可接受解。Grader 要測外部行為、規格與 regression，不要用 diff similarity 限制 Agent 必須模仿原作者。

5. Checkout 舊 commit 為什麼不夠？

因為未來答案可能仍留在 object database、remote refs、branch、tag 或 reflog。應匯出該 tree 到新目錄並重新初始化 repository，再從 Agent 視角做洩漏檢查。

6. Native harness 不同，還算公平嗎？

如果問題是選產品，算是合理的實務比較。但結果屬於 model＋harness 組合，不能歸因於裸模型。若問題是模型研究，才需要共同 harness。

7. Private repo 能保證沒有資料污染嗎？

不能。它降低公開搜尋答案的機率，卻無法排除過去公開版本、既有 Agent session 或其他資料管道。應逐題標示風險，不宣稱絕對乾淨。

8. 最後應該用哪一個指標決定？

先用安全與正確性當硬門檻，再看 pass@1、有效成功成本、時間與失敗類型。單一總分會掩蓋「便宜但常回歸」或「成功但需要大量人工介入」的配置。

五個重點帶走

1. 公開 benchmark 是研究起點；真正的工具選擇要回到你的 repo 與驗收條件。
2. 從 merged PR 出題時，需求、base、accepted patch 與 merge 方法都要能追溯。
3. 只 checkout 舊 SHA 仍可能洩漏未來歷史；使用 tree snapshot 與全新 repo。
4. 三次結果要全部留下，pass@1 與 best-of-three 不能混用。
5. Hidden oracle、盲化人工複核、隱私檢查與完整收據，比一張漂亮排行榜更重要。