前言很多技術(shù)文章會直接說Agent就是用工作流編排大模型。不少開發(fā)者會產(chǎn)生誤解工作流是AI Agent獨(dú)有的技術(shù)。但實(shí)際上工作流、狀態(tài)機(jī)、流程引擎在傳統(tǒng)業(yè)務(wù)系統(tǒng)早已大規(guī)模落地OA審批、訂單流轉(zhuǎn)、售后工單都是典型工作流。LangGraph這類Agent框架底層本質(zhì)依舊是狀態(tài)機(jī)技術(shù)同源但解決的核心矛盾、風(fēng)險點(diǎn)、設(shè)計目標(biāo)完全不一樣。大量資料把普通業(yè)務(wù)工作流和LLM Agent工作流混為一談導(dǎo)致開發(fā)者對Agent特有的State狀態(tài)污染、提示注入繞過流程、死循環(huán)風(fēng)險理解不到位。本文對比傳統(tǒng)業(yè)務(wù)工作流與Agent工作流厘清拓?fù)浣Y(jié)構(gòu)、運(yùn)行時路徑、條件分支的本質(zhì)差異同時給出生產(chǎn)環(huán)境安全最佳實(shí)踐。一、普通業(yè)務(wù)系統(tǒng)工作流OA/訂單狀態(tài)機(jī)代表場景訂單狀態(tài)流轉(zhuǎn)、企業(yè)審批流。核心特點(diǎn)1. 輸入、規(guī)則全部由開發(fā)者預(yù)先寫死流轉(zhuǎn)邏輯、分支條件全部硬編碼每一步去往哪個節(jié)點(diǎn)由程序賦值的結(jié)構(gòu)化狀態(tài)字段驅(qū)動。示例流轉(zhuǎn)待付款 → 已付款 → 已發(fā)貨 → 已完成提交申請 → 經(jīng)理審批 → 總監(jiān)審批 → 通過/駁回分支判斷示例if(status PAID){...}全部為業(yè)務(wù)代碼。狀態(tài)字段由程序賦值外部輸入無法直接修改狀態(tài)控制流程跳轉(zhuǎn)。2. 不確定性極少異常來源大多是網(wǎng)絡(luò)異常、數(shù)據(jù)庫異常等系統(tǒng)層面故障業(yè)務(wù)流轉(zhuǎn)路徑是可窮舉的。3. 核心目標(biāo)編排已經(jīng)寫好的業(yè)務(wù)步驟負(fù)責(zé)狀態(tài)持久化、事務(wù)回滾、任務(wù)重試執(zhí)行人類預(yù)先定義完備的業(yè)務(wù)邏輯。簡單概括規(guī)則人寫死引擎只負(fù)責(zé)執(zhí)行。二、LLM Agent工作流LangGraph StateGraph底層依舊是狀態(tài)機(jī)工作流引擎但是引入了一個不可控的參與者LLM大模型黑盒。AI工作流的本質(zhì)給不可控的大模型行為套上籠子實(shí)現(xiàn)動態(tài)決策、自我修正、強(qiáng)制收斂。Agent工作流獨(dú)有的痛點(diǎn)傳統(tǒng)業(yè)務(wù)幾乎遇不到1. LLM輸出不穩(wěn)定需要運(yùn)行時循環(huán)自我修正大模型會幻覺、回答不全、輸出錯誤。業(yè)務(wù)期望調(diào)用工具補(bǔ)全信息 → 重新生成內(nèi)容 → 審核校驗(yàn) → 不合格就修訂循環(huán)迭代直到輸出合格結(jié)果。傳統(tǒng)業(yè)務(wù)代碼出錯屬于Bug需要修改代碼修復(fù)不會在運(yùn)行時自動循環(huán)修正自身輸出。2. 部分決策邏輯交給LLM不再全部硬編碼傳統(tǒng)工作流所有if分支全部寫死在代碼Agent工作流支持把分支判斷交給大模型輸出結(jié)果驅(qū)動。風(fēng)險隨之而來State狀態(tài)不再只有業(yè)務(wù)代碼可以寫入LLM也可以寫入狀態(tài)字段由此誕生Agent特有漏洞狀態(tài)污染提示注入繞過流程節(jié)點(diǎn)。傳統(tǒng)業(yè)務(wù)工作流不會把狀態(tài)寫權(quán)限交給黑盒外部組件幾乎不存在這類安全問題。3. 運(yùn)行路徑無法預(yù)先完全枚舉循環(huán)次數(shù)未知OA審批流程路徑固定可數(shù)但是用戶提問千變?nèi)f化有的問題直接回答有的需要搜索有的需要多輪修訂。編碼階段無法預(yù)知會循環(huán)多少次框架必須提供最大輪次保護(hù)防止LLM邏輯異常造成死循環(huán)。4. 混合編排代碼節(jié)點(diǎn) LLM節(jié)點(diǎn)共存代碼節(jié)點(diǎn)Java實(shí)現(xiàn)工具調(diào)用、數(shù)據(jù)庫讀寫、業(yè)務(wù)計算LLM節(jié)點(diǎn)大模型生成、模型判斷工作流統(tǒng)一處理兩類節(jié)點(diǎn)異常捕獲、退避重試、狀態(tài)持久化、斷點(diǎn)恢復(fù)。三、誤區(qū)澄清為什么AI Agent需要工作流?錯誤觀點(diǎn)工作流是AI專屬技術(shù)。?正確觀點(diǎn)普通業(yè)務(wù)系統(tǒng)早已廣泛使用工作流/狀態(tài)機(jī)。但是LLM輸出不確定、存在幻覺、部分決策由模型輸出驅(qū)動給AI系統(tǒng)帶來額外剛需循環(huán)迭代修正、動態(tài)條件分支、最大輪次防死循環(huán)、狀態(tài)隔離校驗(yàn)、失敗重試、斷點(diǎn)續(xù)跑。僅靠普通順序代碼 if?else 手寫循環(huán)很難妥善處理LLM帶來的不確定性。反例不使用LangGraph手寫Java實(shí)現(xiàn)修訂循環(huán)// 偽代碼手寫Agent revise?review循環(huán)String answer llm.generate(query);for(int i 0; i MAX_ROUND; i){boolean pass llm.review(answer);if(pass) break;answer llm.revise(answer);}return answer;看起來實(shí)現(xiàn)了修訂循環(huán)但工程上坑非常多需要自行實(shí)現(xiàn)中間狀態(tài)持久化服務(wù)中斷之后無法斷點(diǎn)恢復(fù)LLM調(diào)用的超時、限流退避、異常重試全部自己封裝業(yè)務(wù)復(fù)雜之后多層嵌套循環(huán)代碼迅速臃腫難以維護(hù)安全風(fēng)險循環(huán)判斷flag由LLM輸出控制極易被Prompt注入直接break跳過審核邏輯手寫很難實(shí)現(xiàn)每一條分支出口的白名單校驗(yàn)。LangGraph這類框架就是標(biāo)準(zhǔn)化解決上述通用問題狀態(tài)持久化、條件邊、分支校驗(yàn)、最大輪次限制、節(jié)點(diǎn)重試、斷點(diǎn)續(xù)跑。四、關(guān)鍵概念區(qū)分圖拓?fù)浣Y(jié)構(gòu) VS 運(yùn)行時執(zhí)行路徑很多開發(fā)者混淆這兩個概念這是理解Agent不確定性的核心。對象是否確定說明工作流圖拓?fù)涔?jié)點(diǎn)、邊、跳轉(zhuǎn)目標(biāo)?完全確定代碼定義死有哪些節(jié)點(diǎn)、循環(huán)跳轉(zhuǎn)到哪個目標(biāo)節(jié)點(diǎn)運(yùn)行時不會新增節(jié)點(diǎn)運(yùn)行時行為是否走循環(huán)、循環(huán)多少次、選擇哪條分支?不確定由LLM運(yùn)行時輸出決定舉個例子定義拓?fù)鋑enerate → reviewreview條件邊不通過跳回revise修訂節(jié)點(diǎn)通過直接結(jié)束。拓?fù)涫菍懰赖牟煌ㄟ^就必須回到revise跳轉(zhuǎn)目標(biāo)固定。但是運(yùn)行時用戶問題簡單review一次直接結(jié)束模型幻覺嚴(yán)重revise?review來回循環(huán)3次問題極難循環(huán)觸達(dá)最大輪次閾值強(qiáng)制退出。Agent不是無約束自由跳轉(zhuǎn)流轉(zhuǎn)被鎖死在預(yù)先定義好的圖拓?fù)渲畠?nèi)不確定性體現(xiàn)在在允許的路徑集合里由LLM動態(tài)選擇走哪條分支、循環(huán)多少輪。和普通while循環(huán)本質(zhì)區(qū)別普通Java while/for循環(huán)也可以做到不確定循環(huán)次數(shù)。核心差異不在于循環(huán)語法本身而在于條件判斷的數(shù)據(jù)來源。1. 普通業(yè)務(wù)循環(huán)條件來源于業(yè)務(wù)代碼計算boolean ok codeCheck(answer); // 純業(yè)務(wù)代碼邏輯不受黑盒輸入污染while(!ok){ ... }判斷邏輯完全可控不存在幻覺、提示注入風(fēng)險。2. Agent典型循環(huán)條件判斷來自LLM黑盒輸出boolean ok llmJudgeReview(answer); // 判斷結(jié)果來自大模型輸出while(!ok){ ... }LLM是不可控黑盒會幻覺、會被提示注入篡改判斷結(jié)果甚至篡改State路由字段繞過關(guān)鍵節(jié)點(diǎn)。因此框架必須配套最大輪次防死循環(huán)、狀態(tài)路由白名單校驗(yàn)、LLM調(diào)用重試。五、LangGraph條件邊兩種模式LLM判斷 vs 純代碼判斷addConditionalEdges是LangGraph實(shí)現(xiàn)分支跳轉(zhuǎn)的核心API框架本身不強(qiáng)制使用LLM做判斷兩種模式可以獨(dú)立使用也可以混合。模式1交給LLM做條件判斷典型Agent場景帶來安全風(fēng)險條件邊內(nèi)部調(diào)用大模型由模型輸出決定下一個節(jié)點(diǎn)。workflow.addConditionalEdges(review,edge_async(state - {// 條件判斷交給LLM黑盒String llmJudge llm.call(state.get(answer));if (不通過.equals(llmJudge)){return revise;}else{return end;}}),Map.of(revise,revise, end, END));風(fēng)險點(diǎn)LLM幻覺輸出錯誤判斷Prompt注入場景模型輸出偽造結(jié)果跳過審核直接結(jié)束流程若設(shè)計為LLM直接把next_node寫入State風(fēng)險會進(jìn)一步放大。模式2純Java代碼做條件判斷等價傳統(tǒng)業(yè)務(wù)狀態(tài)機(jī)條件邊完全不調(diào)用大模型全部邏輯手寫代碼沒有Agent特有安全漏洞。workflow.addConditionalEdges(review,edge_async(state - {// 純Java業(yè)務(wù)邏輯無任何LLM調(diào)用int errorCount state.value(error_count).orElse(0);if(errorCount 3){return end;}else{return revise;}}),Map.of(revise,revise, end, END));模式3生產(chǎn)常用混合模式LLM做業(yè)務(wù)判斷代碼做安全兜底LLM負(fù)責(zé)業(yè)務(wù)語義層面判斷Java代碼負(fù)責(zé)強(qiáng)制約束、安全兜底這是生產(chǎn)環(huán)境推薦寫法。workflow.addConditionalEdges(review,edge_async(state - {// 1. LLM輸出業(yè)務(wù)標(biāo)記Boolean llmNeedRevise llm.judge(state);// 2. Java強(qiáng)制兜底最大循環(huán)輪次防止死循環(huán)int round state.value(round).orElse(0);if(round 5){return end;}if(llmNeedRevise){return revise;}else {return end;}}),Map.of(revise,revise, end, END));六、生產(chǎn)安全最佳實(shí)踐規(guī)避State狀態(tài)污染風(fēng)險根源LangGraph本身框架不帶安全漏洞風(fēng)險來自我們把路由判斷權(quán)力交給LLM黑盒。?禁止讓LLM直接輸出節(jié)點(diǎn)ID(next_node)寫入State狀態(tài)條件邊讀取該字段直接跳轉(zhuǎn)。?推薦LLM只輸出業(yè)務(wù)語義標(biāo)記例如need_revise:true/false路由跳轉(zhuǎn)決策邏輯保留在Java代碼層。?Java層增加多重防護(hù)最大循環(huán)輪次強(qiáng)制限制杜絕LLM異常導(dǎo)致死循環(huán)對讀取到的路由標(biāo)記做白名單校驗(yàn)只允許配置內(nèi)的節(jié)點(diǎn)跳轉(zhuǎn)State字段做權(quán)限隔離區(qū)分「LLM可寫入字段」和「代碼獨(dú)占的路由控制字段」敏感路由字段不開放給LLM寫入。條件分支優(yōu)先代碼兜底LLM輸出僅作為業(yè)務(wù)參考依據(jù)不要作為唯一判斷依據(jù)。七、總結(jié)普通業(yè)務(wù)工作流規(guī)則全部由人編碼定義工作流只負(fù)責(zé)執(zhí)行風(fēng)險來自系統(tǒng)故障。LLM Agent工作流底層依舊是狀態(tài)機(jī)圖拓?fù)浣Y(jié)構(gòu)確定運(yùn)行時路徑不確定工作流核心作用是約束、馴化、收斂大模型帶來的不確定性。Agent獨(dú)有的State污染、提示注入繞過流程漏洞根源不是LangGraph框架本身而是將分支判斷能力交給不可控的LLM黑盒。生產(chǎn)實(shí)踐LLM輸出業(yè)務(wù)信號代碼掌握最終路由決策權(quán)做好兜底校驗(yàn)是規(guī)避Agent流程安全問題的核心方案。