聊一个这几年我在各种大模型应用项目里反复踩坑、又反复优化的核心概念context-mode。只要你在做 Agent、做 RAG、做多轮对话、或者用 API 搭任何带记忆的东西你早晚都会撞上同一堵墙——模型能记住的内容是有限的但真实业务里的信息是无限的。把什么塞进上下文、用什么顺序塞、塞满了怎么办、下一轮对话要不要清掉这一整套处理逻辑就是上下文模式。它直接决定了你的应用是看起来聪明还是三句话就失忆也直接决定了你的 API 账单是勉强能撑还是离月底破产不远。这篇文章不聊教科书定义只聊我在真实项目里怎么设计、怎么选型、怎么带货踩坑最后怎么把 context-mode 从“一个模糊的参数”落地成“一整套可复用的工程方案”。适合正在做 LLM 应用开发、但又没系统梳理过上下文策略的工程师也适合那些被 ChatGPT 项目折磨过、想搞清楚为什么自己的产品总是答非所问的产品经理。1. 先搞清楚Context Mode 到底在解决什么问题1.1 术语来源从命令行到智能对话“context-mode”这个词最早被大量使用其实是来自 grep、diff 这类命令行工具。grep 查关键词的时候加上-C 3表示“把命中行前后 3 行也一起显示出来”这就是最朴素的上下文模式——只给你核心命中的行没有意义因为脱离了前后文你根本不知道这段内容在讲什么。到了大模型时代context mode 的含义被彻底放大了。一个 LLM 其实就是一台“根据当前输入预测下一个 token”的机器你说的每一句话、它回答的每一个字都会被塞进一个有限长度的上下文窗口里。窗口越大它能“参考”的信息越多推理越准但代价是计算量更大、响应更慢、费用更高。这里就出现了一个核心矛盾业务场景是无限复杂的而模型窗口是有限且昂贵的。context-mode 就是用来调和这个矛盾的一套调度策略——它决定哪些信息配得上进入上下文窗口哪些信息该被压缩哪些该被遗忘。1.2 核心矛盾窗口不是越大越好很多人刚开始做应用时有一个错觉上下文窗口越大效果就越好。于是他们一看到模型支持 128K、200K 上下文就拼命往里塞文档、塞历史消息、塞各种系统提示词以为“反正装得下”。实测下来这个想法会让我很想捶桌子。拿 API 计费来说绝大多数大模型是按 token 收费的输入 token 和输出 token 都计费而输入占大头。你把 80K token 的文档一把梭塞进去用户问一个“第二页第三段写了什么”其实只有几百个 token 是有用的剩下 79K 都是白烧钱。更糟糕的是上下文过长会导致模型“注意力稀释”它根本不知道应该重点看哪部分结果就是越长的窗口反而产生越差的回答质量这跟人一样一次让你读 20 万字你可能连第一篇的中心思想都记不准确。所以我会在项目里反复强调与其无限扩大窗口不如把内容控制在“刚好够用”的范围。这才是设计 context-mode 的真正目的——不是在追求“装得更多”而是在追求“装得精准”。2. 四种主流 Context 处理模式各有利弊没有银弹2.1 全量模式简单粗暴但成本最高全量模式就是字面意思把所有相关信息一次性全部拼进 prompt 里不做任何筛选。比如做客服助手就把产品手册、常见问题、用户历史订单全部扔进去让模型自由发挥。优点很直接实现成本极低所有信息模型都能看到不存在“因为被过滤掉所以答不上来”的问题。适合那种需要全局信息才能做判断的场景比如让模型总结一份完整合同的风险点你总不能只让它看节选。缺点也致命——成本和延迟都高得离谱。我有一次做内部知识库问答PDF 转文本后有 14 万 token全量塞进去单次请求的输入费用就不是“分”这个量级了而且首字延迟接近 30 秒用户直接抱怨“这破机器是拨号上网吗”。所以全量模式的适用面其实非常窄它只能解决“一次性、文档量可控、时效性没有太高要求”的任务。2.2 检索模式把上下文变成按需加载检索模式是当前 RAGRetrieval-Augmented Generation体系的核心。它借鉴了“按需加载”的思想像图书馆一样先建好索引用户提问时再去做检索只把相关的片段拼进上下文。我常用的做法是把文档切块chunk、做 embedding 向量化、存到向量数据库里用户提问时先做语义检索取出 top-k 个高相关片段再连同用户问题一起发给模型。这个模式的好处是上下文体积大幅缩水成本可控而且因为每次只塞“和问题最相关的内容”回答针对性和准确率反而更高。但检索模式也有自己的头痛之处最怕检索不到。如果你的切块策略不好、向量模型不太行、或者问题里的措辞和文档里的措辞差异太大召回结果可能就是一堆无关内容。我见过不少团队兴冲冲搭了 RAG结果用户问“退货流程”模型答非所问因为文档里写的是“退款相关规定”语义检索没命中。检索模式不是万能的它只能解决“库里有、且能搜到”的问题。2.3 压缩模式丢细节保主线压缩模式也很好理解既然上下文窗口有限那就先把原始内容做一道“摘要提炼”把核心观点、关键数字、结论先抽出来再塞给模型。做长文本分析、需要连续几轮讨论复杂文档时压缩模式的效率优势很突出。比如你有一份 5 万字的行业报告前两轮对话已经在逐章讨论了到了第三轮你想让模型结合全文来回答整体判断每次都全量重塞显然不现实那么预先压缩出一份 2000 字的“核心要点版”既能覆盖主线信息又能让模型站在全局视角上回答。压缩模式的问题是信息损失不可控。摘要算法再好也难免丢掉细节尤其是一些具体数字、条件限定语、转折关系一旦在压缩环节被丢弃后面模型再聪明也救不回来。所以在那种“必须精确、必须能追根溯源”的场景里我一般不会单独用压缩模式而是会把它作为检索或全量模式的“辅助层”——既保留原文入库又准备一份压缩摘要让模型根据摘要判断要不要调取原文细节。2.4 分层滚动模式让模型自己决定记住什么这种模式我越来越常用做法是维护一个“分层记忆池”把上下文分成几层系统层固定指令、任务层当前这轮的核心输入、历史层过去几轮的关键信息摘要、候选层按需检索出来的临时资料。每一轮对话结束后系统会把历史层重新压一遍旧的 key 信息会滚动成更短的摘要无关信息会被遗忘。做过 GPT 类聊天产品的朋友应该会很有体感默认情况下大多数框架对多轮对话的处理就是“把过去 N 轮消息原样拼回去”这会导致一个严重问题——上下文窗口很快被历史聊天占满且早期的内容全是噪声。我搭会员问答 Bot 时就这样玩过用户问了一堆不同类目的问题如果不做分层滚动第 10 轮时模型可能已经忘了第 1 轮的内容但如果全留着窗口又会被无关内容污染。于是我把历史层做成了“分类记忆槽”每个槽保留最近 3 条相关消息和一条摘要用户再问到之前的主题时模型还能从摘要中“回想”起来。这个思路的核心就是上下文不该是一个被动的队列而应该是一个有生命周期的记忆系统。3. 实操落地为 Agent 应用设计一套 Context 处理体系3.1 需求拆解先定义你的上下文里有哪几类内容在动手写代码之前我习惯先做一张“上下文物联网关”。拿我最近做的一个合同审查助手来说在它每一次向模型发请求时可能进入上下文的候选内容有六类系统指令审查规则、输出格式、禁忌事项待审合同原文可能是几十页 PDF 转出来的长文本用户需求本次要重点审查“付款条款、违约责任、知识产权归属”历史问答用户前几轮提到过“我们是乙方希望多争取账期”参考法条/类似合同条款需要从知识库检索的外部材料中间推理结果模型或工具在过程中生成的表格、摘要这六类内容的优先级、体量、生命周期完全不同。系统指令必须永远保留而且不能截断待审合同原文体量巨大可以根据用户需求按章节“局部加载”历史问答该做摘要滚动参考法条则完全依赖检索实时召回。这一步看着简单但很多人栽跟头就是没做这个拆解。他们把所有内容一视同仁地拼进 prompt结果系统指令被一堆历史消息挤出窗口或者法律条款被原文淹没。我先用表格把清单列出来后面每一步都好操作得多。3.2 上下文生命周期的四个阶段我设计 context-mode 时会按“收集-筛选-注入-清理”四步来走下面是我总结的标准流程。第一个阶段是收集。所有可能进上下文的候选信息先不急着塞进 prompt而是一股脑收进来存在一个结构化的容器里。这里用伪代码描述大概是这样的思路function collectContext(request) { return { system: loadSystemPrompt(), documents: loadRelatedDocs(request.docIds), history: memoryStore.getRecent(10), userInput: request.message, fetched: vectorSearch(request.message, topK5) } }第二阶段是筛选。根据本次请求的具体场景给每类内容做取舍。比如用户只问“第三页的支付条款怎么改”你硬把整份合同塞给他就是浪费 token这时候只加载“第三页原文 合同整体目录 与该条款关联的法条”就够了。筛选时要设定预算我的经验值是把单次请求的输入 token 预算分为三档——常规档全文窗口的 60%避免撑满、高配档全文窗口的 80%用于复杂长文分析、经济档全文窗口的 30%用于简单问答。第三阶段是注入。按“系统指令→用户需求→检索片段→历史摘要→文档局部→结构化中间结果”的优先级顺序排列。排序是有讲究的模型对 prompt 开头和结尾的内容注意力相对更强这是业界常说的 anchor effect虽然并非绝对但实践里确实明显把最重要的系统规则放最前面把本次要处理的具体目标放最后面让模型带着目标去读中间的材料。第四阶段是清理。每次响应结束后不能把整段对话原封不动地存起来。我会把历史层做一次摘要压缩新摘要合并旧摘要后回写存好然后把超过 N 轮的原始消息移到冷存储。这样才能保证下一轮请求时历史层的开销是固定且可控的。3.3 关键参数怎么定窗口、检索条数、压缩比例很多刚入行的朋友会问我“有没有一个万能参数推荐”答案是没有但有实测过的经验参考值可以作为起点再慢慢调。检索条数top-k我一般从 4 开始调。对于大部分问答场景top-k 4 条 200~300 token 的片段大概 800~1200 token已经能覆盖答对 80% 的问题只有“多文档综合对比”这种场景我才会上调到 8~10 条。切块大小chunk size切得太小块会丢失上下文逻辑切得太大块又会让检索命中精度下降。我的习惯是 400~600 token 一个 chunk段落之间保留 10%~15% 的重叠给每个 chunk 加一行来源路径元数据。压缩摘要的触发阈值历史决策在 6 轮以内我保留原文超过 6 轮就开始做滚动摘要每 3 轮合并一轮。这个数字是纯粹凭业务节奏定的因为实测 6 轮以内模型对早期细节的“还能回忆起来”的程度还高超过之后错误率会明显上升。窗口预留比例我始终不让 prompt 占满整个窗口至少预留 15%~25% 给模型的输出 token。如果你用的模型窗口是 128K输出可能占 8Kprompt 里就尽量压在 90K 以内留白给模型思考和生成的空间否则经常出现“请求超预算”的错误。4. 踩坑实录我在这条路上遇到过的常见问题4.1 上下文污染历史残留信息反向干扰第一次听说“上下文污染”这个词时我还觉得危言耸听。直到有一次做客服机器人用户前一句问“你们的退款多久到账”客服答完“3~5 个工作日”用户紧接着问“这个能加急吗”模型居然回答“可以免费加急”因为模型在历史消息里把“退款”误读成了“所有订单都支持加急”。这就是典型的上下文污染——历史信息被模型过度泛化你没有及时清理掉上一轮任务中的临时限定条件。我的解决办法是对历史层做分区存储把“用户画像型事实”和“任务型临时状态”分开。任务型状态比如“用户目前正在咨询退款”每轮任务结束后就清掉或弱化只保留画像型事实比如“用户是会员”。4.2 检索命中率低召回不到关键内容RAG 失效的最典型现场是你在知识库里明明存了“A 型号打印机如何换墨盒”的文档用户问“A 打印机没墨了怎么办”结果语义检索返回的全是“B 型号打印机清洁喷头”。这种现象叫“表达习惯错位”——文档表述和用户口语之间有语义差距常规向量检索模型很难跨越。我的排查有三板斧。第一板斧是先做召回诊断把用户问题和召回片段打出来看确认是不是 embedding 本身出了问题。第二板斧是给检索过程加“关键词加权”也就是在向量语义之外用 BM25 或者简单的词法检索获得一个混合分数互补语义盲区。第三板斧是重写查询先让一个轻量模型把用户问题改写为“更接近文档表述的检索语句”再去做 embedding。实测下来第三招提效最明显但会多花 300~500 token 的开销属于一种“以 token 换命中”的取舍。4.3 成本爆炸明明没多少用户账单却高得吓人我在某个项目上线首周就收到过一封让我后颈发凉的账单——单周 API 费用直接顶上一个月的预算。排查后才发现问题出在产品前端疯狂触发会话续接用户每打开一次页面就重新发起一次全量上下文请求且由于我没有做“请求级别的缓存”同样的历史摘要反复被重新计算。后来我总结了三个省钱硬规则。第一相同内容的向量检索结果做短时缓存TTL 设 5 分钟防止同一问题反复检索相同片段。第二历史摘要的更新采用“增量式”不是每次都全量重算而是只把新增的几轮对话和上一轮的摘要合并再压缩。第三把高频启动场景做成“单轮模式”牺牲一部分记忆连续性换回成本和响应速度的平衡。4.4 长上下文的“幻觉放大”问题上下文越长模型越容易编造“好像存在但其实不存在”的内容。这里最坑的是长上下文中某个片段如果只在开头出现过一次模型在生成时可能会记混把 A 文档的条款套到 B 文档上。我检查过一条典型的幻觉输出合同原文里根本没有“违约金为合同总额 20%”这句话但模型煞有介事地引用说“根据贵方合同第 7.2 条”。结果一查7.2 条写的是“争议解决方式”。解决这个问题的思路是“证据要求”在 prompt 里强制要求模型所有关键信息必须标注来源片段 ID且规定“如果原文中没有该信息必须明确说没有不能自行推断”。这一步可以把幻觉率降低一半以上强烈建议所有做文档审查类应用的人加上。5. 进阶方向从静态模式到自适应的 Context-Aware 体系5.1 根据用户难度动态调整模式做到前面这些步骤你的 context-mode 已经比 80% 的简易集成方案要成熟了。但如果想让产品体验再上一个台阶可以试试“场景感知式切换”——不用一套模式打通所有问题而是先判断当前用户的行为特征再动态选择上下文策略。比如用我的会员问答 Bot 来举例。新用户上来问“你们平台怎么收费”这种问题不需要任何历史记忆我会直接走“经济档”把系统指令压缩到最短完全不做检索。但如果是老用户已经连续问了七八个问题且明显在围绕某一个产品做深度调研我会自动切换到“高配档”开启历史摘要、文档局部加载和检索式上下文的完整组合。这种动态切换的本质是把 context-mode 从一个“静态配置项”变成一个“随场景调度的策略集合”。实现上其实不复杂就是加一个输入分类器可以是 100 行代码规则也可以是轻量模型做意图判断在请求进入系统之前把当前会话的“复杂度标签”打出来再映射到对应策略。5.2 让上下文跨会话长期驻留很多产品除了单次会话内的上下文管理还需要跨会话记住用户的长期偏好。这就涉及到“长期记忆层”的设计。我通常做法是为每个用户维护独立的记忆槽位包括事实槽用户的公司规模、行业、偏好、关系槽用户与某个项目/文档的关系、事件槽用户过去做过哪些操作。每次会话结束时我会把这次会话中抽取出来的“结构化事实”写入记忆槽但不把原始聊天记录全量存着。下次用户再登录系统先加载记忆槽里的精简摘要再叠加本次会话的上下文这样用户会觉得这个产品“居然记得我是谁记得我上次聊到一半的事”。这其实就是很多 AI 应用正在追求的“personal memory”能力而它的底层仍然是 context-mode 的合理组合。我踩过不少弯路的总结是context-mode 不是一个“打开就有效”的开关而是一套需要好好设计的工程体系。从我最开始全量塞 prompt 的粗打法到后来检索、压缩、分层滚动、动态切换的组合方案每一步都是被账单、延迟和答非所问逼出来的。如果你现在刚开始设计自己的 AI 应用我的建议是先别急着上最复杂的方案从全量模式做起用真实的数据去观察你的应用到底在哪里“失忆”再按这篇里的思路一步步加上检索、压缩和记忆层。等你跑通了你大概率会和我一样觉得 context-mode 才是决定产品“智商”的那层隐形地基。