SWE-CC：測試通過，Agent 仍可能違反 Repo 規則

一個 coding agent 修好了 bug，測試也全數通過；但它可能沒有照專案要求執行測試、漏寫必要的 AI 協作聲明，或以不符合維護者規範的方式提交。若 benchmark 只看最後的 patch 和測試結果，這些流程問題就不會出現在分數裡。

SWE-CC 論文把這個落差變成可測量的問題：它從 12 個開源專案整理出 823 條可機器檢查的貢獻政策，再追蹤 Agent 的中間行為和最終交付物。作者報告，在這組 500 項任務中，適用政策有 43.1% 遭到違反；即使只看功能已解決的執行，違規仍有 50.3% 發生於中間流程。

這不是所有正式環境的違規率，也不能推論每次違規都會讓貢獻被拒絕或造成損害。它更直接的訊息是：程式功能正確與貢獻流程合規，是兩種不同的品質維度。

SWE-CC 多檢查了哪些事？

既有 coding benchmark 常以 issue 是否解決、測試是否通過作為主要判斷。這能回答「產出的程式是否修好問題」，卻較難回答「Agent 是怎麼完成修改」以及「交付是否符合這個專案自己的貢獻規則」。SWE-CC 針對這兩個缺口，將檢查對象分成兩類：

• 執行軌跡： Agent 如何找規則、下哪些命令、何時跑測試，以及是否遵循需要特定先後順序的流程。
• 最終交付： 程式差異、commit 訊息、pull request（PR）說明、文件和其他由任務產生的檔案。

規則來自專案文件與貢獻說明，不是作者替所有 repo 制定一份通用風格表。研究團隊先為 12 個 SWE-bench Verified 專案蒐集貢獻文件，從中抽出原子政策，再篩成 823 條具有可觀察證據、由貢獻者控制、且屬必要要求的規則。像「修改函式簽章時需更新 docstring」只會在條件符合時納入分母；沒有改動相關部分的任務不會因這條規則被扣分。

每條保留的政策都配有 checker。作者稱評分階段使用輕量、確定性的程式檢查，而非讓另一個語言模型臨場判斷。研究團隊以合格案例、違規案例和不適用案例測試 checker，再由兩位具軟體工程經驗的標註者抽查 150 條（823 條中的 18.2%）。論文報告這批抽樣判定的一致率為 94.0%，Cohen’s κ 為 0.72，並接受其中 87.2% 的 checker。這是論文所述的建置驗證，不等於外部團隊已獨立重做整套基準。

43.1% 是什麼分母？

SWE-CC 將政策分成「觸發」和「合規」兩個步驟：某次任務是否讓規則進入適用範圍，以及進入範圍後 Agent 是否遵守。作者在摘要中報告 43.1% 的適用政策被違反。這個數字描述的是這些被選入的 repo、任務、模型、scaffold 和 checker 所涵蓋的評估，不是 GitHub 上所有 Agent 貢獻的普遍發生率。

研究跑了 500 項由 SWE-bench Verified 延伸的完整貢獻任務，使用四種模型、兩種 Agent scaffold（mini-SWE-agent 與 OpenHands），並比較兩種政策提供方式：

1. Native： 告訴 Agent 政策文件的位置，要求它自行搜尋和理解，較接近政策散落在 repo 文件裡的情境。
2. Consolidated： 把整理好的原子政策放入一份檔案，要求 Agent 閱讀，以減少政策檢索成本，觀察明確規則是否改善遵循。

四種模型在兩個 scaffold 上，功能解決率大約落在 74.6%–94.4%，但 Native 條件下適用政策的合規率在 51.8%–63.8% 之間。直接提供整理好的規則後，平均合規率提高約 8.75 個百分點；可是功能解決率變動很小，且仍有不少政策沒有被遵守。換句話說，找得到規則確實重要，但「已讀到」不代表「做得到」或「每次都記得做」。

另一個值得注意的發現是：在功能已解決的執行中，作者把 50.3% 的政策違規歸在 Agent 的中間軌跡，例如先跑測試再 commit，而專案要求相反的順序。這類錯誤不一定留在最終程式碼裡，事後只檢查 patch 很可能看不見。測試通過並不會回溯證明流程合規。

這個 benchmark 能說明什麼，不能說明什麼

SWE-CC 的貢獻不只在 43.1% 這個結果，也在它把「政策檢查」落成一個可以討論的評估設計。對照只測最終 patch 的方式，它把三件事放在同一個觀察範圍：

• 政策有沒有被找到： Agent 是否嘗試搜尋，必要內容是否真的進入模型上下文。
• 過程有沒有遵守： 工具呼叫、命令順序、測試工作流等是否符合規則。
• 產物有沒有符合： 最後的程式碼、commit、PR 文字和文件是否符合可檢查的要求。

不過這仍是一項範圍有限的作者研究。資料取自 12 個指定開源專案和 500 個 SWE-bench 衍生任務，不能代表所有 repo、語言、工作型態或真實維護者的決策。823 條規則也只涵蓋作者判定為明確、可檢查且由貢獻者控制的要求；含糊建議、主觀判斷，以及無法從執行產物驗證的義務不在同一把尺上。

作者公開的 repo 含有所有 8,000 次實驗的結果匯出、每政策 verdict、checker、測試和執行程式，也提供一份完整示例軌跡；但沒有釋出所有 8,000 次歷史軌跡，因此外部讀者無法逐一重評當時的每個 Agent 行為。論文報告的 checker 人工抽樣審查程序和結果也在研究中，但 repo 沒有釋出該獨立審查的評分資料。本文未找到外部團隊的獨立重跑。

最後，違規是 checker 對特定政策的判定，不等於 maintainer 一定拒絕 PR，也不能單憑此研究說每次違規都會傷害使用者、造成缺陷或增加實際審查工時。更合適的解讀是：只用功能解決率描述 agentic coding，會漏掉一部分與專案治理有關的可觀察失敗。

團隊可以怎麼使用這個觀點？

如果你正在評估 coding agent，不需要立刻把所有 repo 規則都改造成一套大型 benchmark。可以先從最容易定義輸入、輸出和例外的小範圍開始：

1. 選出真的會影響 merge 的規則。 例如需執行的測試命令、不可修改的路徑、commit 或 PR 必填欄位。把建議與硬性要求分開。
2. 記錄 Agent 的實際行為。 保存它讀了哪些政策、執行了什麼工具、順序為何，以及最後提交的檔案；否則流程政策無從驗證。
3. 把規則拆成有前置條件的檢查。 只有當任務改動對應檔案或觸發特定流程時，才判斷該條政策是否適用；無法判斷的情況應保留為未知，而不是默認通過。
4. 分開報功能和治理結果。 同時追蹤 resolve rate、政策觸發率、適用規則合規率，以及 withheld／無法判斷的比例，避免一個總分掩蓋取捨。
5. 人工抽驗高影響規則。 檢查 checker 有沒有把政策讀錯或把例外當違規；依風險調整自動檢查與人工審查的比例。

這與 AI Agent 實戰指南中的 evaluation、state 和 observability 相接：Agent 的成功結果需要可檢查的依據，而不只是模型最後說「完成了」。如果政策還涉及權限、敏感資料或外部工具，可以延伸閱讀企業 AI Agent 安全架構；若關注規則要如何進入 agent harness，再看 Harness Engineering 閱讀地圖和Agentic AI 平台契約。

SWE-CC 的結果不應被當成所有 coding agent 的生產事故統計，而是對評測設計的一個提醒：要知道 Agent 是否能替 repo 做出可接受的貢獻，就得同時檢查它找過什麼、做過什麼，以及最後留下什麼。

來源

• Truong 等人，2026，Correct Code, Broken Contributions? SWE-CC: Benchmarking Repository Policy Compliance for Coding Agents；HTML 全文。
• SWE-CC benchmark、checker、測試與結果資料。