为什么 GUI Agent 离线动作准确率高，闭环任务成功率仍可能很低？

核心回答

browser-use 用 Python 将浏览器状态、模型决策和工具执行组成循环：每轮读取页面截图、DOM 等状态，结合前一轮动作结果生成下一步，再执行动作并把结果送回后续观察。模型选对一个元素，并不代表整批动作仍然适用于执行后的页面，更不代表任务已经完成。

以一次报价采集为例，模型根据当前页面规划“输入产品型号、筛选、打开报价详情”；筛选或打开详情可能导致导航或切换活动页面，原页面中的元素索引随之不再适用。此时应先确认目标供应商和产品规格，再决定下一步。

动作批次为什么要提前停止

multi_act() 支持一轮模型输出多个动作，但会在两类情况下停止剩余队列：

• 动作声明会改变页面。 导航、返回、切换页面等动作标有 terminates_sequence=True，执行后不再继续这一批后续动作。
• 执行后发现页面上下文改变。 比较动作前后的 URL 和 agent_focus_target_id；URL 或活动页面目标改变，就停止剩余动作。这里的焦点指浏览器活动页面目标，不是某个输入框获得键盘焦点。

此外，动作返回错误、任务结束或出现执行异常，也会结束当前批次；此前已经得到的部分结果会保留。具体机制见批次执行与页面变化保护。

停止批次意味着剩余动作没有执行。进入后续步骤时，Agent 根据新状态与已有结果重新决策，代码没有承诺把被截断的整批动作原样自动重试。当前实现也没有“页面新增任意元素就停止批次”的判断；新元素的 is_new 标记用于后续页面描述，不能替代批次中的变化检测。

因此，弹窗或局部重绘即使没有改变 URL、活动页面目标，也可能使后续动作依据过期。批量动作减少模型往返，但会扩大两次观察之间的状态变化窗口；需要按任务中页面变化的频率选择动作批次，而非只追求一次生成更多操作。

错误反馈能帮助继续，不能保证恢复成功

每轮 step() 先准备浏览器状态和前步结果，再请求模型、执行动作和后处理。工具超时或异常会转成 ActionResult，供后续决策使用；普通动作异常会保留先前部分结果，连接异常则交给外层处理。循环仍受步数、超时和失败条件约束，不会无限尝试。见观察与执行循环。

工具结果还需要按含义判断。例如点击索引已失效时，工具会返回“页面可能已经改变，请刷新状态”的内容提示，并不总是设置 error。因此不能用“没有异常”统计所有点击成功；更应该核对所需页面状态是否发生变化。超时也不保证前一个动作没有产生任何副作用，决定重试前还需观察结果。

完成声明怎样与真实结果核对

当前默认启用的 judge 会查看任务、轨迹和截图，把评判附到结果中；它不会覆盖 Agent 自报的 success。发现 done 后，执行循环运行 judge 并结束，并没有“judge 判失败就自动重做”的分支。见完成后的 judge 调用与评判结果的作用。

评测时应分别保存 Agent 自报、judge 判断和业务验收结果。例如确认报价页中的目标产品、价格字段、币种与附件内容，而不是看到“点击成功”或 done 就计为任务成功。对同一组任务再比较动作批次、等待策略和错误恢复后的成功率，才能判断问题主要在模型定位能力，还是执行循环与结果确认。