Agent 的 DAG 工作流引擎与分布式任务图调度工程 2026：从 Temporal 持久化状态机、Airflow ETL 遗产、Prefect/Dagster 资产中心、到 Ray 分布式 actor 调度的工程真相与六件套决策框架

一、问题的提出：Agent 任务为何需要工作流引擎而不是裸 Python 函数

把一个生产级 Agent 系统从 demo 推到生产，工程团队通常会遇到一个共同的拐点：调一次 await agent.run(prompt) 没问题，调一百次并发也没问题，但当任务跨越"分析 → 调用工具 → 等待异步事件 → 状态分支 → 数十秒到数小时不等"的复合形态，且必须保证任何一步失败都可恢复、任何一步都可重放、任何一步的中间状态都可审计时，裸 Python 函数、LangChain 的 Chain、LangGraph 的 StateGraph、CrewAI 的 Crew 都不再是合适的工程单元。问题的本质不是"Agent 是否需要 DAG"，而是"当一个 Agent 任务的执行时间从秒级跃迁到分钟到小时级、且必须跨越进程崩溃、网络分区、LLM 不可用、人类审批这些工程事件时，应当由谁来持有状态、由谁来驱动步骤、由谁来保证 exactly-once 与可重放"。这就是 2026 年所有严肃 Agent 平台都在某处集成或自研一套工作流引擎的根因。

需要立刻澄清的是，本文不讨论"用什么 LLM 框架"——OpenAI Agents SDK、Claude Agent SDK、LangGraph、Autogen、CrewAI 都不是工作流引擎；它们是 Agent 的"思考层"。本文要讨论的，是当思考层决定"下一步该做什么"之后，那个"做"的动作应当如何被调度、被持久化、被重试、被回滚、被审计、被观测。本文也不会假装"工作流引擎对所有 Agent 都是必要的"——对一个 1-3 步、纯同步、单进程的 Agent 来说，写一个 async 函数即可；工作流引擎的工程成本（学习曲线、运维负担、持久化存储、调试黑盒）只有在"长、异步、可恢复"三件事同时出现时才回本。

二、形式化：工作流引擎的核心契约——持久化、确定性、可重放

工作流引擎的工程本质可以用一个五元组 (Σ, A, T, R, E) 来形式化：

• Σ 是工作流状态机（Workflow State Machine）。所有持久化的中间事实、信号、定时器、子工作流句柄、补偿指令都存在 Σ 里。
• A 是活动定义（Activity）。一个活动 = 一个有副作用的代码单元（调 LLM、调工具、调 HTTP、调数据库），活动有输入、有输出、有超时、有重试策略、有不可逆的语义。
• T 是定时器（Timer / Sleep / Timeout）。Agent 的"等 5 分钟"、"等用户回复"、"等外部 webhook"在引擎层都表达为定时器。
• R 是重试与补偿规则（Retry Policy / Compensation）。每条活动都可以声明 maxAttempts、backoffCoefficient、nonRetryableErrorTypes；失败后是否触发补偿 saga（try/catch/finally 的工作流版本）。
• E 是事件与信号（Signal / External Event）。Agent 工作中"用户中途修正了方向"、"工具调用成功但需要人工审批"、"另一个工作流报告完成"都通过 E 注入状态机。

这五元组背后有三个不可妥协的工程契约，缺一即不配叫工作流引擎：

契约 1：持久化（Durability）。工作流的每一步执行、每一条信号、每一个定时器都必须在执行前落盘到持久化存储（PostgreSQL / Cassandra / RocksDB）。这一步不是优化项，是正确性的前提——只有落盘了，进程崩溃后从最后落盘点重放才是确定的。Temporal 的核心论文（Cadence 论文的工程演进版）反复强调：持久化颗粒度越细，重放代价越低，回滚边界越窄。

契约 2：确定性重放（Deterministic Replay）。崩溃后重启一个工作流时，引擎必须能从事件历史（Event History）里"重放"每一步，并保证重放产出的中间状态与崩溃前完全一致。这一条要求工作流代码本身是确定性的（同一份输入产出同一份输出），同时活动的副作用必须被显式标记为"non-deterministic, will be re-executed on replay"。这是为什么工作流代码中禁止直接调用 random.random() 或 datetime.now()——它们必须被引擎控制的 deterministic clock / id generator 替换。

契约 3：可恢复性（Recoverability）。活动失败、网络超时、worker 崩溃三种故障模式必须被统一处理：活动失败按 retry policy 走；网络超时走幂等键（idempotency key）；worker 崩溃由另一个 worker 在超时后接管。Activity Heartbeat 是这套机制的核心——worker 必须在活动执行期间定期发送"我还活着"的信号，引擎才知道何时该认为 worker 已死、何时该重试。

理解了这三个契约，下文对每个引擎的评估就不是"哪个更好"，而是"哪个把这三个契约实现得更适合 Agent 的真实负载"。

三、Temporal/Cadence 派：持久化工作流的状态机真相

Temporal（2026-07-29 拉取，星标 21.9k，fork 1.7k，最后提交 24 小时内）与其前身 Cadence 是"持久化工作流引擎"这一品类的标准实现。它的核心数据结构是 Event History——一条工作流的所有事件（WorkflowExecutionStarted、ActivityTaskScheduled、ActivityTaskCompleted、TimerStarted、TimerFired、WorkflowExecutionSignaled）按时间顺序追加到持久化存储，引擎从 Event History 重放状态机。

在 Agent 场景下 Temporal 的杀手锏是 Activity-as-Tool 模式：把每一个 LLM 调用、工具调用、HTTP 请求、数据库读写都包成 Activity（一个 @activity.defn 装饰的 Python 函数），把 Agent 的"决策—执行"循环写成一个 Workflow（一个 @workflow.defn 装饰的函数，里面只允许 deterministic code：控制流、调用 Activity、等待 Timer、等待 Signal）。Activity 在另一台机器上跑，失败自动重试，Activity Heartbeat 保证长任务的健康监测。

Temporal 与 Cadence 的关键差异在于多租户隔离（Temporal Cloud 的 Namespace 与 Cadence 的 Domain 概念对等）、worker 部署模式（Temporal 倾向 dynamic workflow + worker poll，Cadence 倾向 decision task polling）、以及生态成熟度。2026 年 Temporal 的 Python SDK 已经支持 OpenAI 工具调用的 deterministic 包装——具体做法是把 LLM 调用的 stream、function calling 的 tool 选择、response 解析都包成 Activity，Workflow 层只做"调用 Activity → 检查返回 → 决定下一步"。这种模式让一个 30 步的 Agent 任务在 worker 崩溃后能从第 17 步精确恢复，不会从头重跑。

工程真相 1：Temporal 的 Event History 大小是有限制的。默认 50MB Event History 限制意味着一个长工作流跑久了会触发 "Event History is too large" 错误。生产环境的解决方法是 Continue-As-New（每几千步主动"重启"工作流，把当前状态作为参数传给新工作流实例），这是 Temporal 的"自我截断"机制，不是 bug 而是设计。

工程真相 2：Temporal 的 worker 进程模型与 Agent 的异步特性天然契合。一个 worker 进程可以跑多个工作流的多个 Activity，Activity 通过 task queue 路由；这意味着 Agent 系统的横向扩展是"加 worker 实例"而不是"加 Agent 实例"，调度层与执行层解耦。

工程真相 3：Cadence 的生态在 2026 年仍有特定场景价值——尤其是需要严格 on-premise 部署、强一致性、跨数据中心复制的金融与电信场景。Cadence 的 cross-DC replication 是 Temporal Cloud 至今未完全追平的能力。

四、Airflow 派：DAG 调度器的 ETL 遗产与 Agent 适配的真相

Apache Airflow（2026-07-29 星标 46.3k，fork 17.4k）是 DAG 调度器品类的代名词，但它的核心抽象——DAG（有向无环图）+ Operator（图节点）+ TaskInstance（一次执行实例）——是为 ETL 而生的，不是为长工作流而生的。

Airflow 的 DAG 是静态的：定义一次，按 schedule 周期触发，每次触发产生一次 DagRun，每个 TaskInstance 是一次执行。Agent 任务的"长、异步、可恢复"特性在这里遇到了三个工程困境：

困境 1：静态 DAG vs 动态 Agent 决策。Airflow 的 DAG 在调度器启动时（或者触发时）就被解析成静态结构；Agent 的下一步决策由 LLM 产出，无法预先静态定义 DAG。Airflow 3.x 引入了 dynamic task mapping（一个 Task 可以产出 N 个后续 Task），但仍然局限于"产出静态后续 Task 列表"，不支持"根据 LLM 输出实时改变图结构"。

困境 2：跨任务通信弱。Airflow 的 XCom 是任务间通信机制，但默认限制 48KB、JSON 序列化、不支持流式更新。Agent 的中间状态（长上下文、记忆、工具调用历史）经常远超 48KB。

困境 3：重试与补偿的工程债务。Airflow 的 retries 参数是任务级的，但工作流级的补偿 saga 需要写复杂的 BranchPythonOperator 与 trigger_rule 组合，远不如 Temporal 的 workflow code 直观。

适配 Agent 的工程真相：

真相 1：Astronomer / Dagster / Prefect 在 2026 年明显分流了 Airflow 的部分生态。Airflow 2.x 的 TaskFlow API 让 Python 函数成为 task，让 @task 装饰器写出 ETL 流水线更简洁；但对 Agent 场景仍不是最优解。

真相 2：Airflow 的真正 Agent 价值在"调度编排层"而不是"执行引擎层"。一个常见架构是把 Airflow 当 cron-like 调度器（每日/每小时跑一次 Agent 任务），把每次跑的具体 Agent 执行交给 LangGraph 或 Temporal。Airflow 提供调度、告警、SLA 监控，Agent 框架提供执行、状态、重试。这是一种"分层解耦"的工程妥协。

真相 3：Airflow 3.x 的 Task SDK 与 Event-driven scheduling 正在缩小差距。2026 年的 Airflow 3.x 引入了 external task sensor、event-driven trigger、Dataset-based scheduling，让 Agent 任务可以被其他工作流的产出"事件触发"。但这仍不是 Temporal 那种"持久化状态机重放"的能力，是另一种工程折中。

五、Prefect/Dagster 派：资产中心与动态图重写

Prefect（2026-07-29 星标 23.5k）与 Dagster（2026-07-29 星标 15.9k）是 Airflow 的两个最强挑战者，它们的核心创新是把"DAG"概念升级为"资产（Asset）"——把工作流的节点从"任务"重新定义为"有版本、有 schema、有 lineage 的数据资产"。

Prefect 的 @flow 与 @task 与 Airflow 的 TaskFlow API 看起来很像，但底层工程哲学截然不同。Prefect 的工作流是 Python-native 的——一个 @flow 装饰的函数调用几个 @task 装饰的函数，Prefect 在执行时把它们记录为一次 Flow Run，每个 @task 调用记录为 Task Run，所有元数据持久化到 Prefect Cloud 或自部署的 Prefect Server。Prefect 3.x 引入了 work pool、worker、concurrency limit 等生产级调度原语，但仍保留"Python 函数一等公民"的设计。

Prefect 与 Agent 场景的契合度在于：Agent 的每一步（LLM 调用、工具调用、状态更新）天然是一个 Python 函数调用；Prefect 的 @task 装饰器给它加上 retry、timeout、log、observability，不改变代码结构。这让 Agent 工程师可以把现有 Python 代码几乎无改造地接入 Prefect，获得调度、监控、重试能力。

Dagster 的资产中心（Asset-Centric）模型 是更激进的范式：Dagster 的核心抽象不是"任务"，而是"资产"——一个 Asset = 一份有 schema 的数据 + 一份生成它的函数 + 一份 lineage（它依赖哪些其他资产）。当 Agent 产生中间数据（embedding 向量、记忆条目、对话历史）时，这些中间数据天然是 Asset，Dagster 自动追踪它们的 lineage、版本、schema 演化。

Dagster 与 Agent 场景的真实契合点：

契合 1：记忆系统天然是 Asset 图。一个 Agent 的记忆 = conversations Asset + embeddings Asset + retrieval_results Asset，三者有依赖关系，Dagster 自动追踪每次 retrieval 用了哪些 conversations 与 embeddings 版本。

契合 2：Lineage 是 Agent 调试的金标准。当 Agent 输出错时，工程师能立即看到"这次输出用了哪份记忆、哪份工具 schema、哪个 LLM 版本"——这就是 Dagster 的 lineage 视图。

契合 3：SDA（Software-Defined Assets）的声明式优势。Agent 工程师声明"我想要 embeddings 这个 Asset，它依赖 conversations，用 model X 生成"，Dagster 自动决定何时重跑、如何并行、如何缓存。

两者的工程真相：

真相 1：Prefect 与 Dagster 都是相对"年轻"的工作流引擎（10 年以内），生态成熟度、运维文档、生产案例仍少于 Airflow 与 Temporal。Agent 团队选型时需要评估团队的运维能力与故障容忍度。

真相 2：Prefect 的 flow run 在崩溃后不会自动重放——它的 retry 是 task 级的，不是 workflow 级的。要做到 workflow 级重放必须自己实现 checkpoint 机制。这是它与 Temporal 的核心差距。

真相 3：Dagster 的资产中心模型对 Agent 的 RAG / 记忆 / 训练数据流水线是杀手锏，但对"长、异步、可恢复的 Agent 决策流"仍是次优解——它仍然是 ETL 取向的工作流引擎，决策流的抽象仍是 task + dependency，不是 state machine。

六、Ray/KubeRay 派：分布式 actor 与无中心任务图

Ray（2026-07-29 星标 43.3k）与 KubeRay（2.6k）是与上述所有工作流引擎"工程哲学完全相反"的流派——它们不提供持久化工作流抽象，而是提供"分布式 actor + 任务图调度"的底层原语。

Ray 的核心抽象是 @ray.remote 装饰的 Python 函数或类，它们被注册为 Ray Cluster 上的 actor 或 task，可以被任意 actor / driver 调用。Ray Cluster 由 head node + worker nodes 组成，所有 actor 注册到全局控制平面（GCS），任务调度由 Ray scheduler 完成。Ray 的 task graph 是动态的、无中心的——任何 actor 可以异步 submit 任意 task，无需预先定义 DAG。

Ray 与 Agent 场景的契合度从两个维度评估：

维度 1：分布式 actor 模型。一个 Agent 系统可以分解为 LLM actor（持有 LLM client 连接）、tool actor（持有 tool 调用权限）、memory actor（持有向量数据库连接）、orchestrator actor（持有状态机逻辑）。这些 actor 各自部署在不同 worker 上，通过 Ray 的 RPC 通信。这种模型对短任务、高并发的 Agent 工作负载（如批量处理 10000 条 prompt）效率极高。

维度 2：动态任务图。Ray 的 task 可以产生新的 task，task 之间通过 ray.wait / ray.get 形成动态依赖图。这种灵活性远超 Airflow 的静态 DAG，对"Agent 决策流每一步都可能产生新分支"的场景非常合适。

Ray 的工程真相：

真相 1：Ray 的持久化模型完全由用户承担。与 Temporal 的"自动持久化"相反，Ray 的 actor 状态默认在内存中，actor 崩溃后状态丢失。要做到持久化必须用 Ray 的 external storage + 自定义 checkpoint，或用 Ray Serve 的 deployment model。Agent 团队选 Ray 必须接受"工程债务自己扛"。

真相 2：KubeRay 是 Ray on Kubernetes 的工业级实现。KubeRay operator 把 RayCluster 作为 K8s CRD 管理，提供 autoscaling、observability、multi-namespace 隔离。生产 Agent 平台选 Ray 通常意味着选 KubeRay，单纯裸 Ray 几乎只在 dev/test 出现。

真相 3：Anyscale（Ray 商业化母公司）的 Scale-on-Demand 模型与 Agent 的 bursty 负载高度契合。Agent 流量经常出现"白天低谷、晚间高峰"或"业务上线时突发 10x"，KubeRay 的 autoscaler 可以把 worker node 从 5 扩到 50 再缩回 5，按秒级计费。

真相 4：Ray 与 LangGraph 的工程协同在 2026 年开始成型。LangGraph 的 StateGraph 可以跑在 Ray actor 上，每个 StateGraph 节点对应一个 Ray actor，借助 Ray 的分布式能力横向扩展。这是一种"上 LangGraph 抽象 + 下 Ray 调度"的混合架构。

七、对工程实践的推论：六件套选型决策框架

基于上述四派的工程真相，给 Agent 平台架构师一个六件套选型决策框架——每一条都是可执行的检查项，不是抽象原则：

决策项 1：任务时长维度。< 1 分钟的纯同步任务不需要工作流引擎，写 async 函数即可。1 分钟到 10 分钟的中等任务可以考虑 Prefect/Dagster 的 @task 装饰器（轻量级持久化）。10 分钟以上、跨进程、跨服务的任务必须用 Temporal 这类持久化工作流引擎（自动重放）。数小时甚至跨天的 Agent 任务（如批量报告生成、定时数据同步）Temporal + Continue-As-New 是当前工程最优解。

决策项 2：步骤可变性维度。完全静态的执行图（步骤确定、依赖确定）Airflow 3.x 仍可胜任，ETL 优先选 Airflow。半静态图（步骤基本确定但偶尔动态分支）Prefect 的 dynamic task mapping 或 Dagster 的 dynamic asset 都能处理。完全动态图（每步决策都可能改变后续图结构）必须用 Temporal（workflow code 写状态机）或 LangGraph + Ray actor。

决策项 3：状态持久化维度。无状态任务（每次重跑结果一致）任何引擎都可胜任。有状态任务（必须保留中间状态）需要 Temporal 的 Event History 或 Dagster 的 Asset lineage。强一致性 + 跨 DC 复制：Cadence。

决策项 4：调度粒度维度。cron-like 的周期性调度（每天/每小时触发）Airflow / Prefect / Dagster 都擅长。事件驱动调度（其他工作流产出触发）Prefect 的 event listener / Dagster 的 sensor / Temporal 的 Signal 都能做。LLM 驱动的实时决策触发（"等用户回复"等异步信号）：Temporal 的 Signal + Query 模型。

决策项 5：执行环境维度。纯云端（AWS / GCP / Azure）执行：所有引擎都支持。需要 on-premise / 边缘 / air-gapped 部署：Temporal OSS / Cadence / KubeRay。需要跨云（多云联邦）：Cadence / KubeRay。需要 GPU 池化与共享：KubeRay 优先（与 K8s device plugin 集成最深）。

决策项 6：观测与调试维度。需要完整 Event History 重放 + 任意时刻状态查询：Temporal。需要 asset lineage + schema evolution 追踪：Dagster。需要分布式 trace + actor call graph：Ray Dashboard + OpenTelemetry 集成。需要 SLA 告警 + 调度可视化：Airflow + Astronomer。

六件套组合的常见工程范式：

范式 A：分层解耦。Airflow 调度 → Temporal 执行 → LangGraph 决策。Airflow 提供周期性触发，SLA 监控，告警；Temporal 提供持久化、重放、exactly-once；LangGraph 提供状态机抽象。这是企业级生产平台最常见的架构。

范式 B：全 Temporal。从调度到执行到决策全在 Temporal 里。Workflow code 调 LLM Activity、Tool Activity、HTTP Activity。优点是简单一致，缺点是 Temporal 学习曲线陡。

范式 C：Ray-native。Ray actor 实现所有组件，LangGraph 提供决策抽象。优点是横向扩展性极强，缺点是持久化工程债务大。

范式 D：Dagster 资产中心。Agent 的所有数据（对话、记忆、embedding、决策日志）都是 Dagster Asset，决策流用 Dagster ops / jobs 表达。优点是 lineage 与 schema 演化可追踪，缺点是对长工作流的自动重放支持弱。

八、讨论：任务图粒度、长工作流的工程债务、LLM 步进的非确定性

工程真相 5：任务图粒度的反直觉权衡。把 Agent 任务图拆得越细（每一步 LLM 调用、每一步工具调用都是一个独立 Activity），观测性越强、故障隔离越好，但 Event History 越大、调度 overhead 越高。生产经验值是"按业务边界拆"——一次完整的"用户问—Agent 检索—Agent 决策—Agent 工具调用—Agent 回复"作为一个 Activity，太粗丢失观测，太细 Event History 爆炸。

工程真相 6：长工作流的工程债务不是技术问题而是认知问题。一个跑 24 小时的 Agent 工作流即使技术上能 Continue-As-New 截断、即使 Event History 有 50MB 缓冲，工程师面对它时仍然面临"为什么这次跑这么久？"的认知负担。生产经验是给长工作流显式定义里程碑（milestone）——每 100 步或每 30 分钟落一次里程碑日志，工程师看里程碑而不是看 Event History。

工程真相 7：LLM 步进的非确定性是工作流引擎的未解难题。Temporal 的契约要求 workflow code 是确定性的，但 LLM 调用本身是非确定性的（同一 prompt 可能产出不同输出）。把 LLM 调用包成 Activity 后，Activity 重试可能产出不同结果，整个工作流的行为就不可预测。2026 年的工程妥协是：(1) 给 LLM 调用设 temperature=0（但不保证完全确定性）；(2) 给 LLM Activity 设 idempotency key（用 prompt hash + model version + temperature），重试时跳过；(3) 在 workflow 层加"LLM 输出稳定性"校验，连续两次输出差异过大时触发人工审批。

工程真相 8：工作流引擎与 Agent 框架的工程债务分摊。Temporal + LangGraph 这种组合看似清晰，但实际操作中 workflow code 与 LangGraph StateGraph 之间存在阻抗失配——Temporal 的 deterministic code 不喜欢 LangGraph 的 dynamic reducer；LangGraph 的 checkpoint 不喜欢 Temporal 的 Activity 边界。生产团队需要写一层适配层（adapter），把 LangGraph node 包装成 Temporal Activity、把 LangGraph checkpoint 映射到 Temporal Event History。这层适配层是工程债务的常驻来源。

工程真相 9：工作流引擎的故障域分析被严重低估。一个看似"分布式"的工作流引擎其实是"中心化状态机 + 分布式 worker"的混合架构——状态机持久化到数据库（故障域 = 数据库 HA），worker 是无状态的（故障域 = K8s pod 重启）。生产 Agent 平台必须明确：(1) 工作流状态机的 RTO / RPO（典型目标 RTO < 5 分钟，RPO < 1 分钟）；(2) 数据库的 HA 拓扑（同城双活 + 异地灾备）；(3) worker 池的弹性伸缩（min replicas vs max replicas）；(4) Activity 的幂等键设计（防止重试导致业务侧副作用）。

九、给 SRE 与 Agent 平台架构师的部署清单

把上面所有工程真相压缩成一份可直接打勾的部署清单：

基础设施层：

• 工作流引擎的数据库独立部署，与业务数据库分离。Temporal 用 PostgreSQL 13+，Cadence 用 Cassandra 4+ 或 PostgreSQL，Prefect 用 PostgreSQL，Dagster 用 PostgreSQL。不要和工作流引擎共用数据库。
• 数据库开启 PITR（Point-in-Time Recovery），保留至少 7 天 binlog。
• 工作流引擎的 control plane 与 data plane 分离（Temporal 的 frontend / history service / matching service / worker 是 4 个独立进程）。每个组件独立扩缩容。
• K8s 部署时给 worker pod 设 priorityClassName: high，避免被低优先级负载挤占导致 Activity 调度延迟。

工作流设计层：

• 每个 Activity 必须显式声明 startToCloseTimeout（单次执行超时）与 scheduleToCloseTimeout（含排队总超时）。经验值：LLM Activity 的 startToCloseTimeout 60-120 秒，HTTP Activity 30 秒，DB Activity 10 秒。
• 每个 Activity 必须实现 idempotency。幂等键 = (workflow_id, activity_id, attempt_number) 或业务侧唯一 ID。
• 每个长工作流必须显式实现 Continue-As-New 或 checkpoint。经验值：Event History 超过 10MB 主动 Continue-As-New。
• workflow code 中禁止直接调用 datetime.now() / random.random() / uuid.uuid4() / 任何 IO。统一用引擎提供的 workflow.now() / workflow.random() / workflow.uuid4()。

可观测性层：

• 工作流 trace 走 OpenTelemetry，Activity span 包含输入/输出 hash、模型版本、token 数。
• Event History 导出到数据仓库（Snowflake / BigQuery），用于离线分析。
• Activity Heartbeat 写入 Prometheus / Grafana，关键告警：heartbeat lost > 2x heartbeat interval → page oncall。
• 工作流 SLO 定义：p50 / p95 / p99 完成时间、失败率、retry 次数、Continue-As-New 频率。

运营层：

• 工作流版本管理用 Temporal 的 Workflow Versioning 或 LangGraph 的 thread versioning。不要通过修改 workflow code 强制"版本升级"——必须 explicit migration。
• 给工作流设置 max in-flight 限制，避免一个租户的 burst 流量拖垮全局。
• 工作流引擎的版本升级走 canary：10% → 50% → 100%，每步观察 24 小时。
• 季度 DR 演练：故意 kill 一个 worker pod、kill 数据库主节点、模拟网络分区，验证恢复路径。

给 Agent 平台架构师的 1 行黄金法则：工作流引擎不是 Agent 的"必需组件"，但任何严肃的、跨进程、跨时间、跨故障的 Agent 系统迟早会需要一个。选 Temporal 当你不确定时——它的契约最严格、生态最成熟、工程真相最透明；用 Airflow 当你的 Agent 任务是周期性的、可观测优先的；用 Prefect / Dagster 当你的 Agent 数据资产复杂、需要 lineage；用 Ray + KubeRay 当你的 Agent 负载是 bursty 的、需要 GPU 池化与按秒级横向扩展。

参考文献

1. Temporal Technologies, "Temporal: A Durable Execution Engine for Stateful Applications", 2024. https://temporal.io/blog/temporal-explained
2. Samarasa, Cadence: "The Workflow Orchestrator for Microservices at Scale", Uber Engineering Blog, 2021.
3. Apache Airflow Documentation, "TaskFlow API & Dynamic Task Mapping", 2026. https://airflow.apache.org/docs/
4. PrefectHQ, "Prefect 3.x: Orchestration for the Modern Data Stack", 2026. https://docs.prefect.io/
5. Dagster Labs, "Software-Defined Assets: The Future of Data Engineering", 2026. https://docs.dagster.io/
6. Moritz et al., "Ray: A Distributed Framework for Emerging AI Applications", OSDI 2018.
7. Anyscale, "KubeRay: Productionizing Ray on Kubernetes", 2026. https://docs.ray.io/en/latest/cluster/kubernetes/index.html
8. LangGraph Documentation, "StateGraph & Distributed Execution", 2026. https://langchain-ai.github.io/langgraph/
9. OpenTelemetry SIG, "Semantic Conventions for Workflow Engines", 2025. https://opentelemetry.io/docs/specs/semconv/workflow/
10. AWS Step Functions Documentation, "Durable Functions & Express Workflows", 2026. https://docs.aws.amazon.com/step-functions/
11. Cadence Workflow: Cross-Datacenter Replication, Uber Engineering, 2022.
12. Dask Documentation, "Task Graph Scheduling & Actor Model", 2026. https://docs.dask.org/en/stable/
13. Google Cloud Workflows Documentation, "Durable Execution for Serverless", 2026. https://cloud.google.com/workflows/docs
14. Microsoft Durable Task Framework, "Building Stateful Services in Azure", 2026. https://github.com/Azure/durabletask