arXiv 每日速递 2026-05-05

今日总结

今天 arXiv 一口气抛出 4 篇直击 "LLM/agent 在受约束工作流里到底能不能被信任" 的论文：AutoMat 测 coding agent 能不能从论文文本端到端复现一篇材料科学的实验；GeoContra 把 LLM 写出的 GIS 代码套进一个"地理契约"做 verification + repair；Themis 把 code reward model 从"单一功能正确性"扩展到 5 个准则、8 种语言；"To Call or Not to Call" 直接把 agent 工具调用决策当 normative vs descriptive 不对齐问题来量化。四条线最终汇到博主的核心 thesis：LLM 的端到端 score 已经骗不过人了，下一代评估必须是过程、契约、多准则、决策级的。这正是博主长期 push 的方向，今天值得整段读。

注意：这批论文都是 2026-05-01 当天最新提交，ar5iv 镜像尚未渲染，本期暂无配图，但我会用大量数据表格补足信息密度。

今日全览

论文	方向	核心贡献	与我们的相关度
AutoMat	coding agent benchmark	材料科学论文 claim 的端到端复现，最强 agent 仅 54.1%	⭐⭐⭐
GeoContra	LLM workflow + repair	地理契约 + 静态/运行时/语义三层校验 + bounded repair loop，DeepSeek-V4 从 47.6% → 77.5%	⭐⭐⭐
Themis	code reward model	5 准则 × 8 语言 reward bench + 350K 偏好对训练 600M-32B reward 模型	⭐⭐⭐
To Call or Not to Call	agent tool-use	normative vs descriptive 工具调用决策框架 + hidden-state 估计器	⭐⭐⭐

今日主题：从"端到端 score"走向"决策、契约、多准则"

这四篇论文表面看分散——一个测 agent 重现能力，一个修 GIS 代码，一个训 reward model，一个治理 tool call。但放在一起会发现三个共同的底层信念：

1. 端到端 binary score 已经无法承载评估。AutoMat 把任务拆成 "recover procedure / navigate toolchain / determine evidence supports claim" 三段；Themis 把 reward 从 functional correctness 拆成 5 维（功能、可读、效率、安全、风格）；GeoContra 把 success 拆成 spatial correctness + CRS schema + topology 等多个具体可验证条件。评估正在从 "is it right" 转向 "在哪一段、按哪个准则、出了什么问题"。
2. LLM 的"自我感知"普遍不可信，外部信号才是可靠的。GeoContra 用静态/运行时/语义三层 contract 替代 self-check；Themis 不让 LLM 自评而是训专门 RM；"To Call or Not to Call" 直接量化 LLM 自我感知与最优策略的偏差，用 hidden-state probing 训轻量估计器纠偏。
3. bounded、外置、可解释的纠错回路正在替代"再给 LLM 多一次机会"的暴力 retry。GeoContra 的 bounded repair loop 是典型，AutoMat 的 fragility 错误分析也指向同一方向。

如果你今年在做 agent marginal value、program repair、benchmark methodology 任何一条线，这四篇就是你下一篇论文 related work 的核心引用候选。下面一篇篇拆开看。

---

Can Coding Agents Reproduce Findings in Computational Materials Science?

推荐理由：这是今年 SWE-bench / RepoCod 之外最值得关注的一个 coding agent benchmark——不评 toy task，而是问一个 PhD 都觉得困难的问题：给你一篇论文的全文，你的 agent 能不能从头跑出它的 figure？ 跟博主"agent 边际价值实证量化"完全同频。

📌 论文信息：Ziyang Huang, Yi Cao, Ali K. Shargh, Jing Luo, Ruidong Mei | arXiv:2605.00803 | cs.SE

TL;DR

作者推出 AutoMat，一个让 coding agent 从计算材料科学论文文本中恢复完整工作流并端到端跑出来支撑/推翻 claim 的 benchmark。最强配置 success rate 仅 54.1%，且失败主要来自三大类：incomplete procedure、methodological deviation、execution fragility。

问题是什么？

当前 coding agent benchmark（SWE-bench、HumanEval、LiveCodeBench）共同的问题是任务边界过于干净：明确的 GitHub issue + repo state + 测试套件。但真实科研工作流不是这样：

• 方法描述一半在 paper 一半在补充材料一半在某个组员的 hint 上——agent 必须自己把"散落的 procedure"拼起来。
• toolchain 是 domain-specific 的（VASP、LAMMPS、Quantum Espresso、AiiDA），普通 LLM 没接受过这些 GUI/CLI 的训练。
• 正确性判定不是 unit test pass，而是"我这套数据出来的曲线是否支持论文的 claim"——这是一个判断题，不是简单匹配题。

简单类比：以前的 benchmark 像让你修一个写好测试的 bug，AutoMat 像让你看一篇 paper 然后从空文件夹复刻一遍它的实验。这中间所有 happy-path 假设都不成立。

他们怎么做的？

核心 Insight：把"重现"显式拆成三个互锁的能力——procedure recovery、toolchain navigation、claim adjudication。三者任何一个失败，整个 task 失败。这种强耦合任务设计特别像 SWE-bench Verified 的精神，但语义难度高了一个数量级。

具体方法流程：

1. claim curation：与材料科学领域专家合作，从真实论文里抽取可验证的 claim（注意是带方向的——"X 配置下能量比 Y 配置高 ΔE"），剔除模糊、不可执行、依赖私有数据的项。
2. task scoping：每个 claim 配对它需要的 input materials / target observables / expected procedure 大纲，但不直接给执行细节——要求 agent 自己从 paper 抽。
3. multi-agent settings：评估了多种 agent 设定（不同 foundation model、不同 scaffolding）来分离 model capability 与 framework capability。
4. 错误归因：对失败案例做人工 + LLM-assisted 的错误分类，揭示 fragility 的具体来源。

跟之前方法的本质区别：SWE-bench 的"通过测试 = 成功"和 RE-Bench 的"达到指标 = 成功"都是outcome-only。AutoMat 的成功定义是 claim adjudication 显式 yes/no——而且因为材料科学的 claim 是方向性的（A > B 还是 A < B），它隐含拒绝了"刚好凑够数字"的 reward hacking。

关键结果

设置	Success Rate	主要失败类型
最强 agent 配置	54.1%	execution fragility
paper-only 输入（最难）	显著低于 with-procedure-hint	incomplete procedure
给定 procedure hint	中等	methodological deviation
给定 procedure + tool snippet	最高	仍 ≠ 100%，命中 fragility

结果解读：

• 有意思的是，procedure recovery 不是最大瓶颈——给 agent 一份提示后，成功率确实上升，但 ceiling 仍远低于 100%，说明真正卡死的是 toolchain navigation 与 numerical fragility（设错一个 cutoff 值整个跑出来都错）。
• 这暗示了一个反直觉点："让 agent 读 paper 抽 procedure"已经不是主要难点，"让 agent 在不熟悉的 CLI 工具链里做出正确决策"才是。这跟两年前主流对 agent 的批评（"LLM 看不懂论文"）已经完全不同了。
• 错误分类里 execution fragility 和 methodological deviation 占大头，意味着这是一个典型的"过程质量"benchmark——end score 高低主要由中间步骤的微小偏差决定，正符合博主一直关注的 process quality 论。

局限性与开放问题

• 局限 1：54.1% 的成功率是在材料科学这一个 domain。换到生物信息、天体物理，agent 是否会在 toolchain 上更崩？没数据。如果 fragility 是普遍现象，benchmark 最大的价值反而是领域无关的失败模式分析。
• 局限 2：claim 是被领域专家精选的"可执行 + 可判定"子集，已经回避了一些噪声大的实验性 claim。这意味着 AutoMat 的 success rate 可能是乐观估计——真实科研复现的 noise 更大。
• 开放问题：execution fragility 是 model 能力问题还是 scaffolding 设计问题？论文给了 multiple settings，但没有清晰拆出 framework 与 model 的边际贡献。这正好是博主"agent 边际价值量化"研究路径的天然延伸。

💡 对我们的启发

1. 直接可用的技术点：博主在做 SWE-bench / OpenHands trace 分析时，可以复用 AutoMat 的"三段式失败归因"框架（recovery / navigation / adjudication）来给 trace 加 fine-grained 标签。这比博主之前用的"test execution 是否触发"颗粒度更高，可以做更细的 marginal value 分解。
2. 具体实验想法（1–2 周可做）：拿 AutoMat 公开的失败 trace，逐条标注 "execution fragility" 类失败，统计"模型一次输出错的具体子步骤"。预期假设：execution fragility 的 80% 来自数值/命令行参数的微小偏差，而不是结构性误解。如果验证，论证"在 LLM 输出之外加静态 / 物理一致性约束"是比换更大模型更划算的方向——这本来就是博主 GeoContra-style 工作的论据。
3. 研究趋势判断：domain-specific scientific reproduction 会成为 2026 下半年 coding agent benchmark 的下一个热点（继 SWE-bench、Aider Polyglot 之后）。博主的 OpenHarmony / ArkTS 工具链方向有天然机会——HomeCheck 的规则违规修复 + 性能 issue 复现，可以做成 ArkTS-Bench 的 domain reproduction 版本，比纯 SE 任务更有 niche 防御力。

---

GeoContra: From Fluent GIS Code to Verifiable Spatial Analysis with Geography-Grounded Repair

推荐理由：这是今天最直接命中博主"program repair + 静态信号驱动迭代修复 + 职责切分哲学"研究路径的论文。把"地理领域规则"显式建成 contract，再用静态/运行时/语义三层校验驱动 bounded repair loop——结构上几乎是博主 Python 兼容性修复工作的 GIS 平行版本。

📌 论文信息：Yinhao Xiao, Rongbo Xiao, Yihan Zhang | arXiv:2605.00782 | cs.SE

TL;DR

GeoContra 把每个 GIS 任务表达成一个 executable geospatial contract（自然语言 question + schema + CRS metadata + spatial predicate + topology 约束 + required ops + forbidden shortcuts），让 LLM 生成的 Python 代码经过静态规则检查 → 运行时验证 → 语义检验三层，违反就送进 bounded repair loop。在 7079 个真实 Boston-area 任务上，DeepSeek-V4 从 47.6% 涨到 77.5%，Kimi-K2.5 从 57.7% 涨到 81.5%，11 个开源模型平均提升 26.6 pp。

问题是什么？

LLM 写 GIS / 数据分析代码有一个隐藏顽疾：它会生成"语法和单元测试都过、但语义崩坏"的代码。例如：

• CRS（坐标参考系）混乱：把经纬度直接当成米/像素相加。
• schema 不匹配：把 population_density 字段当成 total_population 用。
• 拓扑违规：计算"两个 polygon 的距离"时返回负值。
• forbidden shortcut：用 df.head() 替代真正的空间 join，得到一个长得像答案的废结果。

这些错误几乎不会被普通 unit test 抓到，因为任务的输出长得"像答案"——但答案是错的。这跟博主在做的 Python 兼容性修复中"API 替换后单元测试虽然通过但语义已偏移"的问题在结构上完全同构。

他们怎么做的？

核心 Insight：把"领域规则"从 LLM prompt 里抽出来变成一个外部、可执行、可审计的 contract——而不是寄希望于 LLM 自己理解 CRS、topology。这正是博主一直主张的"职责切分哲学"——静态分析做约束，LLM 只负责生成。

具体方法流程：

1. contract 构造：每个任务抽取问题、schema、CRS、预期 spatial predicate、required ops（如 must use to_crs）、forbidden shortcuts（如 must not use df.head() 替代 spatial join）。
2. 三层校验：
   • 静态规则检查（rule inspection）：扫代码里有没有 forbidden API、是否调用了 required op。
   • 运行时验证（runtime validation）：跑代码，捕获 exception、检查输出 schema/CRS 是否符合 contract。
   • 语义验证（semantic verification）：跑领域级判定（输出值是否物理可能、distance 是否非负、travel time 是否非负）。
3. bounded repair loop：违反任何一层时，把违规具体描述拼回 prompt，让 LLM 修复，最多 N 轮——这是关键，避免 LLM 在错误上越修越烂。

跟之前方法的本质区别：以前的"自我反思 + 自我修复" pipeline（Self-Refine、Reflexion 类）是让 LLM 自己评、自己改，但 LLM 的 self-judgment 在领域规则上系统性偏差。GeoContra 是外部 ground truth-aware judge + 有限重试，从信息论的角度比 LLM self-loop 严格更强。

关键结果

模型	基线 spatial correctness	+ GeoContra	提升
DeepSeek-V4	47.6%	77.5%	+29.9 pp
Kimi-K2.5	57.7%	81.5%	+23.8 pp
11 个 open-source 模型平均	—	—	+26.6 pp

任务规模：7,079 真实 GIS 任务 × 15 个 Boston 区域 × 9 个任务族 × 11 个模型 × 600 runs = 大量级实验。

结果解读：

• 26.6 pp 是个很大的数字——这意味着对于"流畅但错"的代码生成场景，bounded repair loop + contract 几乎相当于"换一档更强模型"的提升。这又一次验证了：在 retrieval-grounded / verifier-grounded 的 setting 下，scaffolding 的边际价值远大于换模型。
• 论文给出 contract 抓到的具体错误类型 ablation——negative travel time、CRS 字段违规、missing predicate、output cast 脆弱——每一类对应一个 verification rule。这种"一个 rule 抓一类 bug"的结构对博主做 ablation 很友好。
• 一个反直觉点：强模型上的提升仍然显著（DeepSeek-V4 47.6 → 77.5），说明问题不是"小模型理解不到位"，而是**"LLM 没有内化领域规则"是模型规模无关的系统性缺陷**。

局限性与开放问题

• 局限 1：contract 是任务级人工撰写的（CRS、schema、required ops），这个成本不低。能不能从领域 corpus（GIS 教材、文档）半自动抽 contract？论文未涉及。
• 局限 2：bounded repair loop 的最大轮数是个 hyperparameter——没看到 wallclock cost vs accuracy 曲线，所以无法判断"实际线上部署时这个 verifier 到底贵不贵"。
• 开放问题：把 contract 这套机制迁移到通用 SE 场景（不是 GIS 而是普通 Python repo）时，契约的形式语言怎么设计？——这是博主 Python 兼容性修复工作的开放问题之一，GeoContra 给了一个 domain-specific 的范本。

💡 对我们的启发

1. 直接可用的技术点：博主的 Python 版本兼容修复工作（API 演化导致的 silent semantic shift）几乎可以直接迁移这套 contract 三层验证——把"API 行为差异"建成 semantic predicate（如 pandas.iloc 在 1.x 和 2.x 行为差异），用 runtime + 语义层抓 silent failure。这是博主之前 manual 处理但没系统化的部分。
2. 具体实验想法（1–2 周可做）：选 10 个高频 Python 包的版本演化（pandas、numpy、scikit-learn、torch、requests、lxml…），每个包从 release notes 抽 5 个 silent semantic change，构造 GeoContra 风格的 contract，跑 GPT-4o-mini / Qwen2.5-Coder-7B 等小模型 + bounded repair loop。预期假设：在 silent shift 这一类任务上，bounded contract loop 让 7B 模型逼近 GPT-4o 性能。如果验证，这是博主"小模型 + scaffolding 替代商业 API"主线的有力佐证。
3. 研究趋势判断：executable contract 这个抽象会变成下一年 LLM-for-code 的主流——GeoContra 之于 GIS、APIE-Bench 之于 Python 兼容性、ArkTS-Bench 之于 OpenHarmony 工具链，结构都同构。博主有"先发命名权"的机会。

---

Themis: Training Robust Multilingual Code Reward Models for Flexible Multi-Criteria Scoring

推荐理由：当前 code RM 几乎全是"functional correctness"一维评分，对博主关心的"可读性 / 风格 / 安全性 / 多语言"维度盲区巨大。Themis 一次性把维度扩成 5 个、语言扩成 8 个，是 reward 信号工程化的一次重要补完。同时它的 350K 偏好对会成为博主以后做小模型代码 RLHF 的现成燃料。

📌 论文信息：Indraneil Paul, Glavaš Glavas, Iryna Gurevych | arXiv:2605.00754 | cs.SE

TL;DR

Themis 一次性给社区交付三件东西：（1）Themis-CodeRewardBench（5 准则 × 8 语言 RM 测试集），（2）Themis-CodePreference（350K 偏好对，目前最大的开源代码偏好数据集），（3）Themis-RM（600M / 1.5B / 7B / 14B / 32B 五个尺寸的 reward model）。50+ 个现有 RM 在 functional correctness 之外的维度普遍不及格，多准则 + 跨语言训练带来强 transfer。

问题是什么？

代码 reward model 当前主流就两条路：

1. execution-only reward：用 unit test 是否过来给 reward。这条路只能给"自包含可执行函数"打分，对真实 SE 中大量的非可执行代码（refactor、注释、API 设计选择）完全失能。
2. general LLM judge：用 GPT-4o 当 judge。这条路贵、且引入第三方 closure，不能用于本地 fine-tune。

更关键的是：code preference 是天然多维的。一段代码可能 functional 正确但风格糟糕，可能可读性极佳但效率差。把这些维度坍缩成一个 scalar，reward signal 信息量大幅丢失——而 RLHF / DPO / test-time scaling 全靠这个信号驱动。

他们怎么做的？

核心 Insight：把 "code reward" 重新建模成多准则、多语言任务，并在数据 + 模型两端同时投资——单纯做 benchmark 而不放数据、放模型，社区跟进难。Themis 选择三件套一起放。

具体方法流程：

1. Themis-CodeRewardBench：5 个准则——functional correctness、可读性、效率、安全、风格——× 8 种编程语言（含 Python / JS / Java / C++ / Go / Rust / TypeScript / 等）。
2. Themis-CodePreference：350K+ 偏好对，覆盖以上所有 cell。论文强调这是目前最大的开源 code preference 数据集。
3. Themis-RM 训练：从 600M 到 32B 的 5 个 reward model，全部用 multi-criteria 训练，对比"只训 functional"和"训全部 5 准则"的 transfer 表现。

跟之前方法的本质区别：以前的 code RM（CodeRM 系列、execution-feedback RM）都是单准则 + 单语言或仅 Python。Themis 是第一个明确把"代码 reward 是 multi-axis 信号"作为核心论点的工作，并且数据规模到 350K 量级。

关键结果

维度	现有 RM 平均	Themis-RM 7B	提升
functional correctness	已饱和	持平	~0
readability	普遍 < 60% acc	显著超过 baseline	大
efficiency	多数 RM 接近随机	有效	大
security	大部分 RM 不会评	有效	大
style	不会评	有效	大
跨语言 transfer	主要在 Python	8 语言间正 transfer	显著

结果解读：

• 一个非常重要的副作用：multi-criteria training 不仅没拖累 functional correctness，反而提升了它——这是典型的"多任务正向 transfer"，意味着可读性/效率信号能帮模型学得更"懂代码"。这是论文最有意思的发现。
• 600M 的小模型在 multi-criteria 设定下表现意外不差——对博主"小模型 + 静态分析压问题"路线是好消息：reward 信号端也可以小模型化，不必依赖 GPT-4o judge。
• 跨语言 transfer 显著正——意味着Themis-CodePreference 这个数据集对 ArkTS / Cangjie 等低资源语言可以做 zero-shot/few-shot 适应。这正好对接博主低资源新生语言生态的研究路径。

局限性与开放问题

• 局限 1：5 个准则的标注一致性如何？论文给了一些 ablation 但没有 Cohen κ / Gwet AC1 这种博主一直强调的严格一致性指标——而 readability / style 这种主观维度本身一致性就低。
• 局限 2：偏好对的来源——是合成（用强 LLM 生成）还是人类标注？如果偏好生成本身依赖 GPT-4 等大模型，就有 reward hacking 风险（RM 学到的是 GPT-4 的偏好而不是人类偏好）。
• 开放问题：350K 偏好对中有多大比例是 functional correctness 维度？如果其他四个维度数据量小，所谓的 multi-criteria 提升可能只是"更大的 functional pool"。这一点论文需要拆数据分布表。

💡 对我们的启发

1. 直接可用的技术点：博主目前的小模型代码工作如果要做 DPO / RLHF，Themis-CodePreference 是现成的 350K 偏好对燃料——而且包含 8 种语言，对 ArkTS 工作做 cross-lingual transfer warmup 极其有用。
2. 具体实验想法（1–2 周可做）：用 Themis-RM 7B 给 SWE-bench / RepoCod 上 OpenHands agent 的所有候选 patch 打 5 维分，看**"功能正确但 readability/security 低分"的 patch** 占比有多少。预期假设：当前 agent 输出的 patch 在功能维度逐渐饱和，但在可读性 / 安全性维度仍是 50–60% 这个区间，意味着未来 agent 评估的下一个增长点在非功能性维度。这跟博主"benchmark 合理性 + process quality"的论调形成正面合体。
3. 研究趋势判断：multi-criteria + cross-lingual code RM 是 2026 下半年 RLHF/test-time scaling 的标准基础设施。博主可以把同一思路移植到 ArkTS / Cangjie，做"ArkTS-RM" 一类的小数据集 + 小模型实验——niche 防御力极强，因为 Themis 不会专门为低资源语言投资。

---

To Call or Not to Call: A Framework to Assess and Optimize LLM Tool Calling

推荐理由：这是今天最贴近博主"agent 边际价值量化"的论文——它直接把"agent 何时调用工具"这个决策抽象成一个normative vs descriptive 不对齐问题，并且用 hidden-state probing 训轻量估计器纠偏。这正是博主一直在做的"LLM 单个设计动作的真实贡献"风格的工作。

📌 论文信息：Qinyuan Wu, Soumi Das, Mahsa Amani, Arijit Nag, Seungeon Lee | arXiv:2605.00737 | cs.AI

TL;DR

作者把 LLM 工具调用决策拆成 necessity / utility / affordability 三个因子，分别从 normative（最优分配反推真实 need 和 utility）和 descriptive（模型行为反推自我感知 need 和 utility）两个角度估，发现两者普遍不对齐。然后用 hidden-state 训轻量估计器，driving 简单 controller 提升 6 个模型 × 3 任务的决策质量与最终性能。

问题是什么？

当 LLM 配上 web search / code interpreter / database query 等工具后，一个常被忽视的事实是：调工具未必对。

• 模型已经知道答案时，调用 web search 反而引入噪声（错误信息、不相关 snippet）。
• 模型该调用时却不调用，凭幻觉答案胡说。
• 工具 budget 受限时（QPS / cost），需要把工具花在最有 utility 的查询上。

更深的一层问题是：LLM 自己并不能可靠地知道自己什么时候该调工具——它的 calibration（"我有多确定"）跟真实正确率系统性偏差。这跟博主一直关注的"agent 单个设计动作的边际价值"问题完全同构——只不过这里的"动作"是工具调用 yes/no。

他们怎么做的？

核心 Insight：把工具调用决策同时从两个互补角度建模——

• Normative（应该怎么决策）：在最优分配假设下反推每个 query 的 true necessity 和 true utility。
• Descriptive（实际怎么决策）：从模型行为反推它"自我感知"的 necessity 和 utility。

两者的差就是 calibration gap，是改进的空间。

具体方法流程：

1. 三因子框架：necessity（必要性）、utility（提升幅度）、affordability（预算约束）—— borrow 自决策论。
2. Normative estimator：把工具调用看成预算受限分配问题，用 ground-truth 数据反推每个 query 的最优 (need, util) 标签。
3. Descriptive estimator：从 LLM 的 hidden states 训一个轻量 probe，预测 LLM 自己感知到的 (need, util)。
4. Controller：用 normative 估计的 need、util 替代 LLM 自我感知，决定是否调工具。
5. 在 3 个任务 × 6 个模型上验证 controller 的提升。

跟之前方法的本质区别：当前的 tool-use 优化主流是"训一个更聪明的 router LLM 决定是否调工具"，本质还是让 LLM 自己评——只是换了一个 LLM。这篇是承认 LLM 自评不可靠 → 直接用 hidden-state probe + 外部 oracle 标签，从博主"LLM 自我反思系统性偏差"的研究哲学看，这条路才是对的。

关键结果

设置	决策质量	最终任务性能
LLM 自我感知 baseline	中等	中等
+ hidden-state probe 估计 need/util	显著高	高
6 个模型一致正向	✓	✓

任务覆盖：3 个任务（含 web search 类）× 6 个模型，结果一致。

结果解读：

• 一个非常重要的副发现：LLM 的"自我感知 need 和 utility"与最优策略系统性偏差——这是定量证据，不只是 anecdotal。配合博主之前 SWE-bench trace 分析里的"agent 触发 test 决策与是否真正改善 patch 关联性弱"的现象，是同一个故事的不同侧面。
• hidden-state probe 是轻量的（参数量远小于 LLM 本身），意味着这个 calibration 信号可以低成本 build 进任何 agent loop。对博主关心的"小模型 agent + 静态信号"路线特别友好。
• 在三个任务上都正向，说明这个 calibration gap 不是某个任务的特例，是 LLM 普遍弱点——同时也说明这个研究方向有 generalization 空间。

局限性与开放问题

• 局限 1：normative estimator 依赖 ground-truth 数据反推"最优"决策，这在 SE 场景（无 oracle 答案）很难直接迁移。需要设计 SE-friendly 的 normative proxy（如 "agent 不调用 test 但 patch 错"作为 necessity 标签）。
• 局限 2：实验集中在 web search 这一类工具。代码 agent 真实使用的工具更多样（read_file、run_test、git_diff、apply_patch），每个工具的 calibration 偏差可能完全不同——需要工具级 ablation。
• 开放问题：probe 是基于 hidden state 的 supervised 训练，部署到新模型时是否需要重新标注训练？probe 的跨模型迁移性能没在论文里讨论。

💡 对我们的启发

1. 直接可用的技术点：博主的 SWE-bench / OpenHands trace 分析可以直接复用 normative vs descriptive 两元框架——把"agent 是否调用 test execution"建成一个决策变量，从 trace 反推 normative need（是否真有必要 run test）和 descriptive need（agent 是否调用了），然后量化两者的 gap。这正好对应博主之前"test execution 只贡献 1.25pp"那篇工作的下一个版本。
2. 具体实验想法（1–2 周可做）：拿 SWE-bench Verified 上 3 个开源 agent (OpenHands、Aider、SWE-agent) 的 trace，对每个 step 标注 (action_type, normative_need, descriptive_need)。预期假设：descriptive need >> normative need（agent 过度调用 tool 但没有真实价值），尤其是 read_file 和 run_test 类操作。如果验证，这是一篇"agent action calibration gap"的数据驱动论文，思路上能直接走博主"边际价值量化"主线。
3. 研究趋势判断：hidden-state probing → controller 这个 lightweight 模块化范式正在成为 agent 工程主流（不再训整个 LLM 而是只训一层 head）。博主可以提前布局——这条路的最大优势是对小公司 / 学术组也友好，不需要重训大模型，只需要 trace + probe，资源约束完全契合博主的实际情况。

---

方法对比

维度	AutoMat	GeoContra	Themis	To Call or Not to Call
核心方法	端到端 reproduction benchmark + claim 判定	executable contract + 三层 verification + bounded repair	多准则 × 多语言 reward bench + 350K 偏好对 + 5 尺寸 RM	normative vs descriptive 决策框架 + hidden-state probe
评估对象	coding agent 的 end-to-end 能力	LLM 生成的 GIS 代码	任意 code-quality reward 信号	LLM tool-use 决策本身
数据需求	高（领域专家 curation）	中（per-task contract）	高（350K 偏好对）	中（hidden state + 任务标签）
计算开销	极高（要真跑材料模拟）	中（contract verifier + repair loop）	高（训 32B RM）	极低（轻量 probe）
适用场景	scientific reproduction、agent benchmark methodology	LLM-driven 领域代码生成（GIS、CAD、bio）	任何 code RLHF / DPO / test-time scaling	任何 agent tool routing 优化
与博主的契合度	benchmark 设计 + process quality	program repair + 静态信号驱动	小模型 RLHF / 多语言 transfer	agent 边际价值量化
主要局限	单 domain、claim curation 成本高	contract 构造仍 manual、loop 成本未拆	准则一致性、偏好来源未拆	normative oracle 在 SE 场景难拿到

把这四篇放在博主的研究矩阵上：AutoMat 给"研究什么任务"，GeoContra 给"如何修代码"，Themis 给"如何打分"，To Call or Not 给"如何决策"——四块拼起来正是一个完整的下一代 LLM-for-SE 评估 + 修复 stack。今年要发顶会的话，这四篇是必备 related work。