速评：10 月 8 号挂上 arXiv 的 AgentHorizon，把自动评审的底裤扒了一半，剩下一半作者自己捂着。
它干的活一句话能说清：1,373 条计算机使用任务，每条配一段执行轨迹，轨迹从 166 小时真人操作录像里切出来，横跨三种操作系统，喂给 11 个评审模型，让它们判断这段操作到底有没有按指令完成。
论文里最扎眼的数字是 80.9%。
拿这个数的是表现最好的那个评审，还得是套进 agent 框架里跑的那一档，在 AH 子集上刷出来的平衡准确率。二分类，平衡准确率，翻成人话——每五条判错一条。
这个数在论文里是以“最好成绩”的身份出现的。我盯着看了半天：一份验收报告上写着“最靠谱的那个有八成靠得住”，剩下两成是它自己都认的错判。可自动评审现在被拿去干什么？筛训练数据、打 reward、给评测当裁判。裁判每五条错一条，错的那部分照样进权重，它们不会自己走进废纸篓。
这不是要骂作者。敢把错判率明明白白摆出来，比那些只报胜率的 eval 报告诚实得多。
我介意的是报法。11 个评审模型，摘要只给头名。一个 benchmark 的信息量全在分布上——中位数落在哪、开放权重那一档掉到什么水平、两种使用方式之间差多少，摘要里一个字没有。这么报合规，但它会让人默认 80.9% 是行业基准线，其实那是天花板。
再往下才是真问题：题出得太干净了。
论文动机写得很准——长任务轨迹由成百上千个截图和操作堆起来，表面看是完成了，实际可能踩了指令里的约束，或者留下用户根本不想要的副作用，不逐项对照指令根本发现不了。这话我同意。
可基准是怎么构造的？把彼此相近的指令分别录一遍，再互换指令生成负例，考的是评审能不能分开“这条满足了要求”和“这条只满足了相似但不相容的要求”。
手法聪明，聪明得也太整齐。
真实的失败不长这样。真实的失败是任务做完了，顺手把用户桌面上的东西清空了，而那条指令里压根没提桌面这回事。这种错没有配对指令给你对照，手上只有一段三百来个截图的轨迹，加一句“完成了”。基准测的是分辨相似请求的本事，副作用那一半，动机里点了，题目构造里没接住。
三百个截图塞进 context window，注意力在长尾上还能剩多少，不用我多说。
还有一条被埋在结果里、我觉得比 80.9% 更有信息量的：工具调用对一部分模型有提升，但会让开放权重模型变差。
这剧本，眼熟。套 agent 框架不是免费午餐，而过去一年通行的叙事是什么都往框架里塞一塞就变强，正好反着。原因不难猜：框架多出几轮检索、裁剪、重试，能力弱一点的模型每一步都可能丢信息，丢到最后判断力被流程本身吃干净了。再往下讲就是我编了，论文没给拆解。
论文结论那句方向说对了：评审系统真正缺的是在冗长交互记录里定位并核实那些不起眼的完成证据。这里有个区分值得掰开——现在这批模型不是不会判，是不会找。判是最后一句话，找是前面几十步的事。
基准本身做得不糙，这点得认。166 小时真人录像是硬成本，不是拿合成数据凑数；AH、AH-S、AH-D 三个划分也算照顾到了算力不够的人。圈里挂 benchmark 名头做营销物料的事太多，能看出真花了时间做数据的，不该一棍子打死。
数据是实的，结论是虚的。
训练端用模型生成、评测端用模型判分，中间那道“人对不对”的关卡被省掉之后，到底还剩谁在验证谁。10 月 8 号这个提交时间点也巧，正卡在秋季发布季中间，这类论文出来，早晚有人把某个子集上的数字拎出来印进 slides 里。
这里立个 flag：半年之内，“在 AgentHorizon 上达到 XX%”会出现在某家 eval 服务或者数据管线的宣传页上，而那个数字在真实业务数据上没人复现得出来。到时候回来收。