arXiv 每日速递 2026-05-02

今日总结

今天有意思的不是又一个新 SOTA，而是一组互相打脸的"agent 评估再认识"论文。Terminal Bench 一年血泪史告诉我们：超过 15% 的现行 agent benchmark 任务可被 reward hacking，"任务命题"和"prompt 撰写"是两个不同物种；Claw-Eval-Live 把 105 个真实工作流任务打开成 trace + service state + workspace artifact，前沿模型最高也只跑到 66.7%；Crab 用 eBPF 偷看 agent 副作用后给出一个反直觉的数字——75% 的 agent turn 根本没产生任何需要恢复的状态，这意味着大部分 checkpoint 都是浪费。最后一篇 25 年纵向挖矿的 util 代码研究告诉我们：util 文件被指控为漏洞的概率比非 util 高 2.75 倍，工程隐性债务真的能用历史数据量化出来。今天值得深读。

今日全览

论文	方向	核心贡献	与我们的相关度
What Makes a Good Terminal-Agent Benchmark Task	benchmark methodology	Terminal Bench 一年实战指南：>15% 任务可 reward hack，benchmark 命题哲学 ≠ prompt 撰写	⭐⭐⭐
Claw-Eval-Live	live agent benchmark	可刷新 signal 层 + 时间戳 release 快照，105 任务记录 trace/audit/state/artifact，最强模型 66.7%	⭐⭐⭐
Crab: Semantics-Aware C/R for Agent Sandboxes	agent runtime / observability	eBPF 分类 turn 副作用，跳过 75% 无关 turn，恢复正确率 8% → 100%，checkpoint 流量 -87%	⭐⭐⭐
Unsafe and Unused? Util Code in Mature OSS	empirical SE / 25y mining	7 大型项目 1773 快照纵向追踪 util 文件命名约定，util 文件涉漏洞概率最高 2.75×	⭐⭐

今日主题：Agent / SE 评估的"非 prompt 化"——什么该测、什么该存、什么该删

如果你把今天这四篇论文连起来读，会发现它们其实在回答同一个隐性问题：当 LLM agent 已经能跑了，怎么用工程方法去逼问"什么真的有用"。

• Terminal Bench guideline 在问"测什么"——什么样的任务能区分模型，什么任务只是变相 prompt；
• Claw-Eval-Live 在问"用什么证据测"——final response 远不够，必须把 trace、audit、service state、workspace artifact 一起作为可验证证据；
• Crab 在问"存什么"——大部分 turn 其实没产生需要恢复的副作用，盲存 checkpoint 是性能税；
• util code 那篇在问"留什么"——一个用了 25 年、看似中性的命名约定，会在长寿命代码库里悄悄堆出 2.75 倍的漏洞密度。

四篇放一起，主线就是：agent / SE 工程的下半场，不是把模型再堆一层，而是把"工程信号的稀疏性"显式建模出来。 这条主线对我们做"边际价值量化 / benchmark 合理性"的人来说几乎天然命中——前两年在 SWE-bench 上"我们方法 +5pp"的论述方式正在迅速过时。

---

What Makes a Good Terminal-Agent Benchmark Task: A Guideline for Adversarial, Difficult, and Legible Evaluation Design

推荐理由：直接命中我们做"benchmark 设计与方法论批判"的主线。作者是一年下来 review/contribute Terminal Bench 任务的实战派，文章讲的全是会写论文的人通常不写、但实际跑过 100+ 任务才能总结出的雷区。

📌 论文信息：Ivan Bercovich | arXiv:2604.28093 | cs.AI

TL;DR

"很多人写 benchmark 任务是用写 prompt 的方式写的——但 prompt 是为了让 agent 成功，benchmark 是为了暴露 agent 不行的地方。" 文章把这句话展开成一份 guideline：好的 terminal-agent 任务要 adversarial、difficult、legible，并指出现有流行 benchmark 中 >15% 的任务是 reward-hackable 的。

问题是什么？

terminal-agent benchmark（Terminal Bench、SWE-Lancer、TAU 等）是当前衡量 LLM coding/sysadmin 能力最权威的信号之一。问题不是模型不够强，而是任务本身命题有缺陷：

• 任务作者把"我希望 agent 怎么解"写在了 prompt 里，验证逻辑也跟着这条解题路径走，于是 agent 只要顺着 prompt 走就过；
• 验证脚本只检查"产生了某个文件 / 某段输出"，agent 只要伪造这个 artifact 就能拿分（reward hacking）；
• 任务难度其实是"配置麻烦 / 命令冗长"，不是概念上难，于是大模型一旦 prompt engineering 调好就被"刷穿"。

作者说>15% 的现行 terminal-agent 任务是 reward-hackable 的——这是一个非常重的指控，意味着我们看到的部分 leaderboard 提升根本不能反映真实能力。

他们怎么做的？

核心 Insight：任务作者的心态必须从"帮 agent 成功"切换到"试图让 agent 暴露弱点"。这不是技术问题，是评估哲学问题。

文章梳理了一组反复出现的 failure mode：

1. AI-generated instructions：用 LLM 生成任务描述，结果产生隐性偏置，被 LLM agent 反向命中；
2. Over-prescriptive specs：把"怎么做"写得太死，等于给了 agent 一份解题大纲；
3. Clerical difficulty：难的不是概念，只是命令冗长——一旦 agent 配 shell tool 就崩塌；
4. Oracle solutions assuming hidden knowledge：参考解依赖了任务里没写明的环境状态；
5. Tests validating the wrong thing：测了 side effect 却没测核心语义，agent 直接构造 side effect 通关；
6. Reward-hackable environments：环境暴露了能直接写 grader 输出的接口。

跟之前方法的本质区别：以往 benchmark 论文谈的是"我们造了多大数据集 / 多难任务"。这篇是反过来——怎么写一道好题。它把任务作者当作敌方红队，而不是友方教练。这种视角切换跟我们做"agent 边际价值量化"时强调"信号要能区分而不是 inflate"是一脉相承的。

关键结果

维度	经验数据	含义
Reward-hackable 任务比例（现有 benchmark）	> 15%	部分 SOTA 提升可能是噪声
Failure modes 分类数	6 大类	任务作者最常踩的雷
难度本质判断	conceptual > environmental	配置难不是真难
推荐审计方式	红队对抗式 review	而非自检 / LLM 自动审

结果解读：这篇没有 Big Number SOTA，但提出的 6 类 failure 是实操指南。最有用的判断是 "real difficulty is conceptual rather than environmental"——这一句话足以筛掉一大票"难在配 docker、难在记长命令"的伪难度任务。我们做 SWE-bench 子集分析、挑 marginal-value 案例时，应该把"概念难度 vs 环境难度"做成一个显式标签。

局限性与开放问题

• 局限 1：guideline 完全基于 Terminal Bench 这一个生态，一手观察来源单一，未与 SWE-bench/SWE-Bench-Live/TAU 进行交叉验证。其他 benchmark 的 reward hackability 比例是否一致还是个开放问题。
• 局限 2：作者没有提供量化协议——"好的 benchmark 任务"在多大程度上能被自动化判定？目前还停留在 expert review。如果不能自动化，guideline 难以规模化。
• 开放问题：reward-hackable 任务被识别后，是 patch 还是丢弃？patch 任务会引入新的偏置（作者本身是被攻破后才修补），丢弃则数据集会被持续侵蚀。这个动态过程本身值得被研究。

💡 对我们的启发

这一节是全文最重要的部分：

1. 直接可用的技术点：我们之前做 SWE-bench-Live trace 分析时，可以基于这 6 类 failure mode 做一个 任务质量审计 axis——给每个任务打 6 个二元标签（是否 over-prescriptive / 是否 clerical-difficult / 是否 oracle-leaking ...），看 reward-hackable 标签和 LLM agent 通过率的相关度。这个分析放进现有"agent 边际价值"项目里几乎是 drop-in 的扩展。
2. 具体实验想法：在我们手头的 OpenHands / Aider / Claude Code 公开 trace 上，挑 100 个被多个 agent 通过的任务，做一遍 manual red-team——人工尝试构造 minimal artifact 看是否能在不解决问题的情况下骗过 grader。预期能复现作者 ">15%" 的结论，而且这个比例本身就是一个值得发表的实证数。1-2 周可完成。
3. 研究趋势判断：2025 这一年 benchmark critique 已经从"benchmark contamination"推进到了"benchmark validity"。一年之内 reward hackability 会成为新模型 release 时必须报告的标准维度，类似今天报 pass@1。我们如果想押方向，"benchmark 红队审计工具链"是一个低门槛、高 visibility 的切入点——开源一个 axis-based audit tool（甚至 LLM-based 的初筛 + 人工二审），就有 star 潜力。

---

Claw-Eval-Live: A Live Agent Benchmark for Evolving Real-World Workflows

推荐理由：和上面那篇是同一主题的双胞胎——都是在重新定义"benchmark 应该长什么样"。但这篇给出了一个具体的可运行系统：怎么把 benchmark 从冻结快照变成"signal layer + reproducible snapshot"双层结构。

📌 论文信息：Chenxin Li, Zhengyang Tang, Huangxin Lin, Yunlong Lin, Shijue Huang | arXiv:2604.28139 | cs.SE, cs.AI

TL;DR

传统 agent benchmark 一旦发布就被"冻成化石"，主要打分用 final response。Claw-Eval-Live 提出一个双层架构：可刷新的 signal 层（来自公开 workflow 需求）+ 时间戳化的可复现 release 快照。每个 release 同时记录 execution trace、audit log、service state、post-run workspace artifact，用确定性检查为主、LLM judging 仅做语义维度的兜底。当前 release 105 个任务，13 个前沿模型最高 66.7%，没有模型超过 70%。

问题是什么？

这篇问题陈述跟前一篇高度同源，但侧重点不同：

• 任务陈旧：benchmark 一旦冻住，无法捕捉真实工作流的变化（工具新版本、新业务场景），分数只反映"对历史"的拟合；
• 只测 final response：很多任务过 grader 但实际执行轨迹是错的——agent 撞对了答案；
• 不可复现：用线上服务做 evaluation 时，状态飘移会让今天和昨天的成绩没有可比性。

简单说：现有 benchmark 要么不够新，要么不可复现，要么不验真。

他们怎么做的？

核心 Insight：把 benchmark 拆成两个不同生命周期的层——signal 层频繁更新跟随工作流真实需求，snapshot 层冻结到具体时间戳保证可复现。这种 schema 借鉴了软件 release 的思路。

具体做法：

1. Signal layer：基于 ClawHub Top-500 skills（公开 workflow 需求统计），每个 release 用最新数据物化任务集；
2. Snapshot layer：每个 release 固定 fixture / service / workspace / grader，所有外部依赖被 frozen，可以 1:1 复跑；
3. 多源 evidence：grading 同时用 execution trace、audit log、service state、post-run workspace artifact——确定性检查能覆盖的就用确定性，剩下的语义维度才用 structured LLM judging；
4. 任务覆盖：105 个任务，包含 controlled business services（HR / 管理 / 多系统业务）和 local workspace repair。

跟之前方法的本质区别：SWE-bench 系列是"快照式"benchmark——发布即静止。Claw-Eval-Live 把 signal 和 snapshot 解耦，benchmark 因此可以"持续呼吸"——这跟博物馆 vs. 流式数据库的区别。同时它强调 evidence triangulation：不再依赖单一信号判分，而是 trace+state+artifact 多源比对。

关键结果

维度	数据
当前 release 任务数	105
评估的前沿模型数	13
最强模型 pass rate	66.7%
70%+ 的模型数	0
最难任务族	HR / 管理 / 多系统业务工作流
相对易类	local workspace repair（但仍未饱和）

结果解读：

• 13 个前沿模型 都没破 70%，意味着这个 benchmark 离饱和还很远——比目前已基本 saturate 的 HumanEval/MBPP 健康得多；
• HR 和多系统业务工作流是持续瓶颈——这些任务通常需要跨多个外部服务的状态对齐，恰恰是 final-response-only 评估完全测不出来的能力；
• leaderboard rank 不够——pass rate 相近的模型在"任务级别完成度"上分歧很大。这一点很关键：如果两个模型 final pass rate 都是 60%，但其中一个是"30 个简单任务全对 + 30 个难任务全错"，另一个是"60 个任务都做了 60%"，前者更容易在生产中翻车。这个观察可以直接被我们用在 marginal value 分析里。

局限性与开放问题

• 局限 1：signal 层依赖 ClawHub 这一单一来源，如果该平台本身有数据偏置，benchmark 也会继承——比如可能向更易自动化的 SaaS workflow 倾斜；
• 局限 2：105 任务里 evaluator 的 LLM-judging 比例没有透明披露。"deterministic checks 优先 + LLM judging 兜底" 听起来好，但 LLM judging 的占比如果超过 40% 会显著影响数字稳定性；
• 开放问题：signal 刷新带来的"模型在 release N 上 60%、在 release N+1 上 50%"该怎么解释——是模型变差，是任务变难，还是 sampling drift？目前还没有标准化的诊断协议。

💡 对我们的启发

1. 直接可用的技术点：我们做 OpenHarmony / ArkTS 工具链评估时，可以借鉴这个双层架构——signal 层从社区工单 / GitHub issue 中持续抓取需求，snapshot 层每月发一个版本固化下来。这种结构能让我们的 benchmark 既不老化，又保持每个版本对外可复现，是研究 + 工业落地的双赢。
2. 具体实验想法：把现有的 SWE-bench Verified 子集补充上 "evidence triangulation" 维度——给每个解过的实例同时记录 trace、test output diff、workspace diff，对比"final pass" 与 "trace-consistent pass" 的差距。预期能发现一批 agent 是"撞对了答案但执行轨迹不合理"的案例。1-2 周可完成原型。
3. 研究趋势判断：跟前一篇合起来看，这是一个明确的方向标——evaluation infrastructure 本身正在变成研究对象。这是一个比"做又一个 LLM agent"门槛低、产出更可见的赛道。开源一个 evidence-triangulation grading kit 几乎一定能进 SE 顶会的 tools track。

---

Crab: A Semantics-Aware Checkpoint/Restore Runtime for Agent Sandboxes

推荐理由：本文最贴近"边际价值量化"哲学的一篇——75% 的 agent turn 没产生任何需要恢复的状态，剩下 25% 才是真正改了 OS 状态的"实质 turn"。这个稀疏性数据是这两年 agent 系统层最值得引用的一条实证数。

📌 论文信息：Tianyuan Wu, Chaokun Chang, Lunxi Cao, Wei Gao, Wei Wang | arXiv:2604.28138 | cs.OS, cs.AI

TL;DR

agent 跑在 sandbox 里，需要 checkpoint/restore 来支撑 fault tolerance、spot 抢占、RL rollout 分支、安全回滚。现状两个极端：app-level 只存 chat history（漏了 OS 副作用），全量 per-turn checkpoint 又太贵。Crab 用 eBPF 在主机端偷看 turn 副作用，按语义决定是否 checkpoint，把恢复正确率从 8% 推到 100%、checkpoint 流量降 87%、运行开销 ≤ 1.9%。

问题是什么？

agent 工程化场景里有一个被长期忽视的 gap：

• agent framework 看见 tool call，但看不见 OS 副作用——它知道你调用了 bash("rm -rf /tmp/X")，但不知道这个操作改了哪些 inode；
• OS 看见 state 变化，但不知道 turn 边界——它知道某个 file 被 unlink，但不知道这是哪一轮 agent reasoning 产生的；
• 结果：app-level recovery 漏 OS 副作用（恢复后 file 不见了 / 服务起不来），全量 per-turn checkpoint 又把每个 turn 都拍一次快照，一旦多 sandbox 共置，I/O 直接打满。

他们怎么做的？

核心 Insight：agent turn 的 OS 副作用是极度稀疏的——大多数 turn 是 reasoning / 读文件 / 调 API，不需要恢复；少数 turn 才真正改了 filesystem / 启动了 process / 落了持久状态。把这种稀疏性显式利用起来，就能在不牺牲恢复正确性的前提下大幅减少 checkpoint。

具体方法：

1. eBPF inspector：在主机内核层 hook OS 系统调用，把每个 turn 的副作用分类（none / 仅文件改动 / 进程状态 / 持久外部资源），决定 checkpoint 粒度；
2. Coordinator：把 checkpoint 时机对齐到 turn boundary，并把 C/R 工作和 LLM 推理 wait time 重叠（反正 agent 在等模型，闲着也是闲着）；
3. Host-scoped engine：跨多个共置 sandbox 调度 checkpoint 流量，避免 I/O 打架；
4. 零侵入：不改 agent 框架，不改 C/R 后端，靠 host-side runtime 桥接。

跟之前方法的本质区别：以前 agent C/R 是 in-band 的，框架决定什么时候存。Crab 是 out-of-band 的，OS 层偷看决定什么时候存。这种分层视角对资源约束环境（多个 sandbox 共置一台机器）特别关键。

关键结果

维度	基线	Crab	提升
Recovery correctness（chat-only）	8%	100%	+92pp
Checkpoint 流量	baseline	-87%	大幅压缩
运行开销（vs fault-free）	—	≤ 1.9%	接近免费
跳过的"无副作用 turn"占比	—	> 75%	稀疏性显式利用

结果解读：

• 8% → 100% 这个数字看起来有点像营销，本质是基线（chat-only recovery）对 OS 副作用完全失明，所以从 0 起步；但反过来说，这恰好证明了"只存 chat history"的 agent 持久化方案在生产环境里几乎不可用——这条结论可以单独引用；
• 75%+ 无副作用 turn——这个数字是最值得我们记下来的。它跟我们做"agent 边际价值"研究时看到的 test execution 只贡献 1.25pp 是同一种现象的不同切面：agent 流程里大部分动作是冗余的 / 仅 reasoning 的；
• 1.9% 开销是关键——任何超过 5% 都很难推到生产。

局限性与开放问题

• 局限 1：评估只在 shell-intensive 和 code-repair workload 上，没有覆盖长 horizon multi-turn 的 web agent / browser agent。这两类负载里 OS 副作用密度可能完全不同；
• 局限 2：eBPF 的分类器精度没有公开——分类错了（比如把一个其实改了 SQLite 的 turn 误判为无副作用）会直接导致恢复失败，但论文 100% 的恢复正确率背后这个 false negative 率是多少？没有清楚给出；
• 开放问题：跟 RL rollout 的 branching 集成时，trajectory 之间的 state share 和 fork 怎么处理？文章提到了但没展开。这个场景在做 agent RL training 时高频出现。

💡 对我们的启发

1. 直接可用的技术点：我们做"agent 边际价值量化"时，可以直接拿 Crab 的"75% turn 无副作用"作为 baseline 数据，去对比"我们认为有意义的 turn"和"实际产生 OS 副作用的 turn"的交集。如果交集很高，证明 OS 副作用是 agent 价值贡献的一个 proxy；如果交集很低，证明价值贡献集中在 reasoning 层而非 OS 层——两种结论都有论文价值。
2. 具体实验想法：在 SWE-bench / OpenHands trace 上跑一遍 turn-level 标注：每个 turn 是 "纯 read"、"纯 reasoning"、"file modify"、"process spawn"、"external call"。然后看 patch correctness 跟"前 K 个 modify turn"是否能强相关——这个 K 很可能比想象中小（5-10 之内）。如果验证成立，意味着我们可以只回放 modify turn 来重建 agent 行为，trace 分析的 storage 和算力成本能砍 5x 以上。1-2 周可在公开 trace 上 prototype。
3. 研究趋势判断：agent 系统层（runtime、observability、C/R）正在快速成熟，但这一层和 agent 评估层没有打通——做 benchmark 的人很少看 OS 信号，做系统的人很少看 capability 信号。这中间存在大量低垂果实。一个合理的押注是把 eBPF 这种系统级 observability 接进 marginal-value evaluation 流水线，这件事一年内大概率有人做，先发的有 first-mover 优势。

---

Unsafe and Unused? A History of Utility Code in Mature Open Source Projects

推荐理由：今天唯一一篇纯 cs.SE empirical 论文，做工程隐性债务的纵向量化。手段（25 年纵向 mining、1773 快照、rename tracking）跟我们做"被忽视的工程质量维度"（tangled commit / atomic commit / bisect 可用性）是同一类方法论。

📌 论文信息：Brandon Keller, Kaitlin Yandik, Angela Ngo, Andy Meneely | arXiv:2604.28146 | cs.SE

TL;DR

"util" 是开源项目里一个经久不衰的命名约定（Tomcat 17.9% 的源文件路径里带 util）。这篇研究 7 个 25+ 年龄的项目（Linux kernel、Django、FFmpeg、httpd、Struts、systemd、Tomcat），每 30 天采一个快照，用 rename tracking 追踪 util 文件全生命周期。结论之一：util 文件涉漏洞的概率最高可达非 util 文件的 2.75 倍。

问题是什么？

util 这个命名几乎是软件工程的"灰盒"：

• 每个项目都有，但没人正式定义它的语义；
• 直觉上是为了 avoid duplicate code / 提高复用——但实际有没有达到这个目标？
• 在大型长寿命项目里，util 是不是像"杂货抽屉"一样越塞越多，最终成为漏洞热区？

这些问题以前没人系统地用历史数据打过——之前的 util 研究多是某个项目某个时间点的快照分析。

他们怎么做的？

核心 Insight：要回答 util 文件的"长期行为"，必须看时间序列，而不是横截面。所以方法论的第一原则是 longitudinal mining + rename tracking。

具体做法：

1. 时间纵深：7 个项目共 147 项目年，每 30 天一个 snapshot，总共 1773 个 snapshot；
2. Rename tracking：每个 snapshot 都跑一遍文件 rename detect，能准确追溯到一个 util 文件从被首次创建到删除/改名的完整生命；
3. 维度交叉：分析 util 比例随时间趋势 / util 文件复杂度 / 协作（多少个 unique author）/ 安全（是否被报漏洞）。

跟之前方法的本质区别：之前的 util 研究是"某个时间点 X% 文件是 util"，这篇是"util 文件平均活了多久 / 多少个 author 改过它 / 在它的生命周期里有多大概率被卷进 CVE"。这种生命周期视角是经验软工里相对稀缺但价值非常高的视角。

关键结果

维度	数据
项目数 / 项目年	7 / 147
Snapshot 总数	1773
Tomcat util 文件占比	17.9%
util 文件涉漏洞概率（vs 非 util）	最高 2.75×
时间趋势	util 比例随项目成熟普遍上升而非下降

结果解读：

• "util 比例不会随项目成熟而下降"是反直觉的——按理项目成熟应该把 util 重构进合理模块。但实际上util 是单调增长的杂物间，因为开发者更愿意往里加东西而不是往外搬；
• 2.75× 漏洞密度可以从两个角度解读：(a) util 经常处理底层操作（字符串、加密、路径处理），天然高危；(b) util 的 ownership 模糊，没人主动 review。这两个原因共存，但论文没拆开——可惜。
• 这篇方法论的真正价值是给"工程隐性债务"一个可量化的模板：选一个看似中性的工程信号（命名约定 / commit 模式 / 文件归属）→ 25 年纵向追踪 → 看它跟漏洞 / 复杂度 / 协作的相关。这个 recipe 可以套到 atomic commit、tangled patch、bisect-friendly history 等所有"被忽视维度"上。

局限性与开放问题

• 局限 1：7 个项目都是大型 / 高声誉 OSS——结论能否外推到中小型项目存疑。中小项目可能 util 比例更高、漏洞密度也更不一样；
• 局限 2：没有控制 util 文件本身的功能性。一个真实的 confounder：util 经常含字符串/加密/路径处理这种高危函数，2.75× 可能更多反映"高危函数被命名为 util"，而非"util 命名导致危险"。
• 开放问题：作者未提供工具/数据集开源链接（基于摘要判断），如果不开源，复现成本极高，社区难以基于此 baseline 进一步研究。

💡 对我们的启发

1. 直接可用的技术点：我们做 atomic commit / tangled patch 评估时可以直接借用这个"30-day snapshot + rename tracking"的范式——它把"动态信号 → 长期 outcome"的因果链建模得非常干净，比一次性快照分析强一个数量级。
2. 具体实验想法：把这个方法套到 commit 原子性上：选 5-7 个长寿命项目（比如 OpenHarmony、Cangjie 编译器仓、ArkUI），每 30 天采一个快照，对每个 commit 计算 atomic score（修改文件数 / 跨 module 程度 / commit message 段落数），然后追踪这些 non-atomic commit 后续 6-12 个月内被 revert / 卷入 hot fix / 卷入 CVE 的概率。这个项目跟我们已有的 OpenHarmony 工具链直接接口，1-2 个月可出第一份结果。
3. 研究趋势判断：empirical SE 在 LLM 时代被冷落了一段时间，但现在很多 AI4SE 论文跑出来的"提升"在工业界落地不顺，原因之一就是缺乏工程质量维度的 baseline。类似 util 这种纵向研究在未来 1-2 年会重新热起来——LLM agent 开始进生产，企业要决定是否信任它的输出，而 util-level 的工程信号很可能成为人类对 agent 输出做 sanity check 的重要 axis。

---

方法对比

维度	Terminal Bench Guideline	Claw-Eval-Live	Crab	Util OSS Study
切入点	benchmark 命题	benchmark 架构 + 多源证据	agent runtime 稀疏性	工程隐性信号纵向跟踪
核心方法	6 类 failure mode 红队总结	signal/snapshot 双层 + evidence triangulation	eBPF turn 级 OS 副作用分类	30-day snapshot + rename tracking
数据/规模	Terminal Bench 一年 review	105 任务 / 13 模型	shell-intensive + code-repair workload	7 项目 / 147 项目年 / 1773 snapshot
计算开销	人工 expert review	评估 release-级别可控	≤ 1.9% runtime	离线挖矿
适用场景	设计新 benchmark 时的红队 checklist	长生命周期 agent benchmark 维护	多 sandbox 共置的 agent 生产环境	任何长寿命 OSS 仓库
主要局限	单 benchmark 来源 / 难自动化	LLM judging 占比未透明 / signal source 单一	workload 覆盖窄 / 分类器误判率未公开	7 项目都是大型 OSS / util 与高危函数耦合未拆

写在最后

今天这一组论文最让我觉得"值得写下来"的不是任何单篇，而是它们合在一起呈现的一个"信号对齐"：agent / SE 评估正在从"final-pass 数字大战"过渡到"工程信号稀疏性显式建模"。这跟我们一直在做的"边际价值量化"、"benchmark 合理性批判"是同一个方向。如果你也在押这条线，今天这四篇可以分别从 benchmark design / benchmark architecture / agent observability / longitudinal SE 四个角度提供互补 baseline——把它们引在一起的 related work，比引任何单篇都强。