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