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