Multi-Agent 如何可靠运行：Checkpoint、重试与故障恢复

前面的文章已经解决了 Multi-Agent 中的控制问题：任务怎样拆分、Agent 之间传什么、下一步由谁执行，以及运行过程中如何管理 Context、State 和 Memory。

然而，流程设计正确，不代表任务一定能够执行完成。

一个任务可能运行几十分钟，调用几十次模型和外部工具。期间任何一次网络超时、API 限流、进程重启等，都可能让执行中断。

本文我们主要讨论：怎样让已经确定的流程可靠地执行下去，并在发生故障后继续完成。

这也是 Multi-Agent 从原型进入生产环境后须补上的一层防护机制：Execution Runtime，执行运行时。

我们首先区分两个容易混在一起的问题：流程控制与可靠执行。

假设一个研究任务需要三个 Agent：

01Planner
02   |
03   ├── Agent A：研究市场
04   ├── Agent B：研究竞品
05   └── Agent C：研究技术
06          |
07          ▼
08      Synthesizer

Planner 决定创建哪几个 Agent，以及完成之后进入哪个步骤，这属于控制流。

但真正运行时，还会遇到另一类问题：

01Agent A ✓
02Agent B ✓
03Agent C ───── X timeout

此时系统已经知道下一步应该做什么，问题在于 C 没有执行完成。

如果程序直接退出，再重新启动整个任务，那么 A、B 已经完成的搜索、模型调用和计算都会被重新执行。

对于几秒钟的流程，这可能还能接受。

对于运行十几分钟甚至更久的 Agent，这种方式则不能接受。

Anthropic 在其 Multi-Agent Research 系统的生产经验中提到，Agent 会长期运行并持续维护状态，错误也会随着执行步骤累积。因此，他们会结合 checkpoint、retry 等机制，让失败后的任务从现有进度继续，而不是每次从头开始。

所以流程控制与可靠执行的职责分别是：

01Control Plane
02决定：接下来做什么
03
04Execution Runtime
05保证：这件事最终能够执行完成

接下来要介绍的 Checkpoint、Retry、Idempotency，都围绕执行运行时（Execution Runtime），确保 Agent 可靠地执行完成。

实现故障恢复的第一步，是保存执行进度。

这种保存点通常称为 Checkpoint。

可以把一次长任务理解为下面这条时间线：

01t0        t1          t2          t3
02start   checkpoint  checkpoint   crash
03                        |
04                        └──────────→ resume

如果系统只在 t0 保存输入，那么 t3 崩溃以后，只能重新开始。

如果 t1、t2 都保存了执行状态，那么系统可以找到最近一次有效状态，从那里继续。

例如：

01Checkpoint #12
02
03task_id: research-001
04
05A:
06  status: completed
07  artifact: artifact-a.json
08
09B:
10  status: completed
11  artifact: artifact-b.json
12
13C:
14  status: running

恢复以后就不需要重新执行 A 和 B。

运行时只需要知道：

01A completed → 跳过
02B completed → 跳过
03C unfinished → 继续执行

这就是持久化执行（Durable Execution）的核心思想之一：执行过程中的关键状态不能只存在于当前进程内存中。

LangGraph 的 persistence 机制采用 checkpointer 保存 Graph State。执行过程中可以通过 thread_id 关联到同一条运行线程，之后继续读取已经保存的状态。它的 checkpoint 通常发生在 Graph 的节点边界，因此节点划分也会直接影响恢复粒度。

例如把任务设计成：

01search
02  ↓
03analyze
04  ↓
05write

如果 analyze 失败，通常只需要重新执行当前节点。

但如果把三项操作全部塞进一个节点：

01search + analyze + write

即使最后一步失败，也可能需要重新执行整个节点。

因此，节点粒度除了影响代码结构，也会影响故障恢复成本。

不过 checkpoint 也不能无限细。

每一个微小步骤都写一次数据库，会增加存储和协调开销。更实用的做法是优先保存那些：

• 成本较高的模型调用结果；
• 已经完成的子任务；
• 外部系统返回的重要 ID；
• 后续步骤无法轻易重新计算的数据；
• 人工确认后的决策。

Checkpoint 的目标不是记录所有变量，而是确保发生故障以后，已有成果不会轻易丢失。

有了 checkpoint，还需要处理另一类更常见的问题：临时性的失败。

例如：

01HTTP 429
02HTTP 502
03connection reset
04request timeout
05database connection unavailable

这些错误有一个共同特点：

稍后再执行一次，有可能成功。

因此系统通常会进行 Retry，也就是重试。

最简单的策略是：

01失败
02 ↓
03等待
04 ↓
05重试

但生产环境里的 Retry 通常还需要三个限制。

例如：

01max_attempts = 3

如果已经连续失败三次，就不要无限尝试。

否则一个下游服务故障，可能让几百个 Agent 不断发送请求，进一步放大故障。

Backoff 指每次失败后逐渐增加等待时间。

例如：

01第 1 次失败 → 等 1 秒
02第 2 次失败 → 等 2 秒
03第 3 次失败 → 等 4 秒

这就是常见的 Exponential Backoff，指数退避。

它可以避免大量失败任务同时立即重试。

系统还可以给整个任务设置重试预算。

例如：

01整个任务最多允许：
02
0320 次 Tool Retry
043 次 Agent Retry
0510 分钟恢复时间

这样能够防止一个异常任务无限消耗 token、API 配额和计算资源。

LangGraph 的官方示例也把错误分成不同类型：网络错误、限流等临时问题适合自动 Retry；需要用户补充信息的问题可以暂停；未知错误则应该暴露出来供调试。

因此，一个重要原则是：Retry 只适合有较大概率自行恢复的错误。

相反，类似参数本身错误：

01HTTP 400
02invalid schema
03unsupported tool
04permission denied

连续执行十次通常也不会改变结果，这一类错误不应使用 Retry 策略。

因此，可靠系统需要先判断失败类型，再决定是否重试。

Retry 看起来很简单，但执行时可能会隐含着问题。

假设 Agent C 的任务是：

01创建一个客服 Ticket

第一次调用外部系统：

01Agent C
02   |
03   ├── create_ticket()
04   |
05Ticket System
06   |
07Ticket #1001 创建成功
08   |
09   X response timeout

这里出现了一个不正常的状态。

Agent 看到的是：

01timeout

于是 Runtime 判断任务失败，并再次执行：

01create_ticket()

结果可能变成：

01Ticket #1001
02Ticket #1002

事实上第一次已经成功，只是响应没有成功返回。

因此：

能够 Retry，并不代表能够安全 Retry。

这里就要引入 Idempotency，幂等性。

幂等要求同一个逻辑操作执行多次，最终结果仍然与执行一次相同。

例如查询：

01GET /customer/123

重复执行多次结果都完全一样。

但下面这些操作多次执行可能存在幂等问题：

01创建订单
02发送邮件
03写数据库
04扣款
05提交工单
06发布内容

一旦自动 Retry，就必须考虑重复执行。

常见做法是给一次逻辑操作生成唯一的 operation_id：

01operation_id = "research-001-create-ticket-C"

第一次执行：

01create_ticket(
02    operation_id="research-001-create-ticket-C"
03)

第二次 Retry 仍然使用相同 ID。

外部系统如果发现这个 operation 已经成功处理，就直接返回第一次的结果：

01operation already completed
02ticket_id = 1001

这样可以避免重复创建。

如果目标系统本身不支持幂等键，还可以在自己的数据库中保存：

01operation_id
02status
03external_resource_id

然后在执行前进行去重检查。

对于无法做到严格幂等的操作，还可以使用 Compensation，补偿操作。

例如：

01创建资源
02   ↓
03后续失败
04   ↓
05删除刚才创建的资源

这种思路在分布式系统中非常常见。

因此真正可靠的 Retry 通常要和三件事一起设计：

01Retry
02+
03Idempotency
04+
05Compensation

Multi-Agent 系统还会遇到一个运行方式上的选择：同步还是异步。

假设三个 Agent 并行执行：

01A ───────── 15s
02B ───────────────── 30s
03C ───────────────────────── 60s

同步模式下，Coordinator 通常会等待：

01await A
02await B
03await C

只有全部完成之后才进入下一步。

这种方式的优势非常明显：

01状态简单
02结果容易聚合
03错误传播容易理解

因此很多系统最开始都会采用同步执行。

Anthropic 当前公开的 Multi-Agent Research 架构也提到，Lead Agent 会等待一批 Subagent 完成后再继续。这降低了协调复杂度，但一个执行很慢的 Subagent 也可能阻塞整个过程。

异步模式则允许结果独立到达：

01A finished
02   ↓
03立即处理 A
04
05B finished
06   ↓
07立即处理 B
08
09C 继续运行

甚至 Coordinator 可以在 A 返回以后，又创建新的 Agent D：

01A result
02   |
03   └── spawn D
04
05B result
06C running
07D running

吞吐量和并行能力会明显提高。

但 Runtime 也必须处理更多问题：

01哪个结果已经到达？
02哪个任务还在执行？
03某个 Agent 失败是否影响其他 Agent？
04结果到达顺序改变怎么办？
05Coordinator 什么时候可以继续？

这些都属于状态协调问题。

在实践中，原则上：任务规模较小时优先同步；当等待时间和并行度已经成为明显瓶颈，再引入异步执行。

异步可以提高性能，但它同时会增加恢复、状态一致性和错误传播的设计成本。

现在把前面的机制放进同一个例子。

一个任务同时启动三个 Agent：

01A ───────────── completed
02B ─────────────────── completed
03C ───────────── X timeout

A 和 B 已经产生 Artifact。

系统此时存在一个 checkpoint：

01Checkpoint #18
02
03A:
04  status: completed
05  artifact: artifact-a
06
07B:
08  status: completed
09  artifact: artifact-b
10
11C:
12  status: running

C 调用了外部 Ticket API：

01operation_id:
02job-123-agent-c-ticket

外部系统实际上已经创建：

01Ticket #8421

但响应返回过程中发生网络超时。

Runtime 捕获异常以后，首先判断：

01Timeout
02→ transient error
03→ 可以 Retry

随后读取 checkpoint：

01A completed → 不执行
02B completed → 不执行
03C failed    → retry

C 再次调用：

01create_ticket(
02    operation_id="job-123-agent-c-ticket"
03)

外部系统发现相同 operation 已经处理：

01return Ticket #8421

C 得到结果：

01C completed
02artifact-c saved

随后写入新的 checkpoint：

01A ✓
02B ✓
03C ✓

Coordinator 再进入后续汇总阶段。

整个过程可以表示为：

01Checkpoint
02   |
03   ├── A artifact ✓
04   ├── B artifact ✓
05   └── C pending
06          |
07        retry
08          |
09   idempotency check
10          |
11        resume
12          |
13      C artifact ✓
14          |
15     next stage

从这个例子可以看到，真正的故障恢复并不是简单地“失败以后再调用一次”。

它至少涉及：

01Checkpoint
02知道已经完成了什么
03
04Retry
05重新执行可恢复的失败
06
07Idempotency
08避免重复执行而产生错误结果。
09
10Resume
11从已有状态继续流程

缺少其中任何一个环节，都可能让恢复过程重新产生新的问题。

很多 Multi-Agent Demo 的重点放在 Agent 怎么调用、Prompt 怎么写、Supervisor 怎样决定下一步。

这些内容解决的是“系统如何思考和调度”。

进入真实业务以后，必须要解决另一类更基础的问题：

01任务跑到一半会不会丢？
02API 超时以后怎么办？
03已经完成的步骤会不会重新执行？
04重试会不会创建两张订单？
05系统升级会不会破坏正在运行的任务？

这些问题已属于典型的分布式系统工程范围。

Temporal 这类 durable workflow 系统的核心价值，也正是在进程崩溃、网络故障或基础设施中断以后，仍然能够利用持久化的执行历史恢复工作流。

而在 Agent Runtime 中，同样可以借鉴这些成熟思想。

最终，一个可靠的 Multi-Agent 执行层可以概括为：

01State 持久化
02      +
03Checkpoint
04      +
05Retry Policy
06      +
07Idempotency
08      +
09Timeout
10      +
11Observability

流程设计告诉系统下一步应该运行谁。

可靠执行则保证：在模型失败、工具超时、进程重启和系统升级都可能发生的环境里，已经确定的工作仍然能够继续向前推进，并最终得到一个可确认的结果。

这也是 Multi-Agent 从“能够运行”走向“能够长期运行”必须补上的工程基础。