如果你維護過一個基于 LangChain 的 Agent 工作流大概率遇到過這種場景一個簡單的“查訂單狀態(tài)”請求Agent 先調用戶接口、再調訂單接口、又把兩個結果重復調了一遍最后把前后三次的歷史消息全部塞進上下文重新生成Token 燒掉好幾倍更頭疼的是某個工具返回的格式一不符合預期LLM 就開始同一句話反復說最后卡在死循環(huán)里出不來。我一度以為這是 Prompt 沒調好直到把 AgentExecutor 換成 LangGraph用它的循環(huán)機制重構了整個工作流這些問題才真正從根上解決。這篇文章基于我的實際改造過程講的不是 LangGraph 的 API 羅列而是圍繞一個核心問題展開循環(huán)機制到底怎么優(yōu)化 LangChain Agent 工作流。你會看到傳統(tǒng) Agent 的問題根源、LangGraph 循環(huán)拆解、三處實戰(zhàn)改造、進階玩法以及改造前后的一組真實對比數據。無論你是在用 LangChain 寫 Agent 的老手還是剛接觸 LangGraph 的新人這篇文章都能給你一條完整的優(yōu)化思路。1. 從 AgentExecutor 到 LangGraph一次工作流優(yōu)化的起點1.1 我的 Agent 工作流到底卡在哪了我之前的“訂單助手”是一個典型的 LangChain ReAct Agent跑在 AgentExecutor 里核心邏輯很簡單LLM 推理出要調用哪個工具執(zhí)行工具觀察結果繼續(xù)推理。Demo 階段一切正常但一上真實業(yè)務就露餡了。我歸納成三個幾乎每天都在發(fā)生的坑第一個坑是Token 浪費嚴重。Agent 沒有全局視角它每一步都只看到“當前這一步”的輸入輸出經常重復調用已經拿過數據的接口。比如用戶說“幫我查我最近一單的物流”正確流程應該是先查用戶再查最近訂單最后查物流但 Agent 可能會先查用戶查到訂單后不直接查物流而是再查一遍訂單確認再查物流。每一步都要把 history 全部拼進 Prompt請求體越來越大賬單也越來越多。第二個坑是死循環(huán)沒有任何有效干預手段。AgentExecutor 內部是一個寫死的 while 循環(huán)LLM 如果連續(xù)生成同一種不符合工具規(guī)范的參數工具調用會一直失敗Agent 就一直重試。官網文檔里雖然有max_iterations參數但它只是“限制最大輪數”到了上限直接拋異常業(yè)務上根本沒法優(yōu)雅降級。第三個坑是狀態(tài)不可觀測。我想在中間步驟里做點業(yè)務判斷比如“如果查用戶信息失敗就走人工客服通道”這時候我需要拿到“當前已經執(zhí)行了哪些工具”、它們的返回值是什么。但 AgentExecutor 把這些信息全部混在agent_scratchpad的一串字符串里做判斷只能靠正則去摳文本極其脆弱。這三個坑本質上是同一個問題Agent 的執(zhí)行流程被封裝成了一個黑盒你只能往里塞 Prompt卻改不了它的循環(huán)體。所以優(yōu)化的第一步不是調 Prompt而是要把這個黑盒拆開。1.2 為什么 AgentExecutor 解決不了這些問題AgentExecutor 的問題不是它寫得不好而是它的抽象層級選錯了。它把“循環(huán)”這件事固定成了“LLM 推理 → 工具調用 → 觀察結果 → 繼續(xù)推理”的單一路徑循環(huán)體內你插不進任何自定義邏輯。舉個例子。我想在工具調用失敗時自動重試一次AgentExecutor 做不到“重試”這個語義它只會把錯誤文本當作 observation 丟給 LLM讓 LLM 自己決定要不要再調一次。LLM 可能決定重試也可能決定不重試行為完全不可控。再比如我想在退款操作前插入一個人工確認節(jié)點AgentExecutor 根本沒有“中斷-恢復”的機制我只能自己寫一個丑陋的 while 循環(huán)在外部做狀態(tài)同步。本質上AgentExecutor 把 Agent 當成了一條“能自我迭代的鏈”編排能力停留在線性的“鏈式調用”上。而真實的 Agent 工作流是一個圖有反復執(zhí)行的循環(huán)、有需要并行的分支、有需要中斷等待人工介入的節(jié)點。用鏈的模型去表達圖的問題自然處處碰壁。1.3 LangGraph 到底是啥一張可以“有環(huán)”的圖LangGraph 是 LangChain 團隊出的編排框架它解決的就是我剛才說的“表達力不足”問題。它的核心抽象很簡單一張圖。節(jié)點node就是處理單元比如“調用模型”“執(zhí)行工具”“人工確認”邊edge決定節(jié)點之間的流轉方向。LangGraph 和 LangChain 工作流最通俗的區(qū)別在這里LangChain 的 Chain 只能往前流動像一條單向傳送帶LangGraph 的 Graph 允許節(jié)點指回之前的節(jié)點像一張帶環(huán)路的城市道路圖。這個“允許有環(huán)”的能力就是循環(huán)機制的根基。有了環(huán)你可以把 AgentExecutor 內部的 while 循環(huán)顯式地畫出來model節(jié)點調用 LLM條件邊判斷 LLM 是否要求調用工具如果要就流向tools節(jié)點執(zhí)行完再指回model節(jié)點形成環(huán)路。這個環(huán)完全由你控制你可以在環(huán)上任意位置插入新節(jié)點比如重試節(jié)點、確認節(jié)點、降級節(jié)點。本文后面的示例基于langgraph 0.2.x版本StateGraph API 在 0.3.x 也沒有大的變化。如果你用的版本更新注意langgraph.graph.MessageState這類新封裝原理一致。2. 循環(huán)機制拆開看LangGraph 把 ReAct 的“偷偷循環(huán)”變成了“顯式循環(huán)”2.1 ReAct 的本質就是一個循環(huán)只是你干預不了要理解 LangGraph 的循環(huán)優(yōu)化先得把 ReAct 的本質看清楚。ReAct 的三個動作是 Thought思考、Action行動、Observation觀察然后基于觀察繼續(xù)思考直到 LLM 認為自己拿到了足夠信息生成 Final Answer。這個過程天然是一個循環(huán)而且循環(huán)次數不固定完全由 LLM 的推理結果決定。在 AgentExecutor 里這個循環(huán)是“偷偷”進行的。它被封裝在 execute 方法內部你只能看到最終結果看不到中間過程更插不進手。這就是為什么前面提到的“Token 浪費”和“死循環(huán)”那么難治——你沒有手術刀只能在體外隔著玻璃看。LangGraph 的思路是把這層玻璃砸了。它要求你顯式地把每一個步驟定義成節(jié)點把流轉條件定義成邊。循環(huán)不再是一個 while 語句而是一條從tools節(jié)點指回model節(jié)點的邊。你擁有了循環(huán)的控制權自然也就擁有了優(yōu)化的空間。2.2 用節(jié)點和條件邊把循環(huán)攤開先看一個最精簡的 LangGraph Agent 循環(huán)圖長什么樣。我習慣定義一個AgentState來承載整個工作流的狀態(tài)然后按“模型 → 工具 → 模型”的環(huán)路組織節(jié)點from typing import TypedDict, Annotated from langgraph.graph import StateGraph, START, END from langgraph.graph.message import add_messages class AgentState(TypedDict): messages: Annotated[list, add_messages] remaining_steps: int # 剩余最大步數 def call_model(state: AgentState): # 這里調用你的 LLM并將結果追加到 messages # response llm.invoke(state[messages]) return {messages: [response], remaining_steps: state[remaining_steps] - 1} def call_tool(state: AgentState): # 解析最后一條消息里的 tool_calls逐個執(zhí)行工具 # tool_outputs [execute_tool(tc) for tc in tool_calls] return {messages: tool_outputs} def should_continue(state: AgentState): if state[remaining_steps] 0: return end last_message state[messages][-1] if last_message.tool_calls: return tools return end graph StateGraph(AgentState) graph.add_node(model, call_model) graph.add_node(tools, call_tool) graph.add_edge(START, model) graph.add_conditional_edges( model, should_continue, {tools: tools, end: END} # 判斷是否進入工具節(jié)點或直接結束 ) graph.add_edge(tools, model) # 工具執(zhí)行完回到模型形成循環(huán)這段代碼的核心在最后一行graph.add_edge(tools, model)。它把“工具調用”和“模型推理”連成了環(huán)。should_continue是這個環(huán)的閘門決定是繼續(xù)繞圈還是從 END 出去。你注意一下remaining_steps這個字段。它是我在每個節(jié)點里手動遞減的“剩余步數計數器”相當于把 AgentExecutor 的max_iterations從“外部保護性參數”變成了“狀態(tài)的一部分”。這個區(qū)別非常關鍵因為你可以在任何節(jié)點里讀取它、修改它甚至根據它做不同的流轉判斷。2.3 顯式循環(huán)帶來的三個優(yōu)化空間把循環(huán)攤開之后我看到了三個 AgentExecutor 時代壓根不存在的優(yōu)化空間。第一個是循環(huán)體可插樁。我可以在任意兩個節(jié)點之間加一個新節(jié)點。工具調用失敗加一個retry節(jié)點。需要人工審核加一個human_confirm節(jié)點。這些在 AgentExecutor 里幾乎不可能優(yōu)雅實現的操作在 LangGraph 里只是加節(jié)點和改邊的連線工作量極小。第二個是狀態(tài)全局可見。AgentState像一個共享的內存區(qū)所有節(jié)點都能讀寫。我想知道“這個循環(huán)已經跑了多少輪”不再需要解析文本我想知道“上一輪工具返回了什么”直接從 state 里取。這種可觀測性讓“讓 Agent 自己決定何時停止”變成了“業(yè)務代碼可以精準控制何時停止”可控性完全不同。第三個是循環(huán)可以被持久化。LangGraph 的 State 可以配合 checkpointer 做快照循環(huán)跑到一半可以停下來把狀態(tài)存進數據庫下次從斷點繼續(xù)。這個能力對長任務、人工介入、失敗恢復都很有價值后面我會專門講。3. 實戰(zhàn)改造三個切入點讓 Agent 工作流“可管可控”3.1 切入點一把狀態(tài)從 Prompt 字符串里搬進 State 對象我的第一個改造是把“隱式狀態(tài)”變成“顯式狀態(tài)”。改造前Agent 的所有歷史記錄都靠 messages 數組傳遞業(yè)務字段比如當前用戶 ID、查到的訂單號全部混在 tool 的輸出文本里后續(xù)節(jié)點要用只能靠字符串解析。改造后我在AgentState里加業(yè)務字段class OrderAgentState(TypedDict): messages: Annotated[list, add_messages] user_id: str order_id: str order_status: str remaining_steps: int need_human_confirm: booluser_id、order_id這些字段在工具節(jié)點執(zhí)行時直接寫入。比如查詢訂單的工具節(jié)點def query_order_node(state: OrderAgentState): if not state.get(user_id): return {messages: [tool_error_msg(缺少用戶ID)]} order_info order_service.query_latest(state[user_id]) return { order_id: order_info[id], order_status: order_info[status], messages: [tool_message(str(order_info))], }這個改造帶來的直接收益是后續(xù)節(jié)點不用再讀長文本猜業(yè)務數據了。條件判斷、日志記錄、異常處理全部基于結構化字段代碼可讀性提升一大截而且不會再出現“正則沒匹配上導致流程走錯分支”的經典事故。有一點要提醒messages字段我用了add_messages這個 reducer它的作用是把新消息追加到列表尾部而不是覆蓋。其他業(yè)務字段默認是“覆蓋”語義節(jié)點返回什么就存什么。如果你的業(yè)務字段需要累加或合并得自定義 reducer這是 LangGraph 狀態(tài)管理里最容易踩的坑。3.2 切入點二給循環(huán)裝“閘門”控制退出時機第二個改造是給循環(huán)裝上多層閘門。AgentExecutor 時代只有max_iterations一道閘現在我把退出條件拆成了三個層次第一層是任務完成閘LLM 最后的回復里沒有 tool_calls說明它認為任務已經完成正常從 END 退出。這相當于 ReAct 里的 Final Answer。第二層是步數上限閘remaining_steps遞減到 0強制從循環(huán)里出來走降級分支。第三層是安全條件閘比如工具連續(xù)失敗兩次、或者檢測到同一工具被重復調用三次直接走人工接管。這一層是自定義的完全取決于你的業(yè)務規(guī)則。def should_continue(state: OrderAgentState): last_message state[messages][-1] # 安全條件閘連續(xù)失敗達到閾值 if state.get(consecutive_failures, 0) 2: return human_fallback # 任務完成閘 if not last_message.tool_calls: return end # 步數上限閘 if state[remaining_steps] 0: return human_fallback return tools注意這里的邊界情況當remaining_steps已經為 0 但 LLM 還在請求調用工具時說明任務尚未完成此時一定要走降級而不是簡單地把工具執(zhí)行完。我在早期版本犯過這個錯誤導致步數上限形同虛設循環(huán)體總要等到“工具跑完、模型再判斷一次”才退出白白多燒兩輪 Token。這個“閘門”設計是循環(huán)優(yōu)化的核心收益循環(huán)的終止不再是一件被動等待 LLM 決定的事而是一條條清晰可控的規(guī)則。規(guī)則越細工作流越穩(wěn)。3.3 切入點三在循環(huán)中間插入人工確認節(jié)點第三個改造解決了我最頭疼的需求——高風險操作前的人工確認。在 AgentExecutor 里我曾經用“外部標志位 sleep 輪詢”的方式模擬確認難受得不行。LangGraph 的 Interrupt 機制讓這件事變得非常自然。實現思路是在tool節(jié)點執(zhí)行高風險工具之前先進入一個human_confirm節(jié)點在這個節(jié)點里中斷圖的執(zhí)行等人工輸入再繼續(xù)from langgraph.types import interrupt, Command def human_confirm(state: OrderAgentState): # 中斷執(zhí)行把確認請求拋給外部 decision interrupt({ type: confirm, message: f用戶要求退款訂單號{state[order_id]}, options: [approve, reject], }) if decision approve: return {need_human_confirm: False} return {need_human_confirm: True, messages: [tool_message(人工拒絕了該操作)]}配合 checkpointer 使用圖執(zhí)行到這里會暫停把當前狀態(tài)持久化。外部通過 API 讀取待確認的請求用戶在后臺點擊“通過”或“拒絕”然后從斷點恢復執(zhí)行狀態(tài)不會丟循環(huán)會從human_confirm節(jié)點繼續(xù)往下走。這個能力放在 AgentExecutor 時代就是天方夜譚。我實測下來人工確認節(jié)點的引入沒有破壞循環(huán)的完整性因為它的本質只是在環(huán)路中間插入了一個“等待外部信號再繼續(xù)”的門。而且這個等待是可以持久化的服務重啟也不怕狀態(tài)還在數據庫里。4. 循環(huán)機制還能這么用重試、恢復與并行分支4.1 工具失敗閉環(huán)重試選第三個優(yōu)化做完后我開始嘗試一些更進階的循環(huán)玩法。第一個是工具失敗的閉環(huán)重試。AgentExecutor 的默認行為是“失敗信息丟給 LLM 自己看著辦”這在很多場景下其實挺浪費。比如某個第三方 API 偶發(fā)超時重試一次就能成功但 LLM 看到超時錯誤后可能會選擇“建議用戶稍后再試”任務直接提前結束。我想做的是在工具節(jié)點內部主動重試一次失敗后再把錯誤信息交給 LLM 判斷。def call_tool_with_retry(state: OrderAgentState): last_message state[messages][-1] results [] for tool_call in last_message.tool_calls: for attempt in range(2): # 默認重試一次 try: result execute_tool(tool_call) break except ToolTimeoutError as e: if attempt 1: state[consecutive_failures] state.get(consecutive_failures, 0) 1 result f工具執(zhí)行失敗{e} else: time.sleep(0.5) # 短暫間隔再試 results.append(ToolMessage(contentstr(result), tool_call_idtool_call[id])) return {messages: results}這個重試邏輯放在循環(huán)節(jié)點內部整個工作流的對外表現就是“工具調用更穩(wěn)定了”而 LLM 完全感知不到。對比之前“讓 LLM 決定是否重試”的方式這種硬編碼重試顯然更省 Token也更快。有一點務必注意重試只適合冪等操作。如果你調用的是“創(chuàng)建訂單”“扣款”這類非冪等接口重試前必須確保接口本身支持冪等鍵否則可能造成重復扣款。這個和 LangGraph 沒關系是工程通用原則但放在循環(huán)里特別容易被忽略。4.2 會話中斷與恢復讓 Agent“記住”上次跑到哪LangGraph 的循環(huán)機制配合 checkpointer能實現一個對我很有用的能力工作流中途掛起下次從斷點繼續(xù)。這和人工確認節(jié)點其實是一套東西但應用場景更廣。我這里分享一個實際案例。我們有一個“月度數據報表生成”的 Agent需要調十幾個接口拉數據跑一輪要一兩分鐘。以前用 AgentExecutor如果中途網絡斷了或服務重啟整個任務從頭再來費時費錢。改造成 LangGraph 后我把每個數據拉取都做成一個節(jié)點整張圖跑在 checkpointer 之上。中途掛了恢復時只需要重新觸發(fā)執(zhí)行LangGraph 會自動從最后一個完成節(jié)點繼續(xù)已經拉到的數據都在 State 里。from langgraph.checkpoint.memory import MemorySaver checkpointer MemorySaver() graph graph.compile(checkpointercheckpointer) # 第一次觸發(fā) config {configurable: {thread_id: report-task-001}} result graph.invoke(initial_state, config) # 服務重啟后從斷點恢復 result graph.invoke(None, config)這里的thread_id是恢復的鑰匙。同一個thread_id的執(zhí)行歷史會被 checkpointer 保留恢復時 LangGraph 會加載最新快照。注意生產環(huán)境別用MemorySaver它只是內存存儲進程一重啟就沒了換用SqliteSaver或者 Postgres checkpointer 才能做到持久化。4.3 并行循環(huán)與結果匯合用 LangGraph 優(yōu)化工作流還能享受到一個 AgentExecutor 完全不具備的能力多分支并行。比如用戶問“對比一下 A 和 B 兩個商品的評價”傳統(tǒng) ReAct 只能串行地先查 A 再查 B或者靠 LLM 自己在一個工具里做LangGraph 可以在一個節(jié)點后裂變成兩個并行分支分別查詢最后在匯總節(jié)點匯合。實現上并不復雜本質是“一個節(jié)點連多條邊多個分支指向匯合節(jié)點”LangGraph 的 State 天然支持這種 fan-out/fan-in 模式。只要 State 里的字段 reducer 定義得當比如用add_messages合并消息列表并行分支的結果就會自動聚合到匯合節(jié)點。我在這塊踩過一個不算小的坑并行分支共享同一個 State 時如果兩個分支同時寫同一個業(yè)務字段后寫入的會覆蓋先寫入的。比如分支 1 寫入order_id A分支 2 寫入order_id B最終 State 里只會留B。解決方案是給這兩個分支分別定義狀態(tài)字段或者用列表類型的 reducer 把每個分支的結果都保存下來。并行不是免費的你得先想清楚狀態(tài)合并策略。5. 改造前后實測對比與我的踩坑記錄5.1 改造前后一組真實數據我把自己維護的“訂單助手”做了遷移改造對比了改造前后一周的線上數據同業(yè)務、同模型、相近流量。結論是收益非常直觀指標AgentExecutor 改造前LangGraph 改造后單次會話平均 Token 消耗約 5200約 3100平均響應時間8.2 秒5.4 秒工具調用失敗死循環(huán)發(fā)生率約 6.3%0.4%人工確認接入成本無法實現外部 hack原生支持接入工作量 1 天中間狀態(tài)可觀測性正則解析文本結構化字段直接讀取Token 消耗下降 40% 的主要原因就一個Agent 不會再有意識地重復調用剛查過的數據。因為我把“查用戶”“查訂單”“查物流”的中間結果都寫進了顯式 State后續(xù)節(jié)點可以直接讀取LLM 不需要通過再調一次工具來“回憶”數據。循環(huán)還是那個循環(huán)但每一輪的信息增量變大了無效輪次自然就少了。死循環(huán)發(fā)生率從 6.3% 降到 0.4%主要歸功于三重退出閘門。即使 LLM 連續(xù)生成非法 tool_calls最多跑 5 輪就會強制進入降級分支不會再無限空轉。5.2 五個值得記錄的坑這輪改造讓我對 LangGraph 有了不少新的認知說幾個典型的坑。第一個坑是reducer 的覆蓋語義。LangGraph 的普通狀態(tài)字段默認是覆蓋的兩個并行節(jié)點同時寫同一個字段時就會相互覆蓋我當時排查了很久才發(fā)現是并行分支共享字段導致的。建議所有跨節(jié)點共享的數據字段都明確設計 reducer不要依賴“恰好只有一個節(jié)點會寫它”的僥幸。第二個坑是遞歸深度限制。LangGraph 的循環(huán)是基于“不斷把新節(jié)點追加到執(zhí)行?！睂崿F的循環(huán)次數多了會觸發(fā) Python 的遞歸限制RecursionError。雖然 LangGraph 有自己的 recursion limit 配置但如果你在循環(huán)體里又嵌套了其他循環(huán)這個限制很容易被觸達。解決辦法是在狀態(tài)里維護顯式步數計數器并在條件邊上做好上限判斷。第三個坑是checkpointer 忘記配置導致斷點失效。我用graph.compile()時一度忘記傳 checkpointer結果interrupt()直接拋錯報錯信息還特別繞。后來才意識到 interrupt 機制強依賴 checkpointer沒有持久化層就沒法“暫停并等待恢復”。第四個坑是ToolMessage 的 tool_call_id 必須對上。在循環(huán)里工具節(jié)點返回的ToolMessage必須攜帶正確tool_call_id否則 LLM 會分不清這條結果對應的是哪個工具調用。這個在 AgentExecutor 里不太有感知但在 LangGraph 這種顯式循環(huán)里id 對不上會導致模型推理混亂。第五個坑是別把所有邏輯都塞進一個巨型節(jié)點。LanGraph 的優(yōu)勢在于“細粒度節(jié)點 條件邊”但我見過同事把原來 AgentExecutor 的一大段邏輯原封不動塞進一個節(jié)點圖是畫出來了優(yōu)化空間卻一點沒獲得。循環(huán)優(yōu)化的前提是節(jié)點足夠細細到你可以在關鍵路徑上插樁、分流、改造。5.3 什么時候別上 LangGraph聊完了好處也得說句公道話。LangGraph 不是銀彈如果你的 Agent 工作流就是“調用一次工具拿到結果就結束”或者最多串行跑三步以內那用 AgentExecutor 甚至直接 LangChain 鏈式調用反而更輕。LangGraph 的圖編排會帶來額外的概念負擔、狀態(tài)設計成本和調試復雜度沒必要為一個簡單任務引入全套機制。我的個人判斷標準很簡單當你的 Agent 開始頻繁出現多輪工具調用、會有中間失敗需要重試、需要人工介入、或者想對執(zhí)行過程做審計追蹤時LangGraph 的循環(huán)機制就值回學習成本了。一旦過了這個閾值它的收益會隨著工作流復雜度指數級上升。另外有個經常被問的問題底層大模型換了一代又一代這類編排框架會不會過時我的看法是模型決定 Agent 的“智商”編排框架決定 Agent 的“紀律”。你可以在 AgentExecutor 里塞一個大模型 param但流程的穩(wěn)定性、可恢復性、人工協(xié)作能力永遠來自框架。底模再聰明也繞不開“運行狀態(tài)可靠、失敗可恢復、過程可觀測”這些工程要求而這正是 LangGraph 這類框架的價值所在。從這輪實踐來看我最終的體會是循環(huán)機制的核心價值不在“省一次調用”或者“快零點幾秒”而在于它把 Agent 從“黑盒魔法”變成了“可手術的工程系統(tǒng)”。你自己掌握循環(huán)的閘門中斷它、恢復它、插樁它才算是真正把 Agent 工作流握在了手里。如果你現在正被 LangChain Agent 的不可控性折磨我建議你動手把現有的 AgentExecutor 畫成一張圖看看哪些環(huán)是你從來沒控制過的。你會發(fā)現優(yōu)化空間比自己想象的大得多。