周三下午，财务部的Lisa收到一封邮件——某笔采购需要她审批。她点开附件里的Excel表格，发现版本号已经乱成"最终版_真的最终版_5月修订"。上周的审批记录在哪？不知道。谁改的预算数字？找不到。如果审计明天来查，她只能回复："我再问问。"

这不是某个公司的特例。大多数企业的审批流程根本不是"系统"，而是邮件串、转发链和随时可能崩溃的共享表格。当流程跨部门时，问题更糟：采购要查供应商、财务要核预算、法务要审合同，每一步都在不同系统里，没有共享状态。第三步卡住了？从头再来。

打开网易新闻 查看精彩图片

技术层面的核心问题是：没有持久化、结构化的工作流状态。邮件里的流程无法暂停、无法审计、崩溃后无法恢复。一位开发者用LangGraph、FastAPI和SQLite搭建了解决方案，本文是他的实现思路。

打开网易新闻 查看精彩图片

核心需求很明确：工作流必须在人工决策点暂停，并在精确位置恢复——哪怕服务器中间重启过。LangGraph的StateGraph恰好满足这一点。它将工作流结构（节点和边）与工作流状态（类型化的字典数据）分离，每一步转换都自动保存检查点。

两个关键原语让这套方案落地：

interrupt_before：编译图时可指定在哪些节点前中断。到达这些节点时，图暂停、状态持久化到检查点，控制权交回调用方。用相同线程ID再次调用时，从断点精确恢复。

打开网易新闻 查看精彩图片

AsyncSqliteSaver：持久化检查点后端，将图状态写入SQLite。与默认的MemorySaver（进程本地存储）不同，它在服务器重启后仍然存活，任何有正确连接字符串的进程都能读取。

这套"检查点模式"解决了一个常见陷阱：假设进程内存是持久的。实际上，每次服务器重启、每次部署、每次崩溃，都会静默杀死所有进行中的工作流。唯一的修复方案是：每一步转换都写持久存储，而非仅在结束时保存。