Web 自动化 Agent 实战：browser-use 的能力边界与最佳实践

网页自动化是 Agent 最容易“看起来简单、做起来困难”的场景之一。

browser-use 通过把页面理解和动作执行结合起来，显著降低了开发门槛，但生产落地仍然需要工程约束。

适合 browser-use 的任务

信息采集（价格、公告、状态）
后台流程自动化（查询、录入、导出）
规则明确的表单操作

不适合直接自动化的任务

复杂图形验证码
高频反爬强对抗站点
高风险操作（支付、删除、审批）

这些任务建议“人机协同”，而不是全自动。

稳定执行的四个关键点

1. 明确页面状态而不是盲点点击

在执行动作前，先检查关键元素是否出现，减少 race condition。

2. 提供“失败后重规划”能力

页面结构变化是常态。失败后应让 Agent 重新分析页面并选择替代路径，而不是直接报错退出。

3. 任务拆分为短步骤

把长流程切成可恢复小步骤，每步产出状态快照，失败可断点续跑。

4. 高风险动作强制确认

对“提交、删除、发布”等动作，增加人工确认 gate。

监控指标建议

任务成功率
平均执行时长
单步骤失败分布
重试后成功率

如果把这些指标接入可观测平台，你会更快定位是“页面变化”还是“策略错误”。

总结

browser-use 在 Web 自动化 Agent 场景非常强，但它不是魔法。通过任务分层、确认机制与观测闭环，才能把 demo 变成可用生产能力。

建议先从低风险、结构稳定的内部后台流程切入，逐步扩大自动化边界。

常见陷阱与避坑指南

实际落地 browser-use 的团队，最常踩的坑不是“能不能点”，而是“点了之后没意识到点错了”。下面六个陷阱按发生频率从高到低排列，每条都给出对应的工程对策。

陷阱一：把整段操作当一个原子任务下发给 Agent。 表面上 prompt 更简洁，实际上让 Agent 一次性规划 30 步以上动作时，规划质量会断崖式下降。正确做法是把任务拆成 3-7 步的子任务，子任务之间通过状态对象（JSON / 简单 dataclass）传递上下文，每步执行后立即检查关键 DOM 状态。

陷阱二：用 CSS 选择器而不是语义化定位。 站点改版时 class 名字会变，但 button 的 aria-label、input 的 name 属性、表单的 for 关系相对稳定。browser-use 支持基于视觉模型识别元素，但语义选择器依然是首选——它能让重规划阶段的判断更准。

陷阱三：忽略登录态与会话过期。 Cookie 失效是导致 60%+ 任务在第 2 步失败的根因。在任务开始时主动检查登录态；遇到 401/403 不要重试，先重新登录或换账号。

陷阱四：把“人机协同”做成“半自动按键助手”。 真正可用的人机协同是把决策点显式标出——比如“检测到金额 > 5000 元的订单，等待人工确认”而不是“每个动作前弹个确认框”。前者降干扰，后者让用户烦到关掉自动化。

陷阱五：不做步骤级重试。 一次任务执行 50 步，第 30 步失败重头跑是灾难。引入步骤级 checkpoint，至少能让你从第 30 步附近的最近稳定状态恢复，而不是浪费 4 分钟重跑 28 步。

陷阱六：错误地把反爬对抗交给 Agent。 Cloudflare、Akamai、极验这类挑战，单纯靠 Agent 视觉识别 + 点击的方案不稳定，且会污染后续 IP 信誉。识别到挑战时直接中断任务、报告人工，比让 Agent 死磕要可靠得多。

选型决策表

在“用 browser-use / Playwright 脚本 / Selenium / 让人类操作”之间选择时，可以按下面这个表快速判断：

页面结构稳定 + 任务规则明确 + 需要 LLM 理解自然语言 → browser-use 是首选
页面高频改版 + 反爬弱 → 自建 Playwright 脚本，比 Agent 更可控
页面高频改版 + 反爬强 → 商业 RPA 工具（UiPath、Automation Anywhere），它们有 IP 池和人机模拟
任务需要真人判断（设计审查、合规检查） → 不要自动化，把 prompt 优化成“人机协同 checklist”
任务在 5 步以内 → 直接 Playwright 脚本，Agent 反而是 overhead

投入产出比提醒

根据经验，一个中等复杂度的 Web 自动化任务（15-30 步、跨 3-5 个页面），从原型到稳定运行的工程投入是：

写 Playwright 脚本：1-2 天（含调试）
写 browser-use 脚本：0.5-1 天
让 browser-use 稳定到 90%+ 成功率：再加 2-4 天

最后这一步最容易被低估。多数团队栽在“原型跑通就上线”，结果一周后成功率跌到 60% 以下才开始补稳定性，那时回滚成本远高于一开始就投入稳定性工程。