durable execution 三方案取舍 — 宏观工作流 / 微观推理 / 事件溯源

日期: 2026-07-23 阶段: Phase 2 - AI-native 参考架构 标签: #durable-execution #temporal #layered-architecture

核心问题

Day 36-38 解决了崩溃续跑、HITL 暂停、time-travel 调试，背后都依赖一个「持久化执行底座」。今天回答上层的选型问题：这个底座该怎么搭？市面三条路线——Temporal（宏观工作流引擎）、LangGraph（微观推理循环）、事件溯源（自建 append-only 日志）——不是三选一的竞品，而是职责不同的分层。

具体三问：

1. 三方案各管什么、为什么不能互相替代？ 一个常见误判是「用 Temporal 就够了，不需要 LangGraph」或反之。要讲清楚两者解决的是不同问题。
2. 2026-04 业界收敛出的「分层共识」是什么？——Temporal 管宏观工作流、LangGraph 管微观推理循环，事件溯源是底层抽象。
3. 本项目 P2 该选哪条？ 给出明确选型理由，且诚实说明此阶段为何自建轻量层而非直接上 Temporal。

关键内容

A. 三方案的职责边界与不可替代性

① Temporal — 宏观工作流引擎（macro / 持久层）。你把工作流写成代码，Temporal 负责步骤间状态持久化、失败重试退避、超时、worker 崩溃恢复（anup.io, 2026-01-14）。它的核心机制是事件历史 + 确定性重放（Day 36/38），提供 at-least-once 执行、exactly-once 效果（靠幂等）、Saga 补偿、跨服务/跨天的长任务。代价是确定性约束——工作流函数必须确定，任何非确定（随机、now()、并发顺序）会导致重放时与事件历史不匹配、replay 失败（Day 38）。

② LangGraph — 微观推理循环（micro / 推理层）。它管的是单个 agent step 内部那段动态、循环、控制流不可预测的逻辑（agentmarketcap.ai, 2026-04-08）：条件分支、循环、工具选择、子图——即「agent 决定做什么」。LangGraph 1.0 自带 checkpointing，但它的持久化是为推理循环服务的，不是为跨服务长事务设计的。

③ 事件溯源 — 底层抽象（foundation）。Temporal 的事件历史、Restate 的 Journal、本项目 useTraceStore 的 RunTrace.steps[]，本质都是事件溯源：一个 append-only 日志，经确定性函数重放得到状态（resonatehq.io）。它是前两者共享的底层模型，也可以自建——这正是本项目 P1 已经做的（Day 36 论证 useTraceStore 即事件历史雏形）。

为什么不能互相替代？关键洞察（langchain.com 官方口径）：「Temporal executes your workflows. LangGraph builds your agents.」「LangGraph 决定做什么，Temporal 确保它真的被做成」。两者解决的是正交问题：

反直觉洞察①（「我用了 LangGraph 的 checkpoint，就不需要 Temporal 了」是常见误判——它们不在一个层）：LangGraph 的 checkpoint 解决「推理循环内部断点续跑」，但它不解决「这个工作流跨了 3 个微服务、要跑 6 小时、要 Saga 补偿、要企业级审计、要 worker 池水平扩展」。反过来「我用 Temporal 就够了、不需要 LangGraph」也错——Temporal 的确定性约束容不下LLM 推理那种动态非确定控制流，硬塞进去会反复触发非确定性重放错误（Day 38）。正解是分层：把不确定的 LLM 推理关在 LangGraph 里（作为一个 Temporal activity 的内部），让 Temporal 在外层只看到「这个 activity 成/败」这个确定结果。一旦工作流里出现真实副作用（扣款、提交 SAR、跨服务调用），你通常两个都需要。

B. 2026-04 分层共识：activity 里裹一个 StateGraph

业界 2026 收敛出的生产范式（agentmarketcap.ai 2026-04-08；anup.io 2026-01-14）：

"LangGraph is the inner agent logic layer, with each Temporal activity containing a complete LangGraph StateGraph... LangGraph decides what to do and Temporal ensures it actually gets done."

即每个 Temporal activity 内部裹一个完整的 LangGraph StateGraph。这个嵌套的妙处在于把非确定性「装进盒子」：

┌─ Temporal Workflow (宏观, 确定性, 持久, 可跑数天) ───────────────┐
│   activity_1: 取证据 ──► activity_2: AML 推理 ──► activity_3: 提交 SAR │
│                              │                                      │
│                    ┌─────────▼──────────────────────────┐          │
│                    │ LangGraph StateGraph (微观, 非确定)  │          │
│                    │  research ⇄ knowledge ⇄ portfolio   │          │
│                    │  (LLM 推理循环, 工具选择, 分支)        │          │
│                    └─────────┬──────────────────────────┘          │
│                              ▼                                      │
│                    activity 只向外暴露「成/败 + 结果」(确定)          │
└──────────────────────────────────────────────────────────────────┘
     外层 Temporal 看不到 LLM 抖动 → 确定性约束不被破坏
     内层 LangGraph 容纳 LLM 抖动 → 推理自由

这套范式 2026-03-23 随 Temporal × OpenAI Agents SDK GA 落地（temporal.io, 2026-03）：TemporalRunner 把每次 agent 调用包成 Temporal activity，agent 推理循环与工具调用作为离散 activity 在事件历史里持久化，每个外部交互失败自动重试。「应用在长任务快完成时崩了？重启，Temporal 让它从断点继续，省下算力和 token 成本」（temporal.io, 2026-03）。Codex 等已在用 Temporal 做持久编排。

三方案决策表（持久化粒度 / 运维成本 / 适用）：

C. 本项目 P2 选型：自建轻量事件溯源层，暂不上 Temporal

P2 的选型不是「哪个最强」，而是「当前阶段的约束下哪个 ROI 最高」。本项目约束：浏览器内运行的求职作品集 demo（/agent-lab、/aml-copilot），单用户、单进程、无跨服务、无真实资金副作用、无 7×24 SLA。

反直觉洞察②（在错误的阶段引入 Temporal 是负 ROI——重运维抵消了它的全部价值）：Temporal 的杀手锏（跨服务、跑数天、Saga、worker 池水平扩展、企业审计）在本项目一条都用不上，但它的成本（要部署运维一个 Temporal 服务集群、写代码受确定性约束、本地 demo 跑不起来）却全要付。把企业级持久化引擎塞进一个浏览器内 demo，等于「为了用不到的能力付全部运维税」——这是典型的过度工程。正确判断不是「Temporal 好不好」（它很好），而是「此刻的约束需不需要它」（不需要）。这与 Day 36 的诚实纪律一脉相承：不为炫技引入用不到的重型依赖，不谎称已接 Temporal。

本项目选型决策与演进路径：

关键设计纪律：自建层的接口对齐 Temporal/LangGraph 语义（事件历史、幂等键、checkpoint/resume），使得未来真要迁移时是「换实现」而非「重设计」——Day 36 的 idemKey(runId, stepId) 刻意对齐 Temporal 的 workflowRunId-activityId，Day 37 的 thread_id 对齐 LangGraph，正是为此预留迁移路径。

设计要点/决策表

对本项目的落地

• src/agent/durable/ 定位为「轻量事件溯源层」：明确文档化它是 Temporal 事件历史/LangGraph checkpoint 的自建简化版，承载 Day 36（崩溃恢复重放）、Day 37（interrupt/resume）、Day 38（time-travel）三能力。底层数据源即 src/agent/trace/useTraceStore.ts 的 RunTrace.steps[]（事件日志）+ Day 36 的 idempotency.ts（幂等键）+ Day 37 的 approvalQueue.ts（暂停态）。
• 接口对齐迁移路径：idemKey(runId, stepId)（Day 36）对齐 Temporal workflowRunId-activityId；thread_id/ApprovalTask.taskId（Day 37）对齐 LangGraph thread_id；getStateHistory/forkFrom（Day 38）对齐 LangGraph get_state_history/update_state。在 src/agent/durable/README 或类型注释里写明这些对齐，使未来迁 Temporal/LangGraph 时是替换实现。
• agent-lab 文档化分层认知：/agent-lab 的架构说明页加一段「为什么不用 Temporal」——把 C 节决策表展示出来，作为求职作品集的架构判断力证据（PM/架构师视角：知道何时不该用某技术，比堆技术名词更有说服力）。这本身是作品集的差异化卖点。
• orchestrator 嵌套范式预留：src/agent/orchestrator/orchestratorAgent.ts 的 Lead-Subagent 结构天然对应 B 节「activity 裹 StateGraph」——若未来迁 Temporal，整个 runOrchestrator 可作为一个 Temporal activity，内部 subagent 循环即 LangGraph 微观层。当前 budget.ts 的 step/cost/timeout 约束即 activity 级的轻量替代。
• 诚实标注：src/agent/durable/ 头注明确「本项目 P2 自建轻量事件溯源层，非 Temporal/LangGraph runtime；接口刻意对齐二者语义以备 P3+ 迁移；Temporal 迁移为设想，当前约束（单进程浏览器 demo）不需要」。不在作品集任何位置声称「基于 Temporal 构建」。

参考资料

1. anup.io — Temporal + LangGraph: A Two-Layer Architecture for Multi-Agent Coordination（2026-01-14）：Temporal=工作流引擎（持久化/重试/超时/worker 崩溃恢复）；activity 里裹完整 LangGraph StateGraph；两者解决不同问题、干净拼合
2. AgentMarketCap — LangGraph vs. Temporal for Long-Running Agent Workflows: The 2026 Decision Guide（2026-04-08）：LangGraph=微观推理循环（动态循环逻辑、控制流不可预测）；Temporal=多步执行持久（worker 重启/网络失败）；真实副作用进入时通常两者都需要
3. LangChain — Temporal executes your workflows. LangGraph builds your agents.（langchain.com/resources, 2026）：LangGraph 决定做什么、Temporal 确保做成
4. Temporal — Production-ready agents with the OpenAI Agents SDK + Temporal（temporal.io/blog, 2026-03）：2026-03-23 GA；TemporalRunner 包每次 agent 调用为 activity；推理循环+工具调用作离散 activity 持久化事件历史；崩溃后从断点续跑省 token
5. Resonate — Durable Execution: From where do deterministic constraints come?（journal.resonatehq.io）：事件历史/Journal=append-only 日志经确定性函数重放（事件溯源底层抽象）(持续)
6. 本项目 Day 36（幂等键 idemKey 对齐 Temporal）、Day 37（thread_id 对齐 LangGraph）、Day 38（time-travel 对齐 get_state_history）；src/agent/trace/useTraceStore.ts、src/agent/orchestrator/orchestratorAgent.ts、src/agent/orchestrator/budget.ts(2026-06)

SOTA 检查 (2026-06-11)

• 「Temporal 宏观 + LangGraph 微观」分层共识在 2026-04 稳固：agentmarketcap.ai（2026-04-08）、anup.io（2026-01-14）、langchain.com 官方口径一致；Temporal × OpenAI Agents SDK 2026-03-23 GA 把范式工程化落地。CLAUDE.md 记录的「分层共识（2026-04）：Temporal 管宏观工作流、LangGraph 管微观推理循环」与一手来源吻合，未过时。
• 三方案非竞品而是分层，是 2026 主流认知：未见「Temporal 取代 LangGraph」或反向的主张；反而工具链（OpenAI Agents SDK、Vercel AI SDK 6）都在做与 Temporal 的集成，印证分层而非替代。反直觉洞察①（checkpoint≠工作流持久）是 live 的设计误判点。
• 生态版图（2026-06 口径）：LangGraph 1.0（2025-10）、Temporal×OpenAI Agents SDK GA（2026-03）、Microsoft Agent Framework 1.0（2026-04，AutoGen+SK 统一后继、二者进维护模式）、Vercel AI SDK 6（2025-12，Agent 一等抽象、TS 主栈生产首选）。本项目 TS 栈，若未来要框架，Vercel AI SDK 6 + 自建 durable 层比引 Temporal（需独立服务）更贴合部署形态。
• 过时认知警示：(1) 不要把 LangGraph checkpoint 当 Temporal 工作流持久的替代——不在一个层；(2) 不要在不需要的阶段引 Temporal——运维税抵消价值（反直觉洞察②）；(3) AutoGen/Semantic Kernel 已进维护模式（2026-04 起），新项目不应基于它们起步，统一到 Microsoft Agent Framework。
• 待跟踪：本项目是否在 P3 引入持久化（Postgres）但仍不上 Temporal 的判断是否成立；Vercel AI SDK 6 的 Agent 抽象 + Temporal 集成（temporal.io 已有「Building durable agents with Temporal and AI SDK by Vercel」博客）成熟度，作为本项目 TS 栈未来 durable 选型候选；Temporal 2026-02-17 $300M/$5B 融资后生态扩张对自托管成本的影响。