AI 原生浏览器自动化正在重塑开发者构建与 Web 交互的智能体（agents）的方式。通过让大语言模型（LLMs）对页面进行推理，而不是依赖脆弱的 CSS 选择器，新的技术栈——Browser-Use、Stagehand、Steel 和 Playwright MCP——能够在网站发生变化时保持脚本持续运行。
为什么 AI 原生自动化至关重要
传统工具通过静态选择器定位元素来抓取页面。一旦页面设计变更，脚本就会失效，迫使开发者进行昂贵的重写。而由 LLM 驱动的智能体能够阅读页面、理解其用途并决定点击哪个按钮，因此能够应对布局变动。
技术栈的四个组成部分
| 工具 | 主要语言 | 适用场景 |
|---|---|---|
| Browser-Use | Python | 需要处理多个标签页并进行深度推理的智能体 |
| Stagehand | TypeScript | 希望通过模式验证 (Zod) 实现可靠提取的团队 |
| Steel | 托管云服务 | 可扩展的远程浏览器、代理轮换、持久化会话 |
| Playwright MCP | 协议服务器 | 需要直接访问浏览器的桌面助手（例如 Claude Code、Cursor） |
每个组件解决不同的问题。Browser-Use 紧密运行推理循环。Stagehand 提供了一个类型化的 SDK，将原始页面数据转换为结构化对象。Steel 抽象了硬件，为你提供了一组可以按需启动的浏览器集群。Playwright MCP 将浏览器操作转换为任何 LLM 客户端都可以调用的协议。
它们是如何协同工作的
将 AI 智能体想象成一座三层建筑：
- Agent runtime（智能体运行时） – 大脑。Browser-Use 决定“下一步做什么”并调用工具。
- Automation SDK（自动化 SDK） – 手部。Stagehand 提供原语（点击、输入、提取），并返回符合 Zod 模式的数据，从而减少下游错误。
- Cloud infrastructure（云基础设施） – 身体。Steel 提供实际的浏览器实例，处理诸如代理轮换和会话 Cookie 等隐身功能。
- Protocol server（协议服务器） – 神经。Playwright MCP 向外部桌面工具暴露相同的手部功能，让本地 IDE 能够驱动远程浏览器。
你可以将这些层结合起来。例如，在 Steel 的云基础设施之上运行 Browser-Use 的智能体循环。
底层效率技巧
将整个 HTML 文档发送给 LLM 既慢又贵。现代技术栈通过三种方式精简负载：
- Filtered DOM（过滤后的 DOM） – 仅保留交互式节点（按钮、链接）；丢弃其余部分。
- Accessibility snapshots（无障碍快照） – 使用 ARIA 树，这是元素角色和标签的紧凑表示。
- Vision（视觉能力） – 当布局线索至关重要时（例如，区分轮播图与静态网格），向视觉模型提供截图。
这些捷径大幅减少了 Token 使用量，控制了成本，并保留了 LLM 进行智能决策所需的语义丰富度。
选择合适的工具
| 场景 | 推荐技术栈 |
|---|---|
| 稳定的企业门户，大规模回归测试 | 原生 Playwright —— 快速、廉价、确定性 |
| 需要打开多个标签页、追踪链接并在页面间进行推理的自主智能体 | Browser-Use + Steel —— 带有云浏览器的 Python 运行时 |
| 允许用户在工具从 Web 获取文档时编辑代码的桌面助手 | Playwright MCP —— 将浏览器操作暴露为与 LLM 兼容的工具 |
总结
AI 原生自动化并不是现有工具的单一替代品；它是一个模块化的技术栈，允许开发者根据需求选择相应的层。将推理运行时与精简的 SDK、可扩展的浏览器和协议桥接器相结合，你就能构建出在 Web 变化时仍能持续工作的智能体，且不会超出预算。