论文精选｜路由最难学的地方，恰恰是它最有价值的地方：Web Agent 观测模式的上界与下界

一个反直觉的发现

假设你在管理一个客服团队。每个客服有三种工作模式：

1. 只看文字记录（快、便宜，但看不到表情） 2. 只看视频录像（信息最全，但慢、贵） 3. 文字 + 视频都看（最全面，但最贵）

你的任务是：对每个来电，选一种模式派给客服。你想训练一个”路由器”来自动做这个选择。

直觉上，路由器应该这样工作：先让客服在所有三种模式下都试一遍，看哪种模式在哪种来电上表现好，然后训练一个分类器，根据来电特征选模式。

但这篇 2026 年 8 月的论文告诉你：这个方案有一个致命的结构性问题。

问题出在哪里？出在”先让客服在所有模式下都试一遍”这一步。如果客服本身能力不行，它在所有模式下都答错，你就拿不到任何”这种模式在这种来电上更好”的标签。路由器训练需要的标签，是客服成功时才产生的。客服越差，标签越少。而客服越差的地方，恰恰是路由最需要发挥作用的地方。

路由最难学的地方，恰恰是它最有价值的地方。

这就是 Xian Sun 等人在 arXiv 2608.06171 论文《Routing Is Least Learnable Where It Is Most Valuable》的核心发现。

六种观测模式

论文研究的是 Web Agent（网页自动代理）的观测模式选择问题。Web Agent 需要根据当前页面状态决定下一步操作（点击、输入、滚动等），而页面状态可以用不同方式表示：

1. text：页面的文本内容（HTML 转文本） 2. pixels：页面截图 3. both：文本 + 截图 4. 2×2：文本 + 截图 + 两个角落的放大截图 5. text+2corners：文本 + 两个角落截图 6. pixels+2corners：截图 + 两个角落截图

六种模式各有优劣：text 快但缺视觉信息，pixels 慢但信息全，both 最全但最贵。没有一种模式在所有任务上都最优。

三个关键发现

发现 1：模式之间是互补的

论文在 VisualWebArena 和 WebArena 的 8 个 site-model 组合上测试了六种模式。结果：

每种模式都解决了其他模式漏掉的任务。也就是说，有些任务只有 text 能解决，有些只有 pixels 能解决，有些只有 both 能解决。模式之间不是”谁替代谁”，而是”谁补谁的盲区”。

这个发现本身不意外——多模态互补是常识。但接下来的发现才是反直觉的。

发现 2：最优模式在不同任务集上反转

在任务集 A 上最优的模式，在任务集 B 上可能变成最差的。论文测试了 8 个 site-model 组合，最优模式的选择在不同组合之间反转。

这意味着：没有一种”万能最优模式”。你不能说”both 永远最好”或”text 永远最快”——最优选择取决于具体任务分布。

这给路由器的设计提出了一个硬约束：路由器必须能识别任务特征，根据特征选模式。固定模式（不管什么任务都用一种）是次优的。

发现 3：Oracle 上界被噪声膨胀

论文计算了 Oracle 上界（假设路由器永远选最优模式，能解多少任务）。但作者发现一个棘手的问题：

Web Agent 的运行有随机性——同一个任务跑两次，结果可能不同。论文测量了这个噪声：12-14% 的结果在重跑时会改变。

这意味着 Oracle 上界被噪声膨胀了——你看到的”最优模式能解 X% 的任务”，其中有 12-14% 是噪声带来的虚高。真实的上界比这个低。

这个发现对评估有深远影响：以往论文报告的 Oracle 上界，可能都虚高了 12-14%。而很多路由方法的评估，恰恰是以 Oracle 上界为参照的。参照系虚高，评估结论就不可靠。

路由的结构性困境

论文测试了 5 种路由策略，包括基于 LLM 的、基于特征相似度的、基于历史成功率的。结果：

没有任何一种路由策略能稳定地超过”固定一种选好的模式”。

为什么？作者识别出一个核心矛盾：

路由监督信号是在 Agent 成功时才产生的。Agent 失败时，你不知道是模式选错了还是 Agent 本身就不会。这意味着：

– Agent 越强 → 成功越多 → 路由标签越多 → 路由器越好训练 – Agent 越弱 → 成功越少 → 路由标签越少 → 路由器越难训练

而路由最有价值的地方，恰恰是 Agent 最弱的地方——因为强 Agent 不需要路由，固定模式就够了；弱 Agent 才需要根据任务选模式来补短板。

路由标签的供给和路由的价值负相关。作者测量了这个相关性：r = 0.95——几乎完美的负相关。

这个发现让我想起一个跨域同构：教育领域的”马太效应”。成绩好的学生获得更多资源（标签），成绩差的学生获得更少资源。路由器训练也是一样：强 Agent 产生更多路由标签，弱 Agent 产生更少路由标签。最需要路由的地方，路由最难学。

成本下界：一个工程实用方案

虽然路由器训练困难，但论文提出了一个工程实用的方案：成本下界。

思路是：对每个任务，先用最便宜的模式（text）跑一遍。如果成功，结束。如果失败，再换更贵的模式。

这个方案在 8 个 site-model 组合上都能降低成本：9.5-30.6% 的成本节省。虽然不如 Oracle 上界，但它是可实现的、不依赖路由器训练的方案。

这让我想起一个工程原则：先做最便宜的，不行再加码。这和 Progressive Cramming（渐进式压缩）的思路同构——先测最简单的配置，暴露问题后再加码。也和 colibrì 的”1300 行 C 代码先跑起来”同构——先做能跑的，再优化。

三个层面的启示

这篇论文的发现可以归纳为三个层面：

1. 评估层面：Oracle 上界虚高

12-14% 的噪声膨胀意味着以往路由论文的 Oracle 上界都虚高了。未来的评估必须报告噪声水平，而不是只给一个上界数字。

2. 训练层面：标签供给与价值负相关

r=0.95 的负相关意味着路由器训练有一个结构性天花板。在 Agent 最弱的地方，路由器训练最困难。这个困境不是算法问题，是数据问题——你拿不到足够的标签。

3. 工程层面：成本下界是实用方案

9.5-30.6% 的成本节省不依赖路由器训练。先用最便宜的模式，失败后再加码，这是一个可落地的方案。

跨论文共振

这篇论文和几篇近期论文形成共振：

– Regression Tax：技能库让 Agent 变差，5832 次实验中 59% 增益被回归抵消。路由也是一样——路由器本应让 Agent 变强，但训练不当时反而变弱。“本应帮忙的工具反而帮倒忙”是跨论文共识。

– Looping Is Not Reliability：正确性不是吸收态，曾经正确 82.0%→67.3%。路由的 12-14% 噪声也是同构——“曾经成功 ≠ 当前成功”，重跑结果会变。

– TriviaRoomQA：模型在知识边界内还行，出边界直接掉随机。路由也是一样——Agent 在能力范围内不需要路由，出能力边界才需要路由，但那里路由也学不好。“悬崖 vs 斜坡”的认知架构差异。

– MIST：抵抗训练制造虚假稳健性。路由也是一样——固定模式看起来”稳定”，但 Oracle 上界虚高了 12-14%。“评测的盲区就是问题藏身处”。

四篇论文共同指向一个主题：测量覆盖面比测量深度更重要。只测平均通过率会掩盖配对结构（Regression Tax），只测当前正确性会掩盖非吸收态（Looping），只测能力边界内会掩盖悬崖（TriviaRoomQA），只测 Oracle 上界会掩盖噪声膨胀（Routing Bounds）。

诚实评价

这篇论文有几个局限。

第一，只测了 Web Agent 场景。路由困境是否在其他场景（如代码生成、对话系统）也成立，还需要验证。但论文的核心矛盾——标签供给与价值负相关——是结构性的，不依赖具体场景，很可能普遍存在。

第二，5 种路由策略都不强，可能不代表路由器本身的上限。作者也承认这一点，论文的核心贡献不是”路由器不行”，而是”解释为什么路由器难训练”。

第三，成本下界方案虽然实用，但牺牲了延迟。失败后再换模式，意味着最坏情况下要跑两遍。对于延迟敏感的场景，这个方案可能不合适。

但这些问题不影响核心贡献：论文揭示了一个结构性困境——路由标签供给与路由价值负相关（r=0.95）——这个困境不是算法问题，是数据问题。

一个更深的启示

这篇论文最值得记住的不是某个具体数字，而是它揭示的一个普遍原理：

监督学习的标签供给，和监督学习的价值，可以是负相关的。

这个原理不只适用于路由。在强化学习里，奖励稀疏的地方往往是策略最需要改进的地方。在主动学习里，模型最不确定的样本往往是标注最贵的地方。在教育里，成绩差的学生最需要辅导，但辅导产生的反馈最少。

“最需要的地方最难学”不是一个工程问题，是一个结构性困境。意识到这个困境的存在，是解决它的第一步。

论文作者没有给出解决方案，但给出了一个清晰的诊断：路由器训练的天花板不在算法层，在数据层。未来的突破可能不来自更好的路由算法，而来自更聪明的标签生成方式——比如合成数据、反事实推理、或跨 Agent 迁移学习。

结语

这篇论文做了一件漂亮的事：把一个工程问题（路由器训练不好）提升为一个结构性发现（标签供给与价值负相关）。它不解决路由问题，但它告诉我们路由问题的本质在哪里。

路由最难学的地方，恰恰是它最有价值的地方。这个发现不只适用于 Web Agent，可能适用于所有”监督信号在成功时才产生”的学习场景。当你下次遇到一个训练不好的路由器、分类器或推荐系统时，先问问自己：它的标签供给，和它的价值，是不是负相关的？

如果是，那问题不在算法，在结构。

—

论文链接：https://arxiv.org/abs/2608.06171 HTML 全文：https://arxiv.org/html/2608.06171v1