許多工程師對 AI 寫程式的印象還停留在 GitHub Copilot 這種「自動補完」或「對話式生成」的工具。但對於像 Dropbox 這樣擁有巨型單體倉庫（Monorepo）且建構流程極其複雜的大型公司來說，單純生成一段程式碼片段是不夠的。因為在企業環境中，程式碼能否運行，取決於它是否能通過 Bazel 建構系統、是否符合 CI 驗證管線，以及是否在複雜的基礎設施中穩定運行。
為了解決這個問題，Dropbox 開發了名為 Nova 的內部平台。Nova 的核心定位不是一個 AI 助手，而是一個讓 AI Coding Agents（AI 編碼代理）能夠大規模運行的「執行層」與「編排平台」。
為什麼需要 Nova？從本地工具到企業平台的落差
一般 AI 編碼工具擅長的是在本地端產生程式碼，但它們缺乏對企業內部環境的感知。在 Dropbox 的實務中，工程師面對的是高度客製化的環境，包含 Bazel（一種高效能的建構與測試工具，常用於大型專案以確保建構的可重複性）以及嚴格的 Monorepo 驗證流程。
如果 AI 只是給出建議，工程師仍需手動將其複製、執行測試、修復錯誤，這在處理大規模遷移或數千個測試案例時效率極低。Nova 解決了這個痛點，它將 AI Agent 運行在隔離的雲端會話（Isolated Cloud-based Sessions）中，讓 AI 能直接連接到公司的工程基礎設施。這意味著 AI 不再只是「建議」程式碼，而是能直接在真實環境中執行建構與測試，根據失敗結果自我修正。
Nova 的核心運作邏輯：提案、驗證與迭代
Nova 建立了一套被稱為 Propose, Validate, Iterate（提案、驗證、迭代）的工作流。
首先，AI Agent 會針對特定問題提出程式碼修改建議（Propose）。接著，Nova 會在一個與特定提交版本（Commit）綁定的隔離環境中執行驗證命令（Validate），例如執行單元測試或建構檢查。如果測試失敗，AI 會分析錯誤日誌，自動調整方案並再次嘗試（Iterate），直到通過驗證或達到重試上限。
這種設計將 AI 的能力與確定性的系統（Deterministic Systems）結合。對工程師而言，最重要的不是 AI 有多聰明，而是驗證過程是否可靠。
從功能開發轉向維運自動化
雖然 Nova 可以寫新功能，但 Dropbox 發現它在維運與維護任務上效果最顯著。其中一個代表性應用是 Deflaker。
在大型專案中，Flaky Tests（不穩定測試，指同一份程式碼在相同條件下，有時通過有時失敗的測試）是工程師的噩夢。Deflaker 利用 Nova 自動分析通過與失敗的日誌，提出修復方案，並透過多次 CI 運行來驗證修復是否真正解決了不穩定問題，而非僅僅是運氣好通過。
此外，Nova 也被用於大規模的依賴庫升級（Dependency Migrations）。以往的自動化遷移工具缺乏互動性，一旦出錯就得人工介入。現在透過 Nova，AI 可以處理大批量的遷移任務，同時保留人類審核的環節，大幅降低了維護成本。
超越語言模型：基礎設施才是關鍵
Dropbox 的經驗給所有開發者的啟示是：要讓 AI 在企業級環境落地，底層語言模型（LLM）的品質雖然重要，但周邊的基礎設施（Platform Infrastructure）影響更大。
Nova 整合了可觀測性系統（Observability Systems）、內部插件以及基於 MCP（Model Context Protocol，一種讓 AI 能標準化訪問外部數據源的協議）的工具，讓 AI 擁有超越原始碼的上下文意識。同時，Nova 刻意將程式碼的發佈（如分支管理與合併）與 AI 的執行分離，確保所有的變更紀錄依然由人類控制且可審計。
總結來說，Nova 代表了 AI 在工程領域的演進方向：從一個個獨立的 Copilot（副駕駛），轉變為嵌入式基礎設施的一部分。AI 不再只是幫你寫程式碼的工具，而是一個能參與調查生產環境崩潰、處理維運瑣事、協調基礎設施遷移的長期參與者。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。