0.1 从 RPA 到浏览器智能体

0.1 从 RPA 到浏览器智能体

本节摘要：本节解释浏览器智能体为什么存在。先拆确定性脚本（Selenium、Playwright 直写）的两处天花板：结构脆断——页面改版、A/B 实验、懒加载让选择器一夜失效；语义缺失——选择器只描述「在哪」，不描述「是什么」，页面里对人 obvious 的语义在代码里荡然无存。再讲浏览器智能体的解法：目标驱动（任务写成目标而非步骤）与概率路径（每次执行路径由模型现场决定），以及随之付出的确定性与成本代价。随后给出贯穿全书的四流派地图——DOM 动作原语、结构化快照、视觉定位、验证重试，用「点一下添加按钮」这一个问题演示四种解法。最后交代分工：GUI 自动化原理归《深入理解 AI Agent》第 9 章，本书做选型与落地的工程纵深。

学习目标

• 复现确定性脚本的两类典型失败，并说出各自的根因。
• 区分「路径写死」与「目标驱动」两种任务表述方式。
• 画出四流派地图，为同一个操作任务写出四种流派的解法。
• 依据生态全景表与选型三问，为给定任务初选技术路线。
• 明确本书与《深入理解 AI Agent》第 9 章的内容分工。

一、确定性脚本的天花板

传统网页自动化有两条血脉：RPA 工具的录制回放，与 Selenium、Playwright 这类驱动库的手写脚本。形态不同，本质一样——人写路径：把「打开哪个页面、点哪个元素、填什么值」逐字写成指令序列。只要页面守规矩，它快、稳、便宜；页面一变，它就是全公司最脆的资产。

两类天花板值得分开看：

结构脆断好理解，语义缺失更隐蔽。看一段最小复现（本地测试页靶场在第 0.2 节搭建，此处先当伪代码读）：

# failing_selector.py —— 脆弱定位的最小复现（写法示意）
import asyncio

from playwright.async_api import async_playwright


async def main() -> None:
    async with async_playwright() as p:
        browser = await p.chromium.launch()
        page = await browser.new_page()
        await page.goto("http://127.0.0.1:8080/demo_todo.html")
        # 按位置取「页面上的第三个可点元素」——一次改版就断
        await page.locator("button >> nth=2").click()
        await browser.close()


asyncio.run(main())
​

两处问题：其一，位置式定位把「第三个」当成稳定契约，而页面加一个公告横幅它就错位；其二，这行代码没有回答「我在点干什么」，后来者只能靠考古。结构脆断让脚本死得快，语义缺失让脚本死得慢——维护者不敢动它，直到没人敢救它。

二、目标驱动与概率路径

浏览器智能体换了一种任务表述：不写路径，写目标。

「概率路径」是本书反复使用的一个词：模型在每一步从候选动作里做选择，选择带概率，于是整条执行路径是概率的。它换来适应性，也带来三个工程代价——同任务两次执行路径可能不同，回归测试要按「结果等价」而非「步骤相同」设计（第 6 章）；每步都有模型调用的直接成本（第 3 章的渐进式固化正是为此）；出错时需要轨迹级的可观测性（第 11 章生产化）。

把两种形态放在一条光谱上看，中间还有过渡地带：

 确定性 ────────────────────────────────────▶ 自主性
 ├──────────┼────────────────────┼──────────────┤
 纯脚本        半固化                 全自主
 Playwright    热路径固定成代码        browser-use
 直写          冷路径交给模型          Agent 循环
 每次同路径    （第 3.3 节）           每次现场规划
​

本书各章就是在这条光谱上移动：第 1 章抽公共语法，第 2 章推到右端（全自主），第 3 章往回拉（代码优先、Agent 兜底），第 6 章负责把两端都验证住。

三、四流派地图：同一问题的四种解法

拿一个具体问题当探针：「点一下添加按钮」这一步，各流派怎么实现？

                同一个问题：点一下「添加」按钮

 ┌─────────────────────┬─────────────────────┬─────────────────────┐
 │ DOM 动作原语         │ 结构化快照           │ 视觉定位            │
 │ browser-use/Stagehand│ Playwright MCP 等    │ Midscene/Skyvern    │
 │ 读 DOM→候选编号       │ 取无障碍树→ref 引用   │ 截图→坐标框          │
 │ 模型选编号→点击       │ 模型选 ref→工具调用   │ 模型出坐标→换算点击  │
 └──────────┬──────────┴──────────┬──────────┴──────────┬──────────┘
            │                     │                     │
            └─────────────────────┼─────────────────────┘
                                  ▼
              验证重试：无论怎么点，点完都要验证结果再前进
​

四流派不是四选一的宗教，而是可组合的四层能力。工程上的常见形态是：主路径用结构化快照或 DOM 原语（便宜、稳定），语义缺失的局部用视觉兜底，全程用验证重试兜结果。第 5.1 节会给出「结构化优先、视觉兜底」的完整决策依据。

四、生态全景与本书分工

主流开源实现一览（stars 为 2026-10-16 社区口径，量级参考）：

基建侧还有商业与开源两条线：Browserbase 是浏览器会话的商业 SaaS（官网口径：月 3500 万以上会话、约 1 万客户），steel-browser 提供可自托管的同类能力，两者都在第 7 章会话与基建详述。

最后交代与《深入理解 AI Agent》的分工。该书第 9 章《多模态与实时交互》的「Computer Use：GUI 自动化 Agent」一节讲清了原理层：动作空间设计、视觉定位（Grounding）、Set-of-Mark 与结构化元素索引的思想，以及一个 browser-use 入门实验（其实验 9-7）。原理归它，本书做工程纵深——选型、代码落地、验证、生产化；涉及 MCP 工具生态的理论背景则见该书第 4 章《工具》（「工具生态：MCP 与工具选择的挑战」一节）。

给本书的选型三问收尾：一问页面是否语义化（是则结构化快照与 DOM 原语优先，第 1、4 章）；二问流程是否要求确定与可测（是则 Stagehand 半固化路线，第 3 章）；三问预算与速率约束（视觉流派成本数倍于结构化，第 5 章；合规边界第 8 章）。

本节要点回顾

• 确定性脚本的两处天花板：结构脆断（页面一变就死）与语义缺失（没人读得懂）。
• 浏览器智能体 = 目标驱动 + 概率路径；适应性换来可重复性、成本与排查三笔代价。
• 四流派地图：DOM 动作原语、结构化快照、视觉定位、验证重试，可组合而非互斥。
• 生态位：browser-use 事实标准库，Playwright / DevTools MCP 快照双雄，Midscene / Skyvern 视觉侧，Browserbase / steel-browser 基建侧。
• 分工：《深入理解 AI Agent》第 9 章管原理，本书管选型与落地。

地图有了，接下来把靶场立起来：下一节准备 Python 与 TypeScript 双栈环境、安装 Playwright 浏览器、搭好本地测试页，并用 browser-use 跑通全书第一个真实任务。