【免费下载链接】WegentPlan, build, and deliver with an open-source, self-hostable AI workspace for coding, collaboration, and automation.项目地址https://gitcode.com/gh_mirrors/we/Wegent点击查看免费下载Wegent 是一个开源、可自托管的 AI 工作空间AI workspace核心能力包括 AI 编码、团队协作与自动化交付。本文面向新手带你读懂 Wegent 的任务状态机Task State Machine源码一个 AI 编码任务从创建PENDING到执行RUNNING再到**交付COMPLETED**或异常分支FAILED / CANCELLED的完整生命周期。你将理解 8 种任务状态的流转规则、Pipeline 多 Agent 流水线中的确认机制以及卡死任务如何被自动恢复。任务状态机总览8种状态一览 Wegent 用一张清晰的状态枚举表定义了任务的全部生命周期节点。它定义在后端 schemas/task.py 中状态英文值含义是否是终态待执行PENDING任务已创建排队等待调度否执行中RUNNINGBot 正在沙箱/执行器中干活否已完成COMPLETED全部工作交付完毕✅已失败FAILED执行出错附带错误信息✅取消中CANCELLING用户发起取消正在收尾过渡态已取消CANCELLED任务已被终止✅待确认PENDING_CONFIRMATION流水线阶段完成等待用户确认否已删除DELETE软删除标记✅其中COMPLETED、FAILED、CANCELLED、DELETE四个状态被 chat/operations/cancel.py 中的_TASK_FINAL_STATES声明为终态——一旦进入任务不会再醒来。Wegent 桌面端界面任务从左侧列表发起底部终端实时展示执行过程阶段一创建与初始化PENDING任务创建时后端不会直接让它跑起来而是先落库为PENDING。核心流程在 chat/storage/task_manager.py创建时写入的初始 CRD 里status.status就是PENDINGprogress为 0状态并不是独立的数据库字段而是整体存放在任务的CRD JSON类 Kubernetes 风格的自定义资源文档的status块中progress、errorMessage、completedAt、updatedAt都与之同居。统一的状态写入工具函数集中在 services/task_status.py例如mark_task_pending重置进度为 0、清空错误信息、mark_task_failed记录错误信息并写入completedAt、mark_task_completed进度置 100%。这套payload 先算好再写回的设计保证了任何分支修改状态时行为一致。Wegent 项目空间任务在这里创建并被分配给 AI 团队阶段二调度执行RUNNING任务被分配到 Bot 后进入RUNNING。执行期间有两个值得新手注意的细节1. 流式结果实时落库。在 chat/storage/db.py 的save_partial_response中Bot 的响应以部分内容 streaming 标志的形式持续写入子任务Subtask前端因此能逐字看到 AI 输出。2. 子任务与任务是两层状态机。schemas/subtask.py 中的SubtaskStatus与任务状态几乎同构PENDING / RUNNING / COMPLETED / FAILED / CANCELLED。任务的状态其实是由子任务状态聚合推导出来的——子任务完成了策略层才会决定任务该进入哪个状态。阶段三完成判定与协作策略这是状态机最精巧的部分。子任务完成后任务并不会无脑变成COMPLETED而是要经过 chat/storage/db.py 中的状态聚合逻辑new_status, progress strategy.get_task_status_on_subtask_complete( db, task_id, last_subtask.id, subtask_status_str )即由CollaborationStrategy协作策略根据团队模式计算新状态。随后若新状态是COMPLETED、CANCELLED或PENDING_CONFIRMATION写入completedAt时间戳若子任务是FAILED则把error_message透传到任务级用户能在界面看到失败原因。单 Bot 任务通常一步到位走向COMPLETED而多 Bot 团队任务就要走下面的流水线分支了。Pipeline 流水线多Agent接力与待确认分支 当团队以Pipeline 模式组建时如规划 Bot → 编码 Bot → 审查 Bot任务生命周期中会插入一种特殊状态——PENDING_CONFIRMATION。Wegent 团队管理界面Pipeline 模式下多个 Bot 首尾相连逐个接力完成任务整个流水线机制由 adapters/pipeline_stage.py 的PipelineStageService管理关键规则有三条1. 当前阶段是唯一的事实来源。任务 JSON 的spec.currentStage记录当前进行到第几个 Botget_current_stage_index会读取它并做越界保护所有界面展示、阶段推进都只认这一个字段。2. 阶段完成 ≠ 任务完成。should_set_pending_confirmation_on_complete会检查当前阶段是否配置了requireConfirmation如果是且不是最后一个阶段那么子任务完成后任务状态被置为PENDING_CONFIRMATION而非继续执行——把方向盘交还给人类。3. 用户确认后推进或收官。点击确认后pipeline_confirm校验任务确实处于PENDING_CONFIRMATION否则拒绝然后若是最后一个阶段任务直接进入COMPLETEDprogress置 100写入completedAt否则把currentStage加 1状态回落到PENDING并通过build_pipeline_context_prompt生成交接信息handoff message让下一个 Bot 带着上一阶段的成果继续干活。此外还有pipeline_auto_advance未要求确认的阶段完成后自动接力无需人工点击。任务执行完毕进入交付环节变更统计、提交推送与待确认状态一目了然失败与取消如何优雅地刹车 失败分支子任务FAILED时错误信息被聚合到任务级任务标记为FAILED并记录completedAt。用户可以在界面上查看失败原因并借助 chat/operations/retry.py 发起重试。取消分支取消不是一步到位而是一个两阶段状态机用户点击取消 → 任务进入CANCELLING表示正在通知执行器、等待收尾执行器确认停止后chat/operations/cancel.py 把未完结的 assistant 子任务统一标记为CANCELLED任务随之变为CANCELLED并发布TaskCompletedEvent(CANCELLED)事件通知前端。还有一个贴心的兜底如果任务在CANCELLING状态卡住比如执行器失联CANCELLING_STUCK_TIMEOUT_SECONDS超时机制会在空闲超时后强制将其就地终结避免任务永远卡在取消中。状态守护防止乱序更新状态机之所以可靠靠的是守卫条件。例如在 chat/storage/task_manager.py 中check_task_status当任务处于RUNNING或PENDING时拒绝某些变更操作Task is still running恢复/兜底逻辑会检查任务 JSON 里的实际状态防止执行器已经跑完、状态却仍停留在PENDING/RUNNING的僵尸任务。配合 WebSocket 事件推送前端列表页能实时看到任务状态的每一次合法迁移。一图总结任务生命周期状态流转┌────────────────────────────────────────┐ │ Pipeline 模式多Bot接力 │ │ │ 创建 ──▶ PENDING ──▶ RUNNING ──▶ PENDING_CONFIRMATION ──▶ 下一阶段 PENDING │ │ │ │ │ │ └──(最后阶段)──▶ COMPLETED ◀┘ │ └──▶ COMPLETED单Bot/普通任务直接完成 │ ├──▶ FAILED执行出错可重试 │ ├──▶ CANCELLING ──▶ CANCELLED含卡死超时兜底 │ └──▶ DELETE软删除写在最后Wegent 的任务状态机看似只是 8 个枚举值实则是一套完整的设计CRD JSON 承载状态currentStage作为流水线单一事实来源子任务 → 任务两级聚合协作策略决定终态PENDING_CONFIRMATION把人类留在决策回路里两阶段取消 超时兜底保证状态机永远能走到头。如果你想动手阅读源码建议按这条路径走schemas/task.py状态定义→ services/task_status.py状态写入工具→ adapters/pipeline_stage.py流水线推进→ chat/operations/cancel.py取消收尾基本就能串起整个生命周期。更多背景资料可参考 backend/README.md 与 docs/README.md以及流水线推进逻辑 chat/pipeline_advance.py。赞分享【免费下载链接】WegentPlan, build, and deliver with an open-source, self-hostable AI workspace for coding, collaboration, and automation.项目地址https://gitcode.com/gh_mirrors/we/Wegent点击查看免费下载相关推荐BullMQ任务状态机基于有限状态机的任务生命周期管理BullMQ任务状态机基于有限状态机的任务生命周期管理 在分布式系统中任务的可靠执行离不开完善的状态管理机制。BullMQ作为基于Redis的消息队列和批处后端任务调度消息队列Celery Worker 内部状态机制全解析从 celery.worker.state 源码读懂任务生命周期、撤销与持久化Celery Worker 内部状态机制全解析从 celery.worker.state 源码读懂任务生命周期、撤销与持久化 celery.worker.st后端任务调度消息队列Apache Mesos任务状态管理终极指南深入理解任务生命周期和状态转换Apache Mesos任务状态管理终极指南深入理解任务生命周期和状态转换 Apache Mesos作为开源的集群管理框架为开发者提供了高效的资源隔离和共享集群管理云原生任务调度创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
【免费下载链接】WegentPlan, build, and deliver with an open-source, self-hostable AI workspace for coding, collaboration, and automation.项目地址https://gitcode.com/gh_mirrors/we/Wegent点击查看免费下载Wegent 是一个开源、可自托管的 AI 工作空间AI workspace核心能力包括 AI 编码、团队协作与自动化交付。本文面向新手带你读懂 Wegent 的任务状态机Task State Machine源码一个 AI 编码任务从创建PENDING到执行RUNNING再到**交付COMPLETED**或异常分支FAILED / CANCELLED的完整生命周期。你将理解 8 种任务状态的流转规则、Pipeline 多 Agent 流水线中的确认机制以及卡死任务如何被自动恢复。任务状态机总览8种状态一览 Wegent 用一张清晰的状态枚举表定义了任务的全部生命周期节点。它定义在后端 schemas/task.py 中状态英文值含义是否是终态待执行PENDING任务已创建排队等待调度否执行中RUNNINGBot 正在沙箱/执行器中干活否已完成COMPLETED全部工作交付完毕✅已失败FAILED执行出错附带错误信息✅取消中CANCELLING用户发起取消正在收尾过渡态已取消CANCELLED任务已被终止✅待确认PENDING_CONFIRMATION流水线阶段完成等待用户确认否已删除DELETE软删除标记✅其中COMPLETED、FAILED、CANCELLED、DELETE四个状态被 chat/operations/cancel.py 中的_TASK_FINAL_STATES声明为终态——一旦进入任务不会再醒来。Wegent 桌面端界面任务从左侧列表发起底部终端实时展示执行过程阶段一创建与初始化PENDING任务创建时后端不会直接让它跑起来而是先落库为PENDING。核心流程在 chat/storage/task_manager.py创建时写入的初始 CRD 里status.status就是PENDINGprogress为 0状态并不是独立的数据库字段而是整体存放在任务的CRD JSON类 Kubernetes 风格的自定义资源文档的status块中progress、errorMessage、completedAt、updatedAt都与之同居。统一的状态写入工具函数集中在 services/task_status.py例如mark_task_pending重置进度为 0、清空错误信息、mark_task_failed记录错误信息并写入completedAt、mark_task_completed进度置 100%。这套payload 先算好再写回的设计保证了任何分支修改状态时行为一致。Wegent 项目空间任务在这里创建并被分配给 AI 团队阶段二调度执行RUNNING任务被分配到 Bot 后进入RUNNING。执行期间有两个值得新手注意的细节1. 流式结果实时落库。在 chat/storage/db.py 的save_partial_response中Bot 的响应以部分内容 streaming 标志的形式持续写入子任务Subtask前端因此能逐字看到 AI 输出。2. 子任务与任务是两层状态机。schemas/subtask.py 中的SubtaskStatus与任务状态几乎同构PENDING / RUNNING / COMPLETED / FAILED / CANCELLED。任务的状态其实是由子任务状态聚合推导出来的——子任务完成了策略层才会决定任务该进入哪个状态。阶段三完成判定与协作策略这是状态机最精巧的部分。子任务完成后任务并不会无脑变成COMPLETED而是要经过 chat/storage/db.py 中的状态聚合逻辑new_status, progress strategy.get_task_status_on_subtask_complete( db, task_id, last_subtask.id, subtask_status_str )即由CollaborationStrategy协作策略根据团队模式计算新状态。随后若新状态是COMPLETED、CANCELLED或PENDING_CONFIRMATION写入completedAt时间戳若子任务是FAILED则把error_message透传到任务级用户能在界面看到失败原因。单 Bot 任务通常一步到位走向COMPLETED而多 Bot 团队任务就要走下面的流水线分支了。Pipeline 流水线多Agent接力与待确认分支 当团队以Pipeline 模式组建时如规划 Bot → 编码 Bot → 审查 Bot任务生命周期中会插入一种特殊状态——PENDING_CONFIRMATION。Wegent 团队管理界面Pipeline 模式下多个 Bot 首尾相连逐个接力完成任务整个流水线机制由 adapters/pipeline_stage.py 的PipelineStageService管理关键规则有三条1. 当前阶段是唯一的事实来源。任务 JSON 的spec.currentStage记录当前进行到第几个 Botget_current_stage_index会读取它并做越界保护所有界面展示、阶段推进都只认这一个字段。2. 阶段完成 ≠ 任务完成。should_set_pending_confirmation_on_complete会检查当前阶段是否配置了requireConfirmation如果是且不是最后一个阶段那么子任务完成后任务状态被置为PENDING_CONFIRMATION而非继续执行——把方向盘交还给人类。3. 用户确认后推进或收官。点击确认后pipeline_confirm校验任务确实处于PENDING_CONFIRMATION否则拒绝然后若是最后一个阶段任务直接进入COMPLETEDprogress置 100写入completedAt否则把currentStage加 1状态回落到PENDING并通过build_pipeline_context_prompt生成交接信息handoff message让下一个 Bot 带着上一阶段的成果继续干活。此外还有pipeline_auto_advance未要求确认的阶段完成后自动接力无需人工点击。任务执行完毕进入交付环节变更统计、提交推送与待确认状态一目了然失败与取消如何优雅地刹车 失败分支子任务FAILED时错误信息被聚合到任务级任务标记为FAILED并记录completedAt。用户可以在界面上查看失败原因并借助 chat/operations/retry.py 发起重试。取消分支取消不是一步到位而是一个两阶段状态机用户点击取消 → 任务进入CANCELLING表示正在通知执行器、等待收尾执行器确认停止后chat/operations/cancel.py 把未完结的 assistant 子任务统一标记为CANCELLED任务随之变为CANCELLED并发布TaskCompletedEvent(CANCELLED)事件通知前端。还有一个贴心的兜底如果任务在CANCELLING状态卡住比如执行器失联CANCELLING_STUCK_TIMEOUT_SECONDS超时机制会在空闲超时后强制将其就地终结避免任务永远卡在取消中。状态守护防止乱序更新状态机之所以可靠靠的是守卫条件。例如在 chat/storage/task_manager.py 中check_task_status当任务处于RUNNING或PENDING时拒绝某些变更操作Task is still running恢复/兜底逻辑会检查任务 JSON 里的实际状态防止执行器已经跑完、状态却仍停留在PENDING/RUNNING的僵尸任务。配合 WebSocket 事件推送前端列表页能实时看到任务状态的每一次合法迁移。一图总结任务生命周期状态流转┌────────────────────────────────────────┐ │ Pipeline 模式多Bot接力 │ │ │ 创建 ──▶ PENDING ──▶ RUNNING ──▶ PENDING_CONFIRMATION ──▶ 下一阶段 PENDING │ │ │ │ │ │ └──(最后阶段)──▶ COMPLETED ◀┘ │ └──▶ COMPLETED单Bot/普通任务直接完成 │ ├──▶ FAILED执行出错可重试 │ ├──▶ CANCELLING ──▶ CANCELLED含卡死超时兜底 │ └──▶ DELETE软删除写在最后Wegent 的任务状态机看似只是 8 个枚举值实则是一套完整的设计CRD JSON 承载状态currentStage作为流水线单一事实来源子任务 → 任务两级聚合协作策略决定终态PENDING_CONFIRMATION把人类留在决策回路里两阶段取消 超时兜底保证状态机永远能走到头。如果你想动手阅读源码建议按这条路径走schemas/task.py状态定义→ services/task_status.py状态写入工具→ adapters/pipeline_stage.py流水线推进→ chat/operations/cancel.py取消收尾基本就能串起整个生命周期。更多背景资料可参考 backend/README.md 与 docs/README.md以及流水线推进逻辑 chat/pipeline_advance.py。赞分享【免费下载链接】WegentPlan, build, and deliver with an open-source, self-hostable AI workspace for coding, collaboration, and automation.项目地址https://gitcode.com/gh_mirrors/we/Wegent点击查看免费下载相关推荐BullMQ任务状态机基于有限状态机的任务生命周期管理BullMQ任务状态机基于有限状态机的任务生命周期管理 在分布式系统中任务的可靠执行离不开完善的状态管理机制。BullMQ作为基于Redis的消息队列和批处后端任务调度消息队列Celery Worker 内部状态机制全解析从 celery.worker.state 源码读懂任务生命周期、撤销与持久化Celery Worker 内部状态机制全解析从 celery.worker.state 源码读懂任务生命周期、撤销与持久化 celery.worker.st后端任务调度消息队列Apache Mesos任务状态管理终极指南深入理解任务生命周期和状态转换Apache Mesos任务状态管理终极指南深入理解任务生命周期和状态转换 Apache Mesos作为开源的集群管理框架为开发者提供了高效的资源隔离和共享集群管理云原生任务调度创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
全解析：从ERM失效到领域泛化与不变性学习)
