AI让你自己上网查资料，为什么它总是半途卡壳？

你有没有试过让AI帮你做一件稍微复杂点的网络任务，比如"帮我比较五个电商平台上同款耳机的价格和评论"，然后看着它来回折腾半天,最后给你一个明显漏掉大半信息的答案？

这不是你的提示词写得不好。这是AI访问网络的方式本身出了问题。

2026年初,一群研究者在做一件挺朴素的事:他们想看看现在市面上那些让AI访问网络的方法,到底哪个更靠谱。结果发现一个挺扎心的事实,没有一个真的靠谱。每种方法都像是偏科生,擅长一门课,另一门就直接挂科。这篇论文的名字叫WEB$HELL,它想解决的就是这个"偏科"问题。

AI访问网络,到底卡在哪儿

先说说现状。目前让AI上网干活,大致分成三条路子。

第一条路叫搜索增强型。AI调用搜索引擎,拿到一堆网页的纯文本,然后在这些文字里找答案。这类方法的代表有Search-o1、WebThinker之类的系统。它们的强项是广撒网,搜索很多个网页,快速汇总信息。

第二条路叫浏览器型。AI像人一样"看"网页,通过屏幕上的按钮、输入框、下拉菜单来操作。这类方法要用到一种叫

AXTree(辅助功能树)的技术:它是网页为了方便视障用户使用屏幕阅读器而生成的一套结构化描述,记录了页面上有哪些可点击的按钮、哪些能填写的表单。

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。整个过程里,AI不需要关心背后到底是搜索引擎、浏览器还是文件系统在干活,它面对的永远是同一套请求格式。

实测结果:六个考场,全部拿下相对最高分

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

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

在网页导航类任务里,WebArena-Verified是在模拟的真实网站环境里完成任务(比如给购物车里的商品重新排序),WebWalkerQA是从一个起始网址出发,在同一个网站内部找答案。WEB$HELL在前者拿到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个毫无关系的"干扰网页",看它会不会被这些垃圾信息拖慢。结果显示,WEB$HELL的准确率和花费几乎没有波动,保持得相当稳。

反过来,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：WEB$HELL和之前的搜索型、浏览器型AI方法比,优势在哪？

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

Q3：WEB$HELL为什么在干扰信息多的情况下依然稳定？

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