# 上线即崩：网页自主体三断裂实测 ## 概述 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 形态最成熟） | ## 深度分析 ### 一、断裂点之一：弹窗与 Cookie 横幅——"第一步就卡住" 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 里把"关闭弹窗"写成固定代码块，跨次执行结果一致。 ### 二、断裂点之二：登录墙与 2FA——"门后世界" 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——一种务实的混合分工。 ### 三、断裂点之三：反爬与 CAPTCHA——"能力即被识破" 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 协议的供应商门户、已获数据使用授权的公开数据。把"反爬对抗"写进训练营标题是给自己埋雷，正确的产品化方向是**"有授权的浏览器自动化"**，把基础设施（会话、代理、指纹）作为可靠性能力而非对抗能力来卖。 ### 四、架构轴之一：DOM 接地 vs 视觉接地 三栈的根本分歧在"自主体怎么'看'网页"。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 式折中**。这也是为什么很多团队按任务类型分栈部署而非押单一栈。 ### 五、架构轴之二：纯 LLM 驱动 vs 确定性代码混合 第二条架构轴决定了**可复现性**。browser-use 是典型的**纯 LLM 驱动**：每一步都让模型决定下一步动作，灵活但同一个任务跑两次路径可能完全不同，出错难复现、难调试（对应"黑盒即赌"的可观测性痛点）。Skyvern 2.0 的转向最值得研究——它把架构重写为 **"LLM 推理 + 可执行代码"的混合**：把能确定的步骤（固定导航、固定点击）编译成确定性代码块，只在真正需要判断的节点调用 LLM，官方称这是为"可靠、可重复的自动化"。 这种混合范式正在成为生产标配：**确定性骨架 + LLM 关节**。Stagehand 的 `act/extract/observe` 三原语天然支持这种写法——确定性的部分直接写 Playwright 代码，只在需要语义理解时调 AI 原语，一行 AI 夹在一堆确定性代码里。代码示例最能说明这种混合： ```typescript // 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"到"敢上线"的分水岭。 ### 六、标尺陷阱：WebArena happy-path vs 生产 recovery 回到开篇的 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 决策日志，出问题能回放定位。这是把黑盒变灰盒的前提。 ```mermaid 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 + 住宅代理 + 指纹治理组合；无授权不要做——这是法律红线，不是技术问题。 **通用建议**：不要押单一栈，按任务类型分栈；自建覆盖三断裂点的内部基准，每周回归；把登录态、会话、检查点做成共享基建层，三个栈共用。**选型的真正问题不是"哪个框架最强"，而是"我的登录墙在第几步、我的反爬在第几层、我愿意为可复现性付多少确定性代码"**。 ## 参考来源 1. [Stanford AI Index 2026: WebArena 74.3% Meets the 1-in-3 Production Reality](https://agentmarketcap.ai/blog/2026/05/24/stanford-ai-index-2026-jagged-frontier-enterprise-reality) — WebArena 榜单 74.3% 与企业生产 1/3 跑通率的鸿沟量化 2. [Why Browser Agents Fail in Production — steel.dev](https://steel.dev/blog/why-browser-agents-fail-in-production) — 登录态反复重做、第 7 步重复失败的生产断裂机制 3. [Evaluating Browser-Use Agents in 2026 — FutureAGI](https://futureagi.com/blog/evaluating-browser-use-agents-2026/) — WebArena 评 happy-path、生产评 recovery 的标尺错配 4. [Browser Agent Frameworks Compared: Browser Use vs Stagehand vs Skyvern — bytetunnels](https://bytetunnels.com/posts/browser-agent-frameworks-compared-browser-use-vs-stagehand-vs-skyvern/) — 三栈 DOM-first vs 视觉 vs 混合架构横向拆解 5. [The CAPTCHA problem is really a browser-agent readiness test — baristalabs](https://www.baristalabs.io/blog/captcha-browser-agent-readiness-test) — CAPTCHA 与反爬作为自主体就绪度测试的判定逻辑 6. [Browser Use vs Stagehand — skyvern.com](https://www.skyvern.com/blog/browser-use-vs-stagehand-which-is-better/) — Python/DOM 接地与 TypeScript/Playwright 原语的官方对比 7. [Building Browser Agents: Architecture, Security, and Practical Solutions — arXiv 2511.19477](https://arxiv.org/pdf/2511.19477) — 浏览器自主体可靠性与安全挑战的学术综述 > [!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 等场景全覆盖。