量子化学从业者大概都遇到过这样的场景你要给一个跑了二十年的 Fortran 模块加新功能或者把它移植到新的算力平台上结果打开源码的那一刻看到的是绵延上千行的 GOTO、隐式声明、缩写到无法辨认的变量名以及一段被无数人修改过、注释却只有十几行的双电子积分代码。GAMESS 里的两电子积分核心就是这种“历史遗产”的典型。它不算最老的代码但足够老足够重要也足够复杂。这些年大家常说“AI 能写代码了”但真正面对这种遗留 HPC 代码时普遍的感受是让大模型直接重写根本不现实——不是因为模型看不懂 Fortran而是因为“看懂”和“在数值语义完全等价的前提下替换进真实计算流程”之间隔着巨大的鸿沟。于是有人开始把多个 AI 代理Agent组合成一个工作流Agentic Workflow试图让它去完成“理解旧代码 → 拆解逻辑 → 生成新代码 → 自动验证”的完整链路。我的主判断是Agentic Workflow 用在遗留 HPC 代码现代化上真正的价值不是“一键自动迁移”而是把一次原本不可控的、依赖个别人经验的重构过程变成一段可追踪、可迭代、可复用的工程流程。它能不能成功不只看模型强不强更看你怎么设计任务边界、验证反馈和人工节点。下面用 GAMESS 双电子积分核心作为具体对象拆开讲一遍。1. 为什么要用 Agentic Workflow 动 GAMESS 这种老代码1.1 GAMESS 双电子积分核心到底难在哪里GAMESS 是一款在计算化学领域用了很多年的量子化学程序包用来做 HF、DFT、MP2 这类从头算计算。双电子积分two-electron integrals是它的核心模块之一负责计算电子与电子之间库仑相互作用在基函数下的矩阵元。听起来只是一堆数学公式的数值实现但实际代码里有几个极其麻烦的特征。第一索引映射复杂。双电子积分通常表示为 (μν|λσ)涉及四个基函数指标。由于积分存在置换对称性代码里会大量利用对称关系压缩计算范围只计算唯一的积分组合然后通过索引映射复用结果。这种映射逻辑往往通过几层嵌套循环和位运算实现对人类阅读非常不友好。第二数值路径长。一个积分从基函数求值、辅助函数递推、角度动量提升到最终累加中间可能有十几层函数调用。任何一层改错都会导致最终数值出现微小偏差。更麻烦的是这种偏差在简单的分子上可能不明显只有在特定基组、特定几何构型下才会暴露。第三性能导向的代码结构。为了在 HPC 上跑得快原代码里有大量循环展开、临时数组复用、过程内共享变量、甚至通过等价语句优化的痕迹。这些代码用现代 Fortran 或 C 重写时如果直接“翻译”性能可能降一个数量级如果为了性能重构又容易出现语义偏差。所以你会发现双电子积分模块不是不能重写而是重写的风险极高。过去的方法一般是靠少数资深开发人员手工完成周期以月甚至年计。慢的原因不是写代码慢而是“理解旧代码的隐含语义”和“验证新代码的数值等价性”非常耗时。1.2 “现代化”不是换语言而是把可维护性找回来很多人一听到“现代化”第一反应是把 Fortran 改成 C 或 CUDA。但真正的现代化工序不仅仅是换语言。GAMESS 的问题不只是“语言老”还包括全局变量和隐式状态太多无法单元测试。模块边界不清晰改动一处可能影响完全无关的功能。构建系统复杂但缺少自动化回归测试。注释和文档缺失知识都留在少数人的头脑里。在这种情况下即便你保用 AI 把 Fortran 逐行转成 C得到的还是一堆“现代语言的旧代码”。该难维护还是难维护该难验证还是难验证。所以“现代化”的核心目标是让代码变得可以被理解、被测试、被增量修改。而 Agentic Workflow 恰好能在“理解”“测试”“增量修改”这三个环节给予辅助。1.3 Agentic Workflow 能解决这个问题的几层原因Agentic Workflow 比单纯的“大模型聊天窗口输代码”更进一步。它不是只生成一次代码而是让多个代理分工协作围绕一个目标完成多轮推理、尝试和校验。在遗留代码迁移场景里这能解决几个具体问题解决“看不懂”的问题分析代理可以阅读旧代码提取数据流、函数调用关系、变量含义生成结构说明和注释供后续代码生成使用。解决“生成一次不靠谱”的问题代码生成代理可以结合分析结果和测试反馈反复修改而不是一次性输出一个大概率有 bug 的完整文件。解决“验证难”的问题验证代理可以对比新旧代码的输出自动计算误差把“看起来差不多”变成可以量化的指标。解决“过程不可审计”的问题每次代理解读、决策、生成、验证都会留下记录人工可以随时介入不会黑箱化。当然这些能力不会天然出现。如果只是拉一个很大的 prompt 塞进去然后让模型“尽量迁移”结果大概率是失败。所以真正重要的是设计工作流本身。2. 设计一个可落地的 Agentic Workflow从任务拆分到验证回归2.1 先明确目标最小可替换单元而不是一次性全量迁移做 HPC 代码现代化时最忌讳的是一上来就说“把整个 GAMESS 迁移到新架构”。范围太大AI 代理根本无法在有限上下文里理解人工审查也没有抓手。更聪明的做法是选择一个最小可替换单元Minimal Replaceable Unit。什么是“最小可替换单元”的合适粒度我建议这样判断这个单元有清晰的输入和输出。这个单元可以被单独调用或单独测试。这个单元的计算逻辑是自治的不依赖大量隐藏的全局状态。迁移后可以用原有的外部接口封装作为局部替换。在 GAMESS 双电子积分模块里一个合适的单元可以是“计算某个特定角动量组合、某个基组下的一批积分”的函数。例如把计算 s 和 p 型基函数双电子积分的某一组内核函数拿出来先做迁移。先跑通局部替换再逐步放大范围。这样做的原因有两点一是给 Agent 工作流设定一个够得着的目标二是降低验证复杂度。验证单个函数的数值输出远比验证整个模块容易。2.2 工作流的核心步骤理解、拆分、生成、验证、反馈我把一个可落地的 Agentic Workflow 分成五个阶段这五个阶段不是先后执行一次就结束而是形成循环理解Understand读取旧代码文件和相关文档生成代码结构说明、函数依赖图、数据流转描述。这个阶段的目标是让人工和后续代理都能“看懂”。拆分Decompose将一个较大的迁移目标拆成若干个子任务。子任务之间有清晰的接口契约例如函数签名、输入输出格式、允许误差范围。生成Generate代码生成代理根据子任务描述和旧代码实现生成新代码。这里可以生成多个候选版本不一定只生成一次。验证Verify自动编译、运行测试用例对比旧代码输出。验证结果会反馈给生成阶段如果失败生成代理需要修改。审查Review人工审查关键代码和验证报告决定是否接受或继续迭代。这个流程的核心思想是让 AI 代理在“理解”和“验证”两个约束下工作而不是裸奔。没有理解约束生成代码会跑偏没有验证约束生成代码的缺陷不会被发现。2.3 任务编排和代理分工分析代理、代码生成代理、验证代理在实际落地时我不建议把整个流程塞给一个 Agent。更好的方式是让多个专业代理各司其职通过一个调度器或脚本编排。常见的代理角色有代理角色主要职责产生结果分析代理读 Fortran 代码生成解释、依赖图、注释、潜在语义陷阱说明结构化文档或自然语言描述计划代理根据分析结果做任务拆分生成子任务清单和接口契约任务 JSON 或 Markdown 计划代码生成代理针对单个子任务编写新语言代码并自解释代码文件、变更说明验证代理编译、运行、对比输出生成测试报告和误差指标验证报告、错误摘要反馈代理可选汇总验证失败信息把结构化错误反馈给生成代理问题文本、重试建议这种分工要求每个代理的 prompt 都很聚焦上下文不会被无关内容撑爆。比如验证代理不需要理解完整数学推导只需要按照既定测试命令运行并比对结果。代码生成代理需要理解积分算法但不需要关心整个 GAMESS 的构建系统。调度方式上可以先走一个简单的 Python 脚本按阶段调用不同 LLM 接口也可以使用开源的 Agent 框架。重要的是把每个代理的输入、输出定义为结构化对象例如函数签名、文件路径、测试结果 JSON。这样即使更换 LLM工作流仍然可复用。2.4 关键数据流上下文、代码块、测试用例、反馈循环设计 Agentic Workflow 时最容易忽略的是“数据在每个代理之间如何流动”。以迁移一个双电子积分函数为例数据流大概是分析代理输出一段关于旧函数form_2e_integrals的说明包括参数含义、循环结构、用到的递推公式、可能的对称性使用。计划代理输出拆分任务例如“先实现基函数求值函数bas_fns再实现角度递推函数add_angular最后实现主积分函数”。代码生成代理输出针对bas_fns的 C 版本代码附带伪代码注释。验证代理输入一个测试脚本调用新旧两个函数传入相同的基组参数和几何坐标输出数值数组。验证代理输出最大绝对误差、平均误差、是否通过容差比如 1e-9以及失败时定位到具体数组索引。反馈循环的关键是验证失败时不能只告诉代码生成代理“输出不对”而要提供结构化信息比如“索引 (1,2,3,4) 的期望值是 0.123456实际是 0.987654对应旧代码中的缩放因子可能未处理”。这需要验证代理具备一定诊断能力而不是简单 diff。因此在工作流设计阶段最好提前定义好测试用例的目录结构、文件名规则、输出日志格式。否则当任务规模变大后代理之间的交互会迅速失控。3. 具体落地过程分阶段拆解一个双电子积分函数迁移3.1 阶段一建立基线——运行旧模块收集输出作为 oracle在让任何 AI 代理开始迁移之前第一件事是建立可重复的运行基线。你不可能在没有基准输出的前提下验证新代码是否正确。以双电子积分模块为例基线做法是选一个小的测试分子比如水分子或甲胺使用一个中等大小的基组例如 6-31G*。在原有 GAMESS 环境中写一个调用双电子积分模块的小驱动程序输出指定积分的原始数值。如果原模块不容易单独调用可以修改 GAMESS 源码在积分函数入口和出口打印关键数组。保存输出到文件作为 oracle基准答案。这里有一个常见做法不直接对比最终能量等宏观量而是对比“积分裸值”。宏观量经过多次矩阵运算后会掩盖局部误差而对比积分裸值能立刻定位到具体函数。你可以把积分结果按照“壳层对”组织按固定顺序输出成一个长数组方便和后续新代码对比。基线建立之后还要写一个简单的 diff 脚本能比较两个文本或二进制文件输出最大绝对误差和对应的索引。这个脚本就是验证代理的核心工具。3.2 阶段二让模型理解原 Fortran 代码的结构和数学含义给大模型丢一堆 Fortran 文件直接让它迁移通常效果不好。因为 Fortran 代码的可读性差而且大量隐含语义没有写在注释里。你需要先启动一个分析代理让它做几件事阅读单个源文件不要一次给多个大文件提取主函数和子函数列表。对每个函数说明参数含义、返回内容、关键变量。特别标注非局部操作公共块COMMON、模块变量、文件作用域的全局变量这些是迁移时的最大风险点。识别数值算法例如 Rys 积分、McMurchie-Davidson 递推、Pople-Hehre 展开等。如果模型见过类似算法通常能给出很多有用的解释。分析代理的产出不一定是完整的“文档”也可以是结构化 JSON。比如{ function: twopd, parameters: [ {name: x, type: real*8, meaning: 基函数中心 x 坐标}, {name: ex, type: real*8, meaning: 指数参数} ], global_vars: [c, n], uses_symmetry: true, algorithm_hint: Pople-Hehre loop }这个结构会作为代码生成代理的上下文之一。优点是可以过滤掉噪声让生成代理专注于“怎么实现”而不是“这段代码在干嘛”。3.3 阶段三生成新语言代码C/CUDA 或更现代 Fortran生成阶段最重要的原则是一个子任务一个函数不要让代码生成代理一次性生成整个模块。例如你可以先让代码生成代理迁移“双电子积分壳层对索引映射”这个辅助函数。这是一个小函数输入是四个角动量 l1, l2, l3, l4 和壳层编号输出是积分矩阵的线性索引。它没有浮点计算只是索引逻辑。迁移难度低但如果不做对后面全错。生成时prompt 需要包含子任务描述来自计划代理。旧代码片段对应的 Fortran 函数。分析代理生成的结构化说明可选。目标语言规范例如“C17不要使用动态内存分配使用固定大小数组”。函数签名模板方便验证代理调用。要求强类型、显式接口、避免全局变量。这里要提醒一点代码生成代理可能会“过拟合”训练数据做出不存在的 API 调用或假设某些库可用。在 prompt 里尽量声明“只能使用标准库和已经存在的依赖不要发明新依赖”。生成代码后代码生成代理应该先自己读一遍检查明显的编译错误。实际上现在不少模型在生成后可以调用一个“代码自检”工具尝试 compile 或 syntax check。这样能在验证阶段之前排除掉大量低级错误。3.4 阶段四自动化测试对比输出、误差分析验证阶段要做的事情比想象中要多。不是“跑一下误差小于 1e-8 就通过”这么简单。首先如果新代码是用 C 写的你要有一个胶水层让它能被 Fortran 主程序调用或者反过来。常见方式有用iso_c_binding写 Fortran 接口包装 C 函数或者干脆写一个独立的 C 测试可执行文件从文件读取输入、输出数值。对于双电子积分这种纯计算函数独立可执行文件更简单不依赖 GAMESS 的构建系统。其次测试用例要覆盖边界。你可以准备几个不同的测试分子和基组至少包括单原子、s 型基组测试最简单的路径。双原子、含 p 型基组测试角动量增量和对称路径。含 d 型基组测试高阶递推和归一化因子。非对称几何打破部分对称性避免新代码错误地依赖了对称性。第三误差分析要有层次。不能只看最大误差还要看误差分布误差集中在哪些索引相对误差和绝对误差接近零的积分是否允许较大的绝对误差是否出现 NaN 或 Inf。性能退化即使数值正确新代码如果慢 100 倍也需要在报告中标记出来。验证代理要把这些信息整理成报告。报告要足够结构化让代码生成代理能读懂并迭代。3.5 阶段五人工审查和迭代最后一个阶段是人工审查但这不是一个“走过程”的环节。我觉得可以这样定义人工审查的价值审查 AI 无法判断的“长期维护性”问题比如命名风格、模块边界是否合理。审查数值算法近似。AI 可能选择了看似等价但在极端条件下不稳定的实现专家需要判断。审查性能设计。AI 生成的代码如果不做循环展开或向量化可能在正确性通过后被性能优化挡住。决定是否接受或者给生成代理提出新的约束进入下一轮迭代。人工审查不需要五行五行看代码而要看验证报告、代码结构、关键数学路径的注释。因此前面的代理输出质量会直接影响审查效率。如果工作流设计得好一个人可以在一天内审查十几个小函数的迁移结果。4. 实际执行中最容易踩的坑和排查路径4.1 输入输出边界不清生成代码正确率容易被高估很多 Agentic Workflow 第一次跑下来验证通过率看起来很高于是人会觉得“AI 好强”。但紧接着换个测试分子就崩了原因往往是输入输出边界没有定义清楚。比如原 Fortran 双电子积分函数可能隐式依赖某个全局数组sh_info里面存着所有壳层的中心坐标和指数。旧代码在调用前已经初始化了sh_info新代码如果不了解这个依赖就只能在函数内部猜测参数。一旦外部数据顺序变化结果完全错误。处理方式分析代理在“理解”阶段必须显式列出所有隐式依赖。如果发现隐藏全局变量一种做法是把它们改成显式参数传入但这样接口会变得很复杂另一种做法是在测试中复现同样的初始化流程然后再调用新函数。建议根据函数是否频繁调用决定。另外Fortran 数组索引默认从 1 开始C 从 0 开始。迁移时如果漏掉索引偏移就会产生系统性错位。这个问题在 AI 生成的代码里很常见。排查时建议写一个简单的索引检查输出少量非零积分的原始索引和旧代码逐一对比。通常几组数据就能暴露出索引偏移问题。4.2 数值精度和排列组合问题双电子积分有大量对称性和索引映射双电子积分模块最大的隐藏雷区是“对称性利用”。旧代码为了减少计算量通常只计算一部分积分然后通过对称关系映射到所有积分。新代码可能“简化”了逻辑把每个 (μν|λσ) 都直接算一遍。这样数值正确性也许没问题但性能会大幅下降。更糟糕的是如果新代码错误地以为可以直接计算所有组合却漏掉了某些缩并因子结果在能量计算中会出现系统性错误。解决办法在验证报告里同时输出“积分数量”和“唯一积分数量”。对比新旧代码计算的唯一积分数和总积分数量是否一致。如果数量偏差大说明对称性处理出了问题。同时要注意数值精度问题。Fortran 的real*8对应 C 的double但如果原代码在某些位置使用了扩展精度或 Kahan 求和新代码需要用同样策略否则累加误差会积累。建议验证时不要只看一个分子至少用三个不同大小、不同对称性的分子对比并统计误差分布。还有一个常见坑是预处理宏和编译器优化。GAMESS 的源码可能有#ifdef分支不同编译选项下计算路径不同。分析代理如果忽略了这些宏生成的代码可能只符合某一条编译路径换一个宏开关就出错。所以工作流里要明确记录编译选项并在测试时覆盖主要分支。4.3 Agent 上下文爆掉、生成不完整、格式漂移怎么处理用大模型读很长的源代码文件时上下文限制是个现实问题。GAMESS 的积分模块可能有数千甚至上万行一个函数也可能几百行。直接塞进模型的 context往往会导致模型忘记前面的定义或者生成到一半截断。应对策略有三个更细的拆分把函数按“计算辅助量、递推公式、组合矩阵”等子逻辑拆出独立小函数每个小函数单独迁移。结构化摘要代替原始代码分析代理先产生一份高度浓缩的规格说明代码生成代理主要读规格说明而不是读几千行原始 Fortran。需要原始代码时再局部拉取。使用文件分段工具如果只是需要某个函数的特定片段可以使用脚本提取函数定义范围再给模型。格式漂移也是常见问题。模型生成的代码可能突然插入 Markdown 标记、重复函数名、漏掉大括号。验证代理最好在编译之前先做格式检查比如用clang-format或简单括号配对检查。这个环节不需要 AI传统脚本工具反而更可靠。4.4 验证代理不可靠如何设计 oracle 和容差如果验证代理的判断本身是错误的整个工作流会变成“错误确认另一个错误”。所以验证阶段不能只依赖另一段 LLM 生成代码而要尽量用确定性工具。Oracle基准输出必须来自原始代码而不是由 AI 生成。你可以先跑原始 GAMESS 得到积分值保存成标准文件。新代码每轮修改后都跑一次对比脚本生成数值差异报告。对比逻辑用 Python 或 C 写死不用 LLM 判断。容差设置需要结合数值范围。双电子积分的量级可能从 1e-1 到 1e-12。适合用混合容差对绝对值大于 1e-6 的积分允许最大绝对误差是 1e-10对绝对值小于 1e-6 的积分允许最大相对误差是 1e-8任何 NaN、Inf 都直接失败。这个容差可以随着测试用例规模调整但不要一开始就设置很严格的 1e-12否则迭代会被微小数值噪声困住。先放宽一点跑通再逐步收紧。4.5 排查顺序先输入输出、再数值误差、再性能退化当验证失败时新手最容易一头扎进数值误差里反复调代码。更稳的排查顺序是输入输出边界检查新旧代码的输入参数是否完全一致数组形状是否一致索引起点是否一致。这一步能排除大部分“看起来在算实际算的根本不是同一个东西”的情况。中间结果一致性对比函数内部的关键中间变量比如基函数值、辅助积分数组。可以用插桩或日志输出定位误差是在哪一层累加产生的。数值误差如果中间结果一致只有最后输出有差异重点检查累加顺序、缩放因子、归一化、对称性组合。性能退化数值正确后再分析性能。先做 profiling找出热点函数再考虑向量化、内联、消除临时数组分配等问题。这套排查顺序也可以编排到 Agentic Workflow 的验证代理里检测到不同特征就输出不同反馈。比如“输入输出边界一致但中间结果在第三步出现偏差”代码生成代理就会知道去检查递推公式而不是索引逻辑。5. Agentic Workflow 不是银弹适用边界与工程化补全5.1 适合什么代码、不适合什么代码用 Agentic Workflow 做迁移不是对所有 HPC 代码都有效。从经验看适合的条件大致是代码逻辑可以通过函数边界切分不依赖大量隐藏全局状态。数值算法有明确输入和输出可以用少量测试用例覆盖。目标语言和源语言的表达差异没有大到无法桥接。有可执行的 oracle 或测试基准。用来判断“不适合”的信号代码里充满跨文件的 goto、等价语句、动态修改自身代码的元编程。这类代码分析代理很难理解生成代理更难模仿。依赖专有的 MPI 通信状态机或复杂的并行同步逻辑。迁移这类代码不仅要重写计算还要复刻消息传递时序工作流复杂度会呈指数上升。测试成本极高每次运行都需要大型集群和超长耗时。Agentic 工作流需要快速反馈如果一个验证跑一天迭代效率会很低。代码库本身没有版本控制和构建系统连“旧代码能跑起来”都无法稳定复现。这时候应该先做工程化治理而不是急着让 AI 代理迁移。所以双电子积分核心之所以是一个合适的切入点正是因为它计算密集、边界清晰、有数值 oracle而且相对独立。它不是最难迁移的系统级代码但足够有挑战性能暴露工作流设计中的大部分问题。5.2 长期工程化需要补的几件东西日志、版本管理、CI、导入路径即便 Agentic Workflow 成功迁移出了一个函数或一个模块也不要急着说他完成了现代化。真正有长期价值的是配套工程化能力行为日志每次迁移生成的代码、验证报告、误差数据都要存档。一方面用于审计另一方面可以作为后续 Agent 训练的示例。版本管理工作流里的所有 agent 的输入输出都要纳入 git每一次“理解文档”“生成代码”“验证报告”都可在历史中追溯。否则当某个验证通过后你想知道为什么之前失败会发现无从查起。持续集成CI每次有新代码合入自动化跑一轮小型测试和数值回归。双电子积分模块的基础 CI 可以只跑单点能量和梯度不一定要全流程但至少要保证不改坏东西。导入路径和接口隔离迁移后的模块应该通过一个封装接口给外层调用这样旧模块和新模块可以并存在功能开关切换下做 A/B 对比。不要把新代码直接嵌入整个 GAMESS 主流程风险太大。这些工作本身不依赖 AI但它们是 Agentic Workflow 能持续运转的地基。否则每一轮迁移都是“新写一段代码人工对比一下”和不用 AI 没有本质区别。5.3 从“一次迁移”到“可持续能力”让 Agent 积累项目知识一次成功的迁移不应该只是一次性代码替换还应该沉淀一套项目知识库。这些知识包括旧代码的术语表例如shinfo指的是壳层信息数组。已经踩过的坑例如r12与r12sq容易混淆。迁移模式模板例如“当遇到函数参数是数组优先用显式 shape 而不是*”。验证策略模板例如“d 型基组必须测试非对称几何否则无法检测镜像映射错误”。Agentic Workflow 中的分析代理可以在每次迭代后更新项目知识库代码生成代理读取这些知识库作为上下文。刚开始知识库可能是空的但随着迁移推进工作流会越跑越顺。这种“项目知识积累”才是 Agentic Workflow 优于一次性“AI 重写”的最大特点它把经验放进了可复用的流程而不是留在某个工程师脑子里。当然知识库需要维护不能无限膨胀。可以按模块、函数、跨函数规则分类并标记优先级。同时每隔一段时间人工清理失效信息避免模型被陈旧知识带偏。6. 从迁移到现代化工作流的三步法如果要把这套经验抽象成可复用的方法我的建议是面对任何遗留 HPC 模块先别急着写 prompt先按以下三步走。6.1 第一步建立“可验证的行为基线”这一步回答的核心问题是凭什么证明新代码是对的找到模块的最小可调用路径。用一组有代表性的输入跑出基准输出保存为 oracle。编写自动化比较脚本支持输出差异统计。没有行为基线后续所有 Agent 的工作都是空中楼阁。这一步不能省也不能交给 AI 代理自动完成因为它关系到整个项目的可信度。如果你连旧代码在一台新机器上如何稳定构建都没有摸清那首要任务是解决构建可复现性而不是谈迁移。6.2 第二步把任务拆到“人可审查”的粒度合适的粒度标准是单个子任务的代码量不超过两百行测试用例不超过几个函数调用人可以在十分钟内完成审查。如果做不到就继续拆。拆解时可以依赖分析代理但最终应该是人确认。因为只有人知道模块未来十年的演进方向有些函数可能很快会被废弃那就别花力气迁移有些接口是性能关键点那就需要拆得更细方便做性能调优。6.3 第三步把验证、反馈和人工节点固化到流程里最后一步是把 Agentic Workflow 编排进日常开发流程。可以用脚本触发也可以接入 CI。关键是每个环节要留下记录尤其是“生成→验证→反馈→再生成”的循环要能看到它收敛的过程。如果循环超过 N 次比如 5 次还没有收敛就停下来让人工介入。不要任凭代理空转那样只会浪费 token 和时间。人工介入解决的是方向性问题AI 代理解决的是执行性问题。把这三点都做到Agentic Workflow 就不再是“大模型玩票”而是一条可以反复使用的现代化生产线。回头看整个事情我最大的感受是GAMESS 双电子积分核心这样的遗产代码真正难的不是数学公式也未必是 Fortran 语法而是“经验不可见”和“验证困难”。Agentic Workflow 的价值正好在于把这两个问题摊开用结构化任务、显式验证和迭代反馈把原本只存在于资深工程师脑中的迁移过程变成一行行记录、一份份报告和一次次明确对比。如果你正准备拿一个遗留 HPC 模块做现代化实验我建议第一件事不是去选模型、调 prompt而是先从源码里圈出一个最边角的小函数建立好 oracle跑通一次“分析→生成→验证”的循环。等你亲眼看到一个 AI 代理在你给定的约束下把一个小的硬骨头啃下来再扩大到真正的双电子积分核心也不迟。