界面上没有任何提示，后台账本却已经记录了两次写入。
在一张用于受控测试的模拟发票审核页面上，测试工程师向自动化程序下达指令，要求使用具备修改权限的测试账号，将指定发票 INV-2042 的审核备注更新为 Reviewed 并点击保存一次，同时保持相邻发票原状。程序在执行过程中未查询后台数据库。
首次点击保存后，由于页面没有弹出任何成功确认提示，Browser-use 自动化代理在等待三十秒后再次点击了保存按钮，最终在 90.6 秒因等待回显超时退出。测试结束后的后台数据库记录证实，该发票被写入了两次，两次点击间隔 30.8 秒。
面对同一项网页表单任务，开发者通常有三种控制方式。第一种是 Playwright 代表的固定脚本，由代码编排全部操作步骤；第二种是 Stagehand 代表的局部语义识别，主干流程由代码编排，保存按钮定位固定调用模型语义接口；第三种是 Browser-use 代表的全任务自主代理，由模型接收自然语言目标后自主规划多步操作。
本次测试在本地受控环境中进行。工具版本锁定为 playwright-core 1.63.0、@browserbase/stagehand 3.7.3 与 browser-use 0.13.10，后两者底模统一使用豆包 Seed 2.0 Pro。测试以目标发票备注更新正确、后台恰好写入一次、相邻发票数据保持原状为通过标准。
页面变化对三种实现的影响
三款工具在四类场景下各进行三次独立运行，共计完成 36 次测试。
| 工具与实现方式 | 稳定页面 | 延迟渲染（1.2秒） | 按钮更名 | 静默无确认 |
|---|---|---|---|---|
| Playwright（固定文本选择器） | 业务通过 3/3（正常结束） | 业务通过 3/3（正常结束） | 业务通过 0/3（超时停机） | 业务通过 3/3；程序超时 |
| Stagehand（局部语义定位） | 业务通过 3/3（正常结束） | 业务通过 3/3（正常结束） | 业务通过 3/3（正常结束） | 业务通过 3/3；程序超时 |
| Browser-use（全任务自主代理） | 业务通过 3/3（正常结束） | 业务通过 3/3；程序超时 | 业务通过 3/3（正常结束） | 业务通过 2/3；程序超时* |
*说明（分数表示三次运行的业务验收通过数。Browser-use 在静默场景中三次均因等待回显超时，其中一次触发二次点击导致重复写入未通过验收，另两次保持单次写入通过验收）
在更名测试中，保存按钮的文案从原本的 Save review 变更为了 Record review。Playwright 使用固定选择器 getByRole('button', { name: 'Save review' })，由于文本不匹配，在等待 20 秒后抛出超时异常直接停机；Stagehand 则传入语义指令 Find the button that saves the review note for invoice INV-2042，由模型解析页面上下文后定位到已更名的按钮并完成点击。
图 1 展示了三款工具在本次实测中的模型介入位置。Playwright 全流程由固定代码驱动；Stagehand 仅在定位保存按钮这一个环节调用模型；Browser-use 则由模型规划每一步动作。
| 工具与实现方式 | 正常完成耗时* | 单次运行 Token 消耗（12次统计）* | 适用场景与主要代价 |
|---|---|---|---|
| Playwright（固定文本选择器） | 0.7~2.6秒（6次） | 0 Token | 适合界面固定流程；代价是文本变动时需人工更新选择器 |
| Stagehand（局部语义定位） | 8.8~17.1秒（9次） | 约 1.3千 Token（单次 1295~1385） | 适合流程确定但文案常改页面；代价是单次运行承担约 1.3千 Token 与接口延迟 |
| Browser-use（全任务自主代理） | 66.2~83.6秒（6次） | 2.5万~3.4万 Token（单次最高 34,179） | 适用场景在本次测试中尚未验证；代价是单次运行消耗万级 Token，三次静默测试中的一次出现重复点击 |
*说明（耗时统计仅纳入同时满足正常结束与通过业务验收的样本。Playwright 排除更名停机与静默超时共 6 次。Stagehand 排除静默超时 3 次。Browser-use 排除延迟超时与静默超时共 6 次。各工具纳入样本不同，不能直接据此比较速度倍数。Token 统计覆盖全部 12 次运行，完整采集框架发起的全部模型调用用量，包含输入、输出与内部推理）
实测结果表明，确定性流程优先使用固定选择器；若面对文案变动且缺乏稳定测试属性（如 data-testid）的页面，定位失败后再调用模型作为后备是更经济的设想（该策略本次尚未测试，实测中 Stagehand 无论更名与否均每次调用了模型）。而在流程明确的表单中，直接使用全任务代理耗时与 Token 成本均显著增加，且在本次受控测试中出现了一次重复点击。
无回显表单的防范与核验
回到开头的实测案例。那次相隔 30.8 秒的重复写入之所以发生，是因为代理在首次点击后没有看到界面回显，自主触发了第二次点击。要在工程上阻断这类错误，关键在于控制提交时机与核验实际结果。
首先是在点击发出后限制动作。调度程序应当对同一次修改请求建立点击配额，首次点击后锁定后续提交命令，直接从源头阻断 30.8 秒后的第二次点击。对于自研系统，请求中应附带业务幂等键（如 idempotency_key）由服务端实现原子去重。
其次是在等待超时后核验真实状态。保存等待超时不能证明后台未写入，数据可能已经落库成功，重试前必须独立核对业务记录。 在本次实验中，写入次数核验依赖模拟后端的独立写入账本；在实际生产中，也可以通过业务流水、查询接口或提交凭证进行确认。若确认发票 INV-2042 恰好写入一次且备注正确，直接判定业务通过；若结果未明，安全重试必须严格复用首次请求的同一幂等键；若缺乏幂等保障且无法查询凭证，则必须停止自动操作并转交人工核实。上述措施属于针对本次案例的工程建议，尚未在测试矩阵中进行回测验证。
