智能体控制浏览器：五条路线和各自的代价
智能体控制浏览器分五条路线。第一条分水岭是用谁的浏览器：干净实例没有登录态，复用真实 profile 则等于把账号权限交给模型。
想让 AI 智能体替人查资料、填表单、盯后台任务，迟早会碰到浏览器。2026 年这条赛道上名字很多：Playwright MCP、browser-use、Stagehand、腾讯 BrowserSkill、OpenCLI、Claude 的 computer use……它们常被放在一起横评，但多数对比停在功能清单上。清单会告诉你支持哪些操作，却不告诉你这些操作落在你的电脑上会是什么样子。
选型只需要先问两个问题。第一个：它用谁的浏览器，是一个干净的自动化实例，还是日常登录的那个 profile。第二个：它怎么「看见」页面，是读 DOM 结构、读无障碍树，还是看截图。第一个问题决定 agent 能不能办真事，第二个问题决定它办事要花多少钱，以及页面一改版会不会立刻断掉。这篇文章围绕这两个问题，把赛道归成五条路线，讲清每条的实现思路、代表项目和代价。
要点
- 智能体控制浏览器可归为五条路线：协议直连、AI 框架层、MCP 服务器、本地桥接扩展、视觉模型与托管云。
- 第一条分水岭是登录态：干净实例（Playwright 启动的浏览器、云端浏览器）要重新登录；复用真实 profile（BrowserSkill、browser-control、Playwright MCP 的扩展模式）等于把账号权限交给模型。
- 视觉路线（Claude computer use 一类）不依赖 DOM，什么都能点，代价是每张截图约消耗 1,000–1,800 token，而且 Anthropic 建议放在沙箱虚拟机里跑。
控制通道与感知方式
浏览器自动化可以拆成两层：控制通道和感知方式。控制通道决定指令怎么送进浏览器。W3C 的 WebDriver 协议是 Selenium 走的路；Chrome DevTools Protocol（CDP）则是 Puppeteer 和 Playwright 直接对话的接口。还有第三种：在浏览器里装一个扩展，由扩展代为执行指令。这样 agent 进入的就是你正在用的那个浏览器。
感知方式决定模型拿到什么信息。三种常见做法差别很大：
- DOM 是页面的完整结构，信息最全，也最啰嗦。一个复杂页面的 DOM 可以很长，直接塞给模型既占上下文，又容易让它被无关节点分散注意力。
- 无障碍树是浏览器为屏幕阅读器整理出的精简结构，只保留有角色、有名字的元素：按钮叫什么，输入框的标签是什么，链接指向哪里。它是文本，体量远小于截图，Playwright MCP 就靠它工作。
- 截图什么都能看到，包括 canvas 里的图表、图片中的文字，甚至不在网页里的桌面窗口。代价是每一步都要消耗图像 token，而且模型只能靠像素坐标点击，精度受屏幕分辨率影响。
后面五条路线，基本就是这两层的不同组合。
登录态是第一条分水岭
拿 agent 干正经活，多数人卡在登录上。干净实例路线是 Playwright 自己启动一个 Chromium，或者用 Browserbase、Steel 这类托管云。它隔离干净，可以并行开几十个，坏了就扔。代价是没有 cookie：遇到内网系统和登录墙就走不动，每次都得想办法把会话搬进去。
复用自己浏览器的路线正好反过来。登录态、装好的扩展、保存的支付方式都是现成的，但 agent 的每一步都在以本人的身份行动。
设想一个很常见的任务：每天早上打开公司的工单后台，找出超过七天没人处理的工单，逐条加上备注。下面两种情况是推演，用来比较路线差异，不是实测结果。
在干净实例里，agent 先要面对登录页。账号、密码、二次验证都得先解决，而且每次任务可能都要重来一遍。好处是出了岔子，关掉这个窗口就结束了，不会误伤其他网站。
在复用的 profile 里，工单后台已经登录，agent 一上来就能读列表。但同一个浏览器里还开着邮件、报销系统和网银。它要是点错一个按钮，或者被页面上的一段文字带偏，后果会落在你的真实账号上，而且很难撤回。
这一波工具大多押在了第二条路上。腾讯 6 月开源的 BrowserSkill（MIT，截至 2026-10-10 约 8,500 star）、anomaly 7 月的 browser-control（MIT，约 440 star），还有 3 月就起步的 OpenCLI（Apache-2.0，约 3 万 star），出发点都是同一个需求：让 agent 用上已经登录好的网站。这也是安全边界最模糊的一条路线。BrowserSkill 的文档写明，Agent Window 不是安全沙箱，agent 拥有所选 profile 中已登录网站的全部权限。browser-control 的只读会话则是为了防误操作，防不了恶意代码。选这条路线，本质上是把对 agent 的信任当成前提。
五条路线：实现思路与代价
协议直连
这是最老的一条。Selenium（2013 年建仓，约 3.5 万 star）走 W3C WebDriver 协议，每种浏览器挂一个 driver。Puppeteer（约 9.6 万 star）和 Playwright 直接说 CDP，速度快，行为确定，测试和爬虫的地基到今天仍是它们。
它的确定性是真的。同一段脚本跑一千次，步骤基本一致，运行时不调用模型，也就没有推理费用。弱点同样明显：选择器写死在代码里，页面一改版就断。后面几条路线要解决的，几乎都是这个脆弱性。让模型在选择器失效时现场重找，或者干脆不用选择器，都是为了这件事。
AI 框架层
这一层把模型放进循环。browser-use（MIT，约 11.7 万 star）把页面 DOM 提炼成带编号的元素清单交给模型，agent 反复执行「看页面、做决定、出动作」。browserbase 的 Stagehand（MIT，约 2.6 万 star）在 Playwright 上加了 act、extract、observe 三个原语，要点击什么、抽取什么，用自然语言描述即可。字节 web-infra 的 Midscene（约 1.5 万 star）用视觉规划做自然语言端到端测试。Skyvern（AGPL，约 2.3 万 star）混用视觉和 DOM，专门跑重复性的工作流。
这一层的共同点是：代码只当手脚，判断交给模型。所以它灵活，页面稍有变化也能继续往下走。代价是不确定性被带了进来。同一个任务跑两次，路径可能不同；每一步都有模型推理，token 账单也是持续的。
MCP 服务器
这一层换了个问题：模型先要的是一组好用的工具，浏览器只是工具施展的地方。微软的 Playwright MCP（Apache-2.0，约 3.8 万 star）把页面的无障碍树交给模型，按元素引用点击和输入。纯文本模型就能稳定操作，不必消耗截图 token。Chrome DevTools MCP（约 5.3 万 star）补上性能追踪、网络分析这些调试视角，适合让编码 agent 自己排查页面问题。
Playwright MCP 还有一个值得留意的 --extension 模式。装上扩展后，它可以接到正在用的 Chrome 或 Edge 上，相当于这一层也开了一个通向本地桥接的入口。启用前要先确认它接的是哪个浏览器、哪个 profile。
本地桥接
这一层专门解决「用我自己的浏览器」这件事。本地常驻一个 daemon 或 relay，浏览器扩展充当执行端，agent 通过 CLI 或 MCP 发指令。几个项目的差别在于边界怎么画。
BrowserSkill 给每个任务开一个独立的 Agent Window，要动已有的标签页，得先弹出确认；验证码和登录则交还给人。browser-control 让 agent 直接编写 Playwright 片段，靠会话、标签页采纳（adopt）和只读模式划边界，导出网络捕获时顺手把密钥脱敏。OpenCLI 把常用网站做成一条条 CLI 命令，agent 调用命令，不碰底层协议。eyalzh 的 browser-control-mcp（约 330 star）最保守，只开放标签页管理和网页读取，每个域名都要先在浏览器里点头。
边界越窄，能干的事越少，出事时的影响面也越小。这是一个取舍，没有哪个选项是免费的。
视觉模型与托管云
这一层分两头。一头是 computer use。Anthropic 的工具集（2026 年 8 月版本已在 API 和 Google Cloud 正式可用）让模型看截图、报出像素坐标，17 个成员工具覆盖点击、输入、滚动等操作，真正执行则由你的应用负责。它不挑网站，也不挑软件，桌面应用也能点。代价是每张截图约 1,000–1,800 token，点击精度受分辨率影响，Anthropic 自己也建议把它跑在沙箱虚拟机里。
另一种做法是把 agent 直接做进浏览器。Comet（Perplexity，2025 年起）、Dia（The Browser Company）和 Atlas（OpenAI，2025 年 10 月）都是这个思路，普通用户不用配置就能用。
再往另一头是托管云。Browserbase、Steel 把浏览器变成 API，并行几百个会话，代理和验证码也替用户处理。规模化抓取和压力测试长在这里。
横向对比
| 路线 | 代表项目 | 控制通道 | 页面感知 | 登录态 | 隔离方式 |
|---|---|---|---|---|---|
| 协议直连 | Playwright、Puppeteer、Selenium | WebDriver / CDP | 选择器、DOM | 无，需另想办法 | 独立实例 |
| AI 框架 | browser-use、Stagehand、Skyvern、Midscene | Playwright 内核 | DOM 标注、视觉 | 可挂真实 profile | 独立实例为主 |
| MCP 服务器 | Playwright MCP、Chrome DevTools MCP | MCP 工具调用 | 无障碍树、性能追踪 | 扩展模式可复用 | 持久或隔离 profile |
| 本地桥接 | BrowserSkill、browser-control、OpenCLI | CLI / MCP 加扩展 | CDP 快照、元素引用 | 直接用自己的 | Agent Window、会话、采纳 |
| 视觉与托管 | Claude computer use、Comet、Atlas、Browserbase | 模型工具集、产品、云 API | 截图坐标 | 各家自管 | 沙箱虚拟机、云会话 |
读这张表，先看最后两列。我的判断是，这两列比支持的操作数量更能决定一个方案是否值得用。登录态决定 agent 能不能干真活，隔离方式决定出事的时候烧到谁。两列都占好的方案（独立窗口加确认、可审计的会话）目前主要出现在本地桥接层；两列都弱的组合（复用 profile 又没有边界）是这一波工具最该警惕的用法。
表格之外，还有几项代价不容易从功能列表里看出来：
| 代价 | 具体表现 | 主要压在哪条路线 |
|---|---|---|
| 选择器维护 | 页面改版后，写死的选择器失效，脚本要人工修 | 协议直连 |
| 推理开销 | 每一步都由模型判断，token 按步数持续计费 | AI 框架层、视觉模型 |
| 图像开销 | 每张截图约 1,000–1,800 token，步数多时很快累积 | 视觉模型，以及依赖截图的方案 |
| 登录态迁移 | 会话过期后要重新登录，或者把 cookie 搬进去 | 干净实例 |
| 误操作的影响面 | 出错的动作落在哪个账号、哪个系统上 | 复用 profile 的本地桥接 |
这些代价都能用工程手段缓解，但缓解要花钱。选择器维护可以交给模型兜底，兜底又带来推理成本；登录态迁移可以用 profile 解决，profile 又带来权限问题。没有哪条路线能同时免掉所有代价。
安全边界怎么守
智能体控制浏览器有三类风险，性质不同，防法也不同。
第一类是误操作。agent 可能把「保存草稿」点成「提交」，把没写完的邮件发了出去。付款、发送、删除这类动作一旦完成就很难撤回，应该在执行前由人确认。
第二类是页面注入。网页上的一段文字可能被模型当成指令。Anthropic 的 computer use 文档明确提醒，网页内容可能覆盖模型的指令。这算不上某款产品的缺陷，所有读取不可信内容的 agent 都会遇到它。
第三类是凭证暴露。复用 profile 时，登录态就在 agent 够得着的地方。如果工具本身有缺陷，或者页面里的恶意脚本借机利用，会话就可能被借用。BrowserSkill 的文档把「Agent Window 不是安全沙箱」写在了明处，这句话要当真。
防法也分三层。第一层是先走只读路径：browser-control 的只读模式和 eyalzh 的按域名授权都是这个思路，确认没问题再放开写权限。第二层是开审计，BrowserSkill 的 operation audit 和 browser-control 的 journal 都是现成的。第三层是给 agent 单独准备一个 profile，别让它碰到支付页面和你的主邮箱。
三件事里，我会把审计排在第一位。只读和隔离可以事前做，但出了问题要追责，能对质的只有账本。
怎么选
- 查资料、走内部系统、跑后台网页任务：本地桥接层最顺手。BrowserSkill 的独立窗口加人工介入，适合一边干活一边用电脑的人；喜欢写代码编排的，选 browser-control。
- 给写代码的 agent 补浏览器能力：从 Playwright MCP 起步，它的无障碍树路线不吃截图 token。排查性能问题时再加 Chrome DevTools MCP。想复用已登录会话，就开扩展模式，但先看清它接到了哪个浏览器。
- 做 E2E 测试：Midscene 或 Stagehand 叠在 Playwright 上，测试步骤用自然语言写，选择器失效时由模型兜底。兜底也意味着同一个测试两次运行可能走不同路径，断言要写得更严格。
- 规模化抓取、并行任务：托管云，配上等价的反检测浏览器。Camoufox 这类工具只适合抓取者自己有权访问的场景。
- 目标不在浏览器里（桌面软件、系统操作）：computer use，接受它的 token 开销，放在沙箱里跑。
常见问题
扩展模式会交出登录态？
扩展模式让 agent 在正在用的浏览器里操作，它能用到的登录状态和用户本人相同。能读到什么、能做什么，取决于工具实际暴露的接口和权限设置。启用前请对照它的文档确认这些边界，不要凭印象判断。
为什么要放进虚拟机？
截图方案能点到任何东西，包括不该点的地方。页面内容也可能影响模型的判断。把它放进一台可以随时重置的虚拟机，最坏的情况就被限制在那台机器上。这是 Anthropic 文档给出的建议。
只查资料，选哪一条？
从协议直连或 Playwright MCP 起步。无障碍树是文本，比截图省 token，也不需要碰你的 profile。需要登录的内部资料，再考虑本地桥接的只读模式。
脚本和模型哪个省？
固定流程用脚本更省。脚本运行时不调用模型，没有按步计费的推理成本，但页面一改就要人工修。模型控制每一步都有推理成本，页面经常变、流程不固定的时候，它省下的维护时间才值得这笔开销。
接下来看什么
两条线在合流。一条是 MCP 把「模型怎么接工具」标准化，浏览器只是它最先覆盖的领域之一，接入方式会越来越像安装驱动。另一条是浏览器厂商把 agent 内嵌进产品，Comet、Atlas、Gemini in Chrome、Claude for Chrome 都在走这条路，agent 和浏览器之间的距离在缩短。
夹在中间的本地桥接层，长期价值在两件厂商产品不容易做好的事上：用现成的浏览器和登录态，以及把每一步留在本机并可审计。什么时候厂商产品能同时做到这两点，这一层才会真正多余。在那之前，BrowserSkill 这类项目把「agent 用上真浏览器」这件事做得最认真。