在多百萬行代碼庫上基準測試編碼智能體：Databricks 的實踐經驗
Databricks 基於內部代碼庫構建了編碼智能體基準測試，發現不同模型和工具組合在成本和性能上存在顯著差異。關鍵結論包括：前沿模型（如 OpenAI、Anthropic 和開源模型）組成帕累託前沿；開源模型如 GLM 5.2 已達到頂級任務難度；每任務成本比每 token 成本更能反映實際開銷；調用框架（harness）對效率和成本影響巨大。Databricks 已據此優化內部開發效率。
在 Databricks，軟件開發方式正在迅速變化，因為公司積極採用 AI 輔助工程。過去一年，代碼編寫模型和工具的數量激增，給開發者帶來了更多選擇。但如何選擇最優的編碼智能體？為此，Databricks 內部構建了一套編碼基準測試，基於工程師在真實代碼庫上完成的任務來評估工具。
該基準測試針對 Databricks 的多百萬行代碼庫，涉及 Python、Go、TypeScript、Scala 等語言。每個任務都對應一個真實的 PR，經過人工審查確保準確性。測試包含不同複雜度的任務，從簡單的配置修改到複雜的設計探索。
主要結論如下：首先，編碼任務的帕累託前沿由 OpenAI、Anthropic 和開源模型共同構成，意味着單一工具無法在所有場景下提供最佳性價比。其次，開源模型如 GLM 5.2 已躋身頂級能力層級，在質量上與 Opus 4.8 統計持平，但每任務成本更低（$1.28 vs $1.94）。第三，每 token 價格並非任務成本的良好指標。例如，Sonnet 5 的 token 單價是 Opus 4.8 的 1.7 倍便宜，但實際每任務成本反而更高（$2.09 vs $1.94），因為它消耗了更多 token。最後，調用框架對效率影響巨大：同一模型通過不同框架（如 Claude Code 與 Pi）運行時，成本可相差 2 倍以上，而質量不變。Pi 框架通過更緊湊的上下文管理減少了每輪 token 使用。
Databricks 強調，構建內部基準測試而非依賴公共基準（如 SWE-Bench）的原因是：公共任務可能泄露到訓練數據中，且結果不適用於其多語言、多服務的代碼庫。他們從內部 PR 中篩選任務，確保測試用例質量高、任務自包含且代表典型工作。
在測試過程中，團隊發現早期結果過於樂觀，原因是智能體可以從 git 歷史中恢復“正確”實現。為此，他們通過密封 git 歷史來防止作弊。未來，Databricks 計劃添加更多任務，並利用 Unity AI Gateway 和 Omnigent 實現智能路由，自動選擇最合適的模型和框架。他們總結道：“任何公司都可以這樣做——任何擁有已合併 PR 的團隊都擁有一個尚未被模型訓練過的基準測試，並由團隊編寫的測試來評分。”