1. 為什么“七要素”和“七個(gè)決策點(diǎn)”才是 Agent 工程的骨架很多人第一次接觸 AI Agent腦子里蹦出來(lái)的畫(huà)面是科幻電影里那種能自己思考、自己行動(dòng)的智能體。但真到了動(dòng)手寫(xiě)代碼的階段你會(huì)發(fā)現(xiàn)事情完全不是那么回事。你寫(xiě)了一個(gè)循環(huán)讓大模型反復(fù)調(diào)用工具結(jié)果它要么陷入死循環(huán)要么在第三步就忘了第一步的目標(biāo)要么調(diào)用了一個(gè)根本不存在的函數(shù)還理直氣壯地編造結(jié)果。這些問(wèn)題不是模型不夠聰明而是工程實(shí)現(xiàn)上缺了骨架。我做了幾個(gè) Agent 項(xiàng)目之后踩了一圈坑回過(guò)頭來(lái)發(fā)現(xiàn)一個(gè)規(guī)律所有能穩(wěn)定跑起來(lái)的 Agent底層都逃不開(kāi)七個(gè)核心要素和七個(gè)關(guān)鍵決策點(diǎn)。七要素是“一個(gè) Agent 由哪些零件組成”七個(gè)決策點(diǎn)是“這些零件在運(yùn)行時(shí)怎么做選擇”。前者是靜態(tài)結(jié)構(gòu)后者是動(dòng)態(tài)邏輯。把這兩件事想清楚了不管你用 LangChain、CrewAI、Dify 還是自己從零手寫(xiě)都不會(huì)迷路。這篇文章適合誰(shuí)看如果你已經(jīng)用過(guò)大模型 API知道什么是 prompt、什么是 function calling但一提到“搭一個(gè) Agent”就覺(jué)得無(wú)從下手那這篇就是寫(xiě)給你的。如果你已經(jīng)在做 Agent 開(kāi)發(fā)但系統(tǒng)總是不穩(wěn)定、行為不可預(yù)測(cè)那這篇也能幫你找到結(jié)構(gòu)性的原因。我會(huì)盡量用大白話把每個(gè)要素和決策點(diǎn)講透配上可以直接參考的實(shí)現(xiàn)思路和參數(shù)選擇邏輯讓你看完就能動(dòng)手改自己的項(xiàng)目。核心關(guān)鍵詞先擺出來(lái)AI Agent、LLM、工具調(diào)用、循環(huán)機(jī)制、Agent 架構(gòu)。這幾個(gè)詞貫穿全文后面每個(gè)章節(jié)都會(huì)圍繞它們展開(kāi)。2. 七要素拆解一個(gè) Agent 到底由什么組成2.1 要素一LLM 作為推理內(nèi)核但不是全部很多人把 Agent 等同于“大模型加個(gè)循環(huán)”這個(gè)理解只對(duì)了三分之一。LLM 在 Agent 里的角色是推理內(nèi)核負(fù)責(zé)理解目標(biāo)、拆解任務(wù)、決定下一步動(dòng)作。但它不是 Agent 的全部甚至不是最脆弱的部分。選 LLM 做 Agent 內(nèi)核時(shí)有幾個(gè)參數(shù)必須關(guān)注。第一是上下文窗口因?yàn)樗鼪Q定了 Agent 能“記住”多少歷史信息。一個(gè)多輪工具調(diào)用的 Agent每輪都會(huì)往上下文里塞工具返回結(jié)果窗口太小的話跑到第五輪就開(kāi)始丟前面的信息。第二是函數(shù)調(diào)用能力不是所有模型都支持結(jié)構(gòu)化的 tool use有些模型只能輸出文本你得自己解析這就多了一層不確定性。第三是推理延遲Agent 是循環(huán)執(zhí)行的單次延遲乘以循環(huán)次數(shù)就是總耗時(shí)一個(gè)每次調(diào)用要 8 秒的模型跑五輪就是 40 秒用戶體驗(yàn)直接崩掉。我個(gè)人的經(jīng)驗(yàn)是Agent 場(chǎng)景下模型的選擇優(yōu)先級(jí)是“函數(shù)調(diào)用穩(wěn)定性 上下文窗口 推理能力 延遲”。原因很簡(jiǎn)單Agent 的每一步都依賴(lài)上一步的輸出格式正確如果模型經(jīng)常輸出不合法的工具調(diào)用格式后面全盤(pán)皆輸。推理能力弱一點(diǎn)可以靠 prompt 補(bǔ)格式不穩(wěn)定是補(bǔ)不回來(lái)的。2.2 要素二工具集Agent 的手和腳工具就是 Agent 能調(diào)用的外部函數(shù)。查天氣、搜網(wǎng)頁(yè)、讀數(shù)據(jù)庫(kù)、發(fā)郵件、執(zhí)行代碼這些都是工具。工具集的設(shè)計(jì)直接決定了 Agent 的能力邊界。這里有個(gè)常見(jiàn)的誤區(qū)新手總想給 Agent 塞盡可能多的工具覺(jué)得工具越多越強(qiáng)大。實(shí)際情況恰恰相反。工具數(shù)量超過(guò)一定閾值后模型的工具選擇準(zhǔn)確率會(huì)明顯下降。我實(shí)測(cè)下來(lái)單次暴露給模型的工具控制在 5 到 15 個(gè)之間比較穩(wěn)妥超過(guò) 20 個(gè)之后選錯(cuò)工具的概率大幅上升。那工具多了怎么辦兩個(gè)辦法。一是分組暴露根據(jù)當(dāng)前任務(wù)階段只暴露相關(guān)工具比如“信息收集階段”只給搜索類(lèi)工具“執(zhí)行階段”只給操作類(lèi)工具。二是工具路由先用一次輕量調(diào)用判斷該用哪類(lèi)工具再在子集里做精確選擇。這兩種方式本質(zhì)上都是在降低單次決策的復(fù)雜度。每個(gè)工具的定義也有講究。工具描述要寫(xiě)清楚三件事什么時(shí)候用、參數(shù)是什么意思、返回什么格式。我見(jiàn)過(guò)太多工具描述只寫(xiě)了一句“搜索信息”模型根本不知道什么時(shí)候該用它、什么時(shí)候不該用。好的工具描述應(yīng)該像一份迷你說(shuō)明書(shū)讓模型看完就知道該不該調(diào)用。2.3 要素三記憶系統(tǒng)不只是存聊天記錄Agent 的記憶分三層短期記憶、長(zhǎng)期記憶、工作記憶。短期記憶就是當(dāng)前對(duì)話的上下文長(zhǎng)期記憶是跨會(huì)話持久化的信息工作記憶是當(dāng)前任務(wù)執(zhí)行過(guò)程中的中間狀態(tài)。大部分人對(duì)記憶的理解停留在“把歷史消息拼進(jìn) prompt”這只是短期記憶。真正讓 Agent 表現(xiàn)得像“記得住事”的是工作記憶的設(shè)計(jì)。舉個(gè)例子一個(gè)幫你訂機(jī)票的 Agent它需要記住用戶出發(fā)城市、目的城市、日期、預(yù)算、已查到的航班列表、用戶偏好的航空公司。這些信息不應(yīng)該散落在對(duì)話歷史里而應(yīng)該有一個(gè)結(jié)構(gòu)化的任務(wù)狀態(tài)對(duì)象每輪循環(huán)開(kāi)始時(shí)注入 prompt循環(huán)結(jié)束后更新。實(shí)操心得工作記憶用 JSON 結(jié)構(gòu)維護(hù)比純文本歷史可靠得多。模型對(duì)結(jié)構(gòu)化字段的讀取準(zhǔn)確率明顯高于從大段對(duì)話里“回憶”信息。長(zhǎng)期記憶則涉及存儲(chǔ)和檢索。簡(jiǎn)單場(chǎng)景可以用文件或數(shù)據(jù)庫(kù)存關(guān)鍵事實(shí)復(fù)雜場(chǎng)景需要向量檢索。但要注意長(zhǎng)期記憶的寫(xiě)入時(shí)機(jī)很關(guān)鍵不能每輪都寫(xiě)否則會(huì)存進(jìn)去大量噪音。我的做法是任務(wù)結(jié)束時(shí)做一次總結(jié)性寫(xiě)入只存“用戶偏好”和“任務(wù)結(jié)論”這兩類(lèi)信息。2.4 要素四規(guī)劃模塊把大目標(biāo)拆成小步驟規(guī)劃模塊負(fù)責(zé)把用戶的模糊需求拆解成可執(zhí)行的步驟序列。比如用戶說(shuō)“幫我調(diào)研一下競(jìng)品”規(guī)劃模塊要把它拆成確定競(jìng)品范圍、逐個(gè)搜索信息、整理對(duì)比維度、生成報(bào)告。規(guī)劃有兩種模式靜態(tài)規(guī)劃和動(dòng)態(tài)規(guī)劃。靜態(tài)規(guī)劃是一次性生成完整步驟列表然后按順序執(zhí)行。動(dòng)態(tài)規(guī)劃是每執(zhí)行一步根據(jù)結(jié)果決定下一步做什么。靜態(tài)規(guī)劃適合流程固定的任務(wù)動(dòng)態(tài)規(guī)劃適合探索性任務(wù)。我傾向于混合模式先做一次粗粒度的靜態(tài)規(guī)劃生成 3 到 5 個(gè)高層步驟然后每個(gè)步驟內(nèi)部用動(dòng)態(tài)規(guī)劃。這樣既有全局方向感又有局部靈活性。純靜態(tài)規(guī)劃遇到意外情況就卡死了純動(dòng)態(tài)規(guī)劃容易跑偏或者繞圈子。規(guī)劃模塊的輸出格式也很重要。我一般要求模型輸出一個(gè)步驟列表每個(gè)步驟包含步驟描述、預(yù)期輸入、預(yù)期輸出、完成條件。完成條件這一項(xiàng)特別關(guān)鍵它讓 Agent 知道什么時(shí)候該進(jìn)入下一步而不是無(wú)限循環(huán)。2.5 要素五執(zhí)行器真正干活的那一層執(zhí)行器負(fù)責(zé)實(shí)際調(diào)用工具、解析返回結(jié)果、處理異常。這一層看起來(lái)簡(jiǎn)單其實(shí)是最容易出 bug 的地方。工具調(diào)用的返回結(jié)果格式五花八門(mén)有的是 JSON有的是純文本有的是 HTML。執(zhí)行器需要做結(jié)果歸一化把不同格式的返回統(tǒng)一成模型能理解的格式。同時(shí)要處理超時(shí)和重試一個(gè)搜索工具超時(shí)了不能直接讓整個(gè) Agent 崩掉要有降級(jí)策略。還有一個(gè)容易被忽略的點(diǎn)工具返回結(jié)果的長(zhǎng)度控制。有些工具返回的內(nèi)容特別長(zhǎng)直接塞進(jìn)上下文會(huì)擠占空間。執(zhí)行器需要做截?cái)嗷蛘槐Ａ艉彤?dāng)前任務(wù)相關(guān)的部分。我一般會(huì)設(shè)置一個(gè)閾值超過(guò) 2000 字符的返回結(jié)果先做一次摘要再注入。2.6 要素六循環(huán)控制器Agent 的心跳循環(huán)控制器決定了 Agent 什么時(shí)候繼續(xù)、什么時(shí)候停止。這是 Agent 工程里最核心也最容易出問(wèn)題的部分。一個(gè)基本的循環(huán)是這樣的觀察當(dāng)前狀態(tài)、決定下一步動(dòng)作、執(zhí)行動(dòng)作、更新?tīng)顟B(tài)、判斷是否完成。聽(tīng)起來(lái)簡(jiǎn)單但實(shí)際運(yùn)行時(shí)會(huì)遇到各種邊界情況。比如模型一直調(diào)用同一個(gè)工具、模型輸出格式錯(cuò)誤導(dǎo)致無(wú)法解析、任務(wù)已經(jīng)完成了但模型還在繼續(xù)。循環(huán)控制器需要設(shè)置多重終止條件任務(wù)完成標(biāo)志、最大循環(huán)次數(shù)、連續(xù)無(wú)進(jìn)展檢測(cè)、超時(shí)限制。這幾個(gè)條件缺一不可。我見(jiàn)過(guò)只設(shè)最大循環(huán)次數(shù)的實(shí)現(xiàn)結(jié)果 Agent 在達(dá)到上限之前一直在做無(wú)用功白白消耗 token。2.7 要素七輸出格式化讓結(jié)果可用最后一個(gè)要素是輸出格式化。Agent 跑完一圈最終要產(chǎn)出一個(gè)用戶能用的結(jié)果。這個(gè)結(jié)果可能是自然語(yǔ)言回答、結(jié)構(gòu)化數(shù)據(jù)、文件、或者一個(gè)操作確認(rèn)。輸出格式化模塊要做的事情是把 Agent 執(zhí)行過(guò)程中的中間狀態(tài)和最終結(jié)果轉(zhuǎn)換成符合預(yù)期的輸出格式。如果用戶要的是 JSON就不能返回一段散文如果用戶要的是報(bào)告就要有清晰的結(jié)構(gòu)。這里有個(gè)技巧在 Agent 循環(huán)的最后一步專(zhuān)門(mén)用一次模型調(diào)用來(lái)做格式化而不是讓模型在循環(huán)過(guò)程中順便輸出。這樣格式化的質(zhì)量更穩(wěn)定因?yàn)槟Ｐ椭恍枰獙?zhuān)注做一件事。3. 七個(gè)決策點(diǎn)Agent 運(yùn)行時(shí)到底在做什么選擇3.1 決策點(diǎn)一下一步做什么——繼續(xù)、調(diào)用工具還是結(jié)束這是 Agent 每一輪循環(huán)都要做的第一個(gè)決策。模型需要判斷當(dāng)前狀態(tài)信息夠不夠需不需要調(diào)用工具任務(wù)是不是已經(jīng)完成了這個(gè)決策的質(zhì)量直接決定了 Agent 的效率。如果模型過(guò)于保守明明信息夠了還要繼續(xù)搜索就會(huì)浪費(fèi)輪次如果過(guò)于激進(jìn)信息不足就急著給答案結(jié)果質(zhì)量就差。我的做法是在 prompt 里明確定義三種狀態(tài)的判斷標(biāo)準(zhǔn)。比如“如果已有信息能完整回答用戶問(wèn)題輸出 FINISH如果需要外部信息輸出 TOOL_CALL如果當(dāng)前信息部分足夠但需要補(bǔ)充輸出 TOOL_CALL 并說(shuō)明缺什么”。把判斷標(biāo)準(zhǔn)寫(xiě)清楚模型的決策準(zhǔn)確率會(huì)高很多。3.2 決策點(diǎn)二選哪個(gè)工具——工具選擇的優(yōu)先級(jí)邏輯當(dāng)決定要調(diào)用工具后下一個(gè)決策是選哪個(gè)。前面說(shuō)過(guò)工具數(shù)量要控制但即使只有 5 個(gè)工具模型也可能選錯(cuò)。工具選擇的核心邏輯是匹配度排序。模型需要根據(jù)當(dāng)前任務(wù)需求評(píng)估每個(gè)工具的適用程度。這里有個(gè)實(shí)用技巧在工具描述里加入使用場(chǎng)景標(biāo)簽比如“適用于實(shí)時(shí)信息查詢”“不適用于歷史數(shù)據(jù)”。這些標(biāo)簽?zāi)茱@著提升選擇準(zhǔn)確率。另一個(gè)技巧是工具調(diào)用示例。在 prompt 里給每個(gè)工具配一兩個(gè)調(diào)用示例模型看到示例后更容易理解什么時(shí)候該用。這比純文字描述有效得多。3.3 決策點(diǎn)三參數(shù)怎么填——從自然語(yǔ)言到結(jié)構(gòu)化參數(shù)選好工具后要填參數(shù)。這是從自然語(yǔ)言到結(jié)構(gòu)化數(shù)據(jù)的轉(zhuǎn)換過(guò)程也是容易出錯(cuò)的地方。比如用戶說(shuō)“幫我查一下明天北京的天氣”模型需要把它轉(zhuǎn)換成{city: 北京, date: 2024-01-16}。日期格式、城市名稱(chēng)的規(guī)范化、可選參數(shù)的省略這些都需要模型做判斷。提高參數(shù)填寫(xiě)準(zhǔn)確率的方法有幾個(gè)。一是參數(shù)描述要具體不要只寫(xiě)“日期”要寫(xiě)“日期格式 YYYY-MM-DD默認(rèn)為今天”。二是提供參數(shù)示例讓模型有參照。三是做參數(shù)校驗(yàn)執(zhí)行器在調(diào)用工具前檢查參數(shù)合法性不合法就返回錯(cuò)誤讓模型重新填。3.4 決策點(diǎn)四結(jié)果怎么解讀——工具返回信息的理解與篩選工具返回結(jié)果后模型需要解讀這些結(jié)果判斷是否滿足當(dāng)前需求。這一步的難點(diǎn)在于信息篩選返回結(jié)果里可能有很多無(wú)關(guān)信息模型需要提取有用的部分。比如搜索工具返回了 10 條結(jié)果模型需要判斷哪幾條和當(dāng)前任務(wù)相關(guān)。這里容易出現(xiàn)的問(wèn)題是模型被無(wú)關(guān)信息帶偏或者遺漏了關(guān)鍵信息。我的經(jīng)驗(yàn)是在 prompt 里明確要求模型先總結(jié)工具返回結(jié)果再判斷是否滿足需求。這個(gè)“先總結(jié)再判斷”的順序很重要它強(qiáng)迫模型先理解再?zèng)Q策而不是直接跳到結(jié)論。3.5 決策點(diǎn)五狀態(tài)怎么更新——任務(wù)進(jìn)度的追蹤與調(diào)整每輪循環(huán)結(jié)束后Agent 需要更新自己的狀態(tài)已經(jīng)完成了什么、還缺什么、下一步該做什么。這個(gè)決策點(diǎn)決定了 Agent 是否有“全局感”。狀態(tài)更新最容易出的問(wèn)題是信息丟失。比如第一輪查到了用戶的城市第三輪需要用到這個(gè)信息時(shí)模型忘了。解決辦法就是前面提到的結(jié)構(gòu)化工作記憶每輪都顯式地把關(guān)鍵狀態(tài)注入 prompt。另一個(gè)問(wèn)題是狀態(tài)更新不及時(shí)。比如工具調(diào)用失敗了但狀態(tài)里還標(biāo)記為“已完成”導(dǎo)致后續(xù)步驟基于錯(cuò)誤假設(shè)執(zhí)行。所以狀態(tài)更新要和執(zhí)行結(jié)果嚴(yán)格綁定成功才標(biāo)記完成失敗要記錄失敗原因。3.6 決策點(diǎn)六異常怎么處理——工具失敗、格式錯(cuò)誤、超時(shí)的應(yīng)對(duì)異常處理是 Agent 工程里最容易被低估的部分。實(shí)際運(yùn)行中工具調(diào)用失敗、模型輸出格式錯(cuò)誤、網(wǎng)絡(luò)超時(shí)這些都是常態(tài)。異常處理的核心原則是優(yōu)雅降級(jí)不要崩潰。工具調(diào)用失敗時(shí)Agent 應(yīng)該能感知到失敗并決定是重試、換工具、還是跳過(guò)這一步。模型輸出格式錯(cuò)誤時(shí)應(yīng)該有一次重新格式化的機(jī)會(huì)而不是直接報(bào)錯(cuò)退出。我一般會(huì)設(shè)置三級(jí)異常處理第一級(jí)是自動(dòng)重試適用于網(wǎng)絡(luò)抖動(dòng)等臨時(shí)問(wèn)題第二級(jí)是降級(jí)替代比如搜索工具失敗就用緩存結(jié)果第三級(jí)是上報(bào)給模型讓模型決定怎么處理。三級(jí)都處理不了才終止任務(wù)。3.7 決策點(diǎn)七何時(shí)停止——完成判斷與終止條件最后一個(gè)決策點(diǎn)是判斷任務(wù)是否完成。這個(gè)看似簡(jiǎn)單實(shí)際上很容易出問(wèn)題。模型有時(shí)候會(huì)“過(guò)度完成”明明任務(wù)已經(jīng)結(jié)束了還在繼續(xù)調(diào)用工具有時(shí)候會(huì)“提前完成”信息還不夠就給出答案。終止條件要設(shè)計(jì)成多條件與邏輯任務(wù)完成標(biāo)志為真且沒(méi)有待處理的子任務(wù)且輸出格式符合要求才終止。任何一個(gè)條件不滿足就繼續(xù)循環(huán)。同時(shí)要有硬性上限比如最大 15 輪超過(guò)就強(qiáng)制終止并返回當(dāng)前最佳結(jié)果。注意最大循環(huán)次數(shù)不要設(shè)得太高。我見(jiàn)過(guò)設(shè) 50 輪的結(jié)果 Agent 在死循環(huán)里燒掉大量 token。一般任務(wù) 10 到 15 輪足夠復(fù)雜任務(wù) 20 輪也到頂了。4. 從零搭建一個(gè)最小可用 Agent 的完整實(shí)操4.1 環(huán)境準(zhǔn)備與技術(shù)選型先說(shuō)技術(shù)棧。如果你只是想理解 Agent 的原理用 Python 加任意一個(gè)支持函數(shù)調(diào)用的 LLM API 就夠了。如果你想快速搭一個(gè)能用的系統(tǒng)LangChain 或 CrewAI 是不錯(cuò)的起點(diǎn)。如果你想要更細(xì)粒度的控制建議自己手寫(xiě)循環(huán)不依賴(lài)框架。我個(gè)人的選擇是手寫(xiě)核心循環(huán)加輕量工具庫(kù)。原因是我發(fā)現(xiàn)框架的抽象層在調(diào)試時(shí)反而增加難度出了問(wèn)題不知道是框架的鍋還是自己的鍋。手寫(xiě)循環(huán)雖然代碼多一些但每一行都在自己掌控中。環(huán)境依賴(lài)很簡(jiǎn)單Python 3.10 以上、一個(gè) LLM API 的 SDK、requests 庫(kù)用于調(diào)用外部工具。不需要數(shù)據(jù)庫(kù)不需要向量庫(kù)最小可用版本用內(nèi)存和文件就夠了。4.2 定義工具集與工具描述先定義三到五個(gè)基礎(chǔ)工具。我一般從這幾個(gè)開(kāi)始搜索工具、計(jì)算工具、文件讀寫(xiě)工具、HTTP 請(qǐng)求工具。每個(gè)工具用統(tǒng)一的格式定義tools [ { name: search, description: 搜索互聯(lián)網(wǎng)獲取實(shí)時(shí)信息。適用于查詢新聞、天氣、實(shí)時(shí)數(shù)據(jù)。不適用于數(shù)學(xué)計(jì)算、文件操作。, parameters: { query: {type: string, description: 搜索關(guān)鍵詞盡量具體} } }, { name: calculate, description: 執(zhí)行數(shù)學(xué)計(jì)算。適用于加減乘除、百分比、冪運(yùn)算。不適用于需要外部數(shù)據(jù)的計(jì)算。, parameters: { expression: {type: string, description: 數(shù)學(xué)表達(dá)式如 2 3 * 4} } } ]工具描述里的“適用于”和“不適用于”是我強(qiáng)烈建議加的。實(shí)測(cè)下來(lái)加了這兩項(xiàng)之后工具選擇準(zhǔn)確率能提升不少。4.3 構(gòu)建主循環(huán)與狀態(tài)管理主循環(huán)的結(jié)構(gòu)大概是這樣的def run_agent(user_input, max_turns15): state { goal: user_input, history: [], working_memory: {}, turn: 0, done: False } while not state[done] and state[turn] max_turns: state[turn] 1 # 構(gòu)建 prompt prompt build_prompt(state, tools) # 調(diào)用 LLM response call_llm(prompt) # 解析輸出 action parse_action(response) if action[type] FINISH: state[done] True state[result] action[content] elif action[type] TOOL_CALL: result execute_tool(action[name], action[params]) state[history].append({action: action, result: result}) update_working_memory(state, action, result) else: # 格式錯(cuò)誤重試一次 state[history].append({error: invalid format}) return state.get(result, 任務(wù)未完成)這個(gè)結(jié)構(gòu)看起來(lái)簡(jiǎn)單但每一部分都有細(xì)節(jié)。build_prompt要把工具描述、工作記憶、歷史記錄都拼進(jìn)去同時(shí)控制總長(zhǎng)度。parse_action要處理模型輸出的各種格式變體。update_working_memory要判斷哪些信息值得記住。4.4 參數(shù)計(jì)算與關(guān)鍵閾值選擇幾個(gè)關(guān)鍵參數(shù)需要根據(jù)實(shí)際情況調(diào)整。最大循環(huán)次數(shù)我一般設(shè) 15簡(jiǎn)單任務(wù) 5 到 8 輪就結(jié)束了復(fù)雜任務(wù) 12 到 15 輪。上下文長(zhǎng)度上限根據(jù)模型窗口來(lái)定一般留 20% 的余量給輸出。工具返回結(jié)果截?cái)嚅撝翟O(shè) 2000 字符超過(guò)就摘要。重試次數(shù)設(shè) 2 次第一次失敗后重試第二次失敗就降級(jí)。超時(shí)時(shí)間單個(gè)工具調(diào)用設(shè) 30 秒整個(gè)任務(wù)設(shè) 5 分鐘。這些數(shù)值不是固定的要根據(jù)你的具體場(chǎng)景調(diào)整。比如做實(shí)時(shí)對(duì)話的 Agent超時(shí)要設(shè)得更短做后臺(tái)批處理的可以放寬。4.5 實(shí)操現(xiàn)場(chǎng)一個(gè)完整任務(wù)的執(zhí)行記錄假設(shè)用戶輸入是“幫我查一下今天北京的天氣然后換算成華氏度”。第一輪模型判斷需要調(diào)用搜索工具參數(shù){query: 北京今天天氣}。工具返回“北京今天晴氣溫 25 攝氏度”。工作記憶更新{weather_celsius: 25}。第二輪模型判斷需要調(diào)用計(jì)算工具參數(shù){expression: 25 * 9/5 32}。工具返回 77。工作記憶更新{weather_fahrenheit: 77}。第三輪模型判斷信息足夠輸出 FINISH內(nèi)容為“北京今天晴氣溫 25 攝氏度約合 77 華氏度”。整個(gè)過(guò)程三輪循環(huán)兩次工具調(diào)用狀態(tài)更新兩次。這個(gè)流程跑通之后你就可以往里面加更多工具、更復(fù)雜的規(guī)劃邏輯、更完善的異常處理。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 工具調(diào)用死循環(huán)怎么破這是最常見(jiàn)的問(wèn)題。Agent 反復(fù)調(diào)用同一個(gè)工具每次都得到相似結(jié)果但就是不結(jié)束。原因通常是模型沒(méi)有正確判斷“信息已經(jīng)夠了”。排查思路先看工作記憶里是否記錄了已獲取的信息。如果記錄了但模型還是繼續(xù)調(diào)用說(shuō)明 prompt 里沒(méi)有明確告訴模型“這些信息已經(jīng)夠了”。解決辦法是在 prompt 里加一條規(guī)則“如果工作記憶中已包含回答用戶問(wèn)題所需的所有信息必須輸出 FINISH”。另一個(gè)原因是工具返回結(jié)果沒(méi)有變化模型以為沒(méi)查到。這時(shí)候要在工具返回結(jié)果里加一個(gè)標(biāo)記比如“已查詢過(guò)結(jié)果同上”讓模型知道這是重復(fù)查詢。5.2 模型輸出格式錯(cuò)誤頻發(fā)怎么辦模型有時(shí)候不按你要求的 JSON 格式輸出而是輸出一段自然語(yǔ)言。這種情況在模型能力較弱時(shí)尤其常見(jiàn)。解決辦法有三層。第一層是prompt 里給格式示例讓模型照著抄。第二層是輸出解析器做容錯(cuò)比如用正則提取 JSON 部分或者嘗試修復(fù)常見(jiàn)的格式錯(cuò)誤。第三層是格式錯(cuò)誤時(shí)自動(dòng)重試把錯(cuò)誤信息返回給模型讓它重新輸出。我一般三層都上。實(shí)測(cè)下來(lái)加了格式示例之后錯(cuò)誤率能降一半加上容錯(cuò)解析再降一半最后重試兜底基本不會(huì)因?yàn)楦袷絾?wèn)題卡死。5.3 上下文爆炸與信息丟失的平衡Agent 跑多輪之后上下文會(huì)越來(lái)越長(zhǎng)。如果不控制很快就會(huì)超出模型窗口。但如果粗暴截?cái)嘤謺?huì)丟失關(guān)鍵信息。我的做法是分層管理上下文。工作記憶始終保留因?yàn)樗亲铌P(guān)鍵的狀態(tài)信息。歷史記錄只保留最近 5 輪更早的做摘要。工具返回結(jié)果只保留和當(dāng)前任務(wù)相關(guān)的部分無(wú)關(guān)的丟棄。具體操作上每輪循環(huán)開(kāi)始時(shí)先計(jì)算當(dāng)前上下文長(zhǎng)度如果超過(guò)閾值就對(duì)最早的歷史記錄做摘要壓縮。摘要用一次輕量模型調(diào)用完成成本很低。5.4 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方法解決方案Agent 不調(diào)用工具工具描述不清晰檢查工具描述是否說(shuō)明使用場(chǎng)景補(bǔ)充“適用于/不適用于”標(biāo)簽反復(fù)調(diào)用同一工具未判斷信息已足夠查看工作記憶是否記錄結(jié)果prompt 加完成判斷規(guī)則輸出格式錯(cuò)誤模型能力不足檢查是否有格式示例加示例容錯(cuò)解析重試上下文超限歷史記錄太長(zhǎng)統(tǒng)計(jì)每輪 token 消耗分層管理摘要壓縮任務(wù)提前結(jié)束完成條件太寬松檢查終止條件邏輯改為多條件與邏輯工具調(diào)用超時(shí)外部服務(wù)不穩(wěn)定查看工具調(diào)用日志設(shè)超時(shí)重試降級(jí)5.5 獨(dú)家避坑技巧第一個(gè)技巧在工具返回結(jié)果里加“置信度”標(biāo)記。比如搜索結(jié)果標(biāo)注“高相關(guān)/低相關(guān)”讓模型知道哪些結(jié)果更可信。這個(gè)簡(jiǎn)單的標(biāo)記能顯著提升模型的信息篩選質(zhì)量。第二個(gè)技巧給 Agent 設(shè)一個(gè)“思考預(yù)算”。在 prompt 里告訴模型“你最多有 15 輪機(jī)會(huì)請(qǐng)高效使用”。模型知道有預(yù)算限制后會(huì)更傾向于在信息足夠時(shí)及時(shí)結(jié)束而不是無(wú)限探索。第三個(gè)技巧用“反向驗(yàn)證”提升完成判斷準(zhǔn)確率。在 Agent 準(zhǔn)備輸出 FINISH 之前加一步驗(yàn)證“請(qǐng)檢查你的答案是否完整回答了用戶的原始問(wèn)題”。這一步能攔住不少提前完成的情況。第四個(gè)技巧日志要記錄每一輪的完整輸入輸出。Agent 出問(wèn)題時(shí)光看最終結(jié)果根本不知道哪一步錯(cuò)了。把每輪的 prompt、模型輸出、工具返回都記下來(lái)排查效率能提升好幾倍。6. 進(jìn)階方向從能跑到好用還差什么6.1 多 Agent 協(xié)作的適用場(chǎng)景單 Agent 能解決大部分任務(wù)但有些場(chǎng)景適合多 Agent。比如一個(gè)負(fù)責(zé)調(diào)研、一個(gè)負(fù)責(zé)寫(xiě)作、一個(gè)負(fù)責(zé)審核。多 Agent 的優(yōu)勢(shì)是每個(gè) Agent 的職責(zé)更聚焦prompt 可以更精簡(jiǎn)工具集可以更小。但多 Agent 也帶來(lái)新的問(wèn)題Agent 之間怎么通信、怎么協(xié)調(diào)、怎么避免互相等待。我的建議是不要過(guò)早引入多 Agent。先把單 Agent 跑穩(wěn)確認(rèn)瓶頸確實(shí)在“職責(zé)太多”而不是其他原因再考慮拆分。6.2 工具調(diào)用的安全邊界Agent 能調(diào)用工具意味著它能對(duì)外部世界產(chǎn)生影響。發(fā)郵件、改數(shù)據(jù)庫(kù)、執(zhí)行代碼這些操作一旦出錯(cuò)后果可能很?chē)?yán)重。安全邊界的設(shè)計(jì)原則是最小權(quán)限加人工確認(rèn)。Agent 只應(yīng)該擁有完成當(dāng)前任務(wù)所需的最小工具集。對(duì)于有副作用的操作比如發(fā)送、刪除、修改應(yīng)該加一道人工確認(rèn)或者至少加一個(gè)“預(yù)覽”步驟。注意永遠(yuǎn)不要給 Agent 無(wú)限制的代碼執(zhí)行權(quán)限。如果確實(shí)需要執(zhí)行代碼用沙箱環(huán)境限制可訪問(wèn)的資源。6.3 性能優(yōu)化的幾個(gè)方向Agent 的性能瓶頸通常在兩個(gè)地方LLM 調(diào)用延遲和工具調(diào)用延遲。優(yōu)化 LLM 延遲可以用更小的模型做簡(jiǎn)單決策只在關(guān)鍵步驟用大模型。優(yōu)化工具延遲可以并行調(diào)用無(wú)依賴(lài)的工具或者做結(jié)果緩存。還有一個(gè)容易被忽略的優(yōu)化點(diǎn)減少不必要的循環(huán)輪次。很多 Agent 之所以慢是因?yàn)樽隽颂酂o(wú)用功。通過(guò)優(yōu)化 prompt 讓模型更果斷地做決策比優(yōu)化單次調(diào)用速度效果更明顯。6.4 評(píng)估與迭代怎么知道 Agent 變好了Agent 的評(píng)估比傳統(tǒng)軟件難因?yàn)樗妮敵霾皇谴_定性的。我的做法是建一個(gè)測(cè)試用例集包含 20 到 30 個(gè)典型任務(wù)每個(gè)任務(wù)有明確的成功標(biāo)準(zhǔn)。每次修改 prompt 或工具后跑一遍測(cè)試集看成功率的變化。除了成功率還要關(guān)注平均循環(huán)輪次和平均 token 消耗。一個(gè) Agent 成功率提升了但輪次翻倍未必是好事。好的優(yōu)化應(yīng)該是成功率和效率同時(shí)改善。我在實(shí)際項(xiàng)目中的體會(huì)是Agent 的迭代很像調(diào)參但比調(diào)參更依賴(lài)對(duì)任務(wù)本身的理解。你得知道這個(gè)任務(wù)“合理的執(zhí)行路徑”是什么樣的才能判斷 Agent 的行為是否正常。如果自己都不清楚一個(gè)任務(wù)應(yīng)該幾步完成那就沒(méi)法評(píng)估 Agent 做得好不好。所以做 Agent 開(kāi)發(fā)先把手動(dòng)執(zhí)行這個(gè)任務(wù)的流程走一遍記錄下來(lái)這個(gè)記錄就是你評(píng)估 Agent 的基準(zhǔn)線。