三个 Agent 成功率都是 32%，但它们的"翻车方式"完全不一样——这篇论文教你看清"哪里出错了"
你有没有遇到过这种情况：跑了两个 Web Agent，benchmark 一拉，成功率都是 32% 左右，几乎打平。你松了口气，觉得"差不多嘛"。
但如果我告诉你，这两个"打平"的 Agent，一个是根本找不到正确的东西，另一个是找到了却点错了按钮呢？
这两种失败，在工程上的修法天差地别。前者要补探索能力，后者要补执行精度。可在传统 benchmark 里，它们都被压成同一个数字：失败。你拿着这个数字，根本不知道该往哪儿使劲。
这就是这篇来自延世大学和 Microsoft Research 的论文想戳破的问题。它叫 WebStep，arXiv ID 是 2606.15673。核心主张特别朴素：别只看终点了，得看过程。
核心摘要
Web Agent 干活是一长串交互——搜索、翻页、点详情、提交。但现在几乎所有 benchmark 只评一件事：最后做对了没有（terminal success）。整个轨迹被压成一个二元结果，过程信息全扔了。结果就是，成功率相近的 Agent 看起来"实力相当"，但它们的失败方式可能南辕北辙，而你完全看不出来。
WebStep 的解法很聪明：给每个网站配一个语义 MDP 对偶（semantic MDP dual）。Agent 还是只跟渲染出来的 GUI 打交道，但后台有一个确定性的状态机在默默记录每一步的高层语义状态和转移——因为 GUI 本来就是从这个语义模型渲染出来的，所以整条语义轨迹能精确还原，不需要任何人工标注。
基于这个轨迹，论文把"成功率"拆成了探索成功率、执行成功率、技能调用模式、轨迹分叉点等一系列过程指标。最扎眼的一个发现：三个小模型的 terminal SR 全都挤在 31–33%，但拆开看，UI-TARS 探索更强执行更弱，Fara 则探索都懒得探索。再比如在 Housing 网站上，OpenAI CUA 在"提交"动作上比 Qwen3.5 高 23.7 个点，却在"过滤"上低 15.6 个点——网站级平均会把这俩信号抵消掉，而技能级诊断直接告诉你"去补 filter"。
一句话评价：这不是一篇炫技的方法论文，而是一篇把评估这件事做扎实的基础设施论文。它的价值不在某个 SOTA 数字，而在于它给 Web Agent 的评估范式从"排名"推进到了"诊断"。如果你在做 Agent 训练或者选型，这套思路值得认真看。
论文信息
- 标题：Where Did It Go Wrong? Process-Level Evaluation of Web Agents with Semantic State Tracking
- 作者：Jiwan Chung、JiHyuk Byun、Vibhav Vineet、Seon Joo Kim
- 机构：Yonsei University（延世大学）、Microsoft Research
- arXiv：2606.15673
- 项目主页：https://jiwanchung.github.io/webstep/
为什么"只看终点"是个大坑
先看论文开篇的那张图，我觉得它一张图就把整篇论文的动机讲清楚了。
图1：终点结果无法区分质量上不同的失败。任务是"找到 Finley Clark 的消息并回复一个 :fire: emoji"。Fara 压根没找到正确的消息线程；GUI-Owl 找到了正确线程，但用了错误的 reaction。两者拿到完全相同的分数，但失败的本质天差地别。
你品一下这个例子。Fara 是探索失败——它在茫茫消息里没定位到目标。GUI-Owl 是执行失败——它人都走到正确的消息面前了，临门一脚点错了表情。
在传统 benchmark 里，这俩都记为 0 分，完事。可作为一个调模型的人，我看到这两种失败的第一反应是完全不同的：Fara 我得想办法增强它的检索和探索能力；GUI-Owl 我得去查它最后一步动作映射哪里出了岔子。把它们当成同一种失败来处理，是会把优化方向带歪的。
说白了……（这个词我得收回，换个说法）——核心问题就是，二元结果没法支持准确的信用分配（credit assignment）。你不知道 Agent 在哪一步、因为哪种能力的缺失而失败。评估退化成了一个排行榜，而排行榜对"怎么改进"几乎没有任何指导意义。
我自己之前在评 Agent 的时候也踩过这个坑。两个版本成功率差不多，就以为没区别，结果上线后发现一个在长任务上稳定崩溃，另一个是偶发性点错。这种差异，终点指标是真的看不出来。
WebStep 怎么做到"全程可追踪"
关键设计：语义 MDP 对偶
这是整篇论文最漂亮的一个 idea，我得重点讲。
通常你想知道 Agent 每一步在干嘛，要么靠人工逐帧标注（贵且不可扩展），要么靠另一个模型去判断（噪声大）。WebStep 换了个思路：既然网站是我自己造的，那我干脆让网站本身就是一个状态机。
具体说，每个网站背后都挂着一个确定性的语义 MDP，它和 GUI 是并行存在的对偶关系：
- Agent 只跟渲染出来的可视化 GUI 交互（点击、输入、滚动）
- 但 Agent 的每个 GUI 动作不会直接更新页面，而是先转发给后台的语义模型
- 语义模型按状态转移函数算出新状态、决定哪些信息该暴露，然后页面据此重新渲染
图2：WebStep 总览。每个可视化网站都配一个语义 MDP 对偶，把原始 GUI 动作转换成可解释的语义转移。比如"点击 + 输入"这一串底层操作，会被合并成一个高层的语义动作。语义 MDP 是所有行为的唯一真值来源。
这个设计的妙处在于：GUI 轨迹本质上就是语义 MDP 的一次直接执行，所以你能零成本、无标注地拿到完整的语义轨迹。这比事后让模型猜"Agent 刚才那一步算搜索还是过滤"靠谱太多了。
形式上，这个 MDP 定义为 \(\mathcal{M}=(\mathcal{S}, \mathcal{A}, T, \rho_0)\)。状态 \(s=(s^p, s^i)\) 拆成两块：\(s^p\) 是界面位置（当前 URL、搜索过滤设置、分页、打开的弹窗），\(s^i\) 是暴露给 Agent 的物品属性（价格、评分、卖家等）。动作空间 \(\mathcal{A}\) 把坐标级的交互抽象成类型化的语义动作。转移 \(T\) 是确定性的。
我喜欢这个设计的一点是它的确定性。因为整个世界完全确定，论文能静态推导出每个任务的 oracle 轨迹——也就是理论上最短的有效解法。有了 oracle 当参照系，后面所有"Agent 偏离了多远""漏了哪一步"的分析才有了锚点。
规模与领域
WebStep 不是个玩具。
| 项目 | 数值 |
|---|---|
| 自托管网站 | 10 个 |
| 任务总数 | 1,800 个（每站 180 个） |
| 每个模板实例数 | 4–30 个 |
10 个网站覆盖的领域相当生活化：Mail、Calendar、Shopping、Accommodation（住宿）、Food Delivery、Housing（租房）、Coding Q&A、Code Repository、Job Network、Team Chat。
图8：WebStep 全部 10 个网站的截图。上排：邮件、日历、购物、住宿、外卖；下排：租房、编程问答、代码仓库、求职、团队聊天。每个站点都是从真实网站工作流追踪出来后自托管复刻的。
图7：WebStep 任务分布。内环是 10 个网站，每个 180 个任务；外环是各任务模板及其实例数。模板实例数从 4 到 30 不等，反映了不同任务类型的复杂度差异。
难度是怎么"控制"的——硬负样本
这块我觉得设计得很有心思。难度不是靠"任务描述写得更绕"来制造的，而是靠 hard negative（硬负样本）。
什么意思？在列表页或搜索结果页上，会有一堆干扰项，它们共享目标的所有可见属性——同样的标题、价格、类别。光看列表你根本分不出哪个是对的。区分它们的关键属性（比如卖家、配送政策）只在详情页里才暴露。
所以 Agent 想找对目标，就必须挨个点进详情页去看。这一下就把"探索"这个能力给逼出来了——你不深入探索，就只能靠猜。
论文用三个轴来刻画复杂度：硬负样本数量、信息访问层级（列表级 / 过滤级 / 详情级）、oracle 轨迹长度。每个任务还保证全世界恰好只有一个目标满足所有约束，可解且唯一,这点对评估的严谨性很重要。
顺带提一句构建管线：先追踪真实网站工作流，再用编码 Agent（论文里用的是 Claude Opus 4.6）加人工迭代审核生成 MDP 规范，转成自托管网站，最后经 MDP 单元测试、GUI 交互测试、oracle 轨迹重放等自动验证加人工核对。这套流程不轻松，能看出是认真在做基础设施。
跟现有 benchmark 比，差在哪
| Benchmark | 确定性 | 任务数 | 过程评估 | 硬负样本 |
|---|---|---|---|---|
| Online-Mind2Web | ✗ | 300 | ✗ | ✗ |
| WebVoyager | ✗ | 643 | ✗ | ✗ |
| WebArena | ✓ | 812 | ✗ | ✗ |
| VisualWebArena | ✓ | 910 | ✗ | ✗ |
| Mind2Web-Live | ✗ | 542 | 关键节点 | ✗ |
| WebStep | ✓ | 1,800 | MDP | ✓ |
WebArena、VisualWebArena 这些虽然也是确定性的，但都不做过程评估，也没有硬负样本机制。Mind2Web-Live 有一点"关键节点"级的过程评估，但粒度远不如 MDP 这么细。WebStep 是唯一一个把确定性、大规模、MDP 级过程评估、硬负样本四样凑齐的。
把"成功率"拆开：到底该量什么
光有轨迹还不够，得有一套指标体系把它读出来。论文从 MDP trace 里自动算出这么几个聚合指标：
- Terminal SR：老规矩，最后有没有找对目标并成功提交
- Exploration SR：提交前有没有隔离出正确目标（访问详情页序列的最后一个是不是目标）
- Execution SR：在探索成功的前提下的终点成功率——专门隔离"找到之后能不能做对"这个能力
- Informational Coverage：在提交那一步，Agent 观察到的任务相关属性占比，衡量信息收集得彻不彻底
- Step Efficiency：原始 GUI 步数 / 语义步数，比值越低说明越多动作产生了真正的语义进展
Exploration SR 和 Execution SR 这对拆分是整套体系的核心。回到开篇那个例子：Fara 是 Exploration 挂了，GUI-Owl 是 Execution 挂了。有了这两个指标，这两种失败立刻就分得清清楚楚。
技能分解：把动作归到 5 类技能
论文进一步把 MDP 动作映射成 5 类技能：inspect（打开详情）、navigate（界面间跳转）、search（文本检索）、filter（过滤缩小候选）、commit（对目标执行最终动作）。
以 oracle 轨迹为参照，看 Agent 在该用某类技能的时候有没有调用它。注意是"调用"而不是"成功"——因为语义技能往往只有在完成时才能识别。
图3：技能级的强弱画像。不同 Agent 在同一个网站内呈现出截然不同的技能 profile。比如在 Housing 上，OpenAI CUA 的 commit 强但 filter 弱，说明一个 Agent 在某个领域的整体表现，是由内部参差不齐的技能拼出来的。
这张图是论文的"题眼"。我第一次看到"同一个网站内技能排名相反"这个现象时，确实愣了一下——我们平时太习惯于用一个领域的整体分数去评判 Agent 了，从没想过领域内部的技能能强弱倒挂。
图4：技能调用的时间模式。除了"调用了哪些技能"，论文还分析"什么时候调用"。OpenAI CUA 倾向于集中的早期模式（通常以 search 开场），而 Fara 早期动作更分散、且容易过早 commit。
分叉分析：精确定位"哪一步开始崩的"
这是我个人最喜欢的一块。既然成功和失败的轨迹都跑在同一个语义 MDP 上，那就能把它们对齐，找到分歧前最后一个共享状态——这个点就是"分叉点"，是决定性错误发生的地方。
分叉分三类： - Wrong branch（走错路）：两条轨迹下一步动作不同，且都不是 commit - Delayed commit（该交不交）：成功轨迹该 commit 了，失败轨迹还在磨蹭 - Premature commit（过早提交）：失败轨迹提前 commit，成功轨迹还没到时候
图5：轨迹分叉分析定位失败被引入的位置。(a) Wrong branch：第一个把轨迹带偏的决策。分析显示这个决定性错误是 agent-specific 的，而不是所有模型共享的——也就是说不同 Agent 栽的跟头不一样。
论文给的具体数字挺有意思：多数 Agent 的首个错误步是 Inspect（28–41%），也就是点开了错误的物品页；Fara 和 UI-TARS 还常退回 Search（27–29%）；GUI-Owl 则更多通过 Filter 分叉（24%）。在 Delayed commit 里，GUI-Owl 把 65% 的多余动作砸在 Filter 上反复优化；在 Premature commit 里，5 个模型有 4 个最常跳过 Inspect（漏了最后的证据收集），唯独 GUI-Owl 例外——它 64% 是跳过了 Search，在目标还没被检索出来之前就抢着提交了。
失败是 agent-specific 的，不是共享的。 这个结论意味着，针对性修复才是正道，指望一个通用 trick 解决所有 Agent 的问题不现实。
实验：五个 Agent 的真实画像
评估对象覆盖了大小两档：
- 小型专用模型：UI-TARS-1.5-7B（字节）、Fara-7B（微软）、GUI-Owl-1.5-8B（阿里 mPLUG）
- 大型通用模型：Qwen3.5-122B（阿里）、OpenAI CUA（GPT-5.4）
主结果表
| Agent | Terminal SR | Exploration SR | Execution SR | Info Coverage | GUI步数 | 语义步数 | GUI/语义比 |
|---|---|---|---|---|---|---|---|
| Fara-7B | 31.4 | 43.6 | 55.7 | 60.6 | 18.9 | 8.3 | 2.3 |
| GUI-Owl-1.5-8B | 31.9 | 43.6 | 55.6 | 61.9 | 28.3 | 10.4 | 2.7 |
| UI-TARS-1.5-7B | 32.6 | 46.3 | 50.6 | 62.6 | 35.0 | 14.0 | 2.5 |
| Qwen3.5-122B | 57.9 | 66.1 | 73.7 | 67.7 | 22.1 | 9.8 | 2.3 |
| OpenAI CUA | 82.2 | 87.7 | 86.2 | 71.0 | 19.7 | 10.0 | 2.0 |
先看那三个小模型：terminal SR 分别是 31.4、31.9、32.6，挤在一块儿，肉眼看就是"打平"。但过程指标一拆：
- UI-TARS 探索更强（46.3，比另两个高约 2.7 个点）但执行更弱（50.6，比 Fara 低 5 个点），而且步数和信息覆盖率都最高——典型的扩张式探索风格，到处看，但临门一脚不稳。
- Fara 步数和覆盖率都最低——探索参与度偏弱，懒得逛。
同样是 32% 的成功率，一个是"逛得很勤但手抖"，一个是"懒得逛"。修法完全不同。这就是过程评估的价值。
再看大模型这边，OpenAI CUA 不只是 terminal SR 碾压（82.2），它的 GUI/语义比是最低的 2.0——意味着它每个动作的"含金量"最高，更少做无用功。Qwen3.5 也不错（57.9），但跟 CUA 还有明显差距。
题眼复现：Housing 上的技能倒挂
论文反复强调的那个例子，我再拎出来说一遍，因为它太能说明问题了：
在 Housing 网站上，OpenAI CUA 在 commit 上比 Qwen3.5 高 23.7 个点（比如成功发出租房请求），但在 filter 上比 Qwen3.5 低 15.6 个点。
如果你只看 Housing 的整体成功率，这一正一负被平均掉，你只会得到一个"CUA 在 Housing 上略好"的模糊结论。而技能级诊断直接告诉你：CUA 的 filter 是短板，去加点训练过滤的 Housing 样本。 这才是能落地的建议。
难度越高，差距越大
图6：按任务复杂度看探索成功率。(a) 按硬负样本数量分组——5 个 Agent 里 4 个随干扰项增多而单调下滑，唯独 OpenAI CUA 对干扰项数量敏感度低得多。(b) 按 oracle 轨迹长度——Qwen3.5 随任务变长持续下滑，CUA 维持得更久。(c) 按信息访问层级——简单任务上大家差不多，越往详情级走，强弱差距拉得越开。
这张图传递的信息很关键：在简单任务上，所有 Agent 看起来都差不多；真正把它们区分开的是高难度任务。 在 card 级任务（只看列表）上大小模型表现接近，到了 filter 任务开始分化，到 detail 任务就把最强的 CUA 和次强的 Qwen3.5 彻底拉开了。
这其实是对"用简单任务刷榜"的一个隐含批评——如果你的 benchmark 难度不够，所有模型挤在天花板附近，你根本测不出真实差距。WebStep 用硬负样本主动把难度顶上去，差异才显现出来。
我的判断
先说亮点。
语义 MDP 对偶这个设计是真的漂亮。 它用"网站本身就是状态机"的方式，把过程标注的成本干到了零，同时保证了确定性和 oracle 可推导。这不是某个 loss 的小改动，而是评估基础设施层面的一次扎实推进。Exploration / Execution 的拆分、技能分解、分叉分析这一整套指标体系，逻辑自洽且实用，能直接转化成"该补哪个技能、该改哪种时序毛病"的工程动作。
再说我的几点保留。
第一，合成世界和真实网站的 gap 不小。 论文自己在局限里也坦诚了：语义抽象没有捕捉动态内容更新、会话依赖状态、异步加载、个性化推荐这些真实网站的脏活。真实 Web 的混乱程度，远超一个确定性 MDP 能模拟的。所以 WebStep 上的诊断结论能不能直接迁移到生产环境的 Agent，我打个问号。
第二，"测调用而非测成功"是个妥协。 技能分解里测的是 Agent 有没有"调用"某类技能，而不是"成功执行"了它。这是因为语义技能往往只在完成时才能识别。可这意味着技能级的强弱画像，本身还隔着一层——一个 Agent 频繁调用 filter，不代表它 filter 用得好。这个 gap 在解读图3的时候要小心。
第三，基于模板的任务，覆盖不了真实用户请求的模糊性。 1,800 个任务听起来多，但都是模板生成的，缺少真实用户那种含糊、跳跃、自相矛盾的表达。
但这些保留都不影响我对它的整体评价：这是一篇把"评估"这件被低估的事认真做扎实的好论文。 Web Agent 领域现在不缺刷榜的模型，缺的是能告诉你"模型到底差在哪"的工具。WebStep 填的就是这个空。
如果你在做 Web Agent 的训练或选型，我的建议是：别再只盯着那个总成功率了。把你的 Agent 在不同技能、不同难度、不同失败类型上的画像拉出来看一看，你大概率会发现一些总分掩盖掉的真问题。哪怕你不用 WebStep，这套"探索 vs 执行""技能分解""分叉定位"的诊断思路，也完全可以借鉴到你自己的评估流程里。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我