Skyvern 运行引擎选型指南：run_task 与 Workflow 的正确取舍

Skyvern 运行引擎选型指南：run_task 与 Workflow 的正确取舍

【免费下载链接】skyvernAutomate browser based workflows with AI项目地址: https://gitcode.com/GitHub_Trending/sk/skyvern

本篇指南聚焦 Skyvern 的两大自动化执行入口——一次性探索用的run_task（Task）与面向真实、可复用自动化任务的 Workflow（工作流），给出可落地的选型决策框架、CLI/MCP 命令对照与工作流定义示例。读完本文，你将能根据"是否跨页面、是否可复用、是否需要调试与参数化"快速判断该用哪种引擎，并理解两者在底层执行模型（引擎 1.0/2.0/3.0）与缓存脚本上的差异。

决策总览：默认构建 Workflow

skills/skyvern/references/engines.md给出了一个非常明确的基本原则：

默认使用 Workflow 做真实的自动化工作；只有当你在做一次性的、不打算保留结果的探索尝试时，才使用skyvern_run_task。

换言之，run_task不是 Workflow 的简化版，而是一个定位完全不同的一次性探索工具。这一判断在 Skyvern 的 Skill 体系（skills/skyvern/SKILL.md 中的任务分类表）中同样得到印证：run-task被归类为 "Throwaway autonomous trial"（一次性自主试验），而workflow create被归类为 "Multi-page or reusable automation"（多页面或可复用自动化）。

什么时候选择skyvern_workflow_create

以下场景应当优先构建 Workflow，而不是运行run_task：

从源码看，Workflow 是 Skyvern 的核心一等公民：MCP 工具层注册了完整的skyvern_workflow_create / list / get / update / delete / run / status / retry / cancel工具族（见 skyvern/cli/mcp_tools/init.py），而skyvern_run_task只是其中一个单独注册的工具。Workflow 运行 ID 以wr_为前缀，与 Task 运行 ID（tsk_v2_前缀）在工具层有独立的校验逻辑（见 skyvern/cli/mcp_tools/_validation.py），这也从侧面说明两类运行在系统中是两条独立的执行链路。

用 CLI 构建并运行一个 Workflow

# 从 YAML 定义文件创建 Workflow skyvern workflow create --definition @checkout-workflow.yaml # 运行并等待结果 skyvern workflow run --id wpid_123 --wait # 按 run_id 查询状态 skyvern workflow status --run-id wr_789

Workflow 定义示例（多块表单应用）

下面的 JSON 来自 skills/skyvern/references/quick-start-patterns.md，展示了"每个页面一个 navigation 块、最后用 extraction 块取数"的标准组织方式：

{ "title": "Multi-Step Form Application", "workflow_definition": { "parameters": [ {"parameter_type": "workflow", "key": "business_name", "workflow_parameter_type": "string"}, {"parameter_type": "workflow", "key": "owner_name", "workflow_parameter_type": "string"}, {"parameter_type": "workflow", "key": "owner_id", "workflow_parameter_type": "string"} ], "blocks": [ {"block_type": "navigation", "label": "select_entity_type", "url": "https://example.com/form/step1", "title": "Select Entity Type", "navigation_goal": "Select 'Sole Proprietor' as the entity type and click Continue."}, {"block_type": "navigation", "label": "enter_business_info", "title": "Enter Business Info", "navigation_goal": "Fill in the business name as '{{business_name}}' and click Continue.", "parameter_keys": ["business_name"]}, {"block_type": "navigation", "label": "enter_owner_info", "title": "Enter Owner Info", "navigation_goal": "Enter the responsible party name '{{owner_name}}' and ID '{{owner_id}}'. Click Continue.", "parameter_keys": ["owner_name", "owner_id"]}, {"block_type": "extraction", "label": "extract_confirmation", "title": "Extract Confirmation", "data_extraction_goal": "Extract the confirmation number from the success page", "data_schema": {"type": "object", "properties": {"confirmation_number": {"type": "string"}}}} ] } }

要点：

• 用{{parameter_key}}在任意块字段中引用工作流输入参数，实现"同一套流程、不同入参"的复用；
• 同一运行中的所有块自动共享同一个浏览器会话，跨页面状态无需手动传递；
• MCP 场景下通过skyvern_workflow_create(format="json")传入同样的定义结构，随后依次调用skyvern_workflow_run与skyvern_workflow_status。

Workflow 为什么更适合"真实自动化"

在工具层，skyvern_workflow_create对workflow_definition结构有严格校验（要求包含workflow_definition对象与blocks列表，见 skyvern/cli/mcp_tools/workflow.py），每个块可以是navigation、extraction、code等类型，形成"一步一块"的可分解结构。这意味着：

• 块级可观测性：每个块独立记录运行状态，失败时可以精确定位到具体步骤；
• 可重跑：skyvern_workflow_retry可重试已终结的运行，rerun前只需修正参数与环境假设（参见 skills/skyvern/references/rerun-playbook.md）；
• 参数化：skyvern workflow run --id wpid_123 --params '{"email":"user@co.com"}'支持按次注入入参；
• 缓存脚本加速：首次运行由 AI 动态规划，后续运行会重放缓存的生成脚本（SKILL.md 中描述其速度提升可达 10–100 倍）；调试需要强制走 AI 时可用--run-with agent。

什么时候选择skyvern_run_task

skyvern_run_task是专为以下情形设计的一次性探索工具：

• 需要立即执行的一次性探索（one-off exploratory trial）；
• 结果是可丢弃的，不值得保存（disposable）；
• 你只是在验证可行性，之后再决定是否构建 Workflow。

CLI 用法

skyvern browser run-task \ --url "https://example.com" \ --prompt "Check whether the checkout flow works end to end and extract the confirmation number"

MCP 场景下对应的工具调用为：

skyvern_run_task(prompt="Try the checkout flow once and tell me whether it succeeds", url="https://example.com")

注意：run-task是一次性自主 Agent，成本更高（消耗更多 LLM 调用与截图），且不应用于周期性运行或多页面的生产级自动化。

可行性验证的标准路径

官方推荐的从"试验"到"生产"的转化路径是：先用交互式方式走一遍站点——对每个页面使用skyvern_act操作、用skyvern_screenshot验证——确认可行后，把各步骤组装为 Workflow。这也正是 skills/skyvern/references/quick-start-patterns.md 中 "Testing feasibility before building a workflow" 一节描述的工作流。

选型规则速查（Rule of Thumb）

如果任务跨越页面边界，或者听起来像"真实的自动化"而非"试验"，就先构建 Workflow。

结合 skills/skyvern/SKILL.md 的决策规则，可以归纳为如下判断流程：

1. 单页、标签清晰、不需要保留结果 →act或浏览器原语（click/type/select）即可；
2. 用户说try this once、see if this works，明确要一次性探索 →run-task；
3. 任务跨多页、要复用、要定时调度、要显式"设置成自动化"（set up）→workflow create；
4. 任何会重复运行、需要调试或交接给别人的任务，都应尽早从run-task迁移到 Workflow。

底层执行引擎：1.0、2.0 与 3.0

选型决策还涉及一个底层维度——执行引擎（engine）。从生成的 SDK 类型定义 skyvern/client/types/run_engine.py 可以看到，Skyvern 支持多种运行引擎：

"skyvern-1.0", "skyvern-2.0", "skyvern-3.0", "openai-cua", "anthropic-cua", "ui-tars", "yutori-navigator"

• skyvern-1.0（默认）与skyvern-2.0：经典的"已知路径"执行模型。SKILL.md 的描述是 "Engine: known path = 1.0 (default). Dynamic planning = 2.0."，即 1.0 为默认的已知路径执行，2.0 支持动态规划；官方建议"拿不准时优先拆成多个 1.0 块"。
• skyvern-3.0（Task V3 原生引擎）：在 skyvern/forge/agent.py 中可以看到，RunEngine.skyvern_v3将整个任务作为"一次持久化的工具循环"运行（one persistent tool-loop），而非逐块/逐步骤执行；当 Task 块不支持 V3 时会回退到步骤引擎（step engine）。V3 对块类型有支持性限制，相关逻辑同样在 skyvern/forge/sdk/experimentation/workflow_block_engine.py 中通过实验开关（treatment/control）控制。
• CUA 系列（openai-cua、anthropic-cua、ui-tars、yutori-navigator）：接入第三方计算机使用（Computer Use）Agent 的引擎，依赖对应的 LLM caller，未配置对应模型时无法启动。

对大多数读者而言，最实用的结论是：从默认的 1.0 引擎起步，每个页面一个 navigation 块；需要动态规划时再显式切换到 2.0，需要长任务持续循环时可评估 V3，但必须先确认所用块类型对 V3 的支持情况。

命令与工具对照表

下表汇总了两种执行入口在 CLI 与 MCP 工具层面的对应关系（完整工具清单见 skills/skyvern/references/tool-map.md）：

总结

选择引擎的本质是回答三个问题：任务会不会被再次运行？会不会跨页面？需不需要在块级别观察和调试？只要有一个答案是肯定的，就应该构建 Workflow；只有当答案是"一次性、可丢弃、纯探索"时，skyvern_run_task才是更合适的选择。这一"先 Workflow、后 run_task"的默认取向，加上按页面拆分块、用参数实现复用、利用脚本缓存加速的实践，能显著降低真实自动化任务的维护成本与失败排查难度。

【免费下载链接】skyvernAutomate browser based workflows with AI项目地址: https://gitcode.com/GitHub_Trending/sk/skyvern