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