Skyvern 运行状态生命周期全解析从 created 到终态的状态机、暂停恢复与超时治理【免费下载链接】skyvernAutomate browser based workflows with AI项目地址: https://gitcode.com/GitHub_Trending/sk/skyvern运行状态Run Status是 Skyvern 中所有自动化实体任务 Task、工作流 Workflow Run、Observer Cruise 等的统一脉搏它决定了每一次浏览器自动化从提交到结束的每一个可观测阶段。本篇指南以仓库文档 skills/skyvern/references/status-lifecycle.md 为骨架结合源码中的状态枚举与状态机定义系统讲解状态流转路径、各状态语义、暂停与恢复机制以及基于状态做运行时治理的实战方案。读完你将能准确解读任意一次运行的当前状态、预判下一次状态迁移并为自己的业务建立超时告警与故障分诊体系。一、典型生命周期一条从创建到终态的完整路径Skyvern 将一次运行的生命周期抽象为一条线性主线。依据 skills/skyvern/references/status-lifecycle.md典型流程为created → queued → running → 终态terminal status终态共有五种运行一旦落入其中任何一个便不再发生状态迁移completed运行成功结束failed运行因错误失败canceled运行被主动取消terminated运行被终止如触发终止条件或外部干预timed_out运行超过时限而超时主线之外还有一个特殊的非终态paused运行被挂起suspended不占用执行资源且可恢复resume源码中的单一事实来源这份状态清单并非仅存在于文档中。仓库通过skyvern/schemas/run_enums.py定义了全局统一的终态集合作为同步 cron、数据库部分索引和 API 响应辅助函数的唯一依据# skyvern/schemas/run_enums.py # Statuses that are final; once a row reaches one of these, it never changes. # Single source of truth used by sync cron, partial indexes, and run response helpers. TERMINAL_STATUSES (completed, failed, terminated, canceled, timed_out)同时不同运行实体各自持有一份语义一致的状态枚举TaskStatusV1 任务skyvern/forge/sdk/schemas/tasks.pyWorkflowRunStatus工作流运行skyvern/forge/sdk/workflow/models/workflow.pyTaskV2StatusV2/Observer Cruise 任务skyvern/forge/sdk/schemas/task_v2.pyRunStatus统一运行视图skyvern/schemas/run_enums.py这些枚举都实现了is_final()方法用来快速判断某个状态是否已是终态例如TaskV2Status.is_final()直接判断[failed, terminated, canceled, timed_out, completed]五元组。二、状态机细节谁可以迁移到谁仅有状态清单还不够——状态之间并不是任意可跳转的。TaskStatus在枚举上直接内嵌了完整的迁移表can_update_to从源码结构看这正是驱动运行时校验与状态持久化的核心约束。# skyvern/forge/sdk/schemas/tasks.py#L260-L288 def can_update_to(self, new_status: TaskStatus) - bool: allowed_transitions: dict[TaskStatus, set[TaskStatus]] { TaskStatus.created: { TaskStatus.queued, TaskStatus.running, TaskStatus.timed_out, TaskStatus.failed, TaskStatus.canceled, }, TaskStatus.queued: { TaskStatus.running, TaskStatus.timed_out, TaskStatus.failed, TaskStatus.canceled, }, TaskStatus.running: { TaskStatus.completed, TaskStatus.failed, TaskStatus.terminated, TaskStatus.timed_out, TaskStatus.canceled, }, TaskStatus.failed: set(), TaskStatus.terminated: set(), TaskStatus.completed: set(), TaskStatus.timed_out: set(), TaskStatus.canceled: {TaskStatus.completed}, } return new_status in allowed_transitions[self]从迁移表可以提炼出几条重要规则终态是只出不进的死胡同failed、terminated、completed、timed_out的迁移集合都是空集set()一旦进入即永久定格。队列阶段允许直接失败/超时/取消created与queued都可以不经过running直接落到failed、timed_out或canceled——例如排队期间资源不可用、等待超时或用户撤销。唯一特例是canceled → completed取消中的运行若恰好赶上执行完成允许从canceled收敛到completed避免把已完成的结果误判为取消。只有running才能到达completed/terminated说明成功与终止都只能在真正执行阶段发生。状态携带的附加语义同一枚举还定义了状态对数据字段的约束关系skyvern/forge/sdk/schemas/tasks.pyrequires_extracted_info()仅completed强制要求有提取结果extracted information。cant_have_extracted_info()created、queued、running三个执行前/执行中状态不允许有提取结果。requires_failure_reason()failed与terminated强制要求携带失败原因——源码注释特别说明被预算上限截断的运行budget-capped run会以部分提取结果存活下来因此failed/terminated可能携带**部分partial**提取信息而执行前状态则不可能。工作流运行的细微差别WorkflowRunStatus额外引入了两个方法skyvern/forge/sdk/workflow/models/workflow.pyis_final()判断是否为五个终态之一is_final_excluding_canceled()排除canceled的终态判断。源码 docstring 解释了原因——某些调用方如 copilot 工具在mark_workflow_run_as_canceled_if_not_final已执行之后再读取数据行无法区分用户/block 发起的合理取消与兜底机制写入的合成 canceled此时必须排除 canceled 来判断真正意义上的终局。三、非终态paused挂起与恢复的完整闭环paused是工作流运行独有的非终态表示运行被挂起、随时可以恢复。它在执行链路中有两处关键落点写入侧当某个工作流 block 触发暂停条件时服务层将状态置为paused参见 skyvern/forge/sdk/workflow/models/block.py 附近的状态写入。恢复侧API 层的_continue_workflow_run完成查询暂停态 → 置回运行态的闭环# skyvern/forge/sdk/routes/agent_protocol.py#L3791-L3804 async def _continue_workflow_run(workflow_run_id: str, organization_id: str) - None: workflow_run await app.DATABASE.workflow_runs.get_workflow_run( workflow_run_idworkflow_run_id, organization_idorganization_id, statusWorkflowRunStatus.paused, # 只允许恢复 paused 状态的运行 ) if not workflow_run: raise HTTPException(status_code404, detailfWorkflow run not found {workflow_run_id}) await app.WORKFLOW_SERVICE.mark_workflow_run_as_running(workflow_run_id)也就是说只有处于paused的运行才能被恢复恢复操作实质是一次paused → running的合法迁移。为什么恢复要做得如此谨慎mark_workflow_run_as_runningskyvern/forge/sdk/workflow/service.py的实现揭示了防御性设计的用意使用条件更新update_workflow_run_if_not_final拒绝把已进入终态的运行复活为 running——这防止了清理 cron 与重入路径竞争时把timed_out误写回running若更新返回空说明已终态则记录日志 Refusing to mark workflow_run as running — already in final state 并返回现有记录恢复时还会计算并记录queued_seconds排队耗时便于排障。四、超时治理timed_out从哪来、如何配置timed_out是所有终态中唯一由时间驱动的状态也是运维中最常见的终态之一。在源码中超时通常以预设终态的方式参与流程服务层在进入 finally 收尾逻辑前先确定pre_finally_status多个分支都会将其置为WorkflowRunStatus.timed_out参见 skyvern/forge/sdk/workflow/service.py 附近的超时兜底逻辑执行器在检测到运行超时后会检查当前状态是否已是timed_out再进行后续处理skyvern/forge/agent.py 附近。与超时相关的配置项仓库的skyvern/config.py集中管理了大量超时参数以下是其中一部分关键项skyvern/config.py配置项默认值含义BROWSER_SESSION_STARTUP_TIMEOUT_SECONDS55.0浏览器会话启动超时秒BROWSER_CDP_CONNECT_TIMEOUT_MS120000CDP 连接超时毫秒BROWSER_ACTION_TIMEOUT_MS5000浏览器动作超时毫秒BROWSER_LOADING_TIMEOUT_MS60000页面加载超时毫秒BROWSER_SCREENSHOT_TIMEOUT_MS20000截图超时毫秒CODE_BLOCK_EXECUTION_TIMEOUT_SECONDS300代码块执行超时秒PAGE_READY_NETWORK_IDLE_TIMEOUT_MS3000页面就绪网络空闲判定超时毫秒PAGE_READY_DOM_STABILITY_TIMEOUT_MS3000DOM 稳定性判定超时毫秒此外工作流与任务层面支持通过max_elapsed_time_minutes字段设定单次运行的总体时间上限该字段在skyvern/client/types/workflow_run.py、skyvern/client/types/workflow.py及客户端 API 中均有暴露。文档中的运维建议为每类工作流定义最大运行时长Define max runtime per workflow class落到实践上就是将max_elapsed_time_minutes按工作流类型分层配置如数据抓取类 10 分钟、多步骤表单类 30 分钟配合系统级BROWSER_*_TIMEOUT兜底确保任何运行最终都收敛到终态而不是无限悬挂。五、运行时治理三件套最大时长、悬挂告警、失败签名skills/skyvern/references/status-lifecycle.md 在文末给出了三条操作性极强的治理建议结合源码可将其落地为可执行的监控方案。1. 按工作流类别定义最大运行时长在创建工作流/运行请求时显式传入max_elapsed_time_minutes字段已在客户端类型WorkflowRunRequestOutput等中定义对无法预先设定上限的旧运行依赖服务层超时兜底pre_finally_status timed_out分支保证终局。2. 对卡在非终态超过阈值的运行发出告警非终态集合为{created, queued, running, paused}其中paused是唯一合法长期驻留的非终态告警规则建议为running超过类别最大时长阈值、queued超过队列容忍时间可利用服务层记录的queued_seconds指标、以及paused超过业务容忍时间如凭据缺失暂停超过 N 分钟时触发判断是否终态可直接复用各枚举的is_final()或全局TERMINAL_STATUSES元组保证与仓库内部 cron、索引逻辑口径一致。3. 追踪失败签名用于优先级排序failed与terminated强制携带failure_reason见requires_failure_reason()这是失败分诊的第一手数据叠加仓库提供的失败分类failure_category字段存在于 WorkflowRun、TaskV2 等模型中可对历史运行做签名聚合同一站点、同一失败原因、同一失败类别的高频组合应获得更高修复优先级由于failed/terminated可能携带部分提取结果分诊时可保留这些阶段性输出用于复盘而不是直接丢弃。六、快速自查速查表当前状态是否终态可迁移目标备注created否queued、running、timed_out、failed、canceled刚创建尚未入队queued否running、timed_out、failed、canceled排队中可被跳过running否completed、failed、terminated、timed_out、canceled唯一通向成功/终止的阶段paused否running恢复仅工作流运行支持可恢复completed是无要求携带提取结果failed是无要求失败原因可带部分提取结果terminated是无要求失败原因可带部分提取结果canceled是completed唯一特例取消时若已完成可收敛为 completedtimed_out是无超时兜底终态结语Skyvern 的运行状态生命周期虽然只有十种状态但其背后是枚举 迁移表 条件更新构成的严谨状态机终态不可复活、paused可恢复、canceled → completed有唯一例外。理解了 skills/skyvern/references/status-lifecycle.md 中的主线流程再对照 skyvern/forge/sdk/schemas/tasks.py 的迁移表与 skyvern/forge/sdk/workflow/service.py 的防御性更新逻辑你就能准确解释任何一次运行的状态变化并为自己的工作流建立起最大时长 悬挂告警 失败签名的三层治理体系。【免费下载链接】skyvernAutomate browser based workflows with AI项目地址: https://gitcode.com/GitHub_Trending/sk/skyvern创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Skyvern 运行状态生命周期全解析：从 created 到终态的状态机、暂停恢复与超时治理
Skyvern 运行状态生命周期全解析从 created 到终态的状态机、暂停恢复与超时治理【免费下载链接】skyvernAutomate browser based workflows with AI项目地址: https://gitcode.com/GitHub_Trending/sk/skyvern运行状态Run Status是 Skyvern 中所有自动化实体任务 Task、工作流 Workflow Run、Observer Cruise 等的统一脉搏它决定了每一次浏览器自动化从提交到结束的每一个可观测阶段。本篇指南以仓库文档 skills/skyvern/references/status-lifecycle.md 为骨架结合源码中的状态枚举与状态机定义系统讲解状态流转路径、各状态语义、暂停与恢复机制以及基于状态做运行时治理的实战方案。读完你将能准确解读任意一次运行的当前状态、预判下一次状态迁移并为自己的业务建立超时告警与故障分诊体系。一、典型生命周期一条从创建到终态的完整路径Skyvern 将一次运行的生命周期抽象为一条线性主线。依据 skills/skyvern/references/status-lifecycle.md典型流程为created → queued → running → 终态terminal status终态共有五种运行一旦落入其中任何一个便不再发生状态迁移completed运行成功结束failed运行因错误失败canceled运行被主动取消terminated运行被终止如触发终止条件或外部干预timed_out运行超过时限而超时主线之外还有一个特殊的非终态paused运行被挂起suspended不占用执行资源且可恢复resume源码中的单一事实来源这份状态清单并非仅存在于文档中。仓库通过skyvern/schemas/run_enums.py定义了全局统一的终态集合作为同步 cron、数据库部分索引和 API 响应辅助函数的唯一依据# skyvern/schemas/run_enums.py # Statuses that are final; once a row reaches one of these, it never changes. # Single source of truth used by sync cron, partial indexes, and run response helpers. TERMINAL_STATUSES (completed, failed, terminated, canceled, timed_out)同时不同运行实体各自持有一份语义一致的状态枚举TaskStatusV1 任务skyvern/forge/sdk/schemas/tasks.pyWorkflowRunStatus工作流运行skyvern/forge/sdk/workflow/models/workflow.pyTaskV2StatusV2/Observer Cruise 任务skyvern/forge/sdk/schemas/task_v2.pyRunStatus统一运行视图skyvern/schemas/run_enums.py这些枚举都实现了is_final()方法用来快速判断某个状态是否已是终态例如TaskV2Status.is_final()直接判断[failed, terminated, canceled, timed_out, completed]五元组。二、状态机细节谁可以迁移到谁仅有状态清单还不够——状态之间并不是任意可跳转的。TaskStatus在枚举上直接内嵌了完整的迁移表can_update_to从源码结构看这正是驱动运行时校验与状态持久化的核心约束。# skyvern/forge/sdk/schemas/tasks.py#L260-L288 def can_update_to(self, new_status: TaskStatus) - bool: allowed_transitions: dict[TaskStatus, set[TaskStatus]] { TaskStatus.created: { TaskStatus.queued, TaskStatus.running, TaskStatus.timed_out, TaskStatus.failed, TaskStatus.canceled, }, TaskStatus.queued: { TaskStatus.running, TaskStatus.timed_out, TaskStatus.failed, TaskStatus.canceled, }, TaskStatus.running: { TaskStatus.completed, TaskStatus.failed, TaskStatus.terminated, TaskStatus.timed_out, TaskStatus.canceled, }, TaskStatus.failed: set(), TaskStatus.terminated: set(), TaskStatus.completed: set(), TaskStatus.timed_out: set(), TaskStatus.canceled: {TaskStatus.completed}, } return new_status in allowed_transitions[self]从迁移表可以提炼出几条重要规则终态是只出不进的死胡同failed、terminated、completed、timed_out的迁移集合都是空集set()一旦进入即永久定格。队列阶段允许直接失败/超时/取消created与queued都可以不经过running直接落到failed、timed_out或canceled——例如排队期间资源不可用、等待超时或用户撤销。唯一特例是canceled → completed取消中的运行若恰好赶上执行完成允许从canceled收敛到completed避免把已完成的结果误判为取消。只有running才能到达completed/terminated说明成功与终止都只能在真正执行阶段发生。状态携带的附加语义同一枚举还定义了状态对数据字段的约束关系skyvern/forge/sdk/schemas/tasks.pyrequires_extracted_info()仅completed强制要求有提取结果extracted information。cant_have_extracted_info()created、queued、running三个执行前/执行中状态不允许有提取结果。requires_failure_reason()failed与terminated强制要求携带失败原因——源码注释特别说明被预算上限截断的运行budget-capped run会以部分提取结果存活下来因此failed/terminated可能携带**部分partial**提取信息而执行前状态则不可能。工作流运行的细微差别WorkflowRunStatus额外引入了两个方法skyvern/forge/sdk/workflow/models/workflow.pyis_final()判断是否为五个终态之一is_final_excluding_canceled()排除canceled的终态判断。源码 docstring 解释了原因——某些调用方如 copilot 工具在mark_workflow_run_as_canceled_if_not_final已执行之后再读取数据行无法区分用户/block 发起的合理取消与兜底机制写入的合成 canceled此时必须排除 canceled 来判断真正意义上的终局。三、非终态paused挂起与恢复的完整闭环paused是工作流运行独有的非终态表示运行被挂起、随时可以恢复。它在执行链路中有两处关键落点写入侧当某个工作流 block 触发暂停条件时服务层将状态置为paused参见 skyvern/forge/sdk/workflow/models/block.py 附近的状态写入。恢复侧API 层的_continue_workflow_run完成查询暂停态 → 置回运行态的闭环# skyvern/forge/sdk/routes/agent_protocol.py#L3791-L3804 async def _continue_workflow_run(workflow_run_id: str, organization_id: str) - None: workflow_run await app.DATABASE.workflow_runs.get_workflow_run( workflow_run_idworkflow_run_id, organization_idorganization_id, statusWorkflowRunStatus.paused, # 只允许恢复 paused 状态的运行 ) if not workflow_run: raise HTTPException(status_code404, detailfWorkflow run not found {workflow_run_id}) await app.WORKFLOW_SERVICE.mark_workflow_run_as_running(workflow_run_id)也就是说只有处于paused的运行才能被恢复恢复操作实质是一次paused → running的合法迁移。为什么恢复要做得如此谨慎mark_workflow_run_as_runningskyvern/forge/sdk/workflow/service.py的实现揭示了防御性设计的用意使用条件更新update_workflow_run_if_not_final拒绝把已进入终态的运行复活为 running——这防止了清理 cron 与重入路径竞争时把timed_out误写回running若更新返回空说明已终态则记录日志 Refusing to mark workflow_run as running — already in final state 并返回现有记录恢复时还会计算并记录queued_seconds排队耗时便于排障。四、超时治理timed_out从哪来、如何配置timed_out是所有终态中唯一由时间驱动的状态也是运维中最常见的终态之一。在源码中超时通常以预设终态的方式参与流程服务层在进入 finally 收尾逻辑前先确定pre_finally_status多个分支都会将其置为WorkflowRunStatus.timed_out参见 skyvern/forge/sdk/workflow/service.py 附近的超时兜底逻辑执行器在检测到运行超时后会检查当前状态是否已是timed_out再进行后续处理skyvern/forge/agent.py 附近。与超时相关的配置项仓库的skyvern/config.py集中管理了大量超时参数以下是其中一部分关键项skyvern/config.py配置项默认值含义BROWSER_SESSION_STARTUP_TIMEOUT_SECONDS55.0浏览器会话启动超时秒BROWSER_CDP_CONNECT_TIMEOUT_MS120000CDP 连接超时毫秒BROWSER_ACTION_TIMEOUT_MS5000浏览器动作超时毫秒BROWSER_LOADING_TIMEOUT_MS60000页面加载超时毫秒BROWSER_SCREENSHOT_TIMEOUT_MS20000截图超时毫秒CODE_BLOCK_EXECUTION_TIMEOUT_SECONDS300代码块执行超时秒PAGE_READY_NETWORK_IDLE_TIMEOUT_MS3000页面就绪网络空闲判定超时毫秒PAGE_READY_DOM_STABILITY_TIMEOUT_MS3000DOM 稳定性判定超时毫秒此外工作流与任务层面支持通过max_elapsed_time_minutes字段设定单次运行的总体时间上限该字段在skyvern/client/types/workflow_run.py、skyvern/client/types/workflow.py及客户端 API 中均有暴露。文档中的运维建议为每类工作流定义最大运行时长Define max runtime per workflow class落到实践上就是将max_elapsed_time_minutes按工作流类型分层配置如数据抓取类 10 分钟、多步骤表单类 30 分钟配合系统级BROWSER_*_TIMEOUT兜底确保任何运行最终都收敛到终态而不是无限悬挂。五、运行时治理三件套最大时长、悬挂告警、失败签名skills/skyvern/references/status-lifecycle.md 在文末给出了三条操作性极强的治理建议结合源码可将其落地为可执行的监控方案。1. 按工作流类别定义最大运行时长在创建工作流/运行请求时显式传入max_elapsed_time_minutes字段已在客户端类型WorkflowRunRequestOutput等中定义对无法预先设定上限的旧运行依赖服务层超时兜底pre_finally_status timed_out分支保证终局。2. 对卡在非终态超过阈值的运行发出告警非终态集合为{created, queued, running, paused}其中paused是唯一合法长期驻留的非终态告警规则建议为running超过类别最大时长阈值、queued超过队列容忍时间可利用服务层记录的queued_seconds指标、以及paused超过业务容忍时间如凭据缺失暂停超过 N 分钟时触发判断是否终态可直接复用各枚举的is_final()或全局TERMINAL_STATUSES元组保证与仓库内部 cron、索引逻辑口径一致。3. 追踪失败签名用于优先级排序failed与terminated强制携带failure_reason见requires_failure_reason()这是失败分诊的第一手数据叠加仓库提供的失败分类failure_category字段存在于 WorkflowRun、TaskV2 等模型中可对历史运行做签名聚合同一站点、同一失败原因、同一失败类别的高频组合应获得更高修复优先级由于failed/terminated可能携带部分提取结果分诊时可保留这些阶段性输出用于复盘而不是直接丢弃。六、快速自查速查表当前状态是否终态可迁移目标备注created否queued、running、timed_out、failed、canceled刚创建尚未入队queued否running、timed_out、failed、canceled排队中可被跳过running否completed、failed、terminated、timed_out、canceled唯一通向成功/终止的阶段paused否running恢复仅工作流运行支持可恢复completed是无要求携带提取结果failed是无要求失败原因可带部分提取结果terminated是无要求失败原因可带部分提取结果canceled是completed唯一特例取消时若已完成可收敛为 completedtimed_out是无超时兜底终态结语Skyvern 的运行状态生命周期虽然只有十种状态但其背后是枚举 迁移表 条件更新构成的严谨状态机终态不可复活、paused可恢复、canceled → completed有唯一例外。理解了 skills/skyvern/references/status-lifecycle.md 中的主线流程再对照 skyvern/forge/sdk/schemas/tasks.py 的迁移表与 skyvern/forge/sdk/workflow/service.py 的防御性更新逻辑你就能准确解释任何一次运行的状态变化并为自己的工作流建立起最大时长 悬挂告警 失败签名的三层治理体系。【免费下载链接】skyvernAutomate browser based workflows with AI项目地址: https://gitcode.com/GitHub_Trending/sk/skyvern创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考