WebArena多步骤任务：AI助手的数字商场跑腿课

可视化演示

展示WebArena评测中Agent多步骤任务的执行流程：任务分解、网页交互步骤、中间状态验证与步骤间依赖关系。

任务定义

阿哲第一天当跑腿员，组长递给他一张任务单：“顾客要一份生日惊喜，下午5点前送到服务台。”他没问清楚就出发，结果在商场转了一圈，不知道要买什么，也不知道送到哪里，最后空手而归。组长告诉他：任务不是一个模糊的念头，而是一条有起点、有终点、有检查点的路线。

在 WebArena 这座“数字商场”里，每个评测任务也是这样一张任务单。它由一句自然语言目标、一个初始网页状态和一个期望的目标网页状态共同定义。WebArena 包含自托管的在线商店、论坛、GitLab、CMS 等真实可交互应用，Agent 需要像跑腿员一样进入真实店铺，通过多次点击、输入、滚动和跳转完成任务。多步骤任务与单轮问答不同，没有“标准答案直接返回”，必须通过一连串状态变化证明自己到达了终点。

在数学上，一个多步骤任务可以记作一个三元组：

$$\displaystyle \mathcal{T} = (g, \omega_0, \omega^{\ast})$$

1. 任务符号：\mathcal{T} 表示一个多步骤任务整体，相当于一张完整任务单。

$$\mathcal{T}$$

2. 目标描述：g 是自然语言目标，例如“买一件生日礼物并包装好送到服务台”。

$$g$$

3. 初始状态：\omega_0 是任务开始时网页的状态，相当于跑腿员出发时所在的商场门口。

$$\omega_0$$

4. 目标状态：\omega^{\ast} 是任务成功时网页应处于的状态，相当于服务台签收后的凭证。

$$\omega^{\ast}$$

任务单上的每一步都是真实世界的缩影：取号、排队、挑货、结账、包装、交单。阿哲终于明白，跑腿员接到的不是一句话，而是一条需要亲自走完的线——起点在门口，终点在服务台，中途的每一步都算数。

目标拆解

阿哲第二次接到任务：“帮顾客准备一份生日惊喜。”这次他没急着跑，而是把任务单摊在桌上，先画出五个方框：买礼物、买贺卡、要包装、约配送、送服务台。大目标像一棵树，主干分出枝杈。组长表扬他：这就是拆解。

在 Agent 评测中，目标拆解指把自然语言目标转化为若干子目标。WebArena 任务往往包含多个约束，比如商品型号、预算、收货时间等。Agent 需要把它们组织成层级任务树：根节点是总目标，子节点是可执行子目标。这些子目标通常要按一定顺序执行，构成一个序列。拆解不是一次性的：当网页变化、商品缺货时，Agent 还要调整顺序。

一个经典的拆解可以写成从总目标到子目标序列的映射：

$$\displaystyle \mathrm{Decompose}(g) = (g_1 \rightarrow g_2 \rightarrow \cdots \rightarrow g_k)$$

1. 拆解函数：\mathrm{Decompose} 是把总目标切成子目标的操作，相当于把任务单画成一棵方框树。

$$\mathrm{Decompose}(g)$$

2. 总目标：g 是原始自然语言目标，也就是“生日惊喜”。

$$g$$

3. 子目标序列：g_i 表示第 i 个可执行子目标，例如“选购礼物”“购买贺卡”。

$$g_i$$

4. 顺序箭头：\rightarrow 表示子目标之间按顺序执行，前面完成后再做后面。

$$g_1 \rightarrow g_2$$

跑腿员的“好记性不如烂笔头”就是任务树。每个方框都像商场里的一个区域：先在 3 楼买礼物，再到 1 楼买贺卡，最后到服务台集合。拆得好，脚步才不会乱。

状态验证

阿哲在一次任务里，兴冲冲买完礼物赶到服务台，却被柜员提醒“这是给 6 岁小女孩的礼物，你买了男士钱包”。他愣住了：原来挑完商品后没核对购物车，以为点进店铺就是买好了。组长说：每完成一步，都要低头看一下清单。

这在 Agent 评测里叫“中间状态验证”。Agent 每执行若干动作，就读取当前网页的 DOM 快照，对照子目标要求的条件，判断这一步是否真的达成。光看 URL 变化不够，因为很多状态只体现在页面元素的文本、属性或可见性上。验证函数以当前观测和子目标为输入，输出“达成/未达成”。

状态验证函数可以写成：

$$\displaystyle V(s_i, \omega_t) = \mathbb{1}\left[\mathrm{Match}\left(\mathrm{obs}_t, \mathrm{target}_i\right)\right]$$

1. 验证函数：V 判断第 i 个子目标是否在当前状态达成，像跑腿员核对购物清单。

$$V(s_i, \omega_t)$$

2. 子目标：s_i 是待验证的子目标，例如“购物车里已有礼物”。

$$s_i$$

3. 当前状态：\omega_t 是 t 时刻的网页状态。

$$\omega_t$$

4. 观测与目标：\mathrm{obs}_t 是从 DOM 读到的页面观测，\mathrm{target}_i 是子目标要求。

$$\mathrm{obs}_t, \quad \mathrm{target}_i$$

5. 指示函数：\mathbb{1}[\cdot] 当方括号内成立时取 1，否则取 0，对应“打勾/没打勾”。

$$\mathbb{1}\left[\mathrm{Match}\left(\mathrm{obs}_t, \mathrm{target}_i\right)\right]$$

就像跑腿员每买完一样东西就掏出购物清单打一个勾，Agent 也要在每个子目标完成后“打勾”。打勾的意义不是自我安慰，而是防止把“走到柜台”误当成“完成交付”。

依赖处理

有一次阿哲想先到服务台排队，结果被要求“请先取号”；想结账，却被告知“请先挑选商品”。他发现任务单上其实藏着箭头：有些步骤必须发生在另一些步骤之后。

在 WebArena 中，子目标之间存在前置条件、数据传递和资源占用等依赖。例如“登录”必须发生在“下单”之前，购物车中的商品数据要传递给结算页。Agent 需要判断前置条件是否满足；如果依赖的步骤尚未完成，就不能贸然执行。评测中还会出现循环重试——某个依赖暂时失败，以及死锁——两个步骤互相等待，Agent 需要通过放弃、重规划等手段避免。

执行某个子目标前，我们可以用一个包含关系来刻画依赖：

$$\displaystyle \mathrm{Prereq}(s_j) \subseteq \mathrm{Done}_t$$

1. 前置条件：\mathrm{Prereq}(s_j) 是执行子目标 s_j 前必须完成的子目标集合。

$$\mathrm{Prereq}(s_j)$$

2. 子目标：s_j 是当前想执行的一步，比如“结账”。

$$s_j$$

3. 已完成集合：\mathrm{Done}_t 表示 t 时刻已经完成的所有子目标。

$$\mathrm{Done}_t$$

4. 包含关系：\subseteq 要求前置集合里的每一项都在已完成集合中，就像取号必须在排队前完成。

$$\mathrm{Prereq}(s_j) \subseteq \mathrm{Done}_t$$

这些依赖就像商场的动线：先取号才能排队，先排队才能到柜台。跑腿员的任务单上箭头画得越清楚，越不会在服务台和专卖店之间来回折返。

执行策略

阿哲渐渐明白，光有计划还不够。商场里会临时封路、店铺会缺货，他得随时看指示牌、问咨询台，甚至兜圈子也要找到路。好的跑腿员不是背下地图，而是在地图失效时仍能转弯。

Agent 的执行策略决定“下一步做什么动作”。它不仅要看当前网页，还要结合之前的动作轨迹。多步骤任务中表现优秀的 Agent 会记录完整轨迹，包括访问过的 URL、点击过的元素、输入过的文本；当某一步失败时，能够回溯到上一个验证通过的状态再尝试替代路径。探索与利用也需要平衡：既要尝试新路线，也要避免在一个死胡同里反复点击。

这种决策过程可以用条件策略表示：

$$\displaystyle \pi(a_t \mid \omega_t, \tau_{<t})$$

1. 策略函数：\pi 决定 Agent 在当前情形下选择什么动作，相当于跑腿员的临场决策。

$$\pi$$

2. 动作：a_t 是 t 时刻要执行的动作，如 click、type、navigate。

$$a_t$$

3. 当前网页：\omega_t 是当前观测到的网页状态，相当于跑腿员此刻看到的楼层指示牌。

$$\omega_t$$

4. 历史轨迹：\tau_{<t} 是 t 时刻之前的交互记录，决定“之前走过哪、失败过哪”。

$$\tau_{<t}$$

5. 条件关系：竖线表示在所有已知信息条件下输出动作分布。

$$\pi(a_t \mid \omega_t, \tau_{<t})$$

阿哲的临场应变就像这个策略公式：看到“此路不通”就换电梯，看到“缺货”就换店铺。每一步行动都不是拍脑袋，而是根据“我在哪、之前走过哪、接下来要去哪”决定的。

评测指标

到了月底，组长拿出一张打分表。阿哲问：“我不是都把任务完成了吗？”组长摇头：“你有一单忘交贺卡，还有一单在商场里多绕了三圈。完成不等于完美。”

评测多步骤任务不能只看一个数字。WebArena 及类似基准通常关注三类指标：任务成功率——最终状态是否完全匹配目标；部分完成度——子目标完成的比例；步骤效率——实际动作步数与理想步数的比值。这些指标会加权成综合得分，兼顾“做没做成”与“做得好不好”。

任务成功率是最基础的指标：

$$\displaystyle \mathrm{SR} = \frac{1}{N}\sum_{i=1}^{N}\mathbb{1}[\mathrm{succ}_i]$$

1. 成功率：\mathrm{SR} 是任务成功率，表示所有任务中完全成功的比例。

$$\mathrm{SR}$$

2. 任务总数：N 是评测集中的任务数量，相当于一沓任务单。

$$N$$

3. 求和：\sum_{i=1}^{N} 把所有任务的成功标记加起来。

$$\sum_{i=1}^{N}$$

4. 成功标记：\mathbb{1}[\mathrm{succ}_i] 第 i 个任务完全成功时为 1，否则为 0。

$$\mathbb{1}[\mathrm{succ}_i]$$

5. 平均：乘以 \frac{1}{N} 得到最终比率。

$$\frac{1}{N}\sum_{i=1}^{N}$$

打分表上的每一栏都对应跑腿员的一天：成功率是“有没有把货送到”，部分完成度是“有几样忘在车上”，步骤效率是“有没有来回绕路”。阿哲终于明白，金牌跑腿员不是靠一次完美，而是靠每单都稳、每步都准。

数据集构建

阿哲成为组长后，开始给新跑腿员编写任务单。他先写清楚“出发地点、目标地点、注意事项”，然后自己跑一遍确认任务现实可完成，最后做一个检查表，看看新跑腿员执行得对不对。这就是在构建一个多步骤任务的评测数据集。

构建 WebArena 多步骤任务数据集需要四件事：任务模板设计——把同一类目标换成不同商品、账号、主题生成多样本；人工验证流程——确认任务有可行解法且初始状态无歧义；自动评分脚本——用网页状态断言判断是否达成目标；可复现基线——固定环境和起始条件，保证不同 Agent 结果可比。每一步都是为了给“任务单”打上质量标签。

一个人工验证过的数据集可以表示为：

$$\displaystyle \mathcal{D} = \{(g_i, \omega_0^i, \omega_{\ast}^i, r_i)\}_{i=1}^{M}$$

1. 数据集：\mathcal{D} 是构建出的多步骤任务评测集，相当于跑腿员训练营的题库。

$$\mathcal{D}$$

2. 任务项：每个元素 (g_i, \omega_0^i, \omega_{\ast}^i, r_i) 是一张完整任务单。

$$(g_i, \omega_0^i, \omega_{\ast}^i, r_i)$$

3. 描述与状态：g_i 是目标描述，\omega_0^i 是初始网页状态，\omega_{\ast}^i 是目标状态。

$$g_i, \quad \omega_0^i, \quad \omega_{\ast}^i$$

4. 质量标记：r_i 是参考评分或可执行性标签，表示人工验证结论。

$$r_i$$

5. 下标范围：i=1,\ldots,M 表示共有 M 条经过筛选的任务。

$$i=1,\ldots,M$$

跑腿员训练营的题库，就是一本本任务单。好任务单让新人有据可依，烂任务单会让两个人都白跑一趟。数据集的质量，决定了评测这杆秤到底准不准。

AI 应用场景

Python 演示

class MultiStepRunner:    def __init__(self, steps):        self.steps = steps        self.results = {}     def run(self, execute, verify):        for step in self.steps:            if not all(self.results.get(dep, False) for dep in step["deps"]):                self.results[step["id"]] = False                continue            execute(step)            self.results[step["id"]] = verify(step)        total = len(self.steps)        done = sum(1 for v in self.results.values() if v)        return {"success_rate": done / total, "partial_completion": done / total}  if __name__ == "__main__":    steps = [        {"id": "get_ticket", "deps": [], "desc": "取号"},        {"id": "queue", "deps": ["get_ticket"], "desc": "排队"},        {"id": "pick", "deps": [], "desc": "挑货"},        {"id": "checkout", "deps": ["queue", "pick"], "desc": "结账"},        {"id": "wrap", "deps": ["checkout"], "desc": "包装"},        {"id": "deliver", "deps": ["wrap"], "desc": "交单"},    ]     def execute(step):        print("执行:", step["desc"])     def verify(step):        return step["id"] != "wrap"     runner = MultiStepRunner(steps)    summary = runner.run(execute, verify)    print("成功率:", summary["success_rate"])    print("部分完成度:", summary["partial_completion"])

1. self.results = {}用一个字典记录每个步骤是否完成，相当于跑腿员的购物清单打勾表。
2. for step in self.steps:依次遍历任务单上的所有步骤。
3. if not all(self.results.get(dep, False) for dep in step["deps"]):检查当前步骤的依赖是否全部完成，缺一个就跳过。
4. execute(step)执行当前步骤，相当于跑腿员真的跑到对应店铺做动作。
5. verify(step)对执行后的状态做验证，模拟读取 DOM 快照判断目标是否达成。
6. done = sum(1 for v in self.results.values() if v)统计已经打勾的步骤数，算出部分完成度。
7. return {"success_rate": done / total, "partial_completion": done / total}返回评测指标，供上层看板展示。

常见误区

面试题