1. 一個(gè)讓我半夜還在改配置的“小開關(guān)”context-mode到底是什么先講個(gè)真事。前陣子我接手了一個(gè)多輪客服問答項(xiàng)目模型用的是市面上常見的大語(yǔ)言模型需求也很樸素用戶連續(xù)問七八個(gè)問題機(jī)器人要能記得前面說過什么不能答著答著“失憶”。我一開始想得簡(jiǎn)單——多輪對(duì)話嘛把歷史消息全帶上不就行了結(jié)果上線第三天就出問題了用戶在第12輪追問時(shí)模型突然把之前確認(rèn)過的收貨地址回答錯(cuò)了再過幾輪它甚至開始順著用戶隨口一句“那你覺得呢”編出完全不存在的東西。我當(dāng)時(shí)對(duì)著日志里一大串輸入記錄發(fā)懵代碼層面確實(shí)把每輪對(duì)話都傳進(jìn)去了為什么模型還是“忘了”后來我才意識(shí)到問題不是“傳沒傳”而是“怎么傳”。這里涉及一個(gè)很多 AI 應(yīng)用開發(fā)者容易忽略的概念context-mode上下文模式。所謂 context-mode指的是 AI 應(yīng)用在處理輸入時(shí)決定“哪些內(nèi)容能進(jìn)入模型可見上下文、以什么形式進(jìn)入、保留多少歷史”的一套工作方式。說白了它就是控制模型“視野”的開關(guān)和策略。不同框架、不同工具里它長(zhǎng)得很不一樣——有的叫上下文長(zhǎng)度設(shè)置有的叫記憶策略有的叫上下文預(yù)算管理但底層都是同一件事在有限的上下文窗口里把最該讓模型看到的內(nèi)容放進(jìn)去把不重要的內(nèi)容過濾掉或壓縮掉。這篇文章我會(huì)從一個(gè)實(shí)際開發(fā)者的視角把 context-mode 的前因后果講透。包括它解決什么問題、底層 token 預(yù)算怎么算、在真實(shí)項(xiàng)目里怎么配置、以及我踩過的三個(gè)坑和完整排查過程。無(wú)論你是正在做大模型應(yīng)用、還是日常用 AI 編程助手、又或者只是好奇“為什么有時(shí)候 AI 聊天會(huì)突然犯糊涂”這篇文章都能給你一個(gè)相對(duì)完整的答案。我先說結(jié)論絕大多數(shù)上下文“失效”問題都不是模型變笨了而是應(yīng)用層對(duì) context-mode 的使用方式有問題。模型還是那個(gè)模型但你喂給它的東西變了輸出自然飄。2. 別被“百萬(wàn)上下文窗口”的宣傳帶偏context-mode背后的token預(yù)算邏輯2.1 上下文窗口是“上限”不是“默認(rèn)值”現(xiàn)在很多模型動(dòng)不動(dòng)就標(biāo)榜 128K、200K 甚至 1M 的上下文窗口聽起來好像可以無(wú)限堆歷史。但這里有個(gè)特別容易誤導(dǎo)人的地方上下文窗口只是模型最多能接受多少 token 的物理上限不代表你把它當(dāng)垃圾桶往里扔什么都行。先說 token 的計(jì)算。常規(guī)模型里1 個(gè) token 大約是 0.7 個(gè)英文字單詞中文大約 1 到 1.5 個(gè)漢字。一次請(qǐng)求里系統(tǒng)提示詞、歷史對(duì)話、檢索到的文檔片段、用戶當(dāng)前輸入、工具返回結(jié)果所有這些加起來都會(huì)被計(jì)算成輸入 token。模型在生成回復(fù)時(shí)也會(huì)占用輸出 token。也就是說你看到的一次請(qǐng)求真實(shí)消耗是“輸入 token 輸出 token”而不是屏幕里那幾句話的體量。我在那個(gè)客服項(xiàng)目里做過一次實(shí)測(cè)單輪對(duì)話平均約 2000 token7 輪之后只是歷史消息就已經(jīng) 1.4 萬(wàn) token再加上我們注入的客服規(guī)則、訂單列表檢索結(jié)果一次請(qǐng)求的輸入 token 直接沖破 2 萬(wàn)。這個(gè)量級(jí)本身不致命但你會(huì)發(fā)現(xiàn)兩件事第一響應(yīng)延遲肉眼可見地變慢第二模型開始“挑食”——它會(huì)關(guān)注到上下文中間那段內(nèi)容而對(duì)開頭系統(tǒng)提示和靠近結(jié)尾的當(dāng)前問題把握不穩(wěn)。這就是我后來排查“為什么模型突然失憶”的第一條線索。2.2 注意力機(jī)制下的“長(zhǎng)上下文幻覺”稍微說點(diǎn)原理但我會(huì)盡量用大白話。大模型讀取長(zhǎng)文本時(shí)不是逐字閱讀而是通過自注意力機(jī)制計(jì)算每個(gè)位置和所有其他位置的相關(guān)性。這個(gè)機(jī)制決定了模型理論上能看到全部?jī)?nèi)容但它在生成時(shí)對(duì)每個(gè)詞分配的“注意力權(quán)重”是有限的。當(dāng)上下文塞得太滿、噪聲太多模型很容易把注意力錯(cuò)誤地分配到無(wú)關(guān)內(nèi)容上。舉個(gè)例子你問模型“上次說的那個(gè)藍(lán)色保溫杯多少錢”如果歷史記錄里有大量“您購(gòu)買的XX商品已發(fā)貨”“親給您帶來不好的體驗(yàn)非常抱歉”這類客服用語(yǔ)模型可能會(huì)把注意力放在道歉話術(shù)上遺忘掉真正包含價(jià)格的壓低段落。這就是為什么我在后面會(huì)說context-mode 的核心工作不是“多塞”而是“篩選聚焦”。更實(shí)在一點(diǎn)說上下文越長(zhǎng)模型對(duì)中段內(nèi)容的記憶越模糊。我自己的經(jīng)驗(yàn)是超過 8K token 之后很多輕量級(jí)任務(wù)沒必要堆那么長(zhǎng)超過 20K 之后如果沒有清晰的上下文結(jié)構(gòu)設(shè)計(jì)質(zhì)量下滑幾乎是必然的。上下文窗口是給極端場(chǎng)景兜底的不是給普通場(chǎng)景揮霍的。2.3 context-mode 的三種常見實(shí)現(xiàn)策略既然不能無(wú)腦塞那常見應(yīng)用是怎么做的目前主流有三種 context-mode 策略我整理了一個(gè)對(duì)比策略做法優(yōu)點(diǎn)缺點(diǎn)適用場(chǎng)景全量模式把所有歷史對(duì)話、檢索結(jié)果、工具輸出全部拼進(jìn)上下文信息無(wú)損實(shí)現(xiàn)最簡(jiǎn)單token 消耗大響應(yīng)變慢中段信息容易被稀釋短對(duì)話、單輪復(fù)雜任務(wù)截?cái)嗄Ｊ紽IFO只保留最近 N 輪或最近 N 個(gè) token超出部分丟棄實(shí)現(xiàn)簡(jiǎn)單成本可控早期關(guān)鍵信息永久丟失模型會(huì)“真失憶”閑聊型多輪對(duì)話壓縮模式把舊內(nèi)容先交給模型或算法做摘要再以摘要形式注入上下文保留核心信息的同時(shí)控制長(zhǎng)度摘要過程有信息損失還要增加一次摘要調(diào)用長(zhǎng)文檔問答、長(zhǎng)會(huì)話我一開始用的就是全量模式因?yàn)樽詈?jiǎn)單。但等到會(huì)話輪數(shù)一多就發(fā)現(xiàn) token 成本漲得厲害響應(yīng)速度也慢慢滑向不可接受。后來?yè)Q了截?cái)嗄Ｊ接职l(fā)現(xiàn)用戶在第一輪說過的禁忌詞比如“我不吃辣”在第六輪被模型徹底忘光了還在推薦辣菜。最后我們改成了壓縮模式——每 3 輪對(duì)話結(jié)束后讓一個(gè)較輕量的模型把關(guān)鍵決策、用戶偏好、已完成事項(xiàng)提煉成摘要注入后續(xù)上下文。這里的關(guān)鍵點(diǎn)選擇哪種 context-mode本質(zhì)上是在“信息完整度”和“注意力聚焦度”之間做權(quán)衡。沒有哪種模式絕對(duì)正確只有適不適合當(dāng)前業(yè)務(wù)。3. 實(shí)戰(zhàn)配置把 context-mode 變成可調(diào)參數(shù)而不是黑盒3.1 先弄清楚你的應(yīng)用里有哪些“隱性上下文消費(fèi)者”很多人配置上下文只盯著歷史對(duì)話這其實(shí)漏掉了大頭。一次大模型請(qǐng)求中上下文預(yù)算被四類東西同時(shí)瓜分系統(tǒng)提示詞包括角色設(shè)定、業(yè)務(wù)規(guī)則、輸出格式要求。這部分看似不長(zhǎng)但如果寫得啰嗦幾百上千 token 就沒了。歷史對(duì)話多輪交互積累的內(nèi)容。動(dòng)態(tài)檢索結(jié)果RAG 系統(tǒng)召回的相關(guān)文檔片段。工具輸出調(diào)用 API、查詢數(shù)據(jù)庫(kù)、執(zhí)行代碼后返回的結(jié)果。我做客服項(xiàng)目時(shí)測(cè)過一次系統(tǒng)提示詞寫了 800 token工具輸出的訂單列表 600 token動(dòng)態(tài)檢索到的 FAQ 1200 token結(jié)果歷史對(duì)話還沒算呢預(yù)算已經(jīng)快用掉三分之一。所以配置 context-mode 的第一步不是調(diào)參數(shù)是盤點(diǎn)雞鴨——搞明白一次請(qǐng)求里有多少內(nèi)容在和你爭(zhēng)搶上下文窗口。3.2 一個(gè)可復(fù)用的配置思路偽代碼解讀以一個(gè)典型的 Agent 應(yīng)用為例我最后給出的配置結(jié)構(gòu)長(zhǎng)這樣# 偽代碼示例context-mode 配置 context_config { mode: hybrid, # 混合模式截?cái)? 壓縮 max_total_token: 24000, # 硬上限留 8000 token 給輸出 system_prompt: { priority: high, # 系統(tǒng)提示詞永遠(yuǎn)不被截?cái)?max_token: 1500 }, history: { strategy: rolling, # 滾動(dòng)窗口 max_rounds: 6, # 保留最近 6 輪 summary_after: 6, # 超過后觸發(fā)壓縮 summary_model: light # 用輕量模型做摘要 }, retrieval: { strategy: rerank, # 先召回再重排序只放精排前 3 條 max_chunk: 3, max_token: 3000 }, tools: { max_output_token: 1000, # 工具輸出截?cái)?truncate: tail # 保留核心結(jié)論截?cái)嗝骷?xì) } }這里面每一步都不是拍腦袋定的。我拆開解釋一下max_total_token 設(shè) 24000——這是基于我們實(shí)際調(diào)用模型的上限做的安全墊給輸出留足 8000 token避免生成到一半被硬截?cái)?。如果模型窗口?64K也別真用到 60K成本高且延遲大。history 里的 rolling summary——這是上面說的壓縮模式的具體化。最近 6 輪用原始內(nèi)容保證“當(dāng)前正在進(jìn)行的對(duì)話”有完整語(yǔ)境第 7 輪起觸發(fā)壓縮把更早的對(duì)話提煉成要點(diǎn)。這樣做的好處是近 6 輪的細(xì)節(jié)完整而早期信息以摘要形式存在既不會(huì)完全丟也不占用大量預(yù)算。retrieval 里的 rerank——很多 RAG 應(yīng)用回回把 top5、top10 結(jié)果全塞進(jìn)去。實(shí)測(cè)下來文檔檢索質(zhì)量參差不齊放進(jìn)去 5 條可能有 2 條是干擾項(xiàng)。后來我們改成先召回 10 條再用一個(gè)輕量重排序篩出最相關(guān)的 3 條上下文里的噪聲一下子少了很多。tools 的 tail 截?cái)唷ぞ叻祷氐膬?nèi)容往往很長(zhǎng)比如訂單明細(xì)一口氣列出 30 條。模型實(shí)際只需要知道匯總金額和狀態(tài)所以我把它截?cái)嘀槐Ａ艚Y(jié)尾的匯總部分。這里有個(gè)細(xì)節(jié)有些結(jié)構(gòu)化的 JSON 中間部分才是核心所以截?cái)喾绞讲荒芤桓哦撘瓤磾?shù)據(jù)再定策略。3.3 實(shí)際配完之后的一個(gè)意外收獲按這個(gè)配置改造之后客服項(xiàng)目的 token 成本大概降了 40%但這還不是我最高興的。更明顯的改善是回復(fù)一致性用戶在第 8 輪問“剛才我改的地址收貨人叫什么”模型能準(zhǔn)確說出前面提到的新收貨人姓名這在之前全量模式下反而偶爾會(huì)卡殼。原因不復(fù)雜——全量模式下歷史太長(zhǎng)注意力被稀釋重要信息反而“淹沒”了壓縮模式把關(guān)鍵信息提煉成突出重點(diǎn)模型反而更容易命中。這里我想強(qiáng)調(diào)一個(gè)反直覺的結(jié)論限制上下文的長(zhǎng)度有時(shí)候比增加上下文的長(zhǎng)度更能提升模型表現(xiàn)。因?yàn)?context-mode 的本質(zhì)是幫助模型聚焦而不是幫模型記憶。記憶可以靠外部存儲(chǔ)聚焦才是上下文窗口內(nèi)該做的事。4. 三次把項(xiàng)目搞壞的 context-mode 誤用附完整排查鏈路配置思路講完了但說實(shí)話這些認(rèn)知都是我踩坑踩出來的。我把三次比較典型的翻車經(jīng)歷整理出來包括現(xiàn)象、排查過程和根因希望能幫你少走彎路。4.1 事故一歷史輪數(shù)無(wú)限堆token 爆了還“裝沒事”現(xiàn)象另一個(gè)項(xiàng)目里有個(gè)聊天機(jī)器人運(yùn)營(yíng)要求“必須記住用戶所有聊天記錄”。開發(fā)同學(xué)直接把全部歷史拼進(jìn) prompt每次請(qǐng)求的輸入 token 持續(xù)增長(zhǎng)。上線第一天沒事第三天開始部分請(qǐng)求直接報(bào)錯(cuò)——超出模型上下文上限程序崩潰。還有一部分請(qǐng)求雖然成功但響應(yīng)時(shí)間是原來的三倍。排查鏈路看錯(cuò)誤日志確認(rèn)報(bào)錯(cuò)是“maximum context length exceeded”。統(tǒng)計(jì)單請(qǐng)求 token 數(shù)量發(fā)現(xiàn)用戶聊得越多請(qǐng)求 token 線性增長(zhǎng)。臨時(shí)方案是改用更大的窗口模型但成本翻倍治標(biāo)不治本。在請(qǐng)求入?yún)⒗锎蛴?shí)際發(fā)送的 prompt 長(zhǎng)度確認(rèn)歷史對(duì)話沒有做任何截?cái)嗷驂嚎s邏輯。根因明確context-mode 直接落在了“無(wú)限全量模式”——不是沒有模式而是默認(rèn)把模式設(shè)成了“全部塞進(jìn)去”。修復(fù)改成“最近 20 輪 之前內(nèi)容滾動(dòng)摘要”的混合策略?？偨Y(jié)一輪初步對(duì)話生成 200 字摘要比原始幾千字省多了。4.2 事故二RAG 檢索結(jié)果全部塞入模型被無(wú)關(guān)內(nèi)容帶跑偏現(xiàn)象做一個(gè)企業(yè)知識(shí)庫(kù)問答正確率一直上不去。用戶問“年假規(guī)定”模型答非所問地聊起了“離職流程”——因?yàn)闄z索到的文檔里既有年假章節(jié)也有離職章節(jié)還把兩者混在一起講。更麻煩的是有時(shí)答案引用的文檔編號(hào)是錯(cuò)的看起來煞有介事實(shí)際內(nèi)容完全對(duì)不上。排查鏈路第一步先懷疑是檢索質(zhì)量問題打印召回結(jié)果發(fā)現(xiàn) top5 里相關(guān)度第一、第二的確實(shí)是年假內(nèi)容但第三到第五是模糊匹配到的其他制度。第二步看 prompt發(fā)現(xiàn)代碼里直接把 top5 原文全部拼接進(jìn)上下文沒有任何過濾。第三步人工喂同樣的檢索結(jié)果給模型復(fù)現(xiàn)出“答非所問”的現(xiàn)象把五條去掉兩條無(wú)關(guān)的模型回答立刻正常。根因確認(rèn)context-mode 的檢索注入層沒有做相關(guān)性門檻控制噪聲進(jìn)了上下文注意力被帶偏。修復(fù)檢索結(jié)果不做前五全塞改成先按相似度排序設(shè)置置信度閾值低于閾值直接丟棄高于閾值的再取前三條。這個(gè)改動(dòng)讓知識(shí)庫(kù)問答的準(zhǔn)確率從 61% 提到 84%提升非常顯著。4.3 事故三系統(tǒng)提示詞被擠到“不重要的位置”規(guī)則失效現(xiàn)象一個(gè)內(nèi)容生成工具里設(shè)定了嚴(yán)格的輸出格式要求必須 JSON字段名固定用了很多天一直正常。某天產(chǎn)品說要在上下文里增加用戶畫像數(shù)據(jù)結(jié)果改完之后模型開始偶爾輸出 Markdown 格式還帶亂碼文字字段名也變來變?nèi)?。代碼層面明明還在傳系統(tǒng)提示詞為什么規(guī)則失效了排查鏈路先檢查系統(tǒng)提示詞本身沒改過內(nèi)容沒問題。打印完整 prompt發(fā)現(xiàn)用戶畫像數(shù)據(jù)被放在系統(tǒng)提示詞和歷史對(duì)話之間長(zhǎng)度不小。懷疑是位置問題模型對(duì)開頭和結(jié)尾更敏感中間段內(nèi)容最容易“注意力偏弱”。系統(tǒng)提示詞雖然是開頭但緊接著進(jìn)來一大段結(jié)構(gòu)化用戶畫像數(shù)據(jù)干擾了后面的規(guī)則執(zhí)行。進(jìn)一步實(shí)驗(yàn)把系統(tǒng)提示詞復(fù)制一份放在用戶指令之后靠近結(jié)尾問題立刻消失。根因確認(rèn)context-mode 的上下文結(jié)構(gòu)中系統(tǒng)提示詞的“位置優(yōu)先級(jí)”沒有保證被后續(xù)插入的用戶畫像數(shù)據(jù)壓住了。修復(fù)在應(yīng)用層固定 prompt 結(jié)構(gòu)系統(tǒng)提示詞 → 用戶實(shí)時(shí)輸入 → 歷史對(duì)話 → 檢索內(nèi)容 → 工具輸出。同時(shí)給系統(tǒng)提示詞設(shè)置“永不截?cái)唷睒?biāo)記哪怕整體 token 超了也只壓縮其他部分。代碼上加的邏輯很簡(jiǎn)單就是保證系統(tǒng)提示詞始終處在開頭且長(zhǎng)度受控。4.4 從三次事故里提煉的通用排查清單如果你也遇到模型“突然變笨”“規(guī)則失效”“記憶丟失”我建議你按這個(gè)順序排查先看實(shí)際入?yún)衙看握?qǐng)求真正發(fā)給模型的 prompt 完整打印出來別只看業(yè)務(wù)層的傳參。檢查 token 分配系統(tǒng)提示詞、歷史、檢索、工具輸出各占多少有沒有某塊異常膨脹驗(yàn)證上下文位置把內(nèi)容塊換個(gè)位置測(cè)試看看是否受排列順序影響。逐層剝離對(duì)比分別單獨(dú)去掉歷史/檢索/工具輸出看模型表現(xiàn)恢復(fù)到什么程度從而定位“污染源”。測(cè)完再加確定某一塊是元兇后再加回來試一次確認(rèn)不是巧合。這套鏈路雖然樸素但非常管用。說白了context-mode 的問題九成都是 prompt 結(jié)構(gòu)問題而 prompt 結(jié)構(gòu)問題是可以通過打印和隔離實(shí)驗(yàn)復(fù)現(xiàn)的。5. 調(diào)優(yōu)流程與判斷指標(biāo)怎么知道你的 context-mode 配得好不好5.1 別只盯著“省 token”要看任務(wù)完成質(zhì)量配置 context-mode 很容易陷入一個(gè)誤區(qū)——為了省錢把上下文壓縮得過于激進(jìn)結(jié)果模型頻繁答錯(cuò)用戶流失損失遠(yuǎn)大于省下的 token 費(fèi)。我自己的原則是先保證效果再談成本。效果怎么衡量不同場(chǎng)景指標(biāo)不一樣但可以給幾個(gè)方向多輪對(duì)話場(chǎng)景測(cè)試“跨輪信息召回率”。設(shè)計(jì) 10 組需要回憶早期信息的追問看模型正確回答幾組。RAG 知識(shí)問答看答案的準(zhǔn)確性、引用正確率、無(wú)關(guān)內(nèi)容占比人工抽樣 50 條進(jìn)行打分。工具調(diào)用場(chǎng)景看模型能否根據(jù)前幾輪用戶需求正確選擇工具和參數(shù)比如用戶改過地址再問訂單工具參數(shù)是否帶上新地址。我改造客服項(xiàng)目時(shí)建立了一個(gè)小型的回歸測(cè)試集大概 30 條典型的跨輪追問每次調(diào)整 context-mode 配置后都跑一遍。實(shí)測(cè)下來這個(gè)測(cè)試集比任何主觀體驗(yàn)都更能發(fā)現(xiàn)問題。5.2 一個(gè)輕量級(jí)的 A/B 驗(yàn)證方法很多人調(diào) context-mode 是全憑感覺調(diào)來調(diào)去沒有依據(jù)。其實(shí)不需要復(fù)雜系統(tǒng)做一次簡(jiǎn)單的 A/B 就夠了選 50 個(gè)真實(shí)用戶會(huì)話的脫敏樣本。固定模型和參數(shù)溫度、top_p 等只改 context-mode 策略。同一批樣本跑兩遍對(duì)比輸出結(jié)果重點(diǎn)看信息完整度、準(zhǔn)確性、響應(yīng)長(zhǎng)度、響應(yīng)時(shí)間。再統(tǒng)計(jì) token 消耗計(jì)算“單位質(zhì)量成本”。我試過在兩種模式之間做對(duì)比一種是“最近 10 輪全量 之前壓縮”另一種是“最近 5 輪全量 檢索增強(qiáng)注入”。結(jié)果很有意思前者在閑聊場(chǎng)景更好后者在知識(shí)類問答場(chǎng)景明顯更優(yōu)。這說明沒有絕對(duì)最佳策略只有匹配場(chǎng)景的策略。你完全可以用我上面這個(gè) A/B 辦法找出自己的最優(yōu)解。5.3 再說一個(gè)容易被忽略的細(xì)節(jié)輸出 token 也要留夠這是我在調(diào)試中最后才注意到的點(diǎn)。有時(shí)候你配置 context-mode 只盯著輸入側(cè)把輸入 token 壓到很低結(jié)果給模型預(yù)留的輸出空間也很局促——生成到一半被截?cái)嗫雌饋砭拖瘛澳Ｐ蜎]理解需求”。實(shí)為上是因?yàn)樵挍]說完就被掐了。所以配置時(shí)一定要預(yù)留合理的輸出 token 預(yù)算比如復(fù)雜報(bào)告類任務(wù)至少留 4000 到 8000 token否則模型還沒把最后結(jié)論寫完就停了你再怎么調(diào)輸入也沒用。另外如果你用壓縮模式壓縮總結(jié)本身也會(huì)有 token 成本。輕量模型的單次摘要調(diào)用看起來不貴但如果每輪對(duì)話都觸發(fā)一次累加起來也是一筆不小的開銷。我后來把壓縮觸發(fā)閾值調(diào)高比如“每 3 輪壓縮一次”而不是“每輪壓縮一次”成本直接下降效果幾乎沒變。尾聲我現(xiàn)在的 context-mode 思考習(xí)慣這些項(xiàng)目做下來我對(duì) context-mode 的態(tài)度從“一個(gè)參數(shù)”轉(zhuǎn)變成了“一個(gè)設(shè)計(jì)維度”。現(xiàn)在每當(dāng)我接一個(gè)新的 AI 應(yīng)用我都會(huì)在開工前問自己四個(gè)問題一次請(qǐng)求里真正關(guān)鍵的信息是什么哪些內(nèi)容可以外包給數(shù)據(jù)庫(kù)或檢索而不是硬塞進(jìn)上下文歷史對(duì)話里哪些會(huì)干擾模型系統(tǒng)提示詞能不能壓到最短把這些想清楚幾乎就等于完成了 context-mode 的一半設(shè)計(jì)。最后分享一個(gè)小技巧我會(huì)在代碼里給每次請(qǐng)求記錄一個(gè)“上下文使用報(bào)告”輸出系統(tǒng)提示詞、歷史、檢索、工具各自的 token 占比以及最終生成結(jié)果的字?jǐn)?shù)。這樣上線之后萬(wàn)一出問題直接看報(bào)告就能定位是哪塊上下文出了問題不用再逐行打印 prompt 猜來猜去。工具會(huì)迭代、模型會(huì)升級(jí)但 context-mode 這個(gè)思路——在有限的注意力里做聚焦——短期內(nèi)不會(huì)過時(shí)。希望我這篇實(shí)戰(zhàn)筆記能給你一些可復(fù)用的參考也歡迎你在自己的項(xiàng)目里試試那套 A/B 驗(yàn)證法看看會(huì)不會(huì)也得出一些反直覺的結(jié)論。