正在加载视频...
视频章节
Jerry Wu 和 Wyatt Marshall 系统梳理了浏览器代理的真实能力边界:读网页已接近可用,写网页却仍是硬骨头。他们用一个5000任务的真实基准,揭示了性能、失败模式和基础设施为何才是决定性因素。
浏览器代理现状:为什么“会点网页”比你想象的难
Jerry Wu 和 Wyatt Marshall 系统梳理了浏览器代理的真实能力边界:读网页已接近可用,写网页却仍是硬骨头。他们用一个5000任务的真实基准,揭示了性能、失败模式和基础设施为何才是决定性因素。
从“能自动下单”说起:什么才算浏览器代理
在这场演讲的一开始,Jerry Wu 先抛出了一个非常具体、也很直观的定义:“浏览器代理,本质上就是任何能够控制浏览器、代替用户完成网页任务的 AI。”这不是一个抽象概念,而是已经可以跑起来的系统。现场展示的 GIF 中,一个代理从进入厂商官网、搜索商品、加入购物车到完成结账,全程无人干预。
Jerry 特别强调,这类技术“只是在最近一年才真正变得可行”。背后的原因并不神秘:大语言模型能力的跃迁,加上推理、执行和浏览器自动化基础设施的成熟,才让这件事从研究玩具变成工程问题。也正因为如此,今天讨论浏览器代理,已经不再是‘能不能’,而是‘好不好、值不值得用’。
这一定义也悄悄划清了边界:浏览器代理不是聊天机器人,不是插件脚本,而是一个能在真实网页环境中观察、决策、行动的系统。这一点,直接决定了后续所有性能评估的难度。
浏览器代理的“三步循环”:看、想、点
要理解为什么浏览器代理这么难做,Wyatt 和 Jerry 花了不少时间拆解它的底层工作方式。他们把绝大多数浏览器代理抽象为一个三步循环:观察(Observe)、推理(Reason)、行动(Act)。
首先是观察阶段。代理需要理解当前浏览器状态,这通常有两种路径:一种是截图交给视觉语言模型(VLM),另一种是直接解析 HTML 和 DOM 结构,走偏文本的路线。前者更通用,后者更稳定,但都各有代价。
接下来是推理阶段:模型需要根据用户目标,判断“下一步该做什么”。Jerry 举了个很接地气的例子——如果目标是购买电动工具,合理的下一步可能只是“点击搜索框”。最后进入行动阶段,代理会执行点击、滚动、输入文本等原子操作,然后页面状态发生变化,循环重新开始。
这个循环听起来简单,却暗藏陷阱。只要其中一步理解错了页面,后续所有动作都会偏离目标。这也是为什么浏览器代理远比写 API 调用要难。
读网页已接近可用,写网页却集体翻车
真正让这场演讲变得有分量的,是他们刚刚发布的 WebBench 基准测试。Wyatt 介绍说,这个数据集包含了 5000 多个真实任务,覆盖近 500 个网站,既有只读任务,也有需要实际操作页面的写任务,其中约一半已经开源。
结果非常耐人寻味。在只读任务上,行业领先的浏览器代理表现“好得出乎意料”。以 OpenAI Operator(带人工监督)作为基线,成功率约 80%,而最强的全自动代理已经逼近这一水平。Wyatt 直言:“这对信息检索和数据提取来说是个好消息。”
但一到写任务,情况急转直下。整体成功率直接下降 50% 甚至更多,而 Operator 只下降了约 10%。这意味着,人类在环的价值,在复杂交互中被无限放大。正如他们总结的:代理很擅长‘看’,但一旦需要‘动手改东西’,失败概率就急剧上升。
更反直觉的是,那些失败案例中,相当一部分并不是模型不聪明,而是被基础设施拖了后腿。
真正的瓶颈:基础设施与“慢到不能用”的延迟
在失败模式分析中,Wyatt 给出了一个让很多工程师共鸣的结论:如果基础设施能更稳定,代理性能会有“巨大提升”。网络抖动、页面加载失败、弹窗变化,这些在人工操作中可以被直觉化解的问题,对代理却是致命的。
而最大的共性问题,是速度。“可能是目前代理最大的通病,”Wyatt 直言,“它们真的非常非常慢。”在 WebBench 的统计中,完成一个任务往往需要几十秒甚至更久。这意味着,只要场景是实时交互,体验几乎不可接受。
也正因为此,他们在结尾给 AI 工程师的建议非常务实:真正有价值的,不只是更强的模型,而是那些能让代理稳定、快速地执行点击、输入、滚动等原子动作的工具和系统。谁能把这些基础能力做好,谁就能释放浏览器代理的巨大潜力。
总结
这场演讲的价值,不在于展示了多炫的 Demo,而在于冷静地划清了浏览器代理的能力边界:读网页,已经接近工程可用;写网页,仍然高度依赖人类和基础设施。对 AI 工程师而言,机会不只在模型层,更在那些看似“脏活累活”的执行与环境构建中。浏览器代理的未来,很可能由这些细节决定。
关键词: 浏览器代理, AI Agent, WebBench, 视觉语言模型, 大语言模型
事实核查备注: 演讲者:Jerry Wu、Wyatt Marshall;公司:Illuminate;基准:WebBench;任务数量:5000+;网站数量:约500;只读任务成功率:约80%;对比基线:OpenAI Operator(有人类监督);核心问题:写任务性能下降约50%、高延迟、基础设施不稳定。