context-mode这个词最近在AI应用圈子里被反复提起。它不是什么新算法而是一套关于怎么管理大模型上下文的工程实践思路。我自己的好几个LLM项目都栽在上下文管理上所以今天想好好聊聊这个话题为什么你的AI应用总是聊着聊着就傻了为什么上下文窗口明明很大却还是不够用以及一套我实测下来非常有效的context-mode设计方法。这篇文章适合正在做AI应用开发的工程师、被工具记忆太短困扰的重度用户以及所有想搞清楚AI是怎么记住我说过的话的爱好者。我会先拆解上下文管理的核心矛盾再给出具体的实现路径和参数配置最后把我在实战中踩过的坑一一列出来。你可以直接照着这套思路去改造自己的项目。1. 内容整体设计与思路拆解1.1 为什么需要context-mode先理解上下文是个什么东西先打个比方。你和一个朋友聊天他记性超好你说过的每一句话他都记得聊到第50分钟还能准确回你第3分钟随口提的一个细节——这是理想状态。但现实是大模型的记忆不是真正的记忆它只是在每次对话时把你给它的所有文字重新读一遍。这就带来两个矛盾第一个矛盾是上下文窗口有限。目前主流模型的上下文窗口从8K、32K到128K甚至200K token不等听着很大但实际算一笔账就明白了一篇5000字的中文文章大约对应8000-10000个token128K窗口大概只能装下十几万字。而一个真实的多轮对话、一份复杂的项目文档、一次完整的代码审查很快就触及上限。第二个矛盾更隐蔽上下文越长模型越分心。研究表明当上下文里塞入大量不相关的内容时模型对早期信息的注意力会显著下降而且这种下降并不是线性的。也就是说你以为给了模型很多记忆实际上它早就把早期的关键信息打折处理了。context-mode的核心思路就是不再把所有历史记录塞进上下文当作默认策略而是像人一样分清楚什么该短期记住什么该长期存储什么该立即遗忘。这套模式拆解开来就是三个问题哪些信息必须出现在本次请求中喂给模型的当前注意力哪些信息可以压缩后保存需要时再拿出来外部知识哪些信息直接丢弃噪音和冗余1.2 三种主流方案选型压缩、检索、分层我自己尝试过三种实现context-mode的方式各有适用场景这里先做个整体对比后面再细讲实现。方案核心思想优点缺点适用场景滑窗截断只保留最近N轮对话实现简单、资源消耗低早期信息彻底丢失闲聊型、单次任务型摘要压缩把历史对话实时归纳成摘要节省空间、保留主线细节损失、摘要生成有延迟多轮任务型、客服对话分层记忆短期缓冲长期存储检索调取兼顾细节和容量架构复杂、需要调优知识密集型应用、复杂项目代理先说结论不要迷信某一套方案实际项目里我通常组合着用。比如一个客户服务Bot最初我就是用滑窗截断结果用户三天前报过的订单号换了新会话就忘了被用户喷了一顿。后来改成摘要压缩关键信息持久化情况好了很多。但摘要本身也有问题——如果用户反复修改需求摘要会把早期被否掉的方案也压缩进去导致模型翻旧账。真正让我稳定下来的是第三套方案分层记忆架构。它的设计哲学是把上下文拆成几个层次每个层次有清晰的写入、读取、淘汰规则。这套架构也是我接下来要重点讲的context-mode实现。2. 核心细节解析与实操要点2.1 上下文的内容解构系统提示、工作记忆、检索记忆、当前输入一个设计良好的context-mode首先要学会给上下文分类收纳。我把一次完整的LLM调用所需的内容拆成四个部分第一是系统提示词系统指令。它像员工手册定义了模型的身份、行为准则和任务边界。这部分是静态的每次请求都要带但要尽量精简。我见过太多项目在系统提示里堆了上千字的角色设定结果挤占了宝贵的上下文空间。一个合格的系统提示词应该控制在200-300个token以内。第二是工作记忆。对应的是本次对话进行中产生的临时信息比如用户上一步的选择、当前正在处理的文件、刚才计算出的中间结果。这部分是动态的但容量很小通常控制在500-1000个token。它的作用类似于程序员写代码时栈里的局部变量。第三是检索记忆。这是从长期存储中按需拉取的内容。比如用户提到上周聊过的那个需求系统就应该去向量数据库里检索出相关的历史片段而不是把上周所有对话记录全部塞进去。这部分是context-mode的精髓后面我会专门讲怎么实现。第四是当前输入。就是用户刚刚发送的这条消息本身加上必要的执行上下文比如当前页面的URL、当前时间。设计这四个部分时最关键的一个经验是给每一部分设定token预算上限。比如一次请求的上下文窗口是8000 token我的分配方案是系统提示词300 工作记忆800 检索记忆2000 当前输入1500 缓冲余量3400。余量是给模型生成回复的空间——很多人忽略了这个结果上下文塞满模型的回复被硬生生截断。2.2 检索记忆的工程细节向量化、分块、重排检索记忆部分是context-mode里技术含量最高的一环它直接决定了模型能想起什么。整个流程可以拆成三个步骤。第一步是切块。历史对话不能整段塞进向量数据库需要切成长度适中、语义完整的小块。我在实践中发现按会话中的轮次切块比按固定字数切块效果好得多。因为一轮完整的对话本身就是一个语义单元——包含了用户问题和模型回复。每一轮对话一个块配上时间戳、会话ID等元信息入库存储。第二步是向量化。就是用一个嵌入模型把文本块变成一组数字向量。这里有一个很容易踩的坑不同嵌入模型的向量空间不兼容而且新模型版本发布后老数据的向量在新模型下检索效果会明显下降。所以选定一个嵌入模型后就尽量不要换如果必须换就得对历史数据做全量重向量化。第三步是重排。我从检索结果里取Top 20的候选块但实际进入上下文的可能只有Top 5。中间这层筛选需要用一个重排模型比如bge-reranker对候选块做一次精细打分。为什么不用向量检索直接取Top 5因为向量检索擅长找语义相似但不擅长判断哪个才是真正需要的。比如用户问我们的服务器还有多久到期纯语义检索可能把服务器部署文档排在最前面但重排模型会意识到用户问的是时间信息把续费相关记录排在前面。这一步老实说是我在经历了无数次检索结果文不对题的折磨后才加上的。2.3 记忆的存取时机什么时候写、什么时候读、什么时候忘context-mode里最容易忽略的是记忆生命周期管理。我发现在项目初期大家都把精力放在怎么存、怎么取上却很少考虑什么时候该忘。先说什么该忘。用户在对话中反复修改需求这种场景早期被否掉的方案就是明确的该忘的信息。继续保留这些内容只会干扰模型的判断。我的处理方法是每轮对话结束后工作记忆区做一次增量更新——新的事实写入、矛盾的事实覆盖、过期的结论清除。这个更新逻辑可以用一小段规则实现也可以用一个小模型跑一次分类但千万别把全量历史摘要当成每次更新的底稿。再说什么时候读。检索记忆的读取时机有两个触发点一是用户的新消息进入时先做一次语义检索召回与当前问题相关的历史片段二是当模型在生成过程中意识到需要回忆更多内容时比如它发现检索结果里缺少关键信息可以触发二次检索。第二种情况实现起来复杂一些需要先让模型生成一部分内容检测到信息缺失后再去补检索。最后说怎么写。我的习惯是先写后查。用户每发来一条消息我先把它写入长期存储向量化入库再基于这条新消息做检索。这样能保证检索结果里包含用户刚刚提到的内容。否则会有一种尴尬的情况用户问我刚说的那件事你怎么没记住模型检索半天发现那条消息还没入库。3. 实操过程与核心环节实现3.1 场景设定做一个记得住旧事的知识库问答Bot讲完理论我用一个实际项目来完整演示context-mode的搭建过程。这个项目的需求是给一个企业内部的运维知识库做一个AI问答Bot要求它能回答技术问题同时能关联对话历史——也就是用户今天聊过的排查过程过几天再来问时还能接上。我当时的选型是Qwen2.5-72B作为主模型上下文窗口32Kbge-large作为嵌入模型bge-reranker作为重排模型向量库用的是Milvus。整个系统设计成三个服务对话服务、检索服务、存储服务。下面我按实现顺序讲。3.2 第一步定义上下文结构体与预算分配我用Python写了上下文的统一数据结构这部分是所有逻辑的地基。核心字段就四个system_buffer、working_memory、retrieved_memory、current_input。from dataclasses import dataclass, field from typing import List, Dict, Optional dataclass class ContextItem: role: str # system / assistant / user / retrieval content: str token_estimate: int 0 dataclass class ContextBundle: 一次LLM请求所需的完整上下文 system_buffer: List[ContextItem] field(default_factorylist) working_memory: List[ContextItem] field(default_factorylist) retrieved_memory: List[ContextItem] field(default_factorylist) current_input: List[ContextItem] field(default_factorylist) # 预算配置单位token budget { system: 400, working: 1200, retrieval: 3000, input: 2000, reserve: 3000, # 留给模型生成的余量 } def as_messages(self) - List[Dict[str, str]]: 组装成OpenAI风格的消息列表 messages [] for item in self.system_buffer: messages.append({role: item.role, content: item.content}) # 工作记忆和检索记忆都作为system角色注入避免干扰多轮对话格式 for item in self.working_memory: messages.append({role: system, content: f[工作记忆] {item.content}}) for item in self.retrieved_memory: messages.append({role: system, content: f[相关历史] {item.content}}) messages.append({role: user, content: self.serialize_input()}) return messages def serialize_input(self) - str: return \n.join([item.content for item in self.current_input])这里有一个非常关键的设计决策工作记忆和检索记忆不以标准的多轮对话形式注入而是以system角色拼接。这样做的原因是多轮对话的user/assistant交替格式会让模型对当前对话的时间线产生混淆它可能把检索出来的历史片段也当作刚发生的对话导致回复时自己跟自己对话的错乱感。标注成[工作记忆]和[相关历史]后模型能明确区分系统提供的资料和用户实际说的话。预算分配上总窗口是32K token但我只分配了大约9600 token给上下文内容剩下22000留给模型生成长回答。实践里很多项目就是把上下文塞得太满模型回复经常在半路被截断。3.3 第二步工作记忆的更新机制工作记忆是context-mode里更新最频繁的部分。我给它定了三条规则新增规则用户消息中出现新的实体如服务器IP、订单号、人员姓名立即写入工作记忆。更新规则同一主体的事实发生变化时覆盖旧值。比如用户先说我们计划用Nginx两分钟后又说算了还是用Apache工作记忆里Nginx这条就要被覆盖。过期规则对话结束且用户没有明确要求保留时工作记忆在24小时后清空。实际实现时我用了两招来识别实体和事实。第一招是正则词典匹配做粗筛把IP、端口、日期、订单号这类结构化信息抽出来第二招是用一个轻量的NLP模型做关系抽取识别用户偏好环境限制这类非结构化事实。这个抽取逻辑跑在每个用户消息上但为了控制延迟我用的是异步处理——先让对话正常进行抽取任务在后台跑下一轮对话开始时新事实就已经进内存了。写工作记忆时还有个细节每个条目都带上写入时间和来源消息ID。这样如果检索结果和当前输入产生矛盾模型可以参考时间信息判断哪个才是最新的。这个设计帮我在用户临时改需求的场景下避免了不少错误回复。3.4 第三步检索记忆的组装与rerank检索的触发写在了对话服务的请求处理链路里。核心代码如下def build_retrieved_memory(query: str, top_k: int 5) - List[ContextItem]: 从向量库召回并重排返回最终进入上下文的记忆块 步骤 1. 拼接用户当前问题 工作记忆中的关键实体作为检索query 2. 向量检索召回候选top 20 3. rerank精排取top 5 4. 按时间逆序排列最近的排最前 # 1. 构造检索查询 query_compose query if working_entities: query_compose 相关实体: , .join(working_entities) # 2. 候选召回 candidates vector_store.search( queryquery_compose, top_k20, collectionconversation_history, filters{is_deleted: False} ) # 3. 重排 reranked rerank_model.rerank(query_compose, candidates) final_items reranked[:top_k] # 结合时间戳和分数进一步筛选 # 4. 组装 memory_items [] for item in final_items: metadata item.metadata memory_items.append( ContextItem( rolesystem, content( f[{metadata.get(timestamp,)}] f用户: {item.content.get(user_message,)}\n f回答: {item.content.get(assistant_message,)} ), ) ) # 倒序让更近的对话排在前面 memory_items.reverse() return memory_items检索阶段的调优经验query不是直接拿用户原话而是要和工作记忆里的实体做个拼接。用户可能只说继续排查但这个继续指的具体是哪个服务器的哪个问题必须从工作记忆里找。我在第一次上线时没做这一步结果就是用户说那明天再试一次吧系统检索出完全无关的历史——因为明天在向量空间里什么都匹配不到。重排之后还有一个时间排序的逻辑这一点很多人不注意历史对话按时间倒序排列。模型对越靠后的内容注意力越高近因效应所以相距较近的对话放最后让模型优先看到最近发生的事情。3.5 第四步token开销统计与动态裁剪最后一步是整个系统中我觉得最工程实用的部分动态裁剪。因为LLM的token数量不能精确预知检索出来的记忆块可能超预算。我写了一个裁剪器按优先级从低到高删减内容。def trim_to_budget(items: List[ContextItem], max_tokens: int) - List[ContextItem]: 按优先级裁剪检索记忆块可按时间裁剪留最新的工作记忆按规则裁剪留实体匹配度高的 total sum(item.token_estimate for item in items) if total max_tokens: return items # 对检索记忆块优先保留与当前query相关性高的 if items and items[0].role system: for item in items: if [相关历史] in item.content: # 这里假设items已按相关性和时间排序 pass # 简化处理超过预算就逐步丢弃最旧的检索记忆 trimmed [] budget_used 0 for item in items: if budget_used item.token_estimate max_tokens: trimmed.append(item) budget_used item.token_estimate else: break return trimmed实际使用时这个函数只作为兜底策略。正常情况下我把检索预算定成3000 token按每一轮对话含用户问题和模型回答大约500-800 token计算能放进约4-6轮历史对话。如果单轮内容特别长就截断到最大长度而不是整块丢弃这部分我用的是按字符数截断加省略号避免把一句完整的话腰斩。4. 常见问题与排查技巧实录4.1 上下文溢出明明有32K系统却频繁报错我遇到的第一大类问题就是上下文溢出。表现是应用刚开始运行正常几轮对话之后开始报错提示maximum context length exceeded。这种问题的排查思路很重要第一反应不是去减小上下文而是先确认token从哪里消耗的。我在项目里加了一个可观测性面板每次请求都把四个部分的token统计打点。结果发现检索记忆经常出现取回了大量单轮超长对话的情况——比如用户粘贴了一整段报错日志到对话里这一轮就占了2500 token。这时单纯的减少召回数量没用因为召回量减到2条也可能超预算。真正有效的方案是做内容级截断把超长的历史对话按语义切分成更小的子块入库时每个子块控制在300-400 token。检索时召回的是子块而不是整轮对话显著降低了单条体积。另外我还在裁剪器里加了一个睡眠检测如果某轮对话的全部子块在最近5次检索中都没有被召回就给它打上低热度标记后续检索时优先剔除。4.2 张冠李戴模型把A会话的记忆用到了B会话这是context-mode里最危险的问题。一开始我做了一个很粗糙的设计按照用户ID隔离会话但不同会话之间共享了一部分全局知识库——就是运维文档的向量集合。结果出现了一种诡异的现象用户问ks8集群怎么扩容系统把另一个用户在另一个会话里问K8s证书过期的排查记录也检索出来还煞有介事地混进回答里。排查时我用了一个笨办法把每次查询的实际检索结果打印出来看。结果发现检索模块的正确率其实不低问题出在进入上下文后模型无法区分全局知识库内容和私有历史内容。因为两者都是[相关历史]前缀。修复方案是给记忆块打明确的类型标签。我用[文档知识]标注来自运维文档的检索块用[对话记录]标注来自用户历史会话的检索块。同时在提示词里专门加了一句仅当用户明确要求回忆旧对话时才可结合[对话记录]内容回答否则只使用[文档知识]和当前输入。这个改动虽然简单但模型输出的串味情况几乎绝迹了。4.3 模式切换的坑长对话结束后残留记忆干扰新会话第三个典型问题是会话切换时的记忆残留。用户开了一个新会话本意是想问一个全新的问题但系统因为对话历史包含相同关键词而检索出旧会话记录导致模型一开口就提旧事。这个体验非常尴尬。这里我给检索模块加了一个**热启动开关**新会话的前两轮对话检索范围只覆盖全局知识库不包含历史会话当新会话中出现了三个以上与旧会话重叠的实体比如同一台服务器IP、同一个订单号才自动开放历史记忆的检索。这个机制避免了新对话刚开始就被历史绑架的问题。另外还处理了一个极端场景用户在旧会话里明确说了这个问题作废重新来。当时我没有把旧会话打上失效标记结果下次对话又把作废的内容检索出来。现在我在工作记忆里维护一个已废弃主题列表检索时排除这些内容。4.4 检索结果看似相关实则无用的优化技巧这类问题最让人头疼——检索返回的内容听起来很相关但模型就是没法直接用。比如用户问证书过期了有什么影响检索出来的是证书过期会导致无法建立安全连接需要及时更换。这句是对的但完全没回答影响的细节。重排模型打分时因为字面上匹配度高反而给了高分。我的解法是引入**答案型检索**的思路入库时给每个记忆块增加了标签字段包括问题类型比如故障排查、概念解释、操作步骤和解决状态已解决/未解决。检索时不只看语义相似度还做标签过滤。用户问影响时优先召回包含影响字眼的文本块用户问怎么修时则优先召回想操作步骤标签的文本块。这实际上是把知识库的元信息用起来了检索质量提升非常明显。5. 一点个人感悟写了这么多回到最初的问题context-mode到底是什么我觉得它本质上是一种谦逊的做法——承认模型的上下文窗口是有限的承认上下文越长效果越差然后用工程手段去适配这个物理约束。我这套方案不是银弹。如果你的场景是单轮问答、上下文不会累积那根本不需要context-mode直接滑窗截断就行。但如果你的应用需要记住用户说过的话、需要跨会话关联信息、需要在有限的窗口里塞进最多有效内容那这套分层记忆动态检索预算控制的框架应该能帮到你。最后分享一个小技巧上线前用真实用户对话历史做一遍回放测试。把用户几周内的真实对话导出来模拟新会话从日志里检索检查每条记忆的准确率和利用率。这事我每次项目都做比任何单元测试都管用。回放测试做几轮之后你会发现模型回复的整体质量曲线会有非常明显的提升——因为上下文每一寸空间都被花在了该花的地方。