WebWorld：别训练世界模型了，浏览器就是现成的那个

让 VLM 自己看自己写的网页、自己挑毛病、自己改、再自己判断改得好不好——这个自我改进闭环听起来很顺，但做过的人都踩过同一个坑：改完截图看着漂亮了，点一下按钮，没反应。模型既当运动员又当裁判，而它俩的判断都发生在"截图空间"里，赢的那个候选只是"看起来赢了"。

这篇论文给出的答案干脆得有点任性：别费劲去训练什么 world model 了，浏览器本来就是网页代码的世界模型——确定性、可执行、骗不了。缺的不是模型，是一个让 VLM 跟这个现成世界模型打交道的接口。

核心摘要

VLM 驱动的网页代码自改进有个结构性缺陷：提修复方案的和判定修复好坏的是同一个模型，而"截图看着合理"对"页面真的能用"是个很差的代理。WebWorld（arXiv: 2608.30530）把浏览器当作网页代码的现成世界模型，设计了三件套接口——交互契约（contract）、验收证书（certificate）、质量棘轮（ratchet）：VLM 只负责提假设，浏览器重新执行后才发证书，只有拿到证书的修复才进 SFT 训练池。在完全对齐的训练配方下，WebWorld-27B 比 Raw-27B 在 HTMLBench-400 上高 5.3 分、在 MiniAppBench-Val 上高 14.9 分，达到 Kimi-K2.6 和 GPT-5.4 同档水平。最狠的证据是消融：拿掉浏览器证书，9B 模型的提升从 4.8 分直接塌到 0.4 分——收益几乎全在"浏览器背书"这一步。这不是一篇"更大的模型+更多的数据"的论文，是一篇关于"监督信号该由谁来签字"的论文，值得做 agent 数据管线的人细读。

论文信息

• 标题：WebWorld: The Browser as a World Model for Self-Improving Web Code
• arXiv：2608.30530v1，2026 年 8 月 31 日，cs.CL
• 作者：Jiajun Wu, Jian Yang, Yaxin Du, Wei Zhang, Haowen Wang, Junhang Cheng, Yuxuan Zhang, Tuney Zheng, Xianglong Liu, Ming Zhou
• 机构：北京航空航天大学、上海交通大学、IQuest Research、Langboat

🎯 问题：自我改进闭环里的"自己人"问题

现在 VLM 已经能从一个 prompt 生成完整的前端页面了。但"首屏看着对"和"页面真的能用"是两码事：提交按钮可能是死的，游戏可能不理键盘，一次修复可能把上一轮刚修好的控件悄悄弄没。

直觉的解法是把闭环跑起来：VLM 看截图、提批评、重写代码、再看新截图判断改没改好。说实话，我第一反应也是这个思路没毛病——但论文开头就泼了冷水：他们复现了这个朴素闭环（保留 VLM 批评和技能路由，只是去掉浏览器证书），结果在 HTMLBench 上只比 Raw 高 0.4 分，是完整 WebWorld 提升的十分之一都不到。

为什么？问题出在结构，不在提示词。VLM 同时干两份活：提议者（proposer）和裁判（judge），而两份判断都发生在截图空间。于是被选中的候选是"视觉上赢的那个"，可失败恰恰大多是行为层面的——按钮点不动、键盘没响应，截图根本看不出来。想让闭环闭合，必须引入 VLM 自己造不出来的证据。

图1：上半部分是 VLM-only 循环的死穴——"look improved"的修改换来"false process"；下半部分是 WebWorld 的完整环路：GUI 执行（click/key/observe）→ VLM 批评 → 候选补丁（target + preserve）→ 重新执行 → GUI 验证（task works / UI intact / no errors）→ 通过才进轨迹记忆，拒绝就打回。

🏗️ 方法：三件套，把"假设"和"证明"拆开

WebWorld 的核心设计哲学一句话：VLM 只提假设，浏览器负责证明。整个接口围绕三个耦合的工件展开，每个都在堵朴素闭环的一个具体漏洞。

图2：完整管线从左到右：Synthetic Task 生成任务与 HTML 种子 → GUI Interaction 在真实浏览器里跑探针（点击、键盘、观察）→ VLM Agent 产出批评与修复意图 → Interaction Contract 编译成可回放的目标、目标检查、保留检查 → Skill-Guided Repair 生成受限补丁 → GUI Verification 重放浏览器验证 Task Works / UI Intact / No Errors → Accepted 进训练集并开启下一轮，Rejected 打回。

交互契约（Interaction Contract）。VLM 的批评是自由文本，浏览器听不懂"让它更精致一点"。所以 VLM 必须输出结构化批评：问题家族、支撑证据、影响区域、修复后的成功条件、必须保留的行为、建议的修复技能。规划器把它编译成一个三元承诺——要达成什么（target，一个关于页面状态的可判定谓词）、浏览器怎么验（replay，锚定到稳定选择器的动作序列）、什么不能动（preserve set，之前所有已验证能力）。契约还有影响范围（impact scope）约束：补丁越界改到无关区域，契约本身就判失败。说实话这个设计挺漂亮的——"看起来被打磨过"这种纯感知判断，在编译阶段就被过滤掉了，根本到不了修复环节。

验收证书（Acceptance Certificate）。契约是声索，证书才是证据。浏览器按契约重新执行候选，只有目标谓词达成且全部保留谓词不被破坏，才签发一份自包含的证书：重述目标、总结 diff、记录证明级别、打包可离线复现的证据。验证器的形式化就是：

其中 \(\mathcal{P}_t\) 是到第 \(t\) 轮为止所有已验证谓词的集合。证明级别按优先级尝试：同轨迹重放 > 能力增益（之前失败的探针现在过了）> 目标问题进展 > 局部视觉证据 > 静态结构修复。证书只记录赢的那个级别，事后审计可以重放而不是靠主观。

质量棘轮（Quality Ratchet）。运行时进步和训练质量进步是两回事，很多闭环把它们混在一起。WebWorld 区分 IterStep（任何让探索继续的安全步骤）和 QualityStep（有证书背书、可导出为监督的转移）。准入规则比"不回退"更严格：目标必须达成，且 \(\mathcal{P}_t\) 里每个谓词都得继续成立。通过就把候选设为新基线，记忆更新为 \(\mathcal{P}_{t+1} = \mathcal{P}_t \cup \textsc{verified}(e_t)\)。单向棘轮——已验证的能力只能加不能丢，后面任何补丁弄坏其中一条，当场被拒。

四条性质是构造上保证的：假设与证明分离、所有主张类型化、能力记忆单调、准入完全确定性。这意味着每个 accept/reject 都能离线复现，不存在"那次大概是运气好"。

📊 实验：收益几乎全部来自"浏览器签字"

设置。监督语料是 32,800 条证书通过的转移；Raw 路线用未过滤的原始 HTML 在相同预算下训练；4B / 9B / 27B 三档，骨干、优化器、学习率、prompt 模板、评测器全部固定，只换监督来源。评测用 HTMLBench-400（400 个 prompt、6,000 条确定性浏览器测试用例，五个维度总分 100，功能分是大头）和 MiniAppBench-Val 做迁移检查。数据构造管线从不查询评测项，两边探针也是分离的——这点做得比较干净。

主结果（Table 1，节选关键行）：

提升随容量放大：4B 涨 3.4 分、9B 涨 4.8 分、27B 涨 5.3 分。更有意思的是提升的分布——TC pass 和 Functionality 跟着猛涨，而 Rendering、Visual、Code 三个维度涨跌不到一分、方向还不一致。门控根本没在优化"截图好不好看"，可行为分就是赢了。这个副作用我很喜欢：它反过来证明证书约束的确实是行为而不是皮。

证书机制消融（Table 2 / Table 3，9B、同预算）：

这张表是全文最值钱的部分。NoCertificate 不只是"没提升"——它的 TC pass 比 Raw 还掉了 3.1 分（31.0 对 34.1）。换句话说，去掉世界模型背书不是少赚，是往训练池里灌噪声，砸的恰恰是下游最在乎的行为维度。NoPreserve 的结果也在讲同一个故事：不做保留检查照样接受"进步"，但丢掉 3.3 分，损失集中在 TC 和 Functionality——回归就藏在这两个维度里。

深度诊断（Table 4）也很说明问题。固定 5,000 条样本，按最小认证深度过滤：深度 ≥1 时 43.4 分，≥3 时 46.8，≥5 时 48.8，之后饱和。最扎眼的是：5,000 条深度 ≥5 的样本，离用满 32,800 条的完整 WebWorld-9B 只差 0.5 分。深轨迹不是"更长"，是每条样本背了更多已验证能力——这正是单调记忆性质预言的信号密度差异。

验收审计热力图把话讲得更白：

图：WebWorld 接受的候选中 89% 是真进步（True Progress）；而被 WebWorld 拒绝、但 VLM 裁判会接受的候选里，只有 23% 是真进步，30% 是纯视觉改动（Visual Only），还有 19% 状态漂移、13% 保留失败；Score gate 那组稍好点，真进步也只有 34%。VLM 裁判放进来的东西，超过七成是假阳性。

🤔 我的判断

这篇论文最值钱的地方，是把"浏览器即世界模型"这个视角落到了可验证的工程机制上。SWE-bench 之所以 work，是测试套件当 oracle、补丁改不了它；但网页代码的缺陷大多是视觉和交互层面的，没有现成的测试套件——WebWorld 其实就是在没有测试套件的地方，用契约+证书现场"造"了一个 oracle。这个思路的迁移性不弱：任何"有确定性执行环境"的生成任务（shader、CAD 脚本、数据可视化配置）都能套这个假设-证明分离的架子。

但也有几个地方我持保留态度。一是适用范围被刻意收窄到单文件 HTML——作者自己在 Limitations 里承认，多文件、框架重的场景会引入依赖重放、工程组织、agent 脚手架这些变量，证书机制能不能原样搬过去是问号。二是纯感知类缺陷（审美、品牌调性、无障碍细节）没有可执行证书，只能退回 VLM 代理，把噪声原样继承回来——论文对此很坦诚，但也意味着"好看的页面"这件事这个框架管不了。三是深度 ≥5 只用 5K 样本就追平全量数据，这既可以解读为信号密度高，也可以解读为全量池里有大量浅层样本的边际价值接近于零——32,800 条里到底有多少是真正必要的，论文没正面回答。

跟同期工作的位置：HTMLCure 是并发工作，提供了 HTMLBench-400 测试台，WebWorld 只拿它做留出评测，两者不冲突。跟 MLLM-as-judge 那一路（用更强的视觉裁判）相比，WebWorld 的立场是裁判这条路走不通——裁判继承了提议者的模态偏差，审计热力图里那 23% 就是证据。我倾向同意这个判断：裁判可以升级，但"自己人"的结构不变，偏差就不会消失。

💡 收尾

如果你在做 agent 自改进的数据管线，这篇论文给了一个可以直接抄的设计原则：别让提议者给自己的产出签字，找一个它骗不了的对手方来签。浏览器之于网页代码是这个对手方，编译器之于代码、求解器之于数学、模拟器之于控制，都是同一个道理。真正的门槛从来不在"生成更好的候选"，在于准入规则——0.4 对 4.8 的差距，就是签字权的价值。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我