Temporal
Temporal是一个开源的分布式工作流编排平台，用于构建可靠的长时运行业务流程和微服务应用。它通过事件溯源机制持久化记录工作流的每次状态变更，在进程崩溃或重启后能自动重放历史事件以恢复执行状态，从而为开发者屏蔽分布式系统中的故障处理复杂性，支持多种主流编程语言。
核心事实
时间轴 (近 90 天)
Temporal 是 TC39 提案中的现代化日期时间 API，将时间点（Temporal.Instant）和带时区的本地时间（Temporal.ZonedDateTime）等类型严格区分。
Temporal 目前不是全局默认导出可直接替换 Date 的语法糖，而是独立命名空间 Temporal。
把 LangGraph 的节点执行包装成 Temporal Activity 会引入额外的序列化约束和确定性要求，且检查点语义需要在两套状态机之间做映射，因此社区实践多是“借用其租约与重试能力，自建 LangGraph 适配层”，而非直接替换。
持久化任务框架（如Temporal、Restate、Pi Durable）的核心思路是把任务的每一步执行状态写入持久化存储，使任务在故障后能从断点恢复，并保证同一任务不会被重复触发。
在 Agent 场景中，使用 Temporal 时所有非确定性操作（如 LLM 调用、工具执行）应封装为 Activity，工作流层只消费其结果，否则重放会导致重复扣费或状态错乱。
编排层选型建议：如果任务时长超过几分钟且需要人工审批，优先考虑 Temporal 或 Inngest；如果追求极致控制且团队有工程能力，可自研事件驱动循环。
自建基于数据库的状态机方案需要自行处理幂等性写入、检查点粒度、并发控制和状态清理等正确性保证，这是许多团队规模化后转向工作流引擎的原因。
用 SIGKILL 在扫描中途杀掉工作进程的耐久性测试中，12 件物品第一个 worker 刷了 3 件，重启后第二个 worker 刷了 9 件，重复刷新 0 件，活动执行 24 次（期望值 24）。
Sourcerer 的批量重新定价任务跑在 Temporal 上，每个物品两个活动：刷新可比数据、应用新价格。
LangGraph、Temporal和LiteLLM等工具处理的是执行机制，而非执行治理，它们不判断输出内容是否满足业务正确性约束。
还有 40 条时间轴事件
全部知识事实 (20)
Temporal通过事件溯源（Event Sourcing）记录工作流的每次状态变更，当进程恢复时通过重放事件来重建状态
90%已验证Temporal 采用事件溯源机制，将所有函数调用历史记录为不可变日志，可从日志重放恢复执行位置
80%已验证Temporal将工作流抽象为可持久化、可恢复的代码执行单元，即便进程崩溃或机器宕机，工作流执行状态也能被保存并从中断处继续
75%已验证Temporal.io是持久执行（Durable Execution）框架的代表，通过持久化工作流执行历史使任务在基础设施故障后自动恢复
65%已验证Temporal是企业级编排引擎，由前Uber工程师开发，其核心优势是持久执行（Durable Execution），即使服务崩溃或重启工作流状态也能自动恢复
65%已验证AI Agent的执行路径由LLM在运行时动态决定，同一输入在不同时刻可能触发完全不同的工具调用序列
65%待验证ACPX的设计哲学介于传统工作流引擎（如Apache Airflow、Temporal）与纯Agent编排框架（如LangGraph、CrewAI）之间
85%待验证当前Agent编排领域存在抽象层级错配的两极分化格局：重量级方案如LangGraph、Temporal、AWS Step Functions抽象层级过高，轻量级工具如PM2、Supervisor抽象层级过低
80%部分验证持久化执行引擎（Durable Execution）的代表性实现包括Temporal、AWS Step Functions以及LangGraph Platform
75%待验证端到端完整应用在工程意义上需要打通数据层、业务逻辑层和表现层三个维度
70%待验证AgentSpan的设计借鉴了分布式工作流引擎（如Apache Airflow、Temporal）的思路
70%待验证类似编排层的产品包括LangChain/LangGraph、LlamaIndex Workflows、Temporal等
60%待验证Temporal 是 TC39 提案中的现代化日期时间 API，将时间点（Temporal.Instant）和带时区的本地时间（Temporal.ZonedDateTime）等类型严格区分。
50%待验证Temporal 目前不是全局默认导出可直接替换 Date 的语法糖，而是独立命名空间 Temporal。
50%待验证把 LangGraph 的节点执行包装成 Temporal Activity 会引入额外的序列化约束和确定性要求，且检查点语义需要在两套状态机之间做映射，因此社区实践多是“借用其租约与重试能力，自建 LangGraph 适配层”，而非直接替换。
50%待验证持久化任务框架（如Temporal、Restate、Pi Durable）的核心思路是把任务的每一步执行状态写入持久化存储，使任务在故障后能从断点恢复，并保证同一任务不会被重复触发。
50%待验证自建基于数据库的状态机方案需要自行处理幂等性写入、检查点粒度、并发控制和状态清理等正确性保证，这是许多团队规模化后转向工作流引擎的原因。
50%待验证编排层选型建议：如果任务时长超过几分钟且需要人工审批，优先考虑 Temporal 或 Inngest；如果追求极致控制且团队有工程能力，可自研事件驱动循环。
50%待验证在 Agent 场景中，使用 Temporal 时所有非确定性操作（如 LLM 调用、工具执行）应封装为 Activity，工作流层只消费其结果，否则重放会导致重复扣费或状态错乱。
50%待验证Sourcerer 的批量重新定价任务跑在 Temporal 上，每个物品两个活动：刷新可比数据、应用新价格。
50%