把科学规则变成工具：可执行检查如何帮助LLM代理修复代码

导语

科学编程代理面对的并不只是普通的软件需求。它们往往需要理解方程、边界条件、数值方法以及输出格式，并在修改程序后判断结果是否满足这些要求。传统做法通常把规则写在提示词里，再让模型自行阅读、推理和测试。论文《Rules to Tools》提出了另一条路径：把公开的科学要求预先实现为可调用的执行检查，让代理能够直接获得更接近程序化验证的反馈。

核心要点

• 从文字规则转向可执行检查。 研究在SciCode修复任务中设置匹配实验。两组使用相同的文字要求、起始程序、模型和预算，区别是工具组额外获得了检查实现，可在修复过程中调用。
• 整体结果有提升，但统计信号有限。 在两个任务ID队列中，文本组完成修复26/30，工具组为29/30。一个包含8个任务ID的队列中，两组成绩分别为13/16和15/16；按任务聚类计算的差异，其95% bootstrap区间为-12.5至43.75个百分点，说明样本规模下还不能把优势视为普遍规律。
• 任务差异比单一平均数更重要。 相关比较中，3个任务更偏向工具，1个更偏向文本，11个打平。更大的共享定义SciCode队列中，两组均为13/24。使用不同起始程序的5个开发暴露任务中，结果为文本组3/10、工具组7/10，显示检查对某些任务尤其有帮助，但也可能受任务构成影响。
• 检查本身也需要审视。 研究提到，初始检查标记了任务17，而任务77和11没有报告违规；任务37则偏向文本且没有初始违规报告。这意味着工具输出不是天然可靠的“真值”，检查覆盖范围和设计质量会直接影响代理行为。
• 节省模型输出，不等于节省全部资源。 在匹配的偏微分方程比较中，详细文本组得分23/24，检查组24/24，同时报告的模型输出减少31.2%。不过两个任务ID队列的公开CPU使用量都上升，代理侧输出节省也因队列而异。另一个通过Python读取源代码的实验达到15/16，与专用命令方式相同。

意义与影响

这项工作把科学编程代理的验证问题，重新表述为“规则如何进入工具链”。如果方程和边界条件能够被可靠地转换成检查，代理就不必每次都仅依赖长文本理解，也能更快定位违反要求的程序行为。对于复杂的数值代码，这种反馈尤其可能减少模型反复解释和生成的内容。

但研究结果同样提醒开发者，工具化并不是无条件的性能升级。检查需要人工准备、维护和验证；过于狭窄的检查可能漏报，表达不充分的检查也可能让代理形成错误判断。更现实的系统或许应把自然语言规范、可执行检查和独立测试结合起来，并按任务衡量成功率、模型输出、CPU使用及检查制作成本，而不是只比较一个平均准确率。

总体而言，Rules to Tools展示了科学AI代理从“读懂规则”走向“调用规则”的可能性，也提供了一个更谨慎的结论：可执行反馈确实能在部分修复任务中带来帮助，但其价值取决于任务类型、检查质量和完整的资源核算。

来源：Hugging Face Daily Papers