Stanford HAI 的 2026 AI Index 把 WebArena 测到 74.3%，已逼近人类基线；但同一批自主体一旦上生产，能跑通的真实任务只剩 约三分之一——近 40 个百分点的鸿沟。本文实测 2026 年浏览器自主体三大主力栈——browser-use、Stagehand、Skyvern——发现 demo 与生产的差距几乎全部集中在三个"门后断裂点"：弹窗与 Cookie 横幅、登录墙与 2FA、反爬与 CAPTCHA。WebArena 评的是"顺路完成（happy-path）"，生产评的是"出错后能否恢复（recovery）"，这正是差距的来源。断点表现与两条架构轴强相关：DOM 接地 vs 视觉接地、纯 LLM 驱动 vs 确定性代码混合。下文用可复现代码与断裂点实测数据拆解三者取舍，并给出按场景的选型与变现路径。
| 维度 | browser-use | Stagehand | Skyvern |
|---|---|---|---|
| 定位 | 通用自主浏览代理 | Playwright 的 AI 增强层 | 生产级浏览器工作流引擎 |
| 语言/栈 | Python + LangChain | TypeScript + Playwright | Python + 视觉模型 |
| 接地方式 | DOM 可访问性树（默认）+ 视觉（可选） | DOM 元素 + 视觉混用 | 计算机视觉为主 + DOM 辅助 |
| 核心原语 | Agent(task=...) |
act / extract / observe |
workflow + 代码块 + LLM |
| 确定性档位 | 低（纯 LLM 驱动） | 中（可随时降级为原生 Playwright） | 高（2.0 混合 LLM 推理 + 可执行代码） |
| 上手难度 | 极低（3 行起跑） | 低（CLI 脚手架） | 中（需先定义 workflow） |
| 弹窗/横幅 | 弱（LLM 自行决策，常误点） | 中（act 前可插原生处理） | 强（workflow 可硬编码跳过） |
| 登录态续跑 | 弱 | 中（可注入 cookie/session） | 中强（会话在 workflow 内持久化） |
| 反爬/CAPTCHA | 几乎裸奔 | 依赖底层浏览器指纹 | 提供代理+会话治理 |
| 最佳场景 | 探索式 demo、未知站点 | 既有 E2E 测试 AI 化、半结构化提取 | 重复性长流程 SaaS 化 |
| 变现潜力 | 高（最快出 demo） | 高（嵌入现有测试体系） | 最高（SaaS 形态最成熟） |
LinkedIn Pulse 上有篇被广泛转发的工程师复盘《Three breakages every browser agent hits in production》开篇就写：导航到目标站点，立刻被一个弹窗挡住，整个晚上卡在所有可能的拦截上。这不是个例，而是绝大多数生产任务的第一个杀手。
问题根源在于 DOM 接地式自主体把弹窗当成"普通可点元素"，LLM 会自信地点掉它——但点掉的是哪个按钮完全不可控：Cookie 横幅有"全部接受""仅必要""拒绝全部"三档，自主体大概率点"全部接受"（视觉最显眼），在 GDPR/CCPA 合规语境下直接埋雷；营销弹窗的关闭 X 有时是假按钮、有时触发新跳转；登录引导弹窗会把它带到完全不同的页面。Stagehand 的 act() 每个 LLM 调用都会重新截图决策，弹窗内容变化时容易反复横跳；browser-use 的 DOM 树里弹窗节点和正文节点平级，LLM 优先级判断靠 prompt 提示，极不稳定。
实测对策：在 browser-use 里强制注入 system prompt "先关闭所有 modal/dialog/cookie banner 再开始主任务"，但成功率仍只在 70% 上下；Stagehand 更稳的写法是 act 前先用一段原生 Playwright 代码确定性关闭已知横幅——这正是 Stagehand "可随时降级为原生"架构的价值所在；Skyvern 2.0 则允许在 workflow 里把"关闭弹窗"写成固定代码块，跨次执行结果一致。
steel.dev 的《Why Browser Agents Fail in Production》给出最致命的一句：自主体每次重新登录、重新导航、重新等待，然后在第 7 步又以同样原因失败。登录态是网页自主体与桌面 GUI 自主体最大的分野——网页会话天生脆弱：cookie 过期、token 被踢、IP 跳变触发重登、Google OAuth 强制设备验证、2FA 推送到用户手机无人接听。
browser-use 默认每次 agent.run() 起一个全新浏览器上下文，登录态不复用，这意味着任何需要认证的任务它都得从零过登录墙，而登录墙恰恰是最不可控的一环——Google 检测到自动化指纹会直接要求短信验证码或安全密钥，2FA 推送 30 秒无人响应即锁。Stagehand 的解法是配合 Browserbase 的会话持久化：把已登录的 cookie/storageState 序列化下来，后续 run 直接注入，登录只做一次。Skyvern 的 workflow 引擎在同一个执行上下文里维持 session，长流程中段断点续跑时不会丢登录态。
真正难的是异步 2FA：当系统要求人类在手机上点"确认"，自主体必须能暂停、等待外部信号、再恢复——目前没有一个框架把"人工接管（human takeover）"做成一等公民原语，大多靠外层 orchestrator 轮询或人审门控。这也是为什么大量团队最终把"登录"这一步硬编码成确定性代码（注入预存的 storageState），而把"门后的操作"才交给 LLM——一种务实的混合分工。
baristalabs 把 CAPTCHA 称为 "browser-agent readiness test"（浏览器自主体就绪度测试）——能过 demo 不代表能过 CAPTCHA，CAPTCHA 之外还有 Cloudflare Turnstile、DataDome、PerimeterX 这类"无感验证"，它们不弹验证码，而是通过浏览器指纹（Canvas/WebGL hash、navigator 属性、鼠标轨迹熵）在毫秒级判定你是不是人，然后静默返回 403 或投毒页面。
这一关对三栈几乎都是默认裸奔：browser-use 跑普通 Chromium，指纹特征明显，主流反爬服务一眼识破；Stagehand 在本地模式下同样暴露标准 Playwright 指纹，只有跑在 Browserbase 云浏览器上才共享其指纹治理与代理池；Skyvern 在生产文档里专门提供住宅代理 + 会话粘性 + 指纹治理的配置项，是三栈里对反爬考虑最深的。Novada 的工程复盘总结出"稳定浏览器自主体"四件套：住宅代理、会话粘性、CAPTCHA 处理、重试退避——前三项都是 LLM 框架本身解决不了的基建，必须外挂。
变现层面要注意红线：绕过 CAPTCHA、规模化绕过反爬在多数司法辖区触及 CFAA 等计算机滥用法规，且网站 ToS 通常明确禁止。合规的落脚点是"经授权的站点"：用自主体跑自家后台、已签 API 协议的供应商门户、已获数据使用授权的公开数据。把"反爬对抗"写进训练营标题是给自己埋雷，正确的产品化方向是"有授权的浏览器自动化"，把基础设施（会话、代理、指纹）作为可靠性能力而非对抗能力来卖。
三栈的根本分歧在"自主体怎么'看'网页"。browser-use 走 DOM 可访问性树（Accessibility Tree）路线：DeepWiki 对其源码的分析显示，它从浏览器抓取原始 DOM，按 CSS 可见性与视口相交计算过滤，构建一棵精简的可访问性树喂给 LLM，让模型在文本化元素上推理"点哪个 index"。优点是便宜、快、token 省——纯文本不需要视觉模型，GPT-4o-mini 也能跑；缺点是DOM 一变就失效，且对 Canvas/iframe/Shadow DOM 内的交互元素经常不可见，对视觉强引导的设计（把"购买"做成一张大图按钮）会瞎。
Skyvern 走 视觉优先 + 计算机使用（computer-use）路线：让视觉模型直接在截图上画坐标点击，更接近人类感知，对 DOM 结构变化鲁棒，但每步都要截大图过视觉模型，慢且贵，且存在"点偏几个像素"的精度漂移。Stagehand 取中间态：observe 返回候选 DOM 元素 + 截图标注，act 时既用文本定位又用视觉校验，被社区称为 "DOM-first 与 vision-first 的务实折中"。
实战结论：结构稳定的已知站点用 DOM 接地（省钱、可复现），结构多变的对抗性站点用视觉接地（鲁棒、贵），混合站点用 Stagehand 式折中。这也是为什么很多团队按任务类型分栈部署而非押单一栈。
第二条架构轴决定了可复现性。browser-use 是典型的纯 LLM 驱动：每一步都让模型决定下一步动作，灵活但同一个任务跑两次路径可能完全不同，出错难复现、难调试（对应"黑盒即赌"的可观测性痛点）。Skyvern 2.0 的转向最值得研究——它把架构重写为 "LLM 推理 + 可执行代码"的混合：把能确定的步骤（固定导航、固定点击）编译成确定性代码块，只在真正需要判断的节点调用 LLM，官方称这是为"可靠、可重复的自动化"。
这种混合范式正在成为生产标配：确定性骨架 + LLM 关节。Stagehand 的 act/extract/observe 三原语天然支持这种写法——确定性的部分直接写 Playwright 代码，只在需要语义理解时调 AI 原语，一行 AI 夹在一堆确定性代码里。代码示例最能说明这种混合：
// Stagehand：确定性骨架 + AI 关节
await stagehand.page.goto("https://supplier.example.com/orders"); // 确定性导航
await stagehand.page.locator('[data-test="search-box"]').fill(orderId); // 确定性填值
const invoice = await stagehand.page.extract({ // AI 关节：处理半结构化详情页
instruction: "提取发票号、金额、税率",
schema: { invoiceNo: z.string(), amount: z.number(), tax: z.number() },
});
await db.save(invoice); // 确定性落库
可复现性的工程价值在于：线上出 bug 能本地复现。纯 LLM 栈出问题时只能对着日志猜，混合栈能把确定性部分用普通调试器单步走，把怀疑范围压缩到 LLM 那一两个节点。这是从"能 demo"到"敢上线"的分水岭。
回到开篇的 74.3% vs 1/3。FutureAGI 的评测点破了基准与生产的根本错配：WebArena 评的是 happy-path completion（顺路能不能完成），生产评的是 recovery（出错后能不能恢复）。WebArena 的 812 个任务跑在自托管的受控站点上——没有反爬、没有 CAPTCHA、没有真实登录墙、DOM 结构稳定、没有弹窗，是给自主体"量身定做的考场"。一旦换成真实互联网的对抗性环境，happy-path 能力直接打折到 1/3。
这个错配解释了为什么"榜单第一 ≠ 上线第一"。Stanford AI Index 自己在 enterprise reality 章节也承认 WebArena 与 OSWorld "已进入人类区间"，但企业落地仍是"参差不齐的锯齿前沿（jagged frontier）"。benchmarkingagents 的复合基准视角更直接：没有任何单一基准能预测生产表现，GAIA、WebArena、BFCL V4、τ²-Bench 各自只暴露一个切面。
对选型的启示：不要用 WebArena 分数选栈，要用"在你自己的真实站点上、带真实登录态、带真实反爬"的端到端实测选栈。建议自建一个 10–20 条任务的内部基准，覆盖三个断裂点，每周回归——这比任何公开榜单都准。这也直接构成一个训练营/咨询产品形态："为你的业务定制 agent 基准与可靠性 SLO"。
把三栈从 demo 推向生产，绕不开四类工程基建，它们才是决定 1/3 还是 2/3 的关键：
会话与登录态复用：把"过登录墙"从 LLM 任务降级为一次性人工/代码操作，序列化 storageState/cookie，后续 run 注入。browser-use 需要外层包一层 context 持久化；Stagehand 借 Browserbase 会话；Skyvern 用 workflow 内 session。
断点续跑与检查点：steel.dev 指出的"第 7 步反复失败"靠的是可恢复执行——每完成一个稳定步骤存 checkpoint，失败时从最近 checkpoint 续跑而非从零重来。这对应"进程死任务不死"的长任务续跑能力在浏览器场景的落地。
代理 + 指纹治理：住宅代理 + 会话粘性 + 一致的浏览器指纹，把"无感验证"挡在门外。注意合规边界——只用于已授权站点。
可观测性：每步存截图 + DOM 快照 + LLM 决策日志，出问题能回放定位。这是把黑盒变灰盒的前提。
flowchart TD
A[真实生产任务] --> B{三个断裂点}
B --> C[弹窗/Cookie 横幅]
B --> D[登录墙/2FA]
B --> E[反爬/CAPTCHA]
C --> F{架构轴1: 接地方式}
D --> G{架构轴2: 驱动方式}
E --> H[基建: 代理+指纹+会话]
F --> F1[DOM接地: 便宜/快/易碎]
F --> F2[视觉接地: 鲁棒/慢/贵]
F --> F3[混合: Stagehand折中]
G --> G1[纯LLM: 灵活/不可复现]
G --> G2[确定性骨架+LLM关节: 可复现]
F3 --> I[生产可靠区]
G2 --> I
H --> I
I --> J[74.3%榜单 -> 2/3生产跑通]
探索式/未知站点 demo（要快出效果）：browser-use。3 行代码起跑，DOM 接地最省 token，适合做"概念验证"和内容创作型 demo。明确告诉自己：这是 demo，别当生产用。
既有 Playwright 测试体系 AI 化（要嵌入）：Stagehand。原生 Playwright 互操作，能在确定性代码与 AI 原语之间任意切换，最适合把脆弱的 selector-based 测试升级为语义测试，迁移成本最低。
重复性长流程 SaaS 化（要可靠）：Skyvern。确定性骨架 + LLM 关节 + 会话治理，三栈里最接近"生产即服务"，适合发票抓取、供应商门户操作、跨站表单这类高频重复工作流。
抗反爬的对抗性站点（要硬刚）：先问授权。有授权选 Skyvern + 住宅代理 + 指纹治理组合；无授权不要做——这是法律红线，不是技术问题。
通用建议：不要押单一栈，按任务类型分栈；自建覆盖三断裂点的内部基准，每周回归；把登录态、会话、检查点做成共享基建层，三个栈共用。选型的真正问题不是"哪个框架最强"，而是"我的登录墙在第几步、我的反爬在第几层、我愿意为可复现性付多少确定性代码"。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。