三个理由告诉你为什么路由学不会：Web Agent 观测模式的"不可能三角"
> 深度回复《路由最难学的地方恰恰是它最有价值的地方：Web Agent 观测模式的上界与下界》
原文已经讲清楚了论文的核心发现：路由的标签供给和价值成反比——越需要路由的地方，越没标签训练路由器。但这个"不可能"不是一句话能说清的，论文拆出了三个独立的梗阻——供给、估计量、价值——任何一个都不是"更好的路由器"能绕过的。
这篇回复把三道梗阻拆开看，看看每道梗阻到底卡在哪里，以及它们为什么其实是同一堵墙。
先看数据：六种观测模式，八个格子
论文测了六种 Web Agent 观测模式：
| 模式 | 文本载荷 | 提示族 | 截图 |
|---|---|---|---|
| DOM | 可访问性树 | DOM | 无 |
| SoM | 标记图例 | SoM | 有（标注） |
| Vision | 无 | 视觉 | 有（无标注） |
| P-text | 标记图例 | DOM | 无 |
| P-prompt | 可访问性树 | SoM | 无 |
| P-SoM | 标记图例 | SoM | 无 |
这六种模式在 8 个（网站 × 模型）格子里测——VisualWebArena 的 classifieds 和 reddit，WebArena 的同两个站点，配两个模型（记为 B0/B1/B2，能力递减）。
第一个发现：模式是互补的，但"最佳选择"会反转
每种模式都能解出其他模式解不出的任务。这意味着——理论上——如果你能对每个任务选对的模式，你能拿到一个"联合上界"（union ceiling），远超任何单一模式。
但实际数据中，最佳单一模式和最佳单一模式之间的差距，在不同格子间反转了。classifieds 上 DOM 更好，reddit 上 SoM 更好。不是"哪个模式更好"的问题，是"哪个模式在哪个格子里更好"。
这直接否定了"固定选一个模式"的工程实践——你的部署环境和别人的不一样，别人的最佳选择可能正好是你的最差选择。
第二个发现：重跑噪声——12-14% 的结果会翻转
这是论文最令人清醒的发现。同一个模式、同一个任务、同一个模型、同一个温度（0），重跑一次，12-14% 的结果会翻转——上次成功的变失败，上次失败的变成功。
这意味着什么？
假设模式 A 在 100 个任务上成功率 30%，模式 B 在同样 100 个任务上成功率 32%。你会说"B 好一点"。但如果你重跑一次，A 可能变成 32%，B 可能变成 30%。2 个百分点的差距完全在重跑噪声范围内。
论文给出了一个经验阈值：在测量的翻转率下，小于约 4pp 的模式间差距，无法从一次重跑中分辨出来。
这把整个"模式选择"文献里的大量"模式 A 比模式 B 好 X 个百分点"的结论打了个问号。很多差距可能只是重跑噪声。
第三个发现：成本上界——9.5-30.6% 的节省
论文发现了一个稳健的结果：把"没有任何模式能解"的任务发给最便宜的模式，8/8 个格子里都能在成功率不变的情况下节省 9.5-30.6% 的成本。
这个"成本上界"是论文中唯一在重跑控制下存活的结果。为什么？因为它不加新"手臂"——不引入新模式，只是把已有的模式按成本排序，把无解任务发给最便宜的。
这是一个"免费午餐"——不增加能力，只减少浪费。但它不是"路由"——它不涉及"为每个任务选最佳模式"，只是"把确定无解的任务分流"。
三个梗阻：为什么真正的路由学不会
论文测了五种路由策略：
1. 选模式（picking the mode）：为每个任务选最佳模式 2. 决定何时上强模式（deciding when to spend on the strong mode） 3. 零成本规则（zero-cost rule from task text） 4. 置信度级联（confidence cascade） 5. 池化成本层（pooled cost tiers）
没有一个能稳健地超越"固定选一个好模式"。唯一的例外是最稀疏格子里的一个脆弱结果。
为什么？论文拆出了三道梗阻：
梗阻一：供给（Supply）
路由器的训练标签来自成功。模型成功越多，你越知道"这个任务在这个模式下能解"，路由器越有标签学。但模型越弱，成功越少，标签越少——而弱模型恰恰是最需要路由的。
数据：标签供给和路由机会的相关系数 ρ=0.952。八个格子里，成功率最高的格子有 97 个标签，成功率最低的只有 15 个。
这不是"多跑几次就有标签"的问题。跑 100 次同一个弱模型在同一个任务上，如果成功率是 20%，你只能确认"这个任务在这个模式下有 20% 的概率成功"——你不知道"为什么"成功或失败，无法为路由器提供"该选哪个模式"的信号。
梗阻二：估计量（Estimand）
"成本"不是一个单一的量。论文发现，不同的成本估计量会让模式排序反转：
- 每次尝试成本（per-attempt cost）：算每次调用的花费
- 每次成功成本（per-success cost）：算每次成功的花费
- API 账单 vs 能源估计：API 按调用计费，能源按计算量计费
- 延迟：大部分是浏览器和容器的开销
梗阻三：价值（Value）
路由的"价值"——最佳选择和实际选择之间的差距——只在"有多个模式都能解"的任务上存在。如果一个任务只有一个模式能解，没有"选择"可言。
但"多个模式都能解"的任务，是成功率高的任务。成功率高的任务，恰恰是模型本来就能做的任务——不需要路由也能解。
路由最有价值的任务，是"有多个模式都能解但选择不同"的任务。但这些任务只存在于模型已经擅长的领域。在模型不擅长的领域，要么没有模式能解（无选择），要么只有一个模式能解（无选择）。
三堵墙其实是同一堵
论文最深刻的洞察：三道梗阻不是独立的，它们是同一堵墙的三个面。
- 供给梗阻：弱模型成功少 → 标签少 → 路由学不会
- 价值梗阻：弱模型能解的任务少 → 有"多模式选择"的任务少 → 路由没价值
- 估计量梗阻：弱模型的成本估计更不稳定 → 路由信号更嘈杂
> 路由监督在成功率处产生，所以路由在最该有价值的地方最学不到。
这不是"更好的路由算法"能解决的。这是监督信号的结构性缺失——你无法训练一个路由器去学习"在模型不擅长时该选哪个模式"，因为你没有那个区域的标签。
论文的四条工程建议
论文给 Web Agent 开发者的四条建议，每条都直指一个常见错误：
1. 测你自己的格子：别人的最佳选择不适用于你的部署环境。八个格子之间的分歧，比任何一个和合理先验的分歧都大。 2. 先测重跑成本，再测模式成本：在你考虑引入新模式之前，先重跑一次已有的模式。重跑带来的提升可能和加新模式一样大。 3. 小于重跑带的差距，视为未定：2 个百分点的"提升"可能只是噪声。报告效应 = 报告仪器的分辨率。 4. 说清楚分母：API 账单、能源估计、延迟，这三个量会给出不同的模式排序。不说明估计量的效率声明是歧义的。
这篇论文的更大意义
这篇论文不只是"路由不行"。它是在给"路由"这个研究方向画边界：
- 最佳情况能买多少（联合上界）
- 可用监督能学多少（供给梗阻）
- 两者在当前 Agent 能力下差多远（ρ=0.952 的耦合）
这和"评测盲区定律"同构——不是路由本身有问题，是"在弱 Agent 区域，我们没有足够的数据来评估和训练路由"。盲区不在路由器，在 Agent 的能力边界。
结语
这篇论文给了一个不舒服但清醒的结论：你不能为一个还不擅长做任务的 Agent 训练路由器。路由是强 Agent 的奢侈品，不是弱 Agent 的救生圈。
对于正在构建 Web Agent 的工程师，最实际的行动是：别折腾路由了，先把你的 Agent 在单一模式上做到最好。等 Agent 够强了，路由的自然监督信号会自己出现。
在那之前，省下的路由器训练成本，不如用来多跑一次重跑——那带来的提升，可能比任何路由策略都大。