2025年還沒過完圈子里就開始給RAG寫悼詞了?！癛AG已死”、“下一步是上下文工程”這類標題我刷到過不止一次每次都能收獲大量轉(zhuǎn)發(fā)。作為一個實際把檢索增強生成接到業(yè)務(wù)系統(tǒng)里、被檢索漂移坑過無數(shù)回的一線程序員我的態(tài)度很明確RAG不會死真正會被淘汰的是“只會把RAG當萬能拼接器”的粗暴用法。2026年真正該補的課是上下文工程——把有限的上下文窗口當成一項預(yù)算來管理系統(tǒng)化地決定哪些信息進、哪些信息不進、以什么結(jié)構(gòu)進、如何壓縮與緩存。這篇文章不販賣焦慮只講清楚兩個概念的分工邊界并把小白能直接復(fù)現(xiàn)的搭建、調(diào)優(yōu)和排錯經(jīng)驗一并放出來。1. RAG和上下文工程到底在爭什么1.1 先給RAG“驗尸”它到底死沒死RAG的全稱是檢索增強生成核心思路非常樸素模型記不住或者不該記住的知識先放到外部存儲里用戶提問時先檢索相關(guān)片段再把片段拼進提示詞。打個比方你讓一個記憶力一般的人去開卷考試他不需要背完整本教材只需要知道去哪一章翻答案然后把關(guān)鍵段落抄進答題卡。這套思路從誕生起就是為解決大模型的知識過期、編造和私有數(shù)據(jù)無法進入模型參數(shù)這三個問題而且直到今天這三個問題依然是應(yīng)用落地的核心瓶頸。如果“RAG已死”的意思是它要被某種新架構(gòu)徹底取代那它得先回答一個問題在私有知識庫問答、企業(yè)級客服工單處理、風控合規(guī)審查這類必須給溯源依據(jù)的場景里不用RAG你還能用什么答案幾乎是一個字都換不了。模型參數(shù)不會因為你花錢買了大窗口就自動更新企業(yè)客戶要的不是“好像知道”而是“你有本事把哪份文檔、哪一頁、哪個條款列出來”。所以我不但不認為RAG死了反而認為它在落地價值上比前兩年更清晰。那為什么會有“RAG已死”這種說法因為很多人用RAG的時候其實是把它理解成了“拼裝檢索結(jié)果”。前端把用戶問題丟給一個向量庫取回一堆相似片段再用模板一拼完工。結(jié)果檢索不準、片段互相矛盾、上下文塞過載導(dǎo)致生成質(zhì)量下降最后把這筆賬全部算在RAG頭上。實際上這是典型的水管漏水賴水廠——檢索出的是證據(jù)但證據(jù)能不能被模型有效使用取決于你怎么組織、篩選、壓縮和路由這些證據(jù)這已經(jīng)屬于上下文工程的范疇了。1.2 上下文工程是個什么工程上下文工程英文叫Context Engineering字面上看就是“對上下文做工程化治理”。它不是某一天突然冒出來的新架構(gòu)而是一個從提示詞工程進化出來的系統(tǒng)工程。提示詞工程解決的是“單個prompt怎么寫更有效”上下文工程解決的是“整個應(yīng)用每次調(diào)用時應(yīng)該攜帶哪些信息、不帶哪些信息以及這些信息用什么順序和結(jié)構(gòu)進入模型”。我更喜歡用“廚房配菜”來類比提示詞工程像菜譜告訴你糖放幾克、鹽放幾勺上下文工程像后廚的備菜流程決定今天店里來了客人之后哪些食材送進炒鍋、哪些進冷藏室、哪些直接丟垃圾桶后廚整體能不能在高峰期把幾十個訂單穩(wěn)定出菜。它關(guān)注的不只是最后那一勺調(diào)味而是從食材采購數(shù)據(jù)源接入到預(yù)處理清洗過濾再到裝盤順序上下文排版的完整鏈路。所以上下文工程至少包含四件事上下文的獲取、篩選、壓縮與編排上下文的緩存與版本管理上下文的來源跟蹤和預(yù)算控制以及上下文質(zhì)量的可觀測和可評測。這東西聽起來確實比“寫提示詞”重得多但只有把它當成一個工程系統(tǒng)來做才能穩(wěn)定地扛住線上流量和業(yè)務(wù)復(fù)雜度。1.3 兩者的頂層關(guān)系不是替代是分工我的判斷是RAG和上下文工程不是競爭關(guān)系而是局部與整體的關(guān)系。RAG管的是“知識從外部存儲到模型輸入”這一段它是上下文工程的一個關(guān)鍵子模塊。上下文工程管的是“模型輸入層整個生命周期”包括系統(tǒng)提示詞、用戶歷史、工具返回結(jié)果、檢索片段、模型內(nèi)部記憶甚至安全指令全都要在被模型看到之前過一遍治理流程。換個角度說RAG產(chǎn)出的檢索結(jié)果只是“半成品證據(jù)”它能不能被有效使用取決于上下文工程里的排序、壓縮、去重、格式化和預(yù)算分配。很多團隊只做RAG不做上下文工程上線后效果像開盲盒換一條query效果不錯換一條就幻覺百出。根因往往是檢索沒問題但上下文拼裝環(huán)節(jié)完全失控。理解了這層關(guān)系之后再去定義2026年的技術(shù)路線就會清晰很多不會寫作能力、不會做路由的RAG確實不夠用但把RAG嵌入到一個成熟的上下文工程體系里它依然是當前性價比最高的知識注入方式。2. 為什么2025年突然有人喊“RAG已死”2.1 token窗口狂漲帶來的幻覺這兩年各家大模型廠商都在瘋狂推長上下文一百萬字、幾百萬token的窗口一個個冒出來。于是很多人產(chǎn)生了一個直接聯(lián)想既然窗口這么大那我可以把整份產(chǎn)品文檔、整本規(guī)章制度甚至整個知識庫的轉(zhuǎn)儲都塞進提示詞從此再也不需要做檢索。這種思路聽起來很解脫但實際跑過的人基本都會在成本和效果兩方面被打臉。先說成本。長上下文對應(yīng)的輸入價格不會因為塞得多就便宜每次請求都帶上幾十萬token傳輸耗時、排隊耗時、模型首字延遲全部上漲用戶感受到的“響應(yīng)慢”還不是最致命的真正致命的是把幾乎不可能穩(wěn)定復(fù)用的長文本反復(fù)發(fā)送單個用戶日活帶來的機器成本就能把項目的單位經(jīng)濟模型打穿。再說效果。模型接收超長上下文時注意力在這么多token之間分配得很不均。很多簡單的長文本評測能過但只要換成需要跨多個片段做多步推理的復(fù)雜任務(wù)效果依然會明顯退化。這就像開卷考試帶了一整車書進去翻找和定位的時間成本暴漲最后答題時真正有效的信息密度反而降低了。超長窗口的真正價值不在于“替代檢索”而在于給上下文工程留出更大的緩存空間和更長的對話記憶。窗口再大也不能成為不做信息篩選的借口。2.2 RAG管線復(fù)雜之后的口碑滑坡喊“RAG已死”的第二股力量來自真實落地中的一堆敗退體驗。RAG管線的經(jīng)典環(huán)節(jié)包括文檔切分、向量化、索引、召回、重排序、提示詞拼裝每一個環(huán)節(jié)都有不少“輕松翻車”的死角這幾年公開吐槽RAG效果差的聲音越來越多我總結(jié)了一下常見的翻車集中在下面幾類管線環(huán)節(jié)常見問題直接后果文檔切分切塊大小和重疊策略一刀切語義被截斷召回結(jié)果答非所問向量化沒有針對特定領(lǐng)域做適配近義詞理解差檢索召回率偏低索引管理元數(shù)據(jù)缺失版本升級后舊文檔沒下線新舊信息混著用輸出錯得離譜重排序只看語義相關(guān)不看時效和權(quán)威性模型被錯誤證據(jù)帶跑提示詞拼裝把海量檢索片段不加整理全塞進去上下文膨脹模型無法聚焦這些問題本質(zhì)上不是“RAG方法錯了”而是“只做了RAG的殼沒做上下文的魂”。但站在旁觀者和媒體視角現(xiàn)象就是“RAG項目上線效果差”于是標題越寫越驚悚慢慢傳成了“RAG已死”。這兩年我在幾個社區(qū)和技術(shù)群里看到的現(xiàn)象是那些把RAG穩(wěn)定跑出業(yè)務(wù)價值的團隊幾乎無一例外都花了大量時間在上下文工程相關(guān)的臟活累活上比如切塊邊界分析、元數(shù)據(jù)設(shè)計、檢索結(jié)果的壓縮和排序規(guī)則。與其說這些團隊靠RAG取勝不如說他們靠的是上下文工程。2.3 真正變化的不是技術(shù)是問題定義方式說到底2025年最大的變化不是某個模型突然不行了而是大家終于開始用“問題定義”的角度重新審視大模型應(yīng)用。以前我們問怎么把知識塞進模型現(xiàn)在開始問一次完整的對話或任務(wù)它的上下文應(yīng)該長什么樣哪些信息是可信的哪些信息會引入噪聲預(yù)算怎么分配來源怎么追溯這幾問正好是上下文工程的核心盤面。這個轉(zhuǎn)變不是技術(shù)換代而是工程視角的升級。就好比以前做飯關(guān)注的是“用什么鍋”現(xiàn)在關(guān)注的是“整個廚房的出餐流程”。RAG仍然是那把好鍋但光有好鍋已經(jīng)不足以撐起一家餐廳。當越來越多團隊發(fā)現(xiàn)問題定義視角需要升級時“RAG已死”這類話就成了這場升級的粗暴注腳。我看標題從來只看它背后的底層信號大家不是在否定檢索增強而是在呼喚更系統(tǒng)的上下文治理能力。3. 從零搭一個上下文工程工作流3.1 先盤清楚你的“上下文資產(chǎn)”我剛接觸上下文工程時犯過一個錯誤一上來就寫了很多花哨的提示詞模板結(jié)果線上效果沒有任何提升。后來想明白了提示詞只是上下文最后一公里真正要處理的是一整批“上下文資產(chǎn)”。建議先花時間把應(yīng)用里所有會進入模型輸入的信息分門別類我在實際項目里用的是下面這份分類清單資產(chǎn)類型典型內(nèi)容進入上下文的方式靜態(tài)系統(tǒng)上下文角色設(shè)定、任務(wù)目標、安全指令、輸出格式每次請求固定拼裝動態(tài)業(yè)務(wù)上下文用戶畫像、權(quán)限標簽、當前訴求、歷史會話摘要按用戶和會話動態(tài)組裝檢索上下文知識庫片段、工具返回結(jié)果、外部接口數(shù)據(jù)由召回和重排序產(chǎn)出記憶上下文跨會話偏好、長期用戶意圖、業(yè)務(wù)常量從緩存或記憶服務(wù)讀取盤完這四類資產(chǎn)之后還有一個要立刻補上的動作給每個資產(chǎn)塊打上來源標記。我這邊所有的上下文塊統(tǒng)一帶上doc_id、version、source_type、timestamp這些字段別嫌麻煩后面一旦出問題沒有來源標記你連排查的依據(jù)都找不到。3.2 上下文打包與分層策略資產(chǎn)盤清楚了接下來是“怎么組裝”。我會把最終交給模型的提示詞分成四層系統(tǒng)層、任務(wù)層、證據(jù)層、示例層。系統(tǒng)層是固定不變的骨架包含角色、任務(wù)定義、安全邊界和思考規(guī)則這一層要精簡再精簡。我見過不少團隊的system prompt寫得比論文還長把一堆“你是一個強大的AI”“請認真回答”之類的廢話全塞進去除了稀釋注意力之外毫無價值。任務(wù)層放的是用戶當前這一輪的訴求包括通過查詢解析拆出來的關(guān)鍵參數(shù)、語境補充和明確目標。證據(jù)層放的是檢索片段和工具結(jié)果這是整個組裝過程中最需要做預(yù)算控制的一層對此我的經(jīng)驗是并不是召回的片段越多越好真正有效的信息密度才是核心指標。示例層放少量few-shot例子好的示例比反復(fù)強調(diào)“請按JSON格式輸出”這類重復(fù)指令有用得多但示例務(wù)必短小精準否則就是在給上下文增加無謂的開銷。組裝的順序有一個樸素原則先放模型該優(yōu)先看的東西后放補充信息。很多應(yīng)用把所有內(nèi)容一股腦按某種固定順序拼接結(jié)果模型更關(guān)注中間段落而不是最后的結(jié)論這本質(zhì)上是上下文排版沒做好。3.3 用一份最簡單的上下文模板跑通Demo說再多理論不如跑一個最小可復(fù)現(xiàn)的Demo。下面這個Python偽代碼是我在搭建原型時用的基礎(chǔ)模板沒有依賴任何特定框架純用標準庫的思路演示“先拆資產(chǎn)、后組裝、再壓縮”的流程def build_context(query, profile, retrieved_chunks, examples, budget3000): blocks [] # 1. 系統(tǒng)層固定但控制長度 system_block render_system_prompt(roleprofile[role], safety_rulesprofile[safety]) blocks.append((system, system_block)) # 2. 證據(jù)層按相關(guān)度排序逐步分配預(yù)算 remaining budget - estimate_tokens(system_block) for chunk in sorted(retrieved_chunks, keylambda x: x[score], reverseTrue): block [證據(jù)|doc_id{}|version{}|time{}]\n{}.format( chunk[doc_id], chunk[version], chunk[timestamp], chunk[text] ) if estimate_tokens(block) remaining: blocks.append((evidence, block)) remaining - estimate_tokens(block) else: break # 3. 任務(wù)層用戶的真實訴求必須完整放在證據(jù)之后 task_block [用戶訴求]\n query if estimate_tokens(task_block) remaining: blocks.append((task, task_block)) # 4. 示例層最后放預(yù)算還有富余才加 for example in examples: ex_block [示例]\n example if estimate_tokens(ex_block) remaining: blocks.append((example, ex_block)) remaining - estimate_tokens(ex_block) return assemble(blocks)注意順序系統(tǒng)層固定在前證據(jù)層緊隨其后任務(wù)層放到證據(jù)層之后示例層放最后。任務(wù)層在證據(jù)層之后可能讓很多人意外但實測下來模型在讀證據(jù)時已經(jīng)在建立對問題的理解最后看到任務(wù)層時能形成“帶著證據(jù)看訴求”的效果比把用戶問題放最前面更穩(wěn)定。3.4 衡量上下文質(zhì)量的三個指標上下文做完之后不能拍腦袋說“感覺效果不錯”我強烈建議在項目里先定三條衡量標尺。第一是信息密度指有效token占全部輸入token的比例同樣一次請求如果10個片段只有2個被模型真正用上那就是密度太低。第二是覆蓋率指當前任務(wù)真正需要的關(guān)鍵事實是否出現(xiàn)在上下文中漏了必輸。第三是辨析率指模型能不能從上下文中正確選出可信證據(jù)尤其在存在多版本、多來源數(shù)據(jù)時辨析率比覆蓋率更關(guān)鍵。實際操作里我不太建議只看系統(tǒng)自動生成的指標因為自動打分經(jīng)常和用戶體驗脫節(jié)。更笨但有效的辦法是抽100條線上query人工打開一次完整的請求日志對比“上下文內(nèi)容”和“答案質(zhì)量”給每條數(shù)據(jù)打一個“是否可從上下文推導(dǎo)出正確答案”的標記。這么抽出30分鐘左右的時間一定比跑十個評測集更能暴露問題。4. 實戰(zhàn)中的RAG該怎么跟上下文工程共存4.1 檢索不是目的結(jié)構(gòu)化才是把RAG嵌入上下文工程的第一步是改變對檢索結(jié)果的心態(tài)。很多人把檢索結(jié)果當成“原文片段”直接用其實應(yīng)該把檢索結(jié)果當成“需要再次提煉的證據(jù)”。我在業(yè)務(wù)系統(tǒng)里要求所有進入上下文的知識片段必須攜帶結(jié)構(gòu)化元數(shù)據(jù)并且顯式地把元數(shù)據(jù)展現(xiàn)在提示詞里。比如{ doc_id: KB-202601-001, version: 2026.01, department: 客戶服務(wù)部, updated_at: 2026-01-15, trust_level: official, content: 針對訂單未按時送達的情況客服應(yīng)先致歉并補償10元優(yōu)惠券。 }在提示詞中顯式帶上doc_id和version這個動作看似只多了幾個字段實際效果差異非常大。模型在這些字段的引導(dǎo)下會更傾向于把它當成事實依據(jù)而不是自由發(fā)揮的語料。相反如果只把原文文本扔進去模型的“知識引用感”會弱很多幻覺概率隨之升高。4.2 長文檔處理的經(jīng)典組合預(yù)切分重排序壓縮處理長文檔時我用的組合套路是預(yù)切分、重排序、上下文壓縮三段式。首先是預(yù)切分塊大小我一般控制在250到500個token之間重疊量取50到80個token這個參數(shù)是多次測試下來的平衡點。塊太大語義完整但噪聲多塊太小語義被切開但定位準。其次是重排序初召回取回來前面30到50條通過重排序模型篩到前10條左右。千萬別把所有召回結(jié)果都交給模型我給這個上限做的是硬截斷。最關(guān)鍵的是第三步上下文壓縮。這一步的核心是拿一個專門負責“提煉”的模型對每段證據(jù)做壓縮壓縮率控制在原長度的一半以下同時強制保留所有關(guān)鍵數(shù)字、結(jié)論以及引用編號。壓縮前后的差距我舉一個常見案例原本一份1800字的售后政策文檔被壓到不足300字僅保留退款時限、補償金額和例外條件模型回答的準確率反而明顯提升。壓縮Prompt模板我在這里共享一個可用的版本你是上下文壓縮器。請把下面的文檔壓縮到不超過原長度一半 保留與用戶可能問題直接相關(guān)的結(jié)論、數(shù)字、規(guī)則、例外條件。 輸出必須包含原始文檔編號和行號不得編造任何原文不存在的信息。4.3 一個更穩(wěn)健的混合架構(gòu)一套能上生產(chǎn)的架構(gòu)在我看來至少要有五個組件配合。查詢路由器負責判斷用戶輸入適合走檢索、走純生成還是走工具調(diào)用索引層負責知識召回和版本過濾上下文組裝層負責分層打包和token預(yù)算控制緩存層負責復(fù)用靜態(tài)上下文和語義緩存避免每次請求都從頭跑全鏈路校驗鏈負責在模型輸出前檢查引用完整性、關(guān)鍵數(shù)值格式和越權(quán)口徑。組件職責邊界關(guān)鍵設(shè)計點查詢路由器判斷用戶意圖類型用輕量分類模型或規(guī)則不要為了查一句話去跑大型RAG鏈路索引層知識召回、元數(shù)據(jù)過濾強制版本、部門、權(quán)限字段的過濾前置上下文組裝層分層拼裝、預(yù)算分配單層預(yù)算上限超了就壓縮不硬塞緩存層靜態(tài)模板緩存、語義緩存緩存鍵必須包含模板版本號和關(guān)鍵業(yè)務(wù)參數(shù)校驗鏈輸出前引用與數(shù)值校驗引用doc_id必須存在于本次證據(jù)集否則強制回歸或重生成這套架構(gòu)跑下來RAG并沒有消失它只是被壓縮成了“索引層”這個角色。整個系統(tǒng)的穩(wěn)定性從依賴某一個環(huán)節(jié)的效果變成了依賴多個環(huán)節(jié)的協(xié)同治理這也正是上下文工程想表達的中心思想。5. 線上事故復(fù)盤一次“無效上下文”連環(huán)翻車5.1 事故鏈路從檢索漂移到輸出全錯前面講了不少理論來說一個我印象非常深的線上事故。當時我們運營的是一個內(nèi)部知識庫問答系統(tǒng)就叫模擬項目X知識庫里有大量按季度更新的業(yè)務(wù)報表文檔。有一次客服同事在系統(tǒng)里提問“上個季度的退貨率是多少”模型給了一個數(shù)字客服直接引用了這個數(shù)字去答復(fù)客戶結(jié)果客戶反饋“這個數(shù)據(jù)不對吧”一查才知道模型回答的是去年同季度的數(shù)字。復(fù)盤下來問題鏈路比我預(yù)想的更長。文檔預(yù)切分時按固定窗口切舊版本文檔沒有在索引里被標記下架向量召回階段舊版本文檔與用戶提問的語義相似度和新版幾乎持平重排序模型只按語義相關(guān)度打分根本不關(guān)心時間新舊上下文壓縮階段在處理兩段落時把舊版和新版的關(guān)鍵數(shù)字拼到了同一個壓縮片段里還丟了版本標記。最終模型看到的上下文里新舊數(shù)據(jù)是混在一起且無主次的它自然傾向選那個更“順眼”的數(shù)值。這條鏈路里沒有任何一個環(huán)節(jié)是單獨崩潰的但它們串聯(lián)之后直接形成了一次不可接受的錯誤回答。5.2 排查過程先看召回還是先看上下文事故發(fā)生后團隊按直覺先去查檢索日志折騰半天也沒完全定位問題。后來我調(diào)整了排查順序先看模型最終收到的上下文再倒推是哪個環(huán)節(jié)輸入錯了。這個順序很關(guān)鍵因為輸出質(zhì)量直接取決于最終上下文很多時候召回結(jié)果沒問題問題出在拼裝或壓縮過程中。我們重新跑了一遍相同的用戶query把模型最終收到的完整上下文打印出來發(fā)現(xiàn)里面既有新版文檔的結(jié)論也有舊版文檔的數(shù)值兩者還被壓縮層合成了一段“混合結(jié)論”。為了把排查過程寫得可復(fù)現(xiàn)我整理出了當時的排查鏈路排查步驟看到的現(xiàn)象初步結(jié)論打印模型完整輸入上下文中存在兩個版本號且壓縮片段未標注版本上下文組裝層版本標記失效檢查重排序結(jié)果新舊文檔相關(guān)度分數(shù)相差不到1%重排序時間衰減因子缺失檢查索引庫文檔狀態(tài)舊版文本文檔狀態(tài)未置為不可檢索索引元數(shù)據(jù)更新流程有漏洞檢查壓縮prompt未要求保留文檔編號和版本壓縮模板設(shè)計不安全所以排查RAG類問題時我建議把80%的精力放在“最終上下文長什么樣”上而不是一開始就懷疑向量庫召回率不行。上下文是模型唯一消費的東西它如果沒有把準確的證據(jù)放在正確的位置再好的召回模型也救不回來。5.3 修復(fù)方案與驗證結(jié)果修復(fù)動作從索引層一路做到提示詞層從上到下補了四個口子。第一所有文檔寫入索引之前強制校驗版本號和生命周期狀態(tài)舊版狀態(tài)的文檔禁止進入檢索結(jié)果這個用索引過濾器就解決了。第二重排序階段加入時間衰減因子同樣語義相關(guān)度下新近文檔的得分加權(quán)更高衰減強度我取了半衰期策略避免一刀切殺死歷史文檔。第三壓縮prompt里強制要求“輸出必須保留原文檔ID與版本號且禁止將不同版本的數(shù)值合并到同一結(jié)論”。第四輸出端加了一條引用校驗規(guī)則模型回答里出現(xiàn)的doc_id必須在本次輸入上下文的證據(jù)集合里存在如果引用了一個不存在的doc_id就觸發(fā)重新生成或返回兜底話術(shù)。修復(fù)之后我拉了一批歷史query重新驗證發(fā)現(xiàn)錯誤引用從幾乎每周都有爆發(fā)降到了連續(xù)四周為零漏答率也從8.1%降到了1.2%左右。復(fù)盤結(jié)束后我最大的教訓(xùn)是線上RAG系統(tǒng)出問題通常不是單個環(huán)節(jié)壞了而是上下文在鏈路里被悄悄污染了。沒有來源健壯性再聰明的模型都幫不了你。6. 2026年做上下文工程的三個繞不開的坑6.1 上下文從哪來數(shù)據(jù)血緣與來源標注第一個必須補的習(xí)慣是給每一條上下文記錄建立數(shù)據(jù)血緣。所謂數(shù)據(jù)血緣就是得能回答“這條結(jié)論是從哪個文檔、哪個版本、哪個時間點來的”。企業(yè)知識庫的問題比通用場景嚴重得多同一套政策可能一年改三次每次改版都會產(chǎn)生“新舊并存”的窗口期。如果不帶版本標記模型在這個窗口期里就很容易把舊內(nèi)容當成當前有效內(nèi)容。具體落到操作上入庫前給每份文檔生成唯一document_id對該文檔內(nèi)容做hash存成指紋所有引用片段在拼入上下文時都帶上這兩個字段。輸出階段再用引用校驗規(guī)則去核對一旦發(fā)生結(jié)果與上下文不一致就能順著doc_id迅速定位到具體來源。這套機制早期投入大約一到兩個人日但省下的排查時間可能是一個數(shù)量級。6.2 上下文往哪放緩存、路由與版本管理第二個坑是很多人把上下文工程做成了每次請求都現(xiàn)拼現(xiàn)用。再漂亮的組裝邏輯只要每次都全量重跑延遲和成本就下不來。正確做法是把上下文分層處理完全靜態(tài)的系統(tǒng)上下文在產(chǎn)品發(fā)布時已經(jīng)可以預(yù)編譯好直接走模板緩存用戶的基礎(chǔ)畫像和業(yè)務(wù)標簽按用戶維度做短期緩存檢索召回結(jié)果可以做語義緩存讓相同或近似的問題直接命中歷史結(jié)果這一步在客服類應(yīng)用里收益尤其明顯。但緩存最容易被忽視的是版本管理。指令模板一旦調(diào)整舊緩存全部要失效否則用戶會繼續(xù)看到舊說法的答案。我給模板文件加了一個content hash每次發(fā)布后緩存鍵里帶上這個hash模板一改緩存自動切新鍵。這個方法成本低且有效強烈建議直接抄。6.3 成本與延遲token是預(yù)算不是無限資源第三個坑也是2026年必然會被越來越多人關(guān)注的坑token就是錢也是延遲。我見過不少團隊為了追求“信息全面”把證據(jù)層塞得滿滿當當結(jié)果響應(yīng)速度和成本全部爆炸。上下文工程在一定程度上就是預(yù)算管理每一層能拿到多少token應(yīng)當提前定好上限。比如系統(tǒng)層固定200token任務(wù)層不超過300token證據(jù)層最多1500token超出部分要么壓縮要么丟棄。為了能在大流量下做實時控制我寫了一個極簡的token預(yù)算器原理不復(fù)雜會在組裝前先估算每個塊的長度超預(yù)算的直接跳過或交給壓縮模塊處理def estimate_tokens(text: str) - int: # 中文場景下粗略估算漢字約等于1個token英文字符粗略折半 cjk_chars sum(1 for c in text if \u4e00 c \u9fff) return int(cjk_chars (len(text) - cjk_chars) / 2) 16 def enforce_budget(blocks, budget4000): total 0 kept [] for block in blocks: cost estimate_tokens(block[payload]) if total cost budget: continue kept.append(block) total cost return kept這個預(yù)算器看似簡單但它是整個上下文工程穩(wěn)定運行的最后一道保險。線上請求每秒進來幾十個人工肉眼檢查token預(yù)算是不現(xiàn)實的必須用代碼做截斷。我踩過幾次坑之后的體會是上下文工程做得好不好取決于你愿不愿意把它當成一份長期維護的預(yù)算與信任管理活來做而不是靠一兩個花哨模板一勞永逸。2026年如果你還在為RAG的效果發(fā)愁不用急著換框架先把自己系統(tǒng)里的上下文資產(chǎn)盤清楚把來源標記、壓縮規(guī)則、緩存失效這三件事補上大概率比你想象的更有效。