Temporal 是：

Temporal 可以理解为“生产级长任务/多步骤流程的可靠执行系统”。它解决的不是“AI 怎么思考”，而是：

一个业务流程跑到一半失败、超时、服务重启、Worker 挂掉之后，系统还能不能记住进度，并继续把任务跑完。

Temporal 官方把 Workflow Execution 定义为一种 durable, reliable, scalable function execution，也就是“持久、可靠、可扩展的函数执行”。它的 Task Queue 里的任务会持久保存；Worker 掉线后，任务不会丢，等 Worker 恢复后可以继续处理。

---

1. 先用一句话理解 Temporal

普通后端任务是：

程序运行中 → 程序挂了 → 状态丢了 → 任务失败

Temporal 是：

程序运行中 → 程序挂了 → Temporal 记得执行历史 → 换个 Worker 继续跑

所以它的核心价值是：

让长流程任务像普通函数一样写，但具备断点恢复、自动重试、超时控制、状态持久化能力。

2. 为什么需要 Temporal？

比如你的视频分析系统：

1. 用户上传视频
2. 保存视频文件
3. 提取音频
4. 音频转文字
5. 调用大模型分析 transcript
6. 生成摘要
7. 匹配标签
8. 保存数据库
9. 返回结果

如果第 5 步调用大模型时失败了，普通系统可能会出现这些问题：

任务挂了
状态丢了
用户不知道分析到哪一步
重复执行整个流程
数据库写了一半
文件生成了一半
需要人工排查

Temporal 的作用就是把这种流程变成：

第 1-4 步已经成功
第 5 步失败
Temporal 记录失败位置
按照重试策略重新执行第 5 步
成功后继续第 6-9 步

它不是单纯“异步执行”，而是可靠地执行整个业务流程。

---

3. Temporal 的几个核心概念

3.1 Workflow：业务流程本身

Workflow 就是你定义的完整业务流程。

比如：

VideoAnalysisWorkflow

里面可以写：

保存视频
提取音频
ASR转文字
LLM分析
保存结果

Workflow 更像“大脑”或者“流程图”。

它负责决定：

先做什么
后做什么
失败后怎么办
什么时候超时
是否并行执行
是否等待人工确认

3.2 Activity：真正干活的步骤

Activity 是 Workflow 里面的一个个具体任务。

例如：

save_video()
extract_audio()
transcribe_audio()
call_llm()
save_result()

这些才是真正会访问外部系统的代码，比如：

读写数据库
调用大模型 API
读写 MinIO/OSS
调用 FFmpeg
请求第三方接口

Temporal 里一般有一个重要原则：

Workflow 负责流程控制
Activity 负责具体执行

也就是：

Workflow 不直接干重活
Activity 去干重活

---

3.3 Worker：执行 Workflow 和 Activity 的进程

Worker 就是跑在你服务器上的进程。

它会去 Temporal 的 Task Queue 里拉任务，然后执行。

类似：

Worker A：处理视频任务
Worker B：处理 ASR 任务
Worker C：处理 LLM 分析任务

如果 Worker 挂了，Temporal 里的任务还在。官方文档也说明，Workflow 和 Activity Tasks 会持久存在于 Task Queue 中，Worker 掉线后任务会保留，直到 Worker 恢复并处理。

---

3.4 Task Queue：任务队列

Task Queue 是 Temporal 分发任务的地方。

你可以理解成：

Temporal Server 把任务放到 Task Queue
Worker 从 Task Queue 拉任务执行

比如：

video-task-queue
llm-task-queue
asr-task-queue

这样可以把不同任务交给不同类型的 Worker。

---

3.5 Temporal Server：调度和记录中心

Temporal Server 不直接执行你的业务代码。

它主要负责：

记录 Workflow 执行历史
调度任务
管理重试
管理超时
管理状态
把任务分发给 Worker

Temporal Server 后面一般会有数据库，例如 PostgreSQL、MySQL、Cassandra 等，用来保存 Workflow 的执行历史和状态。

---

4. Temporal 最重要的机制：Event History

Temporal 最核心的东西是 Event History，也就是“执行历史”。

比如一个视频任务跑过这些步骤：

Workflow Started
Activity save_video Scheduled
Activity save_video Completed
Activity extract_audio Scheduled
Activity extract_audio Completed
Activity transcribe_audio Scheduled
Activity transcribe_audio Failed
Activity transcribe_audio Retried
Activity transcribe_audio Completed
Activity call_llm Scheduled

Temporal 会把这些关键事件记录下来。

所以当 Worker 挂了之后，它不是“凭感觉恢复”，而是根据历史记录恢复：

前面哪些步骤成功了？
哪些步骤失败了？
哪些步骤需要重试？
Workflow 当前应该继续到哪里？

官方文档提到，Workflow Task 执行时，Worker 会 replay 代码，并基于 Event History 做决策；Activity 的结果会来自历史记录，replay 时不会真的重新执行 I/O。

这点非常关键。

---

5. Temporal 怎么做到“服务器挂了也能继续”？

假设你的流程是：

result1 = step_a()
result2 = step_b(result1)
result3 = step_c(result2)

普通程序：

step_a 成功
step_b 成功
step_c 之前服务器挂了
变量 result1/result2 丢了
任务失败

Temporal：

step_a 成功 → 记录到 Event History
step_b 成功 → 记录到 Event History
服务器挂了
新 Worker 启动
Temporal replay Workflow
恢复 result1/result2
继续执行 step_c

所以 Temporal 的本质不是“程序一直不挂”，而是：

程序可以挂，但执行历史不能丢；只要历史还在，就可以恢复。

Temporal 的 Durable Execution 也常被解释为 crash-proof execution，也就是程序崩溃后仍能恢复执行。

---

6. Temporal 和 Celery / Redis 最大区别

这套架构是：

FastAPI 接收任务
Celery 把任务丢进队列
Worker 执行任务
Redis 作为 broker

适合简单异步任务。

但是 Celery 更像：

执行一个任务

Temporal 更像：

管理一个完整业务流程

对比一下：

对比项	Celery	Temporal
核心定位	异步任务队列	持久工作流引擎
适合任务	简单后台任务	多步骤、长时间、强可靠流程
状态记录	需要自己设计	Temporal 自动记录执行历史
失败重试	支持，但偏任务级	支持，并且和流程状态结合
断点恢复	较弱，需要自己写	核心能力
多步骤流程	需要自己串联	原生支持
补偿事务	需要自己设计	适合 Saga 模式
长时间等待	不太优雅	原生支持 Timer/Sleep
可观测性	需要额外搭建	Temporal Web 可看 Workflow 状态
学习成本	较低	较高

简单说：

Celery = 把一个函数丢后台跑
Temporal = 把一个业务流程可靠地跑到底

---

7. Temporal 的典型能力

7.1 自动重试

比如 LLM API 超时：

第一次调用失败
等待 5 秒
第二次失败
等待 30 秒
第三次失败
等待 2 分钟
成功后继续流程

你不需要在每个地方手写复杂重试逻辑，可以给 Activity 配 retry policy。

---

7.2 超时控制

Temporal 可以控制：

这个 Activity 最多执行多久
这个 Workflow 最多运行多久
这个任务多久没人接就超时
这个任务从调度到完成最多多久

这对视频分析很有用。

比如：

ASR 最多跑 30 分钟
LLM 分析最多 5 分钟
整个视频分析流程最多 2 小时

---

7.3 断点恢复

比如流程跑到这里：

保存视频 ✅
提取音频 ✅
ASR 转文字 ✅
LLM 分析 ❌

Temporal 不需要重头来：

不用重新保存视频
不用重新提取音频
不用重新 ASR
只需要重试 LLM 分析

这对成本很重要，因为 ASR 和 LLM 都可能花钱。

---

7.4 长时间等待

Temporal 很适合这种流程：

提交申请
等待人工审核
3 天后自动提醒
7 天未处理自动关闭

普通系统要写定时任务、状态表、轮询逻辑。

Temporal 可以直接在 Workflow 里表达：

等待人工信号
或者等待 7 天超时

---

7.5 人工介入

Temporal 支持 Signal，也就是外部可以给正在运行的 Workflow 发消息。

例如：

视频分析结果置信度低
↓
Workflow 暂停
↓
等待管理员确认标签
↓
管理员确认后继续保存结果

这个就很适合你的视频标签审核系统。

---

7.6 补偿事务 / Saga

比如一个流程有多个步骤：

扣库存
创建订单
调用支付
生成发票
通知用户

如果后面失败了，可能要回滚前面的动作。

Temporal 可以很适合实现 Saga：

第 1 步成功
第 2 步成功
第 3 步失败
执行补偿：
撤销订单
恢复库存

在你的视频系统里也可以类似：

上传文件成功
数据库任务创建成功
ASR 文件生成成功
LLM 失败
补偿：
清理临时音频
标记任务失败
保留原视频

---

8. Temporal 的运行结构

典型架构是：

FastAPI
  ↓
Temporal Client
  ↓
Temporal Server
  ↓
Task Queue
  ↓
Worker
  ↓
Activity 执行具体任务

放到你的系统里：

用户上传视频
↓
FastAPI 保存视频到 MinIO/OSS
↓
FastAPI 启动 Temporal Workflow
↓
Temporal Server 记录 Workflow
↓
Worker 执行 extract_audio Activity
↓
Worker 执行 ASR Activity
↓
Worker 执行 LangGraph Analysis Activity
↓
Worker 执行 save_result Activity
↓
PostgreSQL 更新任务状态

---

9. 和 LangGraph 组合时怎么分工？

你前面问的 Temporal + LangGraph，最合理的关系是：

Temporal 管外层任务可靠性
LangGraph 管内层 AI 决策逻辑

比如：

Temporal Workflow:
1. save_video
2. extract_audio
3. transcribe_audio
4. analyze_with_langgraph
5. validate_result
6. save_result

其中：

analyze_with_langgraph

内部可以是 LangGraph：

读取 transcript
↓
判断 primary_label
↓
查询标签体系
↓
选择 2-6 个三级标签
↓
检查标签是否重复/过窄
↓
生成摘要
↓
输出 JSON

也就是说：

Temporal 不负责“AI 怎么想”
LangGraph 不负责“任务挂了怎么恢复”

组合起来就是：

Temporal = 可靠执行外壳
LangGraph = AI 分析大脑

---

10. 用 Temporal 改造你的视频分析系统

你现在可能是：

FastAPI
↓
Celery Task
↓
process_video()

里面可能写成：

def process_video(task_id):
    extract_audio()
    transcribe()
    call_llm()
    save_result()

问题是：

中间失败后，不好知道到哪一步
重试可能重头开始
状态要自己维护
任务链路长了很难 debug

Temporal 版本可以设计成：

VideoAnalysisWorkflow
  ├── save_video_activity
  ├── extract_audio_activity
  ├── transcribe_activity
  ├── analyze_transcript_activity
  ├── validate_labels_activity
  ├── save_result_activity
  └── cleanup_activity

每一步都可以单独配置：

重试次数
超时时间
失败处理
是否可并行
是否需要补偿

---

11. 一个伪代码例子

不要纠结语法，先看结构：

@workflow.defn
class VideoAnalysisWorkflow:
    @workflow.run
    async def run(self, task_id: str, video_path: str):
        audio_path = await workflow.execute_activity(
            extract_audio,
            video_path,
            start_to_close_timeout=timedelta(minutes=10),
            retry_policy=RetryPolicy(maximum_attempts=3),
        )

        transcript = await workflow.execute_activity(
            transcribe_audio,
            audio_path,
            start_to_close_timeout=timedelta(minutes=30),
            retry_policy=RetryPolicy(maximum_attempts=5),
        )

        analysis = await workflow.execute_activity(
            analyze_with_langgraph,
            transcript,
            start_to_close_timeout=timedelta(minutes=5),
            retry_policy=RetryPolicy(maximum_attempts=3),
        )

        await workflow.execute_activity(
            save_result,
            task_id,
            analysis,
            start_to_close_timeout=timedelta(minutes=2),
        )

        return analysis

这个流程的意思是：

提取音频失败 → 最多重试 3 次
ASR 失败 → 最多重试 5 次
LangGraph 分析失败 → 最多重试 3 次
保存结果失败 → 单独处理

关键是：
前面成功的结果会被 Temporal 记录下来，不需要你自己到处写状态恢复逻辑。

---

12. Temporal 适合哪些场景？

非常适合：

视频处理流程
AI 分析管道
订单履约
支付流程
退款流程
物流跟踪
数据同步
爬虫任务
审批流程
风控流程
多系统调用
需要人工确认的流程
长期等待任务

不太适合：

非常简单的一次性小任务
毫秒级高频计算
纯缓存任务
只需要简单定时任务
没有失败恢复要求的小项目

---

13. Temporal 的缺点

它不是没有成本。

主要缺点是：

学习成本比 Celery 高
架构更重
需要部署 Temporal Server
需要理解 Workflow / Activity / Worker / Task Queue
Workflow 代码要遵守确定性要求
本地开发调试需要适应
小项目可能显得过度设计

尤其要注意一个点：

Workflow 代码要“确定性”

Temporal 的 Workflow 会 replay，所以 Workflow 里面不能随便写不确定逻辑。

比如不要在 Workflow 里面直接写：

random.random()
datetime.now()
requests.get()

这些应该放到 Activity 里面。

正确理解是：

Workflow 写流程控制
Activity 写外部调用和不确定操作

---

14. 你的项目什么时候该用 Temporal？

如果你现在只是：

用户上传视频
后台分析
返回结果

而且失败了可以手动重跑，那么：

Celery + Redis + PostgreSQL 暂时够用

如果你开始遇到这些问题：

视频任务经常跑一半失败
LLM / ASR 经常超时
用户任务不能丢
需要知道每一步状态
需要断点续跑
需要自动重试
需要人工审核
需要多个 Worker 分工
任务越来越长

那就很适合引入 Temporal。

---

15. 最适合你的架构建议

你的最终架构可以是：

FastAPI
  ↓
PostgreSQL：用户、任务、结果、标签体系
  ↓
MinIO / OSS：视频、音频、截图、结果文件
  ↓
Temporal：编排视频分析长流程
  ↓
Worker：执行具体任务
  ↓
LangGraph：处理 transcript 分析和标签选择
  ↓
Vector DB：标签体系/课程知识/历史案例检索
  ↓
LLM API：摘要、标签理由、结构化输出

更具体一点：

FastAPI：
接收上传、返回 task_id、查询任务状态

Temporal：
管理任务从上传到完成的全流程

Worker：
跑 FFmpeg、ASR、LLM、数据库写入

LangGraph：
做标签判断、摘要生成、工具调用

PostgreSQL：
存任务状态、用户信息、分析结果

MinIO/OSS：
存视频、音频、图片、大文件

Redis：
可保留做缓存、限流、临时状态，但不再作为核心任务可靠性来源

---

16. 最简单的理解总结

你可以这样记：

Celery：把任务丢给后台跑
Temporal：让复杂任务可靠地跑完
LangGraph：让 AI 知道下一步该干嘛

对于你的系统：

Temporal 解决“任务会不会丢、失败后怎么恢复”
LangGraph 解决“AI 怎么分析、怎么调用工具”
PostgreSQL 解决“业务数据怎么存”
MinIO/OSS 解决“大文件怎么存”
Redis 解决“缓存和临时加速”