AI上网查资料总卡壳：三种路线各有短板，混搭成本涨272%

让AI代劳一件稍复杂的联网活儿，比如“比一比五个电商平台上同一款耳机的价格和评价”，结果它折腾半天，交回来的答案明显缺了一大半——这种体验你遇到过吗？

问题不在提示词写得糙，出在AI连网干活的方式本身。

2026年初，有批研究者做了件很实在的事：盘一盘眼下各种让AI上网的办法，究竟哪个更靠得住。结论挺扎心——没一个真靠得住。每种办法都像偏科生，一门课拔尖，另一门直接不及格。论文题为WEB$HELL，要对付的就是这个偏科毛病。

AI连网，究竟堵在哪一步

先看现状。眼下让AI上网干活，大体分三条道。

头一条叫搜索增强型。AI去调搜索引擎，拿回一堆网页的纯文本，再从这些文字里刨答案。Search-o1、WebThinker这类系统是代表。它们的长处是铺得开，能搜很多网页，信息汇总得快。

第二条叫浏览器型。AI跟人一样“看”网页，靠屏幕上的按钮、输入框、下拉菜单去操作。这条路要用上一门叫

AXTree（辅助功能树）的技术：网页为了帮视障用户用屏幕阅读器，会生成一套结构化描述，页面上哪些按钮能点、哪些表单能填，都记在里面。

借着这棵树的structure，AI能判断“这儿有个按钮，点下去会提交订单”。AgentOccam、BrowserUse是这类做法的代表，碰上要跟网页“动手”的任务（改购物车数量、翻页看评论之类），它们干得不错。

第三条路出现得最晚，叫文件系统型。思路是把抓下来的网页存成文件，再用程序员常使的

grep（一条在文本里按关键词快速查内容的命令）去翻找要的信息，而不是把整页网页塞给AI硬读。代表是Fetch-then-Explore。

三条路各干各的，谁也没把另外两条的长处学过来。研究者做了个实验，看这事到底有多严重。他们让“擅长浏览器操作”的AI去做“要广泛搜集信息”的任务（WideSearch测试集），再让“擅长搜索”的AI去做“要深度操作网页”的任务（WebArena-Verified测试集），两边分数都明显往下掉。

信息搜集任务上，浏览器型AI平均只拿到33.6%上下，搜索型AI同一任务平均65.8%，差了将近一倍。掉个个儿，搜索型AI做网页操作任务，平均成功率25.8%，浏览器型AI能到54.7%。

好比让砍价高手去修电脑，再让修电脑的行家去菜市场砍价。两边的活儿都接不住，不是人笨，是那套本事压根没学过。

那把两种办法硬拼起来不就得了？研究者也试了，结果更耐人寻味。

硬拼到一起，成本立刻失控

研究者搭了个“混合型”AI，纯文本和AXTree两种观察方式一起给，再加上浏览器操作权限，取名

HybridSB（Search + Browser的缩写，意思是“搜索加浏览器”的混合配置）。

混合型确实两边都过了关：WideSearch上66.0%，WebArena-Verified上74.0%，单一路线都比不过。可代价呢？喂给AI的文字量猛增290%，调大模型的费用涨了272%。

为什么会这样？研究者看到，这个混合AI会拿两种方式反复查同一个网页。纯文本里找不到的，它换AXTree去找；找到之后，又回头用纯文本核一遍全不全。两种表示互不信任，只能来回核对，核对次数越多，钱烧得越凶。

这就像同时雇了两个助理整理同一份资料，一个只读文字版，一个只看扫描图。你每问一句，两人就得互相对一遍有没有漏看，核对的工夫比干活还费时间。要是一开始就让两人用同一套系统记笔记，这种重复核对根本不会发生。

那再把文件系统的

grep功能加进去试试？研究者又搭了个更复杂的版本HybridSBF（在前面的基础上加了文件系统）。这一回WideSearch任务上的成本降下来了，效果还更好——这类任务本来就是“从许多来源里各挑一点关键信息”，用grep精准查找正好对路。

可到了WebArena-Verified的网页操作任务上，这个版本反倒退步了。原因在于grep只返回匹配上的那一小段文字，看不到这段文字周围的网页结构。比如AI搜到“设置状态”几个字，grep不会告诉它旁边有个按钮能点开状态设置框。结果AI知道有这么个功能，却摸不到入口，只能在页面里反复试，直到允许的操作次数用光。

打个比方，你托人去图书馆查某本书里一句话的出处。他确实翻到了那句话所在的那一页，可你没告诉他，那本书就摆在他面前的书架上。他根本没想过伸手把书抽下来接着翻。信息是找到了，通向下一步动作的那根线却断了。

三个实验跑完，研究者提炼出三条设计原则，这也是整篇论文的核心逻辑起点。第一条是操作性（operability）：系统既得能快速扫一堆网页找信息，也得让AI真正动手操作页面上的控件，两头都不能偏。第二条是一致性（consistency）：网页上的文字内容也好，按钮、表单这类操作对象也好，都得用同一套规则来表示，别让AI在两种“语言”之间来回翻译。第三条是持久性（persistence）：抓过的网页要留着，后面随时能回头查，而不是每次重新抓一遍。

第一条叫

第二条叫

第三条叫

WEB$HELL给出的答案，是给AI配一套统一的“网页语言”

问题想清楚之后，研究者拿出了WEB$HELL。思路说起来并不复杂：别让AI在“读文字”和“点按钮”两种模式之间切换，而是把网页上的一切——一段文字、一张表格、一个按钮——统统翻译成同一种标准格式的“对象”，AI只要学会操作这一种对象就行。这套标准格式叫WEBCONTRACT（网页契约），它规定每个对象必须带三个要素：地址，即agent用来精确指认这个对象的编号；价值，即这个对象到底是什么内容、能做什么动作；关联，即帮助理解它含义的上下文，以及它与其他对象的联系。

论文里有个例子。一个卖衣服的网站，页面上有张尺码选择表格，“中号”那一格本身只是个单元格。WEB$HELL会把它编译成两个相互关联的对象：一个信息对象告诉AI“这一格的值是中号”，同时标注“它属于尺码这一列”；另一个动作对象告诉AI“点这里就能选中中号”，并在关联字段里直接写明这个动作对应的地址。AI看到“中号”的同时，立刻知道该去哪里点，不用再猜。

把网页翻译成这种标准对象的工具叫WEBCOMPILER（网页编译器）。它不靠AI模型去“猜”网页结构，而是用一套从HTML（网页的底层标记语言）语义里提炼出来的固定规则直接转换，不必额外调用大模型理解页面。速度快，结果也稳定、可复现。

编译出来的网页对象，全部存放在WEBCACHE（网页缓存）里。它不是用完就丢的临时记忆，而是持续保留，AI随时可以回头翻查；网页状态变了之后，还能看到之前的旧状态。

又像去图书馆查资料：每翻一页都得把书还回去再重新借出来，效率能高到哪去。WEB$HELL的做法相当于，你借出来的书一直摊在桌上，随手就能翻到任何一页；哪怕这本书后来被人改版，桌上这本旧版还在，可以继续对照着看。

三个部件搭在一起，AI和WEB$HELL之间就形成了一种“请求—响应”的对话循环。AI提一个请求，比如“查一下某个关键词”（grep），或者“执行某个按钮点击”（execute），接口负责到真实网页上把事办成，再把结果连同新的地址一起返回。整个过程中，AI不用管背后干活的是搜索引擎、浏览器还是文件系统，它面对的永远是同一套请求格式。

设计理念说了半天，实际效果如何？研究者在六个测试集上做了对比，覆盖网页搜索、网页导航、深度研究三大类任务。

网页搜索类任务里，WideSearch考的是从大量网页收集信息填成表格，SealQA考的是在互相矛盾、信息不全的搜索结果里找出正确答案。WEB$HELL两项都超过了此前表现最好的Fetch-then-Explore：前者从74.5%提升到78.2%，后者从66.5%提升到72.0%。

网页导航类任务里，WebArena-Verified是在模拟的真实网站环境中完成任务，比如给购物车里的商品重新排序；WebWalkerQA则是从一个起始网址出发，在同一个网站内部找答案。WEB$HELL在WebArena-Verified上拿到67.9%的成功率，是所有对比方法中最高的，比排第二的HybridSBF高出整整10个百分点。

深度研究类任务要求AI综合多个来源的证据，写成报告或做定量分析。在考验跨来源证据整合能力的DeepWeb-Bench上，WEB$HELL明显拉开差距，从28.37分（HybridSBF的成绩）提升到31.11分。

成本更出人意料。按理说做得更好该花得更多，WEB$HELL偏偏不是。深度研究任务上，开源的浏览器操作工具CLI-Anything Browser平均要52.4轮对话才能完成，WEB$HELL只要17.6轮，少了将近三分之二。花费方面，HybridSBF平均每个任务0.111美元，WEB$HELL只要0.096美元——表现更好，还更省钱。

这种“又好又便宜”，靠的就是前面那套统一对象系统。信息全按同一标准组织，AI不必再一边读文字一边猜“这段话对应的操作入口在哪”，直接顺着对象之间的关联跳转，来回试错的轮次因此少了很多。

往下挖一层，那些关联字段究竟值多少钱？

研究者做了一个很直白的对照实验，要验证的就是“信息对象跟动作对象互相挂钩”这件事本身管不管用。

做法是把WEB$HELL里信息对象指向相关动作的那条“关联引用”直接拆掉，逼AI每次都单独去查一份完整的操作列表，才能找到能点的按钮。结果在WebWalkerQA上，准确率从67%掉到56.9%，少了10.1个百分点；在WebArena-Verified上，成功率从71%掉到65%，少了6个百分点。同时，AI得多花好几轮去反复翻操作列表，成本反倒涨了3.6%到21.9%。

实验说明的道理很朴素：信息和操作放在一起看，比拆成两张表高效得多。好比用手机地图找餐厅，地图要是在店名旁边直接给出“导航”“打电话”“查看菜单”几个按钮，一步就能动手；可要是非得先退出地图，再打开另一个App查这家店的电话，查完还得切回地图去导航，中间多出来的那几次切换，时间和注意力就这么白扔了。

另有一组实验也挺有意思，测的是

噪音容忍度。研究者往WEB$HELL的缓存里故意塞了50到400个毫不相干的“干扰网页”，看它会不会被这些垃圾拖慢。结果准确率和花费几乎没什么起伏，稳得住。

反过来看，Fetch-then-Explore的花费随着干扰页面变多翻了一倍多，HybridSBF的花费也一路往上走。研究者找出的原因是：这两个方法在页面变多以后，常常要先列出整个文件夹看看里面有哪些文件，文件越多清单越长，AI要读的内容也跟着涨。WEB$HELL不一样，每个网页、每个具体对象分到的都是短小的固定地址，AI不用“翻目录”，拿着地址直接查就行，地址也不会因为仓库变大而变长。

这就像管一个仓库：每次找货都得先把整仓货架清单打印出来再翻，货堆得越多，这张清单就越长越难翻；可要是每件货入库时就贴好固定货号，不管仓里堆了多少东西，凭货号直接走到对应的架子前就成，查找难度不会随库存增加而增加。

写在后面

这篇论文让我意识到一件以前没细想过的事：我们总以为给AI“喂”更多信息和能力就是进步，可WEB$HELL的实验恰恰说明，把几种能力简单堆在一起，反而会造出大量重复劳动。那个“混合型AI成本暴涨272%”的数字背后，教训是系统设计不能做加法，得先把“几种能力之间怎么互相理解”解决掉，否则堆砌只会带来内耗。

还有个细节值得单独拎出来说：论文里提到一个网页字段存了176万多个字符，这才是真实互联网的样子，比我们想象中“规整”的网页复杂得多。WEB$HELL专门做了把超长内容单独存起来、按需分段读取的机制，这种“遇到极端情况也不崩”的工程细节，往往比论文摘要里那些漂亮的性能提升数字更能说明一个系统有没有经过实战打磨。

以后你的AI助手要是真能替你去各个网站比价、填表、查资料，它背后大概率不需要一颗更聪明的大脑，而需要这样一套帮它看懂整个网络世界“说话方式”的翻译系统。问题留在这儿：当AI访问网络的方式足够统一、足够高效之后，下一个瓶颈会出现在哪里？

Q&A

Q1：WEB$HELL是什么？

A：WEB$HELL是一套让AI统一访问网络的接口系统，它把网页上的信息和可操作按钮都转成标准化的“对象”，AI只要学会一套操作方式，就能同时完成网页搜索、网页操作和深度研究类任务，而且比现有方法更省钱更高效。

Q2：跟之前的搜索型、浏览器型AI方法相比，WEB$HELL的优势在哪？

A：之前的方法各有短板，搜索型AI不擅长点网页按钮，浏览器型AI在大量搜集信息时效率低。两种硬凑到一块，成本会暴涨272%。WEB$HELL靠统一的对象系统避开了这种重复劳动，在六个测试集上都拿到相对最高的表现，成本还更低。

Q3：干扰信息一多，WEB$HELL为什么还是稳？

A：它给每个网页和每个具体内容对象都分配了固定简短的地址，AI拿着地址直接查，不用像别的方法那样翻整个文件清单。文件越多清单越长，可地址的查找难度不会随内容堆积而增加。