Skyvern 是一个开源浏览器自动化框架,用视觉语言模型(VLM,能同时理解图像和文字的模型)解析网页截图,配合大语言模型(LLM)规划动作,用户用自然语言描述目标即可自动完成网页操作——比如搜索商品加入购物车、填写表单、抓取结构化数据。它解决的核心问题是传统自动化脚本过度依赖 CSS 选择器与页面结构:站点一改版脚本就失效,且每个网站都要单独写一套代码。Skyvern 把“怎么操作页面”交给模型实时推理,把“要完成什么”留给用户描述,从而大幅降低维护成本。 框架核心由 FastAPI 服务、React 工作流编辑器和 Playwright 驱动的执行引擎组成,底层依赖 PostgreSQL 持久化任务数据、Redis 做队列与限流。1.0 版本引入块(Block)工作流编排后,任务从单步目标扩展为可组合、可参数化的多阶段流程。本攻略按“速览 → 安装 → 上手 → 能力拆解 → 生产部署 → 对比与避坑”的顺序组织,覆盖从本地搭建到生产落地的完整路径。
掌握 Skyvern 意味着能用一份自然语言任务定义替代大量易碎的爬虫与自动化脚本,是 RAG 数据管道、流程自动化与 AI Agent 落地场景中的实操加分项。
目录
速览卡是工具类内容的固定首屏模块:30 秒判断「这工具是什么、能不能商用、适不适合我」。
为什么需要 Skyvern:从“选择器会失效”到“目标式自动化”
传统浏览器自动化的痛点集中在选择器与页面结构上:CSS 选择器和 XPath 依赖的 DOM 结构、class 命名、加载时序,任何一次前端改版都会导致脚本批量失效;单页应用(SPA,前端动态渲染整页内容的网页架构)还需要处理等待、滚动、弹窗等大量时序问题。一个中等规模的采集项目,通常要为每个目标站点维护一套独立脚本,改版时排查成本远高于写脚本本身。跨站点的表单填写、登录后操作、分页抓取等流程,在无头浏览器(不带界面的浏览器实例)里需要数百行样板代码。
Skyvern 的解法是把页面理解与动作生成全部交给模型:视觉语言模型对截图做多尺度解析,识别出“登录按钮”“价格字段”这类语义元素,大语言模型根据目标描述规划下一步动作,执行后再截图观察,循环直到目标完成或判定失败。整个过程不依赖任何选择器,站点改版后 Agent 会基于新的视觉输入重新推理,这就是它所谓的“自愈”特性。
与同类工具的气质差异在于:Skyvern 用“可解释的视觉推理”换取“弹性的页面适配”,而不是像确定性框架那样追求可预测的执行。代价是每次任务都消耗 LLM 调用、结果存在不确定性,因此它更适合需要跨站点泛化的采集与流程自动化场景,而不是对每一步都有严格断言的 E2E 测试。
安装与环境配置:6 步就绪
前置条件:本机安装 Docker 与 Docker Compose v2,并准备至少一个 LLM 服务的 API Key(OpenAI、Anthropic 或 Google Gemini 均可)。
第一步,克隆仓库并进入目录。第二步,复制环境变量模板生成 .env 文件。第三步,编辑 .env,填入 LLM Key(例如 OPENAI_API_KEY=sk-... 或 ANTHROPIC_API_KEY=sk-ant-...)。第四步,启动全部服务,首次构建需拉取镜像和 Python 依赖,耗时数分钟。第五步,验证服务:UI 界面在 8080 端口,API 自动生成的 Swagger 文档在 8000 端口的 /docs 路径。第六步,若 .env 中配置了 SKYVERN_API_KEYS,在 UI 设置中填入一致密钥后再创建任务;未配置该变量时本地访问无需鉴权。
注意:docker compose 会同时拉起 PostgreSQL(5432)、Redis(6379)、server(8000)、worker 与 UI(8080)。若本机 5432/6379 端口被占用,需先停止相应服务或修改 .env 中的端口映射。
git clone https://github.com/Skyvern-AI/skyvern.gitcd skyverncp .env.example .env# 编辑 .env:至少配置一个 LLM Key,如 OPENAI_API_KEY / ANTHROPIC_API_KEYdocker compose up --build# 验证入口:UI http://localhost:8080,API 文档 http://localhost:8000/docs
快速上手:10 分钟跑通第一个任务
最小可用流程是“一个网址 + 一句目标描述”。任务定义分三部分:url 指定起点页面,navigation_goal 描述要执行的操作,data_extraction_goal 描述要提取的结构化信息。Skyvern 返回任务 ID 后异步执行,每一步动作的推理文本与截图都会保存在任务详情中。
1. 打开 http://localhost:8080,在任务创建区粘贴目标 URL,例如 https://www.amazon.com。
2. 在导航目标输入框填写自然语言操作目标,例如“搜索 men's running shoes 并把第一件商品加入购物车”。
3. 可选:填写数据提取目标,例如“提取商品标题、价格与评分”。
4. 点击创建按钮提交任务,页面自动进入任务详情视图。
5. 在动作轨迹中查看每一步推理与截图;状态变为 completed 后,查看 extracted_information 字段获得结构化结果。
程序化调用使用同一套任务模型,通过 REST API 提交并轮询状态:
进阶技巧:任务接口支持 webhook_callback_url 参数,服务端在任务结束时会回调该地址,不必轮询;目标页面结构复杂时,把 data_extraction_goal 写具体,Agent 会在执行中顺带完成提取,避免二次解析页面。
import timeimport requests BASE = "http://localhost:8000"HEADERS = {"x-api-key": "your-key"} # 未配置 SKYVERN_API_KEYS 时可留空 r = requests.post( f"{BASE}/api/v1/tasks", headers=HEADERS, json={ "url": "https://www.amazon.com", "navigation_goal": "搜索 men's running shoes,把第一件商品加入购物车", "data_extraction_goal": "提取商品标题、价格和评分", },)task_id = r.json()["task_id"] for _ in range(120): detail = requests.get(f"{BASE}/api/v1/tasks/{task_id}", headers=HEADERS).json() if detail["status"] in {"completed", "failed", "cancelled"}: break time.sleep(5) print(detail["status"])print(detail.get("extracted_information"))
核心能力详解:4 大支柱
支柱一 · 视觉感知与多尺度页面解析。Skyvern 对页面截图做多个缩放级别的视觉解析,配合 DOM 可访问性树生成候选元素,再交给 VLM 统一理解。相比纯 DOM 方案,它能感知“视觉上可见”的内容(对比度、遮挡、弹窗遮罩),CSS 类名和 DOM 结构调整不影响元素识别。对文本密集页面(PDF、长文档渲染后的网页),可配置 OCR 服务辅助提取文字。
支柱二 · 目标式执行与自愈循环。执行内核是“观察 → 推理 → 动作 → 再观察”的递归循环:每一步由 LLM 根据当前页面状态生成下一步动作(点击、输入、滚动、选择、等待),命中异常时允许回溯并尝试替代路径。内置对下拉框、日期选择器、条件必填项、新标签页弹窗等常见干扰项的识别,不需要用户预写处理逻辑。
支柱三 · 工作流编排(1.0 Block)。1.0 将执行单元从“单个任务”升级为“工作流”:用 task(子任务)、action(指定动作)、for_loop(循环)、code(Python 代码块)、text_prompt(提示词块)、file_url_parser(文件解析)等块拼接多阶段流程,块之间可传参,参数支持模板注入。UI 提供可视化编排界面,API 侧对应 /api/v1/workflows 与 /api/v1/workflows/runs。
支柱四 · 人机协同与安全边界。blocked 模式在 Agent 不确定时暂停并请求人工确认;payment_mode 在支付、下单类动作前强制人工审批,防止自动扣款;敏感数据可声明为 secrets,在日志中脱敏。任务全程记录每一步的推理文本、动作与截图,形成可审计的执行轨迹,并支持结束回调(webhook)。
生产部署与监控:从上线到运维
部署方式一:单机 docker compose。适合试点与小流量场景,一条命令拉起全部组件,数据落在本地 PostgreSQL。局限是 worker 与 server 在同一进程组,任务量大时执行队列会堆积,且不持久化卷备份时数据有丢失风险。
部署方式二:自建生产架构。将 compose 拆分为基础服务(PostgreSQL、Redis)与应用服务(server、worker、ui)两组编排,worker 可水平扩容;server 与 worker 通过数据库和 Redis 解耦,任务提交后由 worker 消费执行。前端加 Nginx/Caddy 反向代理并强制 HTTPS,在 .env 中配置 SKYVERN_API_KEYS 开启所有 API 的请求鉴权。无头浏览器由 worker 内部的 Playwright 实例管理,可按目标站点配置住宅代理与验证码服务(Capsolver、2Captcha),提取结果回写数据库或 S3。
可观测性:服务端为 FastAPI 标准结构,自带结构化 JSON 日志与 /docs 接口;任务维度关注状态机终态(completed / failed / cancelled)、平均步数、耗时与 LLM token 消耗;动作维度通过任务详情中的分步截图定位失败节点。生产环境建议把失败任务通过 webhook 接入告警系统(Slack/钉钉),并对失败率超过阈值的站点切换代理或降低并发。
<p class="para-label">避坑清单:</p>
<ul class="dash-list"><li>不配置 LLM Key 直接创建任务:执行在第一步即失败,先检查 .env 中 OPENAI_API_KEY / ANTHROPIC_API_KEY 是否正确;</li><li>把 .env 提交进 Git:内含 API Key 与数据库密码,仓库初始化时就应加入 .gitignore;</li><li>期望 100% 成功率:Agent 仍会卡在 Cloudflare 严格反爬、复杂验证码与登录墙前,先跑通单任务再上规模;</li><li>裸奔 8000/8080 端口:公网暴露前必须加反向代理与 API 鉴权,否则任何人可提交任务消耗你的 LLM 额度;</li><li>自动结账不加支付确认:涉及真实资金的操作必须开启 payment_mode 强制人工审批;</li><li>忽略 AGPL 合规:修改后通过网络对外提供服务需开放源码,商业闭源集成前先做 License 评估。</li></ul>
| 维度 | Skyvern | Playwright | Browser Use | MultiOn |
|---|---|---|---|---|
| 定位 | 视觉驱动网页自动化框架(开源) | 确定性浏览器自动化测试框架 | LLM 驱动浏览器 Agent 开源框架 | 托管式网页 Agent 平台 |
| 编排范式 | 自然语言目标 → VLM 视觉解析 → LLM 规划动作 | 手写代码 + CSS/XPath 选择器 | 自然语言指令 + LLM 工具循环(DOM/视觉混合) | 自然语言指令 → 云端 Agent 执行 |
| 类型约束 | 无选择器依赖,页面改版自适应 | 强选择器约束,改版即需改脚本 | 弱选择器依赖,可自定义感知方式 | 无约束,黑盒执行 |
| 学习曲线 | 中:目标描述 + 任务调试 | 高:编程 + 选择器/等待调试 | 中:Prompt 与 Agent 配置 | 低:开箱即用 |
| 生态集成 | REST API、webhook、Docker、PG/Redis、工作流 UI | 语言 SDK 最全(Python/JS/Java 等) | Python 库、可插拔模型、可与 LangChain 搭配 | 商业 API + 托管 UI |
| 生产部署 | 自托管 Docker,worker 可水平扩展 | 自建或托管(Browserless 等) | 自托管为主,需自建编排与监控 | 完全托管,按量付费 |
| License | AGPL-3.0 | Apache-2.0 | MIT | 闭源商业 |
| 适合谁 | RAG 采集、跨站点流程自动化、需要自愈的团队 | 前端测试、稳定站点 E2E | 想用 LLM 快速搭建网页 Agent 原型的开发者 | 没有工程资源、按用量采购的业务方 |
选型建议:站点固定且流程稳定就选 Playwright,确定性最高;需要快速做多模态 Agent 原型研究选 Browser Use;要跨大量站点做数据采集与流程自动化、接受自托管运维,选 Skyvern;完全不想运维、按次付费则评估 MultiOn。注意 License 差异——AGPL 对闭源商用是硬约束。
版本迭代
Skyvern 2024 年夏季开源,演进主线是从“单任务自动执行”升级为 1.0 的“可组合工作流平台”,期间以 0.x 系列持续增强执行稳定性、代理与验证码支持(截至训练数据,可能已有更新版本)。
| 版本 | 时间 | 变化 | 提升 |
|---|---|---|---|
| 0.1.0 | 2024-07 | 首个公开版本 | 自然语言任务 + 多尺度视觉解析 + 递归动作循环,支持导航与数据提取目标 |
| 0.4.0 | 2024-11 | 执行可靠性与可观测性 | 任务详情升级与分步截图回放、代理与验证码服务接入、动作权限约束 |
| 1.0.0 | 2025-01 | 工作流架构重写 | 引入 Block 工作流(task/action/for_loop/code 等)、参数注入、UI 可视化编排,API 聚焦 workflows 与 runs |
1.0 是架构级换代,把产品从“一个 Agent 跑一个目标”升级为“可编排的多阶段自动化平台”,代码块支持后处理、循环块支持批量执行。官方未发布与第三方工具的统一基准评测分数,选型时建议按自己的目标站点与任务类型做小样本自测,对比成功率、步数与耗时。
AI 应用场景
电商竞品数据采集与价格监控(RAG 数据管道)
阶段:RAG 数据管道构建 / 文档智能
解决的问题:传统采集脚本用选择器定位价格、库存字段,电商页面频繁 A/B 测试与改版导致脚本每周都要修;按站点定制还意味着同一套逻辑重复开发。Skyvern 用自然语言目标替代选择器,同一份任务定义可在多个站点复用,改版后 Agent 依据视觉输入重新推理。
具体案例:某团队用 Skyvern 监控多个电商平台的商品价格与库存,每小时提交一次任务并写入 PostgreSQL,再灌入 RAG 检索库。原有 6 个站点各自维护一套脚本,改用 Skyvern 后统一为 3 个工作流模板,改版导致的脚本修复从每周多次降为接近零,新增站点只需补充一个 URL 和两句目标描述。
后台办公流程自动化(跨系统表单录入)
阶段:Agent 编排 / 业务流程自动化
解决的问题:ERP/CRM 等后台系统没有开放 API,或第三方供应商门户只提供网页操作入口,靠人工复制粘贴效率低且易错。Skyvern 识别表单字段语义(如“发票号”“金额”),配合参数化工作流实现跨系统数据搬运。
具体案例:供应链部门需每天将供应商门户的订单状态同步进内部系统。用 Skyvern 编排“登录供应商门户 → 读取订单页 → 提取状态字段 → 写入内部表单”四个 task 块,首次登录由人工确认,后续自动执行。在典型用例中,单条订单录入从 3 分钟人工操作缩短到约 20 秒自动执行,且全程留档每一步截图。
为 AI Agent 提供网页操作能力
阶段:Agent 编排 / 工具调用
解决的问题:LLM 的能力边界在“读”,网页操作(登录、点击、上传、付款确认)此前要逐个手写工具函数。Skyvern 以 REST API 将网页操作封装为可被外部 Agent 调用的能力,结果结构化返回,还可通过 webhook 异步通知。
具体案例:某 AI 助手在回答“帮我在 XX 网站下单”类请求时,把任务推给 Skyvern API,Agent 只负责语义解析与结果汇总。配合 blocked 模式,在下单前暂停请求用户确认,既保持自动化又守住资金安全红线。
常见误区
误区很多第一次看到 Skyvern 的人认为它就是用 Playwright 多写了一个库,本质还是 CSS/XPath 选择器驱动,只是封装得好看一点。
正解Skyvern 底层确实使用 Playwright 管理浏览器实例,但页面理解与动作生成机制完全不同。它通过 VLM 解析多尺度截图和 DOM 可访问性树识别语义元素,动作由 LLM 逐轮推理产生,不存在“写死选择器”这一环。页面改版后,模型依据新的视觉输入重新决策,这正是它区别于传统封装的核心。
为何常见:从技术栈上看 Skyvern 依赖 Playwright,文档中也大量出现浏览器控制相关术语,容易被归入“Playwright 封装”一类。
误区以为任意网站的任务都能自动完成,从不考虑登录态、Cloudflare 人机验证、验证码和风控。
正解Skyvern 需要明确的访问上下文:受登录保护的页面要预先持有会话(文档支持通过注入 Cookie 或认证头维持状态);验证码依赖配置第三方求解服务(Capsolver、2Captcha 等);Cloudflare 等强反爬站点在住宅代理配合下仍可能失败。任务描述里应声明目标站点类型与访问前提,并在小样本上先验证成功率。
为何常见:官方演示视频展示的往往是无登录、无反爬的公开站点,用户容易把演示效果推广到全部站点。
误区状态是 completed,就认为导航目标和提取目标全部稳定达成,直接信任返回结果入库。
正解completed 表示 Agent 认为目标流程已走完,不代表业务上正确。需要在工作流或任务后处理中校验 extracted_information 的完整性(字段非空、类型正确、数值在合理范围),并对缺字段的任务设置重试与告警。Agent 类系统的输出天然带不确定性,生产管道必须在数据层做二次校验。
为何常见:传统脚本成败是二元的,而 Agent 执行是概率性的,沿用“状态等于结果”的惯性思维导致数据质量问题。
误区docker compose up 成功、UI 能创建任务,就认为可以直接对外提供服务。
正解本地 compose 默认把 API(8000)和 UI(8080)端口直接暴露,无鉴权、无 HTTPS、数据落本地盘。上生产至少要:配置 SKYVERN_API_KEYS 开启鉴权、反向代理加 TLS、PostgreSQL 持久卷与备份、worker 独立扩容、失败任务告警。否则任何人都能提交任务消耗你的 LLM 额度,且服务无恢复能力。
为何常见:compose 文件把 PostgreSQL、Redis、worker 等生产组件都写齐了,容易让使用者误以为这就是生产配置。
误区开源等于可以闭源集成进自己的商业产品,改完代码对外卖也不用开源。
正解AGPL-3.0 是强 copyleft 协议,不仅分发的修改版本必须开源,通过网络提供服务(SaaS)的用户也有权获取源码。对 Skyvern 做二次开发并对外提供服务,需要开放相应修改代码;想闭源商用,应评估官方托管服务或商业授权,而不是直接改协议。
为何常见:很多团队只区分“免费/付费”,不区分 MIT/Apache/AGPL 的传染性差异,开源协议条款又长又难读。
面试题
Q1. Skyvern 1.0 的核心执行单元从“单任务”升级为什么?
- A.工作流 Workflow 编排← 正确答案
- B.选择器 Selector 列表
- C.浏览器扩展 Extensions
- D.无头浏览器 Headless 引擎
答案:A。1.0 的核心变化是引入 Block 工作流,把执行单元从单个 task 升级为可组合的 workflow。选择器、浏览器扩展和无头浏览器都不是 1.0 新增的执行单元,其中无头浏览器只是底层运行环境。
Q2. Skyvern 理解页面元素主要依赖什么技术?
- A.视觉语言模型解析页面截图← 正确答案
- B.正则表达式匹配页面源码
- C.CSS 选择器精确定位元素
- D.XPath 路径表达式定位元素
答案:A。Skyvern 的核心是 VLM 对多尺度截图做视觉解析,识别语义元素后由 LLM 决策动作。正则是传统爬虫手段,CSS/XPath 是确定性框架的定位方式,Skyvern 刻意不依赖它们。
Q3. 本地 docker compose 启动后,API 与 UI 的默认端口分别是?
- A.8000(API)与 8080(UI)← 正确答案
- B.3000(API)与 8000(UI)
- C.8080(API)与 443(UI)
- D.5432(API)与 6379(UI)
答案:A。Skyvern 的 server 默认监听 8000,UI 由 Nginx 提供在 8080;5432 是 PostgreSQL、6379 是 Redis 的端口,3000 是常见的 Node 服务端口,均非 Skyvern API/UI 默认端口。
Q4. 下列哪些属于 Skyvern 1.0 工作流的块(Block)类型?
- A.Task 任务执行块← 正确答案
- B.For Loop 循环块← 正确答案
- C.Code 代码执行块← 正确答案
- D.Css Selector 选择器块
答案:ABC。官方列出的块类型包括 task、action、for_loop、code、text_prompt、file_url_parser 等。不存在“CSS 选择器块”,因为 Skyvern 的设计前提就是不依赖选择器,这是它与确定性框架的本质区别。
Q5. 任务 API 中指定“要提取哪些结构化信息”的字段是?
- A.data_extraction_goal(提取结构化信息)← 正确答案
- B.navigation_goal(导航操作目标)
- C.webhook_callback_url(任务结束回调)
- D.proxy_location(指定代理地域)
答案:A。data_extraction_goal 声明提取目标,配合提取模式可返回结构化 JSON。navigation_goal 描述操作动作,webhook_callback_url 是异步回调地址,proxy_location 指定代理类型,均不承担提取声明职责。
Q6. 关于 CAPTCHA 验证码,Skyvern 的处理方式是?
- A.内置专用模型自行破解
- B.集成第三方求解服务← 正确答案
- C.遇到验证码直接失败
- D.自动开挂绕过所有验证码
答案:B。Skyvern 不内置破解模型,而是在 .env 中配置 Capsolver、2Captcha 等服务商的 API Key,识别到验证码时调用第三方求解。它无法绕过所有验证码,更不存在“自动开挂”能力。
Q7. Skyvern 与确定性自动化框架(如 Playwright)相比,正确的说法有?
- A.Skyvern 不依赖 CSS 选择器定位元素← 正确答案
- B.Skyvern 对页面改版具有更强的鲁棒性← 正确答案
- C.Skyvern 底层完全不使用 Playwright
- D.确定性框架更适合对每步严格断言的测试← 正确答案
答案:ABD。Skyvern 通过视觉解析定位元素,改版后基于新截图重新推理,因此 A、B 正确。但 Skyvern 底层正是用 Playwright 管理浏览器,C 错误。确定性框架执行可预测、可断言,适合 E2E 测试,D 正确。
Q8. Skyvern 的生产部署通常需要哪些基础设施组件?
- A.PostgreSQL 持久化任务数据← 正确答案
- B.Redis 承担队列与限流← 正确答案
- C.Playwright 无头浏览器运行环境← 正确答案
- D.仅需一个前端静态托管服务
答案:ABC。官方 compose 和部署文档使用 PostgreSQL 存任务与工作流元数据、Redis 做队列和限流,worker 内运行 Playwright 执行浏览器动作。Skyvern 不是纯前端应用,仅做静态托管无法执行任务。
Q9. Skyvern 的 payment_mode 选项作用是什么?
- A.支付操作前强制人工确认← 正确答案
- B.自动填入所有支付信息
- C.提高支付接口成功率
- D.仅支持虚拟信用卡支付
答案:A。payment_mode 是安全开关,在检测到支付、下单类敏感动作时暂停执行并请求人工确认,防止 Agent 自动扣款。它不代填支付信息,也不提升支付成功率,与支付方式种类无关。
Q10. 运行 Skyvern 之前,环境配置中最关键的一步是?
- A.配置 LLM 提供商 API Key← 正确答案
- B.安装 Node.js 运行时
- C.申请公网固定 IP 地址
- D.购买独立显卡计算资源
答案:A。Skyvern 的视觉理解与动作规划都依赖 LLM/VLM 服务,不配置 Key 任务第一步就会失败。Node.js 仅影响部分前端构建,固定 IP 与显卡不是运行必要条件,docker compose 已封装好运行时依赖。
参考来源
- webpageSkyvern GitHub 仓库源码、Release 与 Issue
- docSkyvern 官方文档安装、API 与工作流指南
- webpageSkyvern 官网产品定位与托管云服务入口
- docskyvernhq Docker Hubserver/ui 官方镜像与版本标签