做 AI Agent 工程最尷尬的時(shí)刻不是模型能力不夠而是你發(fā)現(xiàn) Demo 五分鐘能跑通但真要把它變成一個(gè)能上線、能維護(hù)、敢交到用戶手里的系統(tǒng)橫在中間的全是選擇題。過去一年我?guī)蛨F(tuán)隊(duì)評(píng)審過不少 Agent 項(xiàng)目幾乎無一例外都卡在同一個(gè)地方大家把 Agent 當(dāng)成一個(gè)“會(huì)自己想的腳本”寫起來很爽跑起來也很驚艷一接真實(shí)業(yè)務(wù)就崩。后來我把整個(gè)思考方式拆成兩個(gè)框架先用“七要素”看清 Agent 內(nèi)部由什么組成再用“七個(gè)決策點(diǎn)”理清工程實(shí)現(xiàn)時(shí)每一步到底在選什么。這篇就把這兩個(gè)框架完整講明白——你不需要先會(huì) LangGraph 或 FastAPI只需要按這個(gè)思路走一遍就知道一個(gè)生產(chǎn)級(jí) AI Agent 是怎么從概念落成代碼的。適合正準(zhǔn)備把 Agent 搬進(jìn)業(yè)務(wù)系統(tǒng)的開發(fā)者也適合想給團(tuán)隊(duì)定技術(shù)方案但總覺得“網(wǎng)上教程太散”的架構(gòu)師。1. 七要素先把 Agent 拆開看看一臺(tái)“有手有腦”的機(jī)器怎么組成很多人描述 Agent 時(shí)喜歡說“大模型 工具 記憶”這話對(duì)但太粗了。真到了工程層面我發(fā)現(xiàn)一臺(tái)能穩(wěn)定干活的 Agent 至少要拆成七個(gè)部分缺一個(gè)后面上線就會(huì)拿命補(bǔ)。1.1 任務(wù)邊界Agent 是瑞士軍刀還是專用扳手先回答一個(gè)最土但最重要的問題這個(gè) Agent 到底負(fù)責(zé)什么不負(fù)責(zé)什么。任務(wù)邊界不是一句需求描述而是輸入輸出的嚴(yán)格契約——接受什么格式的消息產(chǎn)生什么類型的動(dòng)作哪些話題必須拒絕哪些情況必須轉(zhuǎn)人工。我見過最典型的失敗案例是有人把“智能客服”做成了“啥都能聊的機(jī)器人”結(jié)果用戶問天氣它也答問股票它也答最后答錯(cuò)一句整個(gè)產(chǎn)品的可信度就崩了。反過來說真正能落地的 Agent 往往非?！捌啤彼蛔鍪酆蠊畏诸?、只做日?qǐng)?bào)生成、只做代碼審查建議。邊界越窄行為越可預(yù)測(cè)也越好評(píng)估。1.2 模型底座LLM 是發(fā)動(dòng)機(jī)不是整輛車第二個(gè)要素是模型本身但要注意一個(gè)認(rèn)知陷阱LLM 只是發(fā)動(dòng)機(jī)Agent 是整車。發(fā)動(dòng)機(jī)決定上限但方向盤、剎車、儀表盤決定能不能上路。很多人以為“換個(gè)更強(qiáng)的大模型Agent 問題就解決了”實(shí)際不是——你缺的往往是流程控制、狀態(tài)管理、錯(cuò)誤恢復(fù)這些“車身部件”。工程上選模型要看的不是排行榜而是三個(gè)硬指標(biāo)推理能力夠不夠處理帶約束的任務(wù)、是否支持穩(wěn)定的工具調(diào)用Function Calling 或 Tool Schema、以及推理成本和延遲能不能被業(yè)務(wù)接受。同一個(gè)任務(wù)簡(jiǎn)單分類可能用小模型十幾個(gè)毫秒就出結(jié)果復(fù)雜規(guī)劃才需要大模型慢慢想這直接引出后面的“決策二”。1.3 記憶系統(tǒng)桌面干凈的人才能干好活記憶是 Agent 被討論最多、也最容易做錯(cuò)的要素。我習(xí)慣把記憶分成三層工作記憶當(dāng)前任務(wù)上下文、長(zhǎng)期記憶跨會(huì)話的歷史信息、程序記憶Prompt、工具定義、規(guī)則配置這些“肌肉記憶”。這里有一個(gè)反直覺的點(diǎn)上下文窗口不是記憶。很多新人以為窗口越大越好于是把幾十頁歷史全塞進(jìn)去結(jié)果模型注意力被沖散回答質(zhì)量反而下降token 成本還打不住。好的記憶設(shè)計(jì)是把上下文當(dāng)桌面——只放當(dāng)前這步需要的東西其他資料放文件柜向量庫、Redis、數(shù)據(jù)庫隨用隨取用完歸檔。1.4 工具調(diào)用手伸得太長(zhǎng)就容易拿錯(cuò)東西工具是 Agent 的“手”和“腳”。一個(gè)客服 Agent 要能查訂單、改地址、發(fā)起退款一個(gè)數(shù)據(jù)分析 Agent 要能查庫、跑 Python、畫圖。但工具不是越多越好——模型每多一個(gè)工具可選選錯(cuò)工具的概率就高一分。工程上每個(gè)工具要定義清楚三件事名字動(dòng)詞 名詞如query_order、參數(shù) Schema嚴(yán)格 JSON別用自然語言描述參數(shù)、以及描述說明這個(gè)工具是干嘛的、什么時(shí)候該用、有沒有副作用。這跟給人寫工作手冊(cè)一個(gè)道理寫得越明白越少出岔子。1.5 規(guī)劃?rùn)C(jī)制先摳 GPS 還是走一步問一步規(guī)劃?rùn)C(jī)制決定 Agent 怎么從“用戶說了一句話”走到“完成一個(gè)多步任務(wù)”。目前主流就兩派一派是走一步看一步的 ReAct推理 行動(dòng)交替循環(huán)適合開放探索型任務(wù)比如“幫我研究一下這個(gè)競(jìng)品”另一派是 Plan-and-Execute先定計(jì)劃再執(zhí)行適合目標(biāo)清晰、步驟可拆的任務(wù)比如“對(duì)所有待處理工單做分類并生成報(bào)表”。生產(chǎn)環(huán)境里我見得最多的其實(shí)是第三種固定管線 局部決策也就是預(yù)先畫好流程圖每個(gè)節(jié)點(diǎn)內(nèi)部讓模型做選擇題而不是讓它自由發(fā)揮。原因后面講決策五的時(shí)候細(xì)說總之你先記住規(guī)劃?rùn)C(jī)制越自由系統(tǒng)越不可控調(diào)試成本越高。1.6 執(zhí)行狀態(tài)能停、能續(xù)、能交給人的流程才敢上線腳本是一次性從第一行跑到最后一行而 Agent 是一個(gè)長(zhǎng)時(shí)間、多步驟、隨時(shí)可能出錯(cuò)的流程。執(zhí)行狀態(tài)要素想解決的是任務(wù)跑到一半比如第三步調(diào)外部 API 超時(shí)了系統(tǒng)能不能停下來、報(bào)個(gè)錯(cuò)、重試一次或者把控制權(quán)交給人類審核再繼續(xù)。我實(shí)踐中強(qiáng)烈建議用顯式狀態(tài)圖來管理 Agent 流程LangGraph 就是這么干的而不是把流程邏輯寫在自然語言 Prompt 里讓模型“自覺遵守”。代碼層面的狀態(tài)機(jī)看得見、摸得著、能測(cè)試Prompt 里的“請(qǐng)按步驟執(zhí)行”則完全無法保證。StateGraph節(jié)點(diǎn)之間怎么跳、什么條件下跳、跳不過去怎么辦都要是顯式的、可回放的條件分支。1.7 觀測(cè)與評(píng)估沒有尺子就沒有優(yōu)化最后一個(gè)要素最容易被忽略卻是生產(chǎn)環(huán)境的生命線。LLM 的輸出有概率性同一個(gè)輸入換一次調(diào)用可能得到不同結(jié)果這意味著你無法用“這次跑通了”來證明系統(tǒng)是好的。必須有結(jié)構(gòu)化的 Trace 日志、細(xì)粒度的評(píng)估集和護(hù)欄規(guī)則才能回答三個(gè)問題這次回答質(zhì)量好不好、花多少錢、慢不慢。做不了觀測(cè)評(píng)估的 Agent 就像不帶儀表盤開車——你敢開上路但出了問題永遠(yuǎn)不知道是發(fā)動(dòng)機(jī)、油門還是路況的責(zé)任。具體怎么做后面“決策七”展開。2. 從要素到?jīng)Q策工程實(shí)現(xiàn)就是一連串取舍2.1 Demo 與生產(chǎn)之間隔著七個(gè)選擇把七要素記在腦子里之后再看“工程實(shí)現(xiàn)”這四個(gè)字就會(huì)覺得清晰很多工程實(shí)現(xiàn)不是一個(gè)動(dòng)作而是一連串取舍。Demo 只需要把七要素搓成一條能跑通的路生產(chǎn)系統(tǒng)則要求在每一個(gè)岔路口都選對(duì)——因?yàn)樯暇€之后你沒法靠“重啟一下”來修 Agent。我把這些岔路口總結(jié)成七個(gè)決策點(diǎn)每個(gè)決策點(diǎn)都對(duì)應(yīng)前面的一個(gè)要素。它們不是按時(shí)間順序逐個(gè)完成而是互相影響、成組出現(xiàn)。比如你選定了多 Agent 架構(gòu)模型、工具、狀態(tài)的設(shè)計(jì)全部要跟著變你選了長(zhǎng)流程規(guī)劃記憶策略就要重新考慮。2.2 七個(gè)要素對(duì)應(yīng)的七個(gè)決策點(diǎn)總覽先把整套對(duì)應(yīng)關(guān)系放在一張表里后面逐個(gè)展開七要素對(duì)應(yīng)決策點(diǎn)核心矛盾任務(wù)邊界決策一單 Agent 還是多 Agent智能化上限 vs 可控性模型底座決策二一個(gè)模型還是大小模型配合效果質(zhì)量 vs 成本延遲記憶系統(tǒng)決策三上下文放多少、倉庫存什么信息完整 vs 噪音成本工具調(diào)用決策四開放多少工具、每個(gè)怎么定義能力強(qiáng) vs 容易選錯(cuò)規(guī)劃?rùn)C(jī)制決策五固定流程還是自由推理確定性 vs 靈活性執(zhí)行狀態(tài)決策六狀態(tài)建模與人工介入點(diǎn)自動(dòng)化 vs 風(fēng)險(xiǎn)控制觀測(cè)評(píng)估決策七上線標(biāo)準(zhǔn)與持續(xù)觀測(cè)迭代速度 vs 系統(tǒng)穩(wěn)定這張表是這套框架的核心。你拿著它去套任何 Agent 項(xiàng)目都能快速定位問題出在哪個(gè)環(huán)節(jié)——是邊界沒定清楚還是工具定義太含糊還是評(píng)估手段缺失。下面我把七個(gè)決策點(diǎn)分別拆開講重點(diǎn)說每一條背后的代價(jià)。3. 前四個(gè)決策點(diǎn)邊界、模型、記憶、工具3.1 決策一這個(gè) Agent 管多寬單 Agent 還是多 Agent第一個(gè)決策也是整個(gè)系統(tǒng)的地基到底做一個(gè)什么邊界的 Agent需不需要拆成多個(gè) Agent。先說結(jié)論傾向能單 Agent 解決的就不要拆多 Agent。多 Agent 看似各司其職很“高級(jí)”實(shí)際上引入了三大麻煩一是通信成本Agent 之間用自然語言傳遞信息信息一定會(huì)失真二是調(diào)試難度出了問題你分不清是哪個(gè) Agent 的鍋三是資源開銷每個(gè) Agent 都要消費(fèi)模型調(diào)用成本線性翻倍。單 Agent 的能力邊界卡在哪里卡在單次任務(wù)復(fù)雜度。如果任務(wù)鏈路超過七八步或者需要同時(shí)維護(hù)多套上下文單 Agent 的上下文就會(huì)很擠。這時(shí)候我建議的拆法不是“按功能拆”而是“按責(zé)任拆”——比如一個(gè)負(fù)責(zé)理解分類一個(gè)負(fù)責(zé)執(zhí)行操作中間通過結(jié)構(gòu)化數(shù)據(jù)傳消息而不是靠文字“你一句我一句”。實(shí)操里我一般先問三個(gè)問題這個(gè)任務(wù)能不能用一個(gè)固定流程描述清楚如果必須靠模型自由推理才能完成推理鏈路有多長(zhǎng)最壞情況下需要同時(shí)記住幾份相互獨(dú)立的信息如果三個(gè)答案都偏向簡(jiǎn)單閉眼選單 Agent。3.2 決策二用什么模型要不要大模型小模型混著來第二個(gè)決策點(diǎn)最熱鬧也最容易踩坑。很多人一上來就選最強(qiáng)模型理由是“反正效果好”。但在生產(chǎn)環(huán)境“效果好”必須和“成本、延遲、合規(guī)”放在一起算賬。我的經(jīng)驗(yàn)是一個(gè)真實(shí)業(yè)務(wù)里至少有兩類任務(wù)一類是固定格式、答案明確的比如工單分類、關(guān)鍵詞抽取、意圖識(shí)別這類任務(wù)根本不需要大模型“思考”中等參數(shù)模型甚至微調(diào)后的小模型就能干又快又便宜另一類是開放式、需要推理的比如寫回復(fù)、做總結(jié)、拆解復(fù)雜指令這必須上強(qiáng)模型。于是“模型路由”方案就出現(xiàn)了入口先用一個(gè)又快又便宜的分類器判斷任務(wù)類型簡(jiǎn)單任務(wù)走小模型復(fù)雜任務(wù)才轉(zhuǎn)發(fā)給大模型。這種混合架構(gòu)能省下相當(dāng)可觀的 token 成本響應(yīng)速度也好看很多。實(shí)現(xiàn)路由的方式也不一定非得上復(fù)雜框架一個(gè) LLM 分類 if-else 就夠。另外提醒一句數(shù)據(jù)合規(guī)如果業(yè)務(wù)數(shù)據(jù)不能出內(nèi)網(wǎng)就別糾結(jié)“最強(qiáng)開源模型跑不跑得動(dòng)”了直接用可私有化部署的模型比如 Qwen 系列或者私有化 API 網(wǎng)關(guān)這比效果排行重要得多。模型這層追求的是“夠用還穩(wěn)”不是“頂配”。3.3 決策三上下文是桌面存儲(chǔ)是倉庫中間是摘要第三個(gè)決策處理記憶系統(tǒng)核心問題是哪些信息進(jìn)上下文窗口哪些進(jìn)外部存儲(chǔ)上下文被撐爆了怎么辦。先定一個(gè)原則上下文窗口里只放“當(dāng)前這一步必須看到的東西”。比如售后 Agent 在處理工單時(shí)工單編號(hào)、用戶訴求、相關(guān)訂單狀態(tài)這三樣必須在場(chǎng)但用戶三個(gè)月前的購(gòu)買記錄就不該出現(xiàn)在上下文里它應(yīng)該躺在外部存儲(chǔ)數(shù)據(jù)庫或向量庫等需要時(shí)再檢索出來。當(dāng)一段會(huì)話變得很長(zhǎng)光靠“裁掉老消息”是不夠的因?yàn)殛P(guān)鍵信息可能就藏在老消息里。我常用的套路是滾動(dòng)摘要每處理完一輪就把此前對(duì)話壓縮成一段結(jié)構(gòu)化摘要下次調(diào)用時(shí)把摘要 最近幾輪完整對(duì)話一起放進(jìn)去。這樣既保留了全局信息又控制住了 token 成本。再進(jìn)階一點(diǎn)就是分層記憶全局用戶畫像長(zhǎng)期、會(huì)話摘要中期、原始對(duì)話短期按需組裝。工程上建議把這些邏輯封裝成獨(dú)立的記憶管理模塊不要散落在 Prompt 里——Prompt 里的記憶規(guī)則模型完全是“憑感覺遵守”的模塊化代碼才是真正可控的。3.4 決策四工具是用得越多越好還是越少越好第四個(gè)決策點(diǎn)直接決定 Agent 的“行動(dòng)力”。我在 1.4 里說過工具太多會(huì)加大選錯(cuò)概率這里補(bǔ)一組實(shí)際數(shù)據(jù)感覺模型在 5 個(gè)候選工具里的選對(duì)率往往比在 20 個(gè)候選工具里的選對(duì)率高出不少——開放性候選越多推理壓力越大越容易在工具描述上產(chǎn)生語義混淆。所以工具集的設(shè)計(jì)原則是“夠用就好 語義清晰”。上線時(shí)先只給 Agent 三到五個(gè)最核心的工具跑通了再逐步加。每個(gè)工具的 Schema 要寫成可以獨(dú)立理解的小文檔做什么、什么情況下調(diào)用、參數(shù)怎么填、有沒有副作用比如“此操作不可逆”必須寫清楚。還有一個(gè)很容易被忽視的點(diǎn)工具返回結(jié)果太復(fù)雜一樣會(huì)把上下文窗口塞爆。你查一個(gè)訂單接口可能返回 200 個(gè)字段但 Agent 真正需要的只有 5 個(gè)。建議在工具內(nèi)部做裁剪和格式化返回給模型的是“精煉后的 JSON”而不是原始接口大包。這相當(dāng)于給 Agent 配一個(gè)會(huì)“先說重點(diǎn)”的助手而不是把整本說明書砸它臉上。4. 后三個(gè)決策點(diǎn)規(guī)劃、狀態(tài)、上線與評(píng)估4.1 決策五固定管線還是自由 ReAct前面說過規(guī)劃?rùn)C(jī)制三選一這里重點(diǎn)講第五個(gè)決策點(diǎn)業(yè)務(wù)里到底用固定流程還是自由推理。我的判斷標(biāo)準(zhǔn)是如果任務(wù)結(jié)果需要可預(yù)測(cè)、可解釋、可追責(zé)選固定管線如果任務(wù)本身就是開放探索型的——例如“幫我查查市場(chǎng)上還有什么競(jìng)品在做類似功能”選 ReAct 式自由規(guī)劃。排錯(cuò)類任務(wù)可以適當(dāng)讓模型在管線內(nèi)做局部選擇但全局路徑必須由流程控制。為什么這么強(qiáng)調(diào)因?yàn)樽杂?ReAct 的本質(zhì)是“每走一步都讓模型決定下一步做什么”這在一個(gè)有明確 KPI 的業(yè)務(wù)里是災(zāi)難模型可能突然去調(diào)一個(gè)無關(guān)工具可能陷入重試死循環(huán)可能在三步之后徹底忘掉用戶最初的要求。固定管線恰好把“每一步做什么”寫死在狀態(tài)圖里模型只需要在每個(gè)節(jié)點(diǎn)里做“小決策”比如這一步選哪個(gè)分支、提取哪些字段。工程實(shí)現(xiàn)上這套固定管線不要用超大 Prompt 去“感化”模型遵守要用代碼控制。LangGraph 這類狀態(tài)圖框架在這一層價(jià)值很大節(jié)點(diǎn)、邊、條件、中斷、恢復(fù)全都在代碼里明確定義模型只負(fù)責(zé)節(jié)點(diǎn)內(nèi)部的生成任務(wù)。這樣出問題你可以在圖的任一步打斷、改參數(shù)、重放而不是對(duì)著十幾輪對(duì)話找“模型哪里想歪了”。4.2 決策六狀態(tài)怎么建模失敗重試和人工審批放哪里第六個(gè)決策點(diǎn)是最容易被新手工程忽略的Agent 不是一個(gè)“一問一答”而是一個(gè)有生命周期的工作流它的狀態(tài)必須被建模、被持久化。先定一個(gè)最小狀態(tài)集任務(wù) ID、當(dāng)前節(jié)點(diǎn)、輸入快照、各節(jié)點(diǎn)輸出、錯(cuò)誤次數(shù)、審批狀態(tài)。這個(gè)狀態(tài)要存在外部存儲(chǔ)里Redis 或 Postgres而不是存在內(nèi)存變量里——道理很簡(jiǎn)單進(jìn)程一重啟、機(jī)器一掛內(nèi)存里的狀態(tài)全沒了客戶工單就丟了。然后是失敗重試策略。工具調(diào)用一定會(huì)偶發(fā)超時(shí)、返回臟數(shù)據(jù)、鑒權(quán)失敗這些都要在狀態(tài)圖里給出分支超時(shí)就重試重試兩次還不行就轉(zhuǎn)人工數(shù)據(jù)校驗(yàn)不通過就回到上一個(gè)節(jié)點(diǎn)重新抽取。重試要帶退避不要狂轟接口——很多上游系統(tǒng)對(duì)突發(fā)重試很敏感會(huì)直接限流。最關(guān)鍵的還是人工審批節(jié)點(diǎn)Human-in-the-loop。凡是涉及改數(shù)據(jù)、退款、發(fā)消息、下單這類有實(shí)際影響的操作都必須在這個(gè)操作前插入一個(gè)“待審批”狀態(tài)流程掛起等人工確認(rèn)后繼續(xù)。這個(gè)設(shè)計(jì)不只是為了合規(guī)也是給系統(tǒng)兜底——模型再怎么聰明也不能讓它直接對(duì)真實(shí)世界做不可逆操作。狀態(tài)圖框架里的interrupt能力就是干這個(gè)的用起來比你手寫隊(duì)列靠譜得多。4.3 決策七上線前怎么評(píng)估上線后怎么觀測(cè)最后一個(gè)決策點(diǎn)決定項(xiàng)目能不能“體面地活著”評(píng)估與觀測(cè)體系怎么搭。先說評(píng)估別指望“用人眼抽查幾條結(jié)果”就算評(píng)估。上線前至少要準(zhǔn)備 50~100 條帶標(biāo)注的測(cè)試用例每條用例寫明輸入、期望行為、驗(yàn)收口徑比如分類正確、回復(fù)包含退款鏈接、語氣合規(guī)。然后跑批統(tǒng)計(jì)指標(biāo)任務(wù)完成率、準(zhǔn)確率、平均工具調(diào)用次數(shù)、失敗率。沒有這組數(shù)字你根本不敢跟業(yè)務(wù)方說“可以上了”。然后是觀測(cè)。生產(chǎn)環(huán)境每跑一次 Agent都應(yīng)該留下一條完整 Trace用戶輸入、每一步調(diào)了哪個(gè)工具、工具返回了什么、模型輸出是什么、耗時(shí)多少、花了多少 token、命中哪個(gè)分支。工具上我推薦 LangSmith 或者 Langfuse 這類可觀測(cè)平臺(tái)能自動(dòng)把鏈?zhǔn)秸{(diào)用串起來出問題以后點(diǎn)開 trace 圖一眼看到哪一步歪了。最后補(bǔ)一個(gè)容易被忽略的成本問題Agent 的 token 消耗是普通 Chat 的幾倍甚至十幾倍因?yàn)橐淮稳蝿?wù)要反復(fù)調(diào)用模型。上線前你要給每個(gè)任務(wù)設(shè) token 預(yù)算上限超預(yù)算直接熔斷轉(zhuǎn)人工并且每周做一次成本復(fù)盤。評(píng)估和觀測(cè)這層做扎實(shí)了后續(xù)優(yōu)化才有依據(jù)——不然每個(gè)“靈光一閃”的優(yōu)化都在蒙著眼睛改系統(tǒng)。5. 完整推演一個(gè)售后工單 Agent 從零到上線5.1 需求背景與七要素快照為了把這七個(gè)決策點(diǎn)串起來我拿一個(gè)我們團(tuán)隊(duì)實(shí)際做過的項(xiàng)目來推演售后工單自動(dòng)處理 Agent。業(yè)務(wù)背景是一家電商公司每天幾百?gòu)埵酆蠊慰头肆Τ跃o希望讓 Agent 自動(dòng)完成“工單分類 → 查詢訂單 → 生成回復(fù)草稿 → 高風(fēng)險(xiǎn)轉(zhuǎn)人工”這一條鏈路。先把七要素快照填一遍。任務(wù)邊界只處理售后工單不閑聊不做營(yíng)銷推薦模型底座公司數(shù)據(jù)不出內(nèi)網(wǎng)用可私有化部署的模型配合一個(gè)小模型做前置分類記憶系統(tǒng)會(huì)話摘要 當(dāng)前工單信息工具調(diào)用三個(gè)——查訂單、查物流、發(fā)起退款申請(qǐng)規(guī)劃?rùn)C(jī)制固定管線執(zhí)行狀態(tài)狀態(tài)圖管理退款節(jié)點(diǎn)前插入人工審批觀測(cè)評(píng)估接 Langfuse 做 Trace準(zhǔn)備 80 條標(biāo)注工單做回歸集。5.2 七個(gè)決策點(diǎn)一次落完第一步定邊界決策一不拆多 Agent單 Agent 走完整個(gè)工單流程。理由很直接鏈路雖然長(zhǎng)但每一步輸入輸出都很清晰不需要兩個(gè)模型互相“商量”拆成兩個(gè) Agent 反而多一層自然語言傳遞的開銷。第二步定模型決策二做一個(gè)三層路由——入口用一個(gè)小模型做意圖識(shí)別判斷“這是售后單、是物流催單、還是其他類型”只有需要生成回復(fù)正文時(shí)才調(diào)用大模型固定模板場(chǎng)景比如純物流催單用一個(gè)規(guī)則模板直接回復(fù)連模型都不調(diào)。這樣算下來真正走到大模型 step 的請(qǐng)求大概只有四成成本立刻打下來。第三步定記憶決策三上下文里只放四樣?xùn)|西——工單編號(hào)、用戶訴求截取前 500 字、訂單狀態(tài)摘要、近三輪會(huì)話摘要。用戶的歷史售后記錄存向量庫需要時(shí)按 top3 召回不占用主上下文。第四步定工具決策四只開放三個(gè)工具query_order(order_id)、query_logistics(tracking_no)、apply_refund(order_id, reason, amount)。前兩個(gè)只讀第三個(gè)有副作用工具描述里明確寫了“調(diào)用后不可撤回需要人工確認(rèn)”。返回結(jié)果在工具內(nèi)部就裁剪成模型真正關(guān)心的字段。第五步定規(guī)劃決策五固定管線狀態(tài)圖四個(gè)節(jié)點(diǎn)classify分類→lookup查訂單/物流→draft_reply生成回復(fù)草稿→human_review人工審批。偽代碼示意from langgraph.graph import StateGraph, END builder StateGraph(WorkOrderState) builder.add_node(classify, classify_node) builder.add_node(lookup, lookup_node) builder.add_node(draft_reply, draft_reply_node) builder.add_node(human_review, human_review_node) builder.add_edge(classify, lookup) builder.add_edge(lookup, draft_reply) builder.add_edge(draft_reply, human_review) builder.add_edge(human_review, END) graph builder.compile()第六步定狀態(tài)決策六每個(gè)工單任務(wù)的狀態(tài)快照寫入 Postgreslookup節(jié)點(diǎn)工具調(diào)用超時(shí)重試一次仍失敗則寫入failed狀態(tài)轉(zhuǎn)人工apply_refund之前強(qiáng)制插入human_review節(jié)點(diǎn)流程掛起等審核人點(diǎn)“同意”才繼續(xù)。這一步把整個(gè)系統(tǒng)的風(fēng)險(xiǎn)控制住了——模型生成錯(cuò)了不用慌人工在看門。第七步定上線評(píng)估決策七先跑 80 條標(biāo)注工單重點(diǎn)看兩個(gè)指標(biāo)分類準(zhǔn)確率要求 95% 以上和草稿可用率人工審核時(shí)需修改比例低于 30%。上線后每天看 Langfuse 里的 trace 分布哪個(gè)節(jié)點(diǎn)耗時(shí)最長(zhǎng)、哪一個(gè)分支命中率最低、平均單量成本是多少。一旦單量成本超預(yù)算就把對(duì)應(yīng)分支切回模板回復(fù)。5.3 上線兩周我調(diào)整了什么這套系統(tǒng)上線兩周最出乎我意料的是分類節(jié)點(diǎn)和回復(fù)節(jié)點(diǎn)都沒出大問題真正拖后腿的是工具返回里的一個(gè)小字段——order_status有幾種邊緣狀態(tài)比如“已申請(qǐng)退款待倉庫確認(rèn)”模型經(jīng)常把這類狀態(tài)誤判成“退款已完成”導(dǎo)致回復(fù)話術(shù)給錯(cuò)。我們沒有急著換大模型而是做了三件事第一在工具返回里把邊緣狀態(tài)單獨(dú)拆字段并加中文釋義減少歧義第二在draft_reply節(jié)點(diǎn)前加了一條規(guī)則判斷命中邊緣狀態(tài)直接走人工模板第三把這類 case 補(bǔ)進(jìn)回歸集防止后續(xù)回歸。改完以后草稿可用率從 74% 提到 88%效果立竿見影。這個(gè)案例想說明的就是Agent 工程不是搭好架子就完事它是一個(gè)持續(xù)用評(píng)估驅(qū)動(dòng)迭代的過程——而每次迭代能精準(zhǔn)找到問題靠的正是上線前布好的觀測(cè)和評(píng)估體系。我個(gè)人的體會(huì)是大部分 Agent 項(xiàng)目翻車翻的從來不是模型能力而是前六個(gè)決策沒想清楚第七個(gè)決策完全沒做。把這套七要素、七決策的框架過一遍基本能把項(xiàng)目里至少八成的不確定性提前排掉。