簡介這是一份聚焦2024年Agent與RAG融合應(yīng)用的深度技術(shù)資料共146頁PDF圍繞八個來自一線企業(yè)的真實案例展開覆蓋游戲娛樂、泛金融、語音助手、辦公協(xié)同等場景。內(nèi)容既詳細拆解網(wǎng)易伏羲語音AI隊友、螞蟻集團agentUniverse多智能體應(yīng)用、小米語音助手等落地細節(jié)也系統(tǒng)分析RAG在緩解大模型幻覺、整合動態(tài)知識與敏感信息處理上的優(yōu)勢適合具備一定信息技術(shù)基礎(chǔ)的研發(fā)人員與技術(shù)管理者了解前沿趨勢、拓展工程思路。整份內(nèi)容以單個PDF文件打包大小12.43MB便于離線閱讀與全文檢索。案例目錄組織清晰除逐項拆解智能體交互、知識檢索增強、模型微調(diào)訓(xùn)練實踐外還提供開源框架選型、Elasticsearch落地、企業(yè)級通用助理構(gòu)建等具體技術(shù)路徑并展望了未來研究方向與挑戰(zhàn)。已有544人學(xué)習(xí)下載對關(guān)注大模型多智能體落地的從業(yè)者而言是一份兼顧廣度與深度的參考資料。1. 2024 年 AgentRAG 為什么值得做一份 146 頁案例集背后的工程信號2024 年年初到現(xiàn)在Agent 和 RAG 幾乎成了大模型應(yīng)用里曝光率最高的兩個詞。單看 RAG它解決的是“讓模型說人話之前先查資料”單看 Agent它解決的是“讓模型不只是說話還要按步驟干活”。這份 146 頁、八大案例的融合應(yīng)用探索把兩件事放到同一條鏈路里背后其實是一個很反直覺的結(jié)論RAG 做得再好也只能當(dāng)知識入口Agent 編排做得再好沒有可靠的檢索與記憶一樣會在第三步開始胡說。真正值得投入的不是二選一而是把檢索、記憶、規(guī)劃、工具調(diào)用串成一條可評估的流水線。這篇筆記適合正在做知識庫問答、企業(yè)私域智能體、業(yè)務(wù)流程自動化的從業(yè)者從架構(gòu)選擇、參數(shù)設(shè)置到排錯路徑按我們能直接復(fù)現(xiàn)的順序講清楚。2. 先看邊界RAG 補不了 Agent 的什么Agent 又補不了 RAG 的什么2.1 從“召回-生成”到“規(guī)劃-執(zhí)行”融合鏈路怎么分層很多人第一次接觸 AgentRAG最容易犯的錯是把它當(dāng)成“更聰明的 RAG”用戶提問 → 檢索 → 把檢索結(jié)果塞進提示詞 → 模型回答。這一步只完成了 RAG 的召回-生成閉環(huán)。真正的 AgentRAG 要比這多兩層一層是規(guī)劃一層是執(zhí)行反饋。我一般會把融合鏈路拆成四層來看。第一層是輸入理解決定用戶到底要“查一個事實”還是“完成一件事”第二層是檢索與記憶既包括向量庫召回也包括對話歷史、長期記憶和知識圖譜這些附加信息來源第三層是規(guī)劃模型根據(jù)檢索結(jié)果決定先調(diào)用哪個工具、要不要追問澄清第四層是執(zhí)行與校驗工具返回結(jié)果后模型要判斷結(jié)果是否滿足訴求不滿足就重新檢索或換工具。這個分層帶來的直接后果是不能再用單一提示詞來寫 Agent。常見做法是給每個階段單獨定義提示詞模板和輸出協(xié)議比如“是否需要檢索”“調(diào)用哪個技能”“給用戶的最終答復(fù)”分別走不同的結(jié)構(gòu)化輸出。這也是那份案例集里反復(fù)強調(diào)的融合應(yīng)用不是把 RAG 的代碼塊復(fù)制進 Agent 框架而是把檢索設(shè)計成 Agent 的一個可觀測動作。否則出了問題你根本分不清是召回沒召回對還是模型規(guī)劃錯了。與這套分層配套的是工具接口的標準化。以 Python 為例我會給每個檢索源和工具定義統(tǒng)一的入?yún)ⅰ⒊鰠⒔Y(jié)構(gòu)# 工具統(tǒng)一返回結(jié)構(gòu)示例 def search_knowledge_base(query: str, top_k: int 5) - dict: 統(tǒng)一的檢索工具入口返回原始結(jié)果和元數(shù)據(jù) hits vector_store.search(query, top_ktop_k) return { success: True, source_type: vector, # vector / kg / structured items: [ { content: hit.text, score: hit.score, source: hit.metadata.get(doc_id), page: hit.metadata.get(page_no), } for hit in hits ], }這段代碼的意義不只是封裝而是讓 Agent 在規(guī)劃階段能看到每次檢索的來源類型、相似度分數(shù)和文檔位置。這樣可以做到兩件事一是當(dāng)分數(shù)偏低時模型可以主動說“我不確定需要再確認”二是調(diào)試階段可以直接回放某個多輪對話看 Agent 在每一步到底檢索了什么。沒有這套結(jié)構(gòu)化返回融合應(yīng)用的排錯就全靠猜。2.2 知識庫類型向量庫、知識圖譜與結(jié)構(gòu)化庫的分工別指望一種存儲打天下這份案例集既然叫“融合應(yīng)用”里面繞不開的一個議題就是知識庫選型。RAG 這個詞在熱搜里常常被等價于“向量檢索 文檔切片”但實際項目里只靠向量庫會很快撞墻。原因在于向量檢索擅長語義相似卻天然不擅長精確約束比如“2024 年第一季度銷售額”如果這條信息沒有以較完整的句式出現(xiàn)在文檔里向量召回基本靠運氣。常見做法是把知識分成三類。第一類是非結(jié)構(gòu)化文檔適合用 embedding 模型轉(zhuǎn)成向量放向量庫第二類是實體關(guān)系比如部門、人員、產(chǎn)品的上下級歸屬、供應(yīng)商關(guān)系適合用知識圖譜KG表達查詢走圖遍歷或 SPARQL第三類是強結(jié)構(gòu)化的表格與指標適合留在 SQL 庫或數(shù)倉里讓 Agent 直接生成 SQL 去查。這三類不是替代關(guān)系而是分工關(guān)系。我在做企業(yè)知識庫時最常用的一條原則是能用 SQL 精確查的絕不放向量庫能畫成圖關(guān)系的絕不打成文本切片。往深一層說這就是熱詞里那句“rag知識庫和結(jié)構(gòu)知識庫區(qū)分以及應(yīng)用場景”的答案。結(jié)構(gòu)知識庫的價值是確定性向量庫的價值是模糊匹配。比如員工問“公司有哪些數(shù)據(jù)產(chǎn)品”這種開放問題用圖譜跑一跳鄰居關(guān)系就能得到結(jié)構(gòu)化清單但員工問“哪位同事負責(zé)過數(shù)據(jù)治理相關(guān)項目”就需要向量檢索去匹配口語化表達。真正的融合應(yīng)用會把這兩個查詢并行發(fā)出再把結(jié)果合并排序。這也是八大案例里多個案例的共同骨架——不是先查庫再回答而是同時查多個庫再交給模型綜合。選型邊界清楚了還要注意一個常見誤區(qū)一提到圖譜就以為要上 Neo4j 這類重型圖數(shù)據(jù)庫。中小項目里用 Python 的 networkx 臨時維護一張小圖或者直接用關(guān)系型數(shù)據(jù)庫的表結(jié)構(gòu)表達實體關(guān)系完全夠用。圖譜引入的成本是維護關(guān)系和寫入約束不是查詢本身。所以我建議按“百級實體以下用表千級以上再上真正圖庫”的節(jié)奏來否則維護成本很快吃掉檢索收益。2.3 上下文窗口、記憶與微調(diào)哪些用系統(tǒng)提示詞解決哪些必須動權(quán)重Agent 和 RAG 融合之后另一個繞不開的話題是大模型上下文長度。很多團隊剛開始做時看到模型支持 128K 上下文就覺得不用做記憶管理了把歷史對話全塞進去。這是一個很貴的錯覺。token 是 Agent 規(guī)劃鏈路的計量單位上下文越長單次推理延遲和成本漲得越快而且超長上下文里的注意力會稀釋檢索回來的關(guān)鍵片段反而可能被淹沒。我一般把記憶分成三層。第一層是短期上下文只保留當(dāng)前任務(wù)相關(guān)的最近幾輪對話通?？刂圃?4 到 8 輪第二層是工作記憶記錄當(dāng)前任務(wù)的目標、已完成步驟、待辦清單這部分要顯式地寫進系統(tǒng)提示詞讓 Agent 知道自己“進行到哪了”第三層是長期記憶存放用戶偏好、歷史結(jié)論等跨會話信息讀取方式不是全量加載而是用向量檢索按需召回。這三層對應(yīng)到工程上就是三個不同的存儲會話緩存、任務(wù)狀態(tài)對象、向量庫。和記憶容易混淆的是“能不能用微調(diào)代替 RAG”。這個問題在案例集中也有典型回應(yīng)微調(diào)改變的是模型的輸出風(fēng)格、格式約束和工具調(diào)用能力而不是給模型注入新知識。常見做法是先做 RAG 把事實材料喂進去如果發(fā)現(xiàn)模型總是回答格式不合規(guī)、JSON 解析失敗、不按指定語氣說話再考慮對模型做微調(diào)或?qū)R。順序不要反。由于微調(diào)是動權(quán)重的重操作一次錯誤微調(diào)可能把模型的基礎(chǔ)能力帶偏所以能靠檢索和提示詞解決的問題我從來不會先上微調(diào)。3. 八大案例的落地路徑從文檔問答到多步業(yè)務(wù)編排3.1 案例類型拆解八大案例大體歸成四類業(yè)務(wù)場景雖然沒拿到 PDF 正文逐頁內(nèi)容但這類 2024 年的 AgentRAG 案例集收錄的八個案例幾乎跑不出四個業(yè)務(wù)方向。第一類是文檔問答比如企業(yè)制度問答、產(chǎn)品手冊問答特征是問題答案能直接落在某篇文檔的某個段落里第二類是私域知識分析比如研報解讀、競品信息匯總特征是答案分散在多個來源需要多路檢索后綜合第三類是數(shù)據(jù)與表格場景比如經(jīng)營分析、銷售報表問答特征是需要從結(jié)構(gòu)化數(shù)據(jù)里做精確查詢第四類是流程編排型任務(wù)比如工單分派、合同初審、運維排查特征是必須走多步驟中途要判斷要不要追問、要不要調(diào)外部工具。這四個方向?qū)?RAG 的要求完全不同。文檔問答是基礎(chǔ)款做好切片和召回就及格私域知識分析就開始考驗 Agent 的多路檢索和結(jié)果融合能力數(shù)據(jù)表格場景必須引入文本轉(zhuǎn) SQL這時候向量庫基本退出主流程主角是 schema 定義和 SQL 生成校驗流程編排型任務(wù)則是 Agent 的主場RAG 退到工具之一模型要在“查資料 → 決策 → 執(zhí)行 → 校驗”的循環(huán)里穩(wěn)定工作。對從事具體項目的人來說看到八大案例想的不該是“我也攢八個”而是先判斷自己的業(yè)務(wù)落在哪一類。判斷標準很簡單用戶的真實訴求是“要一個答案”還是“要一件事被做完”。前者重 RAG后者重 Agent。這也是我接手項目時最先問自己的問題。如果團隊資源有限我通常建議從“文檔問答”或“表格問答”切入因為它們可評估、邊界清楚、翻車的現(xiàn)象好定位流程編排看起來炫但需要同時解決工具穩(wěn)定性和異常兜底容易項目爛尾。3.2 架構(gòu)對照單 Agent、多 Agent 與工具路由哪一種更可控案例集里另一條信息密度很高的線是每個案例用的 Agent 架構(gòu)。常見的有三種。第一種是單 Agent 加工具路由一個模型實例同時負責(zé)理解、規(guī)劃和調(diào)用適合文檔問答和簡單表格場景第二種是 supervisor 模式一個主控 Agent 負責(zé)任務(wù)拆解把子任務(wù)分給多個專家子 Agent適合私域知識分析和流程編排第三種是流水線式編排不靠模型動態(tài)規(guī)劃而是由代碼固定步驟順序適合召回鏈路穩(wěn)定、任務(wù)固定不變的生產(chǎn)場景。這三者之間最常被檢索的一個詞是“harness 和 agent 的區(qū)別”。這里要理清楚像 LangGraph 這類框架本質(zhì)上是 Agent 外殼harness它負責(zé)循環(huán)、狀態(tài)管理和工具注冊但不產(chǎn)生智能。真正的決策來自模型加提示詞加記憶。所以在我眼里框架是工程手段Agent 的定義是“能自主決定下一步調(diào)什么工具的那個循環(huán)”。把這兩個概念混在一起的人容易掉進一個坑框架能跑但業(yè)務(wù)效果卻上不去因為他們沒有認真設(shè)計每個節(jié)點的提示詞和狀態(tài)。架構(gòu)選型上我有一條保守原則模型能少調(diào)就少調(diào)。每次調(diào)用大模型都是一次不確定性注入多 Agent 協(xié)作會把不確定性級聯(lián)放大。所以能用固定路由解決的問題我不讓模型選路能用單 Agent 解決的任務(wù)我不引入多 Agent。只有任務(wù)拆分方式穩(wěn)定、子任務(wù)邊界清楚、且單 Agent 反復(fù)出現(xiàn)“上下文混用”時才應(yīng)該拆成多 Agent。八大案例里真正需要多 Agent 的場景基本都有“多個知識源強隔離且各自加工方式完全不同”這個共同特征。4. AgentRAG 融合避坑記錄五個高頻問題與排查手段4.1 檢索質(zhì)量類為什么檢索出的片段肉眼看著相關(guān)答案卻是錯的現(xiàn)象檢索命中返回的文本與問題高度相關(guān)但模型最終答案還是錯的甚至引用了文檔里并不存在的結(jié)論。原因通常不在模型而在切片和召回鏈路。最常見的是切片過大一段文本里混了多個主題導(dǎo)致向量表征被平均化召回的片段“看著相關(guān)”但關(guān)鍵數(shù)字、條件被稀釋另一種是只取了 top_k 結(jié)果沒有做重排序排在前面的是語義相似但沒有直接回答問題的段落。解決第一步把切片策略從“按字符數(shù)硬切”改成“按語義層級切”優(yōu)先按 Markdown 標題、段落、表格塊切每個切片控制在實際語義完整的最小單位。第二步加重排序先向量召回 20 到 50 條再用交叉編碼器模型精排取前 5。第三步在返回給模型前把每個片段帶上的文檔名、頁碼、章節(jié)路徑一起放進上下文讓模型能識別來源邊界。我自己的排查順序是先看切片能不能直接回答用戶問題再看 top_k 里有沒有包含正確答案最后才懷疑模型推理。4.2 編排狀態(tài)類多輪問答里Agent 做著做著就忘了任務(wù)目標現(xiàn)象用戶連續(xù)追問三四輪后Agent 開始偏離原始任務(wù)目標去回答一個已經(jīng)解決過的分支問題或者重復(fù)調(diào)用同一個工具。原因是任務(wù)狀態(tài)沒有顯式管理。很多人把歷史對話直接塞進上下文模型從一堆混雜消息里自己推斷“當(dāng)前要干什么”一旦中間出現(xiàn)歧義推斷就會跑偏。解決把“任務(wù)目標、已完成步驟、當(dāng)前待辦”單獨剝離出來以結(jié)構(gòu)化狀態(tài)對象的形式固定寫在系統(tǒng)提示詞頂部每次工具調(diào)用后由代碼更新狀態(tài)。對話歷史只作為參考資料不承擔(dān)狀態(tài)記憶職責(zé)。同時給 Agent 定義“退出條件”——如果已確認完成用戶原始訴求就直接輸出結(jié)果不再觸發(fā)新一輪檢索。這層狀態(tài)機設(shè)計比換更強模型更能直接改善穩(wěn)定性。4.3 工具調(diào)用類Agent 老把“不知道該不該查庫”當(dāng)成“要調(diào) SQL 工具”現(xiàn)象用戶問“上個月銷售額為什么下降”Agent 直接生成一段 SQL 去查詢銷售明細但因為問題里缺時間范圍條件SQL 邏輯建立在猜測上結(jié)果自然不可用。原因是工具調(diào)用的觸發(fā)條件設(shè)置得太寬。常見做法是給每個工具寫“何時該用”的描述但描述寫得太泛模型就容易在信息不足時強行調(diào)用。解決字段級約束要寫進工具描述里。比如銷售查詢工具描述里明確寫“必須包含日期范圍參數(shù)否則向用戶追問”未提供渠道維度時禁止按渠道過濾。更進一步的常見做法是加一層輕量路由先由一個小模型判斷問題是否包含查詢必需字段缺字段就先走澄清子流程再進工具調(diào)用。這一條避坑記錄回應(yīng)了熱搜里的“agent開發(fā)”難點——大部分工具失敗不是模型不行而是工具契約本身沒定義清楚。4.4 部署與安全類本地模型與 API 混用密鑰和權(quán)限被帶進上下文現(xiàn)象Agent 調(diào)用外部 API 失敗排查日志發(fā)現(xiàn) API Key 被模型當(dāng)普通文本讀了出來或者 Agent 把內(nèi)部文檔內(nèi)容拼進調(diào)用第三方服務(wù)的請求體造成越權(quán)。原因是為了開發(fā)方便把敏感信息和工具配置一起寫進了系統(tǒng)提示詞或直接用提示詞攜帶憑據(jù)。模型不具備隱私邊界意識提示詞里寫了什么它就認為什么可以用。解決憑據(jù)一律走環(huán)境變量和密鑰管理服務(wù)運行時注入到工具執(zhí)行層不進入提示詞上下文。工具返回結(jié)果也要做脫敏處理地址、手機號、內(nèi)部代號在回傳給模型前過濾一遍。與此同時給 Agent 加訪問控制列表哪些知識庫、哪些工具在什么角色下可用做成代碼層的白名單而不是靠提示詞約束。這一點放到 2024 年的 Agent 安全話題里怎么強調(diào)都不過分安全邊界必須建在模型之外。4.5 上下文污染類歷史對話里夾著錯誤信息后續(xù)回答被帶偏現(xiàn)象第一輪用戶說了一句錯誤假設(shè)Agent 沒有糾正第二輪開始這個錯誤假設(shè)被當(dāng)成事實寫進上下文導(dǎo)致后續(xù)所有回答都基于錯誤前提。原因是無論人還是機器默認會把上下文里的信息當(dāng)事實。對話歷史中用戶的斷言、Agent 自己的錯誤輸出都會污染后續(xù)檢索和推理。解決在上下文組織時對歷史消息做“事實/假設(shè)”分級存儲。常見做法是每輪對話結(jié)束后抽取模型輸出的可驗證事實單獨存到記憶里用戶在對話中的假設(shè)性表述打上“待驗證”標記不進入長期知識。如果 Agent 的答案與檢索結(jié)果沖突必須以檢索結(jié)果為準并在回復(fù)中說明。離線回歸時也要專門構(gòu)造“糾偏測試集”確認模型在用戶給出錯誤前提時能主動質(zhì)疑。5. 把融合鏈路跑起來的工程參數(shù)檢索、記憶與私有化部署5.1 RAG 檢索參數(shù)chunk 大小、top_k、相似度閾值與重排策略先給一份我在文檔問答場景里常用的起步參數(shù)表具體數(shù)值要根據(jù)你的文檔類型調(diào)但方向一般不會變。參數(shù)起步值調(diào)節(jié)方向說明切片長度400-600 字符專業(yè)文檔偏小制度文檔偏大按語義邊界切不硬按長度切片重疊50-100 字符邊界信息密度高就加大防止關(guān)鍵句子被攔腰截斷召回數(shù) top_k20-30重排后取 5向量召回要多精排再收窄相似度閾值0.3-0.5視 embedding低于閾值直接拒答不同模型分數(shù)分布不同先跑測試重排模型bge-reranker 類效果優(yōu)于純向量排序交叉編碼器慢但準embedding 模型bge-m3 / m3e 類中英文混合用多語模型不要選只支持單語的模型這里最容易被忽略的是相似度閾值。很多人不設(shè)閾值導(dǎo)致檢索不到也硬回答。我一般會先在測試集上把分數(shù)分布打出來找出“正確命中”和“錯誤命中”的分界點再把閾值設(shè)到分界點略低的位置。低于閾值時Agent 的回復(fù)模板應(yīng)切換為“知識庫中沒有找到相關(guān)信息請補充關(guān)鍵詞”。嵌入一個 Python 片段說明向量檢索的完整鏈路# 檢索鏈路召回 - 精排 - 拼裝上下文 def retrieve_context(query: str, top_k: int 25, rerank_top_n: int 5): # 1. 向量召回先放大候選池 hits vector_store.search(query, top_ktop_k) if not hits: return [] # 2. 精排交叉編碼器對 query 和候選逐條打分 pairs [(query, hit.text) for hit in hits] scores reranker.compute_score(pairs) # 3. 按精排分數(shù)取前 n 條并過濾低分 ranked sorted(zip(hits, scores), keylambda x: x[1], reverseTrue) context_items [] for hit, score in ranked[:rerank_top_n]: if score min_score: continue context_items.append({ content: hit.text, score: score, source: hit.metadata.get(source), }) return context_items這段代碼有幾個參數(shù)值得專門說。top_k 放在 25 而不是 5是因為第一次向量召回的目的是“別漏”精排的目的是“別錯”如果把候選池一開始就收窄到 5重排就沒有意義了。min_score 過濾放在精排之后而不是向量召回之后是因為向量相似度和精排分數(shù)分布完全不同精排分數(shù)更有區(qū)分度。在實際項目里這些參數(shù)的組合效果直接決定了最終回答的引用準確率。5.2 上下文與記憶窗口token 預(yù)算分配和 Agent 狀態(tài)落地Agent 鏈路里 token 消耗的大頭往往不是最終回答而是反復(fù)攜帶的上下文。我建議把每次調(diào)用的 token 預(yù)算顯式分成四份系統(tǒng)提示詞約占 10%任務(wù)狀態(tài)約占 10%檢索到的知識片段約占 40%對話歷史約占 20%留給生成的空間約 20%。這個比例不是鐵律但它強迫你思考每一份 token 是不是必要的。落到實現(xiàn)上就是把上下文按區(qū)塊拼接而不是簡單地把所有消息倒進 messages 數(shù)組。給出一個常見的組織方式# Agent 上下文組裝分區(qū)管理避免歷史消息淹沒知識片段 def build_messages(state: dict, retrieved: list[dict], history: list[dict]) - list[dict]: system_parts [ {role: system, content: AGENT_SYSTEM_PROMPT}, {role: system, content: f任務(wù)目標: {state[goal]}}, {role: system, content: f已完成步驟: {state[done]}當(dāng)前待辦: {state[todo]}}, ] # 知識片段帶來源標識獨立成塊 knowledge_block \n.join( f[來源:{item[source]}] {item[content]} for item in retrieved ) return system_parts [ {role: system, content: f參考資料:\n{knowledge_block}}, ] history[-6:] # 只保留最近 6 輪對話這里的關(guān)鍵設(shè)計是“任務(wù)狀態(tài)放系統(tǒng)提示詞對話歷史只留最近 6 輪”。原因很實在狀態(tài)是當(dāng)前任務(wù)的骨架每一輪都要看到歷史是血肉超過一定輪數(shù)后不僅用處變小還會引入矛盾信息。如果 Agent 需要更長期的用戶畫像不要繼續(xù)堆歷史而是另開一個長期記憶向量庫按需檢索保持主題和記憶分離。這樣 token 消耗可控而且視野清晰不會越來越糊。5.3 私有化部署與聯(lián)網(wǎng)式工具Ollama 起本地模型API 兼容層統(tǒng)一接口八大案例里有相當(dāng)一部分涉及企業(yè)私有化部署尤其是金融、政務(wù)、工業(yè)場景文檔不允許出內(nèi)網(wǎng)。常見做法是用 Ollama 拉起本地模型然后利用它與 OpenAI 兼容的 API 接口讓上層 Agent 框架只認一種協(xié)議不關(guān)心底層是本地模型還是云端 API。在 Mac 上搭建最小驗證鏈路常規(guī)步驟如下安裝 Ollama拉取一個 7B 到 14B 的中文效果較好的模型啟動服務(wù)后直接用 OpenAI SDK 的 base_url 指向本地端口。embedding 模型同樣可以本地跑再把向量庫落在本地文件或容器里。整套環(huán)境不依賴公網(wǎng)適合先在單機上驗證效果再考慮上 GPU 服務(wù)器。# 本機起一個 OpenAI 兼容的模型服務(wù) ollama pull qwen2.5:7b ollama pull bge-m3 # embedding 也走本地 ollama serve # 默認監(jiān)聽 11434兼容 OpenAI /v1 接口# 通過兼容接口調(diào)用上層 Agent 代碼無需區(qū)分本地還是云端 from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama # 本地服務(wù)不校驗 key占位即可 ) resp client.chat.completions.create( modelqwen2.5:7b, messages[{role: user, content: 根據(jù)檢索資料回答}], temperature0.2 )這段配置里值得注意的有兩點。一是 temperature 調(diào)到 0.2 左右Agent 任務(wù)要的是穩(wěn)定可復(fù)現(xiàn)不是發(fā)散創(chuàng)意二是 embedding 模型和生成模型不要混用同一個服務(wù)端口兩者顯存和批處理方式差異很大混在一起會互相拖慢。私有化部署的驗證重點不是“能不能跑通”而是“在單機條件下延遲能不能接受”。如果業(yè)務(wù)要求秒級回復(fù)7B 量化模型在 M 系列芯片或消費級顯卡上通?？梢宰龅降R庫檢索加多輪記憶疊加之后延遲會翻倍現(xiàn)場演示前必須做一次端到端的壓測。6. 交付前先做離線回歸從單條對話到案例集的驗證技巧無論用什么框架、調(diào)了什么參數(shù)最終判斷 AgentRAG 是否合格得靠可重復(fù)的離線回歸而不是現(xiàn)場“感覺不錯”。我的常用做法是把手頭二十到五十條真實問題固化成測試集每條標注期望答案和必含關(guān)鍵詞每次改動后批量跑一遍分三個維度打分數(shù)檢索命中率、答案正確率、流程完成率。檢索命中率看召回鏈路答案正確率看生成質(zhì)量流程完成率看 Agent 有沒有走完該走的步驟?；貧w測試里最值得做的技巧是“擾動測試”。把同一問題的說法換幾個版本比如“銷售額”換成“營收情況”“賣了多少”確認檢索和回答不會因為措辭漂移而失敗。這條能有效篩出切片粒度過細和 embedding 模型泛化不足的問題。另外每個失敗用例不要只看最終答案要看溯源記錄Agent 當(dāng)時檢索了什么、調(diào)用了什么工具、哪一步開始偏的。把失敗歸因到具體環(huán)節(jié)修復(fù)才有針對性。我現(xiàn)在每接一個新項目都會先搭一個最小的“問題集 記錄腳本 打分表”三件套哪怕只花半天。原因很簡單Agent 鏈路的不確定點比傳統(tǒng)軟件多一個數(shù)量級沒有離線回歸開發(fā)期可能反復(fù)被同一個坑絆倒。這條習(xí)慣幫我省下的排錯時間比任何框架選型都更多。希望幫到你。本文還有配套的精品資源點擊獲取 Agent與RAG融合實踐：從知識檢索到智能體編排的工程方法論
簡介這是一份聚焦2024年Agent與RAG融合應(yīng)用的深度技術(shù)資料共146頁PDF圍繞八個來自一線企業(yè)的真實案例展開覆蓋游戲娛樂、泛金融、語音助手、辦公協(xié)同等場景。內(nèi)容既詳細拆解網(wǎng)易伏羲語音AI隊友、螞蟻集團agentUniverse多智能體應(yīng)用、小米語音助手等落地細節(jié)也系統(tǒng)分析RAG在緩解大模型幻覺、整合動態(tài)知識與敏感信息處理上的優(yōu)勢適合具備一定信息技術(shù)基礎(chǔ)的研發(fā)人員與技術(shù)管理者了解前沿趨勢、拓展工程思路。整份內(nèi)容以單個PDF文件打包大小12.43MB便于離線閱讀與全文檢索。案例目錄組織清晰除逐項拆解智能體交互、知識檢索增強、模型微調(diào)訓(xùn)練實踐外還提供開源框架選型、Elasticsearch落地、企業(yè)級通用助理構(gòu)建等具體技術(shù)路徑并展望了未來研究方向與挑戰(zhàn)。已有544人學(xué)習(xí)下載對關(guān)注大模型多智能體落地的從業(yè)者而言是一份兼顧廣度與深度的參考資料。1. 2024 年 AgentRAG 為什么值得做一份 146 頁案例集背后的工程信號2024 年年初到現(xiàn)在Agent 和 RAG 幾乎成了大模型應(yīng)用里曝光率最高的兩個詞。單看 RAG它解決的是“讓模型說人話之前先查資料”單看 Agent它解決的是“讓模型不只是說話還要按步驟干活”。這份 146 頁、八大案例的融合應(yīng)用探索把兩件事放到同一條鏈路里背后其實是一個很反直覺的結(jié)論RAG 做得再好也只能當(dāng)知識入口Agent 編排做得再好沒有可靠的檢索與記憶一樣會在第三步開始胡說。真正值得投入的不是二選一而是把檢索、記憶、規(guī)劃、工具調(diào)用串成一條可評估的流水線。這篇筆記適合正在做知識庫問答、企業(yè)私域智能體、業(yè)務(wù)流程自動化的從業(yè)者從架構(gòu)選擇、參數(shù)設(shè)置到排錯路徑按我們能直接復(fù)現(xiàn)的順序講清楚。2. 先看邊界RAG 補不了 Agent 的什么Agent 又補不了 RAG 的什么2.1 從“召回-生成”到“規(guī)劃-執(zhí)行”融合鏈路怎么分層很多人第一次接觸 AgentRAG最容易犯的錯是把它當(dāng)成“更聰明的 RAG”用戶提問 → 檢索 → 把檢索結(jié)果塞進提示詞 → 模型回答。這一步只完成了 RAG 的召回-生成閉環(huán)。真正的 AgentRAG 要比這多兩層一層是規(guī)劃一層是執(zhí)行反饋。我一般會把融合鏈路拆成四層來看。第一層是輸入理解決定用戶到底要“查一個事實”還是“完成一件事”第二層是檢索與記憶既包括向量庫召回也包括對話歷史、長期記憶和知識圖譜這些附加信息來源第三層是規(guī)劃模型根據(jù)檢索結(jié)果決定先調(diào)用哪個工具、要不要追問澄清第四層是執(zhí)行與校驗工具返回結(jié)果后模型要判斷結(jié)果是否滿足訴求不滿足就重新檢索或換工具。這個分層帶來的直接后果是不能再用單一提示詞來寫 Agent。常見做法是給每個階段單獨定義提示詞模板和輸出協(xié)議比如“是否需要檢索”“調(diào)用哪個技能”“給用戶的最終答復(fù)”分別走不同的結(jié)構(gòu)化輸出。這也是那份案例集里反復(fù)強調(diào)的融合應(yīng)用不是把 RAG 的代碼塊復(fù)制進 Agent 框架而是把檢索設(shè)計成 Agent 的一個可觀測動作。否則出了問題你根本分不清是召回沒召回對還是模型規(guī)劃錯了。與這套分層配套的是工具接口的標準化。以 Python 為例我會給每個檢索源和工具定義統(tǒng)一的入?yún)ⅰ⒊鰠⒔Y(jié)構(gòu)# 工具統(tǒng)一返回結(jié)構(gòu)示例 def search_knowledge_base(query: str, top_k: int 5) - dict: 統(tǒng)一的檢索工具入口返回原始結(jié)果和元數(shù)據(jù) hits vector_store.search(query, top_ktop_k) return { success: True, source_type: vector, # vector / kg / structured items: [ { content: hit.text, score: hit.score, source: hit.metadata.get(doc_id), page: hit.metadata.get(page_no), } for hit in hits ], }這段代碼的意義不只是封裝而是讓 Agent 在規(guī)劃階段能看到每次檢索的來源類型、相似度分數(shù)和文檔位置。這樣可以做到兩件事一是當(dāng)分數(shù)偏低時模型可以主動說“我不確定需要再確認”二是調(diào)試階段可以直接回放某個多輪對話看 Agent 在每一步到底檢索了什么。沒有這套結(jié)構(gòu)化返回融合應(yīng)用的排錯就全靠猜。2.2 知識庫類型向量庫、知識圖譜與結(jié)構(gòu)化庫的分工別指望一種存儲打天下這份案例集既然叫“融合應(yīng)用”里面繞不開的一個議題就是知識庫選型。RAG 這個詞在熱搜里常常被等價于“向量檢索 文檔切片”但實際項目里只靠向量庫會很快撞墻。原因在于向量檢索擅長語義相似卻天然不擅長精確約束比如“2024 年第一季度銷售額”如果這條信息沒有以較完整的句式出現(xiàn)在文檔里向量召回基本靠運氣。常見做法是把知識分成三類。第一類是非結(jié)構(gòu)化文檔適合用 embedding 模型轉(zhuǎn)成向量放向量庫第二類是實體關(guān)系比如部門、人員、產(chǎn)品的上下級歸屬、供應(yīng)商關(guān)系適合用知識圖譜KG表達查詢走圖遍歷或 SPARQL第三類是強結(jié)構(gòu)化的表格與指標適合留在 SQL 庫或數(shù)倉里讓 Agent 直接生成 SQL 去查。這三類不是替代關(guān)系而是分工關(guān)系。我在做企業(yè)知識庫時最常用的一條原則是能用 SQL 精確查的絕不放向量庫能畫成圖關(guān)系的絕不打成文本切片。往深一層說這就是熱詞里那句“rag知識庫和結(jié)構(gòu)知識庫區(qū)分以及應(yīng)用場景”的答案。結(jié)構(gòu)知識庫的價值是確定性向量庫的價值是模糊匹配。比如員工問“公司有哪些數(shù)據(jù)產(chǎn)品”這種開放問題用圖譜跑一跳鄰居關(guān)系就能得到結(jié)構(gòu)化清單但員工問“哪位同事負責(zé)過數(shù)據(jù)治理相關(guān)項目”就需要向量檢索去匹配口語化表達。真正的融合應(yīng)用會把這兩個查詢并行發(fā)出再把結(jié)果合并排序。這也是八大案例里多個案例的共同骨架——不是先查庫再回答而是同時查多個庫再交給模型綜合。選型邊界清楚了還要注意一個常見誤區(qū)一提到圖譜就以為要上 Neo4j 這類重型圖數(shù)據(jù)庫。中小項目里用 Python 的 networkx 臨時維護一張小圖或者直接用關(guān)系型數(shù)據(jù)庫的表結(jié)構(gòu)表達實體關(guān)系完全夠用。圖譜引入的成本是維護關(guān)系和寫入約束不是查詢本身。所以我建議按“百級實體以下用表千級以上再上真正圖庫”的節(jié)奏來否則維護成本很快吃掉檢索收益。2.3 上下文窗口、記憶與微調(diào)哪些用系統(tǒng)提示詞解決哪些必須動權(quán)重Agent 和 RAG 融合之后另一個繞不開的話題是大模型上下文長度。很多團隊剛開始做時看到模型支持 128K 上下文就覺得不用做記憶管理了把歷史對話全塞進去。這是一個很貴的錯覺。token 是 Agent 規(guī)劃鏈路的計量單位上下文越長單次推理延遲和成本漲得越快而且超長上下文里的注意力會稀釋檢索回來的關(guān)鍵片段反而可能被淹沒。我一般把記憶分成三層。第一層是短期上下文只保留當(dāng)前任務(wù)相關(guān)的最近幾輪對話通?？刂圃?4 到 8 輪第二層是工作記憶記錄當(dāng)前任務(wù)的目標、已完成步驟、待辦清單這部分要顯式地寫進系統(tǒng)提示詞讓 Agent 知道自己“進行到哪了”第三層是長期記憶存放用戶偏好、歷史結(jié)論等跨會話信息讀取方式不是全量加載而是用向量檢索按需召回。這三層對應(yīng)到工程上就是三個不同的存儲會話緩存、任務(wù)狀態(tài)對象、向量庫。和記憶容易混淆的是“能不能用微調(diào)代替 RAG”。這個問題在案例集中也有典型回應(yīng)微調(diào)改變的是模型的輸出風(fēng)格、格式約束和工具調(diào)用能力而不是給模型注入新知識。常見做法是先做 RAG 把事實材料喂進去如果發(fā)現(xiàn)模型總是回答格式不合規(guī)、JSON 解析失敗、不按指定語氣說話再考慮對模型做微調(diào)或?qū)R。順序不要反。由于微調(diào)是動權(quán)重的重操作一次錯誤微調(diào)可能把模型的基礎(chǔ)能力帶偏所以能靠檢索和提示詞解決的問題我從來不會先上微調(diào)。3. 八大案例的落地路徑從文檔問答到多步業(yè)務(wù)編排3.1 案例類型拆解八大案例大體歸成四類業(yè)務(wù)場景雖然沒拿到 PDF 正文逐頁內(nèi)容但這類 2024 年的 AgentRAG 案例集收錄的八個案例幾乎跑不出四個業(yè)務(wù)方向。第一類是文檔問答比如企業(yè)制度問答、產(chǎn)品手冊問答特征是問題答案能直接落在某篇文檔的某個段落里第二類是私域知識分析比如研報解讀、競品信息匯總特征是答案分散在多個來源需要多路檢索后綜合第三類是數(shù)據(jù)與表格場景比如經(jīng)營分析、銷售報表問答特征是需要從結(jié)構(gòu)化數(shù)據(jù)里做精確查詢第四類是流程編排型任務(wù)比如工單分派、合同初審、運維排查特征是必須走多步驟中途要判斷要不要追問、要不要調(diào)外部工具。這四個方向?qū)?RAG 的要求完全不同。文檔問答是基礎(chǔ)款做好切片和召回就及格私域知識分析就開始考驗 Agent 的多路檢索和結(jié)果融合能力數(shù)據(jù)表格場景必須引入文本轉(zhuǎn) SQL這時候向量庫基本退出主流程主角是 schema 定義和 SQL 生成校驗流程編排型任務(wù)則是 Agent 的主場RAG 退到工具之一模型要在“查資料 → 決策 → 執(zhí)行 → 校驗”的循環(huán)里穩(wěn)定工作。對從事具體項目的人來說看到八大案例想的不該是“我也攢八個”而是先判斷自己的業(yè)務(wù)落在哪一類。判斷標準很簡單用戶的真實訴求是“要一個答案”還是“要一件事被做完”。前者重 RAG后者重 Agent。這也是我接手項目時最先問自己的問題。如果團隊資源有限我通常建議從“文檔問答”或“表格問答”切入因為它們可評估、邊界清楚、翻車的現(xiàn)象好定位流程編排看起來炫但需要同時解決工具穩(wěn)定性和異常兜底容易項目爛尾。3.2 架構(gòu)對照單 Agent、多 Agent 與工具路由哪一種更可控案例集里另一條信息密度很高的線是每個案例用的 Agent 架構(gòu)。常見的有三種。第一種是單 Agent 加工具路由一個模型實例同時負責(zé)理解、規(guī)劃和調(diào)用適合文檔問答和簡單表格場景第二種是 supervisor 模式一個主控 Agent 負責(zé)任務(wù)拆解把子任務(wù)分給多個專家子 Agent適合私域知識分析和流程編排第三種是流水線式編排不靠模型動態(tài)規(guī)劃而是由代碼固定步驟順序適合召回鏈路穩(wěn)定、任務(wù)固定不變的生產(chǎn)場景。這三者之間最常被檢索的一個詞是“harness 和 agent 的區(qū)別”。這里要理清楚像 LangGraph 這類框架本質(zhì)上是 Agent 外殼harness它負責(zé)循環(huán)、狀態(tài)管理和工具注冊但不產(chǎn)生智能。真正的決策來自模型加提示詞加記憶。所以在我眼里框架是工程手段Agent 的定義是“能自主決定下一步調(diào)什么工具的那個循環(huán)”。把這兩個概念混在一起的人容易掉進一個坑框架能跑但業(yè)務(wù)效果卻上不去因為他們沒有認真設(shè)計每個節(jié)點的提示詞和狀態(tài)。架構(gòu)選型上我有一條保守原則模型能少調(diào)就少調(diào)。每次調(diào)用大模型都是一次不確定性注入多 Agent 協(xié)作會把不確定性級聯(lián)放大。所以能用固定路由解決的問題我不讓模型選路能用單 Agent 解決的任務(wù)我不引入多 Agent。只有任務(wù)拆分方式穩(wěn)定、子任務(wù)邊界清楚、且單 Agent 反復(fù)出現(xiàn)“上下文混用”時才應(yīng)該拆成多 Agent。八大案例里真正需要多 Agent 的場景基本都有“多個知識源強隔離且各自加工方式完全不同”這個共同特征。4. AgentRAG 融合避坑記錄五個高頻問題與排查手段4.1 檢索質(zhì)量類為什么檢索出的片段肉眼看著相關(guān)答案卻是錯的現(xiàn)象檢索命中返回的文本與問題高度相關(guān)但模型最終答案還是錯的甚至引用了文檔里并不存在的結(jié)論。原因通常不在模型而在切片和召回鏈路。最常見的是切片過大一段文本里混了多個主題導(dǎo)致向量表征被平均化召回的片段“看著相關(guān)”但關(guān)鍵數(shù)字、條件被稀釋另一種是只取了 top_k 結(jié)果沒有做重排序排在前面的是語義相似但沒有直接回答問題的段落。解決第一步把切片策略從“按字符數(shù)硬切”改成“按語義層級切”優(yōu)先按 Markdown 標題、段落、表格塊切每個切片控制在實際語義完整的最小單位。第二步加重排序先向量召回 20 到 50 條再用交叉編碼器模型精排取前 5。第三步在返回給模型前把每個片段帶上的文檔名、頁碼、章節(jié)路徑一起放進上下文讓模型能識別來源邊界。我自己的排查順序是先看切片能不能直接回答用戶問題再看 top_k 里有沒有包含正確答案最后才懷疑模型推理。4.2 編排狀態(tài)類多輪問答里Agent 做著做著就忘了任務(wù)目標現(xiàn)象用戶連續(xù)追問三四輪后Agent 開始偏離原始任務(wù)目標去回答一個已經(jīng)解決過的分支問題或者重復(fù)調(diào)用同一個工具。原因是任務(wù)狀態(tài)沒有顯式管理。很多人把歷史對話直接塞進上下文模型從一堆混雜消息里自己推斷“當(dāng)前要干什么”一旦中間出現(xiàn)歧義推斷就會跑偏。解決把“任務(wù)目標、已完成步驟、當(dāng)前待辦”單獨剝離出來以結(jié)構(gòu)化狀態(tài)對象的形式固定寫在系統(tǒng)提示詞頂部每次工具調(diào)用后由代碼更新狀態(tài)。對話歷史只作為參考資料不承擔(dān)狀態(tài)記憶職責(zé)。同時給 Agent 定義“退出條件”——如果已確認完成用戶原始訴求就直接輸出結(jié)果不再觸發(fā)新一輪檢索。這層狀態(tài)機設(shè)計比換更強模型更能直接改善穩(wěn)定性。4.3 工具調(diào)用類Agent 老把“不知道該不該查庫”當(dāng)成“要調(diào) SQL 工具”現(xiàn)象用戶問“上個月銷售額為什么下降”Agent 直接生成一段 SQL 去查詢銷售明細但因為問題里缺時間范圍條件SQL 邏輯建立在猜測上結(jié)果自然不可用。原因是工具調(diào)用的觸發(fā)條件設(shè)置得太寬。常見做法是給每個工具寫“何時該用”的描述但描述寫得太泛模型就容易在信息不足時強行調(diào)用。解決字段級約束要寫進工具描述里。比如銷售查詢工具描述里明確寫“必須包含日期范圍參數(shù)否則向用戶追問”未提供渠道維度時禁止按渠道過濾。更進一步的常見做法是加一層輕量路由先由一個小模型判斷問題是否包含查詢必需字段缺字段就先走澄清子流程再進工具調(diào)用。這一條避坑記錄回應(yīng)了熱搜里的“agent開發(fā)”難點——大部分工具失敗不是模型不行而是工具契約本身沒定義清楚。4.4 部署與安全類本地模型與 API 混用密鑰和權(quán)限被帶進上下文現(xiàn)象Agent 調(diào)用外部 API 失敗排查日志發(fā)現(xiàn) API Key 被模型當(dāng)普通文本讀了出來或者 Agent 把內(nèi)部文檔內(nèi)容拼進調(diào)用第三方服務(wù)的請求體造成越權(quán)。原因是為了開發(fā)方便把敏感信息和工具配置一起寫進了系統(tǒng)提示詞或直接用提示詞攜帶憑據(jù)。模型不具備隱私邊界意識提示詞里寫了什么它就認為什么可以用。解決憑據(jù)一律走環(huán)境變量和密鑰管理服務(wù)運行時注入到工具執(zhí)行層不進入提示詞上下文。工具返回結(jié)果也要做脫敏處理地址、手機號、內(nèi)部代號在回傳給模型前過濾一遍。與此同時給 Agent 加訪問控制列表哪些知識庫、哪些工具在什么角色下可用做成代碼層的白名單而不是靠提示詞約束。這一點放到 2024 年的 Agent 安全話題里怎么強調(diào)都不過分安全邊界必須建在模型之外。4.5 上下文污染類歷史對話里夾著錯誤信息后續(xù)回答被帶偏現(xiàn)象第一輪用戶說了一句錯誤假設(shè)Agent 沒有糾正第二輪開始這個錯誤假設(shè)被當(dāng)成事實寫進上下文導(dǎo)致后續(xù)所有回答都基于錯誤前提。原因是無論人還是機器默認會把上下文里的信息當(dāng)事實。對話歷史中用戶的斷言、Agent 自己的錯誤輸出都會污染后續(xù)檢索和推理。解決在上下文組織時對歷史消息做“事實/假設(shè)”分級存儲。常見做法是每輪對話結(jié)束后抽取模型輸出的可驗證事實單獨存到記憶里用戶在對話中的假設(shè)性表述打上“待驗證”標記不進入長期知識。如果 Agent 的答案與檢索結(jié)果沖突必須以檢索結(jié)果為準并在回復(fù)中說明。離線回歸時也要專門構(gòu)造“糾偏測試集”確認模型在用戶給出錯誤前提時能主動質(zhì)疑。5. 把融合鏈路跑起來的工程參數(shù)檢索、記憶與私有化部署5.1 RAG 檢索參數(shù)chunk 大小、top_k、相似度閾值與重排策略先給一份我在文檔問答場景里常用的起步參數(shù)表具體數(shù)值要根據(jù)你的文檔類型調(diào)但方向一般不會變。參數(shù)起步值調(diào)節(jié)方向說明切片長度400-600 字符專業(yè)文檔偏小制度文檔偏大按語義邊界切不硬按長度切片重疊50-100 字符邊界信息密度高就加大防止關(guān)鍵句子被攔腰截斷召回數(shù) top_k20-30重排后取 5向量召回要多精排再收窄相似度閾值0.3-0.5視 embedding低于閾值直接拒答不同模型分數(shù)分布不同先跑測試重排模型bge-reranker 類效果優(yōu)于純向量排序交叉編碼器慢但準embedding 模型bge-m3 / m3e 類中英文混合用多語模型不要選只支持單語的模型這里最容易被忽略的是相似度閾值。很多人不設(shè)閾值導(dǎo)致檢索不到也硬回答。我一般會先在測試集上把分數(shù)分布打出來找出“正確命中”和“錯誤命中”的分界點再把閾值設(shè)到分界點略低的位置。低于閾值時Agent 的回復(fù)模板應(yīng)切換為“知識庫中沒有找到相關(guān)信息請補充關(guān)鍵詞”。嵌入一個 Python 片段說明向量檢索的完整鏈路# 檢索鏈路召回 - 精排 - 拼裝上下文 def retrieve_context(query: str, top_k: int 25, rerank_top_n: int 5): # 1. 向量召回先放大候選池 hits vector_store.search(query, top_ktop_k) if not hits: return [] # 2. 精排交叉編碼器對 query 和候選逐條打分 pairs [(query, hit.text) for hit in hits] scores reranker.compute_score(pairs) # 3. 按精排分數(shù)取前 n 條并過濾低分 ranked sorted(zip(hits, scores), keylambda x: x[1], reverseTrue) context_items [] for hit, score in ranked[:rerank_top_n]: if score min_score: continue context_items.append({ content: hit.text, score: score, source: hit.metadata.get(source), }) return context_items這段代碼有幾個參數(shù)值得專門說。top_k 放在 25 而不是 5是因為第一次向量召回的目的是“別漏”精排的目的是“別錯”如果把候選池一開始就收窄到 5重排就沒有意義了。min_score 過濾放在精排之后而不是向量召回之后是因為向量相似度和精排分數(shù)分布完全不同精排分數(shù)更有區(qū)分度。在實際項目里這些參數(shù)的組合效果直接決定了最終回答的引用準確率。5.2 上下文與記憶窗口token 預(yù)算分配和 Agent 狀態(tài)落地Agent 鏈路里 token 消耗的大頭往往不是最終回答而是反復(fù)攜帶的上下文。我建議把每次調(diào)用的 token 預(yù)算顯式分成四份系統(tǒng)提示詞約占 10%任務(wù)狀態(tài)約占 10%檢索到的知識片段約占 40%對話歷史約占 20%留給生成的空間約 20%。這個比例不是鐵律但它強迫你思考每一份 token 是不是必要的。落到實現(xiàn)上就是把上下文按區(qū)塊拼接而不是簡單地把所有消息倒進 messages 數(shù)組。給出一個常見的組織方式# Agent 上下文組裝分區(qū)管理避免歷史消息淹沒知識片段 def build_messages(state: dict, retrieved: list[dict], history: list[dict]) - list[dict]: system_parts [ {role: system, content: AGENT_SYSTEM_PROMPT}, {role: system, content: f任務(wù)目標: {state[goal]}}, {role: system, content: f已完成步驟: {state[done]}當(dāng)前待辦: {state[todo]}}, ] # 知識片段帶來源標識獨立成塊 knowledge_block \n.join( f[來源:{item[source]}] {item[content]} for item in retrieved ) return system_parts [ {role: system, content: f參考資料:\n{knowledge_block}}, ] history[-6:] # 只保留最近 6 輪對話這里的關(guān)鍵設(shè)計是“任務(wù)狀態(tài)放系統(tǒng)提示詞對話歷史只留最近 6 輪”。原因很實在狀態(tài)是當(dāng)前任務(wù)的骨架每一輪都要看到歷史是血肉超過一定輪數(shù)后不僅用處變小還會引入矛盾信息。如果 Agent 需要更長期的用戶畫像不要繼續(xù)堆歷史而是另開一個長期記憶向量庫按需檢索保持主題和記憶分離。這樣 token 消耗可控而且視野清晰不會越來越糊。5.3 私有化部署與聯(lián)網(wǎng)式工具Ollama 起本地模型API 兼容層統(tǒng)一接口八大案例里有相當(dāng)一部分涉及企業(yè)私有化部署尤其是金融、政務(wù)、工業(yè)場景文檔不允許出內(nèi)網(wǎng)。常見做法是用 Ollama 拉起本地模型然后利用它與 OpenAI 兼容的 API 接口讓上層 Agent 框架只認一種協(xié)議不關(guān)心底層是本地模型還是云端 API。在 Mac 上搭建最小驗證鏈路常規(guī)步驟如下安裝 Ollama拉取一個 7B 到 14B 的中文效果較好的模型啟動服務(wù)后直接用 OpenAI SDK 的 base_url 指向本地端口。embedding 模型同樣可以本地跑再把向量庫落在本地文件或容器里。整套環(huán)境不依賴公網(wǎng)適合先在單機上驗證效果再考慮上 GPU 服務(wù)器。# 本機起一個 OpenAI 兼容的模型服務(wù) ollama pull qwen2.5:7b ollama pull bge-m3 # embedding 也走本地 ollama serve # 默認監(jiān)聽 11434兼容 OpenAI /v1 接口# 通過兼容接口調(diào)用上層 Agent 代碼無需區(qū)分本地還是云端 from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama # 本地服務(wù)不校驗 key占位即可 ) resp client.chat.completions.create( modelqwen2.5:7b, messages[{role: user, content: 根據(jù)檢索資料回答}], temperature0.2 )這段配置里值得注意的有兩點。一是 temperature 調(diào)到 0.2 左右Agent 任務(wù)要的是穩(wěn)定可復(fù)現(xiàn)不是發(fā)散創(chuàng)意二是 embedding 模型和生成模型不要混用同一個服務(wù)端口兩者顯存和批處理方式差異很大混在一起會互相拖慢。私有化部署的驗證重點不是“能不能跑通”而是“在單機條件下延遲能不能接受”。如果業(yè)務(wù)要求秒級回復(fù)7B 量化模型在 M 系列芯片或消費級顯卡上通?？梢宰龅降R庫檢索加多輪記憶疊加之后延遲會翻倍現(xiàn)場演示前必須做一次端到端的壓測。6. 交付前先做離線回歸從單條對話到案例集的驗證技巧無論用什么框架、調(diào)了什么參數(shù)最終判斷 AgentRAG 是否合格得靠可重復(fù)的離線回歸而不是現(xiàn)場“感覺不錯”。我的常用做法是把手頭二十到五十條真實問題固化成測試集每條標注期望答案和必含關(guān)鍵詞每次改動后批量跑一遍分三個維度打分數(shù)檢索命中率、答案正確率、流程完成率。檢索命中率看召回鏈路答案正確率看生成質(zhì)量流程完成率看 Agent 有沒有走完該走的步驟?；貧w測試里最值得做的技巧是“擾動測試”。把同一問題的說法換幾個版本比如“銷售額”換成“營收情況”“賣了多少”確認檢索和回答不會因為措辭漂移而失敗。這條能有效篩出切片粒度過細和 embedding 模型泛化不足的問題。另外每個失敗用例不要只看最終答案要看溯源記錄Agent 當(dāng)時檢索了什么、調(diào)用了什么工具、哪一步開始偏的。把失敗歸因到具體環(huán)節(jié)修復(fù)才有針對性。我現(xiàn)在每接一個新項目都會先搭一個最小的“問題集 記錄腳本 打分表”三件套哪怕只花半天。原因很簡單Agent 鏈路的不確定點比傳統(tǒng)軟件多一個數(shù)量級沒有離線回歸開發(fā)期可能反復(fù)被同一個坑絆倒。這條習(xí)慣幫我省下的排錯時間比任何框架選型都更多。希望幫到你。本文還有配套的精品資源點擊獲取