做 AI Agent 這一年多我發(fā)現(xiàn)不管是一千行代碼還是幾萬(wàn)行代碼的系統(tǒng)本質(zhì)都是在跑同一個(gè)東西一個(gè)不斷循環(huán)的“感知 → 思考 → 行動(dòng) → 觀察”過(guò)程。很多人一上來(lái)就研究 LangGraph、Spring AI、Rust 并發(fā)把架構(gòu)搭得特別大結(jié)果連最基本的循環(huán)都跑不穩(wěn)。這篇文章就聊清楚兩件事AI Agent 的最小循環(huán)是什么以及怎么從最小循環(huán)走向可靠系統(tǒng)。這適合兩類(lèi)人看一是剛?cè)腴T(mén) Agent被各種概念繞暈想搞明白底層邏輯的朋友二是已經(jīng)在做項(xiàng)目但總遇到死循環(huán)、超時(shí)、并發(fā)一高就崩想從工程角度夯實(shí)基礎(chǔ)的開(kāi)發(fā)者。我會(huì)把核心原理、最小代碼實(shí)現(xiàn)、工程化手段和常見(jiàn)坑位全部拆開(kāi)講順便穿插一些框架選型經(jīng)驗(yàn)。1. 先理解 AI Agent 的最小循環(huán)1.1 Agent 到底是個(gè)什么東西Agent 不是科幻電影里那種全能機(jī)器人。在當(dāng)下的技術(shù)語(yǔ)境里它就是一個(gè)“大模型 工具 環(huán)境”的組合體通過(guò)循環(huán)決策去完成一個(gè)用戶(hù)目標(biāo)。大模型負(fù)責(zé)思考工具負(fù)責(zé)執(zhí)行環(huán)境是工具所作用的外部世界比如數(shù)據(jù)庫(kù)、網(wǎng)頁(yè)、文件系統(tǒng)、某個(gè) API。舉一個(gè)生活化的類(lèi)比做菜。你是一個(gè) Agent頭腦里的烹飪知識(shí)是大模型菜刀、鍋、灶臺(tái)是工具食材是環(huán)境。你接到“做一盤(pán)番茄炒蛋”的指令后會(huì)先看冰箱里有什么感知然后決定先切番茄還是先打蛋思考接著動(dòng)手操作行動(dòng)看菜的狀態(tài)再?zèng)Q定下一步觀察。這個(gè)循環(huán)反復(fù)進(jìn)行直到出鍋。AI Agent 的最小循環(huán)就是把這個(gè)過(guò)程交給代碼和大模型來(lái)跑。拆開(kāi)看每個(gè) Agent 系統(tǒng)都在做四件事接收信息、生成決策、執(zhí)行動(dòng)作、把執(zhí)行結(jié)果放回上下文。理解了這個(gè)后面所有復(fù)雜架構(gòu)都只是在這個(gè)最小循環(huán)上做工程強(qiáng)化。1.2 最小循環(huán)的四個(gè)環(huán)節(jié)我用工程語(yǔ)言重新描述一遍感知把用戶(hù)請(qǐng)求、歷史對(duì)話、環(huán)境觀察到的內(nèi)容組裝成上下文交給模型。思考模型基于上下文輸出下一步動(dòng)作可能是調(diào)用工具也可能是直接回答。行動(dòng)如果模型決定調(diào)用工具程序就去執(zhí)行真實(shí)函數(shù)查天氣、寫(xiě)文件、查數(shù)據(jù)庫(kù)等。觀察把工具執(zhí)行結(jié)果作為新的消息寫(xiě)回上下文再回到感知環(huán)節(jié)。這四個(gè)環(huán)節(jié)里“思考”看起來(lái)像黑盒實(shí)際上模型的輸出會(huì)被約束成一個(gè)結(jié)構(gòu)化的工具調(diào)用指令比如“調(diào)用函數(shù) get_weather參數(shù)是 city北京”。程序解析這個(gè)指令執(zhí)行對(duì)應(yīng)的 Python 函數(shù)再把返回值塞回消息列表模型看到工具結(jié)果后繼續(xù)決策。在這個(gè)循環(huán)里上下文就是 Agent 的“短期記憶”每輪都會(huì)追加新的消息。如果工具結(jié)果很大或循環(huán)次數(shù)太多上下文會(huì)被撐爆這也是后面要說(shuō)到的上下文管理問(wèn)題的起源。1.3 最小實(shí)現(xiàn)幾十行代碼跑通一個(gè) Agent別急著上框架先自己手寫(xiě)一個(gè)最小循環(huán)這是理解 Agent 最有效的方式。我用 Python 加 OpenAI SDK 做了個(gè)極簡(jiǎn)版換成其他模型接口邏輯也一樣from openai import OpenAI client OpenAI() tools [ { type: function, function: { name: get_weather, description: 獲取指定城市的天氣, parameters: { type: object, properties: { city: {type: string, description: 城市名} }, required: [city] } } } ] def get_weather(city: str) - str: # 這里替換成真實(shí)天氣 API return f{city}今天晴天氣溫25度 messages [{role: user, content: 北京今天天氣怎么樣需要帶傘嗎}] for _ in range(10): # 設(shè)置最大循環(huán)次數(shù)防止死循環(huán) response client.chat.completions.create( modelgpt-4o, messagesmessages, toolstools, ) msg response.choices[0].message messages.append(msg) if not msg.tool_calls: print(msg.content) break for tool_call in msg.tool_calls: if tool_call.function.name get_weather: import json args json.loads(tool_call.function.arguments) result get_weather(args[city]) messages.append({ role: tool, tool_call_id: tool_call.id, content: result })這段代碼已經(jīng)構(gòu)成一個(gè)完整的 Agent 閉環(huán)。注意幾個(gè)關(guān)鍵點(diǎn)模型返回的 tool_calls 包含函數(shù)名和參數(shù)參數(shù)是 JSON 字符串必須解析后才能執(zhí)行工具執(zhí)行結(jié)果要以 role 為 “tool” 的消息追加并且?guī)狭?tool_call_id 做關(guān)聯(lián)循環(huán)必須有上限否則模型一直在調(diào)用工具就崩了。這個(gè)最小實(shí)現(xiàn)能跑通之后你會(huì)直觀感受到 Agent 的核心難點(diǎn)模型輸出的不確定性。它可能不調(diào)工具直接回答錯(cuò)誤答案可能連續(xù)調(diào)用工具十幾次可能把參數(shù)拼錯(cuò)?？煽肯到y(tǒng)要解決的就是這些問(wèn)題。2. 從最小循環(huán)到可用系統(tǒng)繞不開(kāi)的準(zhǔn)備最小循環(huán)只是骨架真實(shí)項(xiàng)目里還要處理工具定義、記憶、規(guī)劃等基礎(chǔ)設(shè)施。這一節(jié)講三件繞不開(kāi)的事。2.1 工具調(diào)用與函數(shù)定義的邊界工具定義是把外部能力暴露給模型的關(guān)鍵。很多新手把函數(shù)寫(xiě)得很大結(jié)果模型經(jīng)常用錯(cuò)。我踩過(guò)幾次坑之后總結(jié)出幾個(gè)原則一個(gè)工具只做一件事參數(shù)要少且語(yǔ)義清晰。比如不要寫(xiě)一個(gè)“全能數(shù)據(jù)查詢(xún)器”而是拆成 get_user_info、get_order_list。description 要寫(xiě)清楚“什么時(shí)候用”最好帶上“如果用戶(hù)沒(méi)提訂單不要調(diào)用訂單查詢(xún)”這種約束。參數(shù)類(lèi)型要嚴(yán)格能枚舉就枚舉模型填錯(cuò)的概率會(huì)降低很多。工具返回值要簡(jiǎn)潔只返回必要信息大段日志直接扔進(jìn)上下文會(huì)浪費(fèi) token還會(huì)干擾模型判斷。工具定義還涉及權(quán)限邊界。Agent 能調(diào)用的工具就是它的“上限”。如果你的 Agent 需要訪問(wèn)內(nèi)部系統(tǒng)一定要做細(xì)粒度的權(quán)限控制比用戶(hù)命令能觸達(dá)的工具列表更小。不要把所有數(shù)據(jù)庫(kù)讀寫(xiě)權(quán)限直接暴露給模型這跟給員工發(fā)一張無(wú)限額度的公司卡沒(méi)區(qū)別。2.2 記憶與上下文管理最小循環(huán)里所有歷史消息都會(huì)進(jìn)入上下文但真實(shí)業(yè)務(wù)場(chǎng)景下對(duì)話不會(huì)只有三輪。我見(jiàn)過(guò)一個(gè)客服 Agent聊到第十輪系統(tǒng)提示詞加完整的商品列表加歷史記錄一次請(qǐng)求直接燒掉 3 萬(wàn) token響應(yīng)也變慢。上下文管理的常見(jiàn)手段有三種截?cái)嘀槐Ａ糇罱?N 輪對(duì)話并且手動(dòng)壓縮系統(tǒng)提示詞。摘要每幾輪對(duì)話后讓模型把前面的內(nèi)容總結(jié)成一段摘要塞回上下文。向量檢索把長(zhǎng)期信息存入向量數(shù)據(jù)庫(kù)需要時(shí)用相似度檢索出相關(guān)片段再注入上下文。這三種各有優(yōu)劣。截?cái)嘧钍∈碌珪?huì)丟失關(guān)鍵信息摘要能保住重點(diǎn)但摘要本身可能出錯(cuò)向量檢索適合知識(shí)庫(kù)問(wèn)答但實(shí)現(xiàn)復(fù)雜度高。我通常的做法是組合使用核心上下文始終保留中間輪次做摘要外部知識(shí)通過(guò) RAG 檢索動(dòng)態(tài)加入。還要注意多輪對(duì)話里的“狀態(tài)”。Agent 的工具調(diào)用完成后如果后續(xù)決策還依賴(lài)之前的中間結(jié)果一定要把關(guān)鍵結(jié)果顯式寫(xiě)入上下文而不是指望模型自己記住。模型對(duì)細(xì)節(jié)的記憶能力遠(yuǎn)沒(méi)有想象中那么強(qiáng)。2.3 規(guī)劃與任務(wù)拆解的工程化很多人把“規(guī)劃”理解成讓模型寫(xiě)一個(gè) todo list 再逐項(xiàng)執(zhí)行。這在簡(jiǎn)單任務(wù)里可行但在復(fù)雜場(chǎng)景里單個(gè)模型輸出的 todo list 往往質(zhì)量不穩(wěn)定。更工程化的做法是讓“規(guī)劃”顯式化。有兩種主流思路ReAct 風(fēng)格不強(qiáng)制顯式規(guī)劃讓模型在循環(huán)中動(dòng)態(tài)決定下一步。Plan-and-Execute 風(fēng)格先讓模型拆解出任務(wù)清單然后逐個(gè)執(zhí)行執(zhí)行完再檢查是否符合目標(biāo)不符合就重新規(guī)劃。Plan-and-Execute 看起來(lái)高級(jí)但實(shí)際落地要小心。如果任務(wù)清單本身拆錯(cuò)了會(huì)出現(xiàn)做了半天無(wú)用功的情況。我一般會(huì)加一道“規(guī)劃校驗(yàn)”的步驟讓模型先告訴自己“這個(gè)任務(wù)的關(guān)鍵依賴(lài)是什么哪些可以并行哪些必須串行”再進(jìn)行工具調(diào)度。另外任務(wù)拆解要區(qū)分“動(dòng)態(tài)拆解”和“靜態(tài)模板”。很多業(yè)務(wù)場(chǎng)景其實(shí)有固定流程比如訂單售后流程確認(rèn)身份 → 查單 → 判斷責(zé)任 → 給出方案這種場(chǎng)景直接用狀態(tài)機(jī)比讓模型自由發(fā)揮可靠得多。Agent 的自由度應(yīng)該被約束在實(shí)際需要的范圍內(nèi)。3. 把 Agent 做成可靠系統(tǒng)工程實(shí)踐才是分水嶺最小循環(huán)像賽車(chē)引擎可以直接上賽道但不能保證不爆缸?？煽肯到y(tǒng)要做的是給引擎加冷卻、加安全籠。這一節(jié)我從五個(gè)工程維度拆解。3.1 超時(shí)、重試與失敗處理大模型調(diào)用不是本地函數(shù)它可能因?yàn)榫W(wǎng)絡(luò)問(wèn)題、服務(wù)端過(guò)載而返回錯(cuò)誤也可能一直掛在那里。不設(shè)超時(shí)的生產(chǎn)系統(tǒng)就是定時(shí)炸彈。我給所有外部調(diào)用設(shè)三級(jí)超時(shí)連接超時(shí)、讀取超時(shí)、整體請(qǐng)求超時(shí)。以 OpenAI SDK 為例client OpenAI( timeouthttpx.Timeout(connect5.0, read30.0, write10.0, pool5.0) )除了網(wǎng)絡(luò)超時(shí)還有工具執(zhí)行本身的超時(shí)。比如一個(gè)工具要調(diào)用第三方 API對(duì)方掛了整個(gè) Agent 就會(huì)被卡住。工具執(zhí)行建議用asyncio.wait_for或線程池的Future設(shè)置超時(shí)超時(shí)后給模型返回“工具執(zhí)行超時(shí)請(qǐng)稍后重試”而不是讓循環(huán)掛死。重試也不是盲目重試。模型調(diào)用失敗要區(qū)分是限流還是服務(wù)端錯(cuò)誤。限流要等待后重試參數(shù)錯(cuò)誤重試一萬(wàn)次也沒(méi)用。我常用的策略是5xx 和連接錯(cuò)誤做指數(shù)退避重試4xx 直接拋出并終止當(dāng)前請(qǐng)求。失敗處理的關(guān)鍵是做兜底話術(shù)。當(dāng)所有重試都失敗時(shí)Agent 不應(yīng)該硬著頭皮編答案而應(yīng)明確告訴用戶(hù)“我現(xiàn)在無(wú)法獲取天氣信息請(qǐng)稍后再試”。這會(huì)讓產(chǎn)品體驗(yàn)有很大提升。3.2 并發(fā)與資源控制Agent 怎么扛并發(fā)“ai agent 怎么扛并發(fā)”是被問(wèn)最多的一個(gè)問(wèn)題。這里先說(shuō)結(jié)論Agent 的并發(fā)瓶頸通常不在代碼而在模型 API 的速率限制和上下文大小。你把 Agent 內(nèi)部循環(huán)拆得再細(xì)只要每個(gè)請(qǐng)求還是同步阻塞地調(diào)模型并發(fā)一高必然完蛋?？覆l(fā)要從幾層入手異步化Agent 的循環(huán)可以使用asyncio改造讓模型調(diào)用和工具調(diào)用都變成異步非阻塞。FastAPI 天生支持異步配合AsyncOpenAI客戶(hù)端可以很好地服務(wù)高并發(fā)請(qǐng)求。并發(fā)上限控制不要無(wú)限制地創(chuàng)建協(xié)程要使用信號(hào)量或連接池限制同時(shí)進(jìn)行的 Agent 任務(wù)數(shù)。我之前線上出現(xiàn)過(guò)幾百個(gè)并發(fā)請(qǐng)求同時(shí)打到模型 API 導(dǎo)致限流的情況加了asyncio.Semaphore(20)后穩(wěn)定很多。請(qǐng)求合并有些模型 API 支持 batch可以把多個(gè)短請(qǐng)求合并成一個(gè)批量請(qǐng)求。但不是所有場(chǎng)景都適用因?yàn)?Agent 循環(huán)依賴(lài)上一步的結(jié)果只有真正獨(dú)立的請(qǐng)求才能合并。狀態(tài)隔離每個(gè) Agent 會(huì)話的狀態(tài)要獨(dú)立存儲(chǔ)不能放在全局變量里。用 Redis 按 session_id 存儲(chǔ)上下文多個(gè) worker 實(shí)例才能水平擴(kuò)展。還有一點(diǎn)容易被忽略工具執(zhí)行的并發(fā)度。Agent 里可能同時(shí)有多個(gè)工具返回如果你的工具函數(shù)是阻塞的比如同步的數(shù)據(jù)庫(kù)查詢(xún)會(huì)擋住事件循環(huán)。高階做法是把工具注冊(cè)成異步函數(shù)或者丟給線程池執(zhí)行。3.3 可觀測(cè)性與日志體系A(chǔ)gent 系統(tǒng)比普通 Web 接口難排查因?yàn)閮?nèi)部的決策鏈路不可見(jiàn)。模型為什么這么回答、為什么調(diào)用了這個(gè)工具、工具返回了什么不做追蹤根本無(wú)從談起。可觀測(cè)性要做到三個(gè)層面日志按 session_id 和 trace_id 記錄每一輪的輸入輸出。重點(diǎn)記錄四件事模型請(qǐng)求的消息數(shù)量、模型返回的內(nèi)容或工具調(diào)用、工具執(zhí)行結(jié)果、循環(huán)次數(shù)。指標(biāo)統(tǒng)計(jì)任務(wù)成功率、平均完成時(shí)間、平均循環(huán)次數(shù)、token 消耗量、工具調(diào)用失敗率。這些數(shù)據(jù)能直接反映 Agent 質(zhì)量。鏈路追蹤用 OpenTelemetry 的 Span 把一次 Agent 任務(wù)的所有環(huán)節(jié)串聯(lián)起來(lái)。推薦把“規(guī)劃→工具調(diào)用→模型再?zèng)Q策”的整體作為一個(gè) trace每個(gè)內(nèi)部調(diào)用作為一個(gè) span。我還會(huì)專(zhuān)門(mén)給 Agent 加一個(gè)“思考日志”把模型每次返回的原始響應(yīng)包括 tool_calls 完整 JSON落盤(pán)方便出問(wèn)題時(shí)復(fù)現(xiàn)。很多人只看最終答案但 Agent 的問(wèn)題往往出現(xiàn)在中間步驟。3.4 狀態(tài)持久化與恢復(fù)扛住宕機(jī)是可靠系統(tǒng)的底線。Agent 任務(wù)執(zhí)行到一半服務(wù)重啟了怎么辦上下文還在嗎很多開(kāi)發(fā)者會(huì)在 Redis 里存上下文列表但 Redis 本身也可能丟數(shù)據(jù)。生產(chǎn)環(huán)境我會(huì)做兩級(jí)存儲(chǔ)實(shí)時(shí)狀態(tài)寫(xiě) Redis用于多實(shí)例訪問(wèn)和快速恢復(fù)。審計(jì)備份每完成一個(gè)關(guān)鍵節(jié)點(diǎn)比如一次工具調(diào)用把上下文同步寫(xiě)一份到數(shù)據(jù)庫(kù)或?qū)ο蟠鎯?chǔ)?；謴?fù)流程是任務(wù)中斷后從備份恢復(fù)上下文重新創(chuàng)建 LLM 客戶(hù)端從上次最后一個(gè)未完成的動(dòng)作繼續(xù)執(zhí)行。這里有一個(gè)坑恢復(fù)到“未調(diào)用工具”的狀態(tài)還是“已調(diào)用但未觀察結(jié)果”的狀態(tài)我建議恢復(fù)到“已調(diào)用但未觀察結(jié)果”避免工具副作用重復(fù)執(zhí)行。比如“發(fā)送郵件”這種非冪等操作重復(fù)執(zhí)行會(huì)出大問(wèn)題。所以工具設(shè)計(jì)時(shí)就要考慮冪等性或者至少讓 Agent 記錄執(zhí)行結(jié)果。狀態(tài)持久化不只是技術(shù)問(wèn)題更是業(yè)務(wù)安全邊界問(wèn)題。4. 技術(shù)選型框架不是銀彈取舍是關(guān)鍵工具鏈現(xiàn)在非常繁榮有 LangChain/LangGraph、Spring AI、Rust 方案也有扣子這類(lèi)低代碼平臺(tái)。選型本質(zhì)是在評(píng)估風(fēng)險(xiǎn)你對(duì)生態(tài)的依賴(lài)程度有多高4.1 LangGraph / LangChain / FastAPI 怎么配合LangChain 把場(chǎng)景抽象得很全面但正因?yàn)槌橄筇嗖瓤映杀疽哺摺angGraph 解決了“有狀態(tài)圖”的問(wèn)題適合做復(fù)雜多跳 Agent節(jié)點(diǎn)之間的狀態(tài)管理比較清晰。FastAPI 是服務(wù)層的好選擇異步支持好類(lèi)型提示完整寫(xiě)起接口來(lái)非常舒服。我目前的實(shí)踐組合是業(yè)務(wù)服務(wù)用 FastAPI 提供 HTTP 接口Agent 內(nèi)部用 LangGraph 構(gòu)建有狀態(tài)的工作流工具層直接用普通 Python 函數(shù)注冊(cè)。LangGraph 的節(jié)點(diǎn)可以定義條件邊這種表達(dá)力很適合 Agent 循環(huán)。但如果你只需要一個(gè)簡(jiǎn)單的“調(diào)工具→再?zèng)Q策”循環(huán)用 LangGraph 反而重了。4.2 Spring AI 與 Java 生態(tài)企業(yè)級(jí) Java 團(tuán)隊(duì)往往繞不開(kāi) Spring AI。它是把 AI 能力注入 Spring 生態(tài)的一套框架好處是能夠復(fù)用現(xiàn)有 Spring Boot 的依賴(lài)注入、事務(wù)管理、監(jiān)控體系。如果你的核心業(yè)務(wù)在 Java 里用 Spring AI 能夠減少語(yǔ)言切換的鴻溝。但是 Spring AI 的迭代速度很快API 變動(dòng)比較頻繁社區(qū)沉淀也還不夠。我接觸下來(lái)適合“在 Java 服務(wù)里嵌入一個(gè) Agent 模塊”的場(chǎng)景但如果是做積木式的復(fù)雜 Agent 產(chǎn)品Java 生態(tài)的靈活度會(huì)低一些。用之前先評(píng)估你的團(tuán)隊(duì)是否真的需要 Java 生態(tài)的穩(wěn)定性而不是因?yàn)椤肮居?Java”就直接選。4.3 Rust 的語(yǔ)言級(jí)優(yōu)勢(shì)有人問(wèn)“基于 Rust 語(yǔ)言做 AI Agent”這個(gè)問(wèn)題更多是沖著并發(fā)和性能去的。Rust 的內(nèi)存安全和高并發(fā)能力確實(shí)讓 Agent 服務(wù)可以承載更高密度的并發(fā)同時(shí)保持極低的資源占用。理論上一千個(gè) Agent 任務(wù)的并發(fā)Rust 的資源和穩(wěn)定性都要比 Python 好。但實(shí)際的痛點(diǎn)在于生態(tài)和迭代速度。Rust 的 LLM 框架還在早期工具鏈不夠豐富上手門(mén)檻高寫(xiě)業(yè)務(wù)代碼效率低。我的建議是除非你的 Agent 服務(wù)已經(jīng)到了需要極致壓榨并發(fā)性能的階段否則沒(méi)必要用 Rust 從零寫(xiě)。比較務(wù)實(shí)的路線是主服務(wù)用 Python/Java把高頻或計(jì)算密集的子模塊用 Rust 做成 sidecar 或獨(dú)立服務(wù)。4.4 低代碼平臺(tái)扣子 Coze 這類(lèi)工具能干嘛扣子這類(lèi)低代碼平臺(tái)確實(shí)能快速搭出 demo很多人都拿它做一些小紅書(shū)自動(dòng)發(fā)消息、簡(jiǎn)單客服問(wèn)答之類(lèi)的 Agent。它的優(yōu)勢(shì)是內(nèi)置了知識(shí)庫(kù)、插件、工作流編排不需要寫(xiě)代碼就能做出一套可用的 Agent。但低代碼平臺(tái)的邊界也很明顯復(fù)雜狀態(tài)管理、私有化部署、高并發(fā)定制化邏輯很難施展。我之前見(jiàn)過(guò)團(tuán)隊(duì)用扣子搭了一個(gè)業(yè)務(wù)流后期想接入自己的鑒權(quán)和數(shù)據(jù)庫(kù)發(fā)現(xiàn)非常別扭。它適合做原型驗(yàn)證、快速給非技術(shù)同事做自動(dòng)化工具真正上生產(chǎn)系統(tǒng)還是得回到代碼。用的時(shí)候心里要清楚低代碼是“能做”不代表“能所有場(chǎng)景都做得好”。5. 可靠系統(tǒng)的評(píng)估沒(méi)有度量就沒(méi)有優(yōu)化Agent 系統(tǒng)的質(zhì)量是不能靠感覺(jué)判斷的。模型換一個(gè)版本可能對(duì)話質(zhì)量提升但工具調(diào)用準(zhǔn)確率下降不跑評(píng)估根本發(fā)現(xiàn)不了。5.1 離線評(píng)估集怎么建準(zhǔn)備一批覆蓋典型場(chǎng)景的測(cè)試用例每個(gè)用例包含用戶(hù)輸入、期望走的步驟、期望的最終答案或答案應(yīng)該包含的關(guān)鍵信息。數(shù)量不用太多50-200 條就能發(fā)現(xiàn)大部分問(wèn)題。評(píng)估指標(biāo)分三類(lèi)任務(wù)成功率Agent 是否正確完成了目標(biāo)。工具調(diào)用準(zhǔn)確率該調(diào)用哪個(gè)工具就調(diào)用哪個(gè)工具不能亂調(diào)。效率指標(biāo)平均循環(huán)次數(shù)、平均 token 消耗。跑評(píng)估時(shí)可以用一個(gè)“評(píng)估模型”當(dāng)裁判讓 gpt-4o 或本地模型打分。但裁判模型也有偏差所以最好同時(shí)保留人工抽檢。5.2 線上回歸與 A/B離線評(píng)估只能守住下限上線后還要做 real traffic 監(jiān)控。最有效的辦法是灰度先讓 5% 流量走新 Agent 版本對(duì)比舊版本的任務(wù)完成率和用戶(hù)滿(mǎn)意度。每次改 prompt、換模型、調(diào)整工具參數(shù)都要跑一輪灰度回歸。我還有一個(gè)習(xí)慣把線上失敗的樣本自動(dòng)收集到“bad case 庫(kù)”每周挑幾個(gè)典型的更新到離線評(píng)估集里。這樣評(píng)估集會(huì)越來(lái)越貼合真實(shí)場(chǎng)景不會(huì)變成自嗨的玩具。5.3 人在回路中的兜底沒(méi)有任何 Agent 能保證 100% 正確所以可靠系統(tǒng)必須考慮人介入的機(jī)制。當(dāng) Agent 的自信心低或連續(xù)兩次工具調(diào)用失敗時(shí)應(yīng)該主動(dòng)轉(zhuǎn)人工。最低成本的做法是設(shè)置一個(gè)“bump 條件”循環(huán)超過(guò) N 次就停止自動(dòng)執(zhí)行把當(dāng)前上下文和候選方案一并交給人工客服處理。人在回路不只是兜底它也是收集反饋的機(jī)制。人工客服看到 Agent 的中間日志后修正一次這個(gè)修正結(jié)果可以成為優(yōu)化工具調(diào)用時(shí)效的訓(xùn)練數(shù)據(jù)。這條飛輪轉(zhuǎn)起來(lái)Agent 的質(zhì)量才會(huì)持續(xù)提升。6. 高頻問(wèn)題與實(shí)戰(zhàn)排查6.1 Agent 陷入了死循環(huán)這是最常見(jiàn)的問(wèn)題。模型在“調(diào)用工具→查看結(jié)果→再調(diào)用工具”之間反復(fù)橫跳可能因?yàn)樯舷挛男畔⒉蛔阋部赡芤驗(yàn)槟Ｐ捅旧淼拿　Ｅ挪樗悸废仍谘h(huán)里打點(diǎn)記錄每次工具調(diào)用的 name 和參數(shù)?？词遣皇峭唤M工具反復(fù)調(diào)用。檢查工具結(jié)果是否有用。很多死循環(huán)是因?yàn)楣ぞ叻祷匦畔⒉粔蚰Ｐ湍貌坏酱鸢钢荒芤恢敝卦?。設(shè)置最大循環(huán)次數(shù)比如 5 次達(dá)到后讓模型總結(jié)當(dāng)前已獲得的成果并給用戶(hù)一個(gè)“當(dāng)前信息不足”的回答。你可能會(huì)看到“Agent 只調(diào)用一次工具就結(jié)束了”這種反向問(wèn)題。排查下來(lái)往往是工具定義寫(xiě)得不好模型認(rèn)為一次調(diào)用就夠了或者系統(tǒng)提示詞里缺少“你可以多次調(diào)用工具直到完成任務(wù)”的引導(dǎo)。這種需要反復(fù)調(diào)整 prompt同時(shí)看評(píng)估集改進(jìn)是否有效。6.2 工具調(diào)用結(jié)果解析失敗模型返回的 tool_calls.arguments 是 JSON 字符串但偶爾會(huì)有非法 JSON比如多了一個(gè)逗號(hào)、鍵沒(méi)帶雙引號(hào)。不要慌最直接的處理是捕獲解析異常把錯(cuò)誤信息發(fā)給模型讓它重新生成參數(shù)。這相當(dāng)于一次自動(dòng)修復(fù)try: args json.loads(tool_call.function.arguments) except json.JSONDecodeError: messages.append({ role: user, content: f你剛才的工具參數(shù) {tool_call.function.arguments} 不是合法 JSON請(qǐng)重新生成 }) continue另外要保證工具函數(shù)的入?yún)⑿ｒ?yàn)。模型可能傳了 schema 里沒(méi)有的字段或者字段類(lèi)型不對(duì)。不要直接拋異常把異常信息包裝成“工具執(zhí)行失敗失敗原因是 XXX請(qǐng)檢查參數(shù)”返回給模型它通常能自我糾錯(cuò)。6.3 并發(fā)一高就嗝屁如果你已經(jīng)用了異步但并發(fā)還是起不來(lái)重點(diǎn)排查兩件事一是工具函數(shù)有沒(méi)有用阻塞式同步 I/O二是模型 API 的限流參數(shù)。很多云廠商的并發(fā)限制是每個(gè) key 的 QPM每分鐘請(qǐng)求數(shù)而不是并發(fā)數(shù)。異步跑起來(lái)后可能瞬間打滿(mǎn)配額。正確的做法是引入令牌桶或簡(jiǎn)單的滑動(dòng)窗口限流。如果用一個(gè)共享的 Redis 計(jì)數(shù)器控制“當(dāng)前正在跑的 Agent 任務(wù)數(shù)”超過(guò)閾值就直接返回 429 讓客戶(hù)端稍后重試。不要為了并發(fā)把所有請(qǐng)求都懟出去。6.4 模型輸出不穩(wěn)定同一個(gè) prompt模型這次答對(duì)那次答錯(cuò)這很正常。應(yīng)對(duì)思路把 temperature 調(diào)到 0 或 0.1在實(shí)際項(xiàng)目中我用 0 配合重試效果挺明顯在系統(tǒng)提示詞里加入“必須遵守步驟”的顯式約束為關(guān)鍵場(chǎng)景準(zhǔn)備 few-shot 示例讓模型模仿示例的輸出格式。更進(jìn)階的手段是用“結(jié)構(gòu)化輸出”功能強(qiáng)制模型返回符合 JSON Schema 的結(jié)果。無(wú)論是工具調(diào)用的參數(shù)還是最終回復(fù)都限制成固定結(jié)構(gòu)能很大程度避免亂寫(xiě)的現(xiàn)象。寫(xiě)在最后我的一點(diǎn)實(shí)操體會(huì)做 Agent 這一年多我踩過(guò)最大的坑不是模型能力不夠而是系統(tǒng)設(shè)計(jì)時(shí)把“可能性”當(dāng)成了“確定性”。最小循環(huán)跑通只是第一步后面每一步——超時(shí)怎么兜、并發(fā)怎么控、狀態(tài)怎么存、壞案例怎么回收——才是真正決定 Agent 能不能上生產(chǎn)的因素。另外我建議所有讀者都手寫(xiě)一次最小循環(huán)哪怕是幾行代碼。當(dāng)你親手看到模型返回的 tool_calls、親手把工具結(jié)果塞回上下文、親手調(diào)試死循環(huán)你會(huì)對(duì) Agent 的整個(gè)機(jī)理有非常直觀的理解。之后再上 LangGraph、Spring AI 這些框架你會(huì)發(fā)現(xiàn)它們只是幫你把循環(huán)的某幾個(gè)環(huán)節(jié)固化下來(lái)核心邏輯和你手寫(xiě)的那幾行一樣。最后分享一個(gè)小技巧Agent 遇到反復(fù)糾纏不清的問(wèn)題時(shí)不一定要繼續(xù)在循環(huán)里打轉(zhuǎn)先給用戶(hù)一個(gè)過(guò)渡性回答把上下文記錄下來(lái)異步繼續(xù)處理或轉(zhuǎn)人工。業(yè)務(wù)上讓用戶(hù)等三秒拿到一個(gè)“處理中”的狀態(tài)遠(yuǎn)好過(guò)讓用戶(hù)盯著 AI 轉(zhuǎn)圈三十秒后得到一個(gè)錯(cuò)誤結(jié)果。