ESM-bench：测试AI智能体是否理解地球系统模型的物理学
Published:
最可怕的部分不在于 AI 智能体在处理地球系统模型代码时失败了，而是它们可能在看似正确的代码中失败。
我思考这个问题已经有一段时间了。现在我们有很多 AI 编程的基准测试，其中一些也确实很有用。它们能告诉我们一个模型是否能修复 Python 的 bug、通过单元测试，或者从真实的软件代码库中恢复一个补丁。
但地球系统模型（Earth System Models）是完全不同的一种东西。
地球系统模型不仅仅是一堆代码。它是物理学的计算表达形式。它包含质量、能量、动量、水、辐射、湍流、土壤、积雪、植被、海洋环流，以及在论文中的方程和模拟输出数字之间存在着极其庞大的 Fortran 代码。
因此，当 AI 智能体编辑这种代码时，问题不仅仅在于：它能编译吗？
更好的问题是：它是否理解这段代码试图保护的物理世界是什么。
这就是 ESM-bench 背后的动机。
这篇关于 ESM-bench 概念和基准测试设计的论文草稿已作为Zenodo 预印本公开。
ESM-bench 是一个基准测试，用于测试 AI 智能体是否能在尊重软件结构和内部编码的物理逻辑的前提下，修改地球系统模型的代码。目前的论文草稿定义了涵盖四个类别的 576 个任务：基于物理的错误修复、过程表示修改、参数化方案选择和参数优化。该基准测试是围绕 Noah-MP、CLM5、SUMMA、ParFlow、MOM6、VIC、WRF 和 E3SM 等生产级 ESM 代码库设计的。
我喜欢这个设定的地方在于，它并不假装科学代码和普通的应用程序代码是一样的。
在普通的软件基准测试中，如果测试通过，一个补丁就算通过了。这已经很难了。但在地球系统建模中，一个补丁可能在语法上非常干净，但在物理上却是错误的。它可能编辑了错误的子程序，使用了错误的通量符号，打破了守恒修正，它可以在保持代码表面合理的同时，悄悄地将模型推向一种非物理的状态。
老实说，那才是最可怕的噩梦。
并不是模型崩溃。崩溃是容易察觉的。真正的危险是，运行起来看似合理的补丁，在人们用来推断这个星球未来的系统中，缓慢地注入了错误的物理机制。
这就是为什么 ESM-bench 将精确的补丁恢复与物理感知审查区分开来。精确匹配考察的是智能体是否完美再现了开发者的 diff 差异。而审查考察的是，提交的补丁是否定位了正确的代码、解决了声明的物理问题、在局部上与物理保持一致、仍有可能编译成功、涵盖了所需的修改，并避免了明显的数值隐患。
我认为这种区分非常重要。
一个模型可能大致理解了物理问题，但写出了结构上完全不同的补丁。模型也可能生成了一些看起来像补丁的东西，但遗漏了实际的物理机制。这两种失败不应该被折叠成一个模糊的单一分数。如果我们希望科学智能体变得有用，我们需要知道瓶颈究竟是在文件定位、代码生成，还是在实际的领域推理。
因此，ESM-bench 采用了两个赛道。
Track A 测试智能体能否根据物理描述找到正确的文件。这听起来很简单，直到你意识到 ESM 代码库可能庞大、古老、模块化，并且充满特定领域的命名约定，这些约定只有在你与代码相处一段时间后才说得通。
Track B 测试智能体在拥有相关的源代码上下文后，能否生成补丁。这正是事情变得有趣的地方，因为智能体必须将科学目标转化为存储库中有效的代码更改。
早期的数字让人保持谦卑。
在论文的初步最小提示评估中，最强的模型在 Noah-MP 上的平均结构 F1 分数仅为 6.7%，而所有评估的前沿模型的精确匹配率均为 0%。但这并不意味着智能体毫无用处。其中一些模型能够部分识别出正确的物理问题，特别是在基于物理的错误修复上。但参数化更改和重实现的繁重任务在很大程度上仍然没有被解决。
这感觉像是基准测试该有的结果。
不是那种每个模型都已经达到 90%、大家为小数点后几位争论不休的排行榜。也不是那种智能体只需要写一个小 Python 函数的玩具任务。真正的前沿领域应该包含失败。它应该告诉我们模型目前在哪里仍然脆弱。
我也在这里发布了一个实时排行榜的快照：ESM 排行榜。2026年4月24日的快照包含了代码库定位和物理感知的补丁合成结果。我发现特别有启发性的一行数据是在较新的代码级提示运行中，Claude Opus 4.7 在协助程度最高的 v4 Noah-MP 设置下达到了 0.312 的结构 F1，而精确匹配率依然是 0%。
这个数字很有用，因为它讲述了一个比“AI 根本不擅长地球系统模型代码”更微妙的故事。
有了足够的代码级脚手架，模型可以靠得更近。它可以解析文件，它通常能触及正确的地方，它能恢复预期更改的片段。但是，即使任务被缩小，智能体仍然很难重现确切的开发者修改，而且最难的物理类别得分仍然接近于零。
对我来说，这才是真正的研究信号。
我们不仅在抽象层面测量智力。我们还在测量智能体是否能尊重一个局部编辑会产生物理后果的科学系统。这比代码自动补全的要求高得多。这更像是要求模型成为一个初级科学软件协作者，它知道什么时候一行代码也是对现实世界的一个陈述。
我关心这个问题的另一个原因是出于实际考虑。
地球系统模型的开发进展缓慢，因为这项工作处于领域科学、数值方法、遗留 Fortran 代码、高性能计算和大量隐性知识的交叉点上。如果智能体哪怕能帮上一点忙，其杠杆效应也是巨大的。它们可以搜索庞大的代码库、起草候选补丁、检查局部物理一致性，并帮助专家提高效率。
但如果它们的帮助缺乏物理感知的审查，它们也可能让工作变得更加危险。
这就是为什么我不认为答案仅仅是更大的模型。我们可能需要配备专门验证工具的智能体。我们需要守恒定律检查器、单位和符号的合理性检查、代码库特定的上下文，以及不将模型视为“神谕”的审查工作流。目标不是取代领域科学家。目标是构建工具，使专家的审查更加敏锐和快速。
ESM-bench 仍处于起步阶段。目前的版本侧重于可审查的补丁级局部证据，而不是完整的长周期模拟审计。这是一个真实的局限。静态的 diff 可以揭示错误的目标、错误的机制、局部单位错误和缺失的保障措施，但它无法证明修改后的模型能在模拟的十年期间保持水分平衡。
尽管如此，我认为这是一个正确的起点。
在我们要求 AI 智能体运行地球系统科学之前，我们应该先问问它们能否在不破坏隐藏在地球系统模型代码中的物理规律的情况下，修改其中的一小段代码。
而目前的答案是：还不能可靠地做到。
这正是建立这个基准测试的价值所在。