北京
周三下午，財務部的Lisa收到一封郵件——某筆采購需要她審批。她點開附件里的Excel表格，發(fā)現(xiàn)版本號已經(jīng)亂成"最終版_真的最終版_5月修訂"。上周的審批記錄在哪？不知道。誰改的預算數(shù)字？找不到。如果審計明天來查，她只能回復："我再問問。"
這不是某個公司的特例。大多數(shù)企業(yè)的審批流程根本不是"系統(tǒng)"，而是郵件串、轉(zhuǎn)發(fā)鏈和隨時可能崩潰的共享表格。當流程跨部門時，問題更糟：采購要查供應商、財務要核預算、法務要審合同，每一步都在不同系統(tǒng)里，沒有共享狀態(tài)。第三步卡住了？從頭再來。
技術(shù)層面的核心問題是：沒有持久化、結(jié)構(gòu)化的工作流狀態(tài)。郵件里的流程無法暫停、無法審計、崩潰后無法恢復。一位開發(fā)者用LangGraph、FastAPI和SQLite搭建了解決方案，本文是他的實現(xiàn)思路。
核心需求很明確：工作流必須在人工決策點暫停，并在精確位置恢復——哪怕服務器中間重啟過。LangGraph的StateGraph恰好滿足這一點。它將工作流結(jié)構(gòu)（節(jié)點和邊）與工作流狀態(tài)（類型化的字典數(shù)據(jù)）分離，每一步轉(zhuǎn)換都自動保存檢查點。
兩個關(guān)鍵原語讓這套方案落地：
interrupt_before：編譯圖時可指定在哪些節(jié)點前中斷。到達這些節(jié)點時，圖暫停、狀態(tài)持久化到檢查點，控制權(quán)交回調(diào)用方。用相同線程ID再次調(diào)用時，從斷點精確恢復。
AsyncSqliteSaver：持久化檢查點后端，將圖狀態(tài)寫入SQLite。與默認的MemorySaver（進程本地存儲）不同，它在服務器重啟后仍然存活，任何有正確連接字符串的進程都能讀取。
這套"檢查點模式"解決了一個常見陷阱：假設進程內(nèi)存是持久的。實際上，每次服務器重啟、每次部署、每次崩潰，都會靜默殺死所有進行中的工作流。唯一的修復方案是：每一步轉(zhuǎn)換都寫持久存儲，而非僅在結(jié)束時保存。
特別聲明：以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
