研究 COBOL 代码迁移：把 AI 锁进笼子，能否突破迁移瓶颈？

研究团队提出把 AI 锁进笼子

一批研究 COBOL 代码迁移的工程师发表论文，提出把 AI 锁进笼子，论文标题为《Agentic Method for Deterministic Validation of Legacy Code Migration》。他们设计了一个叫 Locksmith Loop 的系统，旨在把 AI 限制在一个确定性的框架里，让它只做擅长的事。

三个模块，AI 只碰一个

Locksmith Loop 的架构分三层。第一层是 Migrator，COBOL 源码进来，Java 目标代码出去，这一步不用 LLM，用的是确定性 AST 转换器，每次跑结果一样。第二层是 Witness Search，这是 AI 唯一出场的地方，LLM 不断构造输入用例，企图穿透程序的所有分支，直到覆盖率推不动为止。第三层是 Oracle，COBOL 原版和 Java 迁移版同时跑同一个输入，输出必须逐位一致，任何偏差都视为迁移失败，回退修正。这样设计是因为每一步都有明确的失败模式，Migrator 和 Oracle 是确定性的，Witness Search 是唯一非确定性的环节，但它的失败模式可控，Locksmith 的设计哲学是把 AI 放在它失败后果最轻的地方。

当 AI 推不动了

Witness Search 不是万能的，跑到某个分支边界时可能会卡住，论文里管这种情况叫 Locked Paragraph。系统不指望 AI 能打开所有锁，当 AI 推不动时，分析器会标记这个 Locked Paragraph，然后系统继续推进其他分支，最终覆盖率取决于 AI 能找到多少“钥匙”。论文报告了三个测试案例的结果，两个开源 COBOL 程序达到了“几乎完全覆盖”，生产级程序达到了 91.90%的分支覆盖率，剩下的 8.1%对应着最复杂的业务逻辑、最深的嵌套条件、最古老的 corner case。

连 bug 一起搬，是设计目标

架构还有一个反直觉的设计，迁移后的 Java 必须和原 COBOL 行为完全一致，包括 bug。aldente0630 在 Hacker News 上澄清，保留 bug 是明确的设计目标，这叫 bug - for - bug compatibility，因为那些 bug 已经在生产环境跑了二十年，下游系统依赖它们的行为。但 bug - for - bug 有一个前提，Oracle 对比的是行为，不是代码，Java 程序员看到保留 bug 行为的代码时，没有任何上下文。

4KLOC 和 230KLOC

Hacker News 上的评论质疑了论文的规模。pacaro 给出真实世界的尺度，IRS 一家就有大约 160 个 COBOL 程序，平均每个 23 万行代码。fock 试过，他们用的代码里内嵌汇编，跨十几个文件、5 万行，测试的所有 LLM 完全不知道预处理器是什么。这指向了 Locksmith Loop 的真正边界，AST 转换器不认识源码里的预处理器宏、内嵌汇编等，会直接失败。Zenst 补充了精度问题，金融系统的 COBOL 程序通常使用 packed - decimal，其精度和舍入行为与 `BigDecimal` 并不完全等价，修复差异意味着在 Migrator 里写越来越复杂的规则。Locksmith Loop 的确定性架构方向是对的，但工程复杂度会随系统规模非线性增长。

COBOL - in - Java

dragonwriter 在 HN 上点出架构最深层的矛盾，唯一现实的低错误率方案是确定性转译，但得到的是 COBOL - in - Java，跑起来正确，但维护起来是噩梦。确定性转换的产物语法是 Java，灵魂是 COBOL，人类程序员做迁移时会重新理解系统意图，用新语言的惯用方式重新表达，这引入了风险，但能产出可维护代码，Migrator 选择了零风险路径，但付出了可维护性的代价，把没人懂的老系统变成了没人懂的新系统。

论文没说的东西

Locksmith Loop 的架构设计是对的，把 AI 限制在测试生成，把翻译和验证留给确定性代码，可能是 AI 在严肃软件工程中唯一可靠的使用方式。但它回避了一个更大的问题，迁移 COBOL 系统的真正瓶颈是理解这个系统在做什么。论文假设 Oracle 是给定的，但在真实场景里，COBOL 系统可能跑不起来，Oracle 本身就是一个需要重建的东西。这不是 Locksmith Loop 的错，这是一个验证方法论文，不是迁移工程论文。