10 月 9 日提交 arXiv 的 Web$hell（编号 2610.13416，延世大学团队）处理的是一块被长期低估的地基：智能体到底怎么上网。论文把现有路线分成三派——搜索增强式拿得回信息但丢交互控件，浏览器式交互完整但把整页塞进上下文，文件系统式能选择性阅读却在 grep 时丢掉交互语境。长程任务里，广撒网、能交互、可复访三件事常常发生在同一条轨迹上，单派路线天然瘸腿。
直观的解法是「混着用」，论文的预分析先把这笔账算了出来：搜索加浏览器的混合方案，在 WideSearch 上输入 token 多花 290%、每百次调用成本多花 272%；在 WebArena-Verified 上 token 多花 626%。原因是同一页面被两套表示（清洗文本与可访问性树）各解释一遍，还得互相交叉验证。
三件套：一套 schema、一次确定性编译、一份持久缓存
Web$hell 的方案可以拆成三块。WebContract 定义三套 schema：对象模式把网页里的信息与控件都表示成「地址 + 值 + 关联」的可寻址对象；页面模式统一文件结构，文本按标题层级分节，还附一份目录文件；操作模式规范八种请求-响应操作，从 retrieve、grep 到 execute、focus。
WebCompiler 做确定性编译：按 HTML 语义规则把实时网页编译成信息对象与动作对象，不调模型推理，每页 0.46 到 2.79 秒。它保留解释所需的上下文——比如「衣物尺码」这个 label 与那个下拉菜单的绑定关系。WebCache 管持久与有状态：搜索页预取编译后缓存，404 与验证码提前报告；动作在真实页面执行后，页面改版就编译新状态、分配新地址，而旧状态保持只读——智能体因此能回溯页面历史、审查自己走过的每一步。
六个基准全部占优，但绝对分提醒别乐观
在主实验（gpt-5.6-luna 高推理档，搜索走 Serper，排除含答案的页面）里，Web$hell 在全部六个基准上取得最高成绩：WideSearch 的 item F1 0.782、SealQA 0.720、WebArena-Verified 成功率 0.679、WebWalkerQA 0.671、DeepResearchBench 的 RACE 0.534、DeepWeb-Bench 31.11，对比各路线的更优基线均有提升，网页导航类提升最明显。
效率侧同样好看：深度研究任务平均 17.6 轮收尾，较表现更好的基线少 43.0%，较 CLI 路线代表少 66.4%；而推理成本与文件系统式基本持平（每任务约 0.096 美元对 0.097 美元）——缓存输入占比更高，但缓存按一折计价，总账没涨。消融实验佐证了核心设计：去掉「信息对象到动作对象的引用」，两个导航基准性能一致下滑、成本上升；注入 50 到 400 个干扰页面时，Web$hell 的准确率与成本基本稳定，而文件系统式成本翻倍以上。
怀疑与边界
论文自标 work in progress，几条边界要立清楚：评测只用了一个主干模型，换骨干是否成立待验；搜索依赖 Serper 单一 API；为防泄漏排除了一批含答案的站点，这改变了任务分布；预取参数 k 取 10 时，仍有 9.5% 的金标信息没被智能体观察到——「读得省」与「读得全」之间的张力没有消失，只是被推到了可调的旋钮上。最该盯的其实是 DeepWeb-Bench 的绝对分：31.11 分（满分 100）说明跨源定量分析离解决还远，路线占优不等于任务完成。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。但对自建网页工具的团队，这篇论文的启发不只在方案本身：当智能体开始以「任务轮数」计费，接口层每一次重复解释，都是在给用户的账单添行。