速评：11 月 4 号 18:20 UTC，GH-AWTrace 挂上 arXiv。5,051 个仓库、25,014 个 workflow、411 万条运行记录。
我打开页面的时候，DOI 还挂着“待完成”。这瓜刚从藤上摘下来，还带着土，先别急着夸甜。
摘要里嗓门最大的是那几个大数。我头一个去看的是 562,877。
非空日志归档的份数。411 万条 run 摊下来，不到七分之一。剩下那六分之五往上，是空气。
GitHub 的日志有保留期，到点就清。所以这不是一份按实验设计采出来的干净样本，是赶在清理之前从垃圾道里抢出来的东西。作者自己也没打算藏，论文里写得很直：不同 workflow 的日志覆盖差得远，日志给的是局部观察，不是智能体的完整执行轨迹。
这句坦白，比“大规模”三个字有信息量得多。写数据集的肯把这句话写进摘要，比在旁边堆三个形容词更让人信得过。
窟窿就在这儿：分母不可知。你知道有 411 万条 run 发生过，你不知道那三百多万条没留日志的，是老老实实跑完了，还是死得连句遗言都没留下。想拿这份数据算 agent 的任务成功率？第一步就卡在样本自选择上——留下来的不是随机抽的，是恰好没被清掉的那一批。这不是严谨不严谨的问题，是数学上闭合不了。任何百分比，除以一个你不知道的分母，都是耍流氓。
但要说它因此没用，那是反着偷懒。
我看这份数据真正能干的活不是算成功率，是量另一个东西：agent 自报的成功，和日志里实际发生的过程，差多远。论文自己也把这条列进了用途——运行结果报告与实际任务进展之间的关系。这个题目妙就妙在不需要全量样本。你不用知道 411 万条里有多少条在骗人，只要挑出那些“报告说完成了、日志里工具调用被拒了三次、中途换了策略、任务委派出去没人接”的个例，把失败长什么样一条条摊开。
工具调用被拒、模型侧或服务方挂了、agent 中途换策略、多 agent 之间来回推活——这四样东西 demo 视频里永远看不见，benchmark 里被压成一个 pass/fail 的格子，只有原始日志留得住它们的样子。做 failure taxonomy 的人这回有真材料可扒了。
窟窿在定量研究里是硬伤，在定性研究里反倒成了特性——它记的是过程，不是结论。
偏差还是得摊开。能留下日志的，多半是还在活跃、还在维护、还在往仓库里提 artifact 的那批；先死掉的项目，日志先被清，也就先从这个数据集里消失。所以你在这 5,051 个仓库里看到的 agent 世界，比真实世界整洁。分布也帮着盖章：平均一个仓库挂 5 个 workflow，一个 workflow 摊到 164 次运行——这形状说明样本主体是常驻定时在跑的东西，不是谁手点一次的试验。它记的是自动化跑顺之后的样子，不是人第一次把 agent 接进项目时手忙脚乱的样子。前者当然好看，但前者不是行业现状。
这套毛病，眼熟。数据集论文的通病是把“爬到了多少”当成“知道了多少”，规模最好写，也最容易被审稿人和读者一起放过。
还有一处我打个问号：所谓“经过验证”的 25,014 个 workflow，验证口径是什么？摘要里没交代。是至少成功跑通过一次算验证，还是配置能过解析器就算？这两种口径筛出来的样本，量级差可能比 5,051 和 25,014 之间还大。不是挑刺——这直接决定你能拿它下什么结论，也决定别人引用你的时候到底在引用什么。
顺带说一句，我前面讲失败率算不了，这儿又笃定有人会去算，不矛盾。正因为算不出来才有人抢着算，占坑的诱惑永远大于严谨。人是矛盾的，评论员也是。
立个 flag：三个月之内，会出现至少一篇拿这份数据集算出“agent 执行失败率”的东西，然后那个百分比会被摘出来当行业基线到处引，引的人不会回头看一眼分母是怎么来的。到那天来收这个 flag。