LangGraph 這個(gè)庫這兩年討論度很高但我在社區(qū)里看過不少人的練習(xí)路徑有個(gè)共同問題一上來就追著多代理架構(gòu)跑結(jié)果圖是搭出來了State 卻改得亂七八糟一加分支就崩。我自己練 LangGraph 的順序和別人不太一樣最先啃的就是狀態(tài)代碼——State 的定義、節(jié)點(diǎn)返回值怎么合并、Reducer 怎么控制更新、條件分支里狀態(tài)怎么傳。這套練扎實(shí)之后再看那些多節(jié)點(diǎn)、帶分支、帶記憶的流程基本就通了。這篇文章就把我完整的狀態(tài)代碼練習(xí)過程記錄下來環(huán)境基于我常用的較新版 LangGraph適合剛接觸這個(gè)庫、以及已經(jīng)會(huì)搭圖但對狀態(tài)更新機(jī)制一知半解的同學(xué)。1. 先把狀態(tài)模型這層窗戶紙捅破1.1 狀態(tài)到底是什么、為什么值得專門練LangGraph 的核心是一個(gè)狀態(tài)圖節(jié)點(diǎn)Node負(fù)責(zé)干活邊Edge決定順序而貫穿所有節(jié)點(diǎn)之間、讓每個(gè)節(jié)點(diǎn)都能讀到上下文的東西就是 State。State 本身就是一個(gè)字典結(jié)構(gòu)的對象你用 TypedDict 或 dataclass 提前定義好它長什么樣然后每次節(jié)點(diǎn)執(zhí)行完后把“想改的字段”做成一個(gè)字典返回圖的運(yùn)行時(shí)負(fù)責(zé)把這些改動(dòng)合并回總狀態(tài)里。我說的“練狀態(tài)代碼”練的就是這三件事第一怎么定義一份合理的狀態(tài)結(jié)構(gòu)第二節(jié)點(diǎn)返回什么樣的數(shù)據(jù)、以什么方式合并進(jìn)總狀態(tài)第三在分支、循環(huán)、并行節(jié)點(diǎn)里狀態(tài)怎么傳遞不丟不串。這三件事任何一個(gè)沒搞明白圖都能跑但跑出來的結(jié)果就是不對而且特別難排查。為什么說這個(gè)值得單獨(dú)練因?yàn)楹芏鄠鹘y(tǒng)開發(fā)者的直覺是“函數(shù)輸入輸出”。一個(gè)函數(shù)處理完數(shù)據(jù)把結(jié)果返回給下一個(gè)函數(shù)參數(shù)一顆顆傳下去。這套思路在寫普通后端接口時(shí)沒問題但一旦涉及多步驟的智能體流程——比如先規(guī)劃、再檢索、再生成、中途還要根據(jù)結(jié)果決定走哪條分支——函數(shù)式的傳參會(huì)讓代碼變成一團(tuán)亂麻。State 本質(zhì)上是一塊“公共白板”所有節(jié)點(diǎn)都能往上寫、都能往里讀你不需要在調(diào)用時(shí)手動(dòng)把每一步的臨時(shí)變量傳來傳去。這個(gè)模型想通了LangGraph 就算入門了。1.2 從“接力棒”到“公共白板”的思維切換先看一個(gè)典型的舊思路代碼def step1(raw_text: str) - str: cleaned raw_text.strip().lower() return cleaned def step2(cleaned: str) - list[str]: tokens cleaned.split() return tokens result step2(step1( Hello LangGraph ))每一步函數(shù)都只接收上一個(gè)函數(shù)的返回值如果你想在最后一步同時(shí)拿到 raw_text、cleaned、tokens就得用元組或者類把這些都包著往下傳。代碼一多參數(shù)列表就失控了。換成 LangGraph 的狀態(tài)模型寫法變成了這樣from typing import TypedDict from langgraph.graph import StateGraph, START, END class MyState(TypedDict): raw_text: str cleaned: str tokens: list[str] def step1(state: MyState) - dict: return {cleaned: state[raw_text].strip().lower()} def step2(state: MyState) - dict: return {tokens: state[cleaned].split()} builder StateGraph(MyState) builder.add_node(step1, step1) builder.add_node(step2, step2) builder.add_edge(START, step1) builder.add_edge(step1, step2) builder.add_edge(step2, END) graph builder.compile() print(graph.invoke({raw_text: Hello LangGraph }))注意 step2 里讀的state[cleaned]并不是 step1 直接傳給你的參數(shù)而是 step1 寫好、圖運(yùn)行時(shí)合并進(jìn) State 之后的公共數(shù)據(jù)。這就像一個(gè)團(tuán)隊(duì)共用的項(xiàng)目白板每個(gè)人干完活把自己負(fù)責(zé)的那部分更新上去下一個(gè)同事需要什么直接看白板不需要等某個(gè)人把結(jié)果遞到手里。你可能覺得這個(gè)例子太簡單看不出差別。但你要是在這個(gè)圖里再加一個(gè)“日志收集節(jié)點(diǎn)”、加一個(gè)“異常處理分支”State 的優(yōu)勢馬上就出來了——日志往logs字段里累積分支判斷讀state[status]每個(gè)節(jié)點(diǎn)只需要關(guān)心自己讀寫的那幾個(gè)字段不要碰自己不關(guān)心的東西。這就是狀態(tài)驅(qū)動(dòng)設(shè)計(jì)的核心思想。2. 第一個(gè)狀態(tài)練習(xí)最小可運(yùn)行圖2.1 把環(huán)境準(zhǔn)備好LangGraph 是純 Python 庫安裝很簡單pip install langgraph建議 Python 版本 3.9 以上另外如果你計(jì)劃跑帶持久化的例子還需要確認(rèn)langgraph-checkpoint已經(jīng)作為依賴裝好。我練習(xí)時(shí)習(xí)慣在普通 Python 腳本里寫因?yàn)槟_本跑完能直接看到 print 輸出比在交互式環(huán)境里更容易保留完整記錄。注意LangGraph 的 API 在 0.1 到 0.2 之間有過調(diào)整比較明顯的變化是入口圖用START而不是__start__。我這篇文章的代碼基于 0.2.x 及以上版本如果你還在用很老的版本建議先升級到最新穩(wěn)定版再照著練。2.2 用 TypedDict 把狀態(tài)結(jié)構(gòu)先釘死狀態(tài)結(jié)構(gòu)是一張圖的“數(shù)據(jù)庫表結(jié)構(gòu)”先想清楚再寫節(jié)點(diǎn)。我第一次練習(xí)時(shí)直接上來寫節(jié)點(diǎn)函數(shù)結(jié)果反復(fù)改字段名圖一跑就 KeyError。后來我學(xué)乖了任何練習(xí)的第一步永遠(yuǎn)是定義狀態(tài)。from typing import TypedDict class CounterState(TypedDict): count: int logs: list[str]這個(gè)狀態(tài)有兩個(gè)字段count用來記錄數(shù)值logs用來記錄每一步的處理日志。就這么簡單但注意一個(gè)細(xì)節(jié)字段的類型要寫具體int、list[str]都明確標(biāo)注因?yàn)楹竺鎸懝?jié)點(diǎn)函數(shù)時(shí) IDE 會(huì)幫你做提示字段名拼錯(cuò)時(shí)也能更快發(fā)現(xiàn)。為什么用 TypedDict 而不是普通字典因?yàn)槠胀ㄗ值涮杂闪斯?jié)點(diǎn)里寫state[cnt]和state[count]都不會(huì)報(bào)錯(cuò)運(yùn)行時(shí)才會(huì)炸TypedDict 至少能在編輯器里給你一層提示和約束。LangGraph 本身也支持 pydantic 模型或 dataclass 作為狀態(tài)定義但初學(xué)者從 TypedDict 起步最合適它足夠輕量心智負(fù)擔(dān)最小。2.3 用三個(gè)節(jié)點(diǎn)跑通完整鏈路定義好狀態(tài)之后我加三個(gè)節(jié)點(diǎn)一個(gè)加一、一個(gè)翻倍、一個(gè)收尾記錄。重點(diǎn)看每個(gè)節(jié)點(diǎn)怎么返回“更新補(bǔ)丁”。from typing import TypedDict from langgraph.graph import StateGraph, START, END class CounterState(TypedDict): count: int logs: list[str] def add_one(state: CounterState) - dict: new_count state[count] 1 return {count: new_count, logs: state[logs] [fadd_one - {new_count}]} def double(state: CounterState) - dict: new_count state[count] * 2 return {count: new_count, logs: state[logs] [fdouble - {new_count}]} def final_note(state: CounterState) - dict: return {logs: state[logs] [ffinal count is {state[count]}]} builder StateGraph(CounterState) builder.add_node(add_one, add_one) builder.add_node(double, double) builder.add_node(final, final_note) builder.add_edge(START, add_one) builder.add_edge(add_one, double) builder.add_edge(double, final) builder.add_edge(final, END) graph builder.compile() result graph.invoke({count: 1, logs: []}) print(result)運(yùn)行結(jié)果{count: 4, logs: [add_one - 2, double - 4, final count is 4]}我建議你親手跑一遍這個(gè)例子重點(diǎn)觀察兩件事。第一invoke的入?yún)⑹恰俺跏紶顟B(tài)”返回值是“最終狀態(tài)”中間每個(gè)節(jié)點(diǎn)產(chǎn)生的新狀態(tài)你是看不見的除非你在節(jié)點(diǎn)里打印。第二節(jié)點(diǎn)返回的字典不需要包含所有字段比如double節(jié)點(diǎn)完全可以不返回logs原樣保留也可以像我這樣手動(dòng)拼接后返回。這里有個(gè)初學(xué)者最容易踩的坑以為節(jié)點(diǎn)返回什么狀態(tài)就“變成”什么實(shí)際上對于沒有配置特殊合并邏輯的字段返回的 value 會(huì)直接覆蓋舊值。2.4 在節(jié)點(diǎn)里埋點(diǎn)觀察狀態(tài)流轉(zhuǎn)光看最終結(jié)果你可能還是不知道狀態(tài)到底怎么變的。我的練習(xí)習(xí)慣是在每個(gè)節(jié)點(diǎn)開頭打印當(dāng)前狀態(tài)def double(state: CounterState) - dict: print(f[double] 進(jìn)入時(shí)狀態(tài): {state}) new_count state[count] * 2 return {count: new_count, logs: state[logs] [fdouble - {new_count}]}這樣跑一次就能看到每條邊觸發(fā)時(shí)狀態(tài)里已經(jīng)累積了什么、當(dāng)前節(jié)點(diǎn)準(zhǔn)備改什么。等你以后排查“哪個(gè)節(jié)點(diǎn)把狀態(tài)改壞了”時(shí)這個(gè)習(xí)慣能幫你省下一大半時(shí)間。提示compile()之后得到的是一個(gè)可調(diào)用的編譯對象。你可以反復(fù)調(diào)用invoke每次傳入新的初始狀態(tài)互不干擾。這跟“同一個(gè)圖的多次運(yùn)行之間默認(rèn)沒有記憶”這一特性有關(guān)后面講 Checkpointer 時(shí)再展開。3. 狀態(tài)更新的核心Reducer 機(jī)制一定要親手試3.1 默認(rèn)覆蓋行為先知道“什么都不寫”時(shí)是什么效果在 LangGraph 里如果你在狀態(tài)定義里對某個(gè)字段沒做任何標(biāo)注那它的默認(rèn)更新方式就是“整體覆蓋”。兩個(gè)節(jié)點(diǎn)不管誰先誰后只要都返回同一個(gè)字段名后執(zhí)行的節(jié)點(diǎn)就會(huì)把前一個(gè)節(jié)點(diǎn)的值整個(gè)替換掉。這個(gè)行為本身沒問題count這種標(biāo)量字段用覆蓋就很合理——最后一步的值就是我想要的值。但一旦字段是列表、字典這種“需要累積”的數(shù)據(jù)覆蓋行為就會(huì)讓你抓狂。比如上面例子里如果我不手動(dòng)把state[logs] [新日志]拼好再返回而是直接返回{logs: [新日志一]}那跑完后logs里只剩最后一個(gè)節(jié)點(diǎn)的記錄前面的全丟了。所以你需要理解 Reducer它決定了“多個(gè)更新同時(shí)作用到同一個(gè)字段上時(shí)怎么合并”。沒有 Reducer就是后寫覆蓋有 Reducer就能做到追加、拼接、去重等自定義合并。3.2 用 add_messages 維護(hù)對話消息列表聊到 LangGraph 的紅區(qū)最常用的就是add_messages。它原本是給聊天消息設(shè)計(jì)的 Reducer但理解它的行為能幫你更好地理解所有 Reducer 的運(yùn)作方式。from typing import TypedDict, Annotated from langgraph.graph.message import add_messages class ChatState(TypedDict): messages: Annotated[list, add_messages] intent: str def user_turn(state: ChatState) - dict: return {messages: [{role: user, content: 我想退款}]} def assistant_turn(state: ChatState) - dict: return {messages: [{role: assistant, content: 好的我來幫您處理}]}這里的關(guān)鍵是Annotated[list, add_messages]。Annotated是 Python 自帶的類型標(biāo)注工具LangGraph 會(huì)讀取它的第二個(gè)參數(shù)作為這個(gè)字段的 Reducer。add_messages的作用是如果新舊值都是消息列表就把它們合并如果存在帶id的消息對象還能按id去重更新。你不需要手動(dòng)把歷史消息拼進(jìn)返回值只要返回“這一次新增的消息”運(yùn)行時(shí)就會(huì)自動(dòng)追加到狀態(tài)里的messages上。這就是正確用法節(jié)點(diǎn)只返回增量合并交給 Reducer。3.3 自定義 Reducer寫一個(gè)屬于自己的合并規(guī)則add_messages 好用但它解決不了所有問題。比如你希望某個(gè)字段做“取最大值”“數(shù)值累加”“字典合并”那就得自己寫 Reducer。Reducer 的簽名很固定接收兩個(gè)參數(shù)第一個(gè)是當(dāng)前狀態(tài)里已有的值第二個(gè)是節(jié)點(diǎn)返回的更新值返回合并后的新值。from typing import TypedDict, Annotated, Annotated def sum_reducer(current: int, update: int) - int: return current update class ScoreState(TypedDict): total: Annotated[int, sum_reducer] name: str def node_a(state: ScoreState) - dict: return {total: 10} def node_b(state: ScoreState) - dict: return {total: 5}這兩個(gè)節(jié)點(diǎn)無論怎么排序執(zhí)行最終total都是 15 而不是“后寫的 5”。因?yàn)槊總€(gè)節(jié)點(diǎn)返回的數(shù)值都會(huì)通過sum_reducer與當(dāng)前值合并順序是先加 10 再加 5或者反過來。這里有一個(gè)特別重要的細(xì)節(jié)Reducer 是一對一合并的也就是說它每次只處理“一個(gè)更新值”和“當(dāng)前累積值”。所以在并行分支場景下你不能在節(jié)點(diǎn)里返回一個(gè)“已經(jīng)包含舊值的完整快照”否則會(huì)把已有內(nèi)容再算一遍導(dǎo)致重復(fù)累加。正確的做法永遠(yuǎn)是返回增量讓 Reducer 去做累積。# 錯(cuò)誤示范節(jié)點(diǎn)里自己拼了歷史 def wrong_node(state: ScoreState) - dict: return {total: state[total] 100} # 如果配了 sum_reducer這里最終會(huì)多加一次 # 正確示范只返回增量 def right_node(state: ScoreState) - dict: return {total: 100} # sum_reducer 自己處理累加我把這個(gè)坑單獨(dú)拿出來講是因?yàn)樗谡鎸?shí)項(xiàng)目里特別常見。凡是配了 Reducer 的字段節(jié)點(diǎn)里的返回值含義就變了不再是“最終值”而是“這次貢獻(xiàn)的更新量”。這個(gè)思維轉(zhuǎn)變是練狀態(tài)代碼最核心的一關(guān)。4. 狀態(tài)驅(qū)動(dòng)的條件分支與多路匯合4.1 條件邊的路由約定LangGraph 最吸引人的能力就是條件分支根據(jù)當(dāng)前狀態(tài)的內(nèi)容決定下一步走哪個(gè)節(jié)點(diǎn)。實(shí)現(xiàn)方式是用add_conditional_edges掛一個(gè)路由函數(shù)。路由函數(shù)接收當(dāng)前狀態(tài)返回一個(gè)節(jié)點(diǎn)名字符串或者返回一個(gè)能被映射表翻譯的 key。我推薦直接返回節(jié)點(diǎn)名字符串少一層映射少踩一個(gè)坑。def route(state: ChatState) - str: if state[intent] refund: return refund if state[intent] tech: return tech return human然后這樣掛邊builder.add_conditional_edges(classify, route)運(yùn)行時(shí)會(huì)在classify節(jié)點(diǎn)執(zhí)行完畢后根據(jù)返回的字符串決定下一步進(jìn)哪個(gè)節(jié)點(diǎn)。返回的名字必須在圖里已經(jīng)注冊過否則會(huì)報(bào)錯(cuò)說找不到節(jié)點(diǎn)。4.2 一個(gè)帶分支的完整練習(xí)意圖路由客服系統(tǒng)把前面的內(nèi)容串起來我練過一個(gè)完整的小例子模擬一個(gè)客服入口按意圖分流到不同處理節(jié)點(diǎn)from typing import TypedDict, Annotated from langgraph.graph import StateGraph, START, END from langgraph.graph.message import add_messages class SupportState(TypedDict): messages: Annotated[list, add_messages] intent: str handled: bool def classify(state: SupportState) - dict: text state[messages][-1][content] if 退 in text: intent refund elif 卡 in text or 慢 in text: intent tech else: intent human return {intent: intent} def refund_handler(state: SupportState) - dict: return {messages: [{role: assistant, content: 退款流程已啟動(dòng)}], handled: True} def tech_handler(state: SupportState) - dict: return {messages: [{role: assistant, content: 已創(chuàng)建技術(shù)支持工單}], handled: True} def human_handler(state: SupportState) - dict: return {messages: [{role: assistant, content: 轉(zhuǎn)接人工客服}], handled: True} def route(state: SupportState) - str: return state[intent] # 直接返回節(jié)點(diǎn)名 builder StateGraph(SupportState) builder.add_node(classify, classify) builder.add_node(refund, refund_handler) builder.add_node(tech, tech_handler) builder.add_node(human, human_handler) builder.add_edge(START, classify) builder.add_conditional_edges(classify, route) builder.add_edge(refund, END) builder.add_edge(tech, END) builder.add_edge(human, END) graph builder.compile() result graph.invoke({messages: [{role: user, content: 我想退款}], intent: , handled: False}) print(result)注意這里route直接返回state[intent]而intent是classify節(jié)點(diǎn)寫進(jìn)狀態(tài)里的。所以路由的決策完全依賴狀態(tài)里的字段這就是“狀態(tài)驅(qū)動(dòng)”四個(gè)字的含義。我建議你把輸入改成“網(wǎng)絡(luò)很卡”和“我要投訴”各跑一遍觀察它走的分支完全不同但代碼里沒有寫死任何順序。4.3 分支匯合時(shí)的狀態(tài)同步細(xì)節(jié)很多時(shí)候分支結(jié)束后還要匯合到一個(gè)公共節(jié)點(diǎn)繼續(xù)處理。比如客服所有分支最后都要進(jìn)入一個(gè)“記錄日志”節(jié)點(diǎn)。匯合本身不復(fù)雜只要在每條分支末尾都連到同一個(gè)節(jié)點(diǎn)就行builder.add_edge(refund, record_log) builder.add_edge(tech, record_log) builder.add_edge(human, record_log)但這里有個(gè)非常隱蔽的狀態(tài)問題如果多個(gè)分支是并行執(zhí)行的比如用add_edge讓兩個(gè)節(jié)點(diǎn)同時(shí)指向同一個(gè)下游它們會(huì)同時(shí)寫同一個(gè)狀態(tài)字段。對于配了 Reducer 的字段比如messages更新會(huì)按順序合并不會(huì)丟但對于沒配 Reducer 的字段比如普通int或者str后寫完的覆蓋先寫完的最終結(jié)果取決于執(zhí)行順序而這個(gè)順序在并行場景里是不確定的。所以我的經(jīng)驗(yàn)法則是并行分支里盡量讓每個(gè)分支寫自己的獨(dú)立字段refund_result、tech_result不要在多個(gè)分支里改同一個(gè)無 Reducer 的字段。如果確實(shí)要匯總就定義一個(gè)results字段配上 Reducer讓各方把結(jié)果塞進(jìn)去再統(tǒng)一處理。這個(gè)設(shè)計(jì)思路我在真實(shí)項(xiàng)目里用得很頻繁能避免掉 80% 的“狀態(tài)被莫名覆蓋”問題。5. 狀態(tài)練習(xí)中的常見坑與排查實(shí)錄5.1 狀態(tài)沒更新先按這三個(gè)方向查我在練習(xí)狀態(tài)代碼時(shí)最常碰到的問題就是“我明明 return 了為什么狀態(tài)沒變”。排查順序基本固定第一檢查返回字典的 key 拼寫有沒有跟狀態(tài)定義里完全一致包括大小寫和下劃線。TypedDict 在編輯器里會(huì)提示但你如果用動(dòng)態(tài)字符串構(gòu)造字典提示就失效了必須肉眼核對。第二檢查節(jié)點(diǎn)函數(shù)是否真的執(zhí)行了 return。很多人寫節(jié)點(diǎn)時(shí)先寫了一段打印邏輯最后忘了 return函數(shù)默認(rèn)返回 NoneLangGraph 會(huì)把它當(dāng)成“沒有更新”狀態(tài)自然原封不動(dòng)。第三檢查這個(gè)字段是否配了 Reducer。如果配了累加型 Reducer而你想“設(shè)置新值”返回單個(gè)值的結(jié)果可能跟你預(yù)期不一樣。比如total配了sum_reducer某個(gè)節(jié)點(diǎn)想重置為 0簡單返回{total: 0}并不會(huì)變成 0而是繼續(xù)累加。排查技巧也很直接在每個(gè)節(jié)點(diǎn)開頭打印當(dāng)前狀態(tài)、return 前打印準(zhǔn)備返回的更新值跑一遍輸出就能定位是哪一層的問題。別靠猜狀態(tài)圖一旦節(jié)點(diǎn)多了靠猜是猜不出來的。5.2 Reducer 的“雙刃劍”效應(yīng)給字段加 Reducer 能解決累積問題但也會(huì)帶來意想不到的副作用。最典型的是你在開發(fā)初期給messages加上了add_messages后期某個(gè)節(jié)點(diǎn)想“清空消息列表重新開始”結(jié)果發(fā)現(xiàn)清不掉因?yàn)槿魏畏祷氐牧斜矶紩?huì)跟現(xiàn)有列表合并。解決這類問題我常用的辦法有三個(gè)一是換一個(gè)字段名來承載“重置后的新列表”讓舊列表留在狀態(tài)里但不再被讀取二是在 Reducer 里加入特殊標(biāo)記值比如檢測到更新值是某個(gè)特定字符串時(shí)直接替換而不是合并三是干脆把“重置”也做成一個(gè)明確的業(yè)務(wù)節(jié)點(diǎn)它直接返回一個(gè)全新的消息列表并且你通過設(shè)計(jì)讓它的上游節(jié)點(diǎn)不再往同一個(gè)字段寫增量。這里面沒有銀彈關(guān)鍵是想清楚一旦某個(gè)字段配置了 Reducer全圖所有節(jié)點(diǎn)對這個(gè)字段的更新語義都已經(jīng)變了寫節(jié)點(diǎn)時(shí)必須時(shí)刻記住這一點(diǎn)。我在團(tuán)隊(duì)里跟人協(xié)作時(shí)經(jīng)常在狀態(tài)定義旁邊寫清楚每個(gè)字段的合并語義避免別人把普通字段當(dāng)成覆蓋字段來寫。5.3 TypedDict 的類型邊界與運(yùn)行時(shí)校驗(yàn)TypedDict 雖然在定義階段給了你類型提示但它的約束主要停留在編輯器層面。LangGraph 在運(yùn)行時(shí)對狀態(tài)的校驗(yàn)深度有限尤其是嵌套結(jié)構(gòu)比如state[profile]是一個(gè) dict里面少了一個(gè) key 時(shí)TypedDict 不一定能攔住你等到節(jié)點(diǎn)里訪問時(shí)才報(bào) KeyError。我的建議是狀態(tài)結(jié)構(gòu)盡量保持扁平。字段就是一層每個(gè)字段的值要么是標(biāo)量要么是列表要么是明確類型的數(shù)據(jù)對象。如果確實(shí)有復(fù)雜的結(jié)構(gòu)化數(shù)據(jù)用 dataclass 或 pydantic 模型作為字段類型在節(jié)點(diǎn)邊界做顯式校驗(yàn)。不要試圖在狀態(tài)里塞三層以上的嵌套字典那會(huì)讓整個(gè)圖的可排查性變得非常差。這里還有一個(gè)相關(guān)細(xì)節(jié)LangGraph 對“節(jié)點(diǎn)返回了狀態(tài)定義里不存在的 key”這件事在不同版本里處理方式不完全一致。我建議永遠(yuǎn)不要依賴舊版本的寬松行為返回的 key 必須都定義在狀態(tài)結(jié)構(gòu)里否則直接視為實(shí)現(xiàn)錯(cuò)誤盡早暴露。5.4 Checkpointer 相關(guān)thread_id 不配就白改狀態(tài)練習(xí)做到后面你一定會(huì)碰到持久化和多輪對話的需求。LangGraph 的記憶機(jī)制依賴 Checkpointer當(dāng)你把圖編譯成帶記憶的版本后調(diào)用方式會(huì)發(fā)生變化from langgraph.checkpoint.memory import MemorySaver saver MemorySaver() graph builder.compile(checkpointersaver) config {configurable: {thread_id: thread-1}} graph.invoke({messages: [{role: user, content: 第一輪}]}, config) graph.invoke({messages: [{role: user, content: 第二輪}]}, config)沒有傳config的話每次invoke仍然是從干凈的初始狀態(tài)開始跑之前寫入狀態(tài)的內(nèi)容不會(huì)被保留。我見過不少人配了 Checkpointer 卻忘了傳thread_id然后來問“為什么我的圖沒有記憶”問題就出在這。另外同一個(gè)thread_id的多次調(diào)用之間狀態(tài)是累積的。你想在調(diào)試時(shí)重新開始就換一個(gè)新的thread_id或者用graph.get_state(config)查看當(dāng)前狀態(tài)、用graph.update_state(config, {...})手動(dòng)修改某一步的狀態(tài)。這些 API 都是練狀態(tài)代碼時(shí)遲早要碰的我建議你在基礎(chǔ)練習(xí)通過后專門花半天時(shí)間只練 Checkpointer 相關(guān)的操作。6. 我的練習(xí)心法與最后幾條建議6.1 按什么順序練效率最高如果讓我給一個(gè)建議的練習(xí)順序我會(huì)把它分成四步第一步只練三個(gè)節(jié)點(diǎn)的直線圖把invoke的輸入輸出徹底搞清楚重點(diǎn)理解“節(jié)點(diǎn)返回的是更新補(bǔ)丁”這件事第二步練習(xí)各種 Reducer自己寫一個(gè)累加器、一個(gè)add_messages的聊天累積、一個(gè)取最大值的合并函數(shù)把Annotated的用法吃透第三步練條件分支從最簡單的二分路由開始慢慢加分支、加匯合第四步練帶 Checkpointer 的多輪對話理解thread_id和狀態(tài)持久化的關(guān)系。每完成一步就寫一個(gè)獨(dú)立的小腳本保存下來腳本里加幾個(gè)斷言判斷輸出的狀態(tài)是否符合預(yù)期。比如跑完CounterState后斷言result[count] 4。這樣你后面改動(dòng)狀態(tài)結(jié)構(gòu)時(shí)一跑就能知道有沒有破壞舊行為非常值得。6.2 最值得帶進(jìn)真實(shí)項(xiàng)目的一個(gè)習(xí)慣最后分享一個(gè)我個(gè)人非常受用的習(xí)慣每個(gè)狀態(tài)字段的定義旁邊用注釋寫清楚它的更新語義。比如class OrderState(TypedDict): step: str # 覆蓋后寫為準(zhǔn) logs: Annotated[list, operator.add] # 累加各節(jié)點(diǎn)只追加增量 messages: Annotated[list, add_messages] # 聊天消息自動(dòng)合并這短短幾行注釋能避免掉大量的“跟我預(yù)期不一樣”的 bug。狀態(tài)代碼本來就是 LangGraph 項(xiàng)目里最容易被忽視、卻最影響全局穩(wěn)定性的部分前期多花一個(gè)下午把狀態(tài)模型吃透后面搭真正的多代理應(yīng)用時(shí)你會(huì)感謝自己當(dāng)初沒有跳過這一步。