Jev 加上 Mercury 2.5 用不到 GPT-6 Astra 百分之一的成本，把网页操作基准测试刷到了满分！
花大价钱让最贵的 AI 看屏幕点鼠标，可能从一开始就走错了路！
WebMCP 协议让 Jev 和 Mercury 2.5 组合在网页自动化基准测试中以 112 倍成本优势碾压 GPT-6 Astra 的 Computer Use 方案，核心秘密在于把屏幕像素操作压缩为离散工具调用，准确率从 51% 直接飙到 100%。
最贵的 GPT-6 Astra 被百分之一成本碾压
OpenAI 的 GPT-6 Astra 是目前市面上最贵的旗舰大语言模型，单轮对话的 token 计价能让中小企业望而却步，而 OpenAI 给 GPT-6 Astra 配备的 Computer Use 能力更是把成本推到了天花板：GPT-6 Astra 需要不断截取屏幕画面，把截图送进视觉编码器，识别出按钮坐标，生成鼠标点击指令，再截图确认结果，每一步都在烧钱。
WebMCP 团队在 2025 年公开了一项基准测试结果，直接把这个"贵就是好"的常识砸了个粉碎：Jev 搭配 Mercury 2.5 通过 WebMCP 协议操作浏览器，49 个网页任务全部完成，一个没落下，而 GPT-6 Astra 用代码执行加 Computer Use 的方式跑同一套测试，模型推理成本是 Jev 组合的 112 倍！
更夸张的对比还在后面，GPT-6 Astra 如果切换到纯截图视觉的 Computer Use 模式，不借助代码执行，成本差距直接拉到 245 倍，也就是说 Jev 加 Mercury 2.5 花一块钱能搞定的事，GPT-6 Astra 靠看屏幕得花 245 块钱，而且 GPT-6 Astra 还不一定能全部做对！
让大语言模型看屏幕点按钮到底难在哪
Computer Use 的思路听起来非常直觉：给大语言模型装上一双眼睛，让大语言模型像人类一样盯着屏幕，看到"提交"按钮就点，看到搜索框就打字，看到下拉菜单就选，Anthropic 在 2024 年底率先推出 Claude Computer Use，OpenAI 随后在 GPT-6 Astra 上跟进，整个行业一度认为"让 AI 像人一样操作电脑"是终极方案。
现实却狠狠打脸，一个普通网页的 DOM 结构里可能藏着几千个可交互元素：导航栏里的隐藏菜单、表单里的必填字段、弹窗里的确认按钮、加载中的灰色占位符，大语言模型每做一次截图，都要从这几千个像素区域里找出"下一步该点哪里"，这相当于让一个近视眼在密密麻麻的地铁线路图上找一个你从没去过的站点。
Browser Use 团队开发的开源框架 Ultrafast 尝试用更轻量的方式控制浏览器，WebMCP 团队对 Ultrafast 的测试套件做了可靠性改进后跑了一轮基准，Jev 直接用 Ultrafast 操作浏览器只完成了 49 个任务里的 25 个，刚过一半，剩下的 24 个任务全卡在多级菜单导航、表单错误恢复、任务完成状态判断这些"最后一公里"的环节上，Jev 能找到一个有效的按钮，却选不对真正推进任务的那一步！
WebMCP 把整个网页压缩成一张菜单
WebMCP 的全称是 Web Model Context Protocol，脱胎于 Anthropic 在 2024 年底发布的 MCP 开放协议，MCP 的原始设计是让大语言模型通过标准化接口调用外部数据源和函数，WebMCP 把这套思路搬到了网页场景：网站主动把自己的核心功能封装成一个个命名明确的工具接口，比如 search_products、add_to_cart、checkout，然后通过 WebMCP 协议暴露给外部调用方。
这意味着 Jev 面对的不再是一张布满几千个像素点的截图，而是一份干干净净的工具清单：搜索商品、加入购物车、结算、查看订单，每个工具的名字就是动作本身，Jev 只需要从这份清单里挑一个最符合当前任务目标的选项，不用猜坐标，不用认按钮颜色，不用管那个按钮藏在第三层下拉菜单的哪个角落。
从语言哲学的角度看，WebMCP 做了一件极其精妙的事情：维特根斯坦在《哲学研究》里反复论证"意义即用法"，一个词语的意义不在于词语本身长什么样，而在于词语在具体语言游戏里承担的功能，WebMCP 恰好把网页上那些视觉层面的"能指"（按钮颜色、图标形状、文字排版）全部剥离，只保留了功能层面的"所指"（搜索、购买、提交），Jev 拿到的每一个选项都是一个纯粹的功能符号，歧义空间被压缩到了极限！
Jev 负责选动作 Mercury 负责填参数
Typesafe AI 开发的 Jev 有一个非常独特的设计约束：Jev 只能从给定的离散选项里做选择，不能凭空生成任意文本，这个限制乍一看是缺陷，放到 WebMCP 场景里却变成了巨大优势，因为 WebMCP 提供的工具清单本身就是离散的，Jev 的能力边界和 WebMCP 的接口形态严丝合缝地咬合在了一起。
但工具调用需要参数，选了 search_products 还得告诉系统搜什么关键词，选了 fill_address 还得填具体地址，Jev 生成不了这些自由文本，WebMCP 团队的解法极其简洁：把"选动作"和"填参数"拆成两步，Jev 只负责从工具清单里挑出正确的那一个，参数生成丢给 Mercury 2.5，Mercury 2.5 是一个推理速度超过每秒 1000 个 token 的超轻量语言模型，生成一句搜索关键词对 Mercury 2.5 来说连热身都算不上。
这个分工架构背后的认知科学逻辑非常清晰：网页操作任务里真正的难点是"下一步该干什么"，是在十几个可能的动作里判断哪一个能推进任务，这个决策消耗了绝大部分推理资源，而一旦动作确定了，填个搜索词、写个地址这种参数生成几乎是体力活，WebMCP 团队用最贵的推理预算买最关键的决策，用最便宜的算力填最简单的参数，总成本直接砍掉了两个数量级！
选项越少大语言模型反而越聪明
索绪尔在《普通语言学教程》里提出一个核心观点：语言符号的价值不取决于符号自身的正面内容，而取决于符号与系统中其他符号的差异关系，一个词之所以有意义，是因为这个词不是系统里的其他词，WebMCP 的工具清单恰好构成了一个极度精简的符号系统：当 Jev 面前只有 search_products、add_to_cart、checkout 三个选项时，每个选项的"差异价值"被最大化，选错的概率被最小化。
反观 Computer Use 的截图方案，GPT-6 Astra 面对的"符号系统"是整个屏幕上的几万个像素区域，每个像素区域和相邻区域之间的差异微乎其微，一个蓝色按钮和旁边的蓝色链接在视觉特征上几乎无法区分，GPT-6 Astra 必须额外消耗大量推理步骤去理解页面布局、猜测元素层级、预判点击后果，推理链条越长，每一步累积的误差就越大，最终结果就是 GPT-6 Astra 花了 245 倍的钱，准确率还未必比 Jev 高。
WebMCP 本质上做了一次"语言游戏"的降维：把原本需要在视觉空间里完成的复杂导航游戏，转换成了在语义空间里完成的简单选择游戏，Jev 不需要理解 HTML 结构，不需要识别 CSS 样式，不需要处理 JavaScript 动态渲染，Jev 只需要读懂工具名称的语义，然后做一个单选题，这就是为什么 49 个任务 Jev 能全部拿下，一个不剩！
25 分和 49 分之间隔着一层协议
WebMCP 团队做的最关键的对比实验，是同一个 Jev 在同一套基准测试上，分别用 Browser Use Ultrafast 直接操作浏览器和通过 WebMCP 协议操作浏览器，硬件环境完全相同，任务列表完全相同，唯一的变量就是 Jev 和网页之间有没有 WebMCP 这层协议。
结果差距触目惊心：Browser Use Ultrafast 模式下 Jev 完成 25 个任务，WebMCP 模式下 Jev 完成 49 个任务，准确率从 51% 直接翻倍到 100%，而且 WebMCP 模式下的模型推理成本反而比 Ultrafast 模式低了 18%，因为 Jev 在 WebMCP 模式下不需要反复截图、反复解析 DOM、反复尝试错误路径，每一步都是一次干净利落的工具调用，步数少了，token 消耗自然下降。
WebMCP 团队在实验报告里特别强调了一个细节：Ultrafast 模式下 Jev 失败的 24 个任务，绝大多数不是败在"找不到按钮"，而是败在"找对了按钮却选错了时机"，比如表单还没加载完就点了提交，或者弹窗还没关闭就点了下一步，WebMCP 把这些时序问题全部内聚到了工具层，网站自己负责判断"现在能不能结算"，Jev 只需要决定"要不要结算"，时序判断的复杂性从 Jev 的肩上卸下来，转嫁给了网站自身的业务逻辑！
WebMCP 团队公开了完整的基准测试代码和评估日志，Browser Use Ultrafast 的 25 分成绩仅代表当前测试套件和特定实现下的表现，WebMCP 团队明确表示欢迎社区提交 Pull Request 优化 Ultrafast 的 Harness 配置，如果有人在更优的浏览器控制框架上跑出更高的基线分数，49 分和 25 分之间的差距可能会缩小，但 WebMCP 协议层带来的决策空间压缩效应，在数学结构上几乎不可能被纯视觉方案追平，因为几千个像素点和十几个工具名称之间的信息熵差距，不是靠更好的截图算法就能抹掉的！