人工智能大模型AI 应用媒体生成视频后端前端任务调度【免费下载链接】JellyfishAn end-to-end production workspace for AI-generated short dramas. From script input to structured storyboarding, consistency management, shot preparation, video generation, and export.项目地址https://gitcode.com/gh_mirrors/jellyfish9/Jellyfish点击查看免费下载Jellyfish 是一个面向 AI 短剧生成的端到端生产工作台从剧本输入、结构化分镜、一致性管理到镜头准备与视频生成均有长耗时任务贯穿其中。本文基于仓库中 任务执行架构文档结合源码梳理当前真实生效的任务执行分层GenerationTask作为任务真相层、Redis Celery 作为执行层、前端任务中心作为统一反馈入口。读完本文你将掌握 Jellyfish 中任务从 API 创建、Celery 投递、worker 按task_kind路由执行到状态回写与取消收敛的完整调用链以及 sync / async 两类 executor 的分工与适用场景。当前执行分层两层结构 执行协议层 运行时分层Jellyfish 的长耗时任务执行采用清晰的分层设计文档原文给出的结构如下业务任务真相层 ├── GenerationTask ├── GenerationTaskLink ├── /api/v1/film/tasks ├── /api/v1/film/tasks/{task_id}/status └── /api/v1/film/tasks/{task_id}/result 执行层 ├── FastAPI 负责创建任务与返回 task_id ├── Redis 作为 Celery broker └── Celery Worker 执行长耗时任务 执行协议层 ├── GenerationTask.task_kind ├── task.execute统一 Celery 入口 └── TaskExecutorRegistrytask_kind → executor 运行时分层 ├── Web Runtime │ ├── async SQLAlchemy │ └── FastAPI dependencies └── Worker Runtime ├── sync SQLAlchemy └── Celery task wrappers worker services这套分层背后有明确的核心约束理解它们才能正确扩展任务类型GenerationTask仍是任务状态、结果、错误与取消请求的唯一真相源Celery 不承担业务状态对外暴露职责worker 执行完成后把状态与结果回写到 MySQL。/api/v1/film/tasks当前作为前端全局任务中心的主数据源。GenerationTaskLink当前承担任务与业务实体的关联信息查询relation_type/relation_entity_id。GenerationTask记录运行时指标started_at、finished_at任务状态接口直接暴露started_at_ts、finished_at_ts、elapsed_ms。前端不直接读取 Celery task 状态Celery 只负责执行、不负责对前端暴露业务状态。任务投递统一使用task_kind识别具体执行器。从模型看状态枚举在 types.py 中定义pending / running / streaming / succeeded / failed / cancelledTaskRecord与TaskListItemView均携带executor_type、executor_task_id、cancel_requested等执行与取消相关字段。最小基础设施MySQL Redis Celery Worker当前最小执行层方案为业务库MySQL BrokerRedis 执行器Celery Worker配置规则可在 config.py 中验证DATABASE_URL继续指向 MySQL默认值为sqliteaiosqlite:///./jellyfish.db需按环境显式覆盖。CELERY_BROKER_URL若未显式指定则按 Redis 配置自动拼接如redis://{host}:{port}/{db}。backend/.env由app.config按绝对路径加载避免 worker 因工作目录变化回退到默认 SQLite。Celery 应用实例位于 celery_app.py关键点brokersettings.celery_broker_urlinclude[app.tasks.execute_task]即统一任务入口模块。task_serializerjson、accept_content[json]、task_ignore_resultTrue第一阶段不依赖 Celery result backend业务结果仍回写GenerationTask。worker_process_init信号触发reset_db_runtime()保证 prefork 子进程启动后重建 async DB 运行时避免复用父进程残留的异步引擎。已切到 Celery 的任务清单与两类 executor当前已从本地asyncio.create_task(...)切到 Celery worker 的任务共 12 类divide、extract、check-consistency、optimize-script、simplify-script、analyze-character-portrait、analyze-prop-info、analyze-scene-info、analyze-costume-info、image-generation、video-generation、shot-frame-prompt。它们进一步分为两类执行方式完全不同已切到 sync worker runtime 的文本任务divide、extract、check-consistency、optimize-script、simplify-script、analyze-character-portrait、analyze-prop-info、analyze-scene-info、analyze-costume-info这 9 类任务通过以下组件执行不再在 Celery worker 中承载 async DB runtimedb_sync.py同步引擎把mysqlaiomysql://自动转换为mysqlpymysql://供同步 worker 使用SyncSqlAlchemyTaskStore见 stores.pyworker 专用同步 LLM runtimebuild_default_text_llm_syncscript_processing_worker.pyworker 侧执行逻辑所在地已切到 async delegating executor 的生成类任务image-generation、video-generation、shot-frame-prompt这三类任务同样通过task.execute(task_id)进入统一 Celery 执行层但执行器使用AbstractAsyncDelegatingExecutor作为桥接见 task_executor.py其行为包括每次任务执行前重建 async DB runtimereset_db_runtime()在独立 event loop 中运行既有 async serviceasyncio.run任务结束后主动释放 async engineclose_db()在执行前、结果生成后、结果持久化后执行统一取消检查通过 executor 统一配置任务超时输出统一任务事件日志started / running / cancelled / succeeded / failed这样可以先把执行从 Web 进程迁出同时保持图片 / 视频 provider 调用链的现有 async 实现。三类 async worker 已补最小专项测试重点锁定两点启动前取消请求会直接转cancelled、不再进入后续 provider / agent 调用。从注册表源码 task_registry.py 可以看到三类生成任务的默认超时配置task_kind执行器默认超时script_*九类文本任务各自*TaskExecutorsync无仅阶段边界检查video_generationAbstractAsyncDelegatingExecutor3600 秒image_generationAbstractAsyncDelegatingExecutor1800 秒shot_frame_promptAbstractAsyncDelegatingExecutor600 秒当前 Celery 主链路特征与两阶段模型当前主链路的完整流程API 层创建GenerationTaskAPI 层写入task_kind通过spawn_*_task(...)投递到 CeleryCelery 统一走task.execute(task_id)worker 通过TaskExecutorRegistry按task_kind路由到具体WorkerTaskExecutorworker 执行后把状态与结果回写到 MySQL页面继续通过既有任务状态接口轮询和恢复统一入口实现在 execute_task.pyenqueue_task_execution(task_id)调用run_task_celery.delay(task_id)并把executor_typecelery、executor_task_id回写到GenerationTask便于排障与后续 revoke。run_task_celeryCelery task 名为task.execute按task_id读取task_kind优先用字段值字段为空时回退读payload.task_kind再用task_executor_registry.resolve(task_kind)找到执行器并执行。revoke_task_execution(task_id)仅当executor_type celery且存在executor_task_id时才下发AsyncResult(...).revoke(terminateTrue, signalSIGTERM)。前端入口侧generated_video.py 与 tasks_images.py 均通过enqueue_task_execution(task_record.id)投递确认了API 创建 → 统一投递的链路。两阶段模型生成结果 vs 应用结果对核心任务如divide采用两阶段模型阶段 A生成结果 → 调 LLM / Agent → GenerationTask.result 阶段 B应用结果 → 写业务表 → 更新业务状态在AbstractWorkerTaskExecutor.runtask_executor.py中这一模型被固化为三段式生命周期_execute_phase生成结果并写result→_apply_and_finishshould_apply判断后apply_result写业务表再置为succeeded→ 统一succeeded日志。进度数值也有固定约定running_progress5、result_progress70、succeeded_progress100。当前有真实前端入口的 script-processing 文本任务已统一挂到AbstractWorkerTaskExecutor、AbstractLLMResultGenerator、TaskExecutorRegistry。已模板化的 sync executor 包括script_divide、script_extract、script_consistency、script_character_portrait、script_prop_info、script_scene_info、script_costume_info、script_optimize、script_simplify已接入 registry 的非文本生成 executor 包括image_generation、video_generation、shot_frame_prompt。超时语义阶段边界超时而非强中断sync executor 提供统一 started / succeeded / failed / cancelled 日志与统一阶段边界超时检查。超时语义是阶段边界超时而非执行中强中断检查点有三处_ensure_not_timed_out在进入执行前检查在生成结果后检查在 apply 后检查这意味着单次 LLM 长调用内部不会被打断超时只会在阶段边界生效对 async 三类任务则使用asyncio.wait_for包装整个 runner超时后抛TimeoutError并落failed。全局任务列表接口规则/api/v1/film/tasks的查询规则见 task_status.py 与 stores.py默认返回活跃任务pending / running / streaming与最近结束的任务时间窗口由recent_seconds控制API 默认值为 300 秒ge0, le86400。支持按statuses多选、task_kind、relation_type、relation_entity_id过滤。返回项同时包含任务状态与进度、started / finished / elapsed 指标、executor 信息executor_type/executor_task_id、relation 信息relation_type/relation_entity_id/resource_type、前端默认导航对象信息navigate_relation_type/navigate_relation_entity_id用于任务中心回到对应章节 / 镜头 / 资产。导航对象的解析逻辑在_resolve_navigation_targets中chapter_division / script_extraction / consistency_check / script_optimization / script_simplification映射到chaptervideo / shot_first_frame_prompt / shot_last_frame_prompt / shot_key_frame_prompt映射到shotshot_frame_image反查ShotFrameImage归属的 shotactor_image / scene_image / prop_image / costume_image / character_image反查各自的宿主实体。当前前端任务中心以该接口为主列表来源页面自身只补充两类轻量信息当前页面关联对象的高亮上下文、任务标题 / 来源 / 跳转等即时 UI 元信息。前端任务状态展示页面局部反馈 轻量全局提示当前前端采用页面局部反馈 轻量全局提示旧的页面内大块任务提示组件已退出主流程。具体交互形态触发任务的按钮负责loading状态、防重复点击并帮助用户确认是哪个动作正在运行。任务详情通过 Notification 展示当前状态、进度、开始时间、已运行 / 累计耗时、任务结束后的成功 / 失败 / 取消反馈支持直接跳回来源页面。取消入口优先放在触发区域旁的轻量按钮与 Notification 内的小型取消动作。悬浮任务中心统一展示全局任务列表交互细节包括默认隐藏是否展开按本地历史状态恢复首次进入时悬浮按钮默认位于左下角浮动按钮支持在视窗范围内拖动拖动结束后自动吸附到左侧或右侧边缘并记住最近一次位置展开面板根据按钮位置自动调整展开方向与对齐方式避免超出当前视窗查看当前运行中的任务、最近刚结束的任务显示任务所属对象或来源页面、进度、开始时间和耗时统一执行取消操作支持回到对应来源页面任务结束后短暂保留便于确认执行结果支持按当前页面 / 运行中 / 最近结束与任务类型做轻量筛选面板保持轻量化每页最多展示 3 条任务翻页使用紧凑箭头控件当前页面只负责提供高亮哪些任务与当前对象有关的上下文不再决定任务是否存在高亮匹配优先使用任务的默认导航对象navigate_relation_typenavigate_relation_entity_id后端未返回时回退到原始relation_type relation_entity_id。对未由当前页面显式补充来源信息的任务任务中心按relation_type relation_entity_id自动解析默认来源文案并尽量推导默认查看跳转。主要异步任务的启动、运行中、取消和结束态提示文案已统一收口同类任务在不同页面保持一致语气后续新增任务应复用同一套文案配置。已从页面内大块提示切换到这套较轻交互的页面包括分镜管理页、分镜编辑页、分镜工作室、原文编辑弹窗、资产编辑页、项目工作台章节列表中的分镜提取入口。图片生成页与分镜工作室中的生成动作也已接入同一套 Notification / 任务中心桥接不再只依赖页面内message 手写轮询。仍未切到 Celery 的任务预备能力以下任务当前仍保留旧执行方式且没有真实前端主入口因此不作为主线优先项merge-entitiesanalyze-variants它们虽已纳入任务模型但当前仍属于预备能力接入时可直接复用本文所述的三件套executor 模板 registry 注册 task.execute统一投递。取消语义两级取消当前取消采用两级取消模型前端请求取消 → GenerationTask.cancel_requested true → 若任务由 Celery 执行且存在 executor_task_id → 立即下发 revoke(terminateTrue) → API 直接把业务任务状态推进到 cancelled → 若无法立即终止 → worker 在阶段边界继续执行协作式取消这意味着对已进入 Celery worker 的任务支持 best-effort 的立即取消对应 execute_task.py 中revoke_task_execution下发 SIGTERM。对无法立即终止的单次长调用如单次 LLM 调用内部保留阶段边界协作式取消作为兜底_cancel_if_requested会在进入执行前、生成结果后、apply 后分别检查cancel_requested一旦命中立即mark_cancelled并终止后续阶段。当前不承诺 provider / LLM SDK 层面的绝对强终止只保证业务任务状态会立即收敛。在 store 层stores.pyrequest_cancel会把cancel_requested置真并记录cancel_reason且对仍处于pending的任务直接置为cancelledmark_cancelled则负责把运行中的任务收敛到终态cancelled。服务层约束防止循环导入与依赖倒置任务执行链必须遵守以下约束service层不得反向依赖api.v1.routesCelery task wrapper 只做 task_id 投递worker 侧执行逻辑放在app.services.script_processing_workerWeb 侧任务创建与状态恢复逻辑保留在app.services.script_processing_tasks这条约束已用于修复 worker 下暴露出的循环导入问题是新增任务类型时必须遵守的边界。新增一个任务的推荐路径是定义 executor继承AbstractWorkerTaskExecutor或AbstractAsyncDelegatingExecutor→ 在app.services.worker.task_registry中注册 → API 创建GenerationTask并写task_kind→ 调用enqueue_task_execution投递即可复用完整的日志、超时、取消与状态回写链路。赞分享人工智能大模型AI 应用媒体生成视频后端前端任务调度【免费下载链接】JellyfishAn end-to-end production workspace for AI-generated short dramas. From script input to structured storyboarding, consistency management, shot preparation, video generation, and export.项目地址https://gitcode.com/gh_mirrors/jellyfish9/Jellyfish点击查看免费下载相关推荐Spring 定时任务源码解析从 EnableScheduling 到任务执行的完整链路Spring 定时任务源码解析从 EnableScheduling 到任务执行的完整链路 本篇技术指南以 Spring Scheduling.md http文档教程知识库Jellyfish 当前系统架构全解析从顶层目录、任务执行到分镜状态流转Jellyfish 当前系统架构全解析从顶层目录、任务执行到分镜状态流转 导读 本文围绕 Jellyfish 仓库 site/content/docs/arc人工智能大模型AI 应用媒体生成视频后端前端任务调度wger后端任务优先级设置Celery健身任务的执行顺序wger后端任务优先级设置Celery健身任务的执行顺序 还在为健身应用任务执行顺序混乱而烦恼吗wger作为一款自托管的健身管理平台通过Celery任务队后端医疗健康上一篇3分钟搞定AutoHotkey脚本压缩与混淆从效率优化到代码加密全攻略下一篇magnetW数据库分表最佳实践策略与实现创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Jellyfish 任务执行架构解析：Celery 执行层、任务真相层与前端任务中心的完整链路
人工智能大模型AI 应用媒体生成视频后端前端任务调度【免费下载链接】JellyfishAn end-to-end production workspace for AI-generated short dramas. From script input to structured storyboarding, consistency management, shot preparation, video generation, and export.项目地址https://gitcode.com/gh_mirrors/jellyfish9/Jellyfish点击查看免费下载Jellyfish 是一个面向 AI 短剧生成的端到端生产工作台从剧本输入、结构化分镜、一致性管理到镜头准备与视频生成均有长耗时任务贯穿其中。本文基于仓库中 任务执行架构文档结合源码梳理当前真实生效的任务执行分层GenerationTask作为任务真相层、Redis Celery 作为执行层、前端任务中心作为统一反馈入口。读完本文你将掌握 Jellyfish 中任务从 API 创建、Celery 投递、worker 按task_kind路由执行到状态回写与取消收敛的完整调用链以及 sync / async 两类 executor 的分工与适用场景。当前执行分层两层结构 执行协议层 运行时分层Jellyfish 的长耗时任务执行采用清晰的分层设计文档原文给出的结构如下业务任务真相层 ├── GenerationTask ├── GenerationTaskLink ├── /api/v1/film/tasks ├── /api/v1/film/tasks/{task_id}/status └── /api/v1/film/tasks/{task_id}/result 执行层 ├── FastAPI 负责创建任务与返回 task_id ├── Redis 作为 Celery broker └── Celery Worker 执行长耗时任务 执行协议层 ├── GenerationTask.task_kind ├── task.execute统一 Celery 入口 └── TaskExecutorRegistrytask_kind → executor 运行时分层 ├── Web Runtime │ ├── async SQLAlchemy │ └── FastAPI dependencies └── Worker Runtime ├── sync SQLAlchemy └── Celery task wrappers worker services这套分层背后有明确的核心约束理解它们才能正确扩展任务类型GenerationTask仍是任务状态、结果、错误与取消请求的唯一真相源Celery 不承担业务状态对外暴露职责worker 执行完成后把状态与结果回写到 MySQL。/api/v1/film/tasks当前作为前端全局任务中心的主数据源。GenerationTaskLink当前承担任务与业务实体的关联信息查询relation_type/relation_entity_id。GenerationTask记录运行时指标started_at、finished_at任务状态接口直接暴露started_at_ts、finished_at_ts、elapsed_ms。前端不直接读取 Celery task 状态Celery 只负责执行、不负责对前端暴露业务状态。任务投递统一使用task_kind识别具体执行器。从模型看状态枚举在 types.py 中定义pending / running / streaming / succeeded / failed / cancelledTaskRecord与TaskListItemView均携带executor_type、executor_task_id、cancel_requested等执行与取消相关字段。最小基础设施MySQL Redis Celery Worker当前最小执行层方案为业务库MySQL BrokerRedis 执行器Celery Worker配置规则可在 config.py 中验证DATABASE_URL继续指向 MySQL默认值为sqliteaiosqlite:///./jellyfish.db需按环境显式覆盖。CELERY_BROKER_URL若未显式指定则按 Redis 配置自动拼接如redis://{host}:{port}/{db}。backend/.env由app.config按绝对路径加载避免 worker 因工作目录变化回退到默认 SQLite。Celery 应用实例位于 celery_app.py关键点brokersettings.celery_broker_urlinclude[app.tasks.execute_task]即统一任务入口模块。task_serializerjson、accept_content[json]、task_ignore_resultTrue第一阶段不依赖 Celery result backend业务结果仍回写GenerationTask。worker_process_init信号触发reset_db_runtime()保证 prefork 子进程启动后重建 async DB 运行时避免复用父进程残留的异步引擎。已切到 Celery 的任务清单与两类 executor当前已从本地asyncio.create_task(...)切到 Celery worker 的任务共 12 类divide、extract、check-consistency、optimize-script、simplify-script、analyze-character-portrait、analyze-prop-info、analyze-scene-info、analyze-costume-info、image-generation、video-generation、shot-frame-prompt。它们进一步分为两类执行方式完全不同已切到 sync worker runtime 的文本任务divide、extract、check-consistency、optimize-script、simplify-script、analyze-character-portrait、analyze-prop-info、analyze-scene-info、analyze-costume-info这 9 类任务通过以下组件执行不再在 Celery worker 中承载 async DB runtimedb_sync.py同步引擎把mysqlaiomysql://自动转换为mysqlpymysql://供同步 worker 使用SyncSqlAlchemyTaskStore见 stores.pyworker 专用同步 LLM runtimebuild_default_text_llm_syncscript_processing_worker.pyworker 侧执行逻辑所在地已切到 async delegating executor 的生成类任务image-generation、video-generation、shot-frame-prompt这三类任务同样通过task.execute(task_id)进入统一 Celery 执行层但执行器使用AbstractAsyncDelegatingExecutor作为桥接见 task_executor.py其行为包括每次任务执行前重建 async DB runtimereset_db_runtime()在独立 event loop 中运行既有 async serviceasyncio.run任务结束后主动释放 async engineclose_db()在执行前、结果生成后、结果持久化后执行统一取消检查通过 executor 统一配置任务超时输出统一任务事件日志started / running / cancelled / succeeded / failed这样可以先把执行从 Web 进程迁出同时保持图片 / 视频 provider 调用链的现有 async 实现。三类 async worker 已补最小专项测试重点锁定两点启动前取消请求会直接转cancelled、不再进入后续 provider / agent 调用。从注册表源码 task_registry.py 可以看到三类生成任务的默认超时配置task_kind执行器默认超时script_*九类文本任务各自*TaskExecutorsync无仅阶段边界检查video_generationAbstractAsyncDelegatingExecutor3600 秒image_generationAbstractAsyncDelegatingExecutor1800 秒shot_frame_promptAbstractAsyncDelegatingExecutor600 秒当前 Celery 主链路特征与两阶段模型当前主链路的完整流程API 层创建GenerationTaskAPI 层写入task_kind通过spawn_*_task(...)投递到 CeleryCelery 统一走task.execute(task_id)worker 通过TaskExecutorRegistry按task_kind路由到具体WorkerTaskExecutorworker 执行后把状态与结果回写到 MySQL页面继续通过既有任务状态接口轮询和恢复统一入口实现在 execute_task.pyenqueue_task_execution(task_id)调用run_task_celery.delay(task_id)并把executor_typecelery、executor_task_id回写到GenerationTask便于排障与后续 revoke。run_task_celeryCelery task 名为task.execute按task_id读取task_kind优先用字段值字段为空时回退读payload.task_kind再用task_executor_registry.resolve(task_kind)找到执行器并执行。revoke_task_execution(task_id)仅当executor_type celery且存在executor_task_id时才下发AsyncResult(...).revoke(terminateTrue, signalSIGTERM)。前端入口侧generated_video.py 与 tasks_images.py 均通过enqueue_task_execution(task_record.id)投递确认了API 创建 → 统一投递的链路。两阶段模型生成结果 vs 应用结果对核心任务如divide采用两阶段模型阶段 A生成结果 → 调 LLM / Agent → GenerationTask.result 阶段 B应用结果 → 写业务表 → 更新业务状态在AbstractWorkerTaskExecutor.runtask_executor.py中这一模型被固化为三段式生命周期_execute_phase生成结果并写result→_apply_and_finishshould_apply判断后apply_result写业务表再置为succeeded→ 统一succeeded日志。进度数值也有固定约定running_progress5、result_progress70、succeeded_progress100。当前有真实前端入口的 script-processing 文本任务已统一挂到AbstractWorkerTaskExecutor、AbstractLLMResultGenerator、TaskExecutorRegistry。已模板化的 sync executor 包括script_divide、script_extract、script_consistency、script_character_portrait、script_prop_info、script_scene_info、script_costume_info、script_optimize、script_simplify已接入 registry 的非文本生成 executor 包括image_generation、video_generation、shot_frame_prompt。超时语义阶段边界超时而非强中断sync executor 提供统一 started / succeeded / failed / cancelled 日志与统一阶段边界超时检查。超时语义是阶段边界超时而非执行中强中断检查点有三处_ensure_not_timed_out在进入执行前检查在生成结果后检查在 apply 后检查这意味着单次 LLM 长调用内部不会被打断超时只会在阶段边界生效对 async 三类任务则使用asyncio.wait_for包装整个 runner超时后抛TimeoutError并落failed。全局任务列表接口规则/api/v1/film/tasks的查询规则见 task_status.py 与 stores.py默认返回活跃任务pending / running / streaming与最近结束的任务时间窗口由recent_seconds控制API 默认值为 300 秒ge0, le86400。支持按statuses多选、task_kind、relation_type、relation_entity_id过滤。返回项同时包含任务状态与进度、started / finished / elapsed 指标、executor 信息executor_type/executor_task_id、relation 信息relation_type/relation_entity_id/resource_type、前端默认导航对象信息navigate_relation_type/navigate_relation_entity_id用于任务中心回到对应章节 / 镜头 / 资产。导航对象的解析逻辑在_resolve_navigation_targets中chapter_division / script_extraction / consistency_check / script_optimization / script_simplification映射到chaptervideo / shot_first_frame_prompt / shot_last_frame_prompt / shot_key_frame_prompt映射到shotshot_frame_image反查ShotFrameImage归属的 shotactor_image / scene_image / prop_image / costume_image / character_image反查各自的宿主实体。当前前端任务中心以该接口为主列表来源页面自身只补充两类轻量信息当前页面关联对象的高亮上下文、任务标题 / 来源 / 跳转等即时 UI 元信息。前端任务状态展示页面局部反馈 轻量全局提示当前前端采用页面局部反馈 轻量全局提示旧的页面内大块任务提示组件已退出主流程。具体交互形态触发任务的按钮负责loading状态、防重复点击并帮助用户确认是哪个动作正在运行。任务详情通过 Notification 展示当前状态、进度、开始时间、已运行 / 累计耗时、任务结束后的成功 / 失败 / 取消反馈支持直接跳回来源页面。取消入口优先放在触发区域旁的轻量按钮与 Notification 内的小型取消动作。悬浮任务中心统一展示全局任务列表交互细节包括默认隐藏是否展开按本地历史状态恢复首次进入时悬浮按钮默认位于左下角浮动按钮支持在视窗范围内拖动拖动结束后自动吸附到左侧或右侧边缘并记住最近一次位置展开面板根据按钮位置自动调整展开方向与对齐方式避免超出当前视窗查看当前运行中的任务、最近刚结束的任务显示任务所属对象或来源页面、进度、开始时间和耗时统一执行取消操作支持回到对应来源页面任务结束后短暂保留便于确认执行结果支持按当前页面 / 运行中 / 最近结束与任务类型做轻量筛选面板保持轻量化每页最多展示 3 条任务翻页使用紧凑箭头控件当前页面只负责提供高亮哪些任务与当前对象有关的上下文不再决定任务是否存在高亮匹配优先使用任务的默认导航对象navigate_relation_typenavigate_relation_entity_id后端未返回时回退到原始relation_type relation_entity_id。对未由当前页面显式补充来源信息的任务任务中心按relation_type relation_entity_id自动解析默认来源文案并尽量推导默认查看跳转。主要异步任务的启动、运行中、取消和结束态提示文案已统一收口同类任务在不同页面保持一致语气后续新增任务应复用同一套文案配置。已从页面内大块提示切换到这套较轻交互的页面包括分镜管理页、分镜编辑页、分镜工作室、原文编辑弹窗、资产编辑页、项目工作台章节列表中的分镜提取入口。图片生成页与分镜工作室中的生成动作也已接入同一套 Notification / 任务中心桥接不再只依赖页面内message 手写轮询。仍未切到 Celery 的任务预备能力以下任务当前仍保留旧执行方式且没有真实前端主入口因此不作为主线优先项merge-entitiesanalyze-variants它们虽已纳入任务模型但当前仍属于预备能力接入时可直接复用本文所述的三件套executor 模板 registry 注册 task.execute统一投递。取消语义两级取消当前取消采用两级取消模型前端请求取消 → GenerationTask.cancel_requested true → 若任务由 Celery 执行且存在 executor_task_id → 立即下发 revoke(terminateTrue) → API 直接把业务任务状态推进到 cancelled → 若无法立即终止 → worker 在阶段边界继续执行协作式取消这意味着对已进入 Celery worker 的任务支持 best-effort 的立即取消对应 execute_task.py 中revoke_task_execution下发 SIGTERM。对无法立即终止的单次长调用如单次 LLM 调用内部保留阶段边界协作式取消作为兜底_cancel_if_requested会在进入执行前、生成结果后、apply 后分别检查cancel_requested一旦命中立即mark_cancelled并终止后续阶段。当前不承诺 provider / LLM SDK 层面的绝对强终止只保证业务任务状态会立即收敛。在 store 层stores.pyrequest_cancel会把cancel_requested置真并记录cancel_reason且对仍处于pending的任务直接置为cancelledmark_cancelled则负责把运行中的任务收敛到终态cancelled。服务层约束防止循环导入与依赖倒置任务执行链必须遵守以下约束service层不得反向依赖api.v1.routesCelery task wrapper 只做 task_id 投递worker 侧执行逻辑放在app.services.script_processing_workerWeb 侧任务创建与状态恢复逻辑保留在app.services.script_processing_tasks这条约束已用于修复 worker 下暴露出的循环导入问题是新增任务类型时必须遵守的边界。新增一个任务的推荐路径是定义 executor继承AbstractWorkerTaskExecutor或AbstractAsyncDelegatingExecutor→ 在app.services.worker.task_registry中注册 → API 创建GenerationTask并写task_kind→ 调用enqueue_task_execution投递即可复用完整的日志、超时、取消与状态回写链路。赞分享人工智能大模型AI 应用媒体生成视频后端前端任务调度【免费下载链接】JellyfishAn end-to-end production workspace for AI-generated short dramas. From script input to structured storyboarding, consistency management, shot preparation, video generation, and export.项目地址https://gitcode.com/gh_mirrors/jellyfish9/Jellyfish点击查看免费下载相关推荐Spring 定时任务源码解析从 EnableScheduling 到任务执行的完整链路Spring 定时任务源码解析从 EnableScheduling 到任务执行的完整链路 本篇技术指南以 Spring Scheduling.md http文档教程知识库Jellyfish 当前系统架构全解析从顶层目录、任务执行到分镜状态流转Jellyfish 当前系统架构全解析从顶层目录、任务执行到分镜状态流转 导读 本文围绕 Jellyfish 仓库 site/content/docs/arc人工智能大模型AI 应用媒体生成视频后端前端任务调度wger后端任务优先级设置Celery健身任务的执行顺序wger后端任务优先级设置Celery健身任务的执行顺序 还在为健身应用任务执行顺序混乱而烦恼吗wger作为一款自托管的健身管理平台通过Celery任务队后端医疗健康上一篇3分钟搞定AutoHotkey脚本压缩与混淆从效率优化到代码加密全攻略下一篇magnetW数据库分表最佳实践策略与实现创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考