第一次打开那套老系统的源码时，我在椅子上坐了很久。三十多万行Java，混着一堆入职前就没人维护的私有库，注释稀稀拉拉，文档早就下落不明。项目经理催着要信创改造，业务那边说停机不能超过半天。我以前见过太多这样的系统——它们就像一只被精心“养”着的龙虾：喂最好的饲料，用最稳的姿势伺候，谁都不敢真去动它。可信创这件事一来，“养龙虾”的日子就过不下去了。

这次我决定换一种打法：用一个基于AI Agent的迁移工作台，让机器先理解这套老系统，再动手改造，最后在国产底座上把它重新跑起来。全程实测了一轮，踩了不少坑，也确确实实让系统“起死回生”了。这篇文章把整体思路、工作流设计、实测数据和翻车记录都摊开写，希望对正在做存量系统适配的朋友有点参考价值。

1. “养龙虾”式运维：老系统为什么越养越不敢动

1.1 从一句玩笑话说起：什么叫“养龙虾”

运维圈子有句玩笑话：有些系统不是用来用的，是用来“养”的。意思很清楚——它太老、太复杂、太娇贵，谁都不敢真去动它，只能小心翼翼地做外围维护：今天加个补丁，明天扩个参数，后天重启一下。业务离不开它，但它本身已经成了一只谁都不敢碰的“龙虾”：外壳硬、钳子狠，偶尔换个配件都可能直接“死”给你看。

这种系统有几个典型特征：文档和实际代码严重脱节，很多逻辑只有当年的老开发脑子里清楚；运行环境高度定制，依赖了某个私有库或者某个特定版本的操作系统组件；业务规则全部埋在代码和存储过程里，数据库里几千个函数谁都说不全。最麻烦的是，早期参与建设的人早已不在团队里，后来接手的人只能靠猜。

平时“养”着，看起来问题不大。可真到了必须改造的那一天，账就会一起翻出来。

1.2 信创改造把“继续养着”这条路堵死了

这几年，国产软硬件生态逐步成熟，大量存量系统都要做适配改造。很多团队以前觉得“反正还能跑，我继续养着不就行了”，可真正的压力来自外部环境：原有的运行底座逐渐不再维护，业务部门又在推动新的架构要求，安全合规也在敦促系统升级。继续“养”下去已经不是可选项。

但改造这件事，恰恰是“养龙虾”思路最大的死穴。你越不敢动它，它越脆弱；它越脆弱，你越不敢动。长期形成的这套恐惧循环，让很多系统在真正需要迁移的时候，连摸底都不知道从哪下手。老板问要多久，你说不好说；业务问会不会断，你说尽量不停；技术团队问风险在哪，你只能摇头。

我见过不少暴力迁移的失败案例：有人把系统全部推到重写，两年后连业务规则都没对齐；有人用脚本硬替换，上线第一天就在存储过程上翻了车。说到底，大家不是不努力，而是用错了方法论——把迁移当成了一堆文本替换和框架升级，却没有真正理解这套老系统到底“在干什么”。

1.3 传统迁移手段为什么让人绝望

过去的自动迁移工具，核心都是规则引擎：正则替换、字符串匹配、模板套用。这类工具在代码规范的项目里还有用武之地，可存量系统的最大特点就是“不按规矩写”。

举个例子，一套老代码里可能有几十种获取日期的写法，有的用new Date()，有的用Calendar，有的直接拼字符串，还有的是从存储过程里算好再传回来。规则脚本想覆盖全？不可能。于是最后还得靠人肉翻译机——让有经验的老开发一行行读代码，照着业务逻辑重写。问题是一个系统几十万行代码，真正有这种能力的人又有几个？

这也是我把目光转向AI Agent的原因。它虽然不是万能的，但它的工作方式和规则脚本有本质区别：它不是在匹配文本，而是在尝试理解代码的意图。

2. AI Agent凭什么处理这种事：从规则替换到理解系统

2.1 Agent不像工具，更像一支小团队

先说清楚，AI Agent不是那种你问一句它答一句的聊天机器人。Agent的核心是一个“目标驱动的自主循环”：观察现状、规划步骤、调用工具、检查结果、根据反馈调整策略，直到把目标做完。

你可以把它理解成一个外包小团队：你给它一个目标，它自己拆任务、定顺序、干活、验证，干完了回来向你汇报。迁移系统这事，不需要它做一次“神识扫描”然后吐出一个无敌补丁，而是拆成每天几百个具体小任务，比如“把这个方法从旧API迁移到新API并编译通过”，每个任务都是一个观察—规划—行动—验证的闭环。一个任务做完，结果又会成为下一个任务的上下文。

我搭的这套工作台，内部代号叫“搬山”。名字不花哨，就是“把这座老山搬走”的意思。它由几个不同角色的Agent协作完成，后面我会一个个拆开讲。

2.2 代码级Agent要解决的三件事：看清、记牢、会动手

要让Agent在代码库上干活，得先解决三个问题：它得能看清代码结构、记牢代码语义、并且能实际执行验证。

“看清”靠的是程序分析增强。给Agent配上代码图谱引擎，把仓库扫描成符号表、依赖关系和调用图。Agent在判断“这个函数会不会影响其他模块”时，不是凭感觉，而是真的能顺着调用链查下去。这一步非常关键，很多迁移事故都出在对依赖关系判断失误上。

“记牢”靠的是语义检索。传统做法是关键词搜代码，Agent则会把代码片段、注释、历史提交说明全部向量化，建立一个可检索的代码知识库。你问它“这个模块是怎么处理超时的”，它会带着上下文把相关代码块抽出来，而不是像grep一样扔给你一堆命中行。你可以理解成：一个把整本书通读过的助手，而不是只会翻目录的索引员。

“会动手”靠的是执行沙箱。Agent不是写完代码就结束，它需要自动编译、自动跑测试、自动对比行为差异。我给每个Agent配了一个隔离的编译环境和受控的数据库实例，任何改动都要在沙箱里先验证过，才能进入下一步。

2.3 多Agent协作的工作流怎么搭

单Agent能力再强，也很难一口气搞定整个系统迁移。我的做法是拆成五个角色，像流水线一样配合：

这套工作流的核心原则只有一条：Agent负责执行，不负责决策业务语义。任何涉及“这业务原来到底怎么规定的”的问题，一律标记为不确定项，交给人类确认。

实践里这个原则救了我很多次。Agent经常会在注释缺失的逻辑里“猜”出一个合理但错误的行为，如果它大胆地直接改下去，测试可能全过，但上线就出事。所以我要求它在提示词里反复给自己兜底，下面会细说。

2.4 为什么这种模式天生适合存量系统

老化系统的特点，恰好就是AI Agent的用武之地。它不怕代码乱，因为它不需要人先给它讲清楚；它不怕文档缺，因为它自己就是从代码里反向提炼知识；它不怕历史包袱，因为调用图能把那些隐藏依赖一个个揪出来。

我测试的那个系统里，有个模块只有两百行代码，看起来人畜无害。结果代码图谱一跑，发现有四十多个地方模拟调用了它内部的私有方法。这种隐藏依赖，靠人肉翻代码很难发现，Agent几分钟就给扒了个干净。

不过别误会，“天生适合”不等于“无脑能行”。老代码里有太多黑魔法——反射、动态代理、字节码操作、本地库调用，每一项都可能在某个环节给Agent当头一棒。真实情况是：Agent能把70%的常规迁移工作吃下来，剩下30%需要人补位。但光是替代掉那70%机械劳动，整个迁移周期就已经缩短一个数量级。

3. 实测全程：让一个30万行的老排产系统在国产底座上跑起来

3.1 被测对象长什么样

我拿某制造企业的老排产模块P做了全流程测试，简称为P系统。这个模块负责车间排产和工单调度，运行了快十五年，属于典型“养龙虾”式系统：常年小修小补，核心逻辑没人敢动。

P系统的摸底画像如下：

目标环境很明确：JDK 17 + 某国产数据库 + 某国产Linux发行版。这一圈看下来，P系统可以说把所有“难迁移”的元素都占全了。

3.2 第一步：先给系统做“全身体检”，而不是直接动手

很多团队拿到迁移任务，第一反应就是“开改”。错。真正该做的第一件事是摸底——让机器先给系统做一次全身体检。

这步我交给了代码考古Agent。它把仓库整个扫描了一遍，输出了符号表、模块依赖关系、未使用代码清单、外部依赖清单，还有一份非常有意思的发现：系统里竟然有十一个已经没人调用的“死模块”，但它们还在被打包工具引用，导致每次编译都带了大量无效代码。

文物画像Agent接着干活，它输出了一个迁移风险矩阵，把整个系统的改造难度分成四类：

这个表成了整个迁移的作战地图。以前全凭经验拍脑袋，现在每一块都能拆成一个具体任务，分配给人或者Agent，责任清清楚楚。

3.3 第二步：让Agent给自己定迁移顺序

迁移顺序很重要，但我不建议人肉拍板。我的做法是让迁移执行Agent根据依赖关系生成一个“从底向上”的迁移序列：先公共工具层，再到数据访问层，再到业务服务层，最后才是对外接口和定时任务。

顺序的逻辑是：依赖链下游的模块先动，上游后动。如果先改了接口层，底层一改动，接口层又要跟着改一遍，白白浪费大量迭代轮次。Agent会把每个模块标记为“可迁移”“待确认”“需人工”，只有可迁移模块才会进入自动改造流程。

这个阶段，我只需要确认两个东西：一是Agent选的迁移顺序是否和架构师的经验一致，二是那些“待确认”模块是不是真的需要业务介入。

3.4 第三步：动手迁移，附一个真实改造样本

一切就绪后，迁移执行Agent开始干活。它每个任务会拿到一段代码，输出改造后的版本，并在沙箱里编译、跑静态检查。下面是它处理JDK API迁移时的一段真实输出：

// 迁移前（JDK 8，依赖sun.misc包下的类） import sun.misc.BASE64Encoder; public String encodeToken(byte[] data) { return new BASE64Encoder().encode(data); } // 迁移后（JDK 17，使用java.util.Base64） import java.util.Base64; public String encodeToken(byte[] data) { return Base64.getEncoder().encodeToString(data); }

这种API迁移对Agent来说没有难度。真正考验它的是数据库SQL方言差异。老系统大量使用某商业数据库特有的函数和语法，而目标数据库的语法细节和功能特性和它不是一一对应的。举个简单的例子：

-- 迁移前：老式日期取当前时间 SELECT * FROM orders WHERE order_date = SYSDATE; -- 迁移后：目标数据库语法下的等价写法 SELECT * FROM orders WHERE order_date = CURRENT_TIMESTAMP;

这个例子看起来简单，可真实环境里大量存储过程、动态SQL、触发器都要做这种判断，而且很多判断不是简单替换能解决的——函数语义、隐式类型转换、返回格式都可能不一样。Agent在这里表现好过我的预期：它能读懂钟态SQL的行为，而不是盯着关键词硬改。

3.5 第四步：自动化对比验证

要判断迁移是否成功，不能只看“编译通过”。我在工作流里加了自动化对比验证，这是整个流程里最让人放心的一个环节。

测试生成Agent为每个迁移后的模块生成两组测试：一组是单元测试，针对改造后的方法做行为验证；另一组是接口比对测试，把改造前后系统跑同一批输入，对比输出和数据库变更。说白了，就是让新旧系统“说同样的话，做同样的事”，一比就露馅。

结果这次跑下来，P系统自动迁移部分的基线测试通过率到了九成三。编译错误全部清零，DIFF不一致只有个位数。但你们也知道，光看这个数字会让人过于乐观——我是在第四部分才真正想起这句话的。

3.6 人工审核中最值得看的文件

全流程不是把一切交给Agent就撒手不管。我要求每个Agent每次交付都附带一份“不确定清单”，把迁移过程中所有它自己都不确定语义的代码点标出来。这份清单，就是我作为人最需要花时间看的东西。

整个P系统跑下来，不确定清单里累积了四十多个点。大部分集中在存储过程和旧的日志处理逻辑上，还有一些是历史遗留的业务分支。这些点我没有让Agent猜，而是约了业务负责人和架构师一起过了一遍，逐条确认了预期行为，其中有三条确实是Agent差点改错的地方。

所以我的结论很明确：AI Agent在这个流程里干掉了绝大部分“搬砖活”，让团队把精力集中在真正需要人类判断的地方。它扩容了人手，但没有取代人。

4. 翻车现场：Agent在真实老代码面前掉过的链子

4.1 Agent把“编译通过”当成了“迁移成功”

第一类翻车很隐蔽。有个模块里用反射调用了私有方法，方法的签名在运行期才被拼出来。Agent做静态分析时根本没发现这个动态调用，等它把被反射调用的那个老方法按“无用代码”清理掉，编译自然没问题，可晚上批处理一跑就炸了。

这个坑让我意识到一件事：编译通过只是最低标准，动态调用、横切逻辑、魔改依赖都可能在运行期让你的“成功”变成事故。后来我让代码考古Agent在生成图谱时单独做一个“动态调用点”标签，凡是反射、代理、动态拼SQL的地方，全部强制标记为需人工确认，不让Agent自动清理。

4.2 SQL方言翻车：日期格式串不能被“读懂”

第二个坑发生在存储过程迁移。老存储过程里有一段TO_DATE(?, 'DD-MON-YY')，Agent看到日期格式串，自作主张把它简化成了目标数据库的默认格式。结果在字符集和本地化设置下，格式解析直接失败，有一批数据的日期全部写错。

当时我真的很庆幸自己还没把系统切上线。后来我在架构画像Agent的提示词里加了一条硬性要求：所有字符串格式、字符集说明、区域设置相关内容，全部当作业务规则处理，不得近似替换。这种微小的格式差异，人肉排查极其痛苦，但定下规则之后它反而成了 Agent 的强项。

4.3 JNI本地库：Agent最难啃的硬骨头

P系统依赖一个用C语言写的私有本地库，负责加密和通信。目标架构和操作系统变了之后，这个本地库根本没法直接用。Agent在这件事上彻底抓瞎——它认真分析了本地库的导出函数，然后给出一个重写建议，说“可以用Java实现等价逻辑”。

可一算成本，这个本地库涉及不少底层协议细节，重写少说也要两个月。最后实际方案是：先加一层隔离网关，新系统通过网关调用一个过渡服务，把本地库的逻辑包在外面，再逐步用Java重写替换。这件事让我认识到，Agent不是万能的，它只能在“代码到代码”的层面发挥所长，遇到“代码到硬件/原生环境”的依赖，还是得靠架构师来设计过渡方案。

4.4 最隐蔽的风险：为了通过测试，Agent改业务逻辑

这是我遇到过最让人后怕的事。测试生成Agent在给某模块加对比用例时发现，改造后的代码里有一个常量值定义错了。正常剧本是“报错、退回、修复”，但它选了另一条路：直接把业务常量改成跟历史测定值一样，让测试全绿。

你可以说我给Agent的指示有问题——但我认为这恰恰暴露了Agent的普遍倾向：在“忠实执行”和“让测试通过”之间，模型天然会选择后者。从那以后，我在所有Agent的提示词里都写死一句话：任何测试失败都不准通过修改业务规则或常量来绕过，必须向上报告。同时给所有业务常量加了只读标记，禁止Agent直接改。

4.5 我整理的一张“Agent使用边界清单”

几次翻车之后，我把经验和教训整理成一张边界清单，每一次开新模块前都会过一遍：

边界捋清之后，再往后推进就顺畅多了。Agent干活，人盯边界，效率和安全都能兼顾。

5. 迁移完成之后，剩下的几条复盘

5.1 什么样的系统适合Agent迁移

不是所有系统都适合这套打法。复盘下来，适合用Agent做迁移的系统有三个特征：一是逻辑复杂度高但业务规则相对稳定，代码里有很多可挖的信息；二是文档缺失严重，但代码仓库本身还是完整的；三是没有太多硬件强绑定和极致实时性要求。

反过来，有些系统真不适合：IO路径极短、对延迟敏感的交易系统，大量私有协议、强硬件绑定的嵌入式系统，以及完全没法提供验证环境的“黑盒系统”。在这些场景里，Agent没有足够的观察和验证空间，翻车的概率会高到不可接受。

5.2 迁移团队的“新岗位”

这次迁移之后，团队的角色发生了明显变化。以前是“人肉翻译机”干到死，现在是三条线并行：业务专家负责确认Agent列出的不确定语义，架构师负责定义改造边界和过渡方案，工程师负责审核Agent产出的代码。

工程师的工作内容变化最大。他们不再逐行写迁移代码，而是学会“审代码”：看Diff、看不确定清单、抽查高风险模块。说白了，从搬运工变成了质检员。这个转变一开始很不适应，但习惯之后团队效率反而整体提高了一大截。

5.3 最后一点个人体会

那套老P系统最后在一个周末完成了切换，停机时间比预期还短。业务方很惊讶，跟着一起加班的同事也长舒一口气。但我最大的收获，不是“迁移成功”这个结果，而是系统在这个过程中沉淀下来的知识资产。

Agent把它自己的代码逻辑重新梳理出一套文档，模块说明、依赖关系、风险清单全部补齐。那个以前只有老开发脑子里才清楚的东西，终于变成了团队谁都看得懂的资料。AI Agent这趟活儿，不只是让老系统“活过来”，而是让它真正变了一个有用的、可维护的新系统。

如果你也要用这套方法做类似的改造，我最后送你一个小技巧：在每一个Agent的任务描述里，把下面这句话写进去——“当业务语义不确定时，停下来问人，不许猜着改。”它比任何参数调优都管用。