Agent 程式碼審查的確定性工程

資料來源#

• AI-to-AI Code Reviews of GitHub Pull Requests
• Claude Code Changelog
• How Bridgewater Built an AI Analyst That Does Hours of Expert Research in Minutes
• OpenCodeReview: Determinism over Non-Determinism for Cost-Effective Agent-Based Code Review
• Uncle Bob on Software Fundamentals in the Age of AI

摘要#

Li、Zhang、Wu 等人（Alibaba Group / Nanjing University / Peking University，arXiv 2608.09290，v1 2026-08-10，empirical）依循一項明確的設計理念——為不確定的代理程式打造確定性工程——建構 OpenCodeReview，並在儲存庫層級的審查基準上，與兩個已推出的產品比較。這套理念可以用一句話概括：不要給代理程式最大自由，再寄望它自行收斂；而是在管線中挑選特定位置注入確定性。 這裡選了三個位置，各自針對一種明確指出的變異來源：

1. Rule-Guided Dispatch——哪些檔案要審查、依據哪些準則審查，由四層 glob 比對規則鏈決定，而非交由代理程式判斷。「同一個 PR 永遠會得到相同的檔案與準則指派。」
2. Grounded File Review——不提供通用 shell。透過 ReAct 迴圈提供六種審查專用工具，每種工具都有硬性輸出上限；每個檔案各派出一個平行 SubAgent。
3. Independent Reflection——以證偽為先的過濾器，可以刪除評論、不能撰寫評論；由同一個 LLM 執行，但刻意讓它的資訊邊界比受審查的代理程式更窄。

headline 是 SEM-F1 提升 2.17 倍，同時減少 5 到 15 倍的 token。真正值得帶走的是背後的方向，而這不是摘要所呈現的樣子：這是用召回率換精確率，並以大幅降低成本買來的。 精確率提高 4.7 倍，召回率卻下降，因此勝出的系統實際找到的真實問題數量，少於它所勝過的無限制基準系統。

這是本語料第二篇主張代理程式設計應以確定性勝過自主性的 empirical 來源，前一篇是執行前確定性閘門。兩篇都沒有執行能隔離此主張的比較組。

結果，以及它呈現的方向#

AACR-Bench（Zhang 等人，arXiv 2601.19494）：從 10 種語言的 50 個儲存庫中選出 200 個真實 pull request，並包含 1,505 則 ground-truth 審查評論；這些評論經過 80 多位資深工程師三輪交叉驗證。評論以語意比對評分——由 LLM 評審判斷生成的評論是否在相同位置表達與 ground-truth 評論相同的疑慮——產生 Precision、Recall 與兩者的調和平均 SEM-F1。

論文 headline 所依據的唯一比較，來自表 3 中以相同模型對比最強基準的最佳列：

	SEM-F1	Precision	Match/Gen	Recall	Match/GT	Avg. tokens	Avg. time
OpenCodeReview（Claude-4.6-Opus）	25.10%	33.90%	301/889	20.00%	301/1505	385K	1m23s
Claude Code /code-review（Claude-4.6-Opus）	11.57%	7.23%	435/5980	28.90%	435/1505	5,664K	13m06s

先讀中間四欄，再看最外側欄位。受限系統：

• SEM-F1 勝出 2.17 倍，精確率勝出 4.69 倍；
• 召回率落敗：20.00% 對 28.90%——基準找到 1,505 個專家驗證問題中的 435 個，OpenCodeReview 找到 301 個。因此有 134 個真實問題只被 F1 分數只有一半的系統找出，受限系統則完全沒有找到；
• 每個樣本少用 14.7 倍 token（385K 對 5,664K），耗時少 9.5 倍（1m23s 對 13m06s）。

論文在 §4.2 直接說明這項取捨——「Claude Code 的召回率最高（28.90%）……但代價是精確率嚴重下降（7.23%）」——然而摘要、導言與結論都沒有延續這個重點，三者全以 2.17 倍與節省 token 作為開場。若讀者只看 SEM-F1，會以為受限系統的審查能力好上一倍；但數字顯示，它只是少浪費一倍注意力，找出問題的能力反而更差。 哪一種更符合你的需求，指標不會替你決定，這是部署時的選擇。

效率數據在整個比較組中都相當穩定，品質數據則較為溫和。從五組配對的 Claude Code 列重建出的 token 比率，介於 5.4 倍（GLM-5.1）到 14.7 倍（Claude-4.6-Opus），因此摘要所稱的「5–15 倍」有數據支持；相同配對的 SEM-F1 比率則介於 1.27 至 2.17 倍，與 §4.3 的「1.3–2.2 倍」相符。對 Codex 的比較則是另一回事：SEM-F1 為 21.00% 對 8.36%，成本相近（422K 對 525K token，2m51s 對 2m58s），因為 Codex 的單代理程式 /review 迴圈很早就結束——在 200 個 PR 中只產生 266 則評論、比對成功 74 則，召回率 4.92%，是所有設定中最低的，差距達兩倍。

前緣就是前緣，而圖說誇大了結果#

圖 3 將 12 種設定畫在精確率—召回率空間中（座標軸：Precision 0–40%、Recall 0–30%，皆為線性，沒有倍率；依圖片兩階段規則檢視）。圖中顯示、而文字沒有說明的內容如下：

• 右上象限是空的。 全部設定中，最高精確率是 37.80%，對應召回率 11.70%；最高召回率是 28.90%，對應精確率 7.23%。研究中沒有任何設定能讓兩者都高於 25%。在這個基準上，兩個系統無法排出高下，而是停在同一條前緣上的兩個運作點，沒有任何設定能脫離這條前緣。
• 模型選擇會讓你沿著前緣移動，不會把你帶離前緣。 在 OpenCodeReview 自己的六列中，精確率最高的設定（Claude-4.8-Opus，37.80%）在召回率上並列最低（11.70%）；召回率最高的設定（Claude-4.6-Opus，20.00%）精確率則低了 3.9 個百分點。系統設計決定一個區域，後端模型則選出區域中的某個點。
• 圖 3 的圖說誇大了結果。 圖說稱 Claude Code 與 Codex「分處不同區域，精確率較低，而召回率相近或更低」。然而，兩個 Claude Code 設定的召回率（28.90%、23.37%）都高於 OpenCodeReview 六種設定中的任何一種。§4.4 的正文敘述較嚴謹，圖說則不然；引用正文即可。

這項比較無法隔離什麼#

這篇論文完全沒有消融實驗。 沒有移除反思器的組別，沒有用代理程式分流取代規則導向派送的組別，沒有用 shell 取代有界工具組的組別，附錄也沒有相關內容，全文總共只有三張表。唯一的比較，是完整管線對比兩個完全不同的產品。

這比一般缺少消融實驗的問題更嚴重，因為論文的核心主張明確涉及因果關係：§4.2 將 2.17 倍提升「完全歸因」於系統設計，§5 的結論則稱「系統設計對審查品質的貢獻大於模型選擇」。這套設計實際排除的是模型優勢——所有系統使用相同後端，這點確實做得紮實。它無法區分的是：三種確定性機制彼此的作用，或其中任一機制與三個獨立打造的程式碼庫之間所有其他差異的作用，例如提示文字、派送邏輯、評論行號錨定、輸出格式、終止條件，以及各家供應商的後訓練。

有兩點讓這個疑慮更具體，不只是一般性的保留意見。

基準使用的是舊版產品，而且本知識庫能指出它有多舊。 論文測試的是 Claude Code v2.1.169，並在 §4.1.2 將其描述為「沒有審查專用工具或檔案層級平行處理的通用代理程式迴圈」；§6 則以兩種基準「代表業界已推出的程式碼代理程式現今最先進的水準」為由，替其基準設計辯護。對照本知識庫存檔的 Claude Code 變更紀錄（Claude Code Changelog，vendor-claim，滾動文件快照日期為 2026-08-03，範圍涵蓋 v2.1.200–2.1.220），這已不是實際推出的產品。到了 v2.1.202，版本說明寫道：「將 /review <pr> 改回快速單次審查；如要在指定工作量層級執行多代理程式審查，請使用 /code-review <level> <pr#>」——也就是一項明確採用多代理程式、分工作量級別的 /code-review，至少比受測版本晚了 33 個版本，且在論文提交前已推出。接著 v2.1.206 記錄：「改善 claude-opus-4-8 在所有工作量層級的 /code-review 發現品質」——供應商這項變更針對的，正是論文第二列 Claude Code 所用的後端。再之後，v2.1.215 停止 Claude 自行呼叫這項技能，v2.1.218 則將 /code-review 移到背景子代理程式。這些資訊並不表示論文的數字有誤；它表示論文的產品描述已過時——「沒有檔案層級平行處理」是 v2.1.169 的特徵，不是這類產品的特徵——而 §6 所稱「業界已推出產品的最先進基準」遠不如它宣稱的那麼有力。這也從另一個方向印證了同模型審查盲點的警告：透過供應商的 /review 指令量出的數字，反映的是某個固定版本的產品，不是某個模型，也不是某種架構。

比較結果恰好受到論文想隔離的因素干擾。 兩種基準都使用供應商內建的審查提示，而同模型審查盲點量測了這些提示對輸出量的影響：透過自家的 /review 功能，Codex 會產生 1–2 則評論，Opus 則會產生 7–8 則；只要加入一項要求目標為 7–10 則評論的指示，就足以改變哪些發現會被發布。在這裡，評論數量直接決定精確率（5,980 則生成評論對 889 則），它是基準提示中的一個可調參數，而這項研究從未調整它。因此，論文最有力的單一數據——精確率提高 4.7 倍——受到供應商提示在雜訊容忍度上的調校決定所干擾。

（§4.2 另有一處算術錯誤：該處稱 Claude Code 在 200 個 PR 中產生「4,580 則評論」，但表 3 同一設定的 Match/Gen 是 435/5980。表格才前後一致——435/5980 = 7.27%，可重現印出的 7.23% 精確率；435/4580 = 9.50%，則無法重現。同樣地，§4.1.2 所稱「Claude Code 使用六個模型評估，不含 GPT-5.5」，實際只描述了五列；表 3 與圖 3 的 12 個點也都對應五列。）

反思器刻意看到較少資訊#

論文中最值得移植的機制，也是證據最薄弱的一項。SubAgent 完成工作後，反思模組才會執行，且它只會收到該檔案的 diff 與 SubAgent 的評論——看不到 SubAgent 用來形成評論的工具輔助探索結果。反思器使用相同的 LLM；差別只有資訊邊界，而且方向與一般常見設計相反：審查者看到的資訊嚴格少於作者。

這項設計並非要對抗這種資訊不對稱，而是依此打造：

• 證偽，而非驗證。 反思器唯一要判斷的問題，是 diff 是否直接反證評論中的核心主張。若評論依據的是 diff 以外的背景資訊，就明確不會標記，因為 SubAgent 可能握有反思器看不到的證據。資訊不足的審查者通常會過度駁回；解法是只讓否決權涵蓋審查者能夠判斷的內容。
• 只能過濾。 模組只會刪除、不會新增，因此「對一組評論進行反思，只會減少假陽性，永遠不會引入新的假陽性」。問題涵蓋範圍由 SubAgent 單獨決定；個別評論的可靠度則由反思器單獨決定。
• 解析錯誤時採取放行策略。 若反思器輸出無法解析，就保留所有評論，「在失敗情況下優先保障召回率，而非精確率」。

最後這項特性，與執行前確定性閘門對其 predicate 採取的原則相同——閘門發生例外時會記錄錯誤，並讓呼叫繼續執行——結構上的原因也一樣：過濾器故障時應退化為沒有過濾器，而非引入新的失敗模式。 兩者方向不同（閘門故障會放行有風險的寫入；反思器故障會放行幻覺評論），但遵守相同的不變條件。

證據到此為止。 §5 的結論稱「對反思而言，資訊邊界可能比模型身分更重要」，但支持這個結論的全部證據，只是系統在六種後端上的整體精確率範圍（25–38%）。這並沒有測試該主張。至少需要一組不使用反思器的比較、一組 Reflexion 式的同模型／同背景比較，以及一組不同模型比較；這些都沒做，因此反思模組對 2.17 倍提升的貢獻仍不明。同模型審查盲點中有一項針對相同任務、且方向相反的測量：只改變程式碼審查所用模型的 lineage，固定 harness、diff 與 ground truth，結果發現高嚴重性問題的召回率會因此改變 6–12 個百分點。坦誠衡量兩邊的證據——前者是 case-study，ground truth 由供應商建置；本研究是 empirical——結論不應是任何一方勝出，而是這篇論文的證據等級不足以支持這句特定主張：模型身分是有數字支撐的軸，資訊邊界則是有設計論證的軸。兩者仍各自成立，等待驗證。

在工具端設上限，而非事後壓縮#

限制動作空間是一項具體、值得借鏡的設計：六種工具，各自公開上限。

Tool	Purpose	Bound
file_read	依路徑和選用的行範圍讀取檔案	每次呼叫最多 500 行
file_find	依名稱關鍵字尋找檔案	最多 100 個結果
code_search	搜尋整個儲存庫中的文字模式	最多 100 個相符項目，逾時 10 秒
file_read_diff	檢視另一個變更檔案的 diff	預先計算的 diff
code_comment	提交審查評論	非同步解析
task_done	發出完成訊號	結束迴圈

論文表示，這些限制是為了避免單次呼叫耗盡 context window——論文引用 SWE-Effi 與 Efficient Agents 所稱的 token 滾雪球問題。這是工具輸出修剪在壓縮端所處理問題的預防端解法，兩者比較起來很有啟發性。學習式修剪器會讀取觀察結果，再判斷要保留約 30% 的哪些行；硬性上限則會在第 500 行截斷，完全不看內容，因此可能丟掉代理程式需要的唯一函式主體，而由探查結果引導的篩選器可能會保留它。硬性上限的優點是不需要模型呼叫、額外 prefill，也不會中斷 prefix cache——該頁面比較七種方法時，多數修剪器總 token 數反而增加，原因正是前兩項成本；cache 成本則尚未計價。兩篇來源都沒有執行對方的比較組，因此整份語料都沒有「設上限或壓縮」的測量結果。

還有兩項限制同時運作，兩者依據的都是 context window 使用比例，而非絕對 token 數（Context Window Smart Zone）：diff 超過模型 context window 80% 的檔案，會在派送前被排除；迴圈內壓縮則在使用率達 60% 時非同步觸發，達 80% 時同步觸發，摘要整理歷史中段，同時凍結系統提示與最近幾輪內容。ReAct 迴圈最多執行 30 次；如果連續三輪沒有使用工具，空輪偵測器就會提示代理程式採取動作或結束。

評論行號錨定是管線另一項低調但確定的設計：不直接相信代理程式給的行號，而是用三階段 fallback，先在 diff 新增端的區塊中比對代理程式提供的 existing_code 片段，再比對完整檔案，最後才交給 LLM 重新定位。呼叫模型前先試兩次確定性方法——與Risk-Tiered Auto-Approval在合併閘門採用的順序相同。

這裡每個指標都出自一個尚未驗證的評審#

本頁所有數字都是 Qwen3-235B-A22B-Instruct 的語意比對判定。§6 提出的緩解措施，是每種設定執行五次評審並回報平均值；其辯護理由是：「由於所有系統都在相同規範下交由同一比對器評估，相對比較仍然有效。」

這種辯護正是LLM 評審驗證所指出的做法：使用相同比對器的一致性，不代表比對器有效。 沒有一致性統計，沒有對比人工評審小組判定的 Cohen's κ，沒有針對成對比對的位置或順序控制，也沒有公布五次執行各自的變異。以同一個評審抽樣五次仍是一個同質陪審團，而該頁有量化其代價：測得的組內錯誤相關係數 ρ ≈ 0.66–0.97，表示重複取樣同一個評審所帶來的效益，遠低於獨立抽樣的預期；因此五次執行的平均值，對變異的控制遠不如表面看起來那麼有力。

有兩項緩解措施確實有效，應給予肯定。AACR-Bench 的 ground truth 經過專家驗證——由 80 多位資深工程師進行三輪交叉驗證——標籤品質高於本知識庫審查相關資料中的其他任何項目。§6 也坦承了最重要的構念限制：「真正有用、但不符合任何 ground-truth 項目的評論，會被計為假陽性。」

請認真看待這項承認，因為它改變了「7.23% 精確率」的意義。 這是相對於固定參考資料集的比對率，不是正確率；它不表示 Claude Code 的評論有 93% 是錯的。代理程式審查評論處理結果分析 54,713 則真實代理程式審查評論，衡量人類端的近似指標，結果形狀正好相反：約 71% 的評論已獲處理；在 470 場有爭議但未解決的討論中，只有 63 場屬於事實錯誤或假陽性，11 場被判定為低價值雜訊。資料集、代理程式都不同，而且該樣本只涵蓋有爭議的案例——但這兩種構念不能合併計算，兩者差距也極大。為了提高參考資料比對精確率而最佳化的系統，所最佳化的指標從未被證明能反映開發者實際採取行動的依據。

缺少的比較組：實務工作者非正式執行的版本（Martin，2026-08）#

本頁指出的缺口——沒有人在同一品質標準下比較提示文字與檢查器——有一篇報告可供參照。它值得記錄，正因為它不是正式實驗。Robert C. Martin（Uncle Bob on Software Fundamentals in the Age of AI，2026-08-19，practitioner-opinion）在自己約八個月的工作中先後執行兩種做法，並表示第二種勝出。

第一組：指示。「我早期的提示是：這是測試驅動開發的做法、這是乾淨程式碼的做法、你的程式碼應該像這樣……最後會整理出一份五到十頁的文件，描述所有好的程式碼做法。」結果：「代理程式把那些規則當成《神鬼奇航》裡的海盜法則。它們比較像是指引。」

**第二組：閘門。**將相同標準重新實作成檢查器，讓代理程式在迴圈中逐一通過——涵蓋率加複雜度評分、mutation testing、相依規則規格檔——並將提示縮到最短。結果是他自述：不再閱讀程式碼。

為什麼這是線索，而不是正式比較組：

• 沒有控制、沒有測量，也沒有保留測試集。 這是單一實務工作者對一段時間的回憶，而期間使用的模型也有所改變。
• 作者有完全的 COI。 評分所用的檢查器是他寫的。
• 兩組條件不相符。 指示組使用五到十頁文件；閘門組搭配的是精簡後的提示。他自己的解釋（中間資訊遺失）預測短指示會勝過長指示，因此比較同時混入了「閘門或指示」與「短提示或長提示」兩種差異。把兩者分開，是成本最低、最有價值的實驗版本，但至今沒有人執行。

這份報告的貢獻，是提出一種閘門可能勝過指示的機制；本頁所述的「確定性勝過自主性」理念並未提出這點：隨著 context window 擴大，指示會逐漸失效，檢查器則不會（潛在空間與確定性空間）。這是一項方向性預測——閘門與指示之間的差距應會隨工作階段長度擴大——而本頁所要求的消融實驗可以在同一次執行中免費測試。

關聯文章#

• 閉環式 AI 審查——沒有任何審查基準會固定的部署母體。 AACR-Bench 在精選資料集上，以 1,505 則專家驗證評論評分系統；Selvanayagam 與 Ghaleb 則統計 248,641 個代理程式撰寫的 PR 中，實際發布的審查評論，發現輸出組成會隨本語料中沒有任何基準回報的變數改變——固定 CodeRabbit 後，其 refactor 類別占比仍會因 PR 作者代理程式不同，在 9.7% 到 35.0% 之間變動（Claude Code 與 Copilot 之間有據可查的差距為 24.5 個百分點，95% CI [23.1, 25.9]）。這呼應本頁的作者身分論點：透過供應商 /review 指令量出的召回率反映的是產品建置版本；同樣地，若基準 PR 取自單一作者組成，測到的也會包含這種組成差異。該研究沒有 ground truth，也沒有精確率或召回率數字，因此不會改變 20.00% / 28.90% 的前緣

• 分層監督——同一項論點，但依據的是實務報告，而非基準測試。五位實務工作者都認同一項常態規則：只要某項審查疑慮重要到會一再出現，就應轉成 lint 檢查，並以建置系統作為仲裁者。這種「確定性勝過自主性」的想法，是組織為了應付生成量而逐步採納的做法，不是為了贏得 SEM-F1 比較。它的弱點互補：沒有基準、沒有消融，也完全沒有數據，只能支持方向，無法支持幅度

• Agent-Generated Test Quality——將同一確定性論點放到測試領域：mutation 閘門會實際執行某項標準，而對代理程式測試涵蓋目標的衡量結果則顯示表現不佳

• Robert C. Martin（Uncle Bob）——非正式的閘門對指示比較、其中的混淆因素，以及報告提出的衰退機制

• 讓不切實際的品質工具重獲新生——他在閘門中使用了什麼，以及為什麼那些工具當時派得上用場

• 把代理程式程式碼生成視為編譯——本語料第三項「確定性勝過自主性」主張，也是第三項缺少消融實驗的主張。 Bridgewater 的 PAT 回報程式碼生成延遲約為本頁基準（Claude Code）的四分之一，並能在小幅編輯後幾乎立即重新執行；這來自三項同時注入的設計——具型別的計畫 IR、以 DAG 排程的強制驗證階段，以及靜態分析快取層——但沒有一項經過單獨測試。三個來源呈現的模式已很明顯：專門打造的管線大幅勝過通用代理程式，但每次都沒有測試各組件的貢獻。PAT 在三者中證據最弱（第一方演講、沒有任務集、沒有樣本數、完全沒有品質指標），但設計描述最具體，因為其確定性是量測出的輸出特性——兩個代理程式有 95% 的時間產出相同程式碼——而不是架構意圖

• 執行前確定性閘門——本語料另一項「確定性勝過自主性」結果，也是第二篇跳過相同比較組的研究。 兩篇研究都限制代理程式，並在不同任務領域、不同年份、不同實驗室中回報顯著提升（該研究任務成功率增加 12.4 個百分點，本研究 SEM-F1 提高 2.17 倍），這是對方向的真正獨立佐證。然而，兩篇都沒有執行用來隔離效果的實驗：前一篇沒有測試強制提示四條受閘控規則是否能取得相同提升；本研究則完全沒有消融。因此，「真正發揮作用的是硬性限制，而非指示」仍是兩篇論文共同的假說，不是任何一篇研究的發現。機制也只是相近，並不相同——前一頁的閘門是作用於提議中的變更呼叫的純 predicate，會在執行前拒絕；本研究沒有拒絕任何事情，確定性存在於派送（哪些檔案、哪些準則）以及上限（工具可以回傳多少內容）。值得保留的共同點是失敗語意：兩者都讓確定性層採取放行策略，因此限制機制發生錯誤時，系統會退化為無限制狀態，而非進入新的失敗模式

• 潛在空間與確定性空間——Tan 的診斷在此套用到分流：哪些檔案值得注意、該依據哪份檢查表，是論文認為放錯位置的決策（「若交給代理程式，每次執行的結果都會不同」）；解法是移到採用 first-match-wins 語意的 glob 模式。這也延伸了該頁的第三種類型。規則是自然語言審查檢查表，依確定性的路徑比對選取——派送是確定的，準則內容仍處於潛在狀態——這種混合設計既不是 Tan 的座位安排範例，也不是 τ²-bench 閘門所包含的做法：不是「把文字規則搬進程式碼」，而是「讓程式碼決定模型會讀到哪些文字規則」。但此處的案例有混淆因素，而閘門論文沒有：前者只改變某類規則在哪一側執行，本研究卻同時變動三種機制，並對比兩個不同產品

• 最佳化器與評估器解耦——另一個獨立性軸，方向與該頁其他軸完全相反。 既有軸線都限制評分者能學到哪些評分資訊，或能揭露哪些自身資訊（Bun 的僅看 diff 評審、SEAL 的單位元封存稽核、Cursor 去相關鏡頭、Zhou 的先提交再條件化）。這項設計限制的是評分者能從世界了解什麼：反思器使用相同模型，檢視相同產物，但收到的證據嚴格少於作者；論文認為，資訊不足會打破自我強化偏誤，因為「它看到的比代理程式少，而非更多」。有趣之處在於設計推論：資訊不足的審查者只能負責證偽，因為它無法區分錯誤評論與依賴被隱藏證據的評論，因此否決範圍縮小至 diff 本身能直接反駁的主張，而且模組不得自行產生評論。應將它視為設計而非結果——反思模組沒有經過消融，§5 所稱「資訊邊界可能比模型身分更重要」也是從不同產品的整體數據推論，沒有任何比較組實際改變資訊邊界

• 同模型審查盲點——兩個來源對代理程式審查者的召回率相差 2.5 倍，差異主要來自構念不同。 Greptile 對前沿審查者的高嚴重性錯誤召回率估計為 50.5–62.0%；本研究最佳系統為 20.00%，最佳基準為 28.90%。兩者都沒有錯：前者的 ground truth 是代理程式撰寫 PR 中約 1,500 個由供應商標註的 P0/P1 錯誤，排除了風格與文件評論；本研究則是 200 個人類與代理程式 PR 中 1,505 則各種性質的專家驗證評論。因此，數字取決於什麼才算發現，且代理程式審查尚無母體層級的召回率數字——目前兩項近似 empirical 的測量值相差 2.5 倍。有兩項發現可以互相印證。Greptile 指出，透過 /review 量出的召回率反映的是產品，這為本頁對 v2.1.169 基準過時的質疑提供了獨立依據。它所測得的 lineage 效果為 6–12 個百分點，也是本知識庫中唯一能以測量結果對照 §5「資訊邊界比模型身分重要」的證據

• 代理程式審查評論處理結果——審查層有效性的第三支腳，也是揭示本文最佳數字侷限的一項。 該頁與同模型審查盲點已將採納率（71.4% 的評論獲處理）與召回率（指出 52–62% 的錯誤）並列；本頁再加入相對於專家參考集的精確率（12 種設定介於 7.23% 到 37.80%）。三者不能合併計算，而本研究對構念的警告最為尖銳：§6 承認，真正有用但不符合任何 ground-truth 項目的評論會被算成假陽性；該頁的卡片分類也只發現 470 場有爭議討論中有 11 場被判定為低價值。7% 的參考集比對率與約 71% 的人工處理率衡量的是不同事物，最佳化前者從未被證明能改善後者。兩者也都指出審查代理程式常見的失敗原因：人類最常駁回的真實原因，是代理程式看不到的專案背景資訊（23.8%）；而這正是此架構透過有界工具與 file_read_diff 試圖取得的資訊

• 工具輸出修剪——同一瓶頸改用預防而非壓縮處理，兩邊的取捨也都說得清楚。每項工具設硬性上限（500 行、100 個相符項目、10 秒）不需模型呼叫、不需額外 prefill，也不會中斷 prefix cache——該頁的比較表中，七種學習式修剪器有五種在某些情況下增加 token 數；cache 成本仍未計價——但它完全不看內容，因此會在上限處截斷，而探查結果引導的篩選器會保留重要的約 30%，無論它們位於哪裡。兩套系統也對邊界所在位置有不同看法：該頁的修剪發生在回合之間、代理程式已讀過完整回覆後的代理程式—環境邊界；設限則讓完整回覆根本不會產生。沒有人在同一個 harness 上比較過設限與壓縮

• Cost-per-Task Over Cost-per-Token——少數案例之一：在後端固定的第三方 harness 上，兩項成本指標同時改善。固定模型，只改變審查系統，每個樣本的 token 數從 5,664K 降至 385K（14.7 倍），耗時從 13m06s 降至 1m23s（9.5 倍），同時 SEM-F1 提高 2.17 倍。Writer 替換系統所支持的「harness 比模型更有影響力」結果，在另一種任務領域中再次出現，且不是任何一方販售的基準產品。但有兩點使結果不夠乾淨。對 Codex 而言，token 節省幾乎消失（422K 對 525K），品質差距反而更大，因此成本優勢是該特定基準探索行為的特性，不是受限設計必然帶來的好處。另外，全文完全沒有金額數字——連續第三個系統以 token 和秒計價，卻沒有用金錢計價

• 審查是控制點——自動審查者能力的調節因子，現在呈現為前緣，而非單一數值。該理論把審查能力當成單一構念；本研究則主張審查系統會落在由架構決定的精確率—召回率區域，後端只能在區域內移動，且 12 種設定的右上象限全是空的。該頁提出的「先全部回報、再過濾」建議，在此以強形式落實：SubAgent 決定涵蓋範圍，獨立的過濾式反思器決定哪些評論保留，而且過濾器在結構上無法新增發現；然而，沒有消融實驗，無從得知這種拆分帶來什麼好處

• Repository Exploration Subagent——在同一瓶頸上比較委派與分散兩種做法。FastContext 將探索抽離到一個唯讀子代理程式，讓它回傳精簡引用，保持求解代理程式的 context window 簡潔；本研究則把探索工作下放給每個變更檔案各一個 SubAgent，各自擁有有界讀取工具與獨立 context window，再依需求透過 file_read_diff 找回跨檔案相依資訊。兩者都避免讓探索歷程塞進單一大型 context，也都沒有互相比較；論文表示，檔案層級分割是為了平衡一致性與效率，選擇它而非依照區塊或函式切分，理由是更細的切分會拆散彼此相關的變更

• LLM 評審驗證——本文每個公布的數字都仰賴一個未驗證的語意比對器，§6 的辯護（「所有系統都在相同規範下由同一比對器評估，因此相對比較仍然有效」）正是該頁論點的重述，並被當成緩解措施。沒有與人工比對判斷比較的 κ、沒有順序控制、沒有五次抽樣各自的變異；而五次平均值仍是同質陪審團，實測 ρ ≈ 0.66–0.97 顯示它帶來的效益遠低於獨立抽樣的預期。值得肯定之處：AACR-Bench 的標籤經過 80 多位工程師三輪專家驗證，因此薄弱環節是比對器，而非 ground truth；兩者之中，出現問題的位置在這裡較理想

• 驗證成為新的瓶頸——本語料首次將自動審查的端到端成本量化：每個 pull request 1m23s 與 385K token，只找出 80 多位工程師所發現問題的 20%；基準則耗時 13m06s、使用 5.7M token，找出 28.9%。兩組數字都顯示瓶頸尚未轉移

• Claude Code、Codex——兩個基準，分別以 v2.1.169 與 v0.140.0 測試，透過各產品自己的審查指令執行

• Anthropic、OpenAI、Greptile——本語料三項審查效能測量所用的已推出審查功能之供應商

• 推理與行動交錯（ReAct）——本系統所固定下來的迴圈形式。六種有上限的工具、30 次迭代上限與空輪偵測器，將 CS329A 第 4 講介紹的開放式提示抽象，推向明確列舉並設限的一端

• 部署時會退化的保證：動作空間可靠性、無效允許，以及供應商耦合的安全架構——此系統的六種有界工具可歸為一種無法在規模擴張時恢復已列舉動作保證的作法：將動作空間縮小到可處理範圍，是如何打造系統的設計選擇，不代表在大型空間中恢復了可靠性；而且完全沒有消融實驗，所以工具組上限的貢獻尚未經測試

• 已提交產物鏈——審查步驟在整個生命週期中的位置，以及一種本頁規則導向派送會實際運用的政策產物。Anthropic 的 Applied AI playbook（vendor-claim，2026-08-21）要求技術主管在儲存庫根目錄撰寫 REVIEW.md：列出指定審查項目（bugs / security / compliance-against-spec.md-and-plan.md）、明確區分 Important 與 Nit、限制 nit 數量（「每次審查最多五個，其餘以數量摘要」），並排除生成檔案路徑與 CI 已涵蓋項目。這是人工撰寫的有界輸出規範，與本文測量的方式相似，另外多了一項本系統無法存取的 predicate：diff 是否仍符合已核准的計畫。發現事項依設計僅供參考（「發現事項本身不會核准或阻擋 PR」），由 branch protection 與 code owner 做出決策，並發布機器可讀的嚴重程度統計，供平台工程師選擇是否設為閘門

• 代理程式貢獻下的開放原始碼——實務工作者的反例：開放原始碼維護者將第一輪分流委派給不受限制的自主審查者，而本頁的精確率結果主張應避免這種設定

• LLM-Driven Vulnerability Research——本語料第三個「分階段管線勝過自主代理程式」結果，場景是安全審查而非程式碼審查，也是第一項執行了本頁反覆要求的控制組。Antaeus（arXiv 2607.01138，empirical）將五階段管線與使用相同模型（Claude Opus 4.7）自主探索儲存庫的結果比較；更關鍵的是，也與同一代理程式取得管線自行優先排列的函式清單時比較。這讓候選集固定，只留下「結構化背景加固定格式輸出」與「自行探索」之間的差異。分階段管線找到 35 個 CVE 中的 20 個，代理程式找到 13 個。研究也公布 OpenCodeReview 缺少的組件消融：移除本地程式碼增補，偵測數由 20 降至 13；移除儲存庫層級安全摘要，則由 20 降至 11。但它沒有測試純指示組——沒有人把管線結構貼進提示，再量測效果差異——因此本頁指出的混淆因素仍在更上一層保留。精確率方面也再次出現相同現象：受限系統以更多假陽性換取廣度（20 個錯誤對應 1,732 個發現；代理程式基準則為 240–1,060 個），與本頁 33.90% 精確率／20.00% 召回率的交換方向相反

• 撰寫者／審查者與代理程式對代理程式審查——將本頁三產品表格視為兩家供應商已推出審查指令在相同基準上的唯一對照，也說明哪些推論不成立：Codex 的 /review（200 個 PR 產生 266 則評論，召回率 4.92%）與 Claude Code 的 /code-review（5,980 則評論、召回率 28.90%、精確率 7.23%）是同一條前緣的兩端，差異來自評論數量策略，而非審查模式——兩項研究都沒有改變這個參數。該綜述也指出，本頁缺少反思器消融，是程式碼審查中資訊邊界軸仍未測量的原因

尚待解答的問題#

• 閘門與指示之間的差距是否會隨工作階段長度擴大，如 Martin 的衰退機制所預測？可直接在下方消融實驗中測試，不需增加成本——分別在短與長 context 使用量下執行純指示基準，再比較差異。
• 論文完全沒有任何消融實驗，因此三項確定性注入中的哪一項帶來 2.17 倍提升，以及效果是否能在純指示基準下保留，都尚未測試——少推理，多驗證：確定性閘門找回工具型 LLM 代理程式中的靜默政策違規失敗模式也在自己的領域留下相同缺口。可證偽的實驗設計成本不高，而且程式碼已開放原始碼：執行停用反思器的 OpenCodeReview、以代理程式分流取代規則導向派送的 OpenCodeReview，以及以 shell 取代六種有界工具的 OpenCodeReview；接著將 OpenCodeReview 內建規則文字貼進 Claude Code 的提示中再執行。在最後一組比較出現以前，「確定性勝過自主性」這項設計理念，已兩度在混淆因素下獲得測量，卻沒有與自身的替代方案比較。於 2026-09-23 部分解答——一般性主張有了第三個案例，但不是本論文的直接解答。 Antaeus（arXiv 2607.01138，empirical，儲存庫層級安全審查）是本語料第一個將分階段管線與候選集固定的相同模型比較的系統：最強基準是 Claude Opus 4.7 在取得管線自行優先排列的函式清單後自主探索，排除了本項目所關注的「不同系統、不同目標」混淆因素。管線找到 35 個 CVE 中的 20 個，代理程式找到 13 個；研究也公布組件消融：移除本地程式碼背景，偵測數從 20 降至 13；移除儲存庫層級背景，從 20 降至 11。因此一般性主張有一次與自身替代方案比較並獲得測量。但本項目尚未解決：任務不同（安全稽核，而非程式碼審查）、基準不同、沒有可消融的反思式過濾器，而且最重要的缺口仍在——沒有純指示組；沒有人把管線結構貼進提示，再測量保留下來的效果。精確率代價也以相反方向再次出現（20 個錯誤有 1,732 個假陽性），這說明本頁受限設計的精確率／召回率交換是一個可調參數，不是確定性本身的必然特性。
• 20% 召回率是受限設計的上限，還是審查任務的上限？ 12 種設定中，沒有任何系統能同時達到精確率高於 25% 與召回率高於 25%；在 OpenCodeReview 內部，精確率最高的後端在召回率上並列最後。因此圖 3 的右上空象限可能是架構限制，也可能是基準的限制。無需新增方法即可區分：調整 OpenCodeReview 的反思器門檻與 30 次迭代上限，畫出自己的精確率—召回率曲線，再報告曲線是朝空象限彎曲，還是沿著基準系統所在的前緣移動。
• 這裡的每個數字都是 Qwen3-235B-A22B-Instruct 的比對判定，沒有公布它與人工比對判斷的一致性；但基準標籤確實經過三輪人工驗證。比對器是否足夠符合專家裁定，可支撐 12 種設定的排序？五次平均值的穩定度有多少是真實的，又有多少來自同質陪審團所帶來的 ρ ≈ 0.66–0.97 相依性？兩個問題都能以數百筆抽樣比對判定，再加上作者已有但未公布的單次執行結果差異回答。

資料來源#

• OpenCodeReview: Determinism over Non-Determinism for Cost-Effective Agent-Based Code Review — Zhengfeng Li、Lei Zhang、Xianwei Wu、Zhengqi Zhuang、Yingjie Xu、Boge Wang、Shaofei Zhu、Chuan Wang、Peng Zhao、Xinyu Zheng 與 Guoping Rong（Alibaba Group / Nanjing University / Peking University），OpenCodeReview: Determinism over Non-Determinism for Cost-Effective Agent-Based Code Review，arXiv 2608.09290，v1 2026-08-10 / v2 2026-08-11，empirical（11 頁、3 張表、6 張圖片；程式碼位於 github.com/alibaba/open-code-review）。§1（兩項弱點、三項挑戰、2.17 倍與 5–15 倍 headline）、§2.1–2.3（三條先前研究脈絡及其局部性限制；引用 MSR-2026 實地研究，指出純代理程式 PR 合併率為 45.2%，低於純人工 PR 的 68.4%；遭拒的純代理程式 PR 中有 60% 的訊噪比低於 30%）、§3.2（四層規則鏈、replace／merge 模式、六階段檔案篩選，包括 80% context window 門檻）、§3.3（ReAct 迴圈、30 次迭代上限、空輪偵測、60%／80% 壓縮門檻、六種有界工具、三階段行號錨定 fallback）、§3.4（不對稱資訊邊界、證偽而非驗證、只能過濾、解析失敗時放行）、§4.1–4.4（AACR-Bench 設定、12 種配置、提升精確率而非灌高召回率的解讀、成本效益、精確率—召回率區域）、§5（將確定性視為設計原則、資訊邊界與模型邊界、成本—品質前緣）、§6（研究限制——五次評審平均、相同比對器辯護，以及有用評論會被視為假陽性的讓步）。COI：11 位作者中有 7 位來自 Alibaba Group，系統由 Alibaba 打造，兩個基準是競品；基準 AACR-Bench（arXiv 2601.19494）與本文共有四位作者，包括第二與末位作者，因此評估工具大幅由內部打造。論文僅揭露作者隸屬機構，沒有提出競業利益說明。
• 各表裁定。三張表都曾在 docling 匯入時損壞，已逐一人工修復；原始資料如今包含修復版本，且三張表的圖說都已移到表格上方。 表 1 將 4 列壓成 1 列，表 2 將 6 列壓成 1 列，表 3 同時發生列壓縮與欄位位移，不同（模型、系統）列的儲存格被交錯到各欄，是本語料迄今損壞最嚴重的表。表 3 依據 pdftotext -f 9 -layout 逐格重建。編譯時透過三種彼此獨立的檢查，驗證全部 12 列；若列對應遭到打亂，便無法同時通過：(i) 每列 SEM-F1 都能由印出的 Precision 與 Recall 重算出調和平均值（最大殘差 0.09 個百分點）；(ii) 每列的 Match/GT ÷ 1505 都能重現印出的 Recall（最大殘差 0.05 個百分點）；(iii) 每列的 Match/Gen 都能重現印出的 Precision（最大殘差 0.05 個百分點）。表 1 與 §3.2.2 的正文說明一致（ad-hoc 最高、built-in「base tier」、first-match-wins）；表 2 則與 §3.3.2 的「固定六種工具」及圖 2 所列工具一致——六個工具名稱因此各有三種獨立佐證。不要「修正」細微殘差：§6 表示比率指標取五次隨機評審的平均值，match 數則是合併後的總數，因此印出的是平均比率與比率平均值並列。有兩個錯誤來自論文本身，而非解析過程：§4.2 的「200 個 PR 共 4,580 則」與表 3 同一設定的 435/5980 不符，且只有表格數字符合印出的 7.23% 精確率；§4.1.2 所稱「六個模型，不含 GPT-5.5」實際描述的是五個 Claude Code 列，表 3 與圖 3 總共也只有 12 個點。
• 匯入時發現並修正連接號損壞：「5–15× fewer tokens」在導言及 §4.3 都被錯誤解析成「515 ×」。編譯時已驗證：從表 3 的五組配對 Claude Code 列重建出的 token 比率介於 5.4 倍（GLM-5.1）至 14.7 倍（Claude-4.6-Opus），所以「5–15×」才是正確範圍；同理，§4.3 所述 SEM-F1「提高 1.3–2.2 倍」（實測 1.27–2.17 倍）及對 Codex「2.5 倍」（21.00/8.36 = 2.51 倍），在「token 成本相近」（422K 對 525K，即 OpenCodeReview 便宜 20%）的前提下，都是較保守的說法。
• **依圖片兩階段規則開啟所有圖片。**圖 3（精確率—召回率散點圖）座標軸為 Precision (%) 0–40、Recall (%) 0–30，皆為線性；沒有倍率。圖中的 12 個點確認表 3 的精確率／召回率配對；右上空象限，以及兩個高於 OpenCodeReview 最高召回率的 Claude Code 點，都可以從圖上讀出。圖說所稱「召回率相近或更低」與圖表本身及表 3 相矛盾；§4.4 正文才正確。圖 2（架構圖）確認四層規則、每個檔案各自派出 SubAgent、六種工具、先比對行內容再以 LLM 重新定位的流程，以及反思區塊。圖與正文有兩處不一致，值得記錄：圖中明確列出每個 SubAgent 的 「Planning」 階段，§3.3.1 卻未提及；圖中反思器輸入標為 「File Context」，§3.4.1 則指定為 diff。兩者都不影響引用數值。其餘四張圖片是橫幅、授權資訊與版面裝飾。
• 匯入解析狀態：8 項檢查全部通過，顯示 verify: ok，包括表格壓縮 table-collapse: 0、表格位移 table-shift: 0，以及修復表格後 canary-recall 12/12 (recall 1.00)——這是真正通過而非跳過或空跑；docling 執行過程沒有出現 Stage preprocess failed，因此沒有頁面遭到靜默略過。
• Claude Code Changelog — Anthropic，Claude Code CHANGELOG（vendor-claim，滾動文件快照日期為 2026-08-03，範圍涵蓋 v2.1.200–2.1.220；只有版本說明，沒有任何項目的理由）。本文只用它來確認論文基準的時間：v2.1.202（「將 /review <pr> 改回快速單次審查；如要在指定工作量級別執行多代理程式審查，請使用 /code-review <level> <pr#>」）、v2.1.206（「改善 claude-opus-4-8 在所有工作量層級的 /code-review 發現品質」）、v2.1.215（Claude 不再自行呼叫 /verify 與 /code-review）、v2.1.218（/code-review 移至背景子代理程式）。快照從 v2.1.200 開始，因此無法說明 v2.1.169 的 /code-review 行為；它支持的主張只有：在論文提交前，明確採用多代理程式、工作量分級的 /code-review 至少已推出 33 個版本，這限制了 §6 所稱「業界已推出的程式碼代理程式目前最先進水準」的範圍。完整分析見最佳化器與評估器解耦。
• How Bridgewater Built an AI Analyst That Does Hours of Expert Research in Minutes — McManus、Ran 與 Weight（Bridgewater Associates），LangChain 頻道，2026-07-24，25:44 演講，case-study。引用作為第三個「確定性勝過自主性」案例：程式碼生成延遲約為 Claude Code 的四分之一，編輯後幾乎能立即重新執行，來自三項未經消融的注入（18:08–25:29）。整場演講都是第一方且未經方法驗證；每個數字的證據限制見把代理程式程式碼生成視為編譯。
• Uncle Bob on Software Fundamentals in the Age of AI — Robert C. Martin 與 Matt Pocock，2026-08-19（practitioner-opinion；自動字幕逐字稿）：非正式、未控制、由作者自行評分的先後比較，執行本頁所稱無人做過的兩組測試；受到提示長度混淆。其價值在於衰退機制，不在比較結果。
• 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。本文只引用其 §5.1 與表 3：固定審查工具、跨 35,248 則分類評論改變 PR 作者代理程式時，CodeRabbit 評論類別的組成也會改變；這是「審查基準取自哪些 PR 是一項變數」的大規模證據。標籤是 CodeRabbit 自己標示的標頭，以確定性方式擷取，從未經過外部驗證；論文也拒絕將其解讀為嚴重程度量表。研究沒有精確率、召回率或正確率數字。表格於編譯時依據 pdftotext -layout 核對。完整分析見閉環式 AI 審查