Amazon Science：Agentic AI如何治愈那些”无法替换”的遗留系统

今天读到Amazon Science的一篇论文，标题就让我眼前一亮——《Agentic AI如何修复”无法替换”的遗留系统》。这标题太精准了，它击中了几乎所有企业技术团队的痛点：那些运行了十几年、代码如同天书、文档早已失传、但又支撑着核心业务的老系统。

我之前在一家传统企业做技术咨询时，CTO曾指着机房里一台服务器对我说：”这台机器跑着我们的订单系统，20年前用COBOL写的，现在没人看得懂代码。重写要花两年、预算3000万，但万一出问题，公司可能破产。”他苦笑：”我们只能祈祷它永远不要坏。”

这就是遗留系统的困境——太旧不能用，太重要不能换。而Amazon Science提出的第三条路，让我看到了新的可能性：不是替换，而是”治愈”。

为什么遗留系统是企业的”定时炸弹”

先说说遗留系统到底有多可怕。根据Gartner 2023年报告，大型企业平均有60%的IT预算花在”维持”遗留系统上，而不是创新。这些系统往往有这些特征：

技术栈古老：COBOL、Fortran、甚至汇编语言，当年写这些代码的工程师可能已经退休甚至去世。据招聘平台数据，COBOL开发者年薪能到20万美元，因为太稀缺。

文档缺失：最初的技术文档早已丢失，注释稀少或根本没有。我见过一个企业的核心系统，唯一的”文档”是一张20年前的手绘流程图，还是从某个退休员工家里找到的。

依赖复杂：这些系统像老树的根系，与其他系统、数据库、甚至硬件深度耦合。动一个参数，可能引发连锁崩溃。

业务关键：偏偏这些系统处理的是订单、支付、库存等核心业务。宕机一小时，损失可能上百万。

Amazon Science的论文指出，企业面对遗留系统通常只有两个选择：

  1. 继续忍受：保持原样，祈祷不出问题，逐渐积累技术债务。
  2. 完全重写：花费巨额成本和时间，承担业务中断的巨大风险。

这两个选择都不好。前者是慢性死亡，后者是豪赌命运。而Agentic AI提出的是第三条路：增量治愈。

Agentic AI的”治愈”方案：三步走

Amazon Science的研究团队提出了一个基于Agentic AI的遗留系统改造方案，核心思想是”不破坏、不重写，逐步理解和改进”。

第一步：代码考古——让AI读懂老代码

Agentic AI的第一个任务是”考古”——分析几十年前的代码，理解它在做什么。

传统方法是人工阅读代码，但老代码往往有几十万行，变量命名随意（比如a1、tmp、x），逻辑嵌套深达十几层。人类工程师看一天可能只能理解几百行，还容易出错。

Agentic AI的优势在于：

语义理解能力：现代大语言模型可以理解编程语言的语义，即使是COBOL这种古老语言。论文中提到，他们用Claude 3.5处理了一个30万行的COBOL遗留系统，生成了完整的功能文档。

模式识别：AI可以识别代码中的重复模式、设计模式（即使实现得很原始），理解哪些函数是核心逻辑，哪些是工具函数。

依赖图谱：AI可以自动生成系统的依赖关系图，标识出哪些模块高度耦合，哪些可以独立修改。

Amazon的实验显示，一个Agentic AI Agent花了48小时分析一个遗留系统，根据Amazon Science论文案例，生成的文档准确度达到89%（由人类专家验证）。而人工完成同样工作，估计需要6个月。

第二步：安全重构——在不破坏的前提下改进

有了对代码的理解，Agentic AI可以开始”治疗”——逐步重构和改进代码。

这里的关键是”安全”。遗留系统最怕的就是改动导致崩溃。Amazon的方案是：

小步迭代：每次只改一小部分代码，比如提取一个函数、简化一个逻辑分支。改完立即运行测试，确认没有破坏功能。

自动化测试生成：Agentic AI可以分析代码的输入输出，自动生成测试用例。论文中提到，他们的AI为一个遗留模块生成了2000个测试用例，覆盖率达到92%。

回滚机制：每次改动都保存快照，一旦测试失败，立即回滚到上一个稳定版本。

Amazon的案例中，一个金融系统的遗留模块原本有15000行代码，逻辑复杂度高（圈复杂度200+）。经过Agentic AI的逐步重构，代码缩减到8000行，复杂度降到50，且没有引入任何Bug。

第三步：逐步现代化——从老系统到新架构

最后一步是”现代化”——把老系统逐步迁移到现代架构上。

这不是一次性重写，而是渐进式替换。Amazon的方案是：

API包装：为老系统添加现代API接口，让它可以与新系统交互。Agentic AI可以分析老系统的输入输出，自动生成RESTful API。

数据迁移：逐步将数据从老数据库迁移到现代数据库（比如从DB2迁移到PostgreSQL）。AI可以生成数据迁移脚本，并验证数据一致性。

模块替换：识别出可以独立替换的模块，用新技术重写（比如用Python重写COBOL的某个功能模块）。新老模块并行运行，逐步切流量。

论文中最让我印象深刻的案例是一家零售企业的库存系统。这个系统用Fortran写于1995年，但每天处理上千万次查询。Amazon的Agentic AI方案用了18个月，将系统逐步迁移到基于AWS Lambda的无服务器架构。整个过程中，系统保持100%可用性，没有一次业务中断。

实战中的挑战：AI不是魔法

读完论文，我对Agentic AI的能力很兴奋，但也看到了挑战。

挑战一：代码质量差距

不是所有老代码都能被AI理解。有些代码写得太随意，逻辑跳跃极大，甚至有”黑魔法”（利用语言的未定义行为）。论文中提到，他们遇到过一段汇编代码，通过直接操作内存地址实现某个功能，AI完全无法理解其意图。

挑战二：业务知识缺失

代码只是实现，背后的业务逻辑更重要。比如一个税务计算模块，代码可能只有500行，但背后涉及复杂的税法规则。AI可以理解代码结构，但无法理解”为什么这样计算”。Amazon的方案是让AI生成假设，再由业务专家验证。

挑战三：组织阻力

技术上可行，不代表组织上能推行。很多企业的IT团队对遗留系统有”恐惧心理”——”别碰它，它能跑就行”。推动改造需要高层支持，也需要证明AI的可靠性。Amazon建议先从非关键模块试点，积累信任。

我的思考：从”维持”到”治愈”的范式转变

这篇论文让我重新思考遗留系统问题。过去，我们把遗留系统当作”负担”，最多只能”维持”。而Agentic AI提供了一种”治愈”的可能性——不是抛弃，而是改进。

这背后是一个范式转变：从”系统是固定的”到”系统是可演化的”。

过去，一个系统写完就定型了，后续只能修修补补。而AI让”持续重构”变得可行。就像人体的细胞不断更新，系统也可以在运行中逐步替换自己的”零件”，保持活力。

这对企业的意义是巨大的。Gartner估计，全球企业在遗留系统上的”维持成本”每年超过3000亿美元。如果Agentic AI能将这些成本降低30%，就是近千亿美元的价值。更重要的是，企业可以把资源从”维持”转向”创新”。

当然，这个愿景还需要时间验证。Amazon Science的论文是2026年3月发布的，案例还比较有限。但方向是对的——用AI治愈遗留系统，让企业从技术债务中解放出来。

我很期待看到更多企业采用这个方案。如果你的公司也有那种”20年老古董系统”，不妨研究一下Agentic AI。或许，那台让CTO祈祷”永远不要坏”的服务器，终于可以安心退休了。

参考信息：

  • Amazon Science论文《Agentic AI for Legacy System Modernization》发布于2026年3月
  • Gartner关于企业IT预算分配的报告（2023年）
  • AWS关于遗留系统现代化的技术文档

关键词: #agentic-ai #legacy-systems #amazon-science #system-healing #technical-debt #modernization