Skyvern 运行引擎选型指南run_task 与 Workflow 的正确取舍【免费下载链接】skyvernAutomate browser based workflows with AI项目地址: https://gitcode.com/GitHub_Trending/sk/skyvern本篇指南聚焦 Skyvern 的两大自动化执行入口——一次性探索用的run_taskTask与面向真实、可复用自动化任务的 Workflow工作流给出可落地的选型决策框架、CLI/MCP 命令对照与工作流定义示例。读完本文你将能根据是否跨页面、是否可复用、是否需要调试与参数化快速判断该用哪种引擎并理解两者在底层执行模型引擎 1.0/2.0/3.0与缓存脚本上的差异。决策总览默认构建 Workflowskills/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信号说明任务跨多个页面例如多步骤向导、结账流程、跨站数据采集用户表达了长期使用意图出现了set this up、automate、workflow、reusable、repeat、schedule等关键词需要块级可观测性每个 block步骤块都有独立的执行记录便于定位失败点需要重跑、参数化或缓存脚本Workflow 支持--params传参且后续运行可复用缓存的生成脚本预期要调试或交接给他人定义文件可版本化、可评审、可复用从源码看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 运行 IDtsk_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_789Workflow 定义示例多块表单应用下面的 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(formatjson)传入同样的定义结构随后依次调用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:userco.com}支持按次注入入参缓存脚本加速首次运行由 AI 动态规划后续运行会重放缓存的生成脚本SKILL.md 中描述其速度提升可达 10–100 倍调试需要强制走 AI 时可用--run-with agent。什么时候选择skyvern_run_taskskyvern_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 numberMCP 场景下对应的工具调用为skyvern_run_task(promptTry the checkout flow once and tell me whether it succeeds, urlhttps://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 的决策规则可以归纳为如下判断流程单页、标签清晰、不需要保留结果 →act或浏览器原语click/type/select即可用户说try this once、see if this works明确要一次性探索 →run-task任务跨多页、要复用、要定时调度、要显式设置成自动化set up→workflow create任何会重复运行、需要调试或交接给别人的任务都应尽早从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-navigatorskyvern-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.0Task 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 UseAgent 的引擎依赖对应的 LLM caller未配置对应模型时无法启动。对大多数读者而言最实用的结论是从默认的 1.0 引擎起步每个页面一个 navigation 块需要动态规划时再显式切换到 2.0需要长任务持续循环时可评估 V3但必须先确认所用块类型对 V3 的支持情况。命令与工具对照表下表汇总了两种执行入口在 CLI 与 MCP 工具层面的对应关系完整工具清单见 skills/skyvern/references/tool-map.md能力CLI 命令MCP 工具一次性探索运行skyvern browser run-task --url ... --prompt ...skyvern_run_task创建工作流skyvern workflow create --definition workflow.yamlskyvern_workflow_create运行工作流skyvern workflow run --id wpid_123 --waitskyvern_workflow_run查询运行状态skyvern workflow status --run-id wr_789skyvern_workflow_status列出/搜索工作流skyvern workflow list --search invoiceskyvern_workflow_list重试已终结运行skyvern workflow retryskyvern_workflow_retry发现/校验块类型skyvern block schema --type navigation/skyvern block validateskyvern_block_schema/skyvern_block_validate总结选择引擎的本质是回答三个问题任务会不会被再次运行会不会跨页面需不需要在块级别观察和调试只要有一个答案是肯定的就应该构建 Workflow只有当答案是一次性、可丢弃、纯探索时skyvern_run_task才是更合适的选择。这一先 Workflow、后 run_task的默认取向加上按页面拆分块、用参数实现复用、利用脚本缓存加速的实践能显著降低真实自动化任务的维护成本与失败排查难度。【免费下载链接】skyvernAutomate browser based workflows with AI项目地址: https://gitcode.com/GitHub_Trending/sk/skyvern创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Skyvern 运行引擎选型指南：run_task 与 Workflow 的正确取舍
Skyvern 运行引擎选型指南run_task 与 Workflow 的正确取舍【免费下载链接】skyvernAutomate browser based workflows with AI项目地址: https://gitcode.com/GitHub_Trending/sk/skyvern本篇指南聚焦 Skyvern 的两大自动化执行入口——一次性探索用的run_taskTask与面向真实、可复用自动化任务的 Workflow工作流给出可落地的选型决策框架、CLI/MCP 命令对照与工作流定义示例。读完本文你将能根据是否跨页面、是否可复用、是否需要调试与参数化快速判断该用哪种引擎并理解两者在底层执行模型引擎 1.0/2.0/3.0与缓存脚本上的差异。决策总览默认构建 Workflowskills/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信号说明任务跨多个页面例如多步骤向导、结账流程、跨站数据采集用户表达了长期使用意图出现了set this up、automate、workflow、reusable、repeat、schedule等关键词需要块级可观测性每个 block步骤块都有独立的执行记录便于定位失败点需要重跑、参数化或缓存脚本Workflow 支持--params传参且后续运行可复用缓存的生成脚本预期要调试或交接给他人定义文件可版本化、可评审、可复用从源码看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 运行 IDtsk_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_789Workflow 定义示例多块表单应用下面的 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(formatjson)传入同样的定义结构随后依次调用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:userco.com}支持按次注入入参缓存脚本加速首次运行由 AI 动态规划后续运行会重放缓存的生成脚本SKILL.md 中描述其速度提升可达 10–100 倍调试需要强制走 AI 时可用--run-with agent。什么时候选择skyvern_run_taskskyvern_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 numberMCP 场景下对应的工具调用为skyvern_run_task(promptTry the checkout flow once and tell me whether it succeeds, urlhttps://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 的决策规则可以归纳为如下判断流程单页、标签清晰、不需要保留结果 →act或浏览器原语click/type/select即可用户说try this once、see if this works明确要一次性探索 →run-task任务跨多页、要复用、要定时调度、要显式设置成自动化set up→workflow create任何会重复运行、需要调试或交接给别人的任务都应尽早从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-navigatorskyvern-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.0Task 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 UseAgent 的引擎依赖对应的 LLM caller未配置对应模型时无法启动。对大多数读者而言最实用的结论是从默认的 1.0 引擎起步每个页面一个 navigation 块需要动态规划时再显式切换到 2.0需要长任务持续循环时可评估 V3但必须先确认所用块类型对 V3 的支持情况。命令与工具对照表下表汇总了两种执行入口在 CLI 与 MCP 工具层面的对应关系完整工具清单见 skills/skyvern/references/tool-map.md能力CLI 命令MCP 工具一次性探索运行skyvern browser run-task --url ... --prompt ...skyvern_run_task创建工作流skyvern workflow create --definition workflow.yamlskyvern_workflow_create运行工作流skyvern workflow run --id wpid_123 --waitskyvern_workflow_run查询运行状态skyvern workflow status --run-id wr_789skyvern_workflow_status列出/搜索工作流skyvern workflow list --search invoiceskyvern_workflow_list重试已终结运行skyvern workflow retryskyvern_workflow_retry发现/校验块类型skyvern block schema --type navigation/skyvern block validateskyvern_block_schema/skyvern_block_validate总结选择引擎的本质是回答三个问题任务会不会被再次运行会不会跨页面需不需要在块级别观察和调试只要有一个答案是肯定的就应该构建 Workflow只有当答案是一次性、可丢弃、纯探索时skyvern_run_task才是更合适的选择。这一先 Workflow、后 run_task的默认取向加上按页面拆分块、用参数实现复用、利用脚本缓存加速的实践能显著降低真实自动化任务的维护成本与失败排查难度。【免费下载链接】skyvernAutomate browser based workflows with AI项目地址: https://gitcode.com/GitHub_Trending/sk/skyvern创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考