浏览器自动化代理

它解决什么问题

大语言模型的决策能力需要真实环境反馈才能落地。在浏览器场景中，仅靠 HTTP 客户端请求会遇到三类现实阻力：

• 现代站点依赖客户端 JavaScript 渲染，DOM 结构在导航后才逐步稳定，纯接口调用拿不到最终页面内容
• 登录流程、验证码、动态弹窗、会话过期等交互断点会让自动化脚本中途失效
• 传统自动化方案（如固定 Playwright 脚本）规则写死，无法适应页面布局变化和多步任务的分支判断

结果是：开发者要么手动录制回放，要么花费大量精力维护脆弱脚本。Agent 需要像人一样看到页面、理解上下文、做出连续动作，并在中断后能恢复。

它如何工作

browser-use 把这个循环封装成可调用的代理能力，核心由四个模块组成：

• 本地执行引擎：通过 Playwright 驱动真实浏览器内核，解析渲染后的 DOM 与可访问性树，把页面状态转成 LLM 可读的结构化上下文
• 动作规划层：模型根据目标拆解为 click、type、scroll、extract 等原子动作，执行器负责映射到浏览器 API 并校验结果
• 自定义工具接口：允许注入项目专属函数（如批量导出、表单校验），代理在推理中按需调用并接收结构化返回
• 持久会话 CLI：保留浏览器 profile、cookie 和本地存储，任务中断后可恢复同一上下文，避免重复登录或丢失中间状态

运行时代理以「观察—推理—动作—反思」闭环推进：读取当前页面快照，由模型判断下一步，执行后捕获新状态并校验是否偏离预期。整个过程可本地调试，也可切换到云浏览器执行。

适用边界与注意点

• 能力集中在网页环境的自动化操作；如果目标系统有稳定公开 API，直接集成通常更可靠
• 对重度依赖 Canvas 或非标准交互的站点，DOM 提取可能失真，需要额外适配
• 框架本身不承诺绕过反自动化机制；遇到人机校验或访问控制时需人工介入
• 不要把它当作通用后端执行器；浏览器会话的开销和状态复杂度远高于接口调用
• 由于无法自动提取源码级安装说明，在敏感工作流中运行前请审查上游项目，确认依赖和权限范围符合预期