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