5.3 Skyvern 对照：视觉与 DOM 混合的工作流自动化

5.3 Skyvern 对照：视觉与 DOM 混合的工作流自动化

本节摘要：本节以 Skyvern 收束视觉流派与前半本的四流派对照。Skyvern（Skyvern-AI 出品，约 2.3 万 stars，2026-10-16 社区口径）的定位是用浏览器工作流替代 RPA：视觉加 DOM 混合定位（截图与页面结构交叉验证，对应第 5.1 节混合定位形态的产品化），任务以工作流描述（导航目标、数据抽取、动作链），由自带浏览器集群的服务形态执行——这与 Midscene「嵌进测试代码的库」形成形态学对照。本节先讲混合定位机制与工作流概念，再给 Midscene 与 Skyvern 的定位差异大表（出品、许可、形态、页面表示、强项、典型场景），其中许可一栏的 AGPL-3.0 注记需要单独说明：网络服务形态的开源义务评估属于引入前的必做功课。最后补齐浏览器基建生态位：Browserbase（商业 SaaS，官网口径月 3500 万以上会话、约 1 万客户）与 steel-browser（可自托管的同类，Apache-2.0），为第 7 章会话与基建立路标。示例场景一律取授权与自有流程。

学习目标

• 说出 Skyvern 的混合定位机制与第 5.1 节三种混合形态的对应关系。
• 描述其工作流概念（导航目标、数据抽取、动作链、重试）的组成。
• 用定位差异表在 Midscene 与 Skyvern 之间选型。
• 复述 AGPL-3.0 注记的注意点与引入前的评估动作。
• 报出浏览器基建的两位成员与各自形态（SaaS 与自托管）。

一、定位与形态：服务化的工作流引擎

Skyvern 解决的问题与 RPA 同款：把重复的跨网页流程自动化——表单填报、信息搬运、后台操作。与「录制回放」式 RPA 的本质区别仍在第 0.1 节那对概念：RPA 写路径，Skyvern 写目标；页面改版时前者死、后者靠视觉加 DOM 的混合定位活下来。

形态上它是服务加工作流：自托管的 Skyvern 起一个服务，任务通过界面或 API 提交，服务在自己管理的浏览器会话里执行。这与 Midscene（库，嵌你的代码）、browser-use（库，编你的循环）、Playwright MCP（工具服务器，配你的编码 Agent）构成四种形态——前半本四个流派的「形态学」至此凑齐：

 形态光谱：谁拥有循环，谁拥有浏览器

 库（你拥有循环与浏览器）          工具服务器（你有 Agent，它有工具）    服务（它拥有循环与浏览器）
 ├─ browser-use（Agent 循环）      ├─ Playwright MCP（快照工具面）       ├─ Skyvern（工作流引擎）
 ├─ Stagehand（三原语 SDK）        ├─ DevTools MCP（调试工具面）         │   自托管，API/界面提交任务
 └─ Midscene（测试用例三件套）                                         └─ Browserbase/steel（只出浏览器）
​

这张光谱的读法：从左到右，你交出去的东西越来越多——先是浏览器（交给服务器），再是循环本身（交给服务）；换回来的依次是更省的接入成本与更完整的托管。第 7 章会在这条轴上继续向右延伸（会话基建），第 11 章会在左端讨论「什么必须留在自己手里」（可观测性与数据主权）——形态选择从来不是一次性的，随任务规模在轴上滑动才是常态。

二、视觉加 DOM 混合定位

第 5.1 节列过三种混合形态，Skyvern 属于第一种（结构化发现加视觉确认）的产品化：候选元素同时来自 DOM 分析与截图识别，两路证据交叉验证后才执行——文本对不上但图标对得上、或反过来，都能被另一路兜住。收益直接对应第 5.1 节的两个视觉失败形态：撞类似（DOM 文本消歧）与偏一点（结构化执行不依赖坐标）。代价是每步的信息处理比单通道重，这是「服务化」形态自然能背的成本（有集群、有缓存、有重试预算）。

工作流（workflow）是它的任务组织单位，组成大致为：

「重试与兜底」一行值得多看一眼：它把第 2.1 节的终止条件（步数上限、失败熔断）与第 3.2 节的重试纪律（上限加退避、降级检视）预制进了工作流引擎——用户以配置声明「这一步失败时怎么办」，引擎按声明执行。换句话说，前两章要你在代码里手搭的护栏，在这里变成了声明式字段；代价是护栏的形状受限于引擎提供的选项，要完全定制的兜底逻辑仍需回到库路线。

这张表与第 2.1 节 Agent 循环对照着读：工作流是预编排水准上的循环——步骤骨架由人定（像代码），每步内的定位与操作由模型现场决定（像 Agent），本质是第 3 章混合哲学在「服务」形态上的又一次实现。适用场景因此清晰：重复性高、跨多个页面、以表单与搬运为主的运营流程；反向不适用：需要嵌进测试体系（回 Midscene）、需要极细的循环节奏控制（回 browser-use 或 Stagehand）。

与它要替代的传统 RPA 摆在一起，差异更立体：

最后两行是形态优势的来源：集群并发让「批量」成为一等能力，分级异常处理让长尾有出口。但清醒的一条也在这张表里：维护单位从「整条」降到「单个步骤」不等于零维护——语义变更（页面概念改名、流程改规则）仍要人来改工作流定义，自动化的只是「呈现层变化」这一层。

三、与 Midscene 的定位差异表

选型口诀：测试进代码找 Midscene，流程交服务找 Skyvern。两句合规提醒先行：其一，本书对两者的示例场景都限定在自有页面与授权流程——「跨站搬运」听起来诱人，但必须落在你有权操作的账号与数据上（第 8 章展开）；其二，两者的模型调用都发生在你配置的模型上，成本观沿用第 5.1 节：Skyvern 的混合定位单步更重，批量任务的账要按条算清。

四、AGPL 注记：引入前必做的功课

Skyvern 的开源许可为 AGPL-3.0，与本书其他主角的 MIT、Apache-2.0 不同档，注记含义用两句话说清：AGPL 系许可对「以网络服务形式向用户提供」的场景附加了源码开放义务，条款细节比 MIT 严格得多；因此企业引入 AGPL 项目前，由法务或合规角色做一次许可评估是必做动作——评估范围通常包括部署形态（内部工具还是对外服务）、是否修改源码、与自有代码的链接方式。给工程侧的配合清单（让评估更快走完）：

这不是说 AGPL 不可用——大量公司在合规评估后正常使用 AGPL 组件——而是说它的使用决策比 MIT 多一道门。本书对 Skyvern 的定位是「对照学习对象」：理解其混合机制与工作流形态的价值，不因许可档位而回避，也不在未评估时把它写进生产依赖。

五、基建补位：浏览器会话的两位供应商

视觉流派与工作流形态都吃浏览器资源，前半本最后一次生态位盘点留给浏览器基建：

两者与前半本主角的关系是「地基与房子」：Stagehand 的 env 选项可以切到 Browserbase 云端会话（第 3.2 节提过）；browser-use 与各类自建系统都能把「浏览器从哪来」外包给它们。选型初判：快速起步、弹性峰谷选 SaaS；数据不出域、成本可控优先选自托管——完整的会话管理、指纹、并发与计费话题是第 7 章《会话与基建》的主场，此处立路标即止。

Skyvern 的自托管形态顺带说一句，因为它与基建选型互相影响：自托管意味着浏览器集群、任务队列与模型配置都归你管——数据面完全在内网，但要背运维面（升级、扩容、故障恢复）；用 SaaS 雨伞（如 Browserbase 出浏览器）组合自托管工作流引擎，是数据面与运维面各让一步的中间形态。这个「谁来托管什么」的谱系，第 7 章会展开成完整决策框架，本节只需带着问题离开：你的任务数据能不能出域、你的团队想背多少运维。

六、前半本收束：四流派一张图

第 5 章读完，前半本的地图可以合拢了：

                     浏览器智能体四流派（前半本 00~05 章覆盖前三）

  DOM 动作原语            结构化快照              视觉定位            验证重试
  第 1、2、3 章            第 4 章                 第 5 章             第 6 章起
  browser-use ─ 全自主     Playwright MCP ─ 官方    Midscene ─ 测试     （贯穿）
  Stagehand ─ 代码优先     DevTools MCP ─ 调试      Skyvern ─ 工作流
        │                      │                      │
        └──────── 三者共享三原语语义（act/extract/observe）──────────────┘
                               │
                               ▼
              第 6 章：无论哪种眼睛，点完都要验证（后半本开场）
​

本节要点回顾

• Skyvern：视觉加 DOM 混合定位（交叉验证防撞类似与偏一点）、工作流组织任务（骨架人定、步骤内模型定）、服务形态自带浏览器。
• 形态光谱四档：库（browser-use、Stagehand、Midscene）、工具服务器（两个 MCP）、服务（Skyvern）、地基（Browserbase 与 steel-browser）。
• 选型口诀：测试进代码找 Midscene，流程交服务找 Skyvern；示例场景限自有与授权。
• AGPL-3.0 注记：网络服务形态的开源义务更重，引入前由法务做许可评估是必做动作，工程侧备好四项材料。
• 基建两位：Browserbase（SaaS，官网口径月 3500 万以上会话）与 steel-browser（可自托管），详细归第 7 章。
• 与传统 RPA 的本质差异：任务从录制路径变成目标描述，维护单位从整条脚本降到单个步骤。
• 工作流的「重试与兜底」把前两章的护栏预制为声明式配置；完全定制的兜底仍需回库路线。
• 自托管与 SaaS 的取舍标准：任务数据能否出域、团队想背多少运维——第 7 章展开。
• 前半本至此收束：四流派合拢图把三双眼睛、两种哲学、四类形态指向第 6 章的验证开场。

前半本到此收束：你已经会用三种眼睛看页面（DOM、快照、视觉）、两种哲学组织流程（自主循环与代码优先）、四类形态部署能力（库、服务器、服务、地基）。但所有流派都留了同一个口子——点了不等于点对了。后半本从第 6 章验证与重试开始，把这个口子补上。