上周末想把一个 GUI agent 的分数复现一遍，没跑通。不是模型的问题，是环境。
同一个站点，上午跑出来 41/50，下午同一个脚本跑出来 33/50。中间页面改版了，按钮挪了位置，我写死的那套选择器全废。剩下还能跑通的那一半，基本全是不用登录的浅层页面；要求登录之后才能走完的流程，我连登录都搭不起来，干脆砍掉不测了。砍完之后那个分数好看得我自己都不太敢信。
# 同一个脚本，隔了五个小时
run #1 pass 41/50
run #2 pass 33/50 # 站点改版，选择器全部失效
这段是我自己凑的复现脚本，不是谁的官方工具，但它把我按在地上摩擦了一下午。后来翻到 WebHarbor（arXiv:2611.03634，11 月 2 号挂出来的，31 页，第一作者 Zhaoyang Wang，后面跟了一长串合作者，cs.AI 主分类，也涉及 cs.CL 和 cs.LG），第一反应是又一个堆量的活——153 个网站、3518 个任务，GUI 这块最不缺的就是拿站点数量当卖点的东西。读到它讲环境构建的那部分，我才改主意：它想解决的，正是我上周末碰上的那个问题。
它的做法是把真实网站搬进容器，界面外观、页面内容、业务流程这三样都重建一遍，然后在确定性控制下跑。确定性这个词是我最在意的。线上站点做评测有三个老毛病——内容天天变、动不动被限流、登录之后的流程覆盖不到——听起来是三件事，其实是同一件事：你没法把环境按住。按不住环境，测出来的数就只对那一刻成立，隔五个小时就作废，我那个 41 变 33 就是活证据。
webharbor/
├── envs/
│ └── <site>/
│ ├── docker-compose.yml
│ ├── seed/ # 初始数据
│ └── fixtures/ # 页面与流程的固定快照
└── tasks/
└── <site>/<task>.json
说明一下：这个结构是按论文描述的意思画的，具体字段以仓库为准，我还没把仓库拉下来跑过，所以不敢说它就是长这样。但 seed 和 fixtures 分开这件事本身说明作者是想了的——数据可以从零灌，页面和流程快照固定住，站点改版不会传导到你的分数上。上午下午两个数那种坑，第一层就被堵死了。起一个环境大概就是：
$ docker compose -f envs/<site>/docker-compose.yml up -d
$ curl -s localhost:8080/health
{"status":"ok","seed":"v3"}
健康检查能回来，就说明种子数据灌进去了，可以开始灌任务。任务是这么定义的：
{
"id": "shop-checkout-coupon",
"requires_login": true,
"success": "order.status == 'paid' && coupon.applied"
}
同样是示意，不是官方 schema。但 requires_login 这个字段出现在任务定义里，而不是让评测的人在外面自己拼一个 cookie，这个区别比我一开始以为的大——它意味着登录之后的流程是一等公民，不是"跑不通就跳过"。3518 个任务里多步骤流程和登录后流程都覆盖了，我上周末砍掉的那一半，在这里总算是有位置的。
真正让我觉得这篇值得记一笔的，不是那 153 和 3518 这两个数，是它怎么攒出来的：任务驱动的协作，新任务推着环境往外扩，编码智能体负责把改动实现掉，人类贡献者审核三件事——视觉保真度、功能正确性、任务有效性。
前两项我觉得是常规操作。一开始甚至觉得视觉保真度有点多余，跑分又不看像素；后来想明白，界面长得不像，智能体学到的那点定位能力就迁移不出去，这一项省不掉。
第三项"任务有效性"才是这个流程里最诚实的一笔。一个任务如果在环境里压根走不通，模型怎么练都学不会，最后背锅的是模型。这种亏我吃过：写了个自以为很妙的任务，跑了一晚上全是零分，最后发现是提交按钮的 fixture 少了个事件绑定。把"任务有效性"单独拎出来当审核项，等于承认环境自己也会出 bug，得有人签字。这个态度比多刷两个点更值钱。
接下来泼半盆冷水。
论文说用强化学习训出来的 Qwen 4B 级 GUI 智能体，能迁移到未见任务，在四个基准上和领先的开源 GUI 网页智能体表现相当。这个数字我建议先别急着转发。
未见任务和未见网站是两码事。所有任务都长在同一批 153 个站点的分布里，训练集和测试集在任务层面隔开，但站点模板、交互约定、按钮在哪、表单怎么提交，这些是共享的。4B 能在同一个环境族里追平大模型，说明这套环境信号密度够、练得动，这是个好信号；但它不能直接当成"小模型也能通用"的证据。四个基准具体是哪四个、测试集在站点层面有没有隔开，我得把仓库拉下来自己核一遍才敢下判断，这一步我现在还没做，先记在这儿当个待办。
$ git clone <repo> # 待办一：拉仓库
$ ls envs | wc -l # 待办二：数一下环境到底几个能起得来
$ grep -rl "requires_login" tasks | wc -l # 待办三：登录任务占多少
这三条跑完，我心里才有底。别人的 3518 是别人的，自己数出来的才算。
划重点：第一，GUI agent 评测现在最大的瓶颈不是模型，是环境不可复现，容器化 + 固定快照是目前最朴素的解法；第二，看这类工作别只看站点数和任务数，去看它审什么——把"任务有效性"列进审核项的，通常是真的跑过、被自己的环境坑过的；第三，迁移到未见任务和迁移到未见网站是两回事，看到小模型追平的结论，先问测试集在站点层面有没有隔开。你可以照上面那三条命令自己跑一遍，数出来的数字和论文里的对不对得上，比我说什么都靠谱。