做 Agent 的人應(yīng)該都遇到過(guò)這個(gè)場(chǎng)景大模型單聊的時(shí)候有問(wèn)必答一旦放進(jìn)真實(shí)業(yè)務(wù)里就像一位沒(méi)有手、沒(méi)有筆記本、也沒(méi)有圖書(shū)館借書(shū)卡的專家只能憑記憶里的那點(diǎn)東西硬撐。問(wèn)它“幫我拉一下上季度的渠道數(shù)據(jù)”它要么道歉說(shuō)自己沒(méi)有訪問(wèn)權(quán)限要么一本正經(jīng)地編一串?dāng)?shù)字。所謂 AI Agent本質(zhì)上是把這些缺失的“器官”——大模型的推理能力、記憶系統(tǒng)、知識(shí)檢索RAG、以及工具調(diào)用——組裝起來(lái)讓模型從“能說(shuō)”變成“能做事”。這篇文章我不打算聊什么宏大概念也不會(huì)畫(huà)那些看了更糊涂的架構(gòu)圖。我會(huì)把 Agent 架構(gòu)里最常見(jiàn)的四個(gè)核心模塊拆開(kāi)講大模型、記憶、RAG、工具調(diào)用它們各自負(fù)責(zé)什么、內(nèi)部怎么做、互相之間怎么協(xié)同。內(nèi)容以落地為主適合正在做 Agent 應(yīng)用開(kāi)發(fā)的工程師、準(zhǔn)備把大模型接入業(yè)務(wù)的產(chǎn)品和技術(shù)負(fù)責(zé)人也適合那些對(duì)大模型有一定了解、想搞明白“Agent 到底是怎么組裝起來(lái)”的愛(ài)好者。全程有實(shí)操思路、有參數(shù)參考、有踩坑記錄看完你至少能徒手設(shè)計(jì)出一個(gè)可運(yùn)行的 Agent 原型。1. 先想清楚Agent 到底在解決什么問(wèn)題1.1 大模型是大腦Agent 才是完整的人很多人會(huì)把“大模型”和“Agent”混為一談這是第一個(gè)思維誤區(qū)。大模型本質(zhì)上是一個(gè)概率生成器給它一段輸入它預(yù)測(cè)下一段最合理的輸出。它可以在對(duì)話里展示出驚人的理解力但這份理解力是“無(wú)根”的——沒(méi)有狀態(tài)不能記住昨天的對(duì)話沒(méi)有外部知識(shí)源訓(xùn)練截止日之后的世界對(duì)它來(lái)說(shuō)是一片空白沒(méi)有執(zhí)行能力它無(wú)法真的去查詢數(shù)據(jù)庫(kù)、調(diào)用接口或者操作軟件。Agent 做的事情就是給這個(gè)“大腦”配上記憶、配上知識(shí)庫(kù)、配上可以操作外部世界的工具。我習(xí)慣用一個(gè)類比大模型像一個(gè)只有大腦皮層的專家知識(shí)面廣、推理能力強(qiáng)但他沒(méi)有手、沒(méi)有眼睛、也沒(méi)有筆記本。Agent 是給這位專家裝上了這些器官讓他可以翻筆記本、查資料、動(dòng)手執(zhí)行任務(wù)。這樣一來(lái)“腦”還是那個(gè)“腦”但能力邊界從“能回答”擴(kuò)展到“能完成”。這個(gè)區(qū)別決定了整個(gè)架構(gòu)設(shè)計(jì)的方向你不是在選一個(gè)更強(qiáng)的模型而是在設(shè)計(jì)一套怎么讓模型和其他組件協(xié)作的系統(tǒng)。系統(tǒng)設(shè)計(jì)的好壞往往比模型本身的智商更能決定 Agent 的上限。同一個(gè)模型配合合理的記憶和工具設(shè)計(jì)可以穩(wěn)定完成復(fù)雜任務(wù)配合糟糕的編排連簡(jiǎn)單問(wèn)題都會(huì)答得顛三倒四。1.2 四個(gè)模塊各守一道防線Agent 的架構(gòu)設(shè)計(jì)有一個(gè)非常樸素的思路每個(gè)模塊解決一個(gè)明確的短板。用表格看會(huì)更清楚核心模塊解決的問(wèn)題實(shí)際類比大模型意圖理解、推理、決策、內(nèi)容生成大腦記憶跨會(huì)話狀態(tài)、上下文維持、用戶偏好筆記本RAG外部知識(shí)、私有文檔、實(shí)時(shí)信息獲取圖書(shū)館工具調(diào)用操作真實(shí)系統(tǒng)、獲取結(jié)構(gòu)化數(shù)據(jù)、執(zhí)行動(dòng)作手和腳這四個(gè)模塊不是可選項(xiàng)而是彼此咬合的關(guān)系。沒(méi)有記憶Agent 每次對(duì)話都是“失憶”的用戶說(shuō)“我剛才提過(guò)的條件你忘了”會(huì)直接尬住。沒(méi)有 RAG私有領(lǐng)域的知識(shí)無(wú)從談起模型只能靠訓(xùn)練數(shù)據(jù)里的過(guò)期內(nèi)容硬猜。沒(méi)有工具調(diào)用Agent 就永遠(yuǎn)停留在“嘴上分析”無(wú)法真正完成取數(shù)、發(fā)消息、改配置這類操作。而大模型作為中樞把其他三個(gè)模塊串聯(lián)起來(lái)像一個(gè)調(diào)度員隨時(shí)判斷當(dāng)前任務(wù)該調(diào)動(dòng)哪個(gè)模塊、怎么解釋模塊返回的結(jié)果。所以設(shè)計(jì) Agent 架構(gòu)的第一步不是急著寫(xiě)代碼而是把任務(wù)的鏈路畫(huà)出來(lái)一個(gè)請(qǐng)求進(jìn)來(lái)之后經(jīng)過(guò)哪些判斷、哪些模塊、最終怎么收尾。這個(gè)鏈路清晰了后續(xù)的開(kāi)發(fā)和排查都會(huì)輕松很多。2. 記憶模塊怎么落地短期窗口、長(zhǎng)期檔案與記憶污染2.1 短期記憶上下文窗口的管理是門(mén)手藝大模型的上下文窗口就算再大也不可能無(wú)限裝下所有歷史對(duì)話。我在做項(xiàng)目時(shí)最常遇到的問(wèn)題就是對(duì)話進(jìn)行到第 30 輪把完整歷史塞進(jìn) Prompt 里Token 消耗暴漲、響應(yīng)變慢而且模型還會(huì)被早期無(wú)關(guān)的信息干擾。短期記憶的設(shè)計(jì)本質(zhì)上就是對(duì)上下文窗口的資源管理。目前比較實(shí)用的是“滑動(dòng)窗口 摘要壓縮”的混合策略?；瑒?dòng)窗口很好理解只保留最近 N 輪對(duì)話原文比如 10 到 20 輪更早的內(nèi)容不再進(jìn)入 Prompt。但只做滑動(dòng)窗口會(huì)丟失重要信息所以每隔幾輪就把窗口外的歷史用大模型壓縮成一段摘要作為“記憶概述”保留下來(lái)。實(shí)際用的時(shí)候Prompt 里的結(jié)構(gòu)大概是任務(wù)指令 歷史摘要 最近對(duì)話原文 當(dāng)前問(wèn)題。這樣一來(lái)模型既有長(zhǎng)期脈絡(luò)又有近期細(xì)節(jié)且 Token 開(kāi)銷可控。我踩過(guò)的一個(gè)坑是滑窗邊界設(shè)置得太死。比如用戶在第 25 輪說(shuō)“我之前說(shuō)的那個(gè)價(jià)格是指含稅價(jià)”如果你只保留近 20 輪這個(gè)信息早就被擠出窗口了模型自然無(wú)法正確理解。后來(lái)的改進(jìn)是在滑動(dòng)窗口之外專門(mén)設(shè)置一個(gè)“關(guān)鍵約束區(qū)”只要對(duì)話中出現(xiàn)像“含稅價(jià)”“截止時(shí)間”“排除項(xiàng)”這類的關(guān)鍵信息就單獨(dú)抽出來(lái)長(zhǎng)期保留。這本質(zhì)上已經(jīng)有點(diǎn)往長(zhǎng)期記憶靠了但它很管用。2.2 長(zhǎng)期記憶按主題歸檔的“Agent 檔案庫(kù)”長(zhǎng)期記憶要解決的是跨會(huì)話的問(wèn)題。用戶今天說(shuō)的偏好下次對(duì)話時(shí)最好還能記住。實(shí)現(xiàn)長(zhǎng)期記憶的常見(jiàn)方案有兩類向量化記憶和結(jié)構(gòu)化記憶。向量化記憶的做法是把歷史對(duì)話、用戶偏好、任務(wù)結(jié)論等文本切成片段用 embedding 模型轉(zhuǎn)成向量存進(jìn)向量數(shù)據(jù)庫(kù)。下次用戶發(fā)起新問(wèn)題時(shí)先把問(wèn)題向量化在庫(kù)里做相似度檢索把相關(guān)的歷史記憶撈出來(lái)放進(jìn) Prompt。這個(gè)方案的優(yōu)點(diǎn)是靈活能處理沒(méi)有固定結(jié)構(gòu)的自然語(yǔ)言信息缺點(diǎn)是召回不準(zhǔn)時(shí)容易把不相關(guān)的舊記憶帶進(jìn)來(lái)。結(jié)構(gòu)化記憶則是用固定的數(shù)據(jù)格式記錄關(guān)鍵信息比如用戶偏好、實(shí)體關(guān)系、任務(wù)狀態(tài){ user_profile: { region: 華東, contact_channel: email, language: 中文 }, preferences: { report_style: 簡(jiǎn)版, data_granularity: 按周 }, task_state: { current_project: 某跨平臺(tái)系統(tǒng), next_deadline: 2025-06-30 } }結(jié)構(gòu)化記憶的優(yōu)點(diǎn)是精準(zhǔn)、穩(wěn)定缺點(diǎn)是需要預(yù)先定義好 schema無(wú)法覆蓋所有場(chǎng)景。我現(xiàn)在的慣用做法是兩者結(jié)合核心的偏好和狀態(tài)用結(jié)構(gòu)化 JSON 管理零散的信息和過(guò)程性內(nèi)容走向量庫(kù)。需要特別強(qiáng)調(diào)的是記憶的寫(xiě)入時(shí)機(jī)。不是所有對(duì)話內(nèi)容都值得寫(xiě)入長(zhǎng)期記憶。一次性的臨時(shí)需求、隨口一提的閑聊、帶時(shí)效性的狀態(tài)都不應(yīng)該污染長(zhǎng)期檔案。我會(huì)在每次對(duì)話結(jié)束后讓模型先做一個(gè)“記憶提取”判斷這條對(duì)話里有沒(méi)有值得長(zhǎng)期保存的信息如果有再格式化寫(xiě)入。這個(gè)過(guò)程會(huì)多花一點(diǎn)時(shí)間和 Token但能避免長(zhǎng)期記憶變成垃圾場(chǎng)。2.3 兩個(gè)最容易踩的記憶坑第一個(gè)坑是長(zhǎng)短記憶沖突。比如長(zhǎng)期記憶里寫(xiě)著用戶“偏好郵件通知”但這次會(huì)話里用戶明確說(shuō)了“不要發(fā)郵件直接打電話”。如果短期記憶和長(zhǎng)期記憶同時(shí)塞進(jìn) Prompt模型就會(huì)猶豫甚至輸出矛盾的內(nèi)容?，F(xiàn)在的處理辦法是在 Prompt 中給記憶標(biāo)出優(yōu)先級(jí)明確告訴模型“近期對(duì)話中的明確指令優(yōu)先于歷史偏好記錄”并且盡量讓短期記憶里的新指令覆蓋長(zhǎng)期記憶中的舊配置。第二個(gè)坑是記憶膨脹和成本失控。向量庫(kù)里的記憶如果不加管理會(huì)隨著使用時(shí)間不斷膨脹檢索量變大、命中率下降、存儲(chǔ)費(fèi)用上升。我建議給每條長(zhǎng)期記憶加上時(shí)間戳和訪問(wèn)頻次定期清理過(guò)期的條目比如三個(gè)月未命中、且與當(dāng)前任務(wù)無(wú)關(guān)的歷史記憶可以歸檔或者刪除。還要為記憶檢索設(shè)置一個(gè)上限比如每次最多返回 5 條相關(guān)記憶避免無(wú)關(guān)信息擠占上下文空間。3. RAG 模塊給 Agent 裝上“實(shí)時(shí)知識(shí)庫(kù)”3.1 RAG 的標(biāo)準(zhǔn)流水線先歸檔再召回RAGRetrieval-Augmented Generation檢索增強(qiáng)生成是解決大模型“知識(shí)過(guò)期”和“私有知識(shí)缺失”的主流方案。它的核心思路很直接模型不知道答案沒(méi)關(guān)系先讓它從外部知識(shí)庫(kù)里檢索相關(guān)內(nèi)容再基于檢索結(jié)果來(lái)生成回答。離線階段要做的是知識(shí)歸檔把文檔清洗、去噪按語(yǔ)義切分成適宜檢索的片段chunk然后逐段用 embedding 模型轉(zhuǎn)成向量寫(xiě)入向量數(shù)據(jù)庫(kù)。在線階段則是收到用戶問(wèn)題 → 問(wèn)題向量化 → 在向量庫(kù)中召回最相似的 Top-K 個(gè)片段 → 將片段拼接進(jìn) Prompt → 模型基于片段生成回答。這里最容易影響效果的是 chunk 切分。chunk 太小信息被切碎一塊完整的意思在多個(gè)片段里分散chunk 太大噪聲增多檢索精度下降。就我自己測(cè)試的經(jīng)驗(yàn)通用文檔用 300 到 500 字左右的 chunk 比較穩(wěn)相鄰 chunk 之間保留 10% 到 20% 的重疊能有效避免語(yǔ)義被切斷。檢索召回?cái)?shù)量 top_k 我一般控制在 5 到 8 個(gè)再往上拉高命中的低質(zhì)片段反而會(huì)稀釋核心信息。embedding 模型的選型也有講究。不要盲目追求大參數(shù)模型而是看你的語(yǔ)料是什么語(yǔ)言、什么領(lǐng)域。如果是中文業(yè)務(wù)文檔優(yōu)先選中文語(yǔ)料表現(xiàn)好的 embedding 模型如果是代碼或英文技術(shù)文檔可以調(diào)整選型。模型之間沒(méi)有絕對(duì)的好壞最終都要用你自己領(lǐng)域的測(cè)試集跑一遍看召回效果。3.2 Agent 場(chǎng)景里 RAG 的三個(gè)特殊之處普通問(wèn)答式 RAG 和 Agent 里的 RAG 是有區(qū)別的。普通 RAG 是一次性檢索、一次性生成流程固定Agent 場(chǎng)景下檢索往往是動(dòng)態(tài)的、多輪的、甚至要跟工具調(diào)用聯(lián)動(dòng)。動(dòng)態(tài)檢索很好理解Agent 在完成任務(wù)的過(guò)程中會(huì)根據(jù)當(dāng)前子任務(wù)臨時(shí)發(fā)起檢索而不是從一開(kāi)始就把所有檢索結(jié)果都查出來(lái)。比如 Agent 要先分析問(wèn)題發(fā)現(xiàn)自己缺少某份背景資料才觸發(fā)一次 RAG 檢索。多跳檢索則更復(fù)雜一些Agent 需要先查一輪得到一個(gè)中間結(jié)果再用這個(gè)結(jié)果作為線索去檢索下一輪有點(diǎn)像查資料時(shí)順著參考文獻(xiàn)一路追下去。這種情況下每一輪檢索的結(jié)果都應(yīng)該被記錄下來(lái)作為后續(xù)推理的依據(jù)。還有一個(gè)很容易被忽視的問(wèn)題檢索結(jié)果和工具返回結(jié)果發(fā)生沖突時(shí)該信誰(shuí)比如 RAG 里的文檔寫(xiě)著“某產(chǎn)品線 2025 年 Q2 銷售額持平”但 BI 工具里拉出來(lái)的實(shí)時(shí)數(shù)據(jù)顯示實(shí)際下降了 15%。如果不做處理模型就可能把兩個(gè)互相矛盾的數(shù)據(jù)都寫(xiě)進(jìn)答案或者隨機(jī)采信一個(gè)。我的做法是在 Prompt 中給不同來(lái)源的信息打上“來(lái)源標(biāo)簽”比如 [知識(shí)庫(kù)] 和 [實(shí)時(shí)工具]并設(shè)置優(yōu)先級(jí)規(guī)則——實(shí)時(shí)工具數(shù)據(jù)優(yōu)先作為事實(shí)依據(jù)知識(shí)庫(kù)內(nèi)容用于背景解釋和原因分析沖突時(shí)要在回答里顯式指出差異。3.3 檢索不出好東西按這個(gè)順序排查如果你的 RAG 總是召回一些不相關(guān)的內(nèi)容別急著換 embedding 模型按下面這個(gè)順序排查先看 chunk 切分是否合理。如果檢索命中的片段語(yǔ)義不完整大概率是切分出了斷層需要調(diào)整 chunk 大小和重疊率。再看用戶問(wèn)題的檢索改寫(xiě)。用戶很少會(huì)用精確的術(shù)語(yǔ)提問(wèn)原始 query 直接拿去向量化效果經(jīng)常不如改寫(xiě)后的 query。讓大模型把用戶問(wèn)題改寫(xiě)成一個(gè)更規(guī)范的檢索語(yǔ)句比如“華東區(qū)銷量下降的原因”改寫(xiě)成“華東區(qū) 2025 年 Q2 銷量下降原因分析”能明顯提升召回質(zhì)量。接下來(lái)檢查召回?cái)?shù)量和排序。如果 top_k 召回的結(jié)果里混著大量低相關(guān)片段可以嘗試加一層 rerank 粗排模型先向量召回 30 個(gè)候選再用 cross-encoder 精排選出 5 個(gè)最相關(guān)的。最后還要確認(rèn) Prompt 里的指令是否明確。如果模型總是不按檢索內(nèi)容回答那就要在 Prompt 里寫(xiě)得強(qiáng)硬一點(diǎn)比如“在缺乏檢索依據(jù)的情況下必須明確回答不知道禁止編造”。4. 工具調(diào)用模塊讓 Agent 真的能“動(dòng)手”4.1 工具調(diào)用的本質(zhì)模型只出意圖執(zhí)行器動(dòng)手工具調(diào)用也叫 Function Calling經(jīng)常被誤解為“模型自己去執(zhí)行函數(shù)”實(shí)際上模型并沒(méi)有執(zhí)行能力。它的本質(zhì)是模型根據(jù)用戶的意圖從你提供的工具清單里選擇一個(gè)工具并生成結(jié)構(gòu)化的調(diào)用參數(shù)然后由外部代碼真正去執(zhí)行這個(gè)工具最后把執(zhí)行結(jié)果傳回給模型做下一步推理。一次完整的工具調(diào)用循環(huán)是這樣的系統(tǒng)把可用工具列表名稱、描述、參數(shù)定義注入 Prompt模型根據(jù)當(dāng)前任務(wù)輸出一個(gè)或幾個(gè)工具調(diào)用指令格式為“工具名 參數(shù)字典”外部執(zhí)行器解析指令做參數(shù)校驗(yàn)調(diào)用對(duì)應(yīng)的函數(shù)或 API執(zhí)行結(jié)果返回給模型有時(shí)候是結(jié)構(gòu)化數(shù)據(jù)有時(shí)候是文本模型根據(jù)結(jié)果繼續(xù)推理生成最終回答或發(fā)起下一次工具調(diào)用。工具定義的格式直接影響調(diào)用成功率。每個(gè)工具的描述要像“搜索詞”一樣精準(zhǔn)讓模型能快速判斷什么時(shí)候該用這個(gè)工具。參數(shù)定義要列出名稱、類型、是否必填、示例值例如{ name: query_sales_data, description: 按地區(qū)和日期范圍查詢銷售數(shù)據(jù)適用于銷售分析類問(wèn)題, parameters: { type: object, properties: { region: {type: string, description: 地區(qū)如華東、華南}, start_date: {type: string, description: 起始日期格式 YYYY-MM-DD}, end_date: {type: string, description: 結(jié)束日期格式 YYYY-MM-DD} }, required: [region, start_date, end_date] } }描述寫(xiě)得模糊、參數(shù)定義不清晰是工具調(diào)用失敗的頭號(hào)原因。模型寧可選擇不調(diào)用任何工具也不會(huì)去猜一個(gè)它看不懂的復(fù)雜工具。4.2 工具注冊(cè)與路由別把所有工具塞進(jìn)一個(gè) Prompt很多做 Agent 的新手容易犯一個(gè)錯(cuò)誤把自己系統(tǒng)里所有 API 都注冊(cè)成工具一股腦塞給模型。工具數(shù)量一旦超過(guò)十幾個(gè)模型的選擇準(zhǔn)確率就會(huì)明顯下降還會(huì)出現(xiàn)答非所問(wèn)、選錯(cuò)工具的情況。Prompt 窗口再大也不能這么揮霍。我建議分兩層做工具路由。第一層是“意圖分流”在模型之前先用一個(gè)輕量分類器或者規(guī)則把請(qǐng)求分為幾個(gè)大類比如“數(shù)據(jù)分析類”“日程操作類”“知識(shí)查詢類”然后只把對(duì)應(yīng)類別下的工具列表注入 Prompt。第二層才是在這個(gè)精簡(jiǎn)后的工具集里讓模型做精確選擇。這樣做的好處是既降低了模型的選擇難度也能有效控制 Token 開(kāi)銷還能避免跨域工具之間的誤用。還有一個(gè)細(xì)節(jié)工具的描述文本需要根據(jù)實(shí)際使用效果不斷調(diào)整。模型對(duì)工具的理解完全來(lái)源于描述文字描述中如果加入了恰當(dāng)?shù)挠|發(fā)詞和典型場(chǎng)景比如“適用于銷售分析類問(wèn)題”往往能把工具調(diào)用的準(zhǔn)確率提高不少。4.3 工具層最常翻車的三個(gè)地方工具調(diào)用是最能體現(xiàn)“看著簡(jiǎn)單、用起來(lái)全是坑”的模塊。第一個(gè)坑是參數(shù)幻覺(jué)。模型不是計(jì)算器它生成的參數(shù)有時(shí)會(huì)脫離實(shí)際比如惡意地編造一個(gè)不存在的用戶 ID或者把一個(gè)日期參數(shù)生成成了非法格式。所以外部執(zhí)行器必須做參數(shù)校驗(yàn)而不是直接拿模型給的參數(shù)去調(diào)接口。校驗(yàn)不通過(guò)時(shí)把錯(cuò)誤信息返回給模型讓它重新生成參數(shù)。第二個(gè)坑是工具結(jié)果過(guò)長(zhǎng)。有些工具會(huì)返回幾十條 JSON 記錄直接塞回 Prompt 會(huì)占掉大塊上下文還會(huì)干擾模型對(duì)重點(diǎn)信息的提取。常規(guī)做法是先壓縮結(jié)果保留結(jié)構(gòu)化摘要、只截取前 N 條記錄、對(duì)主要字段做聚合統(tǒng)計(jì)。如果工具支持篩選條件甚至可以追加一輪調(diào)用讓工具先按模型需求做聚合。第三個(gè)坑是安全邊界。Agent 一旦有工具權(quán)限就意味著它能操作真實(shí)系統(tǒng)權(quán)限如果給得過(guò)大后果可能很難收拾。我在設(shè)計(jì)工具時(shí)堅(jiān)持最小權(quán)限原則Agent 默認(rèn)只允許查詢類的只讀工具對(duì)寫(xiě)入、刪除、發(fā)送類操作要么單獨(dú)二次授權(quán)要么通過(guò)人工審批流程。不要為了方便一股腦把管理員的全部權(quán)限都交給 Agent。5. 協(xié)同機(jī)制拆解一條任務(wù)的完整旅程5.1 從用戶消息到最終回復(fù)的模塊流轉(zhuǎn)把四個(gè)模塊裝在一起協(xié)同的過(guò)程可以拆成一條清晰的鏈路。以一條典型的企業(yè)知識(shí)庫(kù)問(wèn)答請(qǐng)求為例整個(gè)流程是這樣的用戶提問(wèn) → 寫(xiě)入短期記憶 → 大模型解析意圖 → 判斷是否需要外部知識(shí) → 觸發(fā) RAG 檢索 → 判斷是否需要實(shí)時(shí)數(shù)據(jù) → 觸發(fā)工具調(diào)用 → 匯總所有信息 → 大模型生成回答 → 更新長(zhǎng)期記憶 → 輸出結(jié)果每一步都有一個(gè)明確的“負(fù)責(zé)人”。意圖解析和生成回答由大模型負(fù)責(zé)歷史信息和用戶偏好從記憶模塊讀取知識(shí)庫(kù)相關(guān)內(nèi)容來(lái)自 RAG實(shí)時(shí)操作和結(jié)構(gòu)化數(shù)據(jù)來(lái)自工具調(diào)用。各個(gè)模塊的數(shù)據(jù)都會(huì)匯聚到 Prompt 里由大模型統(tǒng)一處理和判斷。這里有一個(gè)很容易忽略的環(huán)節(jié)信息的組織方式。當(dāng)三種來(lái)源的信息同時(shí)出現(xiàn)在 Prompt 里時(shí)如果沒(méi)有清晰的段落劃分模型就會(huì)“串味”分不清哪個(gè)是歷史偏好、哪個(gè)是知識(shí)庫(kù)內(nèi)容、哪個(gè)是實(shí)時(shí)數(shù)據(jù)。我在設(shè)計(jì) Prompt 時(shí)會(huì)刻意用分組標(biāo)簽把所有外部信息隔開(kāi)并在指令里聲明每個(gè)來(lái)源的優(yōu)先級(jí)和使用方式模型回答的穩(wěn)定性就會(huì)上一個(gè)臺(tái)階。5.2 Agent Loop循環(huán)什么時(shí)候該停真正的 Agent 并不是“問(wèn)一句答一句”的直線模型它往往要經(jīng)歷多輪“思考-行動(dòng)-觀察”的循環(huán)。我把這個(gè)循環(huán)簡(jiǎn)化為三步觀察當(dāng)前狀態(tài)和已有信息決定下一步行動(dòng)行動(dòng)觸發(fā)工具調(diào)用或檢索觀察結(jié)果判斷是否還需要繼續(xù)或者是否可以生成最終回答。這個(gè)循環(huán)需要設(shè)計(jì)終止條件否則容易出現(xiàn)無(wú)限循環(huán)。我的項(xiàng)目里一般設(shè)置了三道保險(xiǎn)模型自身判斷任務(wù)已完成輸出最終答案達(dá)到最大迭代次數(shù)上限一般設(shè)置在 8 到 10 輪強(qiáng)制結(jié)束循環(huán)中出現(xiàn)重復(fù)的相同工具調(diào)用且沒(méi)有新增信息觸發(fā)中斷。有一回測(cè)試一個(gè)自動(dòng)定票的 Agent它在訂票確認(rèn)環(huán)節(jié)反復(fù)調(diào)用同一個(gè)查詢接口原因是因?yàn)樯弦徊焦ぞ叻祷乩锏哪硞€(gè)字段它沒(méi)解析對(duì)就一直重試。后來(lái)我在循環(huán)邏輯里加了“相同工具調(diào)用超過(guò)三次且參數(shù)相同就中止”的規(guī)則把問(wèn)題解決了。這類異常在真實(shí)場(chǎng)景里非常常見(jiàn)建議你在設(shè)計(jì)循環(huán)時(shí)提前考慮。5.3 一個(gè)具體例子某銷售數(shù)據(jù)分析 Agent用一個(gè)虛構(gòu)的場(chǎng)景把上面的協(xié)同串起來(lái)。假設(shè)你在做一個(gè)“銷售數(shù)據(jù)分析 Agent”用戶問(wèn)“幫我看看這個(gè)月華東區(qū)銷量為什么大幅下降?！钡谝徊酱竽Ｐ徒馕鲆鈭D發(fā)現(xiàn)這是一個(gè)數(shù)據(jù)分析類請(qǐng)求。記憶模塊的短期記憶記住了“當(dāng)前對(duì)話客戶想看華東區(qū)”長(zhǎng)期記憶里調(diào)出了用戶偏好“報(bào)告用簡(jiǎn)版格式”。第二步大模型認(rèn)為缺少實(shí)時(shí)數(shù)據(jù)觸發(fā)工具調(diào)用 query_sales_data參數(shù)是華東區(qū)、本月、環(huán)比上月。工具返回銷售數(shù)據(jù)結(jié)果顯示兩大主力產(chǎn)品線下滑明顯。第三步大模型不滿足于這個(gè)現(xiàn)象想知道下滑的可能原因于是觸發(fā) RAG 檢索從公司知識(shí)庫(kù)里檢索“華東區(qū) 產(chǎn)品線 銷量下滑 原因”相關(guān)文檔召回了兩份資料一份提到渠道政策調(diào)整一份提到競(jìng)品低價(jià)策略。第四步模型把所有信息匯總短期記憶里的對(duì)話目標(biāo)、長(zhǎng)期記憶里的用戶偏好、工具返回的實(shí)時(shí)數(shù)據(jù)、RAG 檢索到的背景資料統(tǒng)一加工成一份簡(jiǎn)版分析報(bào)告并指出“實(shí)時(shí)數(shù)據(jù)表明下滑集中在產(chǎn)品線 A知識(shí)庫(kù)資料顯示同期渠道政策有調(diào)整建議進(jìn)一步核查”。第五步系統(tǒng)把這次分析的關(guān)鍵結(jié)論寫(xiě)入長(zhǎng)期記憶方便用戶下次追問(wèn)時(shí)能直接關(guān)聯(lián)。這整個(gè)過(guò)程看起來(lái)并不復(fù)雜但每一環(huán)都依賴前面模塊輸出的質(zhì)量。記憶不準(zhǔn)、檢索不到、工具參數(shù)錯(cuò)誤任何一個(gè)環(huán)節(jié)出問(wèn)題最終回答都會(huì)失真。6. 落地實(shí)操與排障手記6.1 框架選型從快速驗(yàn)證到深度定制做 Agent 落地第一個(gè)躲不開(kāi)的問(wèn)題是用編排框架還是自研。各種開(kāi)源的 Agent 編排框架確實(shí)可以幫你快速搭出原型省去寫(xiě)底層流程的功夫。但用的時(shí)間長(zhǎng)了你會(huì)發(fā)現(xiàn)框架帶來(lái)的抽象有時(shí)也是一種負(fù)擔(dān)框架封裝好的 Agent Loop、工具調(diào)用方式、記憶策略不一定匹配你的場(chǎng)景調(diào)試起來(lái)反而更費(fèi)勁。我的建議是分階段走。在快速驗(yàn)證階段依賴主流的編排框架和云平臺(tái)的 Agent 服務(wù)盡快搭出閉環(huán)驗(yàn)證核心場(chǎng)景的可行性。等業(yè)務(wù)邏輯跑通、產(chǎn)品方向明確以后再考慮逐步替換先自研 Prompt 管理、再自研工具調(diào)用層、再自研記憶和檢索策略。自研不是目的可控制性才是。大團(tuán)隊(duì)建議早點(diǎn)自研粘合層因?yàn)榭蚣艿母鹿?jié)奏和你的業(yè)務(wù)深度綁定之后維護(hù)成本會(huì)越來(lái)越高小團(tuán)隊(duì)則建議先框架后遷移用最低成本驗(yàn)證價(jià)值。6.2 常見(jiàn)問(wèn)題速查表我在實(shí)際項(xiàng)目里積累了一些高頻問(wèn)題和對(duì)應(yīng)的排查思路整理成一張速查表方便大家遇到類似情況時(shí)直接對(duì)照故障現(xiàn)象排查思路參考方案RAG 檢索經(jīng)常返回?zé)o關(guān)內(nèi)容檢查 chunk 切分是否合理檢查 query 是否需要改寫(xiě)檢查 top_k 召回?cái)?shù)量調(diào)整 chunk 大小和重疊率加 query 改寫(xiě)引入 rerank 精排工具調(diào)用頻繁報(bào)參數(shù)錯(cuò)誤查看模型生成的參數(shù)是否合法檢查工具描述是否清晰外部執(zhí)行器做參數(shù)校驗(yàn)優(yōu)化工具描述和參數(shù)示例Agent 反復(fù)執(zhí)行無(wú)用操作是否出現(xiàn)相同調(diào)用循環(huán)是否缺乏終止條件限制最大迭代次數(shù)增加重復(fù)調(diào)用中斷規(guī)則回答前后矛盾短期和長(zhǎng)期記憶沖突多個(gè)信息來(lái)源無(wú)優(yōu)先級(jí)在 Prompt 中聲明優(yōu)先級(jí)新指令優(yōu)先于歷史偏好調(diào)用鏈路過(guò)長(zhǎng)、Token 消耗高工具結(jié)果過(guò)大未壓縮記憶檢索范圍過(guò)大工具結(jié)果摘要化記憶檢索設(shè)置上限精簡(jiǎn)工具列表6.3 調(diào)試與觀測(cè)沒(méi)有日志就無(wú)法優(yōu)化Agent 這種多模塊協(xié)作的系統(tǒng)最怕的就是“黑盒”。用戶給了一個(gè)指令系統(tǒng)內(nèi)部做了七八個(gè)步驟最后輸出一個(gè)答案如果中間任何一步出了問(wèn)題你根本不知道是哪一步。所以我在做任何 Agent 項(xiàng)目時(shí)第一件事就是把結(jié)構(gòu)化日志搭起來(lái)。每條請(qǐng)求分配一個(gè) trace_id日志里記錄每個(gè)關(guān)鍵事件用戶輸入、意圖解析結(jié)果、記憶命中情況、RAG 召回片段、工具調(diào)用參數(shù)和返回結(jié)果、模型中間輸出、最終回答。每個(gè)事件記錄模塊名、耗時(shí)和 Token 消耗。排查問(wèn)題時(shí)只需要撈出一條 trace_id就能把整個(gè)執(zhí)行鏈路完整還原出來(lái)問(wèn)題出在哪個(gè)環(huán)節(jié)一目了然。大模型應(yīng)用的調(diào)試方法和傳統(tǒng)軟件有一個(gè)很大的區(qū)別沒(méi)有 debugger 可以逐步斷點(diǎn)跟蹤很多時(shí)候只能靠日志和中間產(chǎn)物來(lái)還原過(guò)程。這就更需要把“過(guò)程留痕”做到位。我還會(huì)用“影子模式”做灰度測(cè)試新版本 Agent 先只記錄所有決策和工具調(diào)用過(guò)程不執(zhí)行真實(shí)操作跑一段時(shí)間和舊版本做對(duì)比確認(rèn)沒(méi)問(wèn)題后再切換線上流量。這種方式成本不高但能擋住大量潛在事故。踩過(guò)幾次坑之后我的體會(huì)是Agent 不是把四個(gè)模塊堆在一起就能跑的真正決定上限的是模塊之間的接縫處理。記憶怎么寫(xiě)入、檢索結(jié)果怎么排序、工具結(jié)果怎么壓縮、沖突信息怎么仲裁這些細(xì)節(jié)在每個(gè)項(xiàng)目里都需要反復(fù)調(diào)優(yōu)。你不需要一開(kāi)始就追求完美架構(gòu)先把最小閉環(huán)跑通再把日志鋪好然后一個(gè)一個(gè)坑去填平。這套方法論比我見(jiàn)過(guò)的任何花哨設(shè)計(jì)都更可靠。