本文由『云枢国际/TG @yunshuguoji-国际云服务器代理商 撰写』如需转载请注明！
假设一个常见现场：一个 Agent 任务计划运行 40 分钟，前 39 分钟完成了资料抓取、模型调用和草稿写入，第 40 分钟在调用外部接口时超时，进程退出。团队现在要回答一个问题：是从头再跑 40 分钟，还是从某个中间点接着跑？
真正决定答案的，不是“有没有检查点”，而是三件事：失败前已经发生了什么外部副作用、中间状态能不能可靠恢复、重跑成本是否真的无法接受。断点续跑不是简单地将失败请求再发一次，而是让任务从已确认的状态继续，并且不重复产生扣款、发消息、写库这类副作用。
先判定：重跑还是续跑，看四条线
在编写检查点代码之前，需先通过以下四个维度进行评估。只要有一条明显不过关，强行续跑通常比重跑更危险。
第一条：任务能不能幂等重放
幂等意味着同一个操作执行多次，最终业务结果一致。读操作、覆盖写、带唯一键的写入较易实现幂等；追加写、扣款、发通知等则需设计去重手段。如果重放会导致重复扣款，请先补齐幂等机制。
第二条：外部副作用是否已经发生
超时不等于失败。调用接口超时，钱可能已扣，消息可能已发出。判断顺序应是：先查询外部系统的实际状态，再决定是重试、续跑还是补偿。缺乏状态查询能力的步骤，不适合自动续跑。
第三条：中间状态能不能序列化
检查点应保存“恢复任务所需的最小状态”。数据库连接、线程锁、模型推理的中间张量等通常不能可靠序列化。能存的是：任务标识、输入引用、已完成步骤、幂等键及外部副作用回执。
第四条：单次重跑成本是否可接受
如果任务总时长短、失败频率低、重跑成本仅为几分钟计算资源，那么重跑往往比维护复杂的检查点机制更划算。
断点续跑的最小机制集
若判定结果偏向续跑，以下六项可视为最小机制集。
1. 状态快照：存“恢复所需的最小状态”
快照需回答：任务做到哪一步、下一步做什么、哪些副作用已确认。
- 建议保存： 任务 ID、输入参数引用、已完成步骤列表、幂等键、检查点版本号。
- 不要保存： 连接句柄、线程锁、明文凭据、大二进制内容。
- 间隔设定： 根据“可接受重做量”倒推，通常按步骤边界设置，不在步骤中间切分。
2. 任务队列与重投：让失败可被重新调度
队列解决任务接管问题。关键在于匹配“单步处理时长”与“可见性超时”。若处理时长超过超时范围，消息会重新出现导致重复消费。
3. 幂等键：防止重复副作用
幂等键是副作用操作的唯一标识。推荐由“任务 ID + 步骤 ID + 输入摘要”派生。写库应配合唯一约束，支付操作应先查单再重试。
4. 租约与心跳：防止并发冲突
长任务可能遇到执行者失联。通过租约机制与单调递增的 fencing token，可以防止旧执行者“复活”后覆盖新进度，确保同一时间只有一个执行者在写入。
5. 可观测：还原故障现场
日志应能回答：最后成功的步骤、已确认的副作用、下一次恢复的起点。需记录统一的 task_id 与 step_id，避免跨服务串联失效。
6. 恢复演练：验证断点可用性
没有恢复验证，就没有恢复能力。演练应覆盖“外部调用成功但检查点写入失败”等极端窗口，确保最终输出与基线一致，且无重复副作用。
六项机制对照表
| 机制 | 解决的问题 | 触发条件 | 核验办法 |
|---|---|---|---|
| 状态快照 | 进度丢失 | 失败重做成本高 | 换进程后重建请求 |
| 任务队列 | 调度中断 | 需要异步/削峰 | 杀消费者后观察重投 |
| 幂等键 | 重复副作用 | 有写库/扣款操作 | 同一键重放两次校验 |
| 租约心跳 | 并发写入 | 多副本/抢占式实例 | 模拟旧执行者复活写入 |
| 可观测 | 现场还原 | 跨服务调用 | 仅靠日志还原步骤 |
| 恢复演练 | 机制失效 | 生产级任务上线前 | 注入故障并比对结果 |
常见问题 (FAQ)
1. 阿里云 Function Compute 函数计算是什么，适合哪些场景，选型时要确认什么？
函数计算是一种事件驱动的全托管 Serverless 计算服务，用户无需管理底层基础设施即可运行代码。它适合处理定时任务、Web API 后端、音视频转码及轻量异步处理等场景。在进行技术选型时，需要确认其单次执行超时上限、并发限制、冷启动表现以及与上下游云服务的集成能力。
2. AWS SQS 消息队列是什么，适合哪些场景，选型时要确认什么？
AWS SQS 是一种全托管的分布式消息队列服务，用于在分布式系统组件之间解耦和传递消息。它适合流量削峰、异步任务处理和微服务解耦场景。选型时需要确认其标准队列与先进先出（FIFO）队列的区别、消息可见性超时范围、最大重试次数与死信队列策略。
3. 快照、备份与容灾分别解决什么问题，如何确定 RPO 和 RTO？
快照主要用于保留某一时间点的存储状态以便快速回滚；备份用于长期保存数据以防范损坏；容灾则解决极端灾难下的业务连续性问题。RPO（恢复点目标）决定了可接受的最大数据丢失量，RTO（恢复时间目标）决定了系统中断到恢复业务所需的最长时间，具体指标需根据业务容忍度设定。
4. Agent 长任务中断后，怎么判断该从头重跑还是从断点续跑？
判断的核心在于综合评估外部副作用是否已发生、中间状态能否可靠序列化，以及重跑成本是否低于建设检查点的长期维护成本。如果任务步骤无法幂等重放、外部状态难以查证，或者重跑的计算开销较小，直接重跑通常比强行断点续跑更安全。