长任务中途停了，Microsoft Agent Framework 可以从检查点接着跑

一个 AI 任务先整理材料，再运行几项分析，最后生成报告。前面已经做完，进程却在最后一步中断。如果应用只保存聊天文字，下一次启动未必知道还有哪些步骤没完成。Microsoft Agent Framework 的检查点，保存的是工作流的执行状态，让长任务有机会从一个确定位置继续。

这项能力适合正在构建应用的开发者。项目 README将顺序、并发、交接等流程组织在同一框架内；检查点则为这些步骤补上进度保存，而不是替最终回答增加一个“已保存”标签。

保存的状态，比文字摘要多什么

官方检查点文档说明，工作流按 superstep 推进，在该轮执行器完成后保存检查点。内容包括执行器状态、下一步待处理消息、未完成的请求与响应，以及共享状态。

回到报告的教学情境：前一个执行器产生了分析结果，后一个还没把它整理成最终文本。检查点需要知道结果是什么，也要知道接下来谁应该收到它。只有一份“我们已经做了分析”的自然语言摘要，并不能替代这些运行数据。

这也解释了为什么任意一行程序执行到一半，不一定就是可恢复边界。工作流按自身的步骤模型保存，开发者应把适合单独交付和重试的工作组织成相应执行单元。

先选对存储，再谈重启恢复

Python 文档列出 InMemoryCheckpointStorage、FileCheckpointStorage 和 CosmosCheckpointStorage。内存适合测试和短任务，但进程结束后状态不会自动留下；文件存储保存到明确目录，适合单机与本地开发；分布式场景可以选择对应的持久存储提供方。

这是选型中很容易被略过的一步。演示里能在同一进程重放，不代表关闭电脑后仍然可以恢复。想要后者，应用必须使用实际持久化的存储，并妥善保留检查点。

恢复时，可以列出某个 workflow 的检查点，再按 checkpoint_id 继续运行。官方也展示了在新建的工作流实例中加载旧状态的方式，但要求保持相同拓扑与执行器身份。改了节点关系或重建时随意生成新 ID，都可能使旧状态找不到对应位置。

恢复流程，不等于撤销外部世界

如果某一步已经发出邮件、写入外部数据库，再从此前位置重新执行，外部动作可能发生第二次。检查点保存工作流状态，不能自动替所有第三方系统完成回滚。实际应用应给这些动作安排可识别的请求或幂等处理。

同样，运行状态可能包含用户材料与中间结果，存储应作为可信的应用基础设施管理。无需为了一个本机试验搭满云组件，但要知道数据保存在哪里。

框架代码采用 MIT 许可，模型和云服务依各自条件使用。对于长时间分析、分阶段生成等任务，我会先把一个可恢复的中间成果设计清楚，再选择存储。真正值得保留的是“上次完成了哪些步骤，下一步具体接什么”，而不只是一串重新开始的提示。