Agent 长任务执行到一半失败了，怎么做断点续跑？
面试怎么回答
我会把 Agent 的长任务当成有状态的工作流来设计：任务目标、计划、每一步的输入输出和进度持久化到外部存储，每完成一步记录一次检查点；失败后从检查点读取已完成步骤和摘要，重建上下文，从下一步继续。有副作用的工具调用带任务 ID 加步骤 ID 作为幂等键，重放不会重复写入；区分可重试的超时、限流和不可重试的权限、参数错误。更重要的是把大任务拆小，比如 200 张表拆成 200 个子任务，由调度层控制并发和重试，Agent 只负责单个子任务的判断，最后汇总。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
Agent 执行一个 30 分钟的任务，比如「批量检查 200 张表的数据质量并生成报告」，跑到第 120 张时模型接口超时，整个任务失败。重新跑一遍？那前面的工作全浪费了，还可能重复写入。面试官问这题，本质上是在问你能不能把数据开发的容错经验用到 Agent 上。
为什么 Agent 的长任务更难恢复
- 状态散落在对话上下文里，进程一挂就没了；
- 模型的决策不完全确定，重跑不一定走同一条路径；
- 中间可能已经调用了有副作用的工具，比如写了表、发了消息。
设计思路：把 Agent 当成一个有状态的工作流
- 状态外置并持久化：任务目标、计划、每一步的输入输出、当前进度都写到数据库或对象存储，而不是只留在内存的上下文里；
- 按步骤做检查点：每完成一个步骤就记录一次，就像 Flink 的 Checkpoint、调度系统的任务实例状态；
- 恢复时从检查点重建上下文：读取已完成的步骤和摘要，重新组装上下文，从下一步继续；
- 副作用操作幂等：写表、发通知这类工具调用带上幂等键（任务 ID + 步骤 ID），重放时不会重复执行；
- 区分可重试和不可重试的错误：接口超时、限流可以退避重试；权限不足、参数错误要停下来，交给人处理。
大任务要拆小
200 张表的检查，不要让一个 Agent 一口气跑完：
- 拆成 200 个子任务，每个子任务独立执行、独立记录结果；
- 由调度层控制并发和重试，Agent 只负责单张表的判断；
- 最后再汇总生成报告。
这其实就是把 Agent 放进我们熟悉的调度体系里。
可以借鉴的工具
一些 Agent 框架提供了检查点和持久化执行的能力，也有团队用 Temporal 这类持久化工作流引擎来编排 Agent。关键不在用哪个框架，而在于：状态外置、步骤记录、副作用幂等。