浏览器智能体 2026：技术路线、反爬对抗与选型边界

到 2026 年，浏览器智能体已经不是演示品：填表、比价、订票、跨站汇总信息这类流程化任务，头部实现能给出八九成的任务成功率；但它离「放手不管」仍有距离——反爬封锁在收紧、公开基准之外缺乏可信的成功率数字、一次失败的代价可能是下错一单而不是返回一个报错。这篇文章梳理三条技术路线、代表框架与产品、网站方的对抗手段和可靠性证据，落点是一个朴素的选型判断：高频固定的流程写 API 或脚本，低频开放的任务才值得交给浏览器智能体。

三条技术路线：模型怎么「看见」网页

让模型操作网页，先要解决感知问题。目前有三条路线，差别在于把页面「翻译」成模型输入的方式。

DOM 与可访问性树

把页面解析成结构化快照，给每个可交互元素一个引用编号，模型输出「点击某个 ref」这样的动作。Playwright MCP 是这条路线的代表：官方文档明确说它「不需要视觉模型、纯结构化数据驱动」，工具调用是确定性的，避免了截图方案的歧义；截图功能被明确标注为「只用于查看，不能基于它执行操作」。这条路线省 token、定位准、速度快，代价是依赖页面语义完整——Canvas 应用、自绘控件和无障碍标注缺失的页面对它基本失明，快照与真实渲染也可能有出入。

视觉定位

把屏幕截图喂给多模态模型，模型输出像素坐标和键鼠动作，循环直到任务完成。OpenAI 的 Computer-Using Agent（Operator 背后的模型）与 Anthropic 的 computer use 走这条路。它与本站此前那篇入门向的《Computer Use 入门》的区别在于：本文只把 GUI 操作当作浏览器场景的路线之一，点到为止。视觉路线的优势是不挑页面实现，任何渲染出来的东西都能点，还能顺带覆盖桌面应用；代价是 token 贵、延迟高，坐标到语义的映射会漂移——页面一滚动，之前认准的目标就变了，小按钮也容易点偏。

混合感知

browser-use、Stagehand 等开源框架默认 DOM 为主、视觉为辅：结构化信息负责定位与抽取，截图用于校验结果、处理 DOM 拿不到的场景。这已成为 2026 年工程实践的主流形态，代价是两套感知都要维护，系统复杂度最高。

三条路线的对比：

路线	原理	代表实现	优势	短板
DOM / 可访问性树	解析页面结构，输出带引用的快照，模型按引用操作	`Playwright MCP`	省 token、定位确定、无需视觉模型	依赖页面语义，Canvas 与自绘界面失明
视觉定位	截图输入多模态模型，输出坐标与键鼠动作	`OpenAI CUA`、`Anthropic computer use`	不挑界面，通用性最强	token 贵、延迟高、坐标漂移、小元素易点错
混合感知	DOM 定位为主，截图校验兜底	`browser-use`、`Stagehand`	兼得结构信息与视觉兜底	两套感知都要维护，复杂度最高

小结：三条路线是互补而非替代，感知策略的选择本质是在「省 token 的确定性」与「全场景通用性」之间做交换。

代表实现：从自动化底座到整只浏览器

2026 年的实现生态可以分三层看。

底座层是 Playwright、Puppeteer 和 CDP 协议，几乎所有浏览器智能体都建在它们之上——browser-use 的浏览器控制底层就是 Playwright。这层负责「可靠地点击和输入」，智能体层负责「决定点哪里」。

框架与协议层最有代表性的是 browser-use：GitHub 上超过 11 万 star、MIT 许可，2024 年创建，宣称实现全部 31 个浏览器动作，支持本地浏览器、云端浏览器与 CDP 远程连接；2026 年推出自研模型 BU2 和托管云服务，云浏览器约每浏览器小时 0.02 美元，内置 stealth 模式、验证码处理与住宅代理（以上数据截至 2026-10-10）。微软的 Playwright MCP 则把浏览器能力以 MCP 工具的形式暴露给任意 LLM 客户端，一个值得注意的细节是：其文档提到编码类智能体越来越倾向用 CLI 加技能文件而非 MCP，因为 token 更省——但浏览器操作这种需要专门交互循环的场景，MCP 仍是主要形态。

产品层在 2025 年底到 2026 年密集爆发：ChatGPT Atlas 于 2025 年 10 月发布，是深度集成 ChatGPT 的 Chromium 系浏览器；Perplexity Comet 面向 Max 订阅用户，主打调研型工作流；Anthropic 不做独立浏览器，Claude in Chrome 以扩展形态挂在 Chrome 侧边栏，2025 年 8 月研究预览、同年 12 月 18 日起向全部付费用户开放 beta，金融类站点默认限制操作；OpenAI 的 Operator 则已并入 ChatGPT 的 agent 模式。产品形态与定价变动很快，以上均为截至 2026-10-10 的状态。

小结：框架层已经同质化（都建在 Playwright 上），真正的差异化在感知策略、云基础设施和产品入口——是用库、用协议还是换一只浏览器。

网站方的对抗：检测升级与规则之争

2026 年这个赛道最大的变量，是 Cloudflare 把「agent 流量」变成了独立的管控类别。Cloudflare 的 AI Crawl Control 文档把 AI 流量分成 Search、Agent、Training 三类，站点主的封锁动作会落成 WAF 自定义规则强制执行——而 WAF 规则的优先级高于 robots.txt，后者只是偏好声明，拦不拦由前者说了算。2026 年 7 月 1 日的官方公告宣布：新接入 Cloudflare 的域名，在展示广告的页面上，Training 与 Agent 类流量默认封锁；9 月 15 日起这一策略又扩展到混合用途爬虫（截至 2026-10-10 的政策，仅针对新域名与带广告页面，并非全站一刀切）。Cloudflare Radar 收录的 AI bot 已达 95 个，其中 67 个带可识别的 User-Agent。

检测技术也远比「查 UA」深入：TLS 指纹、浏览器环境一致性、鼠标轨迹、会话级行为序列都是信号，Cloudflare 在 2026 年推出的 Precursor 主打持续的会话级行为检测。但 browser-use 官方博客 2026 年 2 月的一篇分析给出了一个反直觉判断：Akamai、Cloudflare、DataDome 这类反爬系统的检测能力远超实际拦截范围——误杀真人会直接损害转化率，所以很多站点「检测到了但不拦」。这是一场阈值博弈：agent 伪装得越像人，网站方就必须在「漏放 agent」和「误伤用户」之间重新校准。

规则层面则仍是灰色地带：agent 替用户操作，身份算用户还是算爬虫？robots.txt 的语义覆盖不了交互式 agent；服务条款禁止自动化的站点（票务、社交、电商都比比皆是）与 agent 厂商之间的拉扯在整个 2026 年没有定论。工程上的现实是：涉及登录态、支付与个人身份信息的操作，即使技术上可行，合规与责任风险也在使用方一侧。

小结：对抗的天平在向网站方倾斜，「默认放行」正在变成「默认询问」——站点主手里第一次有了分类管控 agent 流量的开关。

可靠性：数字、口径与失败模式

谈可靠性先把公开数字摆出来，并注意测量口径。OpenAI 在 2025 年 1 月公布的 CUA 成绩是：WebArena 58.1%、WebVoyager 87%、OSWorld（操作系统级任务）38.1%——同一个模型，真实网页任务与桌面任务的成功率差了近 50 个百分点。作为参照，WebArena 论文（2023 年）里 GPT-4 基线的成绩只有 14.41%，一年多时间进步显著，但 58.1% 也意味着平均每五次任务失败两次。

WebVoyager 这张榜单在 2026 年被各家刷到了 89%–94%（Magnitude 自报 93.9%、browser-use 自报 89.1%），但这些都是厂商自报分数，评测设置互不统一，连聚合榜单自己都标注「方法学注意事项、配置不可直接比较」。基准之外的真实可靠性更值得警惕：WAREX 论文（arXiv:2510.03285，Microsoft 研究者，2025 年 9 月）往 WebArena、WebVoyager、REAL 三个基准中注入真实世界的故障——网络抖动、弹窗、被攻击的页面——任务成功率显著下降。结论是：干净环境下的高分，不代表抗扰动的可靠性。

工程侧归纳的常见失败模式：

反爬与验证码：browser-use 自己声明没有任何配置能保证绕过所有验证码，Cloudflare 系站点是重灾区；
认证流程：2FA、设备验证、风控弹窗会把 agent 卡死在登录页；
状态漂移：单页应用动态渲染导致快照过期、点了不存在的元素，页面滚动导致视觉目标错位；
自报成功：模型宣布「任务完成」但实际没做成，结果必须程序化校验，不能相信 agent 的自我汇报；
长尾站点：头部网站被各家专门适配，长尾站点的布局怪癖会让成功率骤降。

小结：看任何成功率数字先问三件事——哪个基准、谁测的、有没有注入真实故障。三者缺一，数字就只能当参考。

什么时候用浏览器智能体，什么时候老实写 API

把前面的分析收敛成四个判断问题：

有没有官方 API？ 有就用 API：更便宜、更快、更稳，而且有契约——页面改版不会毁掉你的集成；
流程是否固定且高频？ 固定高频的流程值得写定向脚本或爬虫，一次工程投入长期摊薄；
失败的代价多大？ 浏览比价错了可以重来，下单支付错了是真金白银；
任务是否开放多变？ 每次都不一样的任务，才是浏览器智能体的主场。

flowchart TD
    A["需求：让程序拿到网站数据或完成操作"] --> B{"有官方 API 吗"}
    B -- "有" --> C["直接对接 API"]
    B -- "没有" --> D{"流程固定且高频吗"}
    D -- "是" --> E["写定向脚本或爬虫"]
    D -- "否" --> F{"失败可容忍、可重试吗"}
    F -- "是" --> G["浏览器智能体"]
    F -- "否" --> H["人工处理或传统 RPA"]

据此给出正反两份清单。适合用浏览器智能体：一次性调研与跨站信息汇总（几十个站点查一遍价格与政策）；没有 API 的内部遗留系统；低频、容错、有人工兜底的流程；以及原型验证——先用 agent 把流程跑通，再决定要不要投入工程化。不适合：有官方 API 的一切场景；高频数据同步与交易；不可逆的支付与提交动作（除非每一步人在环确认）；对延迟敏感的场景——agent 一次任务通常以几十秒到几分钟计。

一句话收束：浏览器智能体不是 API 的替代品，而是没有 API 时的兜底、流程尚未定型时的探针。它会越来越强，但 2026 年的正确用法，仍然是把它用在「错了也无妨」的地方。

参考资料

Playwright MCP（GitHub）：可访问性树快照路线的官方实现，「结构化数据驱动、确定性工具调用」的一手表述出自这里。
browser-use（GitHub）：最热门的开源浏览器智能体框架，star 数、云服务定价与 CAPTCHA 声明等数据的一手来源。
OpenAI：Computer-Using Agent：CUA 的官方公告，WebArena 58.1%、WebVoyager 87%、OSWorld 38.1% 的出处。
WAREX: Web Agent Reliability Evaluation on Existing Benchmarks（arXiv:2510.03285）：向主流基准注入真实故障、揭示高分智能体鲁棒性有限的可靠性研究。
WebArena: A Realistic Web Environment for Building Autonomous Agents（arXiv:2307.13854）：真实网页环境基准的原始论文，GPT-4 基线 14.41% 与人类 78.24% 的对照出自这里。
Cloudflare AI Crawl Control 文档：Search / Agent / Training 三分类与 WAF 强制执行的官方说明，理解网站方管控 agent 流量的入口。