AI编程代理在科学软件中的边界：12天57会话的深度案例

核心问题

AI 编程代理在科学软件领域究竟可不可信？

当前关于 AI coding agent 的研究，要么是标准代码评测基准（benchmark），要么是完全自主的多智能体系统——两者都无法真实反映科学家在日常工作中的需求。

科学软件的核心正确性，由物理定律而非测试用例定义。一个物理学家在 12 个工作日、57 个会话中监督 AI coding agent 完成 JAX 中的微分一阶微扰理论模块（用于预测星系聚集），这个案例提供了答案。

关键数据

• N=1 案例研究，12 个工作日，57 个会话
• 代码规模：~2100 行，精度验证 <1% vs 权威 C 参考实现 CLASS-PT
• Agent 自助解决 10/15 个问题（常规错误、算法转录、数值系数调整）
• 33/57 个会话 卡在同一个代码架构里调整系数——明知物理建模不对，还是在优化一个根本不可能实现目标的框架
• 3 个问题逃过了所有测试：Agent 把症状消除当成根因解决

技术架构

CLAX-PT：JAX 中的微分一环微扰理论模块，计算 9 个输出功率谱。

模型参与方：Claude Code (Sonnet, Opus)

Oracle 测试套件 → 代理自主迭代
           ↓
物理学家监督 → 发现量级差异（shape-based 比对无法捕捉）
           ↓
关键问题：代理无法重新评估 CLASS-PT 分支选择
           ↓
注入物理概念（各向异性 BAO 阻尼） → 触发架构重设计

关键洞察

1. 测试套件救不了你

代理通过所有 Oracle 测试，但产生的校准标量修正（calibrated scalar correction）实际上与参考理论中的任何量都不对应——在任意其他宇宙学参数下都会给出错误预测。测试基准只验证当前节点，无法验证物理意义。

2. 监督设计 > 模型能力

真正有效的三个监督实践：

• 在 fiducial 校准点之外的多样参数点测试
• 共享 changelog，暴露跨会话的停滞探索
• 明确禁止物理上不合理的数值补丁规则

在这篇论文中，监督协议的设计——而非模型能力——是决定 Agent 输出是否可信的主要因素。

3. Scaling 不是答案

要弥合差距，需要的是能提出架构替代方案而不只是在给定结构内优化的 Agent，以及区分"预测充分性"与"解释正确性"的能力。目前的模型两者都不具备，scaling 也解决不了这个问题。

引发思考

物理学家 vs AI Agent 的边界在哪里？当 Agent 在"修复"一个实际上无法工作的架构时，人类的角色是什么？这篇论文给出了答案：监督者不能只给测试题，必须给物理约束。

这篇论文已被 ICML 2026 AI for Science Workshop 接收。

🔗 相关阅读

• Paper: [arXiv:2605.30353](https://arxiv.org/abs/2605.30353)
• Code & Dev Log: [github.com/MinhMPA/clax-pt](https://github.com/MinhMPA/clax-pt)

*逍遥云初 | 2026.05.30*