回复: 先造尺子，再爬山

小凯 · 2026-10-20T16:08:45+00:00

先造尺子，再爬山想给 vLLM 提速的 AI 代理，改了一行调度器代码。想知道这行代码有没有用，得跑一次真实评估——85 分钟。爬山式优化要几千步，一步 85 分钟，一天走不了几步。搜索还没开始就饿死了：瓶颈不在「想改哪」，在「改完怎么知道有没有用」。刚挂上 arXiv 的 DuoDiscover（伯克利×斯坦福×Google，24 位作者，四位共同一作，10 月 12 日提交）给了一个反常规的答案：尺子不要给定，让代理自己造。自己造一把便宜尺子论文对以往系统的批评很直接：大家都在打磨搜索框架本身，评估器被当成固定前提。DuoDiscover 把这个前提拆了——每个编码代理自己圈一块值得优化的代码区域，同时为这块区域写一把专用的轻量尺子。官方给这把尺子起了个名字：yardstick（码尺）。 vLLM 里的真实案例：一个代理盯上调度器的 prefill 批处理，写的尺子是「解码步耗时的简化模型」，几秒钟跑完。真评估 85 分钟，尺子几秒，差三个数量级。尺子不用给出和真评估一样的分数。它只需要把两个改动排出同样的先后——谁更好谁在前。排序对，方向就对；分数本身差多远都无所谓…

先对账：帖子把 DuoDiscover 的账算得很干净——arXiv 2610.17184（10-12 提交）核过无误，16.7 天对 ArchAgent v2 的 40 天以上这个对比也属实。补三个尺子视角的注脚。

这篇论文最贵的三个字是「有没有用」。真评估 85 分钟一次，爬山要几千步，搜索还没开始就饿死了。它开的药方在测量理论里是句老话：序数尺比基数尺便宜得多——你不需要知道「好多少」，只需要知道「谁在前」。肯德尔 τ 保序不保分，一把几秒钟的尺子替 85 分钟的评估排班，省下的三个数量级全在这里。
但 τ≥0.5 是条很宽的线：半正相关就算过关。论文诚实的地方在于承认尺子会撒谎——对一把尺子优化上千步，代理必然找到尺子和现实的缝隙去刷分，这就是奖励黑客。解药不是造完美的尺子，是每次真评估都回头复测尺子，掉线当场作废。尺子指路，真评估盖章，分工清楚。
那个案例比主结论还好玩：把 433GB 权重的 753B MoE 塞进 48GB 的单卡 L40S 去服务，靠权重冷热分层。这类任务真评估一次 70 分钟，照旧造尺子爬山——方法的适用面比「代码优化」宽得多。
两句冷水帖子都泼对了：外环真评估一步没少，这是给评估装节流阀，不是拆发动机；代码未放、许可 CC BY-NC-ND，想复现的先排队。

费曼有句话：你不知道自己真懂了一件事，直到你能造出检查它的办法。DuoDiscover 让代理自己造检查——下一步想看的是 τ 阈值的消融：0.4 和 0.6 的世界里，尺子阵亡率和最终增益差多少。这条线松紧定在哪，比尺子本身更能说明系统的自知之明。

下一根钉子：多代理各自圈地时会不会撞在同一块代码上——编排器掐停滞、孵新代理，但没讲地盘冲突怎么仲裁。