arXiv cs.AI 近期出现的 Discriminative World Models for Web Agents 很适合放在今天的论文速读里。它的主题不是再造一个浏览器 agent，而是回答一个更底层的问题：agent 在网页里行动前，是否应该先知道“这个动作之后世界会不会变成合理状态”？相关选题来自 arXiv recent、Hugging Face Daily Papers、Hacker News 对 agent 自动化的持续讨论，以及 Reddit r/MachineLearning 对长流程 agent 可靠性的关注。
浏览器 agent 这两年进展很快。模型能读页面、看截图、点按钮、填表单、调用浏览器工具。但只要任务超过三五步，失败率仍然很高。原因很直接：网页环境是动态的，页面会局部刷新，按钮文案会变化，弹窗会遮挡，登录态会过期，错误路径还会伪装成正常页面。
人类操作网页时，并不是看到按钮就点。我们会预判：点“结账”后应该进入支付页，点“筛选”后列表应该变化，点“保存”后应该出现成功提示。如果结果不符合预期，我们会退回、刷新或换路径。Web Agent 也需要这种世界模型。
生成式世界模型的成本
一种直觉方案是让模型生成未来页面：给定当前截图和动作，预测下一屏会长什么样。这听起来优雅，但工程成本很高。网页状态太复杂，DOM、视觉布局、异步请求、会话状态都在变化。完整生成未来页面不仅难训练，也难和真实浏览器状态对齐。
更重要的是，agent 很多时候不需要完整未来。它只需要知道某个候选动作是否靠谱。比如当前任务是“下载最近一个月发票”，候选动作有三个：
1. 点击 Billing
2. 点击 Delete account
3. 点击 Help center系统不需要生成三个动作后的完整网页，只需要判断第一个动作更可能通向目标，第二个动作高风险，第三个动作相关性低。这就是判别式世界模型的直觉。
DWM 的核心思想
DWM 可以理解为状态转移评分器。输入当前状态、候选动作和候选下一状态，输出这个转移是否合理、是否推进目标、是否可能是错误路径。它不是替代行动模型，而是给行动模型加一个“执行前审查”和“执行后验收”。
对 Web Agent 来说，状态可以来自三类信息：
visual_state: 页面截图或视觉摘要
dom_state: DOM 结构、可点击元素、表单字段
task_state: 用户目标、已完成步骤、历史动作动作可以是点击、输入、滚动、选择、下载、导航。候选下一状态可以来自真实执行后的观察，也可以来自检索到的历史轨迹，甚至可以来自另一个模型的预测。DWM 的关键不是生成，而是判断这些状态转移是否可信。
为什么这比纯 LLM 规划更稳
纯 LLM 规划常见问题是“语言上合理，网页上不成立”。模型会说“点击 Export 按钮”，但页面上按钮可能叫 Download CSV。模型会计划“打开账户设置”，但当前账号权限里根本没有设置入口。它还会在错误页面继续编故事，因为语言上下文仍然看起来连贯。
DWM 的价值是把规划拉回环境。它关心动作和观察之间的对应关系。执行前，它可以给候选动作排序；执行后，它可以判断结果是否符合预期。如果不符合，agent 应该停止继续推进，而不是在错误页面上继续累积错误。
这对长流程任务尤其重要。一个 12 步网页任务，只要第 3 步进入了错误分支，后续 9 步再聪明也没用。世界模型的价值不是让每一步都更花哨，而是尽早发现偏航。
一个工程化架构
实际落地时，不必一开始训练完整 DWM。可以先把它做成一个转移评分接口：
type BrowserState = {
url: string;
title: string;
visibleText: string[];
interactiveElements: Array<{
id: string;
role: string;
label: string;
}>;
};
type CandidateAction = {
kind: "click" | "type" | "scroll" | "navigate";
target?: string;
value?: string;
};
type TransitionScore = {
progress: number;
risk: number;
confidence: number;
reason: string;
};在每一步，planner 先产生多个动作，DWM scorer 给动作打分，再由 executor 执行最佳动作。执行后，observer 把新状态交给 scorer，判断是否达到预期。
planner -> candidate actions
scorer -> rank actions
executor -> browser action
observer -> next state
scorer -> accept or rollback这条链路比“模型直接下一步”多了一层，但会显著改善可调试性。日志里不再只有“点击失败”，而是有候选动作、风险分、预期状态和实际状态。
训练数据从哪里来
DWM 的训练难点在轨迹。你需要大量“状态、动作、下一状态、是否成功”的样本。好消息是浏览器 agent 天然会产生这类数据。每次执行任务时都可以记录：
{
"goal": "download latest invoice",
"state_url": "/billing/invoices",
"action": "click button Download",
"next_state_title": "Invoices",
"progress_label": "success",
"risk_label": "low"
}这里的 URL 只是示意，生产系统不要把真实客户链接和敏感内容直接放进训练集。更合理的方式是保留抽象后的页面结构、元素角色和任务标签，并对敏感字段做哈希或替换。
早期没有训练数据时，也可以用规则和 LLM judge 混合。规则负责明显风险，比如删除、付款、邀请外部账号。LLM judge 负责语义判断，比如某个按钮是否通向发票页面。等日志积累起来，再训练轻量分类器。
对评测的启发
浏览器 agent 的评测不能只看最终成功率。最终成功率重要，但太粗。DWM 这类论文提醒我们，应该增加三类中间指标。
第一是动作有效率。候选动作是否真实存在，是否能被浏览器执行。第二是转移一致性。执行后的页面是否符合动作语义。第三是回退质量。发现错误后，agent 是否能停止、恢复或请求人工确认。
这些指标比最终成功率更适合工程改进。最终成功率从 42% 到 45%，你很难知道该改 prompt、工具还是模型。转移一致性从 70% 到 82%，说明 agent 对网页状态的理解真的变好了。
和安全的关系
DWM 还可以作为安全层。Web Agent 最危险的不是读页面，而是执行写操作。发送邮件、提交表单、删除文件、下单付款都应该经过额外判别。一个转移评分器可以在执行前识别“这个动作可能产生不可逆后果”，在执行后检查“是否进入确认页而不是最终提交页”。
但要注意，DWM 不是权限系统。它只能提供风险信号，不能替代工具级权限、人工审批和审计日志。生产系统应该让 DWM 参与决策，但最终放行仍由策略层控制。
工程结论
Discriminative World Models for Web Agents 的最大价值，是把 Web Agent 从“下一步动作生成器”推进到“状态转移系统”。浏览器自动化不是文本补全任务，而是和动态环境交互。只会生成动作的 agent 很容易在错误路径上越走越远，拥有判别式世界模型的 agent 至少能知道自己是否仍在正确轨道上。
开发者可以从三个小改动开始：记录每步状态转移，把候选动作从一个扩展到多个，给高风险动作加转移评分。即使没有训练专门模型，这套结构也会让浏览器 agent 更容易复盘、更容易迭代，也更适合进入真实业务流程。