上下文模式：大模型应用中的上下文管理与工程实践

1. 为什么“上下文模式”会成为一个绕不开的话题

做AI应用开发这两年，我踩过最大的坑不是模型选型，也不是提示词写得不够花哨，而是上下文怎么给、给多少、什么时候不给。你精心设计的Prompt放进空对话里效果惊艳，一旦放进真实业务场景——几十轮对话、多份文档、后台日志混杂在一起——模型输出立刻开始“漂移”，答非所问、自相矛盾、幻觉频出。后来我发现，问题基本都出在一个被大多数人忽略的设计维度上：上下文模式（context-mode）。

所谓context-mode，简单说就是一套“给模型喂什么上下文、以什么结构喂”的策略体系。它回答的核心问题是：当前这次请求，应该携带哪些信息，携带到什么粒度，用什么顺序组织，才能让模型在质量、成本、延迟三者之间取得最优平衡。这不是某个大模型自带的功能，而是应用层自己设计的一套上下文管理机制。

我最早意识到这个问题，是在给一个内部知识库问答工具做优化的时候。最初把整份文档全文塞进Prompt，回答完整是完整，但一次调用要烧掉几万token，回答还经常把旧版本内容当成新版本输出。后来我尝试给上下文做了分级、分层、分场景，这就是我自己的第一个“context-mode”雏形。这篇文章适合正在做AI应用落地、RAG系统搭建、或者想在提示词工程上再进一步的同学参考，我会把上下文模式的几种设计思路、实现方式和踩坑经验一次性讲透。

2. 上下文模式的核心：先搞清楚上下文是怎么影响模型行为的

2.1 大模型并不是真的“记住”了你们的对话

很多刚接触大模型开发的人会误以为，模型在对话里记得所有历史内容是因为它“记住了”。实际上，模型本身是无状态的——每一次API调用，模型只看到你这次Prompt里携带的字面内容。所谓的多轮对话能力，是应用层把历史消息拼接到Prompt里，重新发送一遍。你上一轮说了什么，模型本轮能否“记得”，取决于你这次请求有没有把上一轮内容再传一遍。

这个机制带来的后果非常直接：上下文是一种受控资源。你传什么，模型就看什么；你不传，它就等于第一次见到你。context-mode要解决的第一件大事，就是在这种无状态机制下设计出有状态的应用体验——哪些对话历史保留、哪些丢弃、哪些压缩、哪些置顶，全部由模式规则决定。

2.2 上下文窗口不是越大越好：三个关键规律

我在实际项目里总结出三条规律，基本适用于目前主流的对话模型：

第一，上下文窗口是物理上限，但成本线永远在窗口之内。假设模型支持128K上下文，你每次塞满128K，单次调用成本可能比你塞2K贵上几十倍。尤其在生产环境里，token消耗直接跟账单挂钩，不是技术问题了。

第二，中间位置的上下文容易被模型“忽略”。业内把这叫做“lost in the middle”——模型对开头和结尾的注意力显著高于中段。你把关键信息放在Prompt中间，哪怕信息完整，模型也常常漏掉。这意味着上下文的结构编排很重要，不是简单拼接就能用。

第三，上下文越杂，语义干扰越强。当Prompt里既有产品文档、又有聊天记录、又有日志片段时，不同来源的语言风格和话题会让模型难以聚焦当前任务。这也就是上下文污染（context pollution）：上下文越多，噪音越多，模型越容易跑偏。

2.3 从无脑全量到按需装配：context-mode的本质

基于上面三条规律，context-mode本质上是在做一件事：将上下文从“单一的、被动的、越堆越多的消息列表”，重构为“分层的、主动配置的、按需装配的信息体系”。它把上下文拆解成几个逻辑单元——核心指令、必要事实、历史摘要、参考文档、当前输入——然后由一套规则来决定每个单元是否入库、保留多少、以什么形态进入Prompt。

这不是一个高大上的算法问题，而是一个工程架构问题。你要做的，是在应用层建立一套“上下文基础设施”：既要有统一的上下文组装入口，也要有不同场景下的模式定义，还要有监控和调参的手段。把这套东西做出来，你就能从“每次手忙脚乱地拼Prompt”升级到“按场景一键切换上下文策略”。

3. 五种主流的context-mode设计模式及其适用场景

3.1 完整模式：所有历史全量携带

完整模式不难理解：把整个会话的消息列表原封不动拼进Prompt。这种模式的优点是实现最简单、信息零损失，适合对话轮次少、单轮信息量大的场景，比如一次性的长文档分析、代码评审。

但它的问题也很扎眼：对话一长，token成本线性上涨；消息一杂，注意力被稀释。我见过一个客户在用了完整模式后，30轮对话时单次调用token数飙到15万，且模型开始频繁引用旧配置来回答新问题——这就是信息太多导致的“历史信息压迫当前指令”。完整模式适合做兜底，不适合做主力的日常模式。

3.2 滑动窗口模式：忘掉该忘的

滑动窗口是完整模式的直接改良：只携带最近N轮对话，更早的内容一律丢弃。N的选择通常根据任务性质来定，比如客服场景保留最近5轮足够，因为用户当前的问题大概率跟上一轮直接相关，跟20轮前的关系不大。

这模式的优点在于控制成本非常有效，缺点则是“突然遗忘”——用户如果中途提到“就像我们刚才说的那件事”，而这件事发生在窗口之外，模型就完全接不上。解决办法是配合下面的摘要模式，而非完全依赖窗口。

3.3 摘要继承模式：记住“结论”，忘了“过程”

摘要继承模式，是在滑动窗口基础上增加一层历史压缩机制：把早期对话在每轮结束后由模型提炼成一段结构化摘要，后续请求携带“摘要 + 最近窗口原始消息”。比如你们前20轮讨论了需求变更的来龙去脉，摘要会记下“用户最终确认采用方案B，弃用方案A”，而详细的争论过程则被丢弃。

这个模式是我在实践中最推荐的一个，因为它平衡了完整性和token成本。但它的实现有一个关键细节：摘要必须连续迭代，而非仅基于首轮生成一次。每一轮新信息都要滚动更新到摘要里，否则摘要会越来越陈旧。我自己的经验是，摘要单独走一次小模型调用，用专门的摘要Prompt，控制摘要长度在300~500字左右，这样既不占主对话太多token，又能保留足够多的决策信息。

3.4 检索增强模式：按需取用，代替全量导入

检索增强模式，也就是常说的RAG（Retrieval-Augmented Generation）思路。在面对知识库问答时，不再把整本文档塞进上下文，而是先把用户问题做相关性匹配，从知识库中召回最相关的3~5个片段，再把这几个片段拼入Prompt。

这种模式的核心理念是“上下文越精准越好，而不是越多越好”。量化来看效果非常显著：我做过一组对比，同样一道问答，全量塞文档需要2万token，检索增强模式只用了1800token，回答准确率还从74%提升到了89%——因为上下文里没有了无关内容的干扰。检索模式的难点在于召回质量：切分粒度、向量化模型、相似度阈值、重排序策略都会影响最终效果，后续实操章节我会展开讲。

3.5 场景预设模式：为不同任务定制上下文骨架

场景预设模式更像是一种“元设计”：为不同类型的任务，定义不同的上下文组织模板。比如“代码生成”模式下，上下文骨架是“系统指令 + 仓库结构信息 + 相关文件片段 + 用户需求”；在“客服对话”模式下，骨架变成“用户画像 + 历史工单 + 当前会话窗口”；在“数据分析”模式下，骨架则换成“数据字典 + 表结构 + 样例行 + 业务问题”。

这个模式解决的是多任务混杂场景下的上下文冲突。如果你一个AI助手既要聊天、又要查库、又要写代码，把所有信息混在一个Prompt里让模型自己“理解”任务，效果大概率是灾难。场景预设模式通过显式的上下文骨架来引导模型的行为模式，让模型仿佛在一个“专岗专用”的状态下工作——这正是context-mode这个词里“mode”的真正含义：一种可切换的工作状态。

4. 实操：从零实现一个可用的context-mode管理器

4.1 架构设计：先抽象出上下文组装的统一入口

动手写代码之前，先明确架构。我建议把上下文管理从业务代码里抽离出来，做成一个独立的模块。无论你是在LangChain、LlamaIndex还是自研框架里做，核心抽象就三个接口：

• build_context(request, session, mode)：根据请求和会话状态，组装出最终进入模型的Prompt上下文。
• update_session(session, request, response)：每次请求结束后，更新会话状态（包括窗口裁剪、摘要滚动更新）。
• select_mode(request)：根据请求特征自动或手动选择使用哪种上下文模式。

这三个接口组合起来，相当于给应用装了一个“上下文阀门”：所有发给模型的内容都经过统一调度，从此再也不会出现“有几处拼接Prompt的代码散落在各个函数里，改一处漏一处”的局面。

4.2 模式配置：用配置驱动，而不是硬编码

每种模式需要一套独立参数。我建议用配置文件或数据类来管理，而不是把逻辑写死在业务代码里。一个精简的配置结构大概长这样：

@dataclass class ContextModeConfig: mode_name: str # 模式名称，如 "full" / "sliding" / "summary" max_turns: int = 0 # 滑动窗口保留轮数；0表示不限制 summary_len: int = 400 # 摘要目标长度（字数） enable_retrieval: bool = False # 是否启用检索增强 retrieval_top_k: int = 3 # 召回片段数量 retrieval_threshold: float = 0.75 # 相似度阈值 include_system_prompt: bool = True # 是否强制包含系统指令

关键在于：所有模式都收敛到同一份配置结构里，组装逻辑由配置驱动，而不是每个模式写一套独立代码。这样切换模式的时候，只是切换一份配置，代码层面几乎不用动。我试过把七种业务场景切换成配置化之后，整个上下文模块的维护工作量下降了至少一半。

4.3 摘要滚动更新的实现：不要每次全量重摘要

摘要继承模式中，最容易犯的错是“每次对话都把全部历史丢给模型重新生成摘要”。这在轮数少时没问题，轮数一多，摘要生成的成本也会水涨船高。更合理的方式是“增量式摘要”：上一轮的旧摘要连同最近新增的对话，一起送入摘要模型，生成更新的摘要。这样无论会话多长，摘要更新的输入始终是“旧摘要 + 新增消息”，而不是全量历史。

我给出一段核心逻辑示意：

def refresh_summary(old_summary, new_messages, target_len=400): prompt = f""" 你是一个对话摘要器。请根据以下旧摘要和新增对话，生成一份更新后的摘要。 要求： 1. 保留关键决策、已确认事项、用户偏好、未解决问题。 2. 忽略寒暄、语气词、无关细节。 3. 摘要控制在{target_len}字以内。 4. 如果旧摘要中的信息已失效（例如被新决策推翻），请以新信息为准。 旧摘要： {old_summary} 新增对话： {new_messages} 更新后的摘要： """ return call_llm(prompt, max_tokens=target_len * 2)

这里还藏着一个细节：摘要Prompt里要有“如果旧摘要中的信息已失效则覆盖”这条指令。否则模型出于惰性，会倾向保留旧内容，新变化反而不容易进入摘要，最终导致摘要的时滞性越来越严重。

4.4 滑动窗口的token预算计算：先算账再定参数

滑动窗口的N轮到底取多少，不该拍脑袋，应该从token预算倒推。我一般按这个公式估算：

假设每轮平均用户消息加助手回复约等于tokens_per_turn，窗口长度就是max_tokens_per_turn = tokens_per_turn * num_turns + system_prompt_tokens + current_input_tokens。

举个例子：每轮平均600 token，系统指令约400 token，当前输入约300 token，模型最大输出预留1024 token，模型窗口上限8000 token。那么可分配给窗口的预算是8000 - 1024 - 400 - 300 = 6276token，除以单轮600，窗口轮数最多约10轮。在这个预算范围内，如果你还想给摘要留空间，N还要再降。

我把这组参数做成了一张速查表，方便场景选型：

注意，这里的数字只是起点，上线后必须根据实际调用数据再调。我自己的习惯是把每次请求的token使用量、回复质量评价、上下文命中率三组数据接到日志里，跑一周之后再看参数是否合理。

4.5 检索增强模式的切分与召回参数要点

关于RAG部分，我简要提几个实操重点。

文档切分粒度，我推荐按语义段落切，而不是按固定长度切。固定长度切分（比如512字符一刀切）极易切断句子和段落，导致召回片段语义破碎。我自己用的是先按markdown标题结构分块，再对每个大块做段落级切分，单块长度控制在300~500字。向量化模型的选择上，如果知识库是中文为主，优先用针对中文优化的嵌入模型，通用英文向量模型在中文场景的召回质量会明显差一截。

召回后的重排序（rerank）不要跳过。第一次召回Top20，经过rerank之后再取Top3~5，比直接按向量相似度取Top5的效果要稳得多。这个处理能让最终进入上下文的内容最贴近当前问题。上下文模式的价值在“选什么”，重排序的价值在“选谁最好”，两者是叠加关系不是替代关系。

5. 典型场景下的模式选型与参数调优实录

5.1 知识库问答助手：从全文搬运到向量召回

我接手过一个内部规章制度问答机器人，最初实做方式非常粗放：用户问什么，就把规则库里所有可能相关的文档全文拼到Prompt里。由于制度文件动辄上万字，一次问答的token消耗经常破万，回答中还经常出现“按照旧版制度第X条”这类错误引用。

改造后，我给这套系统接入了检索增强模式：制度文档按章节切块，每块控制在400字以内；用户提问先向量召回Top20，再经过一次轻量rerank取Top5；Prompt里固定只放这5个片段。改造后单次问答token降到1500左右，引用准确率从68%升到92%。这里有一个人经验教训：最初我用TOP5直接拼入，经常出现“多片段内容互相矛盾导致回答逻辑混乱”的情况，后来在Prompt里加了一句明确指令——“当不同片段存在矛盾时，以更新生效日期者为准，并明确指出相关条目可能存在版本差异”，问题基本消失。

5.2 智能客服机器人：摘要 + 窗口协同

客服场景的典型难点是：用户常常在第三轮才说出真正意图，但前面的寒暄和身份确认信息又不能丢。我试过只用滑动窗口（10轮），遇到用户说“那我刚才说的退款的事呢”就会漏上文；加上摘要继承模式后，前几轮的关键信息被压缩成“用户要求对订单A申请退款，原因是商品损坏，当前状态是已发起申请但未收到确认”，之后无论窗口怎么滑，摘要始终带着这个核心语境。

实现上有一点特别值得注意：摘要不能只在会话结束时生成，而应每轮都增量更新，但没有必要每轮都调用大模型生成一次。我的做法是，只有用户新消息里出现“意图变化”或“关键实体”时才触发摘要刷新，否则沿用上一轮摘要。判断意图变化可以对消息做一次轻量分类，成本很低但效果显著。

5.3 长文创作助手：场景预设 + 分幕上下文

长文写作助手是最容易上下文混乱的场景。用户想让你写一章小说，她可能前面说“文风要冷峻”，中间又说“插入一段校园回忆”，最后要求“结尾要开放式”。如果所有指令在同一上下文里持续生效，模型会在后半程依然背着前半程的旧指令，导致节奏割裂。

我用场景预设模式把创作过程切分成多“幕”：设定幕（人物设定、世界观）、情节幕（本章具体任务）、修订幕（对上一版的反馈）。每一幕独立维护上下文，主Prompt只携带当前幕的相关信息和精简后的全局设定摘要。结果是，模型在当前幕内的遵循度明显提升，且不会因为前面某句随口的话带偏整个后半程。如果你开发的AI工具涉及“长目标任务”，强烈建议考虑这种分幕上下文设计。

6. 常见问题与排查技巧实录

6.1 症状：模型开始“忘事”，明明上下文中包含该信息

排查路径是先检查实际发送到模型的Prompt内容，而不是猜测。很多框架会对拼接结果做截断或省略处理，你以为“上下文中包含”，其实模型根本没收到。我遇到过最坑的一次，是LangChain内部把SystemMessage放在列表最后，而我们的阅读器对长消息做了截断，结果系统指令被砍掉一半，模型行为彻底失控。

确认Prompt完整性之后，再检查内容位置。如果你发现关键信息确实在上下文里，但模型还是漏读，大概率是“lost in the middle”——关键信息被挤到中段了。对策有两种：要么把关键指令移到Prompt首部或尾部，要么减少上下文总长度，把噪音内容压缩。

6.2 症状：摘要模式开启后，回答内容越来越泛

这是典型的摘要过度压缩。摘要越短，信息密度越低，模型只能靠“常识”补全细节，输出自然越来越泛。建议把摘要字段拆分成“决策记录、待办事项、用户偏好、背景事实”四个小节分别压缩，而不是揉成一段笼统的话。每节设定不同权重：决策记录权重最高，必须逐字保留；语气类信息权重最低，可直接省略。

6.3 症状：检索增强命中率低，答非所问

优先检查两件事：切分是否打断语义；查询和文档是否同domain。打断语义的情况在PDF文档中尤其常见，表格被切成碎片后向量化效果极差。解决办法是结构化解析表格，再将表格转成Markdown后作为一个独立块参与切分。domain不一致的情况则常见于“用户问A，但库里只有B”，这不是上下文模式能解决的，需要前置意图路由。

6.4 症状：每次调用token数超过预算，成本失控

先看是不是有无意中叠加多个模式：有些框架里既开了历史消息全量拼接，又开检索增强，等于两套上下文都在消耗预算。我的建议是套一个“预算闸门”：在组装上下文后、发送模型前，统计Prompt总token数，超过预算时自动降级——比如先砍检索片段数量，再裁窗口轮数，最后压摘要长度。按这个优先级降级，对回答质量的影响是最小的。

6.5 症状：切换模式后，某类特定任务的输出质量反而下降

模式切换是有试错成本的，不要指望一套参数通吃所有任务。我遇到过客服场景切到“全量模式”后回答变得啰嗦——因为模型看到的历史内容太丰富，开始主动补充无关细节。解决办法是把模式选择做成一个可观测的决策：上线前先做小流量A/B对比，用“回复相关度、完成率、用户反馈”三指标来评估，不要只凭感觉判断“好像变聪明了”。上下文模式调优是一个持续的过程，每次改动都要有指标支撑，不然很容易被模型输出的随机性带偏。

7. 最后分享一个实测中非常管用的小技巧

说一个我在多个项目里屡试不爽的“隐藏细节”：给上下文打标签。在组装Prompt时，用不同的XML标签或Markdown引用块把不同来源的上下文区分开，例如<retrieved_docs>、<chat_history>、<user_profile>、<system_rules>。模型在理解混排信息时，结构化的来源标签会显著降低上下文间的互相干扰。

我在一个知识库项目中试过：同样内容，不加标签时模型回答正确率为78%，加上来源标签后提升到86%，这8个百分点来自纯结构收益，没有增加任何token。很多人在提示词工程上花费大量精力，却忽略了上下文信息本身的结构化呈现也是一种隐式指令——它告诉模型：这些信息来自不同通道，你要分而治之。

context-mode说到底不是某个函数或某段配置，而是一种设计思路：把“喂什么给模型”看作和“怎么写Prompt”同等重要的工程问题。当你开始用这种视角改造应用，那些飘忽不定的模型输出，会变得逐渐可控起来。