把几百行旧代码翻译成新语言不难，难的是让一套运行数十年的工程系统在重构后仍给出同样结果。9月9日，Mistral披露与一家欧洲能源运营商的遗留代码迁移实践：目标系统约30万行Fortran 77，第一阶段迁移了4万行核心功能到C++。这不是一次“提示词生成代码”的演示，而是一场围绕数值一致性、文档恢复、Agent分工和人工验收的交付复盘。

迁移的第一产物不是C++，而是对照基线

这套水库模拟程序没有完整测试套件，核心状态散落在COMMON全局内存中，变量还会按首字母隐式确定类型。一个拼写错误可能悄悄生成新变量，编译器并不会替团队报警。若直接让模型改写，代码即使能编译、能运行，也无法证明物理结果没有漂移。

项目组先让Fortran程序导出最终状态和关键中间状态，再在C++侧建立测试框架逐项比对。哪些中间变量真正影响水库计算，由领域工程师确认。随后每个迁移模块都必须通过同一套数值奇偶性检查。这个投入看似没有产出新功能，却让长时间Agent任务变得可判断、可回滚，也给业务方提供了最直观的完成证据。

百余Agent先恢复“系统为什么这样写”

旧系统的说明散落在早期PDF、代码注释和工程师经验里。团队先解析程序，生成完整的调用者—被调用者树，再用百余个Agent从叶子模块向上阅读、解释和提交文档。老PDF还要经过文字识别，结果与代码对照后才能合并。这样做把隐藏知识放回代码旁，也减少多个Agent对同一全局状态做出互相矛盾的猜测。

文档工作并非一次性生成。Agent提交变更，定时审查循环发现问题后再开修订任务，工程师最终检查合并。对企业而言，这一层比换模型更关键：如果输入知识仍旧不可读，模型能力越强，只会以更快速度扩大误解。

调用树还给并行化提供了边界。底层模块先被解释和验证，上层Agent才使用已经确认的接口和语义，避免百余任务同时改动同一片全局状态。由依赖关系决定顺序，比按文件数量平均分配更接近真实工程，也方便在某个分支失败时只回退局部。

两次失败说明，全自治并不等于低成本

第一条路线让一个Agent在一周内负责一个子程序，得到的代码可以运行，却几乎只是把Fortran逐句搬到C++：全局结构和跳转逻辑被原样保留，维护性没有真正改善。第二条路线引入规划、编码、测试、审查多个Agent，结构更好，但复杂错误出现后容易停滞，额外协调也没有自动换来收敛。

最终采用的是受控中间路线：人操作编码、测试和审查Agent，按模块推进，把经验上规模控制在不足一万行的子树；架构先由水库工程师审核，再拆成任务队列，循环执行计划、实现、测试与修订，最终仍由人审查合并请求。4万行首期成果建立在原系统可运行、自包含的有利条件上，依赖外部系统或缺失物理知识的项目会更难。

这里的人工闸门并不是让专家逐行手写，而是把稀缺判断放在架构、验收点和异常处理上。Agent承担重复阅读、初稿和测试修复，领域专家确认物理含义，软件工程师决定模块边界。三种角色各守一段责任，才能避免“能跑”被误当成“已经现代化”。

小编判断：Agent迁移的核心指标是可证明

这次复盘最有价值的结论，是把“写了多少新代码”降到次要位置。遗留系统改造首先要证明行为一致，其次才是重构质量和速度。对照框架、可读文档、有限任务边界和人工闸门共同构成了交付系统，模型只是其中的执行能力。

企业复制时应记录每个模块的数值偏差、一次通过率、人工介入次数、故障恢复时间、审查退回率和最终维护复杂度。若只有迁移行数，没有可重复测试与回滚路径，所谓Agent自动化只是把技术债从旧语言搬到新语言，甚至让下一轮维护更难追溯，并拖累审计与交接。