1. 從“會聊天”到“會干活”智能體到底在解決什么問題這兩年“AI智能體”這個詞出現(xiàn)的頻率越來越高但你要是真去問一圈會發(fā)現(xiàn)大家對它的理解差得挺遠(yuǎn)。有人覺得它就是能多輪對話的聊天機(jī)器人有人以為是能自動寫周報的腳本工具還有人直接把它等同于大模型本身。我最早接觸這個方向的時候也走過彎路踩過不少坑。經(jīng)過幾個項(xiàng)目的實(shí)際打磨我對智能體的理解更偏向一個“會調(diào)用工具、能拆解任務(wù)、能自主決策”的軟件系統(tǒng)它更像是給AI裝上了手和腳讓模型從“動嘴”變成“動手”。先聊一個最基礎(chǔ)的問題我們?yōu)槭裁葱枰悄荏w而不是直接調(diào)用大模型API我在做模擬項(xiàng)目X的時候最開始就是簡單的“用戶提問-大模型回答”效果其實(shí)還行。但一旦涉及復(fù)雜任務(wù)比如“幫我調(diào)研一下這個行業(yè)的競爭對手整理成表格再寫一份摘要發(fā)到群里”單次對話根本搞不定。原因很簡單大模型本質(zhì)上是一個概率文本生成器它沒有記憶長對話能力再強(qiáng)也有上下文窗口、不能執(zhí)行外部操作不能真的去訪問網(wǎng)頁或者寫數(shù)據(jù)庫、也不具備持續(xù)的任務(wù)狀態(tài)管理。智能體的價值恰好在這些縫隙里補(bǔ)位。智能體能做的核心事情可以歸成三類第一是任務(wù)分解把用戶模糊的意圖拆解成可執(zhí)行的步驟第二是工具調(diào)用通過函數(shù)或者API去操作外部系統(tǒng)第三是狀態(tài)管理在多輪執(zhí)行中記住“做到哪一步了、下一步該干什么”。這三件事串起來就是一個智能體的最小閉環(huán)。這篇文章我會基于實(shí)際做過的項(xiàng)目經(jīng)驗(yàn)把智能體的技術(shù)架構(gòu)拆開講清楚從最外層的應(yīng)用入口到核心的Agent編排引擎再到底層的模型接入、工具層和數(shù)據(jù)層每一層都結(jié)合具體的方案選型和踩坑經(jīng)歷來聊。內(nèi)容適合兩類讀者一類是剛開始接觸智能體開發(fā)想搞明白整體架構(gòu)的初學(xué)者另一類是已經(jīng)寫過一些Demo但覺得自己的Agent“不夠聰明、不夠穩(wěn)”想找優(yōu)化方向的開發(fā)者。2. 分層看架構(gòu)一個能落地的智能體由哪幾部分構(gòu)成聊架構(gòu)之前先給一個全景式的分層視圖。一個完整的智能體系統(tǒng)從下往上大致是基礎(chǔ)設(shè)施層、數(shù)據(jù)與知識層、模型服務(wù)層、Agent核心引擎層、工具/插件層、應(yīng)用與交互層。這六層之間有明確的調(diào)用關(guān)系但又不是純粹的“上層依賴下層”有些層是橫切的比如可觀測性和安全審計會貫穿所有層。我用一個生活化的類比來解釋這個分層。想象一個“智能管家”的運(yùn)作過程管家Agent核心引擎接到主人的指令“把書房收拾好”應(yīng)用層入口他需要先理解這句話的意思模型服務(wù)層結(jié)合自己腦子里對書房布局的記憶數(shù)據(jù)與知識層制定一個“先分類→再清掃→最后歸位”的計劃任務(wù)規(guī)劃然后動手去做——搬書、擦桌子、扔垃圾工具層整個過程中他要知道自己做到哪一步了有沒有出錯狀態(tài)管理與可觀測。最后他向主人匯報“書房收拾完了另外我發(fā)現(xiàn)兩本舊書可能賣掉了”結(jié)果生成與交互?；氐郊夹g(shù)實(shí)現(xiàn)上每一層都有自己的關(guān)鍵組件?；A(chǔ)設(shè)施層是最容易被忽視的。很多團(tuán)隊(duì)做智能體上來就寫代碼調(diào)模型結(jié)果到了部署階段才發(fā)現(xiàn)GPU資源怎么分、服務(wù)怎么擴(kuò)容、模型怎么緩存都沒想好。我見過不少項(xiàng)目原型階段用別人的API跑得很燙一上生產(chǎn)就各種超時、限流說到底就是基礎(chǔ)設(shè)施層沒設(shè)計。數(shù)據(jù)與知識層解決的是“模型不知道的事”和“模型記錯的事”。大模型的訓(xùn)練數(shù)據(jù)有時間截止點(diǎn)企業(yè)內(nèi)部的知識庫它完全沒見過這時候就需要RAG檢索增強(qiáng)生成或者Fine-tuning來把私有知識接進(jìn)去。RAG適合知識量大、更新頻繁的場景Fine-tuning適合格式固定、風(fēng)格要求嚴(yán)格的場景兩者各有優(yōu)劣后面會展開。模型服務(wù)層是智能體的“大腦”。這里要決策的事情包括用閉源API還是開源模型用單一模型還是多個模型各司其職模型的溫度、上下文窗口、工具調(diào)用格式怎么配這些決策直接決定了智能體的“聰明程度”和“性格”。Agent核心引擎層是整個系統(tǒng)的技術(shù)難點(diǎn)所在。它負(fù)責(zé)理解用戶意圖、規(guī)劃執(zhí)行步驟、調(diào)用工具、觀察結(jié)果、決定下一步動作構(gòu)成了一個循環(huán)。常見的技術(shù)路線包括ReAct模式、Plan-and-Execute模式、以及目前比較火的Graph-based多智能體協(xié)作模式。這一層是后面第三、四、五節(jié)的重頭戲這里先不展開。工具層是智能體能力的邊界。沒有工具的智能體只能“紙上談兵”有了工具才能“動手干活”。工具的形式可以是大模型API調(diào)用Function Calling/JSON Mode、代碼解釋器、RPA腳本、數(shù)據(jù)庫查詢接口、Web搜索接口等。工具層的設(shè)計質(zhì)量很大程度上決定了智能體的實(shí)際可用性。應(yīng)用與交互層是用戶直接接觸的部分?？梢允蔷W(wǎng)頁聊天框、IM機(jī)器人比如釘釘/企微機(jī)器人、命令行工具、甚至語音交互這些形式對智能體內(nèi)部狀態(tài)的要求差別很大。例如IM場景需要處理異步消息和會話中斷恢復(fù)Web場景則更重視流式輸出效果。這六層說完你大概能感受到智能體不是“一個大模型包打天下”而是一個系統(tǒng)工程。接下來我會挑幾個技術(shù)復(fù)雜度最高、踩坑最多的層深入講。2.1 工具選型之前的靈魂拷問你要做的是哪種智能體正式開始寫代碼之前有一件事必須先想清楚你的場景到底需要哪種智能體。我見過最典型的返工案例就是有人一上來直接上多智能體框架結(jié)果業(yè)務(wù)邏輯簡單反倒被框架的并發(fā)和通信機(jī)制拖累原本兩天的活兒拖了一周。從復(fù)雜度維度來分智能體大致有五種形態(tài)。第一是單輪工具調(diào)用型。用戶輸入一句指令A(yù)gent判斷要調(diào)用哪個工具調(diào)用完直接把結(jié)果返回。比如“幫我查一下今天北京的天氣”查詢天氣API就是一次調(diào)用。這種最簡單不需要做狀態(tài)管理本質(zhì)上就是“意圖識別工具路由”。第二是多輪任務(wù)執(zhí)行型。用戶給一個目標(biāo)Agent內(nèi)部要拆成多個步驟每個步驟可能需要不同的工具而且步驟之間有依賴關(guān)系。比如“幫我把這份Excel里的數(shù)據(jù)清洗一下剔除空行把金額列格式化成萬元再生成一份圖表”。這需要Agent維護(hù)一個中間狀態(tài)知道當(dāng)前執(zhí)行到哪一步。第三是對話式任務(wù)型。在第二類的基礎(chǔ)上用戶可能中途介入、修正指令、追加需求。比如“停一下金額不要格式化了先給我看一下前10行數(shù)據(jù)”。這對Agent的上下文管理能力要求更高要能隨時暫停當(dāng)前計劃、處理新指令、然后決定繼續(xù)還是調(diào)整。第四是自主規(guī)劃型。用戶給一個模糊的長期目標(biāo)Agent自己制定計劃并逐步執(zhí)行過程中可以自主調(diào)整策略。比如“幫我盯著這個競品網(wǎng)站每周整理一次更新動態(tài)并生成簡報”。這種需要有定時觸發(fā)機(jī)制、跨Session的記憶、以及異常處理策略。第五是多智能體協(xié)作型。多個Agent各有分工通過某種通信機(jī)制協(xié)作完成復(fù)雜目標(biāo)。比如“銷售日報智能體”和“客戶畫像智能體”協(xié)同給市場部生成每日線索質(zhì)量分析。這種需要設(shè)計通信協(xié)議、任務(wù)分發(fā)和結(jié)果匯聚機(jī)制。我做過的項(xiàng)目里第一類和第二類占了大多數(shù)。說句實(shí)在話很多第三類需求實(shí)際上是第二類加了一個“人工審核節(jié)點(diǎn)”沒必要真做成全雙工對話。這里給一個實(shí)用建議能用單Agent解決的就不要上多Agent能用流程編排解決的就不要讓模型自由發(fā)揮。智能體越“自由”不可控性越大調(diào)試成本直線上升。3. 核心引擎細(xì)節(jié)ReAct模式、Plan-and-Execute與狀態(tài)管理Agent核心引擎是智能體的“大腦”也是最需要吃透原理的部分。把它的工作方式作為一個“循環(huán)”來理解是最直觀的。我將它拆成六個環(huán)節(jié)。第一是感知Perceive接收當(dāng)前狀態(tài)包括用戶最新的輸入、歷史上下文、上一步的工具執(zhí)行結(jié)果等。第二是思考Think結(jié)合當(dāng)前狀態(tài)分析“現(xiàn)在是什么情況、需要做什么”。第三步是決策Act決定執(zhí)行哪個工具調(diào)用、傳什么參數(shù)。第四是執(zhí)行Execute真正調(diào)用外部工具并獲取結(jié)果這一步通常由代碼框架完成不經(jīng)過模型。第五是觀察Observe工具返回的結(jié)果作為新的“感知”進(jìn)入下一輪循環(huán)。第六是終止Finish達(dá)成用戶目標(biāo)或達(dá)到最大輪數(shù)限制后生成最終回復(fù)。這整個過程就是ReAct模式——Reasoning和Acting交替進(jìn)行。它的核心優(yōu)點(diǎn)在于把“推理”和“行動”解耦每一步都既可以推理也可以行動像人類的思考方式。通過一個實(shí)際例子來看這個循環(huán)的實(shí)際運(yùn)作。假設(shè)用戶說“幫我查一下某家公司的最新融資動態(tài)順便梳理一下最近三個月他們CEO的公開演講觀點(diǎn)”。Agent的第一輪會思考“用戶要兩件事我需要先搜索融資信息”然后調(diào)用Web搜索工具執(zhí)行后觀察返回的頁面片段。第二輪思考可能是“搜索結(jié)果比較雜需要篩選一下時間再看一下CEO演講的信息”于是再調(diào)用一次搜索或者調(diào)用新聞聚合API。第三輪如果沒有找到演講信息Agent會考慮換個搜索詞或者直接搜索這個CEO的公開演講如果還是找不到可能會給用戶一個誠實(shí)的說明“CEO演講信息未找到已搜索N個關(guān)鍵詞建議補(bǔ)充信息來源?！边@里有個容易被忽略的重點(diǎn)模型的每一次“思考”和“行動”都會被記錄在上下文中這意味著上下文長度決定了Agent能“想多少步”。如果你的模型上下文只有4K那基本上做不了真正的多輪工具調(diào)用——搞兩三輪就滿了。這也是為什么做Agent開發(fā)建議選擇長上下文模型。Plan-and-Execute模式與ReAct不同它省去每步推理過程。給定目標(biāo)后Agent先綜合生成一份完整計劃再逐步執(zhí)行。這種模式適合步驟相對明確的場景優(yōu)點(diǎn)是Token消耗低、執(zhí)行穩(wěn)定缺點(diǎn)是不夠靈活用戶中途改變主意時調(diào)整成本較高。我用過的一個折中方案是主干用Plan-and-Execute做規(guī)劃但每個執(zhí)行步驟里用ReAct做異常兜底。具體來講如果某個步驟執(zhí)行失敗自動退化成ReAct——模型查看錯誤信息自行調(diào)整工具調(diào)用參數(shù)進(jìn)行重試。這種混合模式在實(shí)際項(xiàng)目中表現(xiàn)不錯比單一模式更穩(wěn)健。狀態(tài)管理是Agent引擎里最容易被忽略的細(xì)節(jié)。很多時候Demo看起來“聰明”一旦恢復(fù)會話、覆蓋長任務(wù)就出現(xiàn)“失憶”問題。我的做法是設(shè)計一個“任務(wù)狀態(tài)對象”至少包含以下字段任務(wù)ID、用戶ID、當(dāng)前狀態(tài)pending/running/paused/completed/failed、目標(biāo)描述、執(zhí)行計劃、每一步的執(zhí)行狀態(tài)與入?yún)?出參、已執(zhí)行的中間結(jié)果摘要、錯誤次數(shù)與錯誤信息列表。這個狀態(tài)對象有兩個關(guān)鍵用途。一是支持暫停與恢復(fù)。比如一個分析任務(wù)要跑十分鐘用戶中途說要改需求Agent可以先暫停等用戶改完再恢復(fù)執(zhí)行。實(shí)現(xiàn)上就是把正在跑的任務(wù)狀態(tài)持久化到數(shù)據(jù)庫恢復(fù)時讀取狀態(tài)并繼續(xù)。第二個用途是支持“智能體自我總結(jié)”因?yàn)樯舷挛拇翱谟邢轆gent不可能把每一步原始結(jié)果都塞進(jìn)上下文我的方案是每執(zhí)行完一個步驟用模型生成一段不超過100字的摘要存入狀態(tài)對象作為下一輪思考的參考信息。這招“中間結(jié)果摘要化”很好用能有效延長Agent的有效工作輪次。3.1 Function Calling讓模型正確調(diào)用工具的三個關(guān)鍵設(shè)計工具調(diào)用能力是智能體真正能“干活”的基礎(chǔ)。目前主流模型都支持Function Calling或者Tool Use中文社區(qū)常把這幾個概念混著說這里統(tǒng)一一下OpenAI定義的是Function CallingAnthropic叫Tool Use開源社區(qū)沿用的詞是Tool Calling。本質(zhì)上都是同一件事——讓模型輸出結(jié)構(gòu)化JSON參數(shù)來調(diào)用外部工具而不是輸出自然語言。想讓模型“正確地”調(diào)用工具最關(guān)鍵的是API描述文檔的質(zhì)量。這個質(zhì)量直接決定成功率。我給一個自檢清單。第一函數(shù)名要語義清晰。不要用func1、process_data這種名字模型不是讀代碼的高手函數(shù)名就是它理解“什么時候用這個工具”的第一線索。比如search_web_articles(query, date_from, region)模型一看就知道是搜索網(wǎng)絡(luò)文章。第二參數(shù)描述要說清楚三件事這個參數(shù)的業(yè)務(wù)含義、有哪些合法取值、如果不傳會怎樣。例如參數(shù)region可填“中國大陸、港澳臺、其他區(qū)域默認(rèn)不填則不限區(qū)域”描述越具體模型越少胡亂發(fā)揮。第三要做到“用例子喂模型”。對于不太常用的工具在工具描述里附一個調(diào)用示例。有些API文檔會示范“當(dāng)用戶想了解北京天氣時調(diào)用get_weather(city北京, unitcelsius)”模型產(chǎn)生的幻覺就會大幅減少。最后再補(bǔ)充一個我踩過的坑Tool調(diào)用參數(shù)校驗(yàn)。模型生成的JSON參數(shù)雖然格式對但值可能是錯的——比如日期寫成“今天”或者把“最近三個月”解析成具體日期時因時區(qū)問題出錯。所以我的建議是在工具層設(shè)立一個“參數(shù)規(guī)范化層”專門負(fù)責(zé)把模型輸出的原始參數(shù)轉(zhuǎn)換成工具真正需要的格式比如把中文時間詞翻譯成時間戳把模糊的數(shù)字范圍換算成Upper和Lower。不要指望模型輸出一次就對要做校驗(yàn)、修正、重試機(jī)制。注意如果模型的函數(shù)調(diào)用三次都失敗建議記錄下來形成一個“模型不擅長調(diào)用工具”的分析。很多問題其實(shí)是工具描述不清晰而不是模型能力弱。我遇到過一個案例同一個工具描述把“操作執(zhí)行失敗時請調(diào)用get_error_detail查詢詳情”改成“遇到錯誤時調(diào)用get_error_detail接口獲取錯誤原因再根據(jù)原因決定是否重試”模型的重試成功率從62%升到88%。說明描述方式重大影響行為。4. 實(shí)操環(huán)節(jié)從零搭建一個多工具智能體前面把架構(gòu)拆得比較細(xì)這節(jié)進(jìn)入實(shí)戰(zhàn)從頭搭建一個具備“搜索、計算、數(shù)據(jù)庫查詢”三類工具的智能體用來完成一個復(fù)合型任務(wù)。我們以“從商品庫中找出銷售額排名前十的商品再搜索這些商品的相關(guān)新聞最后生成一份簡報”為例。這個場景覆蓋了智能體的核心能力數(shù)據(jù)庫查詢SQL工具、計算排名計算可以交給代碼解釋器、Web搜索抓取新聞、內(nèi)容生成匯總簡報。整個Demo用Python寫Agent框架自己實(shí)現(xiàn)不依賴重型商業(yè)框架方便你理解底層邏輯。4.1 環(huán)境準(zhǔn)備與工具定義使用Python 3.10以上的版本依賴包安裝清單包括openai或anthropic看用什么模型、pydantic用于參數(shù)模型、flask或fastapi用于外部服務(wù)模擬、sqlite3自帶的可以做數(shù)據(jù)庫工具。我們需要定義三個工具。第一個是query_product_sales對應(yīng)SQL查詢工具負(fù)責(zé)執(zhí)行SELECT語句。它的輸入?yún)?shù)包括表名、列名和條件第二個是execute_python_code對應(yīng)代碼計算器用來做數(shù)據(jù)加工第三個是search_web_news默認(rèn)調(diào)用一個搜索API接口。用JSON Schema來描述這三個工具示例如下。真實(shí)項(xiàng)目中工具描述會更長但結(jié)構(gòu)保持一致。[ { type: function, function: { name: query_product_sales, description: 查詢商品銷售數(shù)據(jù)庫返回滿足條件的記錄列表。表名為products重點(diǎn)字段包括product_id, product_name, category, total_sales_31d近31天銷售額, total_orders訂單量, updated_date。, parameters: { type: object, properties: { fields: {type: array, items: {type: string}, description: 需要查詢的字段名列表例如[product_name,total_sales_31d]}, condition: {type: string, description: SQL WHERE子句條件不包含WHERE關(guān)鍵字。例如\category數(shù)碼\}, order_by: {type: string, description: 排序字段例如\total_sales_31d DESC\}, limit: {type: integer, description: 返回記錄的最大條數(shù)默認(rèn)10} }, required: [fields, condition, order_by, limit] } } }, { type: function, function: { name: execute_python_code, description: 執(zhí)行一段Python代碼用于數(shù)據(jù)計算和聚合。代碼在受限環(huán)境中執(zhí)行可安全處理數(shù)據(jù)支持運(yùn)行數(shù)學(xué)運(yùn)算、列表推導(dǎo)、字符串處理。, parameters: { type: object, properties: { code: {type: string, description: 完整的Python代碼代碼通過變量data接收輸入數(shù)據(jù)處理結(jié)果顯示在最終返回中。例如data是list[dict]你想排序取前10可以寫sorted_data sorted(data, keylambda x: x[total_sales_31d], reverseTrue)[:10]} }, required: [code] } } }, { type: function, function: { name: search_web_news, description: 根據(jù)關(guān)鍵詞搜索互聯(lián)網(wǎng)新聞返回標(biāo)題、鏈接、發(fā)布時間和摘要片段。, parameters: { type: object, properties: { query: {type: string, description: 搜索關(guān)鍵詞例如某品牌 最新新聞}, max_results: {type: integer, description: 返回結(jié)果條數(shù)默認(rèn)5} }, required: [query, max_results] } } } ]這里我要強(qiáng)調(diào)一下execute_python_code的工具描述。為什么要在描述里給示例代碼因?yàn)槟Ｐ徒?jīng)常搞不清楚“我應(yīng)該寫完整的代碼還是偽代碼”給一個具體的示例它可以照著做。我實(shí)際測試中發(fā)現(xiàn)加了示例后模型生成的代碼質(zhì)量有明顯提升不容易出現(xiàn)“只寫函數(shù)定義忘記調(diào)用”的問題。4.2 Agent運(yùn)行主循環(huán)自己寫還是用框架如果你只是想快速驗(yàn)證可以用業(yè)界主流編排框架比如LangChain、LlamaIndex、AutoGen、CrewAI、Dify等它們內(nèi)置了Agent循環(huán)和工具調(diào)用邏輯。但如果你想把底層原理吃透我強(qiáng)烈建議你至少手寫一遍極簡Agent循環(huán)。我手寫版本的代碼邏輯大致如下。def run_agent(user_query, tools, system_prompt, max_iterations8): # 初始化對話歷史 messages [{role: system, content: system_prompt}] messages.append({role: user, content: user_query}) # 準(zhǔn)備tool definitions從tools中提取 tool_schemas [t.get_schema() for t in tools] for step in range(max_iterations): # 請求模型允許調(diào)用工具 response client.chat.completions.create( modelMODEL_NAME, messagesmessages, toolstool_schemas, temperature0.3, # 工具調(diào)用場景溫度不宜太高 ) msg response.choices[0].message # 如果模型沒有要求調(diào)用工具說明任務(wù)完成直接返回 if not msg.tool_calls: return msg.content # 否則追加模型輸出 messages.append(msg) # 遍歷每個工具調(diào)用依次執(zhí)行 for tool_call in msg.tool_calls: func_name tool_call.function.name func_args json.loads(tool_call.function.arguments) # 在tools列表中查找并執(zhí)行 result execute_tool(func_name, func_args) # 把工具結(jié)果返回給模型result是字符串化后的數(shù)據(jù) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse)[:8000] # 防止超長截斷 }) # 超過最大迭代次數(shù)強(qiáng)制收尾 return 已達(dá)最大步驟數(shù)未能完成任務(wù)請簡化需求或補(bǔ)充信息。這個循環(huán)大概是Agent編排引擎的最核心骨架。有幾個細(xì)節(jié)值得單獨(dú)講。第一關(guān)于temperature參數(shù)建議在做工具調(diào)用時設(shè)置低一點(diǎn)的溫度0.2~0.4保證模型的輸出更穩(wěn)定、更少隨機(jī)發(fā)散做內(nèi)容生成和創(chuàng)意思考時再調(diào)高溫度。我見過一個“機(jī)智”的辦法同一套消息先用低溫跑工具調(diào)用拿到結(jié)果后用高溫生成最終文案效果挺好。第二關(guān)于工具結(jié)果截斷我在代碼里加了[:8000]的限制。這是實(shí)戰(zhàn)中必須做的防御否則工具返回一個超長文本比如報告全文直接把上下文擠爆。更好的做法是對返回內(nèi)容先做摘要再塞進(jìn)上下文。如果是結(jié)構(gòu)化數(shù)據(jù)只選關(guān)鍵字段透傳。第三關(guān)于max_iterations這是一種“及時止損”機(jī)制。很多Demo失敗的原因就是Agent陷入無限循環(huán)——調(diào)工具、報錯、重試、再報錯。循環(huán)上限建議設(shè)置在6-10之間防止成本失控。4.3 手動跑一遍這個案例把上述代碼跑起來用戶輸入是“找出銷售額前十的商品然后查一下它們最近的新聞生成一份簡報”。大致執(zhí)行的流程如下。第一步Agent先調(diào)用query_product_sales構(gòu)造查詢參數(shù)。我期望它能生成類似這樣的參數(shù)fields[product_name,total_sales_31d,category]condition11order_bytotal_sales_31d DESClimit20。注意我設(shè)limit是20而不是10。為什么因?yàn)槿绻蝗?0名后面篩選時余地不夠取20名再做二次排序更穩(wěn)妥。這屬于“給模型留容錯裕度”的技巧純靠模型自己領(lǐng)悟容易翻車可以在system prompt里提示“取數(shù)時可以適當(dāng)多取最終再篩選”。第二步SQL查詢返回20條商品記錄后Agent調(diào)用execute_python_code對data做排序并選出前十。它生成的代碼大致是sorted_data sorted(data, keylambda x: x[total_sales_31d], reverseTrue) top10 sorted_data[:10] result [{rank: i1, name: item[product_name], sales: item[total_sales_31d]} for i, item in enumerate(top10)] result第三步Agent需要拿著這10個商品名去搜索新聞。這里有個常見的操作一次性調(diào)用10次search_web_news還是合并為一次實(shí)際中我建議一次搜索一個商品但也建議控制并行度否則工具延遲會拖慢整體流程。我們的循環(huán)里每個tool_call都會串行執(zhí)行10次搜索可能得等不少時間。一種加速辦法是第一輪先查銷量前3的商品生成簡報后告訴用戶“已覆蓋前三剩余7個如果需要可以繼續(xù)”這樣更快且不會顯得“不干完活”。第四步 Agent把新聞搜索的結(jié)果和商品銷售數(shù)據(jù)匯總調(diào)用最終的文本生成能力也就是不讓他調(diào)用工具在messages里給出所有數(shù)據(jù)讓他寫簡報輸出一份結(jié)構(gòu)化的中文簡報。整個過程跑下來你會看到模型“糾結(jié)”的一些痕跡。比如它會在一次回復(fù)里同時調(diào)用兩個搜索工具或者搜索的時候把商品名搞錯。這些都是正?，F(xiàn)象調(diào)優(yōu)方向就是我們上面說的工具描述優(yōu)化和參數(shù)校驗(yàn)。4.4 可觀測性設(shè)計沒有日志排查的Agent就是一場災(zāi)難智能體項(xiàng)目開發(fā)中最容易忽視也最致命的是可觀測性。普通API開發(fā)出錯看堆棧就行Agent出錯卻要面對“模型哪一步想歪了”這種問題。沒有完整的日志調(diào)試等于盲人摸象。我的做法是做一個“思維鏈追蹤器”。每輪循環(huán)里把以下信息記錄下來當(dāng)前的步驟編號、模型的思考內(nèi)容就是assistant message里的content部分有時為null、調(diào)用的工具名稱和參數(shù)、工具返回的狀態(tài)碼和數(shù)據(jù)前500字符、加了這輪之后的總Token數(shù)、當(dāng)前迭代到第幾步。最后把這些日志轉(zhuǎn)成可視化的時間線一眼就能看到Agent在哪一步走偏了。這里再分享一個從實(shí)際項(xiàng)目中總結(jié)的經(jīng)驗(yàn)Agent的“錯誤”分兩類——一類是模型理解錯了比如該調(diào)A工具調(diào)成了B另一類是需要多次嘗試才成功的“軟錯誤”比如第一次搜索沒結(jié)果第二次換關(guān)鍵詞才搜到。后者其實(shí)是正?，F(xiàn)象不要一看到重試就覺得是bug。我見過一個調(diào)優(yōu)案例把“單次搜索失敗就放棄”調(diào)整為“允許最多3次改詞重試”任務(wù)的最終成功率從78%升到了94%。成本追蹤同樣不能忘。每一輪Agent循環(huán)都是多次模型調(diào)用Token消耗上升很快。建議在日志里記錄每一輪的Tokens并設(shè)置“單次任務(wù)Token上限”超過上限就強(qiáng)制結(jié)束。5. 工具層設(shè)計從簡單API調(diào)用到多工具編排工具層決定了智能體能力的邊界也是最需要精細(xì)設(shè)計的一層。我用“三個原則”來概括工具層設(shè)計。第一個原則是“工具盡量細(xì)粒度”。不要設(shè)計一個超級工具把所有事干了。比如“處理數(shù)據(jù)”不如拆成“排序”“過濾”“聚合”“繪圖”四個工具。細(xì)粒度工具的好處是模型更容易理解每個工具的適用場景參數(shù)也更簡單。但也不是越細(xì)越好太細(xì)會導(dǎo)致模型需要連續(xù)調(diào)用很多次才能完成任務(wù)增加Token開銷和失敗概率。一般經(jīng)驗(yàn)是保持每個工具的職責(zé)單一但入?yún)⒃O(shè)計要靈活。第二個原則是“返回結(jié)果要結(jié)構(gòu)化且減幅”。工具返回給模型的數(shù)據(jù)最好用JSON格式而且要預(yù)先壓縮。比如數(shù)據(jù)庫查詢返回100行數(shù)據(jù)如果全塞給模型上下文很快就爆了。我的做法是工具層內(nèi)置“結(jié)果摘要函數(shù)”對于超過一定長度的結(jié)果先做聚合摘要再返回。比如查詢銷售額明細(xì)返回的是{total_records: 10000, top_10: [...], summary: 前三名是A、B、C}而不是直接給一萬條記錄。模型的決策需要的是關(guān)鍵信息和概要不是原始數(shù)據(jù)。第三個原則是“工具要有容錯和可恢復(fù)機(jī)制”。工具執(zhí)行失敗時返回給模型的不應(yīng)該只是一句“ERROR”。要返回有信息量的錯誤信息——失敗了哪一步、可能的原因、建議的重試方向。比如“數(shù)據(jù)庫連接超時5秒可重試或檢查條件”模型就能據(jù)此調(diào)整。我在實(shí)際開發(fā)中專門寫過一個“錯誤信息規(guī)范化模塊”把不同工具的錯誤統(tǒng)一成標(biāo)準(zhǔn)格式智能體判斷錯誤處理方式的準(zhǔn)確率提升明顯。5.1 工具與記憶要不要給Agent配一個外部記憶智能體的記憶力決定了它是“見過就忘”還是“越來越懂你”。我在做項(xiàng)目時越往后越發(fā)現(xiàn)記憶設(shè)計是提升體驗(yàn)的關(guān)鍵。智能體的記憶可以分三層短期記憶就是對話上下文已經(jīng)聊過長期記憶是關(guān)于用戶偏好的持久化信息需要寫入數(shù)據(jù)庫工作記憶是當(dāng)前任務(wù)的中間狀態(tài)前面講的“任務(wù)狀態(tài)對象”。三層記憶各自有不同的技術(shù)實(shí)現(xiàn)。長期記憶的實(shí)現(xiàn)我比較推薦向量數(shù)據(jù)庫加RAG的做法。每次對話結(jié)束時用模型生成“用戶關(guān)鍵信息摘要”比如“用戶偏好簡潔回復(fù)關(guān)注數(shù)據(jù)準(zhǔn)確性”把摘要向量化存到向量數(shù)據(jù)庫。下次對話開始時檢索相關(guān)性最高的幾條摘要注入到System Prompt里讓模型“想起”用戶是誰。這種“摘要化記憶”比直接存對話原文好用得多不僅省存儲還能避免私密信息泄露。不過要注意的是長期記憶也是一把雙刃劍。如果摘要寫得不準(zhǔn)確反而會誤導(dǎo)模型。我踩過的一個坑是在某個項(xiàng)目里系統(tǒng)自動把“用戶催過兩次進(jìn)度”摘要成了“用戶性格急躁對回復(fù)速度高度敏感”結(jié)果后續(xù)每次回復(fù)都過度解釋用戶體驗(yàn)很差。所以我的建議是記憶摘要要過濾主觀判斷只記錄客觀事實(shí)和明確偏好。比如“用戶在上次任務(wù)中要求用表格呈現(xiàn)數(shù)據(jù)”可以記“用戶好像很急”就不應(yīng)該記。5.2 多智能體協(xié)作一人干活和多人干活怎么權(quán)衡聊到多智能體很多初學(xué)者會興奮覺得“越多越智能”。實(shí)際做下來我的看法是多智能體協(xié)作是“殺雞用牛刀”的高頻場景必須謹(jǐn)慎。多智能體系統(tǒng)的核心難點(diǎn)在于如何分工、如何通信、如何避免重復(fù)勞動和資源浪費(fèi)。常見的方案有三種。第一種是主管-下屬模式。由一個“主管Agent”接收用戶任務(wù)分解后分發(fā)給多個“專家Agent”并行處理等結(jié)果回來后由主管統(tǒng)一匯總。這種模式適合任務(wù)可以明確拆分的比如“產(chǎn)品分析報告”—市場Agent整理競品銷售Agent整理銷冠數(shù)據(jù)研發(fā)Agent整理技術(shù)動態(tài)最后由主管整合。第二種是流水線模式。任務(wù)按順序經(jīng)過多個Agent每個Agent處理自己負(fù)責(zé)的階段再傳給下一個。比如“數(shù)據(jù)清洗Agent → 數(shù)據(jù)分析Agent → 報告生成Agent”。這種模式需要提前設(shè)計好上下接口的數(shù)據(jù)協(xié)議任務(wù)流清晰。第三種是Debate模式。多個Agent扮演不同立場角色互相提出觀點(diǎn)和質(zhì)疑最后匯總。這種模式適合需要多角度分析的場景比如“對某市場策略做可行性分析”正方和反方Agent互相反駁最后給決策參考。我這邊的建議是在多智能體架構(gòu)中優(yōu)先采用主管-下屬模式因?yàn)檫@種模式對流程的控制能力最強(qiáng)也最容易實(shí)現(xiàn)斷點(diǎn)重試。Debate模式Idear很酷但Token消耗大、結(jié)果波動大不適合生產(chǎn)環(huán)境。此外多智能體之間的通信機(jī)制建議采用“結(jié)構(gòu)化消息”而不是自然語言聊天。自然語言通信容易產(chǎn)生歧義調(diào)試?yán)щy。結(jié)構(gòu)化消息可以用協(xié)議約定消息字段比如{sender: scheduler, receiver: market_agent, task_type: research, payload: {...}}。6. 模型選型與接入方案閉源API、開源模型還是混合方案模型是智能體的大腦選型的決策樹我把它總結(jié)為三個問題。第一你的業(yè)務(wù)對數(shù)據(jù)安全性要求多高如果數(shù)據(jù)不能出內(nèi)網(wǎng)基本只能選開源模型或私有化部署的商業(yè)模型。第二你的場景對能力上限的要求多高例如復(fù)雜推理、長文檔理解、多語言能力這些都對更頂尖的模型更友好。第三你的預(yù)算是多少Token成本要算細(xì)賬。這里給一個成本核算的小示例。假設(shè)每天活躍用戶1000人每人平均對話30輪每輪模型返回200tokens模型價格按常見閉源模型的中檔價格估算。如果N輪中包含工具調(diào)用上下文實(shí)際tokens往往是輸出的好幾倍。我粗略算了一下這類場景如果用性能較強(qiáng)的模型一個月的Token成本可能要到一萬塊錢這個量級。如果你用的是開源模型自部署主要成本是GPU機(jī)器比如一張消費(fèi)級顯卡對于7B左右的模型推理夠用但能否撐住并發(fā)要看工程優(yōu)化水平。兩種路線各有利弊沒有絕對優(yōu)解關(guān)鍵看場景和預(yù)算。團(tuán)隊(duì)不趕時間、技術(shù)儲備夠的話可以走混合路線主體用開源模型支撐大多數(shù)高頻任務(wù)對復(fù)雜推理任務(wù)路由到能力更強(qiáng)的商業(yè)模型。這種“能力路由”架構(gòu)用一個模型網(wǎng)關(guān)層實(shí)現(xiàn)統(tǒng)一模型接口底層可隨時替換。我在項(xiàng)目中實(shí)踐過效果不錯。這里提一個模型網(wǎng)關(guān)層的設(shè)計統(tǒng)一輸入輸出格式、統(tǒng)一錯誤處理、可配置路由策略例如按輸入長度/任務(wù)類型路由。有了網(wǎng)關(guān)后續(xù)換模型、做灰度都方便得多。6.1 開源模型與閉源模型在Agent場景下的優(yōu)劣勢對比在Agent場景下模型的核心能力不只是“生成自然語言”還包括嚴(yán)格遵循系統(tǒng)指令的能力、準(zhǔn)確輸出JSON結(jié)構(gòu)化內(nèi)容的能力、長上下文中的信息保持能力、以及最關(guān)鍵的“對齊工具調(diào)用格式”的能力。從我的實(shí)際測試看閉源商用模型在Function Calling的格式遵循上做得比較成熟官方API文檔就寫得很清楚很少出現(xiàn)工具調(diào)用格式亂掉的狀況。開源模型的兼容性則要看具體型號有些開源模型雖然也宣稱支持Tool Call但原生格式可能與你的Agent框架不完全兼容需要做一層適配。好消息是現(xiàn)在不少開源模型都在強(qiáng)化工具調(diào)用能力尤其一些國內(nèi)的開源模型在中文工具描述理解上表現(xiàn)相當(dāng)好效果不輸閉源模型在中低復(fù)雜度場景下的表現(xiàn)。給一個非科學(xué)的經(jīng)驗(yàn)值如果你要做的Agent復(fù)雜度在“單工具調(diào)用簡單任務(wù)”級別開源模型完全夠用如果是“多工具協(xié)同復(fù)雜推理長流程任務(wù)”建議優(yōu)先考慮能力更強(qiáng)的商業(yè)模型或者把開源模型與商業(yè)模型混合路由使用。另外還有一個容易被忽略的點(diǎn)開源模型的上下文長度如果不是特別長長任務(wù)場景的可用性會受影響。選型時要注意不同型號的上下文窗口差異別拿短上下文的模型硬跑長任務(wù)。6.2 混合模型路由策略用低成本完成高質(zhì)量任務(wù)混合路由是我在項(xiàng)目中實(shí)踐過的一個有效方案。核心思想是不同的任務(wù)類型對模型能力的要求不同很多高頻任務(wù)其實(shí)并不需要最貴的模型。設(shè)計一套路由規(guī)則把簡單任務(wù)分流到便宜的模型上把難任務(wù)交給更強(qiáng)的模型總體成本可以下降很可觀。舉一個可落地的例子。某客戶的智能體系統(tǒng)每天處理兩類任務(wù)一類是“查快遞單號”模型只需要從用戶輸入中提取出快遞公司和單號再調(diào)用查詢API這類任務(wù)簡單用便宜的模型就夠了另一類是“總結(jié)與分析市場報告”需要很強(qiáng)的理解能力用更貴的模型。路由規(guī)則可以這樣設(shè)置根據(jù)任務(wù)長度和是否需要調(diào)用工具的參數(shù)數(shù)量來判斷。如果用戶輸入短工具調(diào)用參數(shù)是枚舉類用便宜模型如果用戶輸入長工具調(diào)用參數(shù)復(fù)雜、任務(wù)本身是多步驟的用貴模型。更精細(xì)的做法是先用便宜模型做初步判斷如果遇到它沒把握的情況再升級到貴模型。我在實(shí)踐中用的是一種“置信度閾值”策略便宜模型輸出時附帶一個置信度分?jǐn)?shù)低于閾值就轉(zhuǎn)給強(qiáng)模型重跑。這個策略被驗(yàn)證過能在功能質(zhì)量下降幅度很小的情況下節(jié)約不少Token成本。7. 數(shù)據(jù)與知識層RAG、Fine-tuning到底怎么選數(shù)據(jù)與知識層要解決的核心問題是讓智能體“知道別人不知道的信息”。兩個主流技術(shù)路線是RAG和Fine-tuning很多新手喜歡把兩者對立起來我理解下來它們解決的其實(shí)是不同層次的問題。RAG全稱檢索增強(qiáng)生成核心流程是文檔切塊→向量化→存儲到向量數(shù)據(jù)庫→用戶提問時檢索最相關(guān)的塊→把檢索結(jié)果塞進(jìn)Prompt→讓模型基于這些信息回答。RAG適合的是“知識量巨大、需要實(shí)時更新、來源多”的場景。比如企業(yè)內(nèi)部資料庫、行業(yè)資訊追蹤、客服知識庫這些都是典型RAG場景。它的優(yōu)點(diǎn)是更新知識只要換文檔不用重新訓(xùn)練模型它的缺點(diǎn)是檢索質(zhì)量直接決定回答質(zhì)量有引用鏈條可查但遇到檢索不到的情況回答就會“胡編”。Fine-tuning全稱微調(diào)核心流程是準(zhǔn)備一批符合輸出格式要求的高質(zhì)量樣本用這些樣本對基礎(chǔ)模型做增量訓(xùn)練讓模型學(xué)會你要的風(fēng)格和格式。Fine-tuning適合的是“輸出格式固定、風(fēng)格要求嚴(yán)格、推理規(guī)則明確”的場景。比如我要讓模型嚴(yán)格按照J(rèn)SON格式輸出企業(yè)財報摘要或者模仿特定風(fēng)格寫營銷文案Fine-tuning效果比RAG好。用一句話總結(jié)我的取舍經(jīng)驗(yàn)RAG負(fù)責(zé)“給模型找材料”Fine-tuning負(fù)責(zé)“教模型怎么說話”。大多數(shù)智能體項(xiàng)目優(yōu)先做RAG只有當(dāng)你發(fā)現(xiàn)“材料都對但輸出格式/風(fēng)格總不對”的時候再考慮Fine-tuning。也有兩者結(jié)合的方案先用RAG檢索材料再用一個大模型或Fine-tuned小模型做格式化輸出。7.1 文檔切塊的細(xì)節(jié)塊長、重疊、索引優(yōu)化RAG系統(tǒng)效果很受文檔切塊影響切塊策略不同檢索結(jié)果可能天壤之別。我把切塊的關(guān)鍵參數(shù)和踩坑經(jīng)驗(yàn)總結(jié)如下。塊大小通常建議在300到800字之間設(shè)越大上下文信息越全但檢索精度越差冗余噪音也越多設(shè)太小又容易丟失上下文語義。這里說的字是漢字字?jǐn)?shù)英文Token差不多按比例折算。實(shí)際調(diào)優(yōu)方法是拿一份代表文檔多嘗試幾種塊大小對比檢索命中率再結(jié)合下游回答質(zhì)量來選。塊重疊指的是相鄰塊之間重合的部分一般建議設(shè)塊大小的10%~20%。為什么需要重疊因?yàn)榍袎K通常按固定長度切很可能把一個主題從中間砍斷重疊可以在一定程度上彌補(bǔ)這種割裂。索引方面向量索引加倒排索引的混合檢索效果往往優(yōu)于純向量檢索。純向量檢索的優(yōu)點(diǎn)是語義理解強(qiáng)缺點(diǎn)是遇到專有名詞比如產(chǎn)品型號、人名容易飄BM25這類倒排索引的優(yōu)點(diǎn)是精確匹配強(qiáng)缺點(diǎn)是理解不了同義語義?；旌蠙z索把兩者結(jié)果用RAG Fusion方式融合實(shí)際效果穩(wěn)定不少。再補(bǔ)充一個“父子塊”方案。把長文檔切成粗粒度的大塊父塊同時在內(nèi)部切出更細(xì)的小塊子塊。檢索時用子塊匹配用戶問題命中后把對應(yīng)的父塊整塊送給模型。因?yàn)楦笁K上下文信息更全模型能讀到更完整的上下文子塊命中又足夠精準(zhǔn)。這種方案在處理技術(shù)文檔、學(xué)術(shù)論文時特別好用。7.2 向量數(shù)據(jù)庫選型參考向量數(shù)據(jù)庫是RAG的核心底座。給出按場景的選型參考表格。場景推薦方案理由Demo原型、數(shù)據(jù)量10萬條輕量級方案本地文件型零運(yùn)維、上手快適合快速驗(yàn)證中小型項(xiàng)目、數(shù)據(jù)量10萬~500萬條開源向量數(shù)據(jù)庫性能與功能平衡支持多種索引大規(guī)模生產(chǎn)、數(shù)據(jù)量500萬條成熟的數(shù)據(jù)庫服務(wù)或自建集群高可用、水平擴(kuò)展能力更強(qiáng)有完整監(jiān)控已有業(yè)務(wù)數(shù)據(jù)庫的團(tuán)隊(duì)在原有數(shù)據(jù)庫上加向量擴(kuò)展減少額外組件利用已有運(yùn)維體系選型還有幾個非功能性指標(biāo)要重點(diǎn)看索引構(gòu)建速度、查詢延遲、過濾查詢能力比如按時間、權(quán)限過濾、更新刪除的實(shí)時性、以及與現(xiàn)有技術(shù)棧的集成便利性。不要只盯著基準(zhǔn)測試的分?jǐn)?shù)生產(chǎn)環(huán)境最煩的是運(yùn)維問題。另外我建議如果數(shù)據(jù)量級在千萬以下別自己搭分布式向量數(shù)據(jù)庫用成熟方案夠用了自建集群大多是給自己找事。8. 應(yīng)用層與交互體驗(yàn)如何讓智能體像一個靠譜的同事應(yīng)用層是用戶直接感知的一層也是智能體“像不像真人”的體驗(yàn)關(guān)鍵。我總結(jié)下來應(yīng)用層設(shè)計有三個重點(diǎn)流式輸出、意圖確認(rèn)與澄清、多輪會話管理。流式輸出這個詞可能有人不熟就是模型生成內(nèi)容的同時一個字一個字地推送給用戶。如果沒有流式輸出用戶提問后要等幾秒甚至十幾秒才能看到完整回復(fù)體驗(yàn)非?！氨铩?。流式輸出能讓用戶先看到文字在跳動感覺系統(tǒng)在“思考”?，F(xiàn)在主流大模型API都支持SSE流式輸出實(shí)現(xiàn)成本不高強(qiáng)烈建議啟用。意圖澄清是容易被忽視但很影響體驗(yàn)的環(huán)節(jié)。用戶在提需求時往往信息不足比如“幫我看一下最近銷售情況”這時好的Agent應(yīng)該追問“是看哪個區(qū)域的什么時間段按銷售額還是訂單量”而不是瞎猜一通直接執(zhí)行。我的做法是在Agent的System Prompt里明確指示“如果用戶需求存在多種合理解釋且會影響工具參數(shù)必須向用戶確認(rèn)選項(xiàng)而不是自行假設(shè)”。多輪會話管理涉及用戶發(fā)言、Agent回復(fù)、工具調(diào)用中間狀態(tài)全套的存儲和恢復(fù)。這里的難點(diǎn)是實(shí)現(xiàn)“任意的深度鏈接恢復(fù)”。比如用戶早上開了個任務(wù)中午關(guān)電腦走了晚上打開網(wǎng)頁想接著聊系統(tǒng)應(yīng)該能恢復(fù)早上的上下文和任務(wù)狀態(tài)。這塊需要對話存儲的SessionID設(shè)計、狀態(tài)持久化和檢索增強(qiáng)。很多智能體項(xiàng)目在Demo階段不重視這個問題一到真實(shí)生產(chǎn)就暴露了。8.1 輸出結(jié)構(gòu)化的最佳實(shí)踐讓模型“好好說話”智能體的輸出不只給用戶看很多場景還要給下游系統(tǒng)消費(fèi)。這就涉及到結(jié)構(gòu)化輸出。比如Agent生成了“對這個商品的評估結(jié)論與三個建議”如果只是自然語言文本下游系統(tǒng)無法解析。更好的方案是要求模型輸出一個JSON對象包含“結(jié)論”和“建議”等字段。強(qiáng)制JSON輸出的技術(shù)方案有三種。一是用模型的JSON模式目前主流API基本支持你可以在請求參數(shù)里開一個JSON輸出模式模型會保證生成合法JSON二是用Function Calling的“偽裝調(diào)用”定義一個叫final_answer的函數(shù)明確函數(shù)參數(shù)就是一個結(jié)構(gòu)體讓模型把最終輸出放進(jìn)結(jié)構(gòu)體里返回這是很常用的技巧三是用提示詞強(qiáng)制約束比如“您必須以JSON格式回復(fù)格式為{...}”這個方法在開源模型上成功率不穩(wěn)定需要配合解析后端的容錯處理。我在實(shí)戰(zhàn)中的經(jīng)驗(yàn)是結(jié)構(gòu)化輸出的系統(tǒng)提示詞最忌諱的是“又要自由發(fā)揮又要JSON格式”。模型一旦糾結(jié)怎么組織語言JSON就容易被破壞。正確做法是把系統(tǒng)提示詞里的格式要求做到“死板而清晰”。比如你讓它輸出報告就規(guī)定好“只輸出JSON不要附帶任何解釋文字不要使用markdown代碼塊”這樣模型反而更穩(wěn)定。8.2 人工審核與人工接管Agent不能完全放飛再智能的Agent總有自己搞不定的時刻。我強(qiáng)烈建議在應(yīng)用層設(shè)計“人工審核節(jié)點(diǎn)”和“人工接管機(jī)制”。適用于以下場景涉及高風(fēng)險操作比如批量刪除數(shù)據(jù)、發(fā)送對外郵件、修改核心配置時Agent只負(fù)責(zé)生成操作計劃和參數(shù)執(zhí)行前必須等人工確認(rèn)。技術(shù)實(shí)現(xiàn)上可以攔截Agent的工具調(diào)用在Agent引擎和執(zhí)行層之間加一個“審批網(wǎng)關(guān)”對定義了“需要人工確認(rèn)”權(quán)限的工具先把調(diào)用申請發(fā)到人工審核界面審核通過后再真正執(zhí)行。這個機(jī)制用代碼實(shí)現(xiàn)就幾十行但對生產(chǎn)系統(tǒng)的安全性提升巨大。另外建議給智能體加一個“投降機(jī)制”當(dāng)連續(xù)多次嘗試失敗、或者檢測到任務(wù)超出能力范圍時允許Agent主動把會話轉(zhuǎn)移給真人員工。我的經(jīng)驗(yàn)是在System Prompt里寫清楚“當(dāng)用戶的需求涉及操作權(quán)限不足、系統(tǒng)能力不支持、或者連續(xù)3次重試仍未解決問題時請主動告知用戶將轉(zhuǎn)接人工支持并提供當(dāng)前的執(zhí)行日志摘要?！边@能讓用戶感覺Agent有分寸而不是硬撐到底。9. 常見問題與調(diào)試思路Agent開發(fā)者的避坑手冊代碼寫得再熟也會在Agent項(xiàng)目里遇到一堆“看起來玄學(xué)”的問題。這一節(jié)我按問題出現(xiàn)的頻率整理一個速查表每一條都是實(shí)戰(zhàn)中驗(yàn)證過的排查思路。癥狀可能原因排查與解決方向模型不調(diào)用工具總是直接文本回復(fù)工具描述不清晰或系統(tǒng)提示詞沒強(qiáng)調(diào)必須調(diào)工具檢查工具description是否寫清了“何時使用”在system prompt里強(qiáng)調(diào)“要獲取數(shù)據(jù)必須調(diào)用工具”模型調(diào)用工具但參數(shù)明顯不對工具參數(shù)描述不夠具體或模型缺少示例參考為每個參數(shù)加上“合法取值”說明必要時給一個調(diào)用示例工具調(diào)用陷入了循環(huán)錯誤信息不夠可操作模型不知道下一步怎么走讓工具返回“原因建議動作”結(jié)構(gòu)化錯誤信息限制最大迭代輪數(shù)第一次調(diào)用成功但后續(xù)上下文錯亂消息歷史拼接有問題檢查tool消息是否與assistant的tool_call關(guān)聯(lián)正確檢查上下文順序任務(wù)跑到一半模型“忘了”最初目標(biāo)上下文太長早期信息被擠出窗口做中間結(jié)果摘要把關(guān)鍵目標(biāo)固定在system prompt中每輪重述輸出偶爾不是合法JSON模型能力邊界使用JSON模式、Function Calling兜底或增加解析重試邏輯系統(tǒng)響應(yīng)太慢幾秒才回一句話鏈?zhǔn)秸{(diào)用太多、模型推理慢減少不必要的中間步驟考慮并行多個工具調(diào)用或用更強(qiáng)模型降低自我糾錯次數(shù)成本飆升明顯超出預(yù)算Token用量失控設(shè)“單任務(wù)Token上限”工具結(jié)果截斷與摘要化用便宜模型處理簡單任務(wù)排查Agent問題時最重要的一件事是“復(fù)現(xiàn)”。我建議在調(diào)試環(huán)境里把用戶輸入原樣重現(xiàn)一遍觀察每一步的工具調(diào)用和模型輸出。不要試圖靠經(jīng)驗(yàn)猜問題Agent的狀態(tài)空間太大猜不出來的。把日志打開逐輪分析比什么都管用。9.1 經(jīng)驗(yàn)總結(jié)Agent開發(fā)者的三個習(xí)慣做了一年多的Agent項(xiàng)目我歸納出三個受益很深的工作習(xí)慣。第一個習(xí)慣是“先寫測試用例再寫Agent”。好的做法是先準(zhǔn)備15~20條典型用戶語料覆蓋正常情況、模糊需求、異常輸入三大類然后讓Agent跑這些用例記錄通過率和失敗原因。每次調(diào)整系統(tǒng)提示詞、工具描述或模型參數(shù)后都重跑一遍這組用例做回歸。這樣迭代的每一步自己心里都有數(shù)。第二個習(xí)慣是“讓工具返回信息更豐富而不是讓模型猜”。工具層是最好優(yōu)化的地方把工具返回結(jié)果做得越規(guī)范模型的決策質(zhì)量就越高。這一原則我屢試不爽。第三個習(xí)慣是“面向簡化設(shè)計”。每當(dāng)覺得Agent邏輯越來越繞時就提醒自己——用戶要的是結(jié)果不是復(fù)雜度。簡化任務(wù)流程、簡化工具數(shù)量、減少中間環(huán)節(jié)往往可靠性顯著提升。給Agent留的“自由發(fā)揮”空間要越小越好只有把不確定性壓縮到最小系統(tǒng)才能真正穩(wěn)定。10. 寫在最后一點(diǎn)個人的體會回到題目說的“AI智能體的技術(shù)架構(gòu)與解決方案”。經(jīng)過這些項(xiàng)目的實(shí)操我的體會是智能體開發(fā)最難的往往不是模型或者算法層面的創(chuàng)新而是一大堆工程細(xì)節(jié)的堆疊——工具描述怎么寫、狀態(tài)怎么管、日志怎么記、出錯了怎么降級、超時時怎么兜底。這些都是“笨功夫”但決定了一個Agent項(xiàng)目是停留在Demo級的炫技還是能真正落到生產(chǎn)環(huán)境里跑業(yè)務(wù)。如果讓我給剛開始做智能體的朋友提一個最具體的建議那就是第一版永遠(yuǎn)用手寫的方式把“模型-工具-狀態(tài)”這個循環(huán)跑通不要急著套重型框架。等你親手調(diào)試過一輪、親手把模型“調(diào)教”得會正確使用工具之后再去看各類編排框架你的理解會完全不一樣——你會知道每一步發(fā)生了什么也就能判斷框架替你省了什么、又替你藏了什么坑。這個“手寫一遍”的過程我覺得是繞不開的功課。另外還有一個小技巧可以分享給每個工具都加一個“是否適合當(dāng)前任務(wù)的簡要說明”字段雖然模型不一定每次都會看但真的有用。而且這個字段還有個額外的好處——你在調(diào)試工具調(diào)用失敗時可以通過日志一眼看出模型為什么選錯工具絕大多數(shù)原因都會寫在它自己的思考里。善用模型自己留下的線索調(diào)試Agent的效率會高很多。