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