很多人第一次跑 browser-use 是这样的：本地 Demo 顺手得不行，一放到真实站点就开始飘——元素找不到、点错位置、循环打转、最后悄悄失败还返回一段看着挺像那么回事的结论。问题往往不在模型本身，而在任务描述、步骤边界和验收方式没设计好。这篇按工程落地的顺序，讲清从写第一条任务到接进日常测试该做哪些事，每一步都给出可执行动作和判断标准，不涉及具体跑分和版本对比。
很多人第一次跑 browser-use 是这样的：本地 Demo 顺手得不行，一放到真实站点就开始飘——元素找不到、点错位置、循环打转、最后悄悄失败还返回一段看着挺像那么回事的结论。问题往往不在模型本身，而在任务描述、步骤边界和验收方式没设计好。
下面按工程落地的顺序讲：从写第一条任务，到加上边界，到挂了怎么查，再到接进日常测试。每一步都给可执行动作和判断标准，不涉及具体跑分和版本对比，数字类的信息一律到站内页面核对当时的情况。
先把「任务」写成可验收的样子
- 一条任务只说一件事：把「登录后台、导出报表、核对数字、发通知」拆成四个独立任务，串行跑，任一环节失败都能单独重试，别指望一个提示词全干完
- 描述里写死可判断的终点，比如「页面上出现订单号文本」「表格行数大于 0」，而不是「检查一下订单」，否则 Agent 只能自己编一个完成标准
- 把已知的固定信息（入口地址、账号从环境变量读、必填筛选条件）放在任务外层，模型只负责现场判断的部分，减少它自由发挥的空间
- 不确定时先跑「只观察不点击」的版本：让它把当前页面元素和状态描述出来，确认它看得懂这一页，再放开操作
判断任务拆得够不够细，有个土办法：把任务念给一个没看过你系统的人听，问他「你怎么知道这步做完了」。答不上来的那一步，就是描述里缺验收点的地方。补上验收点再跑，比你调参有效率得多。
三种终点写法对照
| 写法 | 问题 | 改成什么 |
|---|---|---|
| 检查一下订单状态 | 模型自己编完成标准，每次都不同 | 页面订单状态区域出现「已发货」文本 |
| 把数据弄出来 | 执行路径无限多，容易点错 | 导出按钮点击后，出现下载完成提示且文件行数大于 0 |
| 登录并操作 | 中间任何一步失败整条任务废掉 | 拆成登录、操作两个任务，登录失败单独重试 |
跑起来之前先卡边界：步数、超时、白名单
- 设步数上限和整体超时先手工跑一遍正常流程，数它用了多少步，上限就压到两倍左右。超了直接判失败并保留截图，比让它无限重试划算，也避免它在页面上乱点。
- 划站点和动作范围列出允许进入的域名，以及哪些动作必须人工确认：提交表单、删除数据、付款这类写操作单独走审批，不要和只读任务混在一个批次里跑。
- 为每步留痕每一步记录截图、当前地址、模型这一步的意图、耗时。排查时先看从哪一步开始偏，没有留痕就只能靠猜，而且截图是事后复盘的唯一证据。
- 把抖动当正常分支网络抖动和登录态过期写清楚对应动作：重试一次、重新登录、还是直接退出。当成异常崩掉，会让整条流水线看起来成功率很低，实际是处理策略没写。
边界设完之后，建议拿一条最稳的只读任务连续跑几次，确认基线成功率的量级。具体跑几次、看什么指标，到 /tools/verify 里按当时的说明做一遍，别凭感觉估。
跑挂了按这个顺序查，不要先怀疑模型
- 先看页面拿到的到底是什么：很多失败是页面结构变了、元素在 iframe 里、或者加载需要滚动才出现，Agent 看到的东西和你浏览器里看到的根本不是一回事
- 再看任务描述有没有歧义：把同一条任务重复跑几次，如果失败点每次都不一样，多半是描述太模糊或者页面有随机内容，不是模型不行
- 然后看动作粒度：连续多步小点击容易累积偏差，试着把「点 A、再点 B、再填 C」合并成一步语义动作，或者反过来拆得更细，两种都试一次对比成功率
- 最后才调模型和参数。到 /models 对照当前可选模型的能力定位，别用最便宜的档位跑需要多点判断的流程
| 现象 | 优先怀疑 | 先做的动作 |
|---|---|---|
| 元素找不到 | 页面结构和 Agent 看到的不一致 | 打印当前页面摘要和截图，人工比对 |
| 每次卡在不同地方 | 任务描述有歧义或页面内容随机 | 重复跑同一条任务，看失败点是否漂移 |
| 前半段顺畅后半段崩 | 动作粒度太细，误差累积 | 把多步点击合并成一个语义动作再试 |
| 成功率突然整体下滑 | 站点改版或上游接口不稳 | 先验证依赖接口，再跑浏览器任务 |
排查时记住一个顺序：页面事实、任务描述、动作粒度、模型参数。反过来先换模型，往往把真正的问题盖住，下次换个模型又复现，白花时间。
接进日常测试流程的做法
browser-use 的定位是补位，不是替代。它适合「人工写脚本太贵、又必须定期跑」的那类检查，比如定期确认关键页面还能正常走通。纯接口断言、纯数据校验不要用它，成本高还不稳，用普通请求断言更快更准。
- 先验证依赖链路跑浏览器任务之前，先确认它依赖的接口是通的。接口本身不稳的时候，浏览器层的失败会混在一起，让你分不清是谁的问题。到 /tools/verify 把链路过一遍再开始。
- 结果输出成结构化字段至少包含任务名、成功与否、卡在哪一步、截图路径。直接进你现有的测试报告，不要去解析模型的自然语言总结，那段文字只适合人看。
- 盯长期成功率用 /tools/quality-monitor 这类监控看每条任务随时间的成功率。某条任务从某个时间点开始往下掉，通常是站点改版，而不是模型变差。
- 控制跑的频率不是每条任务都要每天跑。改动频繁的页面跑勤一点，稳定的流程按周跑。频率本身也是成本，先想清楚「跑了发现问题我改不改」，不改就别跑。
如果你的浏览器任务要访问的站点本身是企业内部系统或者依赖第三方服务，先确认访问策略和账号有效期，这部分最容易在半夜的定时任务里突然失效。具体站点和方案怎么选，到 /sites 看当时的收录情况和你自己的网络条件对不对得上。
下一步把上面这套边界和验收点先套到你自己的一条任务上跑通，再考虑接进流水线；需要挑工具和监控方案时，去工具目录和监控页按当时的说明核对。→常见问题
browser-use 能不能替代现有的自动化测试脚本？
看场景。流程固定、断言明确的回归测试，传统脚本更快更稳也更便宜；页面结构经常改、需要现场判断下一步点哪的探索型检查，才是它的主场。务实做法是两者并存，把浏览器 Agent 限制在少数几条人工维护成本最高的用例上。
一条任务反复失败，怎么判断是模型问题还是页面问题？
先手动走一遍同样的流程，确认页面本身没问题、登录态没过期。然后跑一次只观察不点击的版本，看它描述出来的页面内容和你看到的是否一致。一致说明是描述或动作设计的问题，不一致说明它没拿到正确的页面状态，先解决加载和元素定位。
跑一次要花不少 token，怎么把成本压下来？
三个方向：任务拆小减少无关上下文、限制步数避免无限重试、把只读的固定检查交给普通脚本。具体单价换算到 /tools/model-cost-calculator 自己算，别拍脑袋估。判断标准是单条任务成本能不能接受，而不是单次调用便宜。
