假设你对 Agent 说：
帮我查明天下午从上海到北京的航班，选一个合适的，但先不要付款。
一个 Agent 可以有很多种做法：
- 调用航班搜索 API，直接得到结构化结果。
- 请求网页的 HTTP 响应，从 HTML 或内嵌数据里提取航班。
- 启动浏览器，用 Playwright 按 label 填出发地、目的地和日期。
- 通过 Chrome DevTools Protocol 读取 DOM、网络请求或 Accessibility Tree。
- 在浏览器扩展的 content script 里理解页面，再由 service worker 协调动作。
- 把网页截图交给多模态模型，让它找到日期选择器并输出点击坐标。
- 复用一个已有登录态的真实浏览器，完成筛选和旅客信息填写，在付款前交还给人。
这些都可以被叫作“Agent 控制浏览器”，但它们实际处于不同层级，拥有完全不同的成本、稳定性和权限。
查公开航班信息，可能根本不需要打开浏览器；填写动态表单，需要真实的页面状态；选择日历里的某一天，可能需要 DOM，也可能只能靠视觉；而最终付款不是“再点击一次”，而是一次需要授权、确认和终态验证的业务提交。
先给出本文的核心判断：
最好的 Browser Agent 不是最像人类点网页的 Agent，而是能在 HTTP、结构化页面接口和视觉控制之间，选择最短、最少权限、最容易验证的路径。
要理解这些路线，最重要的不是背工具名字，而是分清两个经常混在一起的维度：Agent 用什么通道改变浏览器，以及它用什么表示理解页面。
一、先拆掉一个误区：访问网页不等于控制浏览器
“上网”至少包含四个不同等级的任务。
| 等级 | 例子 | 需要真实浏览器吗 | 关键难点 |
|---|---|---|---|
| 获取公开信息 | 读取新闻、文档、价格页 | 通常不需要 | 内容抽取、时效和来源 |
| 页面内交互 | 搜索、筛选、翻页、填写表单 | 经常需要 | 动态 DOM、元素定位、等待 |
| 管理浏览器状态 | 登录、Cookie、多标签页、下载上传 | 需要 | 会话隔离、凭据、弹窗与文件 |
| 完成有副作用的任务 | 发帖、提交工单、下单、付款 | 需要浏览器或业务 API | 授权、幂等、确认和终态验证 |
如果任务只是“读取一篇公开论文”，启动完整浏览器、渲染页面、截图，再让多模态模型 OCR，是一条昂贵的弯路。HTTP 请求或论文 API 已经能给出更干净的内容。
但如果任务是“登录 CRM，找到某个客户，把字段改成已跟进”，仅靠 HTTP 抓取就不够了。Agent 必须持有正确会话，处理前端状态，准确定位控件，并在提交后确认服务端记录真的改变。
因此，Browser Agent 不是单一技术，而是一套从信息获取到有状态执行的控制栈。
二、心智模型：六阶段闭环，两条正交轴
一个完整的 Browser Agent 可以拆成六个阶段：
flowchart LR
U[用户任务] --> P[规划与选路]
P --> O[获取与观察<br/>HTTP DOM AXTree Screenshot Network]
O --> G[定位<br/>URL API Element Ref Coordinate]
G --> A[行动<br/>Request Locator CDP Extension Mouse]
A --> B[浏览器与网站状态]
B --> V[验证<br/>页面断言 API 查询 文件或业务终态]
V -->|未完成或状态不明| O
V -->|证据通过| D[完成]
S[权限 会话 预算 人工确认] -.约束.-> P
S -.约束.-> A
S -.约束.-> V六个阶段分别回答：
- 获取信息：能否直接请求资源，还是必须运行页面？
- 表示页面：把当前状态表示为响应正文、DOM、Accessibility Tree、网络事件还是截图？
- 定位目标：目标是一个 URL、业务 ID、DOM 节点、可访问性节点还是坐标？
- 执行动作：发送 HTTP 请求、调用 locator、执行 JavaScript、发 CDP 命令，还是模拟鼠标键盘？
- 验证结果：页面、文件、API 或业务数据库出现了什么外部证据？
- 管理权限与状态：谁的登录态、允许访问哪些站点、哪些动作必须由人确认？
在这个闭环里，控制方式有两条正交轴。
轴一：控制通道——怎样改变浏览器或网站
常见通道包括：
- HTTP/API 请求。
- W3C WebDriver。
- Playwright、Puppeteer 一类高层自动化库。
- Chrome DevTools Protocol（CDP）。
- 浏览器扩展 API 和 content script。
- 页面里的 JavaScript。
- OS 级鼠标、键盘与截图。
轴二：观察表示——模型到底看见什么
常见表示包括：
- HTTP 响应、JSON 或提取后的正文。
- 原始 HTML 或裁剪后的 DOM。
- Accessibility Tree / ARIA role 与 accessible name。
- 网络请求、响应和浏览器事件。
- 屏幕截图、OCR、图标框与坐标。
- 工具预先整理的语义 snapshot。
这两条轴不能混为一谈。
Playwright 不是 DOM 的同义词。它可以通过 locator 使用 DOM 和 ARIA 语义，也可以截图、监听网络、管理下载、执行 JavaScript 和创建隔离的 browser context。
CDP 也不是“坐标点击协议”。它包含 Target、DOM、Runtime、Network、Accessibility、Input、Page 等多个域，既能读取结构，又能监听网络、执行脚本、管理 tab 和发送输入事件。CDP 官方文档明确把能力划分为带命令和事件的多个 domain，同时提醒 tip-of-tree 协议变化频繁，不保证向后兼容。
同一个“点击提交”动作，可以来自不同组合：
| 观察表示 | 定位方式 | 控制通道 | 特征 |
|---|---|---|---|
| DOM | data-testid 或 CSS | WebDriver/Playwright | 精确，但依赖页面结构 |
| Accessibility Tree | role + name | Playwright/CDP | 接近用户语义，依赖无障碍质量 |
| Screenshot | 图标、文字与坐标 | CDP Input/OS 鼠标 | 覆盖广，grounding 更难 |
| Network | 请求 URL 与 payload | HTTP/CDP | 接近业务数据，但要处理授权与稳定性 |
| 业务对象 | order_id、draft_id | 正式 API | 语义最强，覆盖取决于接口 |
三、路线一：HTTP、网站 API 与搜索抽取——能不启动浏览器就不启动
最轻的“浏览器控制”其实不控制浏览器。
对公开、静态或已有正式 API 的信息，Agent 可以直接使用 HTTP client、搜索 API、RSS、站点数据接口或领域连接器。返回结果通常是 HTML、JSON、XML 或文本，不需要加载字体、CSS、图片、广告和交互脚本。
为什么它往往是首选
- 快：没有浏览器启动、渲染和动画等待。
- 便宜：正文或 JSON 比整页 DOM 和截图占用更少上下文。
- 确定性更强：URL、状态码、schema 和业务 ID 比屏幕坐标更稳定。
- 容易并发与重试：只读请求通常没有页面焦点和 tab 竞争。
- 容易验证：可以检查响应状态、字段、时间戳和内容哈希。
在航班例子里，如果有获得授权的搜索 API，Agent 可以直接提交出发地、目的地和日期，获得航班编号、时间和价格。此时让模型在网页日历上找数字，是把结构化查询退化成视觉操作。
它什么时候不够
- 页面内容由 JavaScript 在浏览器里二次加载或计算。
- 网站需要 Cookie、WebAuthn、设备状态或复杂登录流程。
- 任务依赖真实布局、图像、Canvas、地图或拖拽交互。
- 请求需要 CSRF token、一次性 nonce 或页面生成的状态。
- 网站没有授权 API，内部接口随前端发布变化，也不承诺兼容。
这里要划一条边界：浏览器能观察到网络请求，不代表 Agent 就应该绕开页面，长期依赖未经授权的内部接口。接口稳定性、访问权限、网站条款、robots 约束和请求频率仍然成立。本文讨论的是技术选型，不是规避认证、反爬或使用规则的方法。
四、路线二：WebDriver 与高层自动化框架——让程序操作真实浏览器
当任务必须运行页面时，最成熟的路线是使用浏览器自动化接口。
W3C WebDriver 把自己定义为一种远程控制接口：通过与语言和平台无关的 wire protocol，让浏览器外部的进程检查并控制 user agent。Selenium 是这一标准路线最典型的生态。
Playwright 和 Puppeteer 则提供更高层的编程接口。它们不等同于 Selenium，也不应被简单归类为“另一套 CSS selector”。对 Agent 而言，高层框架真正重要的是把一批容易出错的浏览器机制包装成可组合动作：
- tab、popup、frame 和 browser context。
- navigation 与页面生命周期。
- locator、点击、输入、选择和拖拽。
- 网络监听、请求等待和 response 检查。
- Cookie、localStorage、IndexedDB 与登录状态。
- 下载、上传、对话框、权限和设备模拟。
Locator 的价值是“重新解析 + 等待 + 检查”
初学自动化时很容易把 locator 理解成“选择器的别名”。其实它更像一个可重试的元素查询承诺。
Playwright 的官方 locator 文档说明，每次 locator 被用于动作时，都会重新找到当前最新的 DOM 元素；如果 React/Vue 在两次动作之间重新渲染了按钮，locator 会尝试解析新的对应元素，而不是永远抓住旧句柄。官方也建议优先使用用户可见属性和显式契约，如 getByRole()、label 和 test ID。
执行点击前，Playwright 的actionability 检查还会确认目标唯一、可见、稳定、能接收事件并且 enabled。它解决的是大量自动化脚本常见的“元素明明找到了，为什么还是点失败”。
但 auto-wait 不是业务完成保证。按钮可点击，只能说明动作条件成立；点击以后是否保存成功、服务端是否返回目标结果，仍需要单独的 assertion 或外部 verifier。
Browser Context 是状态边界，不只是测试便利
Playwright 的 BrowserContext 可以在同一浏览器进程中创建相互隔离的会话。非持久 context 不把浏览数据写入磁盘；storage state 则可能包含 Cookie、localStorage、IndexedDB 和认证信息。
对 Agent 来说，这带来两种相反需求：
- 隔离优先：临时研究、并行任务和不可信网站使用干净 context，避免任务之间污染 Cookie、权限和缓存。
- 连续性优先：必须操作登录后页面时，受控地复用特定账号或 profile 的认证状态。
认证状态不是普通缓存。Playwright 的认证文档明确提醒，保存的状态文件可能包含足以冒充用户的敏感 Cookie 和 header。生产 Agent 需要把它当凭据管理，而不是随手提交到仓库或塞进提示词。
五、路线三：DOM、Accessibility Tree 与页面 JavaScript——三张不同的地图
一个网页至少可以有三种“结构视图”：
- DOM：HTML 元素、属性和父子关系，是脚本与页面框架主要操作的对象。
- Accessibility Tree：浏览器根据 DOM、ARIA、样式和可访问性规则计算出的用户语义视图。
- 视觉渲染：布局、颜色、图像、Canvas、遮挡和实际屏幕像素。
它们重叠，但不相等。
DOM：信息最丰富，也最容易过载
DOM 可以提供 ID、class、文本、属性、表单值、事件相关节点和组件结构。问题是现代页面的原始 HTML 可能极长，包含追踪脚本、隐藏模板、SVG path、框架生成节点和大量与任务无关的布局层。
Mind2Web 收集了 137 个真实网站、31 个领域上的 2,000 多个开放任务和人工动作序列。论文的一个直接发现是：真实网页的原始 HTML 往往太长，无法直接放进 LLM；先用较小模型筛选候选元素，可以显著提高后续决策的效率和效果。
这留下一个长期有效的原则：页面观察不是把 DOM 全倒给模型，而是为当前动作保留相关结构。
常见定位优先级可以是：
稳定业务 ID / test ID
→ role + accessible name / label
→ 唯一可见文本与相对关系
→ CSS / XPath 结构路径
→ 坐标兜底越依赖深层 CSS 或 XPath，越容易被无关布局重构破坏。
Accessibility Tree：把页面翻译成用户语义
role=button, name=Continue 通常比 .checkout > div:nth-child(3) > button 更接近任务语言。role/name locator 也更容易暴露页面的无障碍问题：如果一个用户可见按钮没有可访问名称，屏幕阅读器和 Agent 都会更难使用它。
但 Accessibility Tree 不是 DOM 的完美摘要。纯装饰节点可能被忽略，自绘控件可能没有语义，错误的 ARIA 可能产生误导。对依赖视觉比较、颜色、空间关系和图片内容的任务，它也可能缺失关键事实。
页面 JavaScript：在当前页面世界里直接计算
Agent 或自动化库可以在页面 context 里执行 JavaScript，用于读取应用状态、筛选节点、触发事件或计算页面内部结果。这比每个 DOM 节点都跨进程查询快，但有三类边界：
- 代码运行在页面的安全和生命周期约束内。
- 跨域 iframe 受到 same-origin policy 限制，外层页面脚本不能随意读取内层文档。
- 页面 JavaScript 触发的合成事件，不一定等价于真实用户输入或浏览器默认行为。
高层自动化框架可以通过浏览器协议切换到不同 frame，扩展 content script 也有自己的执行世界，但这不意味着 Web 的安全边界消失了；只是控制平面处在页面脚本之上。
Shadow DOM、iframe、虚拟列表与 Canvas
- iframe：每个 frame 都有独立文档和导航状态，Agent 需要明确进入正确 frame；跨域让普通页面 JS 的观察受到限制。
- Shadow DOM：open shadow root 可以被现代 locator 穿透或显式进入；closed shadow root 不保证可见。
- 虚拟列表：DOM 中只存在当前视口附近的行，搜索“第 500 条”前可能必须滚动并等待节点生成。
- Canvas/WebGL：画面可能只是一块像素缓冲，没有可用的内部 DOM 节点，必须依赖应用 API、视觉或坐标。
这些问题说明：DOM 很强，但它不是网页世界本身，只是浏览器提供的一张结构地图。
六、路线四：直接使用 CDP——更接近浏览器内核，也更接近复杂性
Chrome DevTools Protocol 是 Chromium 生态里非常有力的控制面。DevTools 自己就在使用它。常见 domain 包括：
| CDP Domain | 能力示例 | Browser Agent 用途 |
|---|---|---|
Target | 发现、创建、附加 tab/frame/worker | 管理页面与子目标 |
DOM | 读取节点、属性、box model | 结构观察与坐标计算 |
Accessibility | 读取 AXNode、role、name、value | 语义 snapshot 与 grounding |
Runtime | 在页面执行 JavaScript、获取对象 | 局部抽取和页面计算 |
Network | 监听请求响应、读取 body、管理 Cookie | 等待数据、验证请求、调试状态 |
Input | 发送鼠标、键盘、触摸事件 | 坐标动作 |
Page | 导航、截图、生命周期事件 | 页面控制与视觉观察 |
CDP 的优势是覆盖深、事件丰富、能同时观察页面结构、网络和浏览器 target。它适合调试工具、Chromium 专用 Agent runtime、远程浏览器服务和高层框架没有封装的边缘能力。
代价也很直接：
- 它主要绑定 Chromium/Blink 生态，不是统一跨浏览器标准。
- target、session、frame、worker 和导航生命周期需要自行管理。
- tip-of-tree 协议可能变化，直接依赖细节会带来兼容成本。
- 容易绕过高层框架已有的等待、重试、actionability 和错误恢复。
因此，直接 CDP 不是“比 Playwright 更高级”的默认选择。更稳的做法通常是：常规交互使用高层 locator，需要底层观察、网络、Accessibility 或特殊输入时，再通过 CDP 下钻。
七、路线五：浏览器扩展——把 Agent 能力安装进用户浏览器
另一条路线不是从外部驱动浏览器，而是把观察和动作能力作为扩展长期运行在浏览器内部。
Chrome 扩展常见结构是：
网页
↕
content script（读取/修改页面 DOM）
↕ message passing
extension service worker（状态、策略、网络与扩展 API）
↕
Agent 或本地/远程服务Chrome 的官方 content script 文档说明，content script 默认运行在 isolated world：它能访问和修改 DOM，但它的 JavaScript 变量与页面脚本、其他扩展隔离。需要更高权限的能力时，content script 通过消息与 service worker 或扩展页面通信。
扩展路线适合什么
- 长期存在的浏览器助手、侧边栏和用户触发自动化。
- 复用用户当前 tab、登录态与页面上下文。
- 在页面导航过程中持续观察，或与浏览器 UI 深度集成。
- 用站点级规则、content script 和扩展 API 形成稳定产品。
它的边界在哪里
扩展不是“拥有整个浏览器”。它能做什么取决于 manifest、API 权限、host permission、页面类型和浏览器政策。Chrome 的权限文档列出的 host permission 可以允许扩展读取敏感 tab 属性、注入脚本、访问 Cookie、监控网络或修改请求；这也意味着权限请求必须被当成安全设计，而不是安装时全选。
相比一次性的干净 browser context，装在真实用户浏览器里的扩展拥有更强的 ambient authority：邮箱、后台、社交账号和公司内网可能同时处于登录状态。权限越宽，提示注入或代码缺陷的爆炸半径越大。
八、路线六：截图、多模态模型与坐标动作——当页面只剩像素
有些任务必须看图：
- Canvas 日期选择器、地图和图表。
- 商品图片、颜色、布局和视觉相似度。
- 没有可用 DOM 的远程浏览器或视频流。
- 页面结构存在，但语义缺失或严重噪声。
视觉 Browser Agent 通常接收截图和任务，生成对目标元素的描述或坐标，再通过 CDP Input、WebDriver action 或 OS 鼠标键盘执行。
这条路线的核心难点叫 grounding：模型可能理解“点击返程日期”，却仍然要把这个意图落到正确的像素区域。
SeeAct：会规划，不等于能落到正确元素
SeeAct 用多模态模型理解网页并生成动作意图，再研究怎样把意图 grounding 到真实元素。论文在 Mind2Web 和 live website 设置中发现，人工完成 grounding 时模型表现出很强潜力，但自动 grounding 与 oracle 之间仍有明显差距；作者提出的最好策略结合了 HTML 结构与视觉，而不是只押注其中之一。
这给工程实践一个很直接的提示：多模态模型的高层判断可以很好，执行层仍可能点错。 规划分数不能替代 grounding 和终态成功率。
WebVoyager：视觉带来通用性，也暴露密集文本弱点
WebVoyager 让多模态 Agent 在 15 个真实网站上端到端执行任务。论文报告其原始实验中达到 59.1% 的自动评估成功率，但更有价值的是错误分析：日期可能点错、滚动方向可能迷失、模型可能只找到部分答案；作者还观察到视觉方案在密集文本网站上不一定占优，并提出用 HTML 文本增强视觉输入。
这些是 2024 年论文设置中的结果，不是今天的模型排名。它们留下的长期结论是：视觉扩大了覆盖面，却没有取消结构化文本、历史状态和验证的价值。
视觉路线的典型局限
- 分辨率、缩放、响应式布局改变坐标。
- 滚动后旧截图与当前页面不再一致。
- sticky header、弹窗和动画遮挡目标。
- 相似图标、重复按钮和小字号造成歧义。
- 截图看不到网络错误、隐藏字段和服务端真实状态。
- 每轮高分辨率图像与长轨迹带来延迟和 token 成本。
因此，视觉最适合作为结构接口的补充与兜底，而不是默认把每个网页都降级成像素。
九、路线七：Agent-aware browser runtime 与远程浏览器
浏览器 Agent 真正进入日常工作后，问题会从“怎么点”升级为：
- 登录态从哪里来？
- Agent 与人会不会争同一个 tab？
- 多个任务怎样隔离 Cookie、下载和站点副作用？
- MFA、验证码和敏感提交怎样交还给用户？
- 浏览器崩溃或 Agent 中断后怎样恢复？
- 谁能审计 Agent 看过什么、做过什么？
这推动了两类运行时：
- 远程/托管浏览器：每个任务启动隔离 browser context 或云浏览器，通过 WebSocket、WebDriver、CDP 或封装 API 控制。
- Agent-aware 浏览器：浏览器自身提供任务空间、语义 snapshot、登录态复用、Agent ownership 与 human handoff。
我在《Ego Lite 的关键不是会点网页，而是把浏览器变成 Agent 的共享运行时》里专门分析过第二类设计。这里不重复产品细节，只保留一个判断：浏览器开始替 Agent 持有长期状态与真实账号后，它就不再只是自动化库，而是一个权限运行时。
这种运行时通常采用混合控制：稳定位置用 DOM/Accessibility locator，特殊组件用视觉，网络与下载用协议事件，高风险动作交给人确认。竞争点也不再是多一个 click()，而是状态隔离、权限、观察质量、失败恢复和接管体验。
十、论文地图：不同 benchmark 到底在测什么
Browser Agent 论文很多，但数字经常不可直接比较。先区分它们评测的对象。
| 工作 | 环境与观察 | 主要评测 | 它回答的问题 | 不能直接推出什么 |
|---|---|---|---|---|
| WebGPT | 受限的文本浏览环境 | 带引用长回答的人类偏好与事实性 | 模型能否搜索、浏览并收集证据 | 能否操作任意现代 GUI |
| Mind2Web | 真实网站的离线轨迹与 HTML | 元素选择、动作和步骤准确率 | 能否跨任务、网站和领域泛化 | 在线执行时是否能恢复异常 |
| WebArena | 自托管的真实风格功能网站 | 端到端功能正确性 | 长链网页任务能否真正完成 | 对公网变化和视觉任务的通用性 |
| WorkArena | ServiceNow 企业软件，BrowserGym | 33 类知识工作任务 | Agent 能否处理典型企业 Web 工作 | 任意消费网站上的表现 |
| VisualWebArena | 可复现网站 + 图文观察 | 910 个视觉 grounding 任务 | 视觉信息何时是完成任务的必要条件 | 真实账号与开放公网的安全性 |
| SeeAct | Mind2Web + live websites | 规划、grounding、在线任务 | 多模态理解与元素 grounding 的差距 | 生产级连续可靠性 |
| WebVoyager | 15 个真实网站，截图交互 | 端到端任务与自动评估 | 视觉 Agent 能否在公开网站闭环执行 | 评估器与真实业务状态完全等价 |
| BrowserGym | 统一 observation/action 环境 | 多 benchmark 可复现实验 | 怎样标准化 Agent 与网页环境接口 | 某个模型天然具备生产可靠性 |
从 WebGPT 到真实交互环境，研究问题发生了什么变化
WebGPT 使用文本化浏览器：模型看到当前页面游标附近的文字，通过搜索、点击链接和滚动等受限命令收集引用。它解决的是“怎样让模型浏览证据并写出可核查回答”，不是通用 GUI 自动化。
Mind2Web 把问题推进到真实网站和动作轨迹，但主要是离线评测：预测标注轨迹上的下一元素和动作，不等于真的在变化的网站里完成任务。
WebArena 与 VisualWebArena 把评测变成可执行环境和功能终态。WebArena 原论文中的最好 GPT-4 baseline 端到端成功率为 14.41%，人类为 78.24%；VisualWebArena 再加入图片、布局与视觉比较不可缺少的任务。这些数字属于各自论文的模型和设置，真正重要的是评测范式变化：从预测人走过的路，变成检查 Agent 是否把环境变到正确状态。
BrowserGym 则试图统一 observation、action space、benchmark 接入和实验管理。它提醒我们，Agent 的表现不只取决于模型，还取决于页面怎样被表示、有哪些动作、错误怎样反馈、任务怎样验收。
这与 SWE-agent 提出的 Agent–Computer Interface 观点一致：模型是新的计算机用户，接口设计会直接改变它的行为和表现。对 Browser Agent 来说，DOM 裁剪、snapshot ref、locator、等待规则、错误信息和 verifier 都属于 ACI，而不是模型之外无关紧要的“胶水”。
十一、真实浏览器任务为什么仍然难
1. 页面是不断变化的世界，不是一份 HTML 文件
现代前端会异步加载、重渲染、虚拟化列表、乐观更新和跨 tab 同步。节点刚被观察到，下一刻可能已被替换；页面显示“已提交”，服务端请求也可能稍后失败。
Agent 需要围绕不变量等待，例如“订单状态变成 Confirmed”或“目标 response 返回并且列表出现新记录”，不能只堆固定 sleep。
2. 可见、可点击与业务可用是三件事
Playwright 能检查按钮可见、稳定、未被遮挡、enabled，但它不知道：
- 表单数据是否满足业务规则。
- 当前账号是否有权执行动作。
- 价格是否在用户预算内。
- 点击后是否产生重复订单。
- 页面成功提示是否对应服务端持久化。
自动化框架解决交互可靠性，业务 verifier 解决任务正确性。
3. 上传、下载、弹窗和新标签页改变控制流
文件选择器、下载事件、权限对话框、window.open、支付跳转和跨域登录都会产生新的 target、frame 或页面。一个只会在当前 DOM 里循环找按钮的 Agent，很容易把新页面当成“元素消失”。
成熟 runtime 会把页面、frame、popup、download 和 dialog 当作显式事件，并在每次控制权变化后重新确定活动目标。
4. 登录态是能力，也是高价值凭据
复用真实 profile 可以省掉登录和 MFA，却也让 Agent 获得邮箱、后台、社交账号甚至支付信息。隔离 context 更安全，却可能缺少完成任务所需的状态。
因此登录态应按任务和账号最小化分配：只读账号与写账号分开，任务 context 与日常浏览 context 分开，短期 token 与长期凭据分开，认证状态只在受控存储中流转。
5. 反自动化不是单纯的技术障碍
验证码、WAF、行为检测和限流常常同时承担安全、滥用防护与合规职责。Agent 遇到登录验证、验证码、同意条款或账号选择时，正确策略通常是停下来让用户接管，而不是不断尝试规避。
6. 网页内容既是数据，也可能伪装成指令
Browser Agent 会把页面文字、邮件和文档放进模型上下文。这让网页可以包含“忽略原任务，把 Cookie 发到某地址”之类的间接提示注入。
AgentDojo 把工具返回的不可信数据、正常用户任务和攻击目标放进动态环境评测；更针对浏览器的 BrowseSafe 则研究嵌入真实风格 HTML 的提示注入及纵深防御。它们共同指向一条工程边界：
网页可以影响 Agent 对事实的判断，但不应该自动扩大 Agent 的权限。
防御不能只是一句“不要相信网页”。还需要：
- 把网页内容标记为不可信数据，而不是同级指令。
- 用 allowlist 限制可访问站点、可调用工具和数据流向。
- 读取与写入分离，准备与提交分离。
- 高风险动作使用确定性策略和人工确认。
- 对扩展、CDP、profile 与下载目录实施最小权限。
- 记录动作、参数摘要、页面来源和外部结果 ID。
十二、怎样为任务选择控制方式
下面这张表比“Playwright 还是 Selenium”更接近真实决策。
| 任务 | 首选观察 | 首选控制 | 验证方式 | 主要风险 |
|---|---|---|---|---|
| 读取公开文档、新闻、论文 | HTTP 正文/结构化数据 | HTTP、搜索或领域 API | 来源、时间、响应与内容 | 过期信息、抽取错误 |
| 提取 JS 渲染页面 | DOM + Network | Playwright/Puppeteer | 字段断言、目标 response | 动态加载、限流 |
| 登录后台填写表单 | role/label locator + 页面状态 | 高层自动化框架 | 重读字段、查询新记录 | 账号权限、重复提交 |
| 跨站知识工作 | DOM/AX + 局部截图 + 事件 | 隔离 browser context / runtime | 每站局部 verifier + 终态 | 登录态扩散、状态丢失 |
| Canvas、地图、图表 | Screenshot/OCR + 可用 DOM | 视觉 grounding + 坐标 | 截图变化、业务数据交叉验证 | 坐标漂移、视觉歧义 |
| 下载与上传 | 页面事件 + 文件元数据 | 框架 download/upload API | 文件名、哈希、服务端对象 | 路径泄漏、恶意文件 |
| 长期浏览器助手 | DOM/AX + tab/profile 状态 | 扩展或 Agent-aware runtime | 审计日志、权限与动作结果 | ambient authority、提示注入 |
| 下单、付款、删除、公开发布 | 业务摘要 + 外部真相源 | 授权 API 或浏览器准备流程 | 人工确认 + 业务终态 | 不可逆副作用 |
一条实用的降级链
有授权的正式 API / HTTP 数据
→ DOM / role / label locator
→ CDP 或扩展补足底层能力
→ 截图 + 视觉 grounding
→ OS 鼠标键盘兜底这不是说 HTTP 永远比视觉高级，而是优先选择语义更强、猜测更少的接口。任务可能在同一条轨迹里多次切换：
HTTP 查询航班候选
→ Playwright 打开登录后的预订页
→ role/label 填写字段
→ 视觉处理自绘日期组件
→ Network/页面断言确认报价
→ 人工确认最终付款
→ API/订单页查询终态混合控制的价值不在“工具更多”，而在于每一层只处理它最擅长的部分。
十三、生产级 Browser Agent 的最小结构
如果把前面的路线压缩成一个框架无关的最小系统，它至少需要七个部件：
- 任务契约：目标、禁止条件、预算、允许站点和完成证据。
- 选路器：判断 HTTP、DOM、CDP、扩展或视觉哪条路径成本最低。
- 观察裁剪器：只提取当前决策需要的 DOM、AX、网络或图像区域。
- 动作执行器：对 locator、request、download、popup 和坐标动作提供一致反馈。
- 浏览器状态层：管理 tab、frame、context、profile、Cookie、下载和 checkpoint。
- 权限与人机门：限制数据和动作空间，在敏感节点交还控制权。
- 外部 verifier：通过页面、文件、API 或业务状态判断真实完成。
其中模型最适合做的是理解目标、处理语义歧义、选择候选和异常恢复；代码最适合持有权限、状态、幂等、等待条件和终态验证。
如果一个系统只有 screenshot → LLM → click(x, y)，它拥有的是视觉操作回路，不是完整 Browser Agent runtime。
十四、最后用七个问题检查你的方案
- 能否不用浏览器？ 公开信息是否已有 HTTP、API 或领域连接器？
- 模型看见的是什么？ 原始 HTML、裁剪 DOM、AX Tree、网络事件还是截图？
- 定位凭什么稳定？ 业务 ID、role/name、文本关系、selector、snapshot ref 还是坐标？
- 动作失败时知道为什么吗？ 是元素不存在、被遮挡、权限不足、导航变化还是业务拒绝？
- 登录态怎样隔离？ Agent 能访问哪些站点、账号、Cookie、文件和扩展权限？
- 哪里必须由人确认？ 发送、付款、删除、授权、公开发布是否有提交门？
- 什么证明任务完成？ 是模型说完成、页面出现提示，还是外部世界达到可查询终态？
如果这七个问题没有答案，换一个更强模型或再加一个点击工具，通常不会让系统真正可靠。
浏览器是人类进入数字世界的通用界面，所以它天然吸引 Agent。但 GUI 的通用性也意味着低语义、高权限和大量隐含状态。成熟的 Browser Agent 不会坚持用一种方式走到底：它会在能请求数据时不渲染页面，能使用 locator 时不猜坐标，必须看图时缩小观察范围，涉及真实账号时隔离权限，并在每个关键动作后重新观察世界。
真正的进步不是让 Agent 点得越来越像人，而是让它越来越少猜、越来越少越权，并且越来越能证明自己真的完成了任务。