AutoDev Bridge：构建 Agent 自动分析老旧系统，设计迁移路径与方案实施

要说老旧系统迁移这事儿，AutoDev Bridge 可以说是走出了一条新路——它是利用 AI 技术为这类“老古董”转型提供智能化解决方案的实用工具。下面咱们直接进入正题，聊聊它到底是怎么一回事。

故事得从 2023 年说起。那时候模型能力还比较有限，我们在 AutoDev 里设计了不少针对遗留系统的特性。到了 2025 年，随着自动编程智能体 AutoDev Sketch 的不断迭代，思路也打开了：能不能把 AI 智能体正式请进遗留系统迁移的战场？于是，AutoDev Bridge 这个想法就应运而生了。

为什么大模型能做得更好？

公司 Thoughtworks 在遗留系统迁移这块其实积累很深，从迁移策略设计到安全防护网搭建，方法不少。但不管是用“绞杀者”模式还是“修缮者”模式，最终都绕不开人工介入。到了 2025 年，越来越多的 AI 智能体已经能把自动化迁移变成现实，所以我们进一步完善了开源方案。

那么，大模型在遗留系统迁移上到底凭什么能做得更好？

• 设计合理的路径规划。
  迁移这件事，成本永远是优先考虑的。大模型本身就像个知识库，能非常精准地给出成本评估，这就省事多了。

• 生成架构蓝图。
  结合目录结构、依赖信息、API，AI 能对着当前系统，一笔一画勾勒出初步的架构蓝图，相当于先把地图画明白。

• 提炼代码中的业务知识。
  借助 AST 等技术，AI 能分析出现有代码的业务逻辑，然后基于理解进行重写——而不是盲目搬动。

• 跨语言翻译。
  跟生成新代码不同，LLM 在翻译成目标语言上效率极高，几十秒到几分钟就能搞定，比人工翻快多了。

• 迁移防护网的增强。
  也就是自动生成测试来验证迁移的正确性，实现精准回归测试。当然，在前端领域，这块还有不足。

• ……
  还有很多潜力可挖。

所以你看，其实归结起来就是两件核心事：

• 如何让 AI 借助工具，更好地理解遗留系统？
• 如何借助工具，把迁移过程中的风险降下来？

AutoDev Bridge 如何加速老旧系统迁移？

带着对遗留系迁移的理解，我们设计了 AutoDev Bridge 的初步方案。它的核心能力包括：

• LLM 生成的迁移方案（基于“探索-感知-响应”的闭环）
• 基于 C4 的当前架构现状分析（靠 AI 工具调用完成）
• 结合 AST 与调用链的业务逻辑分析（AI 真正去理解代码）
• 生成迁移测试用例
• AI 辅助的代码翻译
• ……

最关键的一点是，AutoDev Bridge 与 IDE 紧密结合，能获得非常准确的 IDE 上下文。这一步对降低 AI 幻觉来说，至关重要。

探索-感知-响应：LLM 生成的迁移方案

过去，遗留系统迁移一直被定义为 Cynefin 框架里的“复杂问题”——你没办法预测结果，只能靠实践去摸索。基于这个思想，我们设计了 AutoDev Bridge 的思维框架：先探索，再感知，再响应。既然模型在行动前需要有一张蓝图（C4 模型），我们就分成三步走：

• 探索：
  初步调用工具，获取系统基本信息，比如目录结构、依赖关系。

• 感知：
  基于探索结果，生成初步的架构蓝图和迁移方案。

• 响应：
  进行迁移方案的验证，生成测试用例和迁移代码。

落实到国内模型能力上，就是由 V3 负责探索，R1 做方案设计，再由 V3 来执行响应。各司其职，效率很高。

面向架构视图的工具设计

为了让 AI 更好地理解当前系统的架构，我们专门面向架构视图设计了一系列工具：

下面就是 AI 基于某个项目架构视图的分析结果示例：

不过说实话，DeepSeek 目前对 C4 模型的理解还有限，这部分还需要进一步优化。

业务知识提取与理解

在业务逻辑分析上，我们主要依赖基于 API 的 AST 与调用链分析。先通过 webApiView 拿到所有 API，再通过 knowledge 获取 API 的调用链。比如：

/knowledge:GET#/api/blog/*

有了从 Controller 到 Repository 的完整调用链，AI 理解当前 API 的业务逻辑就变得非常直观：

当然了，这只是一个简单示例。实际场景下，AI 还得结合搜索等工具，获取更多上下文信息，才能做出更精准的判断。