1. 從“context-mode”這個(gè)詞說起它到底指什么第一次看到“context-mode”這個(gè)標(biāo)題很多人會(huì)愣一下——它不像“XX管理系統(tǒng)”“XX爬蟲框架”那樣一眼能看出用途。我最初接觸這個(gè)詞是在做對(duì)話系統(tǒng)上下文管理的時(shí)候當(dāng)時(shí)團(tuán)隊(duì)里有人提出“給會(huì)話加一個(gè) context-mode 開關(guān)”我才意識(shí)到這其實(shí)是一個(gè)描述“上下文處理策略”的抽象概念而不是某個(gè)具體的庫或工具。簡(jiǎn)單來說context-mode 指的是一個(gè)系統(tǒng)在處理“上下文”時(shí)采用的模式或策略。這里的“上下文”可以是一段對(duì)話的歷史消息、一次請(qǐng)求攜帶的環(huán)境參數(shù)、一個(gè)函數(shù)執(zhí)行時(shí)的作用域鏈也可以是一個(gè) AI 應(yīng)用在生成回復(fù)前需要參考的全部背景信息。而“mode”則意味著面對(duì)同樣的上下文系統(tǒng)可以選擇不同的處理方式——全量保留、滑動(dòng)窗口截?cái)?、摘要壓縮、按優(yōu)先級(jí)篩選、分層緩存等等。它解決的問題非常實(shí)際上下文不是越多越好也不是越少越好而是要在“信息完整性”和“資源消耗”之間找到平衡點(diǎn)。比如一個(gè)客服機(jī)器人如果把用戶過去三個(gè)月的所有對(duì)話都塞給模型token 成本會(huì)爆炸響應(yīng)也會(huì)變慢但如果只保留最后一句話機(jī)器人又會(huì)丟失用戶之前說過的訂單號(hào)、產(chǎn)品型號(hào)等關(guān)鍵信息。context-mode 就是用來定義“到底保留哪些、丟棄哪些、怎么組織”的那套規(guī)則。這篇文章適合三類人看一是正在做對(duì)話系統(tǒng)、Agent 應(yīng)用、RAG 管道的開發(fā)者你們一定被上下文長(zhǎng)度折磨過二是做后端服務(wù)、需要管理請(qǐng)求級(jí)上下文比如鏈路追蹤、多租戶隔離的工程師三是對(duì) AI 應(yīng)用架構(gòu)感興趣、想理解“為什么同樣的大模型不同產(chǎn)品體驗(yàn)差那么多”的技術(shù)愛好者。我會(huì)從概念拆解講到落地實(shí)現(xiàn)把我在實(shí)際項(xiàng)目里踩過的坑和總結(jié)出的模式都攤開來說。需要先說明一點(diǎn)context-mode 目前沒有一個(gè)官方標(biāo)準(zhǔn)不同團(tuán)隊(duì)對(duì)它的定義有差異。我下面講的是基于常見工程實(shí)踐歸納出來的一套理解框架你可以把它當(dāng)作設(shè)計(jì)參考而不是照搬的規(guī)范。2. 上下文為什么需要“模式”三種典型困境2.1 困境一窗口有限但信息無限增長(zhǎng)大模型的上下文窗口是有硬上限的。早期是 4K token后來到 32K、128K現(xiàn)在有些模型號(hào)稱支持百萬級(jí)。但窗口變大不等于可以無腦塞。我做過一個(gè)實(shí)測(cè)把一個(gè) 8 萬 token 的對(duì)話歷史直接喂給模型響應(yīng)延遲從 1.2 秒漲到了 7 秒以上成本翻了十幾倍而回答質(zhì)量并沒有線性提升——因?yàn)榇罅繗v史信息是冗余的反而稀釋了關(guān)鍵內(nèi)容的注意力權(quán)重。這就引出一個(gè)核心矛盾業(yè)務(wù)上希望“記住一切”工程上必須“有所取舍”。context-mode 的第一個(gè)作用就是定義取舍規(guī)則。常見的策略包括滑動(dòng)窗口只保留最近 N 輪、摘要壓縮把舊對(duì)話總結(jié)成一段話、關(guān)鍵信息抽取只保留實(shí)體、意圖、槽位、分層保留近期全量 遠(yuǎn)期摘要等。每種策略對(duì)應(yīng)一種 mode適用場(chǎng)景不同。2.2 困境二不同任務(wù)對(duì)上下文的敏感度差異巨大同一個(gè)系統(tǒng)里不同請(qǐng)求對(duì)上下文的需求可能完全相反。我拿一個(gè)實(shí)際項(xiàng)目舉例那是一個(gè)法律咨詢助手用戶會(huì)先描述案情然后連續(xù)追問細(xì)節(jié)。對(duì)于“幫我總結(jié)一下剛才說的案情”這類請(qǐng)求需要完整的歷史但對(duì)于“勞動(dòng)合同法第幾條規(guī)定了試用期”這種事實(shí)性問題歷史上下文幾乎沒用反而可能干擾模型。如果系統(tǒng)只有一種上下文處理方式就會(huì)出現(xiàn)兩難全量保留則事實(shí)性問題變慢變貴激進(jìn)截?cái)鄤t總結(jié)類請(qǐng)求丟信息。context-mode 的價(jià)值就在于讓“上下文策略”變成可切換的配置根據(jù)請(qǐng)求類型、用戶等級(jí)、會(huì)話階段動(dòng)態(tài)選擇。這就像開車時(shí)的駕駛模式——市區(qū)用經(jīng)濟(jì)模式高速用運(yùn)動(dòng)模式?jīng)]有一種模式通吃所有路況。2.3 困境三上下文里混著“噪聲”和“信號(hào)”原始上下文往往很臟。用戶可能發(fā)了一堆“嗯”“好的”“稍等”中間夾雜著真正重要的需求描述系統(tǒng)日志里混著無關(guān)的調(diào)試信息多輪工具調(diào)用產(chǎn)生的中間結(jié)果大部分是一次性的。如果不加處理直接使用模型會(huì)被噪聲帶偏。我遇到過最典型的情況用戶在和機(jī)器人聊了二十輪之后突然問“那這個(gè)多少錢”。如果上下文里最近幾輪都在聊別的產(chǎn)品模型很可能答錯(cuò)價(jià)格。這時(shí)候需要的 context-mode 是**“按相關(guān)性重排 時(shí)間衰減”**——不是簡(jiǎn)單取最近幾條而是根據(jù)當(dāng)前 query 去檢索歷史中語義相關(guān)的片段再結(jié)合時(shí)間新鮮度加權(quán)。這已經(jīng)接近 RAG 的思路了但作用域是會(huì)話內(nèi)部而非外部知識(shí)庫。3. 拆解 context-mode 的核心維度一張?jiān)O(shè)計(jì)決策表要設(shè)計(jì)一套 context-mode 機(jī)制我習(xí)慣從四個(gè)維度去思考。下面這張表是我在多個(gè)項(xiàng)目里反復(fù)用到的決策框架你可以對(duì)照自己的場(chǎng)景填一遍基本就能確定需要哪些 mode。維度關(guān)鍵問題常見選項(xiàng)適用場(chǎng)景保留策略保留哪些上下文全量 / 滑動(dòng)窗口 / 摘要 / 檢索式 / 分層全量適合短會(huì)話檢索式適合長(zhǎng)會(huì)話組織方式上下文怎么排列時(shí)間正序 / 時(shí)間倒序 / 相關(guān)性排序 / 結(jié)構(gòu)化分區(qū)倒序利于近期優(yōu)先分區(qū)利于多類型信息壓縮手段如何減少 token截?cái)?/ 摘要 / 實(shí)體抽取 / 向量化摘要保語義抽取保精確切換觸發(fā)何時(shí)換 mode輪次閾值 / token 閾值 / 意圖識(shí)別 / 手動(dòng)指定意圖識(shí)別最智能但成本高3.1 保留策略從“全量”到“檢索式”的連續(xù)譜全量保留是最簡(jiǎn)單的 mode適合會(huì)話輪次少比如 5 輪以內(nèi)、上下文總量可控的場(chǎng)景。它的優(yōu)點(diǎn)是零信息損失缺點(diǎn)是成本隨輪次線性增長(zhǎng)。我一般把它作為默認(rèn) mode但設(shè)置一個(gè) token 閾值超過就自動(dòng)降級(jí)。滑動(dòng)窗口是保留最近 N 輪或 N 個(gè) token。這里有個(gè)容易踩的坑按輪次截?cái)嗪桶?token 截?cái)嘈Ч顒e很大。用戶一輪可能只發(fā)“好的”兩個(gè)字也可能發(fā)一大段案情描述。按輪次截?cái)鄷?huì)導(dǎo)致 token 數(shù)劇烈波動(dòng)按 token 截?cái)喔€(wěn)定但可能把一輪對(duì)話從中間切斷。我的做法是按 token 截?cái)嗟ＷC不切斷單條消息從最舊的消息開始整條丟棄。摘要壓縮是把舊上下文用模型總結(jié)成一段話。這里的關(guān)鍵是摘要的粒度和更新頻率。我試過每 5 輪做一次摘要結(jié)果發(fā)現(xiàn)摘要本身也要消耗 token 和時(shí)間而且多次摘要會(huì)累積誤差。后來改成“當(dāng)上下文超過閾值時(shí)把最舊的一半消息摘要成一段”效果更穩(wěn)。摘要 mode 適合長(zhǎng)會(huì)話但要注意摘要可能丟失細(xì)節(jié)所以關(guān)鍵實(shí)體訂單號(hào)、金額、日期最好單獨(dú)抽取保留。檢索式是進(jìn)階方案把歷史消息向量化存入臨時(shí)索引每次請(qǐng)求時(shí)用當(dāng)前 query 檢索 top-k 相關(guān)片段。這個(gè) mode 最省 token但引入了檢索延遲和召回率問題。我在一個(gè)知識(shí)密集型客服項(xiàng)目里用過配合“最近 3 輪全量 檢索 top-5 歷史片段”的混合策略效果比純滑動(dòng)窗口好很多。3.2 組織方式順序會(huì)影響模型注意力同樣一組上下文排列順序不同模型的表現(xiàn)可能差很多。我做過對(duì)比實(shí)驗(yàn)把關(guān)鍵信息放在上下文開頭、中間、結(jié)尾三個(gè)位置模型對(duì)結(jié)尾位置的召回率最高開頭次之中間最差——這就是所謂的“l(fā)ost in the middle”現(xiàn)象。所以我的經(jīng)驗(yàn)是把最重要的信息放在上下文的末尾靠近用戶當(dāng)前 query次要信息放開頭最不重要的放中間。如果是多類型信息系統(tǒng)指令、歷史對(duì)話、檢索結(jié)果、當(dāng)前問題用明確的分隔符或結(jié)構(gòu)化標(biāo)簽分區(qū)比如用 XML 標(biāo)簽包裹不同區(qū)塊模型對(duì)結(jié)構(gòu)的敏感度比純文本高。3.3 壓縮手段摘要和抽取要配合使用摘要擅長(zhǎng)保留“語義走向”比如“用戶之前咨詢過退貨政策表示對(duì)運(yùn)費(fèi)不滿”。抽取擅長(zhǎng)保留“精確事實(shí)”比如訂單號(hào)ORD-2024-8871、金額￥299。兩者不是替代關(guān)系而是互補(bǔ)。我的做法是摘要用于對(duì)話脈絡(luò)抽取用于關(guān)鍵實(shí)體兩者拼在一起作為壓縮后的上下文。這里有個(gè)實(shí)操細(xì)節(jié)抽取實(shí)體時(shí)不要只抽一次就完事因?yàn)閷?shí)體可能在后文被修正。比如用戶先說“我要退 A 商品”后來說“算了改成 B 商品”。如果只保留第一次抽取的 A就會(huì)出錯(cuò)。所以抽取邏輯要支持覆蓋更新以最后一次出現(xiàn)的值為準(zhǔn)。3.4 切換觸發(fā)什么時(shí)候該換 mode手動(dòng)指定 mode 最可控但用戶體驗(yàn)差。自動(dòng)切換需要觸發(fā)條件常見的有輪次閾值超過 10 輪切換到摘要 modetoken 閾值上下文超過模型窗口的 60% 時(shí)觸發(fā)壓縮意圖識(shí)別檢測(cè)到“總結(jié)”“回顧”類意圖時(shí)切回全量檢測(cè)到事實(shí)性問題時(shí)切到精簡(jiǎn) mode成本預(yù)算按用戶等級(jí)或請(qǐng)求優(yōu)先級(jí)動(dòng)態(tài)調(diào)整我傾向于組合觸發(fā)token 閾值作為兜底防止超限意圖識(shí)別作為優(yōu)化提升體驗(yàn)。純靠意圖識(shí)別風(fēng)險(xiǎn)大因?yàn)橐鈭D分類本身可能出錯(cuò)一旦把需要全量的請(qǐng)求誤判為精簡(jiǎn)用戶會(huì)明顯感到“機(jī)器人失憶了”。4. 落地實(shí)現(xiàn)一個(gè)可運(yùn)行的 context-mode 管理器光講概念不夠我把自己項(xiàng)目里用的一套簡(jiǎn)化實(shí)現(xiàn)拆出來講。這套代碼用 Python 寫核心是一個(gè)ContextManager類支持多種 mode 切換。你可以直接拿去改。4.1 數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)消息、會(huì)話、模式配置先定義基礎(chǔ)結(jié)構(gòu)。每條消息包含角色、內(nèi)容、時(shí)間戳、token 數(shù)、以及一個(gè)可選的pinned標(biāo)記用于標(biāo)記不可丟棄的關(guān)鍵消息。from dataclasses import dataclass, field from typing import List, Optional import time dataclass class Message: role: str # user / assistant / system / tool content: str timestamp: float field(default_factorytime.time) tokens: int 0 pinned: bool False # 關(guān)鍵消息壓縮時(shí)優(yōu)先保留 dataclass class ContextConfig: mode: str sliding # full / sliding / summary / retrieval / hybrid max_tokens: int 4000 # 上下文 token 上限 window_size: int 10 # 滑動(dòng)窗口保留輪次 summary_threshold: int 3000 # 觸發(fā)摘要的 token 閾值 retrieval_top_k: int 5 # 檢索式保留片段數(shù)這里pinned字段很關(guān)鍵。我在實(shí)際項(xiàng)目里發(fā)現(xiàn)有些消息絕對(duì)不能丟比如用戶明確說“記住我的訂單號(hào)是 XXX”或者系統(tǒng)注入的租戶配置。給這些消息打上 pinned 標(biāo)記任何壓縮策略都要優(yōu)先保留它們。4.2 滑動(dòng)窗口 mode 的實(shí)現(xiàn)與邊界處理滑動(dòng)窗口看似簡(jiǎn)單但邊界處理有講究。我的實(shí)現(xiàn)邏輯是從最新消息往前累加 token直到接近上限然后整條保留不切斷消息。def sliding_window(messages: List[Message], max_tokens: int) - List[Message]: selected [] total 0 # 先保留所有 pinned 消息 for msg in messages: if msg.pinned: selected.append(msg) total msg.tokens # 從最新往前加非 pinned 消息 for msg in reversed(messages): if msg.pinned: continue if total msg.tokens max_tokens: break selected.append(msg) total msg.tokens # 恢復(fù)時(shí)間正序 selected.sort(keylambda m: m.timestamp) return selected注意這里有個(gè)細(xì)節(jié)pinned 消息可能很多如果 pinned 本身就超限了怎么辦我的做法是pinned 優(yōu)先超限時(shí)對(duì) pinned 內(nèi)部再做一次摘要而不是直接丟棄。因?yàn)?pinned 之所以被標(biāo)記就是因?yàn)樗匾苯觼G會(huì)出大問題。4.3 摘要 mode什么時(shí)候摘要、摘要什么、怎么拼接摘要 mode 的觸發(fā)時(shí)機(jī)我前面提過是 token 超過閾值。但摘要本身也有講究。我的實(shí)現(xiàn)是把最舊的一半非 pinned 消息交給模型摘要摘要結(jié)果作為一條 system 消息插入上下文開頭。def summarize_old_messages(messages: List[Message], llm_client) - str: # 取最舊的一半非 pinned 消息 non_pinned [m for m in messages if not m.pinned] half len(non_pinned) // 2 to_summarize non_pinned[:half] if not to_summarize: return text \n.join(f{m.role}: {m.content} for m in to_summarize) prompt f請(qǐng)用簡(jiǎn)潔的中文總結(jié)以下對(duì)話的關(guān)鍵信息保留實(shí)體、數(shù)字和結(jié)論\n{text} return llm_client.generate(prompt)這里有個(gè)坑摘要 prompt 必須明確要求保留實(shí)體和數(shù)字否則模型會(huì)寫成“用戶咨詢了退貨相關(guān)問題”這種沒用的概括。我試過不加這句結(jié)果摘要里訂單號(hào)全丟了后面用戶問“我那個(gè)訂單怎么樣了”機(jī)器人完全接不上。拼接時(shí)摘要消息放在最前面然后是 pinned 消息最后是最近的全量消息。這樣模型先看到背景摘要再看到關(guān)鍵事實(shí)最后看到當(dāng)前對(duì)話層次清晰。4.4 檢索式 mode會(huì)話內(nèi)向量檢索的輕量方案檢索式 mode 適合超長(zhǎng)會(huì)話。完整方案需要向量數(shù)據(jù)庫但會(huì)話內(nèi)檢索其實(shí)可以用輕量方案用 TF-IDF 或 BM25 做關(guān)鍵詞檢索不一定要上 embedding。因?yàn)闀?huì)話內(nèi)消息通常有大量詞匯重疊用戶會(huì)重復(fù)提到同一產(chǎn)品名、訂單號(hào)關(guān)鍵詞檢索的召回率已經(jīng)夠用而且零額外成本。from rank_bm25 import BM25Okapi def retrieval_mode(messages: List[Message], query: str, top_k: int) - List[Message]: corpus [m.content for m in messages] tokenized [doc.split() for doc in corpus] bm25 BM25Okapi(tokenized) scores bm25.get_scores(query.split()) # 取 top_k同時(shí)保證最近 3 輪一定在 top_indices sorted(range(len(scores)), keylambda i: scores[i], reverseTrue)[:top_k] recent list(range(max(0, len(messages)-3), len(messages))) final_indices sorted(set(top_indices) | set(recent)) return [messages[i] for i in final_indices]這個(gè)方案我在一個(gè)日均 5 萬次請(qǐng)求的項(xiàng)目里跑過檢索延遲在 10ms 以內(nèi)比 embedding 方案快一個(gè)數(shù)量級(jí)。當(dāng)然如果會(huì)話里語義相似但用詞不同的情況多還是得上 embedding。選型要看具體數(shù)據(jù)分布。4.5 混合 mode我的默認(rèn)推薦配置純?nèi)魏我环N mode 都有短板我最終在生產(chǎn)環(huán)境用的是混合 mode最近 3 輪全量 pinned 消息 檢索 top-5 歷史片段 超長(zhǎng)時(shí)追加摘要。這個(gè)組合覆蓋了“近期精確”“關(guān)鍵事實(shí)”“相關(guān)歷史”“遠(yuǎn)期脈絡(luò)”四個(gè)層次。配置上我把max_tokens設(shè)為模型窗口的 50%留一半給模型輸出和系統(tǒng)指令。這個(gè)比例是我多次壓測(cè)后定的超過 60% 時(shí)延遲明顯上升低于 40% 時(shí)信息不夠用。當(dāng)然不同模型不一樣你需要自己測(cè)。5. 踩坑記錄那些讓我加班到凌晨的上下文問題5.1 坑一摘要的“滾雪球”誤差早期我做摘要 mode 時(shí)是每次超限就把全部歷史摘要一次然后新消息繼續(xù)追加下次超限再把“舊摘要新消息”一起摘要。結(jié)果跑了十幾輪之后摘要變得面目全非——最初的訂單號(hào)、金額全沒了只?！坝脩糇稍兞耸酆髥栴}”這種廢話。根因摘要是不可逆的有損壓縮多次摘要會(huì)累積誤差就像反復(fù)復(fù)印同一張紙?jiān)接≡侥：?。修?fù)方案改成“分層摘要”——原始消息保留在存儲(chǔ)層不刪摘要只用于構(gòu)建上下文。每次摘要時(shí)從原始消息重新生成而不是在舊摘要上再摘要。這樣雖然多存了數(shù)據(jù)但摘要質(zhì)量穩(wěn)定。存儲(chǔ)成本遠(yuǎn)低于模型調(diào)用成本這筆賬要算清楚。5.2 坑二pinned 消息的“僵尸化”有次用戶反饋機(jī)器人“記不住事”。排查發(fā)現(xiàn)用戶早期說過的訂單號(hào)被標(biāo)記為 pinned一直保留在上下文里。但后來用戶改了訂單新訂單號(hào)沒有被標(biāo)記 pinned結(jié)果舊訂單號(hào)一直占著位置新訂單號(hào)反而被滑動(dòng)窗口擠掉了。根因pinned 標(biāo)記是靜態(tài)的沒有隨信息更新而失效。修復(fù)方案引入“實(shí)體版本”概念。同一類實(shí)體如訂單號(hào)只保留最新版本舊版本自動(dòng)取消 pinned。實(shí)現(xiàn)上可以用一個(gè)簡(jiǎn)單的實(shí)體槽位表每次抽取到新值就覆蓋舊值并更新對(duì)應(yīng)消息的 pinned 狀態(tài)。5.3 坑三多租戶場(chǎng)景下的上下文串?dāng)_在一個(gè) SaaS 項(xiàng)目里多個(gè)租戶共用同一套服務(wù)。有次出現(xiàn)嚴(yán)重 bugA 租戶的用戶看到了 B 租戶的上下文片段。排查發(fā)現(xiàn)是緩存 key 設(shè)計(jì)有問題只用了 session_id 做 key而 session_id 在不同租戶間可能重復(fù)。根因上下文隔離維度不足。修復(fù)方案緩存 key 必須包含租戶 ID 用戶 ID 會(huì)話 ID 三級(jí)。而且上下文管理器初始化時(shí)就要綁定租戶不能等到寫入時(shí)才檢查。這個(gè)坑讓我意識(shí)到context-mode 不只是“保留多少”的問題更是“隔離誰和誰”的問題。多租戶場(chǎng)景下隔離優(yōu)先級(jí)高于一切壓縮策略。5.4 坑四工具調(diào)用結(jié)果的“一次性污染”Agent 應(yīng)用里工具調(diào)用會(huì)產(chǎn)生大量中間結(jié)果比如搜索返回的十條網(wǎng)頁摘要、數(shù)據(jù)庫查詢的原始行。這些結(jié)果對(duì)當(dāng)前輪有用但下一輪基本是噪聲。我早期沒處理導(dǎo)致上下文迅速膨脹而且模型經(jīng)常被上一輪的搜索結(jié)果帶偏。修復(fù)方案給工具結(jié)果設(shè)置TTL生存輪數(shù)默認(rèn)只保留 1 輪除非被顯式引用。實(shí)現(xiàn)上給消息加一個(gè)expire_after字段構(gòu)建上下文時(shí)過濾掉已過期的工具消息。這個(gè)改動(dòng)讓平均上下文 token 數(shù)下降了 40%響應(yīng)質(zhì)量反而提升。6. 效果驗(yàn)證怎么知道你的 context-mode 選對(duì)了6.1 三個(gè)必須監(jiān)控的指標(biāo)選 mode 不能憑感覺要有數(shù)據(jù)。我一般盯三個(gè)指標(biāo)上下文 token 均值與 P95均值看成本P95 看極端情況。如果 P95 遠(yuǎn)超窗口說明壓縮策略沒兜住。關(guān)鍵信息召回率構(gòu)造一批測(cè)試用例每個(gè)用例有一個(gè)“必須被模型看到”的關(guān)鍵信息訂單號(hào)、日期、金額檢查最終上下文里是否包含。這個(gè)指標(biāo)直接反映壓縮是否過度。端到端響應(yīng)延遲上下文處理本身有開銷摘要、檢索要單獨(dú)計(jì)時(shí)不能混在模型推理里。6.2 一個(gè)簡(jiǎn)單的 A/B 測(cè)試框架我通常用離線回放做 A/B把歷史真實(shí)會(huì)話拿出來用不同 mode 重新構(gòu)建上下文讓模型生成回復(fù)然后人工或自動(dòng)評(píng)估質(zhì)量。評(píng)估維度包括事實(shí)準(zhǔn)確性、上下文連貫性、指令遵循度。跑幾百條就能看出明顯差異。這里有個(gè)經(jīng)驗(yàn)不要只看平均分要看方差。有些 mode 平均分不差但方差大意味著不穩(wěn)定線上會(huì)出各種詭異問題。我寧愿選平均分略低但方差小的 mode。6.3 線上灰度與回滾策略新 mode 上線一定要灰度。我的做法是按用戶 ID 哈希分流先放 5% 流量觀察一周?；貪L開關(guān)要能秒級(jí)生效而且回滾后要能恢復(fù)到舊 mode 的上下文狀態(tài)——這就要求上下文存儲(chǔ)層和 mode 邏輯解耦mode 只是“視圖”底層消息始終完整保存。7. 不同場(chǎng)景下的 mode 選型建議7.1 客服機(jī)器人混合 mode 強(qiáng) pinned客服場(chǎng)景的特點(diǎn)是會(huì)話中等長(zhǎng)度10-30 輪關(guān)鍵實(shí)體多訂單、產(chǎn)品、金額且用戶經(jīng)?；厮?。我推薦混合 modepinned 策略要激進(jìn)——所有實(shí)體抽取結(jié)果都標(biāo)記 pinned并做版本管理。摘要用于對(duì)話脈絡(luò)檢索用于歷史回溯。7.2 代碼助手滑動(dòng)窗口 文件上下文分區(qū)代碼助手的上下文分兩部分對(duì)話歷史和當(dāng)前文件內(nèi)容。文件內(nèi)容通常很大但結(jié)構(gòu)清晰適合用分區(qū)方式組織——把函數(shù)簽名、相關(guān)代碼塊、報(bào)錯(cuò)信息分區(qū)放置。對(duì)話歷史用滑動(dòng)窗口即可因?yàn)榇a問題通常聚焦在當(dāng)前幾輪。這里有個(gè)技巧把光標(biāo)位置附近的代碼放在上下文末尾模型對(duì)末尾注意力最強(qiáng)。7.3 長(zhǎng)文檔問答檢索式為主全量為輔長(zhǎng)文檔問答的上下文主要是文檔片段不是對(duì)話歷史。這時(shí)候 context-mode 的重點(diǎn)是片段檢索和重排。我的做法是先用向量檢索召回 top-20再用 cross-encoder 重排取 top-5最后按文檔順序排列保持邏輯連貫。對(duì)話歷史只保留最近 2 輪因?yàn)槲臋n問答通常是獨(dú)立問題。7.4 多 Agent 協(xié)作結(jié)構(gòu)化上下文 角色隔離多 Agent 場(chǎng)景下每個(gè) Agent 只需要看到與自己角色相關(guān)的上下文。比如規(guī)劃 Agent 需要看全局目標(biāo)執(zhí)行 Agent 只需要看當(dāng)前子任務(wù)。這時(shí)候 context-mode 的核心是按角色過濾 結(jié)構(gòu)化傳遞。我一般用 JSON 結(jié)構(gòu)定義上下文每個(gè)字段標(biāo)注可見角色構(gòu)建時(shí)按角色裁剪。8. 我個(gè)人的幾條實(shí)操心得第一上下文處理邏輯要和業(yè)務(wù)邏輯解耦。我見過太多項(xiàng)目把壓縮邏輯寫死在業(yè)務(wù)代碼里改一個(gè)策略要?jiǎng)邮畮讉€(gè)文件。正確的做法是抽象出 ContextManager業(yè)務(wù)層只負(fù)責(zé)往里面塞消息取的時(shí)候指定 mode。第二永遠(yuǎn)保留原始消息。壓縮后的上下文是給模型看的但存儲(chǔ)層要留全量。排查問題時(shí)原始消息是唯一真相。我吃過虧——有次線上出問題結(jié)果發(fā)現(xiàn)壓縮后的上下文把關(guān)鍵信息丟了但原始消息也沒存根本沒法復(fù)現(xiàn)。第三token 計(jì)數(shù)不要用估算。不同模型的 tokenizer 不一樣估算誤差可能到 20%。我早期用字符數(shù)除以 4 估算結(jié)果中文場(chǎng)景嚴(yán)重低估導(dǎo)致頻繁超限。后來統(tǒng)一用對(duì)應(yīng)模型的 tokenizer 精確計(jì)數(shù)雖然慢一點(diǎn)但穩(wěn)定。第四給上下文加“新鮮度權(quán)重”。同樣相關(guān)的兩條歷史消息一條是 5 分鐘前的一條是 3 天前的顯然前者更重要。我在檢索式 mode 里加了時(shí)間衰減因子score 相關(guān)性 × exp(-Δt / τ)τ 取 1 小時(shí)左右。這個(gè)改動(dòng)讓“最近提過但語義匹配度略低”的信息更容易被召回。第五定期 review 上下文內(nèi)容。我每個(gè)月會(huì)抽樣看一批線上真實(shí)上下文經(jīng)常發(fā)現(xiàn)意外情況比如某個(gè)工具返回了超長(zhǎng) JSON、某個(gè)用戶發(fā)了大量重復(fù)內(nèi)容、某個(gè)系統(tǒng)消息被反復(fù)注入。這些問題不看原始數(shù)據(jù)是發(fā)現(xiàn)不了的。Review 之后針對(duì)性加過濾規(guī)則比盲目調(diào)參有效得多。context-mode 這個(gè)東西說到底是在資源約束下做信息取舍的工程藝術(shù)。沒有銀彈只有對(duì)場(chǎng)景的深刻理解和對(duì)數(shù)據(jù)的持續(xù)觀察。我上面給的配置和代碼都是起點(diǎn)真正適合你業(yè)務(wù)的 mode得自己跑數(shù)據(jù)、看指標(biāo)、迭代出來。