Workflow-Orchestration 与 Durable Execution

当面试官开始问 Workflow、Orchestration、Durable Execution，说明他已经不满足于你只会做一个会调工具的聊天机器人了。他想看的是：你是否能把一个 Agent 任务做成一个能跨步骤、跨时间、跨中断、可恢复、可审批、可观测的生产流程。

这道题通常会围绕下面几个问题展开：

1. Workflow 和 Agent 是什么关系？是替代还是组合？
2. 为什么复杂 Agent 任务不能只靠一个 while-loop + function call？
3. 什么叫 durable execution？它和失败后重试一下有什么本质区别？
4. LangGraph 这种图式工作流和 Temporal 这种 durable workflow 系统各自解决什么问题？
5. 什么场景用图编排就够，什么场景必须上真正的 durable workflow 引擎？
6. 如果系统崩了、worker 挂了、用户半路审批、任务跑了三天，你的流程还能不能接着走？

所以，这一题本质上考察的是Agent 从交互程序走向业务流程系统时，你有没有系统工程视角。

在面试时你可以这么一句话表达：

:::color1
Workflow Orchestration 解决的是多步骤任务如何按状态、依赖和策略被有序推进；Durable Execution 解决的是这些推进过程如何在失败、重启、中断和长时间等待后仍然可以可靠继续，而不是从头再来。前者强调流程控制，后者强调执行可靠性。真正生产可用的 Agent 往往两者都需要。

:::

为什么 Agent 系统会自然走向工作流编排

一个单次问答 Agent 可以靠大提示词 + 一轮模型调用 + 几个工具完成，但只要任务复杂度上来，系统就会出现以下特征：

• 需要多步推理与多步执行；
• 步骤之间有显式依赖；
• 某些步骤要等外部结果；
• 某些步骤要等待人工审批；
• 某些步骤失败可重试，某些失败必须停止；
• 某些任务可能持续几分钟、几小时、几天；
• 某些步骤有副作用，不能重复执行。

这时如果你还用一个纯粹循环调用模型直到结束的框架，就会出现：

• 状态难追踪；
• 中断难恢复；
• 审批难插入；
• 错误处理散落在各处；
• 日志难回放；
• 执行边界不清晰。

这就是 Workflow Orchestration 需要登场的原因。

一图看懂：为什么 Workflow 和 Durable Execution 是两层问题

这张图里的关键是：
编排器决定下一步是什么，状态存储保证下一步还能继续。
很多人只讲前者，不讲后者，就停留在流程图层面，而不是运行时层面。

Workflow、Agent、Orchestrator 三者关系怎么讲

1. Agent 是能根据上下文决定行动的执行体

Agent 具有一定自治性，可能会：

• 选择工具；
• 决定下一步；
• 进行推理；
• 在模糊问题上做探索。

2. Workflow 是步骤关系和状态转移的框架

Workflow 更强调：

• 步骤有哪些；
• 依赖关系是什么；
• 什么条件下从 A 到 B；
• 什么条件下进入审批或结束；
• 哪些步骤能并行；
• 哪些步骤失败后怎么处理。

3. Orchestrator 是把流程推进下去的控制层

Orchestrator 的职责包括：

• 读取当前状态；
• 决定执行哪个节点；
• 调用节点；
• 持久化结果；
• 处理重试与超时；
• 接入人工中断；
• 记录 trace。

所以，Agent 和 Workflow 不是非此即彼的关系。
一个非常成熟的回答是：

Agent 适合解决步骤内部的不确定性，Workflow 适合解决步骤之间的确定性。Orchestrator 把这两者组织起来。

这句话在面试里非常好用。

Workflow vs Agent：什么时候该让模型自己决定，什么时候该由流程提前写死

这是最经典的追问之一。

更适合 Workflow 的场景

• 流程有明确业务规则；
• 步骤顺序相对固定；
• 合规要求强；
• 需要可解释、可审计；
• 需要审批和回滚；
• 失败处理要非常稳定；
• 任务结果比探索空间更重要。

例如：

• 报销审批；
• 工单分派；
• 数据同步；
• 测试发布流程；
• 采购申请流程。

更适合 Agent 的场景

• 问题空间开放；
• 需要探索和试错；
• 工具选择不固定；
• 用户需求模糊；
• 更强调推理与规划能力。

例如：

• 开放式调研；
• 代码修复探索；
• 复杂问答；
• 任务分解与方案生成。

最常见的生产组合方式

最实际的答案不是二选一，而是：

• 用 Workflow 决定阶段；
• 在某些节点里调用 Agent 做局部自治推理；
• Agent 产出的结论再回到 Workflow 中继续执行。

例如：
合同审查流程里，整体阶段是固定的：上传 → 解析 → 初审 → 风险项汇总 → 人审 → 出具意见；但风险项提取这一步可以交给 Agent。

什么是 Durable Execution

这道题必须答得明确。
Durable Execution 不是失败了自动重试那么简单，它的核心在于：

系统能够在执行过程中把状态和进度以可恢复的方式保存下来，因此即使进程崩溃、机器重启、任务等待很久、人工中断后再继续，也不需要从头重新执行已经完成的步骤。

这里有两个关键词：

1. 已完成工作不会白做

假设一个 20 步任务跑到第 17 步，worker 挂了。
如果没有 durable execution，你可能只能：

• 从头跑；
• 或者靠人工判断从哪接。

如果有 durable execution，系统应该知道：

• 前 16 步已经成功；
• 当前卡在第 17 步；
• 第 17 步是否产生副作用；
• 是否需要重放还是继续；
• 下次恢复时从哪里接。

2. 状态恢复是系统级能力，不是业务代码临时补丁

很多同学会说：我们把中间结果存数据库，出错再读回来。
这当然是思路的一部分，但 durable execution 更强调运行时级别的恢复语义，而不是每个业务节点各自随手存点东西。

换句话说，Durable Execution 是把恢复能力提升为平台能力。

LangGraph：图式编排与持久执行

LangGraph 很适合用来解释Workflow 和 Agent 的结合。

它的核心抽象是什么

可以浓缩成三个词：

• State：共享状态；
• Node：执行节点；
• Edge：状态转移与流程连接。

这种模型很适合 Agent 场景，因为：

• 可以把规划、检索、工具调用、审批、结束等都做成节点；
• 可以在节点之间显式表达条件和分支；
• 可以让部分节点由 LLM 自治决定；
• 可以持久化每一步的 checkpoint。

Persistence / Checkpoint 的价值

图工作流如果没有 checkpoint，很快就会出现两个问题：

• 失败后只能重跑；
• 人工中断后无法继续。

有了 checkpoint，每一步执行完都能把状态快照存下来。这样可以支持：

• fault tolerance；
• human-in-the-loop；
• time travel / replay 调试；
• 多轮任务延续；
• 会话线程级状态管理。

这是 LangGraph 与只有一个 agent loop的根本区别之一。

LangGraph 更适合什么

• 需要把 Agent 拆成显式节点；
• 希望保留一定自治能力；
• 想快速搭建可中断、可恢复、可调试的图式流程；
• 任务主要围绕 LLM 推理、工具调用和状态转移；
• 对工作流历史和调试可视化有需求。

一句话记忆：
LangGraph 更像为 Agent 设计的状态图运行时。

Temporal：Durable Workflow 的经典代表

Temporal 很适合解释 durable execution 的工程本质。

Workflow Execution 是什么

Temporal 把 workflow execution 当成主执行单元。
它可以持续很久，可以有本地状态，可以接收 signals，可以调用 activities，可以在 worker 崩溃后通过事件历史恢复。

这里最重要的认知是：

• Workflow 不是普通进程；
• 它的进度由事件历史和运行时语义保护；
• Worker 掉了可以换另一个继续，不需要人工找回状态。

Activities 是什么

Activities 通常表示真正去做外部副作用或 IO 的工作，例如：

• 调支付接口；
• 查数据库；
• 发消息；
• 调第三方服务；
• 写文件；
• 调 shell 或远端执行器。

为什么 Temporal 强调 Activity 幂等？
因为 Activity 可能被重试。
只要有重试，就有重复执行风险；只要有重复执行风险，副作用就必须设计幂等。

Signals、Queries、Updates 为什么重要

复杂流程里，Workflow 往往不是启动后静静跑到结束，而是会在中途被外部交互影响，例如：

• 用户补充资料；
• 管理员审批通过；
• 运营强制取消；
• 前端查询当前状态；
• 外部事件到达后继续。

这些能力使得 Workflow 更像一个长期存活、可交互的业务流程实体。

LangGraph 和 Temporal 怎么选

这是非常高频的系统设计题。推荐你按下面思路回答：

更偏 LangGraph 的情况

• 你关心的是 Agent 节点编排；
• 核心步骤大多是 LLM 推理、工具调用和对话状态推进；
• 你想快速构建图式 Agent；
• 需要 checkpoint、HITL、状态图调试；
• 工作流生命周期相对中等，不一定跨很多天。

更偏 Temporal 的情况

• 你有很强的业务流程可靠性诉求；
• 任务可能持续很久；
• 需要强恢复语义；
• 需要严肃处理重试、超时、定时器、补偿、事件驱动；
• 需要把 workflow 当成生产级业务实体管理。

实际工程里非常常见的组合方式

外层用 Temporal 这种 durable workflow 管理业务流程阶段、重试、等待和补偿；
内层某些智能步骤用 LangGraph 或自定义 agent runtime 跑推理图。

例如：

• 外层工作流：接单 → 数据准备 → 调用代码修复 Agent → 等待人工 review → 发布；
• 内层 Agent：分析报错 → 检索仓库 → 生成补丁 → 运行测试 → 形成建议。

这样的分层往往比所有东西都交给一个 agent loop稳定得多。

Durable Execution 和普通重试有什么区别

很多候选人会把两者混。
你可以这样区分：

普通重试

重点是：
某个动作失败了，再试一遍。

它通常关注：

• 失败类型；
• 重试次数；
• 退避时间；
• 幂等保护。

Durable Execution

重点是：
整个流程即使被打断，也能从正确位置继续。

它关注：

• 已完成步骤的持久记录；
• 当前状态与转移点；
• 外部事件恢复；
• 多天任务等待；
• worker 崩溃后的恢复；
• 人工中断后的继续执行。

一句话记忆：
重试解决一个动作失败怎么办，Durable Execution 解决整个过程断了怎么办。

Agent 场景里最需要 Durable Execution 的地方

1. 长时间工具或后台任务

例如：

• 大规模代码库扫描；
• 多网页长链调研；
• 大文件解析；
• 报表生成；
• 批量自动化操作。

2. 需要人工审批的步骤

例如：

• 删除数据；
• 发外部通知；
• 合同提交；
• 批量执行脚本；
• 进入生产环境。

这类流程会被人为暂停，没有 durable execution 就很容易丢状态。

3. 多 Agent 协作链

一个 Agent 把子任务委托给另一个 Agent，再等待返回。
如果调用关系拉长，没有可靠状态记录和恢复机制，系统很容易变成只在 demo 里能跑通。

4. 带副作用的多步流程

例如：

• 创建工单；
• 更新数据库；
• 发邮件；
• 再同步第三方系统。

中间任一步失败，都需要知道前面做到了哪里，以及后面是重试、补偿还是人工接管。

工作流状态设计：校招生最容易忽略什么

1. 终止条件

流程什么时候结束？
是模型说我觉得结束了就结束，还是必须满足：

• 某个 artifact 已生成；
• 某个审批已通过；
• 某个状态已写回；
• 某个验收条件已满足？

没有显式终止条件，Agent 很容易在工具循环里打转。

2. 中断点

流程在哪些位置允许暂停？

• 等用户；
• 等审批；
• 等外部事件；
• 等定时器；
• 等远端 Agent 返回。

这些位置最好在设计时就是一等状态，而不是临时 if-else。

3. 幂等边界

哪些节点可以重复执行？
哪些节点一旦重试就要特殊保护？
比如生成摘要可以重复，发送通知就必须小心。

4. 错误分级

并不是所有错误都应导致整个 workflow fail。
你应该区分：

• 可重试错误；
• 不可重试错误；
• 需要人工介入的错误；
• 可降级继续的错误。

5. 观测与回放

没有 trace、checkpoint 和事件历史，出问题时你根本不知道：

• 是模型推理错；
• 工具挂了；
• 状态没存；
• 分支条件写错；
• 还是审批没回来。

常见误区

误区 1：Workflow 就是写一串 if-else

太浅。
真正的编排系统要考虑状态转移、并行、超时、中断、恢复和可观测。

误区 2：Durable Execution 就是把结果存数据库

不够。
存数据库是手段之一，Durable Execution 更强调运行时语义：怎么 checkpoint、怎么 replay、怎么恢复、怎么等待事件、怎么保证步骤边界清晰。

误区 3：Agent 越自主越好，不需要 Workflow

错误。
很多业务场景恰恰需要 Workflow 来限制 Agent 的自由度，使过程可审计、可解释、可治理。

误区 4：上了 Workflow 就不需要 Agent

也不对。
Workflow 适合管理确定性流程，Agent 适合处理不确定性探索。很多系统最优解是二者组合。

误区 5：只要能恢复，就不需要幂等

错误。
恢复不等于重复执行安全。只要某步可能被重放或重试，副作用节点仍然必须设计幂等。

高频面试题与回答模板

1. Workflow 和 Agent 是什么关系？

标准回答：Workflow 管步骤之间的确定性与状态转移，Agent 管步骤内部的不确定性与推理。生产系统里通常是 Workflow 包裹 Agent，而不是二选一。

2. 什么是 Durable Execution？

标准回答：它让流程在崩溃、重启、长时间等待或人工中断后，仍能从已知正确状态继续，而不是从头执行。重点是持久化进度和恢复语义，不只是失败重试。

3. LangGraph 和 Temporal 的区别是什么？

标准回答：LangGraph 更偏 Agent 状态图和节点编排，适合 LLM / tool / HITL 场景；Temporal 更偏生产级 durable workflow，适合长生命周期、强恢复语义、复杂重试和补偿控制。很多系统会组合使用。

4. 为什么复杂 Agent 任务不能只靠 agent loop？

标准回答：因为一旦任务跨多步、有审批、有长等待、有副作用和失败恢复需求，单纯 loop 很难显式管理状态、中断、重试和回放，系统会非常脆弱。

5. Durable Execution 和 Retry 的区别是什么？

标准回答：Retry 关注某个动作失败后再试一次，Durable Execution 关注整个过程断了以后还能否从正确位置继续。前者是局部容错，后者是流程级可靠性。

6. 什么时候一定要上真正的 workflow 引擎？

标准回答：当任务持续时间长、业务影响大、步骤多且带副作用、需要审批和恢复、需要严肃观测和补偿时，最好上专门的 workflow / durable execution 引擎，而不是靠临时脚本。

项目表达模板

我们的 Agent 不是一轮模型调用就结束，而是一个多阶段流程：任务解析、资料准备、模型推理、工具执行、人工确认和结果交付。早期我们用简单 agent loop，很快遇到状态难恢复、审批难插入、失败后容易重跑的问题。后来我们把系统改成工作流编排：每一步都是显式节点，节点之间通过共享状态流转；关键节点后做 checkpoint，长等待和审批用持久状态保存。对偏智能的步骤，我们在节点内部调用 Agent；对业务可靠性强的外层流程，则交给 durable workflow 运行时管理。这样即使 worker 挂掉，系统也能从已知步骤继续，而且全链路有 trace 和回放。

小结

把这篇压缩成四句话：

1. Workflow Orchestration 管流程推进，Durable Execution 管流程能否可靠继续；
2. Agent 适合步骤内部的不确定性，Workflow 适合步骤之间的确定性；
3. LangGraph 更像 Agent 状态图运行时，Temporal 更像生产级 durable workflow 系统；
4. 真正上线的 Agent 任务，一旦跨时间、跨步骤、跨审批、跨副作用，就离不开编排与持久恢复。

如果你能围绕这四句话讲清楚状态、checkpoint、replay、activity、审批和恢复，这一题在系统设计面里就会很扎实。