Browser Use 新增完成检查，AI 网页任务可按条件验收

2026 年 11 月 14 日，开源浏览器自动化工具 Browser Use 发布 1.0.5，为执行过步骤的任务默认增加一次模型完成检查。开发 AI 网页助手的团队，可以读取结构化判断、失败原因和网站使用经验，进一步核对任务是否达到要求。本文说明检查依据、自定义验收条件，以及这次额外调用带来的费用和证据范围。官方发布记录

[配图建议：网页最终状态与三项验收条件一起被核对 + 紫色纸纹的平面编辑插画]

执行结束后，再对照任务检查结果

设想让 AI 在一个测试后台创建活动草稿，要求名称、日期和可见范围都符合指定条件。执行过程可能经过填写表单、修正格式、点击保存。应用要向用户交付结果，还需要确认保存后的页面是否显示了正确内容，以及草稿状态是否成立。

1.0.5 的检查器会使用执行任务的同一个模型，结合原始任务与执行记录，生成 result.judgement。其中包括 success、failure_reason、description，以及提示注入、网站拦截或验证码相关标记，gotchas 则记录网站使用经验。它给产品提供了可进一步处理的结果字段。新增检查器 PR

这次正式版本发表于北京时间 11 月 14 日 16:24。基础检查能力与截图支持在同日先后合并，1.0.5 将它们一起纳入发布。本文讨论 Python 开源库的这项更新，具体应用升级时间由团队自己的部署流程决定。版本发布记录 发布集成 PR

完成条件写得越具体，检查结果越容易核对。对于活动草稿，可以要求“保存后页面显示指定日期，状态为草稿，列表中能找到该记录”。对资料收集任务，可以要求每项结论带来源链接。这样的条件也便于人工抽查和建立后续回归样本。

[配图建议：填写表单、保存结果、按条件检查三个步骤 + 清楚的流程信息图]

检查器能看到什么，决定它能判断什么

截图支持为检查增加了页面证据。固定版本实现会从运行记录中选择最近的不同截图，并结合最终页面截图，最多保留四张，按时间顺序交给模型。最终页面在浏览器停止前获取，受视觉配置、页面可见性和抓取超时等条件影响。截图支持 PR 固定版本截图选择实现

文字记录也经过长度控制。源码将整段 trace 限制在 12 万字符，过长时保留开头和末尾，任务与自定义检查上下文另有长度上限。应用设计证据记录时，应把最终结果和关键反馈写清楚，让检查器能够联系任务要求与实际交付。固定版本检查器源码

例如，表单提交后出现成功提示，稍后列表却显示旧日期。要判断日期是否保存，测试流程可以安排一次返回列表的读取，将保存后状态记录下来。若任务是下载报表，则继续核对文件名称、内容和目标时间范围。这里的证据组织属于应用层设计，需要结合业务定义。

将关键交付状态放进可观察的页面或记录中。浏览器侧看到的确认信息、业务系统中的记录状态和下载文件内容，可以分别提供证据。团队可以在试点时逐项查看检查器得到的输入，确认它确实接触到了判断所需的信息。

[配图建议：原始任务、操作记录和最终页面共同支持判断 + 克制的技术结构示意图]

用自己的条件配置检查，并处理待复核状态

开发者可以通过 judge_context 传入验收条件。下面是已有模型与浏览器配置的接入片段，假设 my_llm 和 my_browser 已在项目中准备好，目标为团队可测试的后台。

from browser_use import Agent

agent = Agent(
    "在测试后台创建一份活动草稿",
    llm=my_llm,
    browser=my_browser,
    judge_context=(
        "保存后的详情页应显示指定名称和日期，"
        "状态为草稿，并能在列表中找到同一条记录。"
    ),
)
result = agent.run_sync()
print(result.judgement)

这些参数与同步调用入口可在 1.0.5 的 README 中核对。实际项目应把“指定名称和日期”换成自己的明确值，并让测试任务覆盖保存后的读取过程。固定版本使用说明

消费检查结果时，可以为不同情况设置对应的应用状态。官方源码与测试覆盖了检查请求失败后 judgement 为 None 的情形，项目需要保留处理这个值的分支。检查器回归用例

检查结果与业务动作之间的衔接由应用决定。团队可以先把结果接入任务记录，观察误判类型和人工复核成本，再逐步用于更具体的交付流程。这样便于在证据不足时保留清楚的处理路径。

[配图建议：成功、需处理和待复核三种任务状态 + 简洁产品流程示意图]

记录网站经验，同时核算额外调用

gotchas 用来提炼网站规则，例如字段接受的日期格式、网站返回的限流提示，或完成任务需要的页面顺序。1.0.5 会在成功任务中也记录这些经验，便于团队了解一次任务经历过哪些网站反馈。截图与网站经验更新

作者用 13 次真实会话、每次三次评判来检查这部分行为，观察点包括网站拒绝输入和拦截时是否留下经验。该实验范围适合说明记录行为，读者自己的任务正确率仍需用实际网站与人工答案评估。本文采用作者发布的验证说明作为证据。作者验证记录

额外评判通常增加一次低推理强度的同模型调用，其 token 与费用会并入 result.usage 和 result.cost_usd。遇到模型以图片相关的 4xx 错误拒收截图时，代码会再进行一次纯文字判断。应用还可以用 judge=False 关闭这项检查，根据任务价值安排使用范围。固定版本调用与降级逻辑 费用统计测试

截图会按原样发送给所选模型，文字则按项目的敏感数据配置做处理。试点时可以使用获准测试的页面和数据，确认模型接收范围，并把执行、评判、人工复核的时间与费用放进同一份任务记录。固定版本使用说明

先比较整条交付流程的成本与正确性。适合优先评估的，是已经使用 Browser Use、需要批量核对网页任务的团队。小规模试点可以保留几项会触发表单错误或缺少最终状态的任务，检查条件是否写清、证据是否充分，再决定部署方式。

[配图建议：网站规则记录与任务调用费用一起复盘 + 平面技术工作台插画]

今天先写清一条网页任务的完成条件

今天可以选一条可重复的测试任务，写下三个能从页面或产物核对的完成条件，再检查 1.0.5 返回的判断、原因与经验。已有自动化流程的团队先保存这组记录，评估人工复核负担与额外费用，再确定哪些任务适合启用。

你的网页助手最常遇到的是字段格式被拒绝、保存后状态不一致，还是交付文件内容有误？这些实例可以直接用来设计第一组检查条件。

核查时间为北京时间 2026 年 11 月 15 日。本文依据官方发布、PR、固定版本源码与回归用例阅读进行核查，代码为接入片段，业务场景与处理建议用于说明应用方法，封面为原创 AI 概念插画。

[配图建议：一条任务与三项可验证条件对应排列 + 留白充足的编辑式笔记插画]