1. 上下文管理到底在管什么第一次听到“上下文管理”这个词很多人会下意识觉得这是个大模型或者AI应用才有的概念。其实不然。只要你的系统需要在多次交互之间保持状态、需要在有限的资源里塞进尽可能多的有效信息、需要在不同模块之间传递“当前正在发生什么”的认知你就在做上下文管理。它不是一个具体的框架或工具而是一类问题的统称。我最早接触这个概念是在做一个多轮对话系统的时候。当时遇到的核心问题是用户聊到第十轮模型已经忘了第三轮说过的关键信息但如果把十轮对话全部塞进去响应速度又慢得没法用。这就是典型的上下文管理问题——信息量无限增长但处理窗口有限。后来我发现同样的逻辑出现在很多场景里代码编辑器要管理打开的文件和光标位置游戏引擎要管理场景中所有对象的状态甚至一个客服工单系统也要管理用户的历史操作记录。所以这篇文章想聊的是我在实际项目中踩过坑、试过方案、最终沉淀下来的一套上下文管理思路。它不绑定某个特定平台或框架更多是关于怎么想、怎么选、怎么落地的经验。如果你正在做对话系统、Agent应用、状态机驱动的业务系统或者任何需要“记住之前发生了什么”的项目这些内容应该能直接拿来参考。核心关键词就一个上下文管理。但围绕它展开的是窗口分配、优先级排序、压缩策略、持久化方案、检索增强这一整套工程实践。下面我按实际做项目的顺序从设计思路到落地细节再到问题排查一层层拆开讲。2. 整体设计思路与方案选型2.1 先搞清楚上下文的三个层次在动手写任何代码之前我习惯先把上下文拆成三层来看这个习惯帮我避免了很多返工。第一层是即时上下文也就是当前这一轮交互直接依赖的信息。比如用户刚说的那句话、刚点击的按钮、刚上传的文件。这层信息的特点是时效性极强但生命周期极短通常处理完就可以丢弃或归档。第二层是会话上下文指的是当前这次会话session内积累的信息。比如用户在前面几轮提到的偏好、已经确认过的参数、系统已经执行过的操作。这层信息需要在会话期间保持可用但会话结束后不一定需要长期保留。第三层是长期上下文跨会话甚至跨用户存在的知识。比如用户的画像、历史行为模式、领域知识库。这层信息量最大但单次交互中真正用到的只是其中一小部分。为什么要分这三层因为它们的存储介质、检索方式、更新频率完全不同。即时上下文放内存里就行会话上下文可能需要Redis或类似的高速缓存长期上下文则往往要落到向量数据库或关系型数据库里。如果不分层把所有信息混在一起管理后期维护会非常痛苦。我见过不少项目一开始把所有上下文都塞进一个JSON对象里传来传去前两周跑得挺好到第三周字段膨胀到上百个没人敢删任何一个因为不知道哪个还有用。分层管理就是解决这个问题的。2.2 窗口预算把token当钱来花如果你做的是基于大模型的系统那上下文窗口就是你的预算。每一轮交互你都有固定的token额度怎么分配直接决定了系统的智能程度和响应成本。我的做法是给窗口做预算分配。假设总窗口是8000 token我会大致这样切用途预算占比说明系统指令10%角色设定、输出格式要求、安全约束长期知识20%从知识库检索回来的相关片段会话历史40%最近N轮对话的摘要或原文即时输入20%用户当前这句话及相关附件输出预留10%留给模型生成回复的空间这个比例不是固定的要根据场景调。比如客服场景可能长期知识占比要提高到30%因为产品信息很重要而创意写作场景可能会话历史占比要加大因为风格连贯性更关键。关键原则是永远不要让你的输入把窗口占满。我踩过的坑是早期做对话系统时把历史对话全部原样塞进去结果用户说了一句很长的话直接超限报错。后来改成动态裁剪根据当前输入的长度反推历史部分能用多少预算就再也没出过这个问题。2.3 压缩策略摘要、抽取还是丢弃上下文不可能无限增长所以必须有压缩机制。我试过三种主流策略各有适用场景。摘要压缩是把多轮对话用模型总结成一段简短的话。优点是信息密度高缺点是会丢失细节而且摘要本身也要消耗一次模型调用。适合对话轮次多、但细节不那么重要的场景。抽取压缩是从历史中只提取关键实体和意图比如“用户提到了北京、三天、预算5000”。优点是结构化、好检索缺点是会丢失语气和上下文关联。适合任务型对话。滑动窗口丢弃最简单就是只保留最近N轮旧的直接扔掉。优点是零成本缺点是可能丢掉重要信息。适合对历史依赖不强的场景。实际项目中我通常是组合使用最近3-5轮保留原文更早的做摘要再早的只保留抽取出的关键实体。这样在有限预算里能覆盖尽可能长的时间跨度。2.4 检索增强让长期知识按需进入长期上下文不可能全部塞进窗口所以需要检索。这里的关键是检索的时机和粒度。我的做法是在每一轮用户输入进来后先用一个轻量级的意图识别或关键词提取判断是否需要查长期知识。如果需要再用向量检索或关键词检索召回Top-K个片段经过重排序后取最相关的几条放入窗口。粒度控制很重要。如果召回的是整篇文档可能一条就把窗口占满了如果召回的是单句话可能信息不完整。我一般按段落或固定长度切块每块200-500字召回后再根据相关性分数截断。有个细节容易被忽略检索回来的内容要标注来源和时间。这样模型在引用时能区分“这是用户刚说的”还是“这是知识库里的旧信息”避免把过时信息当成当前事实。3. 核心细节解析与实操要点3.1 会话状态的存储结构设计上下文管理的底层是状态存储。我推荐用分层键值结构来组织而不是一个大平铺的字典。具体来说会话状态可以这样设计{ session_id: xxx, created_at: timestamp, immediate: { last_user_input: ..., last_intent: ..., pending_slots: {} }, session: { turn_count: 12, summary: 用户正在咨询退款流程..., key_entities: [订单号123, 退款, 三天内], recent_turns: [] }, long_term_refs: { user_profile_id: xxx, retrieved_knowledge: [] } }这样分的好处是每一层可以独立设置过期时间和存储介质。immediate放内存session放Redis并设置30分钟过期long_term_refs只存引用ID实际数据在外部数据库。实操中要注意不要存原始对话全文在session里。我见过把每一轮完整对话都append到一个数组里的做法跑一天下来单个session能到几MB。正确做法是只存最近几轮的原文更早的存摘要或只存实体。3.2 窗口裁剪的具体算法窗口裁剪不是简单地“保留最近N条”而是要根据token预算动态计算。我常用的算法逻辑是这样的先计算系统指令和输出预留的固定开销得到可用预算。把即时输入放进去计算剩余预算。从最近一轮开始往前遍历会话历史逐轮累加token数直到接近预算上限。如果还有剩余预算用检索增强填充长期知识。如果预算不够对最早的那轮做摘要压缩腾出空间。这里有个经验值单轮对话的token数波动很大用户可能发一句话也可能贴一整篇文档。所以遍历时要留10%-15%的缓冲不要卡得太死。另外裁剪的边界要尽量落在完整轮次上不要把一轮对话从中间切断。如果实在放不下宁可整轮丢弃或整轮摘要也不要半截截断否则模型会困惑。3.3 摘要生成的触发时机与质量控制摘要不是每轮都做那样成本太高。我的触发条件是当会话历史超过窗口预算的60%时对最早的那部分做一次摘要。摘要的质量控制有几个要点保留实体和数字摘要里必须包含用户提到的具体名称、时间、数量这些是最容易在压缩中丢失但最重要的信息。保留意图和状态用户想做什么、已经做到了哪一步这两个信息必须保留。控制长度摘要长度建议在原文的20%-30%之间太短丢信息太长没意义。可追溯摘要要记录它覆盖了哪几轮对话方便需要时回查原文。我一般用一个小模型来做摘要成本低且够用。如果对质量要求高可以用大模型但设置更严格的prompt约束。踩过的坑早期摘要prompt写得太宽松模型把摘要写成了“用户和助手进行了友好交流”完全没用。后来改成强制要求“必须包含以下字段用户目标、已确认信息、待办事项”质量才稳定下来。3.4 多轮对话中的指代消解上下文管理里最容易被低估的难点是指代消解。用户说“它”、“那个”、“刚才说的”系统必须知道指的是什么。我的做法是在每轮输入进入窗口之前先做一次指代替换。具体来说维护一个最近提到的实体列表当检测到代词时用最近匹配的实体替换掉。比如用户先说“我想退订单123”后来说“它什么时候能到账”系统要把“它”替换成“订单123的退款”。这个替换不需要很复杂基于规则的最近匹配就能解决80%的情况。剩下的20%可以用模型辅助判断。关键是替换后的文本再进入窗口这样模型看到的就是明确的表述不需要自己去猜。3.5 上下文版本管理与回滚在复杂系统里上下文是会变的。用户可能说“不对我刚才说错了应该是后天不是明天”。这时候需要能回滚到之前的状态。我的做法是给会话状态加版本号每次修改前先快照。回滚时恢复到指定版本。快照不需要存全量存diff就行节省空间。这个机制在调试时特别有用。当发现模型输出不对时可以回放上下文的变化过程定位是哪一步的信息出了问题。4. 实操过程与核心环节实现4.1 从零搭建一个上下文管理模块假设我们要为一个对话系统实现上下文管理下面是我实际用过的搭建步骤。第一步定义数据模型。先确定会话状态的结构参考3.1节的JSON设计。用Pydantic或类似工具做类型校验避免字段缺失或类型错误。第二步选择存储介质。即时上下文用进程内字典会话上下文用Redis设置TTL长期知识用向量数据库。如果规模小可以先用SQLite过渡但接口要抽象好方便后续替换。第三步实现窗口管理器。核心是一个函数输入是当前会话状态和用户新输入输出是组装好的prompt。这个函数内部完成预算计算、历史裁剪、检索增强、指代消解。第四步接入摘要服务。当触发条件满足时异步调用摘要生成更新会话状态。注意要加锁避免并发写冲突。第五步加监控和日志。记录每轮的实际token消耗、裁剪了哪些内容、检索召回了什么。这些日志是后续优化的依据。4.2 关键参数的计算与选择窗口预算的具体数值怎么定我一般这样算假设模型支持128K token但实际使用中我不会用满。经验值是用到60%-70%留出余量应对突发长输入。所以有效预算约80K。然后按2.2节的比例分配系统指令8K长期知识16K会话历史32K即时输入16K输出预留8K。会话历史32K能放多少轮按平均每轮500 token算大约60轮。但实际中我会把最近10轮保留原文约5K更早的做摘要压缩到2K左右这样能覆盖更长时间。这些数字不是死的要根据实际日志调整。我通常跑一周后看统计如果发现经常触发裁剪说明预算偏紧如果窗口利用率长期低于50%说明可以放宽。4.3 检索增强的接入细节检索增强的接入分三步索引构建把长期知识按段落切块每块200-500字用embedding模型转向量存入向量数据库。切块时注意保留上下文比如每块开头加上所属文档的标题。查询构造用户输入进来后不是直接拿原始文本去检索而是先做一次查询改写。比如用户说“这个怎么退”改写成“退款流程 操作方法”。改写可以用小模型做也可以用规则模板。结果融合召回Top-10后用重排序模型精排取Top-3放入窗口。放入时要加来源标注比如“[知识库-退款政策] 退款将在3-5个工作日到账”。实测下来查询改写这一步对召回质量影响很大。不做改写直接检索准确率大概60%做了改写能到85%以上。4.4 并发场景下的上下文隔离如果系统要同时服务多个用户上下文必须严格隔离。我的做法是每个会话有唯一的session_id所有存储操作都带这个ID。Redis的key用session:{session_id}:state的格式天然隔离。内存中的即时上下文用线程本地存储或异步上下文变量避免串号。摘要和检索服务要无状态所有状态通过参数传入。有个容易忽略的点异步任务的上下文传递。如果摘要生成是异步的要确保它拿到的是正确的会话快照而不是共享的可变对象。我一般传不可变的副本进去。4.5 性能优化减少不必要的模型调用上下文管理本身也会消耗资源尤其是摘要和检索。优化方向有几个缓存检索结果同样的查询在短时间内重复出现直接返回缓存。摘要延迟生成不阻塞主流程后台异步做下一轮再用。批量处理多个会话的摘要任务可以合并成一次模型调用。降级策略如果摘要服务超时直接丢弃最旧的历史保证主流程可用。我实测过加了缓存之后检索相关的模型调用减少了约40%整体响应时间下降了15%左右。5. 常见问题与排查技巧实录5.1 模型“忘记”了之前说过的关键信息这是最常见的问题。排查思路首先看日志确认那条信息是否还在窗口里。如果被裁剪了说明预算分配或裁剪策略有问题。如果还在窗口里但模型没用到可能是信息被淹没在大量无关内容中。解决方法提高关键信息的优先级。我一般会给用户明确确认过的信息打标记裁剪时优先保留。另外在系统指令里加一句“请特别注意用户已确认的以下信息...”能显著提升模型对关键信息的关注度。5.2 上下文越长响应越慢这是必然的但可以优化。排查方向检查是否有重复内容。我见过历史里同一句话出现三次的情况是去重没做好。检查检索召回是否过多。Top-10和Top-3的响应时间差很多但效果可能差不多。检查摘要是否及时触发。如果等到窗口快满了才摘要那之前几轮就已经很慢了。5.3 多轮之后回答开始跑偏这通常是上下文污染导致的。比如早期的一轮里模型理解错了这个错误被摘要保留下来后续越滚越大。解决方法在摘要prompt里加一条“如果发现之前有理解错误请在摘要中标注并纠正”。另外定期做一次全量重摘要而不是增量摘要能减少误差累积。5.4 常见问题速查表问题现象可能原因排查动作解决方向模型忘记关键信息被裁剪或淹没查日志确认信息位置提高优先级、加系统提示响应越来越慢上下文膨胀统计token增长曲线及时摘要、去重、限制召回数回答跑偏上下文污染回放上下文变化全量重摘要、纠错标注指代错误消解失败检查实体列表改进替换规则、加模型辅助并发串号隔离不严检查session_id传递严格隔离存储和异步任务摘要质量差prompt太宽松检查摘要输出强制字段约束、小模型专用5.5 几个我踩过的坑坑一把上下文管理当成纯技术问题。实际上它有一半是产品问题——哪些信息重要、保留多久、精度要求多高这些需要和产品侧对齐。我早期自己拍脑袋定策略后来发现和业务预期不符返工成本很高。坑二过度依赖模型做压缩。模型摘要确实方便但成本和延迟都高。后来我把很多压缩逻辑改成规则化的比如只保留实体和意图效果差不多但快很多。坑三忽略冷启动。新会话没有任何历史检索增强就成了主要信息来源。如果检索没做好第一轮体验就很差。所以检索的优化优先级其实很高。坑四没有做上下文的可视化。调试时只能看日志很痛苦。后来我做了个简单的页面把每轮的窗口内容、裁剪决策、检索结果都展示出来排查效率提升了好几倍。6. 进阶让上下文管理更智能的几个方向6.1 基于重要性的动态保留不是所有历史都同等重要。我在后来的项目里尝试给每轮对话打重要性分数依据包括是否包含用户确认、是否包含数字或实体、是否是任务关键步骤。裁剪时按分数排序而不是单纯按时间。这个做法的效果很明显同样预算下关键信息的保留率提升了约30%。分数可以用规则算也可以用一个小模型预测。6.2 上下文的分支与合并有些场景下用户会同时进行多个话题。比如一边问退款一边问发票。这时候上下文需要分支管理每个话题独立维护历史避免互相干扰。实现上可以用话题ID做区分每个话题一个子上下文。当用户切换话题时切换到对应的子上下文。合并则发生在话题收敛时比如两个话题都指向同一个订单。6.3 跨会话的上下文继承用户下次回来时如果能继承上次的关键信息体验会好很多。但不是全部继承而是有选择地继承。我的做法是只继承长期实体和未完成的任务比如“上次你咨询的退款还在处理中”。这需要长期上下文的存储和检索配合实现上比单会话复杂但价值很高。6.4 上下文管理的可观测性最后想强调可观测性。上下文管理是个黑盒如果不加监控出了问题很难定位。我建议至少监控这几个指标每轮的实际token消耗和预算利用率裁剪触发频率和被裁剪的内容类型摘要的生成频率和质量评分检索的召回率和相关性分布指代消解的成功率这些指标能帮你提前发现问题而不是等用户投诉了才去查。我个人在实际操作中的体会是上下文管理没有一劳永逸的方案它需要随着业务变化不断调整。但只要你把分层、预算、压缩、检索这几个核心机制搭好后续的优化就是调参数的事不会伤筋动骨。另外别追求一步到位先跑通最小闭环再根据实际日志逐步优化比一开始就设计复杂架构要靠谱得多。