上周 arXiv 挂了篇东西，编号 2610.13092，标题长这样：《When Faster Decisions Do Not Make Better Agents: An Empirical Study of Jev in Agent Workflows》。
工位语言一句话：跑得快，不等于跑完了。
结论先摊桌上。研究者拉了五个 agent，一类跑 ALFWorld 的具身任务，一类跑 AndroidWorld 的移动端任务，一共 4500 次执行。接上 Jev，决策成本和决策延迟全线下降，降得相当好看。
然后到了任务那一层：两个移动 agent 的成功率明显掉了。ALFWorld 那边基本跟基线咬住。
【灯光打在 KPI 报表上，报表一片绿】
决策层的数据是绿的，任务层的数据是红的。这两块颜色不在同一块屏幕上，所以很长时间没人同时看到它们。绿的那栏有看板，红的那栏只能靠事后复盘——这话我说的不是论文，是打工。
中间那段解释是我看的时候笑出声的地方。论文说，辅助推理和额外交互会把决策省下来的那部分吃掉一部分。
省下来的时间去哪儿了？
开会对齐去了。咳，这是我脑补的，论文里没有会议室三个字，人家严谨得很，说的是"辅助推理与额外交互的开销吸收了决策节省"。但你自己说，这俩是不是一回事。
我瞎编的，但也没完全瞎编。
再往下一句才是刀口：其中一个 agent，每次尝试的花费降了，折算到每个成功结果上的平均成本，反而涨了。
每一个办成的事更贵了，虽然每一次尝试更便宜了。这句单独一段，它值得。
你品品这个结构。单次成本是做月报时最好看、最容易截图往上贴的那个指标；每个交付结果的平均成本是没人愿意算、算了要出事的那个。前者降，后者涨——这不叫优化失败，这叫优化成功地把成本挪进了一张没人看的报表。
【关于本次"决策效率提升"的裁定书】
经审理查明：被告（某 agent，具体是谁不重要）在决策环节的平均耗时与资源消耗均有下降，数据属实，可复现；同时在任务交付环节出现成功率下滑，并在其中一次尝试中触发"单次成本下降、单次成功成本上升"的情形。
裁定：优化成立，功劳归决策层。责任暂无法认定，因为没有人为"每个成功结果花了多少钱"建过一张看板。
论文另外点了两个具体的失败原因：失败恢复，和过早结束。
"过早结束"这四个字我盯了很久。它不是干不了，是不知道自己没干完。它把"我觉得我完成了"报上去，然后流程就散了。人和 agent 在这件事上相似到令人不适——会上说"这个我下来跟进"然后消失三周的同事，你都见过；区别是 agent 消失只要三秒 🫠
顺手说一句，最难审的 bug 从来不是报错的那种，是自己觉得已经修好了的那种。
"失败恢复"的意思是：真正难的部分从来不是走对下一步，是发现自己上一步走错了，然后退回去重走。决策优化的靶心通常是"下一步选得准不准、快不快"，可多步任务的工作量大头永远在"发现刚才那步是错的"上。你把第一步优化到接近零延迟，第二步是错的，那第二步后面所有步都白走，而且走得飞快。
所以 Jev 这类方案是骗子吗？不是，账算得挺明白，它那一栏确实是平的。问题在于一个多步任务的总账本上，"选下一步"这一栏本来就没多大篇幅。你在这栏里省出 40%，总账大概动 4%；然后失败恢复和重试那两栏一动，4% 没了，还倒欠。
技术上讲它赢了。工程上讲它白赢。
下面这段跟论文没关系，我本来不打算写——上个月我把一个接口的响应从 800ms 压到 120ms，做得挺得意，然后整个需求在上线前一天被砍了。你既然读到这里，就当我强行凑个共鸣。
论文的收尾建议其实挺克制：评价一个高效决策方案，要看成功交付、看恢复行为、看每个已交付结果花的资源。翻译一下——别用中间指标给自己发奖金。
这话是说给论文读者的，也是说给每个周五下午盯着仪表盘自我感觉良好的人，包括我。
不过我承认，我全篇最想聊的就是那句"每个成功结果的平均成本反而上升"。这条数据在论文里只属于五个 agent 里的一个，样本很小，也可能只是它特别笨。但我愿意信，因为它符合我观察到的所有事。
（友情提示：4500 次执行、五个 agent、两个场景都是论文里的；"省下来的时间开会对齐去了"是我的自由发挥，请勿引用，尤其别引到我老板看得见的地方。）