使用 ReviewBench 評估代碼審查代理

代碼審查代理正在興起，LangChain 內部也構建了一個。評估這類代理是否有效是一個難題：現有的基準很少能反映內部審查標準，因此 LangChain 創建了 ReviewBench。該基準來源於 LangSmith 單體倉庫中的真實 PR 反饋，由受信任審查者的評論篩選出具體問題，並轉化為可復現的 Harbor 任務。

ReviewBench 的起點是真實審查歷史，而不是人為編寫的合成缺陷。原始評論噪聲很大，包含許多瑣碎問題和疑問，因此 LangChain 使用 LLM 門控過濾弱候選，再逐條人工審查，只保留能識別變更引入的真實問題、且足夠具體可驗證的評論。這使得基準衡量的是代理能否恢復實質缺陷，而非復刻審查者的每句話。

具體任務示例包括：一個數據庫 SQL 查詢按 ID 刪除資源時未檢查租户，代理需要識別項目級安全規則；另一個端點遷移丟失了原 API 的過濾器，代理需要對比兩版實現發現行為迴歸。這些任務要求代理理解代碼庫隱含契約，而不能只掃描變更行。

ReviewBench 目前包含 59 個任務和 64 個基線問題，任務以 Harbor 格式編寫。代理在任務開始時獲得凍結的 PR 上下文，可通過本地 GitHub 存根查看元數據和 diff，還能檢查完整種子倉庫，最後提交結構化問題列表。隱藏的驗證器使用 LLM 作為評判，比較提交結果與基線。覆蓋率衡量是否找到同一代碼路徑中的同一潛在問題，精確率衡量提交發現中正確的比例，F1 是這兩個指標的調和平均。

初步實驗使用相同的 Deep Agents 基礎框架運行模型，每個任務嘗試三次，刻意不使用自定義審查提示。結果顯示最強模型僅能恢復約 30% 的基線問題，代理通常會報告有效問題，但仍會漏掉許多真實審查者發現的具體問題。Luna 和 Terra 的表現低於預期，它們的審查策略似乎較窄，往往只關注少量發現就停止。

進一步的對照實驗表明，提示策略影響顯著。為 Luna 配置了高推理努力和結構化審查提示（要求先明確 PR 變更內容，追蹤周圍系統對該行為的依賴，並針對調用方、測試和相關實現驗證發現）後，在 20 個任務的子集上其得分達到 0.32，高於使用靜態審查提示的 Kimi 和 Opus 在同一任務上的得分。這説明改進審查流程本身可能比更換模型或添加工具更有效。

未來，LangChain 計劃擴展 ReviewBench，增加更多任務以提高穩定性，並覆蓋安全約束、API 兼容性以及需要變更行之外上下文的情況。最終目標是衡量代理能否在真實變更中發現實質問題，同時不增加不必要的噪音。