在現代的大型軟體開發流程中，程式碼審查（Code Review）是確保品質與安全的核心環節。然而，當開發規模達到 LinkedIn 這種等級時，僅依賴人力審查會造成嚴重的瓶頸，而直接將現成的 AI 審查工具接在 GitHub 等版本控制系統前端，往往無法達到預期的效果。根據 InfoQ 的報導，LinkedIn 的工程團隊發現，通用型的 AI 模型在處理特定企業的程式碼時，經常缺乏對組織內部編碼標準、慣例以及所謂的部落知識（Tribal Knowledge，指僅在團隊內部口耳相傳而非正式文件化的知識）的理解，導致 AI 產出的建議過於籠統，甚至出現幻覺（Hallucination，指 AI 生成看似合理但事實錯誤的資訊）。
通用 AI 審查工具在實務上面臨三個結構性限制。首先是單一模型的盲點，如果僅依賴一個模型，它可能會重複地忽略同一類型的錯誤，或持續對某些低價值的問題提出警告。其次是自定義能力的不足，企業需要將組織層級的政策、特定儲存庫的慣例以及針對高風險場景的指導方針同時整合進審查流程中，而通用工具難以兼顧。最後是缺乏運維控制力，將 AI 審查視為基礎設施的一部分，意味著需要對延遲、錯誤率與模型效能進行嚴格的監控與評估，而第三方工具通常無法提供足夠的透明度。
為了克服這些挑戰，LinkedIn 開發了一套基於多代理（Multi-Agent）架構的 AI 程式碼審查平台。這套系統的核心在於不再依賴單一 AI，而是部署多個獨立的 AI 審查代理，每個代理使用不同的模型與推理邏輯。當多個代理獨立地識別出同一個問題時，系統會將這種收斂（Convergence）視為強而有力的證據，從而提高建議的信心水準。對於僅由單一代理發現的問題，系統則會進行獨立驗證，而非直接捨棄。在最終將評論發布到 PR（Pull Request，合併請求）之前，系統還會過濾掉僅涉及美觀、已被修正、無關緊要或與儲存庫慣例不符的建議，以確保開發者接收到的訊號純度最高。
在技術實作層面，LinkedIn 將此平台視為生產級基礎設施。系統採用基於 Kubernetes 的架構，建構了一套事件驅動（Event-driven）的管線，利用持久化佇列（Durable Queues）與可水平擴展的工作節點（Horizontally Scaled Workers）來處理大量的審查請求。這種設計讓工程團隊能夠像監控伺服器一樣，監控 AI 審查的延遲、建議的採納率以及供應商 API 的失效情況，確保 AI 審查能搶在人類審查者介入之前完成，真正發揮加速開發的價值。
為了量化 AI 審查的實際成效，LinkedIn 建立了一套自動化的採納率評估管線。該管線會比對 AI 提出的建議與最終合併後的程式碼，以確認開發者是否採納了建議。在對 1,727 個 PR 中的 5,230 條評論進行採樣分析後，結果顯示 63.9% 的建議被採納。值得注意的是，不同類型的錯誤採納率差異顯著：併發問題（Concurrency Bugs）的採納率高達 100%，邏輯錯誤為 80%，Bug 修復為 58.1%，重構建議為 43.5%，而安全性修復則為 40.6%。這證明了多代理架構在捕捉高風險技術錯誤方面具有極高的價值。
雖然 LinkedIn 選擇了多代理與強運維控制的路線，但其他公司也有不同的嘗試。例如 Cloudflare 圍繞開源的 OpenCode 構建編排系統，而 Databricks 則透過 Unity AI Gateway 與 Omnigent 等工具來集中管理 AI 成本與開發工具。這些不同的路徑反映出，在規模化 AI 程式碼審查時，企業必須在通用能力、自定義深度與運維成本之間取得平衡。LinkedIn 的經驗顯示，將 AI 審查從單純的聊天機器人轉化為可監控、可驗證且具備組織上下文的基礎設施，才是提升大規模開發效率的關鍵。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。