2026/9/11 16:43:21
FEATURED · 精选文章 
Conductor 任务生命周期完全指南状态流转、重试机制与超时策略【免费下载链接】conductorConductor is an event driven agentic workflow engine providing durable and highly resilient execution engine for applications and AI Agents项目地址: https://gitcode.com/GitHub_Trending/co/conductor本文是 Conductor 工作流引擎中任务Task生命周期管理的权威参考。从SCHEDULED到COMPLETED或FAILED每个任务在运行期间都会经历一系列状态迁移理解这些迁移是正确配置重试retry、超时timeout与错误处理的前提。读完本文你将能够精确解读任务状态机与超时语义为任务定义写出正确且可落地的TaskDef配置并在生产环境中诊断任务卡住、超时、反复失败等经典问题。一、为什么需要理解任务生命周期在 Conductor 的事件驱动型工作流引擎中一个工作流实例Workflow由若干任务Task组成每个任务在生命周期内会经历一系列状态迁移。系统级任务如 HTTP、Inline、DoWhile 等由服务端执行而用户自定义任务由 Worker 进程轮询poll执行。无论哪种形态任务的每一次执行都以状态的形式被持久化——这正是 Conductor 实现持久化执行durable execution的根基任务状态不是内存中的瞬时变量而是可以随时恢复、重试、审计的持久化事实。从源码结构看任务状态的权威定义位于 TaskModel.java 中的Status枚举每个状态用三个布尔属性描述其语义public enum Status { IN_PROGRESS(false, true, true), CANCELED(true, false, false), FAILED(true, false, true), FAILED_WITH_TERMINAL_ERROR(true, false, false), COMPLETED(true, true, true), COMPLETED_WITH_ERRORS(true, true, true), SCHEDULED(false, true, true), TIMED_OUT(true, false, true), SKIPPED(true, true, false); private final boolean terminal; // 是否为终态 private final boolean successful; // 是否算成功 private final boolean retriable; // 是否可重试 ... }这个枚举直接印证了文档中状态图的核心结论除了SCHEDULED与IN_PROGRESS其余状态全部是终态terminal而FAILED、TIMED_OUT虽然本身是终态但被标记为retriable意味着它们可以在满足重试条件时复活为新的执行SCHEDULED。COMPLETED_WITH_ERRORS则同时是终态、成功态且可重试——这正是可选任务optional task的语义任务失败了但工作流选择继续走下去。二、任务状态机一张图看懂所有流转每个任务在其生命周期中遵循以下状态迁移来自 tasklifecycle.md 的状态图mermaid 语法可被 GitHub 与主流文档工具直接渲染2.1 状态一览表状态说明SCHEDULED任务已入队等待 Worker 轮询。IN_PROGRESSWorker 已领取任务并正在执行。COMPLETED任务成功完成。FAILED任务因错误失败Conductor 会根据任务定义的 retry 配置进行重试。FAILED_WITH_TERMINAL_ERROR任务以不可重试错误失败不做任何重试。TIMED_OUT任务超过配置的超时时间Conductor 会按 retry 配置重试。CANCELED因工作流被终止而取消。SKIPPED通过 Skip Task API 跳过工作流继续执行下一个任务。COMPLETED_WITH_ERRORS任务失败但在工作流定义中被标记为 optional可选工作流继续。2.2 状态语义的源码依据FAILED_WITH_TERMINAL_ERROR在Status枚举中标记为terminaltrue, successfulfalse, retriablefalse即一次性终态绝不重试。从源码结构看它通常由系统级任务在重试无意义的场景下设置例如 DoWhile.java 在执行循环任务遇到不可恢复错误时会将循环体任务置为该状态避免无意义的无限重试。COMPLETED_WITH_ERRORS则被标记为terminaltrue, successfultrue, retriabletrue工作流决策器Decider在 DeciderService.java 中将**可选任务optional**的失败任务置为COMPLETED_WITH_ERRORS工作流视其为成功完成但有错误从而继续推进后续任务。三、重试机制自动重排与重试策略当一个任务以可重试错误失败FAILED时Conductor 会按配置的延迟自动重新调度reschedule该任务。以下时序图完整呈现了一次失败重试的全过程3.1 重试相关的 TaskDef 参数参数说明retryCount最大重试次数。retryLogicFIXED、EXPONENTIAL_BACKOFF或LINEAR_BACKOFF详见 TaskDef 配置文档。retryDelaySeconds重试之间的基础延迟秒。maxRetryDelaySeconds计算所得延迟的上限防止指数退避无限增长。backoffJitterMs为每次延迟附加随机毫秒数将并发重试在时间上打散。totalTimeoutSeconds横跨所有尝试的硬性墙钟预算详见总超时一节。3.2 重试延迟的源码级计算重试延迟的真正计算发生在决策器 DeciderService.java 中其逻辑与TaskDef字段一一对应FIXED固定每次重试延迟固定为retryDelaySeconds。LINEAR_BACKOFF线性退避延迟 retryDelaySeconds × backoffScaleFactor × (retryCount 1)即随尝试次数线性增长。EXPONENTIAL_BACKOFF指数退避延迟 retryDelaySeconds × 2^retryCount即每多一次尝试延迟翻倍。所有策略在计算后都会经过applyMaxRetryDelayCap应用maxRetryDelaySeconds上限随后若配置了backoffJitterMs 0会通过ThreadLocalRandom.current().nextLong(0, backoffJitterMs 1)产生[0, backoffJitterMs]的随机毫秒抖动叠加到秒级延迟上最终以毫秒精度写入callbackAfterMs。这正是打散并发重试、避免羊群效应的实现细节。3.3 关键默认值来自 TaskDef.java从TaskDef源码字段的默认值可以直接得到以下事实retryCount默认3retryLogic默认FIXEDretryDelaySeconds默认60秒responseTimeoutSeconds默认3600ONE_HOUR即 1 小时maxRetryDelaySeconds默认0不设上限backoffJitterMs默认0无抖动totalTimeoutSeconds默认0不设总预算timeoutPolicy默认TIME_OUT_WF。四、超时场景poll / response / task 三种超时超时是分布式系统中任务既不成功也不失败时的兜底机制。Conductor 区分三种超时理解它们的区别是配置正确性的关键。4.1 Poll timeout轮询超时若在pollTimeoutSeconds内没有 Worker 轮询该任务任务被标记为TIMED_OUT这通常意味着任务队列积压backlogged queue或 Worker 数量不足。从配置层面看pollTimeoutSeconds在TaskDef中默认不设置Integer pollTimeoutSeconds默认为null即无超时需要按队列积压容忍度显式配置。4.2 Response timeout响应超时Worker 已轮询到任务但在responseTimeoutSeconds内未回报结果任务被标记为TIMED_OUT。该机制专门兜底Worker 执行中途崩溃的场景Worker 可以延长响应超时在轮询到任务后持续上报IN_PROGRESS状态并携带callbackAfterSeconds值表示我还在执行请再等 N 秒。默认responseTimeoutSeconds为 1 小时见上文源码默认值但实践中建议按任务实际耗时收紧。4.3 Task timeout任务超时 / 单次尝试 SLAtimeoutSeconds是单次尝试的整体 SLA即使 Worker 不断发送IN_PROGRESS心跳只要累计耗时超过timeoutSeconds任务同样被标记为TIMED_OUT。以下时序展示了经典的心跳保活但超时仍触发场景注意最后一步的语义当任务已进入终态后迟到的成功结果会被直接忽略。因此凡是可能长时间运行的任务必须让timeoutSeconds覆盖真实执行时长否则会出现任务实际成功但被判超时重试的重复执行问题这正是分布式系统典型的 at-least-once 语义代价。五、Timeout 配置参数总览参数说明默认值pollTimeoutSecondsWorker 轮询任务的最大等待时间。无超时responseTimeoutSecondsWorker 轮询后回报结果的最大等待时间。600s文档标注timeoutSeconds单次尝试的 SLA从首次IN_PROGRESS到终态。无超时totalTimeoutSeconds所有尝试加总的硬性预算覆盖retryCount。无超时timeoutPolicy超时后的动作RETRY重试、TIME_OUT_WF失败工作流、ALERT_ONLY仅告警。TIME_OUT_WF默认值差异提示上表responseTimeoutSeconds的 600s 是文档标注值而当前仓库源码 TaskDef.java 中的字段默认值为ONE_HOUR3600s。两者存在版本差异实际行为请以你所部署版本生成的 TaskDef 为准。timeoutPolicy默认值为TIME_OUT_WF与源码字段一致。六、Total timeout总超时——跨尝试的硬性预算totalTimeoutSeconds限制的是所有重试尝试加总的墙钟时间。一旦该预算耗尽无论retryCount还剩多少次都不会再调度重试6.1 源码中的总超时判定在 DeciderService.java 中总超时的判定在每次重试排队前执行if (taskDefinition.getTotalTimeoutSeconds() 0 task.getFirstScheduledTime() 0) { long totalElapsedSeconds (System.currentTimeMillis() - task.getFirstScheduledTime()) / 1000; if (totalElapsedSeconds taskDefinition.getTotalTimeoutSeconds()) { // 抛出 TerminateWorkflowException终止工作流 // 任务此前状态为 TIMED_OUT 则工作流状态为 TIMED_OUT否则为 FAILED ... } }两个关键实现细节时间基准是firstScheduledTime——即从该任务第一次被调度而不是最后一次失败起算确保预算覆盖全部尝试与间隔延迟预算耗尽即终止工作流若任务在总超时前的状态是TIMED_OUT工作流最终状态为TIMED_OUT否则为FAILED。因此totalTimeoutSeconds非常适合需要无论重试多少次任务整体必须在 N 秒内出结果的硬性 SLA 场景例如对用户可见的支付、下单等强实时操作。七、实战一份完整的 TaskDef 配置模板综合以上参数给出一个生产级任务定义 JSON 模板可直接通过 Metadata API 注册{ name: send_notification, description: Sends a push notification with bounded retries, retryCount: 3, timeoutSeconds: 30, responseTimeoutSeconds: 20, pollTimeoutSeconds: 60, retryLogic: EXPONENTIAL_BACKOFF, retryDelaySeconds: 5, maxRetryDelaySeconds: 40, backoffJitterMs: 500, backoffScaleFactor: 1, totalTimeoutSeconds: 120, timeoutPolicy: TIME_OUT_WF, ownerEmail: platformexample.com }配置解读timeoutSeconds: 30——单次尝试最多执行 30 秒防止心跳保活导致的无限执行responseTimeoutSeconds: 20——Worker 领取后 20 秒内必须回报兜底崩溃场景20s 30s 的搭配合理pollTimeoutSeconds: 60——队列中 60 秒无人领取即视为积压retryLogic: EXPONENTIAL_BACKOFFretryDelaySeconds: 5maxRetryDelaySeconds: 40——第 1、2、3 次重试延迟依次为 5s、10s、20s且被 40s 封顶backoffJitterMs: 500——每次延迟附加 0~500ms 随机抖动避免大量失败任务同时重试造成重试风暴totalTimeoutSeconds: 120——4 次尝试1 次初始 3 次重试加总不得超过 120 秒即便retryCount未耗尽也必须终止并让工作流进入FAILEDtimeoutPolicy: TIME_OUT_WF——一旦超时直接失败整个工作流默认值此处显式声明。八、状态流转的触发方系统任务与 Worker任务状态的每一次迁移都由两类执行者推动系统任务System Task如 HTTP、Inline、DoWhile、Join、SetVariable 等由 Conductor 服务端直接执行其状态迁移由 WorkflowExecutorOps 与决策器统一驱动无需外部 Worker。例如 DoWhile.java 在循环条件异常时将任务置为FAILED_WITH_TERMINAL_ERROR。用户任务Worker Task状态流转完全依赖 Worker 通过 API 上报——轮询领取SCHEDULED → IN_PROGRESS、心跳保活持续IN_PROGRESScallbackAfterSeconds、上报结果IN_PROGRESS → COMPLETED/FAILED。因此若生产环境中观察到任务长期停留在SCHEDULED优先排查 Worker 是否在线、队列是否有积压若长期停留在IN_PROGRESS优先排查 Worker 是否崩溃响应超时兜底或callbackAfterSeconds心跳是否失联任务超时兜底。九、常见问题速查现象可能原因处置建议任务卡在SCHEDULED后变TIMED_OUTWorker 不足或队列积压扩容 Worker设置pollTimeoutSeconds并配合监控告警任务执行中 Worker 崩溃任务卡在IN_PROGRESSWorker 未上报心跳依赖responseTimeoutSeconds兜底及时转TIMED_OUT并重试Worker 一直在发心跳任务仍超时timeoutSeconds小于真实执行时长上调timeoutSeconds或将长任务拆分为多个步骤任务不断重试但总也完不成retryCount偏大且无总预算设置totalTimeoutSeconds硬性封顶大量任务在同一时刻集中重试无抖动导致的羊群效应配置backoffJitterMs打散重试时间失败后立刻重试间隔太短retryDelaySeconds过小结合retryLogic使用指数退避并设置maxRetryDelaySeconds十、参考资料Task Lifecycle 官方文档本文的骨架来源TaskDef 配置文档含 Retry LogicTaskDef 元数据定义任务状态枚举定义决策器重试延迟计算与总超时判定可选任务与终态错误处理示例Metadata API 参考通过掌握任务状态机、重试策略与三类超时的精确语义你将能针对不同的业务场景强实时 SLA、重试敏感性、Worker 稳定性做出合理的TaskDef配置让 Conductor 的持久化执行能力真正为你的应用与 AI Agent 工作流保驾护航。【免费下载链接】conductorConductor is an event driven agentic workflow engine providing durable and highly resilient execution engine for applications and AI Agents项目地址: https://gitcode.com/GitHub_Trending/co/conductor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Conductor 任务生命周期完全指南：状态流转、重试机制与超时策略
Conductor 任务生命周期完全指南状态流转、重试机制与超时策略【免费下载链接】conductorConductor is an event driven agentic workflow engine providing durable and highly resilient execution engine for applications and AI Agents项目地址: https://gitcode.com/GitHub_Trending/co/conductor本文是 Conductor 工作流引擎中任务Task生命周期管理的权威参考。从SCHEDULED到COMPLETED或FAILED每个任务在运行期间都会经历一系列状态迁移理解这些迁移是正确配置重试retry、超时timeout与错误处理的前提。读完本文你将能够精确解读任务状态机与超时语义为任务定义写出正确且可落地的TaskDef配置并在生产环境中诊断任务卡住、超时、反复失败等经典问题。一、为什么需要理解任务生命周期在 Conductor 的事件驱动型工作流引擎中一个工作流实例Workflow由若干任务Task组成每个任务在生命周期内会经历一系列状态迁移。系统级任务如 HTTP、Inline、DoWhile 等由服务端执行而用户自定义任务由 Worker 进程轮询poll执行。无论哪种形态任务的每一次执行都以状态的形式被持久化——这正是 Conductor 实现持久化执行durable execution的根基任务状态不是内存中的瞬时变量而是可以随时恢复、重试、审计的持久化事实。从源码结构看任务状态的权威定义位于 TaskModel.java 中的Status枚举每个状态用三个布尔属性描述其语义public enum Status { IN_PROGRESS(false, true, true), CANCELED(true, false, false), FAILED(true, false, true), FAILED_WITH_TERMINAL_ERROR(true, false, false), COMPLETED(true, true, true), COMPLETED_WITH_ERRORS(true, true, true), SCHEDULED(false, true, true), TIMED_OUT(true, false, true), SKIPPED(true, true, false); private final boolean terminal; // 是否为终态 private final boolean successful; // 是否算成功 private final boolean retriable; // 是否可重试 ... }这个枚举直接印证了文档中状态图的核心结论除了SCHEDULED与IN_PROGRESS其余状态全部是终态terminal而FAILED、TIMED_OUT虽然本身是终态但被标记为retriable意味着它们可以在满足重试条件时复活为新的执行SCHEDULED。COMPLETED_WITH_ERRORS则同时是终态、成功态且可重试——这正是可选任务optional task的语义任务失败了但工作流选择继续走下去。二、任务状态机一张图看懂所有流转每个任务在其生命周期中遵循以下状态迁移来自 tasklifecycle.md 的状态图mermaid 语法可被 GitHub 与主流文档工具直接渲染2.1 状态一览表状态说明SCHEDULED任务已入队等待 Worker 轮询。IN_PROGRESSWorker 已领取任务并正在执行。COMPLETED任务成功完成。FAILED任务因错误失败Conductor 会根据任务定义的 retry 配置进行重试。FAILED_WITH_TERMINAL_ERROR任务以不可重试错误失败不做任何重试。TIMED_OUT任务超过配置的超时时间Conductor 会按 retry 配置重试。CANCELED因工作流被终止而取消。SKIPPED通过 Skip Task API 跳过工作流继续执行下一个任务。COMPLETED_WITH_ERRORS任务失败但在工作流定义中被标记为 optional可选工作流继续。2.2 状态语义的源码依据FAILED_WITH_TERMINAL_ERROR在Status枚举中标记为terminaltrue, successfulfalse, retriablefalse即一次性终态绝不重试。从源码结构看它通常由系统级任务在重试无意义的场景下设置例如 DoWhile.java 在执行循环任务遇到不可恢复错误时会将循环体任务置为该状态避免无意义的无限重试。COMPLETED_WITH_ERRORS则被标记为terminaltrue, successfultrue, retriabletrue工作流决策器Decider在 DeciderService.java 中将**可选任务optional**的失败任务置为COMPLETED_WITH_ERRORS工作流视其为成功完成但有错误从而继续推进后续任务。三、重试机制自动重排与重试策略当一个任务以可重试错误失败FAILED时Conductor 会按配置的延迟自动重新调度reschedule该任务。以下时序图完整呈现了一次失败重试的全过程3.1 重试相关的 TaskDef 参数参数说明retryCount最大重试次数。retryLogicFIXED、EXPONENTIAL_BACKOFF或LINEAR_BACKOFF详见 TaskDef 配置文档。retryDelaySeconds重试之间的基础延迟秒。maxRetryDelaySeconds计算所得延迟的上限防止指数退避无限增长。backoffJitterMs为每次延迟附加随机毫秒数将并发重试在时间上打散。totalTimeoutSeconds横跨所有尝试的硬性墙钟预算详见总超时一节。3.2 重试延迟的源码级计算重试延迟的真正计算发生在决策器 DeciderService.java 中其逻辑与TaskDef字段一一对应FIXED固定每次重试延迟固定为retryDelaySeconds。LINEAR_BACKOFF线性退避延迟 retryDelaySeconds × backoffScaleFactor × (retryCount 1)即随尝试次数线性增长。EXPONENTIAL_BACKOFF指数退避延迟 retryDelaySeconds × 2^retryCount即每多一次尝试延迟翻倍。所有策略在计算后都会经过applyMaxRetryDelayCap应用maxRetryDelaySeconds上限随后若配置了backoffJitterMs 0会通过ThreadLocalRandom.current().nextLong(0, backoffJitterMs 1)产生[0, backoffJitterMs]的随机毫秒抖动叠加到秒级延迟上最终以毫秒精度写入callbackAfterMs。这正是打散并发重试、避免羊群效应的实现细节。3.3 关键默认值来自 TaskDef.java从TaskDef源码字段的默认值可以直接得到以下事实retryCount默认3retryLogic默认FIXEDretryDelaySeconds默认60秒responseTimeoutSeconds默认3600ONE_HOUR即 1 小时maxRetryDelaySeconds默认0不设上限backoffJitterMs默认0无抖动totalTimeoutSeconds默认0不设总预算timeoutPolicy默认TIME_OUT_WF。四、超时场景poll / response / task 三种超时超时是分布式系统中任务既不成功也不失败时的兜底机制。Conductor 区分三种超时理解它们的区别是配置正确性的关键。4.1 Poll timeout轮询超时若在pollTimeoutSeconds内没有 Worker 轮询该任务任务被标记为TIMED_OUT这通常意味着任务队列积压backlogged queue或 Worker 数量不足。从配置层面看pollTimeoutSeconds在TaskDef中默认不设置Integer pollTimeoutSeconds默认为null即无超时需要按队列积压容忍度显式配置。4.2 Response timeout响应超时Worker 已轮询到任务但在responseTimeoutSeconds内未回报结果任务被标记为TIMED_OUT。该机制专门兜底Worker 执行中途崩溃的场景Worker 可以延长响应超时在轮询到任务后持续上报IN_PROGRESS状态并携带callbackAfterSeconds值表示我还在执行请再等 N 秒。默认responseTimeoutSeconds为 1 小时见上文源码默认值但实践中建议按任务实际耗时收紧。4.3 Task timeout任务超时 / 单次尝试 SLAtimeoutSeconds是单次尝试的整体 SLA即使 Worker 不断发送IN_PROGRESS心跳只要累计耗时超过timeoutSeconds任务同样被标记为TIMED_OUT。以下时序展示了经典的心跳保活但超时仍触发场景注意最后一步的语义当任务已进入终态后迟到的成功结果会被直接忽略。因此凡是可能长时间运行的任务必须让timeoutSeconds覆盖真实执行时长否则会出现任务实际成功但被判超时重试的重复执行问题这正是分布式系统典型的 at-least-once 语义代价。五、Timeout 配置参数总览参数说明默认值pollTimeoutSecondsWorker 轮询任务的最大等待时间。无超时responseTimeoutSecondsWorker 轮询后回报结果的最大等待时间。600s文档标注timeoutSeconds单次尝试的 SLA从首次IN_PROGRESS到终态。无超时totalTimeoutSeconds所有尝试加总的硬性预算覆盖retryCount。无超时timeoutPolicy超时后的动作RETRY重试、TIME_OUT_WF失败工作流、ALERT_ONLY仅告警。TIME_OUT_WF默认值差异提示上表responseTimeoutSeconds的 600s 是文档标注值而当前仓库源码 TaskDef.java 中的字段默认值为ONE_HOUR3600s。两者存在版本差异实际行为请以你所部署版本生成的 TaskDef 为准。timeoutPolicy默认值为TIME_OUT_WF与源码字段一致。六、Total timeout总超时——跨尝试的硬性预算totalTimeoutSeconds限制的是所有重试尝试加总的墙钟时间。一旦该预算耗尽无论retryCount还剩多少次都不会再调度重试6.1 源码中的总超时判定在 DeciderService.java 中总超时的判定在每次重试排队前执行if (taskDefinition.getTotalTimeoutSeconds() 0 task.getFirstScheduledTime() 0) { long totalElapsedSeconds (System.currentTimeMillis() - task.getFirstScheduledTime()) / 1000; if (totalElapsedSeconds taskDefinition.getTotalTimeoutSeconds()) { // 抛出 TerminateWorkflowException终止工作流 // 任务此前状态为 TIMED_OUT 则工作流状态为 TIMED_OUT否则为 FAILED ... } }两个关键实现细节时间基准是firstScheduledTime——即从该任务第一次被调度而不是最后一次失败起算确保预算覆盖全部尝试与间隔延迟预算耗尽即终止工作流若任务在总超时前的状态是TIMED_OUT工作流最终状态为TIMED_OUT否则为FAILED。因此totalTimeoutSeconds非常适合需要无论重试多少次任务整体必须在 N 秒内出结果的硬性 SLA 场景例如对用户可见的支付、下单等强实时操作。七、实战一份完整的 TaskDef 配置模板综合以上参数给出一个生产级任务定义 JSON 模板可直接通过 Metadata API 注册{ name: send_notification, description: Sends a push notification with bounded retries, retryCount: 3, timeoutSeconds: 30, responseTimeoutSeconds: 20, pollTimeoutSeconds: 60, retryLogic: EXPONENTIAL_BACKOFF, retryDelaySeconds: 5, maxRetryDelaySeconds: 40, backoffJitterMs: 500, backoffScaleFactor: 1, totalTimeoutSeconds: 120, timeoutPolicy: TIME_OUT_WF, ownerEmail: platformexample.com }配置解读timeoutSeconds: 30——单次尝试最多执行 30 秒防止心跳保活导致的无限执行responseTimeoutSeconds: 20——Worker 领取后 20 秒内必须回报兜底崩溃场景20s 30s 的搭配合理pollTimeoutSeconds: 60——队列中 60 秒无人领取即视为积压retryLogic: EXPONENTIAL_BACKOFFretryDelaySeconds: 5maxRetryDelaySeconds: 40——第 1、2、3 次重试延迟依次为 5s、10s、20s且被 40s 封顶backoffJitterMs: 500——每次延迟附加 0~500ms 随机抖动避免大量失败任务同时重试造成重试风暴totalTimeoutSeconds: 120——4 次尝试1 次初始 3 次重试加总不得超过 120 秒即便retryCount未耗尽也必须终止并让工作流进入FAILEDtimeoutPolicy: TIME_OUT_WF——一旦超时直接失败整个工作流默认值此处显式声明。八、状态流转的触发方系统任务与 Worker任务状态的每一次迁移都由两类执行者推动系统任务System Task如 HTTP、Inline、DoWhile、Join、SetVariable 等由 Conductor 服务端直接执行其状态迁移由 WorkflowExecutorOps 与决策器统一驱动无需外部 Worker。例如 DoWhile.java 在循环条件异常时将任务置为FAILED_WITH_TERMINAL_ERROR。用户任务Worker Task状态流转完全依赖 Worker 通过 API 上报——轮询领取SCHEDULED → IN_PROGRESS、心跳保活持续IN_PROGRESScallbackAfterSeconds、上报结果IN_PROGRESS → COMPLETED/FAILED。因此若生产环境中观察到任务长期停留在SCHEDULED优先排查 Worker 是否在线、队列是否有积压若长期停留在IN_PROGRESS优先排查 Worker 是否崩溃响应超时兜底或callbackAfterSeconds心跳是否失联任务超时兜底。九、常见问题速查现象可能原因处置建议任务卡在SCHEDULED后变TIMED_OUTWorker 不足或队列积压扩容 Worker设置pollTimeoutSeconds并配合监控告警任务执行中 Worker 崩溃任务卡在IN_PROGRESSWorker 未上报心跳依赖responseTimeoutSeconds兜底及时转TIMED_OUT并重试Worker 一直在发心跳任务仍超时timeoutSeconds小于真实执行时长上调timeoutSeconds或将长任务拆分为多个步骤任务不断重试但总也完不成retryCount偏大且无总预算设置totalTimeoutSeconds硬性封顶大量任务在同一时刻集中重试无抖动导致的羊群效应配置backoffJitterMs打散重试时间失败后立刻重试间隔太短retryDelaySeconds过小结合retryLogic使用指数退避并设置maxRetryDelaySeconds十、参考资料Task Lifecycle 官方文档本文的骨架来源TaskDef 配置文档含 Retry LogicTaskDef 元数据定义任务状态枚举定义决策器重试延迟计算与总超时判定可选任务与终态错误处理示例Metadata API 参考通过掌握任务状态机、重试策略与三类超时的精确语义你将能针对不同的业务场景强实时 SLA、重试敏感性、Worker 稳定性做出合理的TaskDef配置让 Conductor 的持久化执行能力真正为你的应用与 AI Agent 工作流保驾护航。【免费下载链接】conductorConductor is an event driven agentic workflow engine providing durable and highly resilient execution engine for applications and AI Agents项目地址: https://gitcode.com/GitHub_Trending/co/conductor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
