把 GAMESS 的双电子积分核心从老式 Fortran 迁移到现代代码再用 Agentic Workflow 来管理这个过程听起来像是“AI 自动改写代码”的故事。但真按这个思路落地第一周就会被旧代码里的 COMMON 块、隐式类型、非标写法和全局数据拖住。我的看法是这个任务值得做也确实适合用智能体工作流来辅助但它本质上是工程改造不是生成式 AI 的炫技场。我会把整个流程拆开讲先理解双电子积分核心为什么是典型的遗留 HPC 代码再明确 Agentic Workflow 在这个场景里的定位然后按“基线准备、单函数转换、批量编排、验证回归、人工审查”的顺序走一遍最后说清楚哪些坑我会优先绕开。1. 先搞清楚这个改造任务的本质不是换语言是换执行模型1.1 GAMESS 的双电子积分核心为什么值得改造又难在哪儿GAMESS 是一套量子化学计算程序用于分子结构、电子结构、反应路径等方向的计算。它的历史非常长代码主体保留了大量的 FORTRAN 77 时代风格隐式类型声明、COMMON 块共享全局数据、GOTO 跳转、DO 循环里直接混着 I/O等等。这些代码在现代编译器上还能编但维护成本已经很高团队里新成员接手尤其痛苦。双电子积分two-electron integrals是量子化学计算里用于描述电子间库仑排斥作用的核心模块。它要处理的是四重重叠积分在分子轨道、原子轨道基组的展开下会产生海量组合。为了少算代码里通常还有大量对称性判断和精度阈值截断。所以它既是性能瓶颈也是代码复杂度最高的区域之一。在现代 HPC 环境里这套老代码的问题是“能跑但不顺”。老式 Fortran 写法依赖全局数组和固定大小分配不容易移植到 GPU也不容易做细粒度并行。编译器优化受限数据布局和计算核心也很难和现代 CPU 或加速器匹配。把它现代化不是为了追新而是为了让后续优化有立足点。但这部分代码恰好又是数值正确性最敏感的区域。一个整数溢出、一个阈值比较方式改变、一个数组顺序变化都可能让整个积分值偏离。改造时真正要守住的不是语法风格而是数值结果的一致性。1.2 Agentic Workflow 在这里不是“聊天生成代码”而是“带验证的任务编排”很多人一看到 Agentic 就觉得是从头到尾自动改完。真实场景里并不这样。Agentic Workflow 在这个场景里可以理解为把“改造双电子积分核心”这个大型任务拆成多个可由大模型驱动的智能体执行的小任务每个小任务都有明确输入、输出和验证条件。一个智能体做代码结构解析一个智能体负责生成现代 Fortran 或 C 版本另一个智能体写对照测试还有一个做编译错误修复。它们之间通过任务队列和结果反馈协作而不是一次性把整个文件丢给模型输出。这种设计和传统脚本自动化的区别在于工作流里多了条件判断和迭代循环。比如编译失败就自动把错误日志回传给改写智能体让它重新生成。比如数值比对不一致就触发人工复核。这些操作过去要靠工程师手动在终端和编辑器之间来回切换现在可以编排成一套半自动流水线。为什么这种模式适合双电子积分核心因为它属于“规则强、逻辑稳定、验证方式清楚”的模块。规则强智能体能较快理解结构逻辑稳定不会每两周变一次需求验证方式清楚只要能跑出同一组数值就能判断是否成功。这样的代码正是智能体工作流最适合先试水的类型。反过来如果代码库整体耦合很高、连依赖关系都无法梳理让智能体直接做全仓重构只会产出大量无法验证的代码。这个场景里的 Agent 并不是在替人做最终决定。它是把工程判断变成可执行步骤把重复劳动接过去最终决定权仍然在人和测试闭环这边。2. 改造前先把三样东西备好可编译仓库、数值基线、可重复环境很多团队一上来就让智能体改写代码结果改完没有东西可对照也不知道是变好还是变坏。我建议进入 Agentic Workflow 之前先做三件事。2.1 可编译仓库没有能跑的基线后面全是盲改第一步不是写 prompt也不是拉新语言框架而是先把旧代码完整、可重复地编译出来。对 GAMESS 这类老 HPC 项目这一步往往比你想象中要花时间。可能要选特定版本的编译器要匹配 BLAS、LAPACK、MPI 等数学库和并行库还要处理老旧的 Makefile 或 autotools 脚本。把“在当前机器上能编译通过”作为第一个里程碑。完成之后把编译命令、依赖版本、环境变量、你改过的任何参数全部记到仓库里。最好用一个脚本固化而不是依赖某个同事的 shell 历史。原因很直接如果我不能从零复现一次构建后面所有智能体生成的代码都无法进入验证环节因为你不知道它到底在跟哪个版本对照。如果条件允许还可以在 CI 里先加一个“总是能构建旧代码”的任务。哪怕只是简单的 build-only也能在早期挡住环境漂移带来的各种奇怪报错。2.2 数值基线用相同输入锁定参考输出有了可编译的旧程序下一步是运行一条“标准轨迹”把旧代码的数值结果锁定下来。我一般会选 2 到 3 个有代表性的小体系比如水分子、甲烷这类轻量分子用一组固定基组和计算设置生成参考输出。输出里至少要有积分值、总能量、梯度这些关键量。把所有结果保存成文件最好放进 git同时记下版本、编译器、优化选项和计算日期。基线的意义很明确它是后续所有改造的裁判。智能体改完一个函数我们不是问“写得对不对”而是问“跑出来的数值与基线差多少”。如果没有基线后面评判起来就是各说各话。需要注意基线里的“数值完全一致”有时是做不到的因为浮点运算顺序改变最后几位可能不同。所以基线不是简单的二进制 diff而是用给定阈值做判断。比如能量差控制在 1e-8 以内、积分值控制在 1e-10 以内具体阈值需要根据项目场景自己定。这里给的是通用思路不是固定标准。2.3 可重复环境容器化和依赖版本锁定减少环境噪声HPC 代码迁移非常容易翻车的地方是环境不一致。今天在这台机器能跑明天换集群就失败分不清是代码问题还是依赖问题。所以第三步是用容器或模块系统把环境固定下来。常见的做法有几种用 Docker 或 Singularity/Apptainer 打包编译环境用 Spack 或 EasyBuild 管理依赖版本在集群上用 module 文件锁死编译器、MPI 和数学库版本。选哪种工具不重要重要的是最终能做到“一份配置多处复现”。环境固定之后Agentic Workflow 里的编译和验证任务也会变简单。智能体提交新代码后工作流可以在同一个容器里编译、运行、比对避免出现“本地能跑、容器里崩了”这类干扰。很多人实际推进时会忽略这一点但环境噪声一旦混进来排查成本会迅速盖过 AI 节省下来的时间。这三件事做完你就有了一个稳定的改造舞台能编旧代码能拿旧结果环境可复现。接下来才轮到真正让智能体去改局部代码。3. 最小闭环让智能体先完成“单函数转换”而不是“全仓重构”进入 Agentic Workflow 后最该强调的一点是不要第一次就让工作流处理成千上万个函数。先从最小闭环开始把一个代表性函数从旧语言转换到现代语言跑通验证再逐步扩大范围。3.1 输入给 Agent 的上下文应该长什么样智能体不是魔法它只能基于上下文工作。所以 prompt 的质量直接决定输出质量。我一般会让 prompt 包含以下几块内容一段旧代码片段尽量带上所在文件路径和引用关系这个函数在双电子积分路径里的角色说明它依赖的公共块、数组、类型定义和外部函数目标语言和风格约束明确禁止改动的物理阈值、对称性判断和截断逻辑输出格式要求只给代码还是需要附带解释。举个简化示意假设旧代码里有一小段长这样SUBROUTINE COMPUTE_INTEGRAL(IA, IB, IC, ID, VAL) IMPLICIT DOUBLE PRECISION (A-H, O-Z) DIMENSION COEF_A(*), COEF_B(*), COEF_C(*), COEF_D(*) COMMON /BASDATA/ COEF_A(100), EXP_A(100) VAL 0.0D0 DO 10 I 1, NA DO 20 J 1, NB VAL VAL COEF_A(I) * COEF_B(J) * EXP_A(IJ) 20 CONTINUE 10 CONTINUE IF (DABS(VAL) .LT. THRESH) VAL 0.0D0 RETURN END注意这段代码只是示意不是 GAMESS 的真实代码但你能够看到典型特征隐式类型、COMMON 块、固定数组、DO 循环、阈值截断判断。给智能体的 prompt 可以写成你是一位熟悉量子化学和 HPC 代码迁移的工程师。 下面是一段 FORTRAN 77 风格的双电子积分计算示意代码。 请完成以下任务 1. 解释这段代码在计算什么分析它依赖哪些全局数据 2. 将其转换为现代 Fortran保持数值逻辑完全一致 3. 不要改变阈值判断条件不要改变循环顺序 4. 输出转换后的代码并列出你所做的关键改动。这个 prompt 的好处是给了边界。智能体不能自由发挥它的产出可以用后续测试严格验证。3.2 指定目标语言和约束避免自由发挥做 legacy HPC 现代化时目标语言可以有几种选择要根据项目实际人力、生态和后期的 HPC 优化方向来决定。常见选项包括现代 Fortran、C以及 Python 绑定。现代 Fortran 的优势是迁移路径短很多旧数据结构可以保留编译器和数学库生态成熟。C 的优势是表达力强更容易接入现代 CPU 向量化、GPU 框架和新的 HPC 库缺点是迁移时往往需要重写数据结构和内存管理。Python 绑定通常不是替代计算核心而是为上层调用提供接口。选定语言后还要定约束数值类型是否统一为 double precision是否允许 integer 使用多字节内存是否允许动态分配还是继续使用静态数组错误处理是否要求显式异常或返回错误码并行当前阶段是否引入 OpenMP还是保持串行可读性是否要求每个函数有注释和模块化结构。这些约束要尽量写进工作流配置里而不是依赖每个 prompt 碰运气。只要约束明确智能体生成的代码才有一致性。3.3 对照测试怎么写才能判断转换是否成功单函数转换成功后不能只看“编译通过”。要有一个最小对照测试把旧函数和新函数放到同一入口下传入相同参数比较输出。对照测试至少要覆盖典型输入正常范围的轨道指数、坐标和角动量边界输入接近零的阈值、接近极小值的系数对称输入交换指数后结果是否保持一致数值异常很大或很小的中间值会不会产生 NaN。对于双电子积分这类数值敏感代码我建议使用“绝对误差 相对误差”双重判断。如果旧输出是 1e-3 量级允许的绝对误差可以放松一点如果输出是 1e-12误差标准就要明显收紧。这个最小闭环跑通之后你才算真正验证了“Agentic Workflow 在本项目里可用”。如果连单个函数都不能稳定转换后面批量化的意义就不大。4. 从单函数到双电子积分核心批量改造的拆分与编排单函数跑通后很多人的第一反应是“直接让 Agent 把整个模块全部重写”。我建议别这么干。把任务拆小、分清依赖、限定范围成功率会高得多。4.1 按“读取—计算—写入”拆分任务而不是按文件拆老 HPC 代码里一个文件往往塞了几十个函数函数之间通过 COMMON 块或全局数组共享数据。如果按文件拆Agent 很容易在分析依赖时失控更合理的做法是按数据流拆。双电子积分核心可以粗略分成几块读取基组和组织输入数据计算单个积分的数学逻辑做对称性判断和阈值截断把结果写入积分子或能量累加器。每一块都可以是一个独立任务智能体只需要处理和它直接相关的输入输出不需要理解全部历史。拆分之后还要排优先级。优先处理计算热点、依赖关系简单、测试容易定义的函数把耦合很深、依赖很多模块的函数留到后面或者人工处理。我给 Agentic 流水线加任务队列时会记录每个函数的状态待转换、转换中、待验证、验证通过、人工复核。这样可以看到整个改造过程的瓶颈在哪儿而不是把任务丢进去黑盒跑几天再一起看结果。4.2 Agent 要能感知积分的对称性和精度阈值双电子积分核心有一个非常容易翻车的特性大量对称性判断和精度阈值截断。这些逻辑是物理和数学上的优化不是可有可无的边角料。比如同一组积分在交换电子标号时可以不重复计算某个中间量小于阈值时可以直接置零避免后面无意义的计算。智能体在改写循环时如果只是为了“简化代码”很容易把这些判断合并掉或者改变判断顺序结果就是数值结果出现偏差。所以在批量编排时我会把“保留对称性判断和阈值截断”作为一条硬约束写进所有相关任务。更稳妥的做法是单独让一个智能体做“约束抽取”先从旧代码里抽出一份阈值与对称性清单再交给改写智能体执行。这样可以把物理规则和代码重写解耦后面核对起来也更清楚。4.3 失败重试、人工介入和结果记录批量改造不是“跑完就成功”。它是一个迭代过程会持续产生编译失败、测试不通过、数值不一致等问题。所以工作流从一开始就要设计好失败处理路径。我的做法是给每个转换后的函数维护一条记录旧函数名、新函数名、目标路径、编译状态、测试状态、数值差异、人工评论。每次失败都自动把日志和对比结果回传到队列交给重试智能体或直接推给人工复核。伪代码大致是这样的for func in task_queue: if func in completed: continue generated ask_agent(build_prompt(func)) write_to_target(generated) if not compile_check(generated): push_back_to_queue(func, errorcompile_log) continue if not numeric_compare(func): mark_needs_review(func, diff_report) continue mark_completed(func)这里的ask_agent只是一个示意函数代表你选择的智能体调用方式。具体是用 API 还是本地模型是同步调用还是异步队列取决于实际环境。核心思路不变有失败就记录、回传、重试有差异就集中到人工队列。人工介入的触发点也要提前定义。比如连续三次重试仍失败或者数值差异超过阈值但没有明显错误时直接进入人工复核不要让它无限循环。Agent 处理常规情况效率很高但遇到物理和数值上的异常判断仍然需要人来做决定。5. 验证和收口数值一致性、性能回归、代码审查当所有任务完成整个积分核心都转换到现代语言后真正的验证才刚刚开始。很多团队在这里容易松懈以为“能编译、能跑通样例”就收工了结果回到完整分子体系上又翻车。5.1 数值一致性同一输入必须在小阈值内对齐数值一致性是第一道硬门槛。做法是把改造前后的程序在同样的输入文件、同样的硬件或兼容环境下各跑一遍然后对比关键输出。对于双电子积分核心来说不应该只比最终能量还要比积分本身。因为积分是后续所有计算的基础。如果最终能量对上了但积分数组存在细微差异很可能只是误差被后续步骤稀释但某些路径上会被放大。建议做三层对比单元级逐个函数对比输出模块级整个积分模块的输出总量和分布对比应用级全程序跑完的能量、梯度、轨道占据数对比。每一层都可以定一个阈值但数值结果允许极小的浮点差异。判断“是否通过”需要根据项目精度要求和历史经验来确定。5.2 性能回归现代化不能只把慢代码换个语言有时候智能体把旧 Fortran 改写成了很现代的代码单元测试也通过但在真实任务上反而比旧代码慢。原因不一定是智能体写错了而是它生成的循环结构和数据访问方式不符合现代 CPU 的缓存和向量化特性。所以性能回归是现代化项目的必选项。建议至少准备一个中等规模的基准测试记录改造前后的运行时间、峰值内存、多线程扩展性等指标。不要只看第一版的结果多次运行取中位数更靠谱。如果新代码只是提升了可读性但性能明显下降需要决定是否接受或者继续做性能优化。性能优化通常不是一次智能体重写就能完成的。还需要配合性能分析工具找到热点再针对循环、数据布局、向量化和并行度做专项优化。老代码虽然旧但往往经历过多轮手工调优某些方面不一定差。现代化的价值更多体现在扩展性和维护性上。5.3 代码审查人是最终负责人最后一道关 用Agentic Workflow将GAMESS双电子积分从Fortran迁移到现代HPC代码
把 GAMESS 的双电子积分核心从老式 Fortran 迁移到现代代码再用 Agentic Workflow 来管理这个过程听起来像是“AI 自动改写代码”的故事。但真按这个思路落地第一周就会被旧代码里的 COMMON 块、隐式类型、非标写法和全局数据拖住。我的看法是这个任务值得做也确实适合用智能体工作流来辅助但它本质上是工程改造不是生成式 AI 的炫技场。我会把整个流程拆开讲先理解双电子积分核心为什么是典型的遗留 HPC 代码再明确 Agentic Workflow 在这个场景里的定位然后按“基线准备、单函数转换、批量编排、验证回归、人工审查”的顺序走一遍最后说清楚哪些坑我会优先绕开。1. 先搞清楚这个改造任务的本质不是换语言是换执行模型1.1 GAMESS 的双电子积分核心为什么值得改造又难在哪儿GAMESS 是一套量子化学计算程序用于分子结构、电子结构、反应路径等方向的计算。它的历史非常长代码主体保留了大量的 FORTRAN 77 时代风格隐式类型声明、COMMON 块共享全局数据、GOTO 跳转、DO 循环里直接混着 I/O等等。这些代码在现代编译器上还能编但维护成本已经很高团队里新成员接手尤其痛苦。双电子积分two-electron integrals是量子化学计算里用于描述电子间库仑排斥作用的核心模块。它要处理的是四重重叠积分在分子轨道、原子轨道基组的展开下会产生海量组合。为了少算代码里通常还有大量对称性判断和精度阈值截断。所以它既是性能瓶颈也是代码复杂度最高的区域之一。在现代 HPC 环境里这套老代码的问题是“能跑但不顺”。老式 Fortran 写法依赖全局数组和固定大小分配不容易移植到 GPU也不容易做细粒度并行。编译器优化受限数据布局和计算核心也很难和现代 CPU 或加速器匹配。把它现代化不是为了追新而是为了让后续优化有立足点。但这部分代码恰好又是数值正确性最敏感的区域。一个整数溢出、一个阈值比较方式改变、一个数组顺序变化都可能让整个积分值偏离。改造时真正要守住的不是语法风格而是数值结果的一致性。1.2 Agentic Workflow 在这里不是“聊天生成代码”而是“带验证的任务编排”很多人一看到 Agentic 就觉得是从头到尾自动改完。真实场景里并不这样。Agentic Workflow 在这个场景里可以理解为把“改造双电子积分核心”这个大型任务拆成多个可由大模型驱动的智能体执行的小任务每个小任务都有明确输入、输出和验证条件。一个智能体做代码结构解析一个智能体负责生成现代 Fortran 或 C 版本另一个智能体写对照测试还有一个做编译错误修复。它们之间通过任务队列和结果反馈协作而不是一次性把整个文件丢给模型输出。这种设计和传统脚本自动化的区别在于工作流里多了条件判断和迭代循环。比如编译失败就自动把错误日志回传给改写智能体让它重新生成。比如数值比对不一致就触发人工复核。这些操作过去要靠工程师手动在终端和编辑器之间来回切换现在可以编排成一套半自动流水线。为什么这种模式适合双电子积分核心因为它属于“规则强、逻辑稳定、验证方式清楚”的模块。规则强智能体能较快理解结构逻辑稳定不会每两周变一次需求验证方式清楚只要能跑出同一组数值就能判断是否成功。这样的代码正是智能体工作流最适合先试水的类型。反过来如果代码库整体耦合很高、连依赖关系都无法梳理让智能体直接做全仓重构只会产出大量无法验证的代码。这个场景里的 Agent 并不是在替人做最终决定。它是把工程判断变成可执行步骤把重复劳动接过去最终决定权仍然在人和测试闭环这边。2. 改造前先把三样东西备好可编译仓库、数值基线、可重复环境很多团队一上来就让智能体改写代码结果改完没有东西可对照也不知道是变好还是变坏。我建议进入 Agentic Workflow 之前先做三件事。2.1 可编译仓库没有能跑的基线后面全是盲改第一步不是写 prompt也不是拉新语言框架而是先把旧代码完整、可重复地编译出来。对 GAMESS 这类老 HPC 项目这一步往往比你想象中要花时间。可能要选特定版本的编译器要匹配 BLAS、LAPACK、MPI 等数学库和并行库还要处理老旧的 Makefile 或 autotools 脚本。把“在当前机器上能编译通过”作为第一个里程碑。完成之后把编译命令、依赖版本、环境变量、你改过的任何参数全部记到仓库里。最好用一个脚本固化而不是依赖某个同事的 shell 历史。原因很直接如果我不能从零复现一次构建后面所有智能体生成的代码都无法进入验证环节因为你不知道它到底在跟哪个版本对照。如果条件允许还可以在 CI 里先加一个“总是能构建旧代码”的任务。哪怕只是简单的 build-only也能在早期挡住环境漂移带来的各种奇怪报错。2.2 数值基线用相同输入锁定参考输出有了可编译的旧程序下一步是运行一条“标准轨迹”把旧代码的数值结果锁定下来。我一般会选 2 到 3 个有代表性的小体系比如水分子、甲烷这类轻量分子用一组固定基组和计算设置生成参考输出。输出里至少要有积分值、总能量、梯度这些关键量。把所有结果保存成文件最好放进 git同时记下版本、编译器、优化选项和计算日期。基线的意义很明确它是后续所有改造的裁判。智能体改完一个函数我们不是问“写得对不对”而是问“跑出来的数值与基线差多少”。如果没有基线后面评判起来就是各说各话。需要注意基线里的“数值完全一致”有时是做不到的因为浮点运算顺序改变最后几位可能不同。所以基线不是简单的二进制 diff而是用给定阈值做判断。比如能量差控制在 1e-8 以内、积分值控制在 1e-10 以内具体阈值需要根据项目场景自己定。这里给的是通用思路不是固定标准。2.3 可重复环境容器化和依赖版本锁定减少环境噪声HPC 代码迁移非常容易翻车的地方是环境不一致。今天在这台机器能跑明天换集群就失败分不清是代码问题还是依赖问题。所以第三步是用容器或模块系统把环境固定下来。常见的做法有几种用 Docker 或 Singularity/Apptainer 打包编译环境用 Spack 或 EasyBuild 管理依赖版本在集群上用 module 文件锁死编译器、MPI 和数学库版本。选哪种工具不重要重要的是最终能做到“一份配置多处复现”。环境固定之后Agentic Workflow 里的编译和验证任务也会变简单。智能体提交新代码后工作流可以在同一个容器里编译、运行、比对避免出现“本地能跑、容器里崩了”这类干扰。很多人实际推进时会忽略这一点但环境噪声一旦混进来排查成本会迅速盖过 AI 节省下来的时间。这三件事做完你就有了一个稳定的改造舞台能编旧代码能拿旧结果环境可复现。接下来才轮到真正让智能体去改局部代码。3. 最小闭环让智能体先完成“单函数转换”而不是“全仓重构”进入 Agentic Workflow 后最该强调的一点是不要第一次就让工作流处理成千上万个函数。先从最小闭环开始把一个代表性函数从旧语言转换到现代语言跑通验证再逐步扩大范围。3.1 输入给 Agent 的上下文应该长什么样智能体不是魔法它只能基于上下文工作。所以 prompt 的质量直接决定输出质量。我一般会让 prompt 包含以下几块内容一段旧代码片段尽量带上所在文件路径和引用关系这个函数在双电子积分路径里的角色说明它依赖的公共块、数组、类型定义和外部函数目标语言和风格约束明确禁止改动的物理阈值、对称性判断和截断逻辑输出格式要求只给代码还是需要附带解释。举个简化示意假设旧代码里有一小段长这样SUBROUTINE COMPUTE_INTEGRAL(IA, IB, IC, ID, VAL) IMPLICIT DOUBLE PRECISION (A-H, O-Z) DIMENSION COEF_A(*), COEF_B(*), COEF_C(*), COEF_D(*) COMMON /BASDATA/ COEF_A(100), EXP_A(100) VAL 0.0D0 DO 10 I 1, NA DO 20 J 1, NB VAL VAL COEF_A(I) * COEF_B(J) * EXP_A(IJ) 20 CONTINUE 10 CONTINUE IF (DABS(VAL) .LT. THRESH) VAL 0.0D0 RETURN END注意这段代码只是示意不是 GAMESS 的真实代码但你能够看到典型特征隐式类型、COMMON 块、固定数组、DO 循环、阈值截断判断。给智能体的 prompt 可以写成你是一位熟悉量子化学和 HPC 代码迁移的工程师。 下面是一段 FORTRAN 77 风格的双电子积分计算示意代码。 请完成以下任务 1. 解释这段代码在计算什么分析它依赖哪些全局数据 2. 将其转换为现代 Fortran保持数值逻辑完全一致 3. 不要改变阈值判断条件不要改变循环顺序 4. 输出转换后的代码并列出你所做的关键改动。这个 prompt 的好处是给了边界。智能体不能自由发挥它的产出可以用后续测试严格验证。3.2 指定目标语言和约束避免自由发挥做 legacy HPC 现代化时目标语言可以有几种选择要根据项目实际人力、生态和后期的 HPC 优化方向来决定。常见选项包括现代 Fortran、C以及 Python 绑定。现代 Fortran 的优势是迁移路径短很多旧数据结构可以保留编译器和数学库生态成熟。C 的优势是表达力强更容易接入现代 CPU 向量化、GPU 框架和新的 HPC 库缺点是迁移时往往需要重写数据结构和内存管理。Python 绑定通常不是替代计算核心而是为上层调用提供接口。选定语言后还要定约束数值类型是否统一为 double precision是否允许 integer 使用多字节内存是否允许动态分配还是继续使用静态数组错误处理是否要求显式异常或返回错误码并行当前阶段是否引入 OpenMP还是保持串行可读性是否要求每个函数有注释和模块化结构。这些约束要尽量写进工作流配置里而不是依赖每个 prompt 碰运气。只要约束明确智能体生成的代码才有一致性。3.3 对照测试怎么写才能判断转换是否成功单函数转换成功后不能只看“编译通过”。要有一个最小对照测试把旧函数和新函数放到同一入口下传入相同参数比较输出。对照测试至少要覆盖典型输入正常范围的轨道指数、坐标和角动量边界输入接近零的阈值、接近极小值的系数对称输入交换指数后结果是否保持一致数值异常很大或很小的中间值会不会产生 NaN。对于双电子积分这类数值敏感代码我建议使用“绝对误差 相对误差”双重判断。如果旧输出是 1e-3 量级允许的绝对误差可以放松一点如果输出是 1e-12误差标准就要明显收紧。这个最小闭环跑通之后你才算真正验证了“Agentic Workflow 在本项目里可用”。如果连单个函数都不能稳定转换后面批量化的意义就不大。4. 从单函数到双电子积分核心批量改造的拆分与编排单函数跑通后很多人的第一反应是“直接让 Agent 把整个模块全部重写”。我建议别这么干。把任务拆小、分清依赖、限定范围成功率会高得多。4.1 按“读取—计算—写入”拆分任务而不是按文件拆老 HPC 代码里一个文件往往塞了几十个函数函数之间通过 COMMON 块或全局数组共享数据。如果按文件拆Agent 很容易在分析依赖时失控更合理的做法是按数据流拆。双电子积分核心可以粗略分成几块读取基组和组织输入数据计算单个积分的数学逻辑做对称性判断和阈值截断把结果写入积分子或能量累加器。每一块都可以是一个独立任务智能体只需要处理和它直接相关的输入输出不需要理解全部历史。拆分之后还要排优先级。优先处理计算热点、依赖关系简单、测试容易定义的函数把耦合很深、依赖很多模块的函数留到后面或者人工处理。我给 Agentic 流水线加任务队列时会记录每个函数的状态待转换、转换中、待验证、验证通过、人工复核。这样可以看到整个改造过程的瓶颈在哪儿而不是把任务丢进去黑盒跑几天再一起看结果。4.2 Agent 要能感知积分的对称性和精度阈值双电子积分核心有一个非常容易翻车的特性大量对称性判断和精度阈值截断。这些逻辑是物理和数学上的优化不是可有可无的边角料。比如同一组积分在交换电子标号时可以不重复计算某个中间量小于阈值时可以直接置零避免后面无意义的计算。智能体在改写循环时如果只是为了“简化代码”很容易把这些判断合并掉或者改变判断顺序结果就是数值结果出现偏差。所以在批量编排时我会把“保留对称性判断和阈值截断”作为一条硬约束写进所有相关任务。更稳妥的做法是单独让一个智能体做“约束抽取”先从旧代码里抽出一份阈值与对称性清单再交给改写智能体执行。这样可以把物理规则和代码重写解耦后面核对起来也更清楚。4.3 失败重试、人工介入和结果记录批量改造不是“跑完就成功”。它是一个迭代过程会持续产生编译失败、测试不通过、数值不一致等问题。所以工作流从一开始就要设计好失败处理路径。我的做法是给每个转换后的函数维护一条记录旧函数名、新函数名、目标路径、编译状态、测试状态、数值差异、人工评论。每次失败都自动把日志和对比结果回传到队列交给重试智能体或直接推给人工复核。伪代码大致是这样的for func in task_queue: if func in completed: continue generated ask_agent(build_prompt(func)) write_to_target(generated) if not compile_check(generated): push_back_to_queue(func, errorcompile_log) continue if not numeric_compare(func): mark_needs_review(func, diff_report) continue mark_completed(func)这里的ask_agent只是一个示意函数代表你选择的智能体调用方式。具体是用 API 还是本地模型是同步调用还是异步队列取决于实际环境。核心思路不变有失败就记录、回传、重试有差异就集中到人工队列。人工介入的触发点也要提前定义。比如连续三次重试仍失败或者数值差异超过阈值但没有明显错误时直接进入人工复核不要让它无限循环。Agent 处理常规情况效率很高但遇到物理和数值上的异常判断仍然需要人来做决定。5. 验证和收口数值一致性、性能回归、代码审查当所有任务完成整个积分核心都转换到现代语言后真正的验证才刚刚开始。很多团队在这里容易松懈以为“能编译、能跑通样例”就收工了结果回到完整分子体系上又翻车。5.1 数值一致性同一输入必须在小阈值内对齐数值一致性是第一道硬门槛。做法是把改造前后的程序在同样的输入文件、同样的硬件或兼容环境下各跑一遍然后对比关键输出。对于双电子积分核心来说不应该只比最终能量还要比积分本身。因为积分是后续所有计算的基础。如果最终能量对上了但积分数组存在细微差异很可能只是误差被后续步骤稀释但某些路径上会被放大。建议做三层对比单元级逐个函数对比输出模块级整个积分模块的输出总量和分布对比应用级全程序跑完的能量、梯度、轨道占据数对比。每一层都可以定一个阈值但数值结果允许极小的浮点差异。判断“是否通过”需要根据项目精度要求和历史经验来确定。5.2 性能回归现代化不能只把慢代码换个语言有时候智能体把旧 Fortran 改写成了很现代的代码单元测试也通过但在真实任务上反而比旧代码慢。原因不一定是智能体写错了而是它生成的循环结构和数据访问方式不符合现代 CPU 的缓存和向量化特性。所以性能回归是现代化项目的必选项。建议至少准备一个中等规模的基准测试记录改造前后的运行时间、峰值内存、多线程扩展性等指标。不要只看第一版的结果多次运行取中位数更靠谱。如果新代码只是提升了可读性但性能明显下降需要决定是否接受或者继续做性能优化。性能优化通常不是一次智能体重写就能完成的。还需要配合性能分析工具找到热点再针对循环、数据布局、向量化和并行度做专项优化。老代码虽然旧但往往经历过多轮手工调优某些方面不一定差。现代化的价值更多体现在扩展性和维护性上。5.3 代码审查人是最终负责人最后一道关