先弄清网站有哪些功能
能拿到源码时,我们先看代码和网站功能,确认能查什么、能改什么、什么结果才算正确。拿不到源码时,就要另外检查能覆盖哪些任务。
比较成功率、Token 用量和完成任务的时间。
我们先确认任务的正确答案,再用 WebMCP 尝试以较少步骤完成任务。把你的 Computer Use Agent 与它比较:是否答对、多做了哪些操作、多用了多少 token 和时间。
面向 Agent 与模型团队 · 比较不同版本的实际表现
SAME SUCCESS. DIFFERENT COST.
65 本书 → 最低价三本
更少 token
更少耗时
WebMCP 相对 CU · token 与耗时均为五轮中位数;实测参考,不是理论极限。
先确认哪些任务已经可以完成
统计完成任务一共用了多少 token
检查是否完成,再比较用了多久
WHY WEBMCP
例如,任务是找出网站上最便宜的三本书。CU 通常需要浏览页面、找到翻页入口,再读取价格。我们可以用 WebMCP 提供查书和读价格的工具,让模型直接获取所需信息。然后比较:两种方式是否都答对,各花了多少 token 和时间。
能拿到源码时,我们先看代码和网站功能,确认能查什么、能改什么、什么结果才算正确。拿不到源码时,就要另外检查能覆盖哪些任务。
用 WebMCP 列出可调用的功能,说明要填什么、会返回什么。模型可以直接选择功能,不必每次都从页面上找按钮。
每多看一次页面、多尝试一次操作,都可能增加 token 和等待时间。直接调用功能可以减少这些步骤。能省多少,要实际运行后比较。
只要任务所需的信息和操作都能用文字与工具提供,支持工具调用的文本模型就能尝试完成任务。这样可以测出:不需要找按钮、识别截图时,任务要花多少 token 和时间。
这让我们能回答一个具体问题:模型已经知道有哪些功能、怎么调用时,完成任务需要多少资源?再拿这个结果与 CU 比较,就能看到多花的时间和 token。
这些工具需要我们根据网站功能构建并检查。WebMCP 不会自动读懂全部源码,也不保证一定找到最短步骤。 查看 WebMCP 说明 ↗
GROUND TRUTH + REFERENCE EXECUTION
评测要分清两件事。第一,什么结果算正确,也就是 ground truth。第二,一种已验证的完成方法,需要多少步骤、token 和时间。只比较速度,可能把没做完的任务误认为更快。
例如,三本书是否选对、价格是否正确、有没有按要求排序。每一项都检查,不能只凭答案看起来像是对的。
交付:正确结果和检查规则记录 WebMCP 是否完成任务、用了多少 token、从开始到结束花了多久。再与 CU 的结果比较。
交付:完成情况、Token 和耗时WebMCP 成功完成任务,说明这个任务在当时的条件下做得到。它用了多少资源,是一个实际比较值,不代表其他方法不可能做得更快或更省。
SUCCESS × TOKENS × TIME
切换三组已完成实验,比较完整成功率、总 token 和耗时。既看是否完成,也看执行代价;完成量不同的运行,单独解释。
成功轮次 / 总轮次
总 token · 每轮中位数
秒 · 每轮中位数
两组均 5/5 成功。WebMCP 每轮 token 中位数低 52.0%,耗时中位数低 36.2%。这组结果展示了成功率之外,仍可测量的效率差距。
任务:遍历四页、65 本书,找出最低价三本。这里是五轮实测中位数的比较,不是理论最小消耗。已完成实验,非在线评测演示。总 token 是运行记录中的累计用量,包含重复上下文;不等于输出长度或账单金额。三组实验分别展示,不合并成功率。
下载对比数据 ↓ONE TASK. TWO EXECUTION PATHS.
先约定网页数据、任务要求和运行限制。WebMCP 用工具完成任务,CU 用约定的页面操作方式完成任务。最后单独检查两组答案,并统计 token 和耗时。
功能列表 → 文本模型调用 → 单独检查答案
Ground truth · Token · 耗时截图 / 无障碍树等约定能力 → UI 操作 → 结果
完成度 · Token · 耗时参考答案和裁判接口不向被测 CU Agent 开放。使用工具的参考组与 CU 组分别记录能力条件。
成功率与 token、耗时共同报告。模型、预算、环境版本和重试规则纳入协议,失败运行保留其实际消耗。
用已知正确、错误和部分完成的状态验证校验器。环境异常与 Agent 失败分别记录。
COMPLETION BEFORE EFFICIENCY
HN 的一次 CU 运行,100 条正文正确,只有 25 条回复关系得到确认。ground truth 要核对的是完整交付,才能让后续的资源比较有意义。
已核验正确未确认
这一项未通过。75 条关系未确认,因此本轮完整任务未通过。
数据来自已完成的 HN 实验,原结果经独立页面核验。此交互展示评分方式,不会启动 Agent;WebMCP 裁判流程属于下方的试点设计。
下载样例数据 ↓YOUR EVALUATION PACKAGE
为 Agent 团队、模型团队和企业自动化团队构建任务集。用同一套标准比较版本,判断能力是否进步,以及进步需要多少额外资源。
网站能力地图、任务快照、目标字段、业务规则与经过验证的结果校验器。
经过验证的短路径、文本模型运行条件、逐轮完成度、token 与耗时;注明建图与初始化成本。
成功率、资源差距、失败消耗与逐任务证据,支持版本对比。
按约定预算重复评测,观察成功率与资源用量的变化,记录环境和版本。
当前为浏览器任务试点。任务范围、参考执行可行性、交付格式、维护期限与报价按需求确认。
READ THE METRICS CORRECTLY
不一定。知道有哪些功能、怎么调用,通常能减少找按钮和试错。我们会记录实际找到并验证过的做法,但不把它说成唯一或最优的做法。步骤最少,也不一定最省 token 或最快。
如果所需信息能用文字返回,操作能通过工具完成,模型就不必看懂截图。它仍需要理解任务、选择功能和检查答案。需要判断图片内容的任务,要用另外的评分方法。
能提供一个实际比较对象。WebMCP 做完而 CU 没做完,说明当时存在一种可行做法。两组都做完,就可以比较步骤、token 和耗时。差距可能来自可用信息、工具、规划或页面操作,不能全部算作视觉能力的差距。
就是判断答案对不对的依据。例如,应该选中哪三本书、价格是多少、是否按要求排序。我们会另外核对这些答案,不会因为工具返回了一个结果,就直接认定它正确。
Token 是模型处理内容的计量单位,用来统计模型用了多少输入和输出。这里展示每轮累计用量,包含重复发送的内容。它不直接等于费用:模型价格、缓存和计费方式也会影响账单。
尽量使用同一份网页数据、相同账户权限和任务要求,并记录模型、工具、重试次数等条件。准备工具和整理网站功能花了多少资源,也要单独记录。没做完的任务不能当成更快完成;网页或任务量不同时,也不能直接比较快了几倍。
我们会通过你填写的邮箱联系你,确认要测哪些任务、比较哪些版本、交付什么结果,以及价格和时间。提交申请不会扣费,也不会自动开通服务。
BENCHMARK AGAINST WHAT’S POSSIBLE
填写目标任务、要比较的版本,以及你希望提高成功率、减少 token,还是缩短耗时。我们会与你确认评测内容。