Foam-Agent：让多智能体接管 OpenFOAM 工作流，离可信 CFD 还有几道门槛

2026-08-07

多智能体, CAE, CFD, GitHub开源项目, Foam-Agent, OpenFOAM, 仿真自动化

计算流体力学项目常把大量时间消耗在求解器启动之前：理解需求、寻找相近算例、建立几何与网格、编写十几个彼此关联的字典、检查边界名称、准备运行脚本。求解开始后，工程师还要盯住日志、修正配置、判断收敛情况并制作图像。任何一个文件里的字段名、量纲或边界类型不一致，都可能让 OpenFOAM 在几秒内退出；更棘手的情况是程序顺利结束，结果却不满足物理规律。

GitHub 项目 csml-rpi/Foam-Agent 尝试把这条长链交给一组专职智能体。用户描述 CFD 任务，系统负责规划、教程检索、网格、配置、本地或 Slurm 执行、日志修复及 PyVista 绘图。项目采用 MIT 许可证，默认面向 Foundation OpenFOAM v10，另有 ESI 字典的尽力转换路径。论文在 110 个任务上报告 88.2% 的执行成功率；这个指标首先衡量“案例能否执行完成”，不能直接替代网格无关性、数值收敛和实验对照。

为什么要拆成多个智能体

OpenFOAM 案例看似是一组文本文件，内部却存在密集依赖。controlDict 选择应用程序和时间控制；constant 目录声明物性、湍流或热物理模型；0 目录中的速度、压力、温度及湍流变量必须覆盖网格里的每个边界；fvSchemes 与 fvSolution 又要匹配方程、算法和字段名称。把所有内容一次性交给单个大模型生成，常见故障包括复制了错误版本的教程、混用稳态与瞬态设置、漏掉湍流场、边界拼写不一致，以及 Allrun 调用了不存在的工具。

Foam-Agent 用 LangGraph 保存工作流状态，并将职责分配给六类角色：Architect、Meshing、Input Writer、Runner、Reviewer、Visualization。主图根据中间状态选择分支：规划后判断采用标准 OpenFOAM 网格、Gmsh 生成网格还是外部网格；文件生成后选择本地运行或 HPC；执行有错误便进入审查与改写循环，无错误且用户明确要求后处理时才进入可视化。仓库默认最多允许 25 次审查循环，单次本地运行默认超时一小时。

项目还将 plan、input_writer、run、review、apply_fixes、visualization 等能力公开成 MCP 工具，外部智能体可以单独调用或组合编排。Pydantic 模型约束节点与工具的输入输出，减少格式漂移。

这里需要区分两层边界。LangGraph 图内的状态用于一次工作流的控制与交接，包含用户要求、规划结果、网格路径、已生成文件、运行状态、错误信息、审查历史和可视化请求；节点依据这些字段决定下一条边。它适合表达“当前案例走到哪一步”以及“失败后回到哪个节点”。MCP 则把能力变成进程外可调用接口，调用方只应依赖工具参数和返回结构，不应假定服务内部采用哪张图、保存了哪些临时变量。若外部编排器依次调用 plan、input_writer 和 run，案例目录或案例标识就成为显式交接物，调用方还要负责超时、重试、幂等与权限。MCP 工具可组合不代表共享状态天然可靠：并发修改同一案例、重放 apply_fixes、客户端中断后重复提交，都需要版本号、运行 ID、文件摘要或目录锁来防止覆盖。仓库提供了可组合接口，以上事务控制仍应由部署层补齐。

第一段任务链：理解需求并寻找参照案例

Architect 首先把自然语言整理为案例名、物理域、类别和求解器，再生成需要创建的目录与文件清单。一个可用的请求至少应说明几何尺度、流体属性、稳态或瞬态、入口出口条件、壁面条件、目标雷诺数或速度、模拟时长、输出间隔，以及希望观察的物理量。信息缺失时，模型会依据教程和领域知识补齐，这也意味着假设可能悄悄进入案例。工程使用中应把“用户明确给定”“由系统推断”“引用教程默认值”分开记录。

知识检索采用分层多索引设计。论文描述了四类 FAISS 索引：教程结构、教程文件细节、Allrun 执行脚本、OpenFOAM 命令文档。系统先依据案例元数据缩小候选范围，再查询目录结构和具体配置。这样的两阶段检索可以防止一个语义相似、物理模型却不同的教程占满上下文。例如，同为管内流动，层流、RAS、可压缩传热和多相流需要的字段集合差别很大；先按域、类别和求解器过滤，比在全部文件中做一次向量近邻搜索更稳妥。

论文消融实验给出了检索设计的作用：没有 Reviewer 时，分层检索的执行成功率为 57.3%，单索引检索为 44.6%；加入 Reviewer 后，两者为 88.2% 和 84.6%。这说明检索质量会影响初始案例，也说明后续执行反馈能修复一部分检索或生成错误。它仍然无法保证选中的教程适用于目标雷诺数、网格拓扑和关注量，因此仓库当前还会输出相似案例匹配等级及使用范围提示，提醒生成节点不要机械复制弱匹配模板。

第二段任务链：网格、边界与案例文件

Meshing Agent 支持三条路线。简单规则几何可以让 Input Writer 生成 blockMeshDict 或 snappyHexMeshDict，再由 Allrun 调用 OpenFOAM 原生工具。用户也可提供 Gmsh ASCII 2.2 格式的 .msh 文件，系统复制后执行 gmshToFoam。第三条路线是根据文字生成 Gmsh Python 脚本，脚本创建几何、三维网格及物理分组，随后转换为 polyMesh。

文字生成网格是最值得关注、风险也较高的环节。代码会提取请求里的边界名，运行模型生成的 Python，检查 .msh 和 polyMesh 是否出现，对比实际边界与预期边界，再运行 checkMesh。若 Gmsh 报错、边界集合不一致或网格检查失败，错误会进入代码修正循环。对于二维问题，系统仍会生成薄三维网格，并将合适的前后表面改为 empty；无滑移表面则应在网格边界文件和场文件中保持一致。

checkMesh 通过仅说明拓扑和部分质量指标达到工具门槛，不能证明近壁 y+、激波、分离或热边界层得到足够分辨。复杂 CAD 和外部网格仍要核对单位、法向、区域、patch、局部加密及边界层质量。

Input Writer 随后按 system → constant → 0 → 其他文件 的优先级写案例。默认的 sequential_dependency 模式会把已经生成的文件内容放入下一次调用上下文，用于保持字段、边界和物性一致；parallel_no_context 可加快生成，但更依赖后续重试。论文把这一步描述为依赖图的拓扑遍历。消融结果显示，在没有 Reviewer 时，依赖生成可将不同温度设置下的成功率由 48.2% 提高到 56.4%，或由 45.4% 提高到 57.3%；有 Reviewer 时，总成功率差距缩小，但平均修复轮数下降，API 成本和等待时间随之减少。

边界条件是跨文件一致性的集中考验。以不可压缩 RAS 为例，网格里出现 inlet、outlet、walls 和 frontAndBack，那么 U、p、k、omega 或 epsilon、nut 都要包含相同 patch，并使用与求解器和湍流模型兼容的类型。入口速度还要与几何尺度、运动黏度和目标雷诺数相符。系统能够对字符串和文件依赖做检查式生成，却没有一个完整的量纲方程求解器来证明所有自然语言约束彼此一致。高价值项目最好在需求进入智能体前先转换成机器可校验的参数表。

一致性也不限于 patch 名称。controlDict 中的 application 必须能读取 constant 下对应的物性字典；湍流模型决定初始场集合以及 fvSolution 中需要配置的线性求解器；可压缩案例里的压力、温度、热物性和状态方程要使用兼容量纲；decomposeParDict 的子域数还要与本地 MPI 参数或 Slurm 任务数相等。网格重命名、区域拆分或 changeDictionary 又可能使生成时正确的边界表在运行前发生变化。因此更稳妥的做法是在写完全部文件后建立一次案例级联检：解析 polyMesh/boundary，抽取每个场文件的 boundaryField，核对求解器所需字段、字典引用、函数对象字段及并行规模，再把差异作为结构化错误交给 Reviewer。逐文件生成负责降低首轮错误率，案例级联检负责发现后写文件造成的反向不一致。

第三段任务链：选择求解器、运行和监控

求解器选择由规划结果及检索案例共同影响。Foam-Agent 默认验证路径是 Foundation v10；ESI 分支只对部分名称和字典做尽力翻译，执行与修复仍需逐案例验证。团队应把 OpenFOAM 分支和版本设为硬门禁。

Runner 会清理旧日志和数值时间目录，执行生成的 Allrun，捕获标准输出与错误输出，并扫描 OpenFOAM 错误。HPC 路径可生成 Slurm 脚本、提交 sbatch、查询队列状态，再读取作业日志。任务描述中若提供节点数、每节点进程数和账户信息，系统可以写入脚本；论文也称其可结合网格分解与规模推断资源参数。

当前“运行监控”主要覆盖进程状态、超时、退出错误和日志模式。生产环境还要监控 Courant 数、残差、连续性误差、力或压降历史、资源和并行负载。稳态达到 endTime 不等于收敛，瞬态无崩溃也不等于统计充分。可通过受控的 function objects 和独立判据脚本，让 Runner 返回结构化指标。

第四段任务链：错误恢复与后处理

执行失败后，Reviewer 会收集错误日志、当前 OpenFOAM 文件、相似案例和用户原始要求，分析根因并生成最小修改计划。计划以目标文件和具体修改项表示，Input Writer 进入 rewrite 模式后重写相关文件，再次运行。历史记录保存每轮错误和建议，提示模型避开已经失败的修法。论文的消融图显示，Reviewer 是成功率提升最大的组件：无 Reviewer 的基线约为 50%，加入迭代反馈后超过 80%。这符合工程直觉，因为 OpenFOAM 的报错通常携带缺失关键字、维度不符、未知 patch、字段未定义或线性求解器配置错误等明确线索。

不过，自动修错容易出现“让程序继续跑”的局部最优。模型可能通过更换边界类型、降低时间步、改用更耗散格式、放宽求解容差或替换湍流设置来消除错误，同时改变原始问题。仓库 Reviewer 提示词要求不要修改用户声明的参数，并通过历史避免循环；工程部署还应增加不可变约束清单，对几何尺寸、物性、入口条件、模型类别、目标时间和关键离散方案设置修改权限。每轮 patch 都应保留 diff，并记录修改理由。

一条可审计的修复记录至少应绑定六项内容：运行 ID、失败日志摘要、修改前文件哈希、Reviewer 的根因分类、获准修改的文件与键、修改后的验证结果。应用修复前先检查补丁是否触碰不可变参数，应用后执行字典解析、边界集合与量纲检查，再启动求解器；若仍失败，则把新日志和本轮 diff 追加到轨迹。相同错误签名连续出现、补丁往返切换，或关键参数发生漂移时，应停止自动循环并转人工审核。审计报告还应区分“语法修复”“运行稳定性调整”“物理模型变更”：前两类可在规则许可下自动执行，第三类通常需要工程师批准。这样才能回答案例为何被修改、修改是否超出授权、成功运行是否以牺牲原要求为代价。

Visualization Agent 仅在用户明确提出后处理时触发。它先尝试确定性的 PyVista 脚本，失败后再调用模型生成或修复脚本，读取 .foam 并输出 PNG。报告应保存绘图脚本、色标范围、时间步、采样位置和原始数据，避免图像设置掩盖问题。

可靠性：执行成功与可信结果之间的距离

论文在 CFDLLMBench 的 110 个案例上报告 Claude 3.5 Sonnet 为 88.2%，MetaOpenFOAM 为 55.5%，GPT-4o 驱动的 Foam-Agent 为 59.1%。这些任务覆盖层流、湍流、传热、燃烧、多相、激波和浅水等类别。仓库 2026 年版 README 还列出 FoamBench 基础与高级任务在 Claude Opus 4.6、最多 25 轮条件下达到 100% 的结果。两组数字使用的模型、代码版本、循环上限和评测划分存在差异，适合分别引用，不能拼成一条持续提升曲线。

论文结论也明确把后续工作指向“结果级对齐”。现有评测的核心仍是可执行性，个别外部网格案例通过速度云图与专家案例作了对照。对 CFD 来说，可信度至少还包括：守恒误差是否可接受；残差和关注量是否稳定；时间步与网格加密后结论是否稳定；湍流模型、壁面处理和 y+ 是否匹配；边界条件是否代表实际装置；关键结果是否与解析解、公开基准、实验或已审定案例一致。智能体可以自动收集这些证据，但判据必须由团队预先定义。

可以把结果验证整理成四维矩阵。第一维是数值过程，记录残差下降、连续性误差、Courant 数、线性迭代异常和关注量平台期；第二维是离散敏感性，比较至少三套网格以及必要的时间步加密，并报告关键量变化率或 GCI；第三维是物理一致性，检查质量、动量与能量收支、对称性、符号、量级、y+ 和模型适用区间；第四维是外部证据，依次对照解析解、制造解、公开基准、实验数据或企业已审定案例。每个任务应预先声明适用单元格、阈值、证据文件和失败处置，避免求解结束后临时挑选有利指标。矩阵允许某些单元格标记为不适用，但不应以一张云图替代积分量、剖面与不确定性证据。

可复现实验应锁定仓库提交、镜像摘要、OpenFOAM 版本、Python 依赖、模型标识、提示词、温度、循环上限、向量库和随机种子，并归档调用、生成文件与修复轨迹。模型或教程库更新都可能改变案例。

安全：生成脚本必须关进沙箱

Foam-Agent 会执行模型生成的 Allrun、Gmsh Python、可视化 Python 和 Slurm 脚本，这比生成普通配置文件拥有更大的系统权限。仓库 Docker 方案提供了良好起点，但容器仍应采用非特权用户、只读根文件系统、独立工作卷、CPU/内存/进程/磁盘配额，并默认关闭不必要的网络访问。API 密钥应通过短期凭据或秘密管理器注入，不应写入案例、日志和镜像；README 也提醒 Codex 的 auth.json 等同密码。

MCP 远程端口还要加认证、TLS、来源限制和工具级权限。生成脚本应先静态扫描，只允许白名单命令和案例目录内路径，拒绝网络下载、宿主敏感目录及任意 shell 拼接。外部网格也要限制大小、格式和解析资源。

接入企业 CAE、PLM 与算力队列

企业环境中，Foam-Agent 适合放在现有流程的受控服务层。上游由 CAE 门户或 PLM 提交仿真任务包，包内使用零件或装配版本、CAD 派生件编号、材料牌号、工况 ID 和验证规范引用，避免把未受控的自然语言当作唯一输入。几何清理、表面网格和商业前处理器可继续留在既有工具链，Foam-Agent 接收经过批准的网格与边界语义表，生成 OpenFOAM 案例及机器可读清单。下游则把日志、配置摘要、镜像摘要、结果指标和审计轨迹回写到仿真数据管理系统；大体积场数据进入对象存储，只在 PLM 保存版本关系、校验和与可追溯链接。

算力侧不宜让模型直接持有集群登录权限。较稳妥的方式是由队列适配器接收经过策略校验的资源请求，映射账户、分区、服务等级、最长墙钟时间、节点与任务上限，再生成或填充组织批准的 Slurm 模板。提交后以作业 ID 关联案例，队列状态、退出码、资源利用率和日志由适配器回传；取消、续跑、扩容及跨分区重提受独立权限控制。企业还可在 MCP 工具前增加 API 网关，把规划、写文件、提交作业、读取结果设为不同角色权限，并用事件总线连接审批、许可证检查、成本中心和归档流程。这样既保留模块化调用能力，也能沿用已有 CAE 治理与算力配额。

工程团队的最小验证方案

评估这类系统无需先投入大型工业算例。一个可在一两天内完成的最小方案，可以选三个公开案例：Re=100 或 1000 的方腔驱动流、二维圆柱绕流、带压降或换热指标的通道流。三者分别覆盖稳态或准稳态基准、非定常周期量、工程积分量。固定 Foundation OpenFOAM v10、同一模型、同一提交和 Docker 镜像，每个提示重复运行三次。

第一道门禁检查案例结构：必需文件齐全，字典可由 OpenFOAM 读取，边界集合在 polyMesh/boundary 与所有初始场中一致，量纲和用户给定参数无漂移，Allrun 只能调用批准命令。第二道门禁检查网格：checkMesh 无致命项，并记录单元数、最大非正交度、最大偏斜度、最小体积；至少生成粗、中、细三套网格。第三道门禁检查数值过程：监控 Courant 数、残差、连续性误差和关注量，设置超时、发散及停滞判据。

第四道门禁检查结果。方腔可比较中心线速度剖面；圆柱可比较平均阻力系数、升力振幅和 Strouhal 数；通道可比较压降、摩擦因子或 Nusselt 数。团队应预先写出容差，例如积分量相对基准误差不超过 5%，细化网格后的关键量变化小于 2%。第五道门禁检查可复现性：三次生成的文件差异、修复轮数、token 成本、总耗时和最终指标都进入报告。若一个案例只有一次跑通，仍不足以说明系统稳定。

最后进行一次受控故障注入：故意删掉 fvSchemes 条目、写错 patch 名或移除湍流字段，观察 Reviewer 是否只修改必要文件、是否保持用户参数、能否在限定轮次内恢复。再进行一次安全测试，在提示里夹带读取宿主文件或联网下载的要求，确认沙箱与命令白名单能够拦截。通过这些小测试，团队可以判断 Foam-Agent 适合做案例草拟助手、自动回归工具，还是可以进入有人审核的计算队列。

结语

它目前更适合作为“会运行和修案例的自动化工程层”，其输出仍需数值分析与物理验证。对工程团队而言，最稳妥的接入方式是锁定环境、限制脚本权限、保留完整轨迹，并把网格、收敛、守恒和基准误差写成自动门禁。这样，智能体负责高频配置与诊断，专家把时间集中在模型假设、验证标准和设计判断上。

会员专区