AutoDevBridge：構建Agent自動分析老舊系統，設計遷移路徑與方案實施

在 2023 年，基於當時的模型能力有限，我們在 AutoDev 設計了一系列的遺留系統功能的特性。而在 2025 年，經過自動程式設計智慧體 AutoDev Sketch 的一系列迭代，我們開始思考如何將 AI 智慧體應用到遺留系統中，便產生了 AutoDev Bridge 這個想法。

為什麼大模型能做得更好？

過去，我們公司 Thoughtworks 在這方面有非常多的積累，包括從遷移策略的設計、安全防護網的搭建等等，但是不論哪種遷移模型（絞殺者、修繕者等）最後都是需要人工介入的。而在 2025 年，已經有越來越多的 AI 智慧體能夠做到自動化遷移，因此我們進一步完善了我們的開源方案。

在遺留系統遷移上，為什麼大模型能做得更好呢？

設計合理的路徑規劃。通常來說，優先基於成本考慮，而大模型作為一個知識庫，能非常好的給你成本評估。
生成架構藍圖。結合目錄結構、依賴資訊、API，AI 能針對於當前系統描繪出初步的架構藍圖。
提煉程式碼中的業務知識。結合 AST 等，分析現有程式碼的業務邏輯，再基於其重寫。
跨語言翻譯。與生成程式碼不同的是，LLM 能非常好的將其翻譯成目標語言，只需要幾十秒到幾分鐘的時間。
遷移防護網的增強。即生成自動化測試來驗證遷移的正確性，實現實現精準迴歸測試。（注：在前端依然有所不足）
……

所以，我們只需要思考兩件事：

如何讓 AI 能借助工具更好地理解遺留系統？
如何藉助降低遷移的風險？

AutoDev Bridge 如何加速老舊系統遷移？

基於對遺留系統遷移的理解，我們設計了 AutoDev Bridge 的初步方案。它主要包括：

LLM 生成的遷移方案。（基於“探索-感知-響應”方案）
基於 C4 的當前架構現狀分析。（基於 AI 工具呼叫）
結合 AST 與呼叫鏈的業務邏輯分析。（AI 理解程式碼）
生成遷移測試用例。
AI 輔助的程式碼翻譯。
……

藉助與 IDE 的緊密整合，AutoDev Bridge 能獲得非常準確的 IDE 上下文，以進一步降低 AI 幻覺的產生。

探索-感知-響應：LLM 生成的遷移方案

在過去，我們將遺留系統遷移定義為 Cynefin 中的複雜問題，即你無法預測結果，只能透過實踐來發現。於是乎，我們參考了 Cynefin 的思想，設計了現有的 AutoDev Bridge 的思維框架，即你要先探索、再感知、再響應。由於，我們預期的是模型在行動前是需要有一個藍圖（C4 模型），所以我們將這個過程分為三個階段：

探索：透過初步呼叫工具，獲取系統的基本資訊，如目錄結構、依賴關係等。
感知：基於探索的結果，生成初步的架構藍圖、遷移方案。
響應：進行遷移方案的驗證、生成遷移測試用例、生成遷移程式碼。

落地到國內的模型能力下，就會由由 V3 來進行探索，R1 進行方案設計，由 V3 進行響應。

面向架構檢視的工具設計

為了更好讓 AI 理解當前系統的架構，我們面向架構檢視設計了一系列的工具。

工具名稱 (name)	描述 (desc)
componentView	列出當前專案的所有UI元件列表，如React、Vue元件
containerView	列出當前專案的所有模組
webApiView	列出當前專案的所有Web API
stylingView	列出當前專案的所有CSS、SCSS類
dir	獲取當前層級的目錄結構
history	獲取當前檔案的歷史提交資訊
knowledge	從 API 呼叫鏈進行分析，預設 depth = 2（不可修改），即 Controller 到 Repository 的呼叫鏈