最近被問得最多的一類問題不是“智能體有什么用”而是“智能體到底是由什么組成的”。很多人把智能體和聊天機(jī)器人劃等號覺得接一個(gè)大模型API、套一個(gè)對話框就算完事結(jié)果一上線就發(fā)現(xiàn)它既記不住前幾輪說過的話也調(diào)用不了任何真實(shí)接口稍微復(fù)雜一點(diǎn)的需求就卡死。其實(shí)智能體是一個(gè)由多個(gè)模塊組成的小型系統(tǒng)大模型負(fù)責(zé)當(dāng)大腦規(guī)劃模塊決定先干什么后干什么記憶模塊保證它不“失憶”工具層讓它有手有腳反饋和容錯(cuò)機(jī)制讓它不至于在錯(cuò)路上狂奔。這篇文章就把“智能體的組成”這件事從頭到尾拆一遍把每一塊的職責(zé)、原理、踩坑點(diǎn)和使用時(shí)機(jī)都講清楚。適合三類人看正在做AI產(chǎn)品原型的學(xué)生或開發(fā)者準(zhǔn)備智能體相關(guān)崗位面試的人以及用過Coze、Dify但想搞清楚底層邏輯、考慮自己寫代碼搭建的工程師。1. 先拆結(jié)構(gòu)為什么說智能體不是“一個(gè)模型”而是五層系統(tǒng)1.1 為什么不能直接拿大模型當(dāng)智能體在拆組成之前必須先理解一個(gè)底層事實(shí)大模型本身不是智能體它是智能體的“大腦皮層”。模型做的是根據(jù)前面所有token預(yù)測下一個(gè)token輸入一段文本它返回一段文本這個(gè)過程里沒有目標(biāo)、沒有狀態(tài)、沒有外部世界。你問它“幫我查一下上海明天天氣”它只能編一個(gè)答案出來因?yàn)槟Ｐ陀?xùn)練數(shù)據(jù)和實(shí)時(shí)天氣之間沒有必然聯(lián)系。我習(xí)慣打一個(gè)比方大模型像一個(gè)記憶超群但沒有手腳、也記不住幾分鐘前聊過什么的顧問。他能給建議但沒法執(zhí)行他會順著你的話往下說但不會主動(dòng)盯住一個(gè)目標(biāo)想辦法繞開障礙。智能體的價(jià)值就是在這個(gè)顧問身邊配上一個(gè)秘書團(tuán)隊(duì)有人負(fù)責(zé)拆任務(wù)有人負(fù)責(zé)記筆記有人負(fù)責(zé)打電話查資料還有人負(fù)責(zé)檢查他有沒有把事辦錯(cuò)。這個(gè)“秘書團(tuán)隊(duì)”就是智能體的組成模塊。1.2 智能體為什么會“火”起來一次關(guān)鍵能力躍遷很多人以為智能體是這兩三年才有的概念其實(shí)Agent這個(gè)詞在強(qiáng)化學(xué)習(xí)、多智能體系統(tǒng)里已經(jīng)存在幾十年。真正讓LLM時(shí)代的智能體爆發(fā)是模型具備了Function Calling能力加上ReAct范式開始普及。ReAct就是把Reason推理和Act行動(dòng)交替執(zhí)行模型先根據(jù)當(dāng)前情況想一步然后決定調(diào)用哪個(gè)工具拿到工具返回的結(jié)果后再繼續(xù)推理。整個(gè)過程像一個(gè)人拿到任務(wù)后先想清楚目標(biāo)是什么選擇一個(gè)工具去獲取信息或執(zhí)行動(dòng)作看到結(jié)果再想下一步循環(huán)直到完成目標(biāo)或觸發(fā)終止條件?，F(xiàn)在你看到的所有智能體開發(fā)框架包括LangChain、LangGraph、Dify、Coze、AgentScope、Spring AI等底層基本都是這個(gè)循環(huán)的不同包裝。這不是巧合而是因?yàn)檫@套模式最貼合“目標(biāo)導(dǎo)向”的推理方式。你理解了這套范式再看智能體的組成就會順理成章。1.3 為什么要拆成模塊工程上不只是“為了好看”模塊化設(shè)計(jì)在智能體項(xiàng)目里不是理論潔癖而是實(shí)實(shí)在在的工程需要。我見過很多項(xiàng)目把智能體堆成一個(gè)巨大的Prompt所有邏輯都靠自然語言描述塞進(jìn)上下文結(jié)果改一個(gè)細(xì)節(jié)要?jiǎng)尤殖鰡栴}也無從查起。把智能體拆成模塊之后至少有四個(gè)好處可替換覺得模型腦子不夠用換一個(gè)底座其它模塊不用動(dòng)覺得某個(gè)工具不好用單獨(dú)替換工具實(shí)現(xiàn)?？烧{(diào)試日志可以按模塊打點(diǎn)哪一步出了問題一目了然?？蓮?fù)用記憶模塊、工具層可以從一個(gè)智能體搬到另一個(gè)智能體?？蓽y試每個(gè)模塊都可以單獨(dú)寫測試用例不用等整個(gè)系統(tǒng)跑通。在后面的章節(jié)里我會把智能體拆成五大核心模塊來講這些模塊的組合方式幾乎就是所有智能體應(yīng)用案例集的底層模板。2. 五大核心模塊每一塊負(fù)責(zé)什么、為什么必須存在2.1 大腦層大模型LLM不是越大越好作為大腦的大模型是第一塊組成它解決“理解與生成”的問題同時(shí)負(fù)責(zé)把其他模塊串起來?，F(xiàn)代智能體框架中模型除了輸出回答還要輸出“結(jié)構(gòu)化決策指令”到底該調(diào)用哪個(gè)工具、調(diào)用參數(shù)是什么、任務(wù)是否已經(jīng)完成。所以模型的能力上限基本決定了智能體的智能上限。模型選型上有幾個(gè)判斷維度上下文長度決定了短期記憶這個(gè)“杯子”能裝多少水推理能力決定了復(fù)雜任務(wù)的拆解深度工具調(diào)用穩(wěn)定性決定了工程上是否省心成本與延遲決定了智能體能否規(guī)模化落地。最好的選擇不是最強(qiáng)的模型而是在任務(wù)復(fù)雜度、單位成本和響應(yīng)速度之間取平衡。我的經(jīng)驗(yàn)是先用強(qiáng)模型跑通場景再用弱模型做降本驗(yàn)證。很多簡單的工具調(diào)用任務(wù)小模型加一個(gè)寫得很具體的Prompt完全夠用。另外多模態(tài)大模型的進(jìn)展讓智能體的輸入通道從純文本擴(kuò)展到了圖片、語音但組成原理不變只是大腦層的能力更豐富了。2.2 規(guī)劃決策層把大目標(biāo)拆成可執(zhí)行的小步驟規(guī)劃層是智能體和普通聊天機(jī)器人最大的分水嶺。用戶說“幫我整理本周市場數(shù)據(jù)并寫一份周報(bào)”聊天機(jī)器人會直接開始編報(bào)告智能體則會先拆分出查詢數(shù)據(jù)源、清洗數(shù)據(jù)、生成圖表、起草報(bào)告、檢查格式等子任務(wù)再?zèng)Q定執(zhí)行順序。常見的規(guī)劃策略有三類各有適用場景ReAct式規(guī)劃走一步看一步適合目標(biāo)模糊、環(huán)境動(dòng)態(tài)變化的任務(wù)缺點(diǎn)是容易繞彎子。Plan-and-Execute式先讓模型生成一個(gè)整體計(jì)劃再逐步執(zhí)行適合流程明確的場景能大幅減少中間推理次數(shù)但遇到意外變化時(shí)需要維護(hù)計(jì)劃更新。Reflexion式在執(zhí)行失敗后把失敗原因作為“經(jīng)驗(yàn)”反饋給模型讓它重新嘗試適合需要反復(fù)試驗(yàn)的任務(wù)。實(shí)際項(xiàng)目中很少有人只用單一策略更多是混用。比如做客服智能體開場走ReAct判斷用戶意圖確認(rèn)是查詢件后切換成固定流程異常時(shí)再走Reflexion重試。規(guī)劃層的本質(zhì)是決策它把“下一步做什么”變成模型可以推理的問題。這里有個(gè)實(shí)操要點(diǎn)一定要在系統(tǒng)提示詞里給規(guī)劃層加上邊界告訴它什么情況下必須停下來問用戶什么情況下不許自作主張。否則模型很容易為了“完成目標(biāo)”在錯(cuò)的方向上反復(fù)橫跳。2.3 記憶系統(tǒng)沒有記憶的智能體就是“金魚”LLM本身不保留任何跨請求的狀態(tài)每一次調(diào)用都是“一次性”的。因此記憶系統(tǒng)是智能體組成的必備模塊。記憶通常分三層第一層是短期記憶就是把最近幾輪對話塞進(jìn)上下文窗口實(shí)現(xiàn)連續(xù)對話。窗口管理需要技巧常見做法是把舊對話逐輪壓縮成摘要只保留與當(dāng)前任務(wù)相關(guān)的細(xì)節(jié)。第二層是長期記憶也就是“把知識沉淀下來”。最常見的是向量數(shù)據(jù)庫把文本切塊、用Embedding模型編碼成向量查詢時(shí)把用戶問題也轉(zhuǎn)成向量做相似度檢索。參數(shù)上我建議切塊大小控制在500到800個(gè)字符左右重疊50到100個(gè)字符保證跨塊語義不斷裂。Embedding模型盡量和主模型配套如果混用不同體系檢索出來的內(nèi)容模型可能“看不懂”。第三層是結(jié)構(gòu)化記憶用數(shù)據(jù)庫或KV存儲保存用戶偏好、訂單狀態(tài)、歷史結(jié)論等確定性的信息。這一層比向量檢索更準(zhǔn)也不容易被檢索結(jié)果干擾適合對準(zhǔn)確性要求高的場景。銷售智能體就是典型例子客戶上次提到的預(yù)算、家人關(guān)系、跟進(jìn)節(jié)點(diǎn)這些信息放結(jié)構(gòu)化存儲里每一次會話直接讀取比等向量檢索靠譜得多。2.4 工具調(diào)用層讓智能體真正“有手有腳”工具層解決的是模型無法直接操作真實(shí)世界的問題。它的組成包括工具定義、執(zhí)行器、返回處理三部分。工具定義的本質(zhì)是給模型寫“說明書”。現(xiàn)在主流模型都支持Function Calling做法是提供一個(gè)JSON Schema描述工具名稱、用途、參數(shù)類型。模型讀了說明書后在需要時(shí)生成一個(gè)“調(diào)用指令”而不是直接執(zhí)行。這一段定義質(zhì)量影響巨大我踩過不少坑description寫得太模糊模型就不知道該什么時(shí)候用參數(shù)名寫得太抽象模型就填錯(cuò)值。寫description有一個(gè)技巧想象你在讓一個(gè)聰明的實(shí)習(xí)生干活你要把前提條件、返回值含義、邊界情況全部寫清楚。執(zhí)行器是實(shí)際跑工具的地方可以是一個(gè)Python函數(shù)、一個(gè)REST API封裝、一段SQL、甚至一個(gè)代碼解釋器。這里必須做的工程加固包括超時(shí)控制、異常捕獲、結(jié)果大小限制。很多失敗不是模型的問題而是工具本身報(bào)錯(cuò)后模型拿到一段紅色堆棧就懵了。返回處理同樣重要。工具返回的原始數(shù)據(jù)要精簡再喂給模型數(shù)據(jù)庫查詢返回100行原始記錄模型容易被干擾你提前做一次匯總只把關(guān)鍵指標(biāo)給它決策質(zhì)量會大幅提升。RAG本質(zhì)上就是工具層的一種特殊形態(tài)它的輸出是檢索到的知識片段。所以不要老想著“RAG和Agent誰替代誰”在組成視角下RAG只是Agent工具箱里的一個(gè)工具。2.5 反饋與容錯(cuò)層決定智能體靠不靠譜最后一塊組成是反饋與容錯(cuò)這是很多教程不提、但項(xiàng)目上線后最關(guān)鍵的模塊。模型不是每次都對工具不是每次都不報(bào)錯(cuò)網(wǎng)絡(luò)不是每次都通暢。反饋與容錯(cuò)層要做的事情分成三層輸入校驗(yàn)、執(zhí)行容錯(cuò)、結(jié)果校驗(yàn)。輸入校驗(yàn)指在用戶輸入進(jìn)入規(guī)劃層之前先做敏感信息檢測、意圖邊界判斷、參數(shù)格式校驗(yàn)從源頭減少后續(xù)錯(cuò)誤。執(zhí)行容錯(cuò)指給每個(gè)工具調(diào)用加超時(shí)、重試和指數(shù)退避失敗后把錯(cuò)誤信息結(jié)構(gòu)化地反饋給模型讓它嘗試替代方案而不是把原始異常直接暴露給用戶。結(jié)果校驗(yàn)指在智能體給出最終答復(fù)前做規(guī)則檢查比如金額是否匹配、日期是否正確、工具是否真的調(diào)用成功。我見過一個(gè)客服智能體訂單查詢工具返回值解析失敗時(shí)它會自信滿滿地說“您的訂單已發(fā)貨”用戶一看物流信息完全對不上。問題就出在缺少結(jié)果校驗(yàn)層模型把不完整的工具返回當(dāng)作有效結(jié)果拿去用了。加一道校驗(yàn)發(fā)現(xiàn)工具返回字段不完整就強(qiáng)制進(jìn)入“重新查詢或轉(zhuǎn)人工”分支這類“一本正經(jīng)胡說八道”的問題立刻少了一半。這套機(jī)制在工程領(lǐng)域有個(gè)說法叫LLM智能體的自主容錯(cuò)控制本質(zhì)就是讓系統(tǒng)在無人干預(yù)的情況下識別異常、修正或隔離故障、繼續(xù)完成任務(wù)。3. 平臺搭智能體和Python搭智能體差別到底在哪3.1 平臺路線Coze、Dify這類工具解決“快”的問題Coze和Dify為代表的低代碼平臺幾乎把智能體的組成封裝成了可視化模塊你拖一個(gè)大模型節(jié)點(diǎn)連一個(gè)知識庫節(jié)點(diǎn)掛一個(gè)插件節(jié)點(diǎn)再加一個(gè)對話入口一個(gè)能跑的智能體就出來了。這類平臺特別適合三種情況一是快速驗(yàn)證產(chǎn)品想法不需要寫代碼二是團(tuán)隊(duì)里有產(chǎn)品經(jīng)理、運(yùn)營人員希望他們也能直接維護(hù)智能體三是發(fā)布渠道多平臺能直接一鍵接入微信群、網(wǎng)站客服、釘釘?shù)取Ｆ脚_方案的代價(jià)是抽象層級太高。底層怎么規(guī)劃、上下文怎么管理、模型如何選擇都被封裝成開關(guān)和模板。做一些標(biāo)準(zhǔn)任務(wù)沒問題一旦你要實(shí)現(xiàn)一個(gè)復(fù)雜的條件循環(huán)、要在多個(gè)智能體之間傳遞任務(wù)、要私有化部署、要接入自己訓(xùn)練的專用小模型平臺提供的自由度往往不夠這時(shí)你會在平臺的各種“高級設(shè)置”里折騰半天最后發(fā)現(xiàn)還是得自己寫。3.2 代碼路線從LangGraph、AgentScope到Spring AI用代碼搭智能體等于你自己來設(shè)計(jì)和實(shí)現(xiàn)上面所有模塊。當(dāng)前用得比較多的框架Python生態(tài)有LangGraph、AutoGen、AgentScopeJava生態(tài)有Spring AI結(jié)合AgentScope的實(shí)踐?？蚣苤皇悄_手架真正的組成部分還是要靠代碼定義。代碼路線的優(yōu)勢是控制力。你可以精確控制狀態(tài)流、可以給特定用戶走特定分支、可以自定義日志和監(jiān)控、可以任意接入內(nèi)部系統(tǒng)、可以做A/B測試。缺點(diǎn)是門檻高并且要自己處理工程細(xì)節(jié)會話并發(fā)、上下文壓縮策略、工具鑒權(quán)、失敗重試、資源回收等。用平臺三分鐘能跑通的Demo用代碼可能要寫一個(gè)周末但上了生產(chǎn)環(huán)境維護(hù)和擴(kuò)展的底氣完全不一樣。3.3 一個(gè)對照表到底怎么選我整理了一張表按個(gè)人經(jīng)驗(yàn)打分對比維度平臺路線Coze/Dify代碼路線Python/框架開發(fā)速度快幾小時(shí)出Demo慢初期要寫不少樣板代碼可控性低細(xì)節(jié)被平臺封裝高每一層都可改可移植性弱換平臺等于重寫強(qiáng)代碼可在任意環(huán)境部署軟件工程能力弱難以做灰度、單元測試強(qiáng)可接入CI/CD和監(jiān)控體系私有化部署受限受平臺約束靈活可內(nèi)網(wǎng)或本地運(yùn)行維護(hù)成本初期低深度定制后反而高初期高穩(wěn)定后低適合人群產(chǎn)品、運(yùn)營、快速驗(yàn)證開發(fā)者、深度定制、大型系統(tǒng)我自己做項(xiàng)目的習(xí)慣是“先平臺后代碼”先用平臺把業(yè)務(wù)邏輯跑通拿到真實(shí)對話樣本分析用戶到底需要哪些工具、哪些環(huán)節(jié)容易失敗再用代碼框架重寫把平臺驗(yàn)證過的邏輯固化下來。這比一上來就找框架教程看三天更高效。4. 一個(gè)最小可落地的智能體從需求到代碼骨架4.1 動(dòng)手前先畫一張“能力地圖”搭智能體之前我強(qiáng)烈建議先用一張紙把邊界畫清楚用戶是誰輸入是什么輸出是什么需要訪問哪些外部系統(tǒng)哪些操作必須經(jīng)人工確認(rèn)哪些失敗必須轉(zhuǎn)人工。這個(gè)能力地圖決定了后面所有模塊的設(shè)計(jì)。比如做一個(gè)“訂單助手”輸入是用戶的文本或訂單號輸出是查詢結(jié)果或售后解決方案需要的工具是訂單查詢API、物流查詢API、退款申請API必須人工確認(rèn)的是金額超過300元的退款必須轉(zhuǎn)人工的是投訴、罵人、無法定位異常等。提前規(guī)劃好邊界比直接在代碼里瞎寫判斷強(qiáng)太多。我在實(shí)際工作中發(fā)現(xiàn)超過一半的智能體開發(fā)項(xiàng)目失敗不是因?yàn)槟Ｐ筒粔蚵斆鞫悄芰吔鐝囊婚_始就沒定義清楚。4.2 極簡代碼骨架一個(gè)不依賴框架的ReAct循環(huán)下面用最少的代碼演示一個(gè)智能體的核心骨架。它不綁定任何具體框架邏輯就是“模型決策、工具執(zhí)行、結(jié)果回填、循環(huán)決策”。這是理解智能體組成最直觀的代碼形態(tài)。import json from openai import OpenAI TOOL_IMPL {} # 工具名 - 可調(diào)用函數(shù) class MiniAgent: def __init__(self, model, system_prompt, tools): self.client OpenAI() self.model model self.system_prompt system_prompt self.tools tools def run(self, user_input, max_steps5): messages [{role: system, content: self.system_prompt}, {role: user, content: user_input}] for step in range(max_steps): resp self.client.chat.completions.create( modelself.model, messagesmessages, toolsself.tools, tool_choiceauto) msg resp.choices[0].message messages.append(msg) if not msg.tool_calls: # 模型不再調(diào)用工具直接輸出 return msg.content for tc in msg.tool_calls: # 依次執(zhí)行模型要求的工具 name, args tc.function.name, tc.function.arguments try: result TOOL_IMPL[name](**json.loads(args)) result json.dumps(result, ensure_asciiFalse)[:2000] except Exception as e: result fTOOL_ERROR: {e} messages.append({role: tool, tool_call_id: tc.id, content: result}) return 已達(dá)到最大步驟數(shù)請重新描述問題這段代碼已經(jīng)把智能體組成的四個(gè)關(guān)鍵環(huán)節(jié)體現(xiàn)出來了System Prompt限定角色和能力邊界tools聲明模型可以使用的工具循環(huán)結(jié)構(gòu)實(shí)現(xiàn)規(guī)劃與執(zhí)行交替異常捕獲把錯(cuò)誤反饋給模型而不是直接崩潰。把TOOL_IMPL里加入真實(shí)函數(shù)再配上對應(yīng)的tools定義就構(gòu)成一個(gè)能跑的智能體。4.3 三個(gè)決定“好用還是難用”的細(xì)節(jié)第一個(gè)細(xì)節(jié)是System Prompt。不要只寫“你是助手”至少要包含四段信息角色與風(fēng)格、能力邊界與禁止事項(xiàng)、可用工具和什么時(shí)候用、輸出格式偏好。模型讀到的說明越具體行為越可控。第二個(gè)細(xì)節(jié)是工具返回結(jié)果的長度。上面代碼里我已經(jīng)設(shè)置了截?cái)?000字符。工具返回幾萬字時(shí)模型的注意力會被無關(guān)字段淹沒決策質(zhì)量斷崖式下降。建議在工具內(nèi)部先做一層摘要只返回模型真正需要的字段。第三個(gè)細(xì)節(jié)是完整日志。每個(gè)循環(huán)步驟要把模型思考內(nèi)容、調(diào)用的工具名、參數(shù)JSON、返回值摘要、執(zhí)行耗時(shí)都記錄下來。這些日志在出問題debug時(shí)價(jià)值極高。很多初學(xué)者不記錄日志出了問題就只能盲猜。4.4 千萬別用“兩三個(gè)問題”來驗(yàn)收智能體一個(gè)常見錯(cuò)誤是拿兩三個(gè)精心設(shè)計(jì)的問題測一下覺得效果好就上線。智能體類系統(tǒng)的驗(yàn)收一定要場景化測試準(zhǔn)備20個(gè)正常情況用例再準(zhǔn)備20個(gè)刁鉆用例包括信息缺失、敏感請求、多輪追問、工具故障、超長輸入、語氣攻擊。把這些用例錄成自動(dòng)化腳本批量跑記錄通過率和失敗原因。我自己的做法是把測試集存在一個(gè)表格里跑完一輪導(dǎo)出結(jié)果逐個(gè)看失敗的case把失敗原因歸到“模型問題”“工具問題”“Prompt問題”“記憶問題”四類分類修補(bǔ)。經(jīng)過三四輪迭代通過率一般能從70%提到95%以上。這個(gè)過程沒有捷徑但能保證不上線后翻車。5. 常見問題與排查技巧實(shí)錄5.1 智能體“答非所問”到底是哪一層出問題了現(xiàn)象用戶問A智能體答B(yǎng)或者答著答著跑偏。排查順序很重要先看日志里模型每一步的思考文本確認(rèn)它在做什么決策再看工具返回是否被正確注入到后續(xù)上下文最后看記憶檢索出來的內(nèi)容是不是和當(dāng)前問題相關(guān)。很多時(shí)候是長期記憶檢索把不相關(guān)的歷史信息塞了進(jìn)來干擾了模型。解決方法是降低相似度閾值或者在前置檢索后加一道相關(guān)性重排。5.2 工具調(diào)用反復(fù)失敗模型“不會用”工具現(xiàn)象模型執(zhí)意調(diào)用一個(gè)不存在的工具名稱或者填出明顯不合法的參數(shù)或者干脆忽略工具直接編答案。原因通常是工具定義描述不到位。推薦做法把工具描述寫成“在什么條件下應(yīng)該調(diào)用”“參數(shù)表示什么”“返回后如何處理”不要只寫一句“查詢訂單”。這個(gè)坑在智能體面試?yán)镆彩歉哳l題考察的就是你對工具層組成的理解程度。5.3 多智能體協(xié)作時(shí)的“搶話”問題當(dāng)智能體的組成從單個(gè)Agent擴(kuò)展到多智能體時(shí)最典型的問題是誰都想回應(yīng)、互相打斷。工程上的解法是把通信機(jī)制和調(diào)度機(jī)制拆出來定義統(tǒng)一的消息格式每個(gè)智能體只訂閱自己負(fù)責(zé)的事件調(diào)度器決定消息分發(fā)給誰給每個(gè)智能體設(shè)定優(yōu)先級和發(fā)言頻率上限。負(fù)責(zé)銷售的和負(fù)責(zé)售后的如果都能回答“價(jià)格問題”就要在語義層做分類避免重疊。這就回到同一個(gè)原則模塊職責(zé)要正交。5.4 一張速查表現(xiàn)象可能原因排查與解決智能體瞎編答案缺少結(jié)果校驗(yàn)、工具返回被忽略加規(guī)則校驗(yàn)層強(qiáng)制校驗(yàn)工具結(jié)果越跑越偏缺規(guī)劃邊界在規(guī)劃Prompt中加“何時(shí)停止、何時(shí)詢問”工具調(diào)用失敗定義不清、返回過長、鑒權(quán)過期重寫工具描述截?cái)喾祷貦z查憑證上下文混亂記憶壓縮策略不好改用摘要壓縮加關(guān)鍵信息結(jié)構(gòu)化存儲多智能體搶話職責(zé)重疊、無調(diào)度消息訂閱、優(yōu)先級、職責(zé)清單6. 組成模塊不變場景組合千變?nèi)f化6.1 銷售智能體記憶和工具權(quán)重最高銷售場景的智能體組成上突出兩塊客戶記憶和業(yè)務(wù)工具。它需要結(jié)構(gòu)化存儲客戶偏好、歷史溝通記錄、近期動(dòng)向需要調(diào)用CRM、報(bào)價(jià)單、庫存查詢等工具。話術(shù)生成反而不是最關(guān)鍵的地方。很多銷售團(tuán)隊(duì)做出來的智能體“話很漂亮但沒法成交”原因就是它記不住客戶上個(gè)月說過的預(yù)算范圍工具又只會推送模板內(nèi)容。把記憶和工具這兩塊補(bǔ)齊智能體才真正能幫銷售干活。6.2 教育情感智能體除了知識還有情緒判斷教育場景尤其是小學(xué)數(shù)學(xué)輔導(dǎo)這類場景智能體的組成比通用助手多了兩層情感識別和學(xué)習(xí)進(jìn)度記憶。小學(xué)數(shù)學(xué)智能體要做得好核心不是把答案算出來而是把題目拆成孩子能理解的步驟用蘇格拉底式提問引導(dǎo)孩子自己得出答案并且根據(jù)孩子之前錯(cuò)過的題型調(diào)整講解方式。這就要求規(guī)劃層有教學(xué)策略記憶層記錄掌握程度反饋層在孩子反復(fù)做錯(cuò)時(shí)切換更簡單的講法。這類智能體如果少了情感判斷模塊只會冷冰冰地報(bào)答案家長用兩次就會放棄。6.3 客服與代碼智能體結(jié)果可驗(yàn)證是第一優(yōu)先級客服智能體典型的組成是知識庫RAG、工單系統(tǒng)工具、轉(zhuǎn)人工策略代碼智能體則是大模型加代碼執(zhí)行沙箱、文件讀寫工具、測試反饋循環(huán)。這兩個(gè)場景有一個(gè)共同點(diǎn)結(jié)果必須可驗(yàn)證?？头荒軄y承諾賠付代碼不能生成一遍過不去的代碼。所以工程實(shí)踐中都會加一道校驗(yàn)器客服側(cè)校驗(yàn)政策條款和金額代碼側(cè)運(yùn)行測試用例。校驗(yàn)不通過絕不直接輸出。6.4 不是所有對話任務(wù)都需要“智能體”最后提醒一句不是所有對話任務(wù)都值得上完整的智能體組成。如果任務(wù)只是固定的問答、FAQ、知識檢索一個(gè)RAG應(yīng)用就夠了加太多模塊只會增加延遲和不可控性。智能體的優(yōu)勢場景有三個(gè)共同點(diǎn)目標(biāo)明確、需要外部動(dòng)作、結(jié)果可以驗(yàn)證。反過來如果這三點(diǎn)不成立先別急著上Agent把你的Prompt調(diào)好、RAG做好可能更快更穩(wěn)。我個(gè)人做了十幾個(gè)智能體項(xiàng)目之后的體會是搭一個(gè)能跑的Demo真的不難難的是把“組成”這件事想明白——每一層都獨(dú)立可測、每一條失敗路徑都有預(yù)案。智能體會一本正經(jīng)地胡說八道會在工具失敗后自欺欺人會為了完成目標(biāo)在錯(cuò)路上繞圈這些都不是模型單點(diǎn)能解決的而是靠反饋、日志、權(quán)限邊界和失敗重試這些工程模塊去兜底。設(shè)計(jì)智能體的第一天就把它們放進(jìn)來而不是上線前才補(bǔ)能少踩很多坑。如果你正打算從平臺跳到代碼我建議先拿一個(gè)月真實(shí)對話做測試集把通過率跑上去再談架構(gòu)比看多少篇拆解文章都管用。