context-mode实战指南：AI应用上下文管理与记忆分层优化

1. 为什么我建议每个做 AI 应用的人都认真对待 context-mode做 AI 应用开发这几年踩过最大的坑不是模型选型也不是 Prompt 写不好而是“上下文”管理一团糟。很多人一开始觉得把用户的历史消息一股脑塞给大模型就完事了结果 ChatGPT 这类产品看着挺聪明自己做出来的应用却像个“金鱼脑”——问两句就忘问多了还乱答。真正的问题出在 context-mode也就是上下文管理模式上。这个关键词看着专业说白了就是一句话你要以什么方式、把哪些历史信息、以什么形态喂给模型。它决定了你的应用是“记得住”还是“记不住”是便宜还是贵是流畅还是卡顿。我最早是在做一个客服机器人的时候被逼着认真研究 context-mode 的。当时用户抱怨最多的就是“为什么我前面说过的地址它记不住”我一看日志发现我把最近 20 轮对话全部塞进 Prompt结果模型确实“记住”了地址但每轮请求的 token 数暴涨响应时间从 1 秒变成 4 秒月底账单更是吓人。后来我花了三周时间重构上下文管理把 context-mode 从单一的全量模式改成“短期窗口 摘要沉淀 关键实体抽取”的组合模式效果立刻不一样了响应快了一半成本降了 40%用户满意度反而上来了。这篇内容就是想把我在 context-mode 上的完整理解、设计思路、落地代码和踩坑记录都写出来。适合正在做对话机器人、AI Agent、知识库问答或者任何需要“长期记忆”的 AI 应用的开发者参考。里面没有玄学只有可以抄作业的方案。1.1 先把 context-mode 的本质说透context-mode 不是某个框架里的一个开关而是一整套关于“模型输入上下文”的组织哲学。它回答的核心问题有三个第一保存哪些信息第二用多长的信息窗口第三以什么粒度、什么形态把信息重新组织后送给模型我拿人来做类比。你和朋友聊天的时候不会把相识以来的每句话都在脑子里回放一遍再回答对方。你会有选择地调用记忆最近几轮聊天的细节记得最清楚更早的事情你只会记得大概意思。如果聊到某个关键人物你会从长期记忆里把他拎出来补充这个人的背景。“金鱼脑”就是只保留最近几轮而把所有历史都塞给模型等于让一个短时记忆容量有限的人强行背下整本聊天记录他一定会消化不良模型也一样。所以 context-mode 本质上是在模拟人的记忆分层机制。基础的单轮模式只关心当前这句用户输入多轮模式开始维护一个短期对话缓冲区再往上走就涉及把历史对话做摘要、提取结构化信息、建立向量索引这些更精细的手段。每一层解决不同问题也付出不同复杂度的代价。理解了这个就不会被各种高级名词绕晕。1.2 context-mode 的典型适用场景不同业务对上下文的需求差异非常大。在线问答这种“一问一答”场景理论上甚至可以不做上下文管理但一旦涉及多轮信息确认、用户信息收集、形态持续变化的业务状态context-mode 就成了刚需。我整理下来最适合采用完整 context-mode 方案的场景有这三类客服机器人 / 销售助理用户会持续补充诉求比如“我再加一个 XX 型号的报价”“刚才那个地址改成另一个”模型必须记住前面说了什么还要能识别改的是哪一部分。AI Agent / 多步骤任务代理Agent 拆解任务、调用工具、返回结果整个过程会产生大量中间数据。如果上下文管理不好Agent 会在中途忘记原目标产生“做着做着跑偏了”的现象。个性化陪伴 / 角色扮演这类应用要求模型记住用户的姓名、偏好、人生经历等长期信息而且对话往往持续几个月甚至更久。光靠滑动窗口根本不可能必须引入长期记忆机制。如果你发现自己做的应用“偶尔聪明、经常失忆”大概率不是模型不行而是 context-mode 根本没设计。2. context-mode 的核心设计记忆分层与信息取舍真正开始设计 context-mode 之前有一件事你必须先想明白你要让模型记住哪些东西以及你打算为这些“记忆”付出多少 token 成本。这两件事直接决定了你的技术选型。我见过很多团队一上来就搞向量数据库做得很重结果业务场景根本不需要那么深的记忆。我也见过不少单机小应用全靠暴力拼接上下文最后被成本压垮。我的建议是先按“记忆层次”拆解需求再决定每一层用什么手段实现。这套思路是我在生产环境验证过无数轮的骨架也是理解后续所有代码实现的基础。2.1 第一层短期会话窗口相当于人的“工作记忆”短期会话窗口是最直观的 context-mode。实现上通常是一个 deque 或者 list保存最近 N 轮用户消息和助手回复。轮到新请求时把窗口里的消息与当前输入拼在一起作为 Prompt 发给模型。为什么不能无限加大 N因为 token 限制和响应延迟双双制约着你。我实测过GPT-4 类模型在 Prompt 超过 3000 token 之后首字延迟肉眼可见地增加。另外窗口过大还有个隐蔽问题模型对 Prompt 中部的信息注意力最弱这个在行业里叫“lost in the middle”。历史信息被淹没在超长的 Prompt 中间模型要么忽略它要么产生幻觉反而比不提供更糟。所以短期窗口的 token 预算我一般控制在总上下文窗口的 30%-50% 之间。比如模型支持 8K 上下文留给短期窗口的只在 2K 到 4K 左右剩下的留给当前指令、工具结果和摘要。具体数字看你的业务形态纯闲聊可以放更多历史需要大量工具调用结果的历史就得让路。这里给一个可参考的窗口设计思路最近 1-2 轮完整保留原文因为用户通常会在这里做轻微修正漏了细节就接不上中间 8-10 轮优先保留与当前主题相关的部分不相关的按时间顺序淘汰更早的内容只保留摘要或者关键实体不进入短期窗口2.2 第二层会话摘要相当于人的“情节记忆”摘要模式是我陆陆续续推荐给所有要做长期对话的团队的方案。它解决的问题很朴素历史太长了放不下那我们就让模型把历史压成一段话。具体做法是每经过一定轮数我常用 6-8 轮触发一次摘要更新。把旧的历史消息和上一版摘要一起发给模型要求它提炼出仍然重要的信息生成新摘要。下次请求时不再携带原始历史而是只携带这份摘要。这里有一个关键细节很多人会做错摘要不是“重写一遍”而是“增量合并”。你每次都要把旧摘要拿出来让模型看完旧摘要和新对话后输出“仍然重要的旧信息 值得记录的新信息”。否则摘要会一直丢东西聊到后面模型连用户叫什么都不记得了。我踩过一个大坑一开始让模型只对“新对话”做摘要不加旧摘要进去。结果用户在第 30 轮问“还记得我一开始说的使用场景吗”模型一脸茫然。后来改成增量合并把旧摘要作为输入的一部分模型才能把早期关键信息一直带下去。摘要在 context-mode 中的定位是“把握全局”而非“精确复述”。它牺牲了细节换来了超长对话的可行性和可控的 token 消耗。如果你的应用需要精确记住用户说过的一串数字、一个具体地址摘要是做不到的那就需要下面这层——关键实体抽取。2.3 第三层关键实体与结构化记忆相当于人的“语义记忆”实体抽取是我在 context-mode 里最推荐投入的一层。它跟摘要不冲突反而是互补关系。摘要负责“记住大概”实体负责“钉死关键”。常见的做法是从每轮对话中抽取出结构化信息比如姓名、地址、日期、商品编号、偏好、价格上限等存成 JSON 或者键值对。每次生成请求时把这些实体信息作为前置背景注入 Prompt。好处非常明显。你不需要在摘要里反复强调“用户地址是北京朝阳区 XX 路 88 号”只要在第一次出现时抽出来之后每轮请求都带上这份结构化的用户画像即可。不仅准确而且 token 占用极低。我在一个电商售前机器人项目里就用了一个简单的规则正则 LLM 二次校验把用户提到的商品型号、预算区间、收货城市全部抽出来。效果是对话进行到第 20 轮模型还能准确说出“用户想看的是 E5 系列的 1TB 款预算 7000 左右人在上海”。这是纯摘要模式很难做到的。实体抽取的设计难点在于实体的时效性。比如用户先说“预算 5000”后来又改成“预算可以到 8000”。你需要决定是覆盖旧值还是保留历史轨迹。我的经验是分两类处理一类是稳定属性姓名、城市、爱好直接更新覆盖一类是动态状态当前预算、当前目标型号必须保留旧值的同时标记新值让模型能理解这是更新不是矛盾。2.4 三种模式的选型策略别一上来就全都要选型策略这件事我见过太多反向案例了。有人做个天气查询机器人愣是上了向量数据库加长期记忆维护成本高到吓人。也有人做高复杂度的工作流 Agent却只用最简单的滑动窗口导致 Agent 频繁失忆。我的建议是根据“对话时长的需求”和“信息精度需求”两个维度来选型分辨出自己到底需要哪种 context-mode场景特征推荐 context-mode 组合理由单轮问答、无状态工具调用不管理或仅最近 1 轮不需要记忆省 token 省延迟常规客服、多轮信息确认短期窗口 实体抽取用户会补充/修改信息钉死关键实体最重要超长对话、叙事型应用滑动窗口 增量摘要 实体抽取长期记忆必须分层缺一不可Agent 多次工具调用短期窗口 完整的工具调用记录结构重点是任务状态不是用户闲谈我现在做新项目默认起步方案永远是“短期窗口 摘要 实体抽取”三层组合但每一层的容量和触发频率会根据业务调。比如纯内容创作助手实体抽取可以弱一点CRM 类应用实体抽取就是命根子。等跑起来有真实数据了再优化每一层的参数。3. 手把手实现一个可用的 context-mode 管理器理论讲完接下来是实操。我会带着你从零实现一个轻量的 context-mode 管理器支持短期窗口、增量摘要、实体抽取三层能力。不用任何重量级框架核心依赖就是 Python 3.9 和 OpenAI SDK有能力的可以平替到任意大模型接口。整个代码可以直接抄走改。为了让代码有真实感我下面用一个“家政服务预约机器人”作为示例场景。用户会和机器人多次对话约定服务时间、地点、服务项目中途还会改时间。你看完代码后可以把这个场景换成任意你正在做的业务。3.1 设计数据结构会话对象是 context-mode 的基石不管用哪种 context-mode你都需要一个统一的数据结构来承载会话状态。我在生产环境里通常把它定义成一个 Session 对象包含以下核心字段session_id会话唯一标识messages短期窗口内的消息列表每项包含 role 和 contentsummary历史对话的滚动摘要memory从对话中抽取出的关键实体/用户画像以 JSON 存metadata其他业务需要的状态信息这样整个 context-mode 的状态就收敛到一个对象里。无论是存 Redis、存数据库还是多机共享状态都只用序列化这一个对象就行。3.2 基于 token 预算的上下文组装逻辑组装上下文是整个 context-mode 的核心调度环节。我的做法是先定总预算再按优先级分配。假设模型上下文上限是 8000 token我会做这样的预算分配系统指令固定 800 token角色设定、回复格式等实体记忆固定 300 tokenJSON 结构注入工具/检索结果最多 1500 token如果有近期对话窗口最多 2500 token历史摘要在剩余空间中自适应一般给到 800-1200 token这段逻辑用代码写出来是这样class ContextModeManager: def __init__(self, max_tokens8000): self.max_tokens max_tokens self.system_prompt 你是家政服务预约助手负责收集用户的服务需求。 self.short_term_window [] # 短期窗口消息 self.summary # 历史摘要 self.memory {} # 关键实体 self.tokenizer self._get_tokenizer() def build_context(self, current_input): 组装发给模型的完整消息列表按优先级分配 token budget self.max_tokens - 800 # 预留给系统指令 # 第一优先级实体记忆 memory_payload self._format_memory(self.memory) budget - self.tokenizer(memory_payload) # 第二优先级短期窗口自适应截断 window_messages self._fit_window_into_budget( self.short_term_window, budget ) # 第三优先级历史摘要 summary_payload self._fit_summary_into_budget(self.summary, budget) return [ {role: system, content: self.system_prompt}, ] summary_payload window_messages [ {role: user, content: current_input} ]这段代码的核心思路是按优先级裁剪而不是按先后顺序裁剪。实体记忆永远不丢短期窗口优先保留最近几轮摘要实在放不下了才截断。我试过反过来先放摘要后放窗口模型对最近内容的敏感度会下降不少遇到用户临时改需求就容易出错。3.3 增量摘要的触发时机与更新实现摘要更新不是每轮都做的那样既浪费 token 又破坏上下文连续性。我的生产经验是当短期窗口内的消息总 token 数超过阈值时触发一次摘要合并。阈值我通常设为短期窗口预算的一半比如预算 2500 token那么窗口超过 1250 就触发。更新摘要时把旧摘要和当前窗口内的全部消息拼起来让模型产出一个新的摘要。这段逻辑的实现def update_summary(self): 增量摘要旧摘要 新消息 - 新摘要 if not self.short_term_window: return merge_prompt f 这是此前的对话摘要 {self.summary if self.summary else 无} 这是最近几轮的新消息 {.join( f{m[role]}: {m[content]}\n for m in self.short_term_window )} 请生成一份更新后的摘要。要求 1. 保留此前摘要中仍然重要的信息 2. 把新消息中的重要信息合并进来 3. 用简洁的中文概括100字以内 new_summary self._call_llm(merge_prompt) self.summary new_summary self.short_term_window [] # 窗口清空等待新一轮积累这里有个细节更新后短期窗口我选择清空而不是保留一半。原因是不清空的话下次组装上下文时同一批信息既出现在摘要里又出现在窗口里等于重复计费而且模型容易被冗余信息干扰。如果你担心窗口清空后短期记忆缺失可以把更新时间点选在语义边界上比如用户说完一个完整需求之后。3.4 实体抽取的实现与更新策略实体抽取我建议先用关键词正则做一轮粗筛再用 LLM 做细化和更新。全量走 LLM 的话延迟高、费用高只走正则的话又处理不了用户口语里的复杂说法。低配版实现正则 JSON 模板import re def extract_entities_rule_based(text): 从一条用户消息中抽取基础实体 entities {} city_pattern r([\u4e00-\u9fa5]{2,8}?(?:市|区|县)) match_city re.search(city_pattern, text) if match_city: entities[city] match_city.group(1) date_pattern r(今天|明天|后天|周[一二三四五六日]|\d{1,2}月\d{1,2}日) match_date re.search(date_pattern, text) if match_date: entities[service_date] match_date.group(1) return entities高配版实现LLM 合并更新def update_memory_with_llm(self, user_input): prompt f 现有用户记忆JSON形式 {json.dumps(self.memory, ensure_asciiFalse)} 用户最新消息 {user_input} 请从中抽取所有可结构化存储的信息并更新到记忆里。 注意 - 如果新消息与旧信息冲突以新消息为准用 updated 标记 - 只输出 JSON不要输出额外文字 result self._call_llm(prompt) try: self.memory json.loads(result) except json.JSONDecodeError: # 如果模型输出不干净做一次容错提取 self.memory self._extract_json_from_llm_output(result)实际跑下来规则抽取负责“快”LLM 负责“全”两者配合后基本能在一次响应内完成记忆更新不需要额外排队任务。3.5 完整请求流程的串联示例所有组件就位后一次带 context-mode 的完整请求流程是这样的def handle_user_message(session, user_input): # 1. 更新短期窗口 session.short_term_window.append({role: user, content: user_input}) # 2. 更新关键实体记忆 session.update_memory_with_llm(user_input) # 3. 判断是否触发摘要更新 if session._count_window_tokens() session.window_budget // 2: session.update_summary() # 4. 构建上下文并请求模型 context session.build_context(user_input) reply call_llm(context) # 5. 把回复写入短期窗口 session.short_term_window.append({role: assistant, content: reply}) return reply整体串联起来就是一个最小可用的 context-mode 实现。开发过程中建议每一步都打日志特别是 token 消耗和窗口长度后面调优全靠这些数据说话。4. 真实项目里的 context-mode 调优与问题排查代码能跑通只是第一步。我在线上项目里真正花时间最多的是各种奇奇怪怪的上下文问题。这里挑几个出现频率最高的记录一下每个都是我真实踩过的坑不是网上抄来的理论。4.1 上下文截断后语义断裂这是最隐蔽的一个问题。短期窗口满了之后我一开始直接砍最旧的消息。结果用户上一轮说“把刚才那个方案改成 B 版”这轮说“价格多少”——模型根本不知道“刚才那个方案”是指 A 还是 B因为我刚好把包含 A/B 方案的那轮给裁掉了。后来我改成了“语义相关优先”的裁剪策略。具体做法是维护一个简单的关键词索引当需要裁掉超长窗口内容时优先保留与当前轮关键词重合度高的历史消息。技术上不复杂用一个 TF 词频统计就能实现但效果立竿见影。上下文截断不是按时间一刀切而是要按与当前话题的相关度来切。4.2 摘要越滚越薄早期关键信息丢失摘要模式跑久了会出现“信息蒸发”。一开始摘要里还有用户姓名滚了 20 轮之后姓名就消失了。我排查后发现原因在摘要更新的 Prompt 上我只说了“保留重要信息”但没定义什么是重要模型倾向于保留最新消息里的宴细节。解决办法是给摘要更新加一个“关键信息清单”让模型逐项检查KEY_ENTITY_CHECKLIST 检查以下信息是否存在于旧摘要或新消息中存在则必须在新摘要中保留 1. 用户姓名 2. 服务/商品类型 3. 预算或价格 4. 时间地点 5. 用户明确表达的偏好 把这份清单拼进摘要更新的 Prompt问题就解决了。后来我干脆把这五项做成结构化字段每次更新摘要时单独输出这些字段再随摘要一起存下来可靠性更高。4.3 实体记忆冲突没有兜底用户先说了“预算 5000”后来又说了“太贵了能不能便宜点”。第三个问题来了“我到底说了多少次贵”实体更新逻辑里我直接覆盖了预算字段但丢了“用户对价格敏感”这个状态。现在我的实体记忆模型分两层静态属性和动态状态。静态属性直接覆盖动态状态保留最近三条变更轨迹memory: { budget: { current: 5000, history: [ {value: 5000, time: 2024-01-10 10:20}, {value: 未明确, time: 2024-01-10 10:15} ] } }这样模型既能知道用户当前预算也能看出来源历史判断用户“是否反复修改预算”时就有了证据。如果做销售转化类的 Agent这类历史轨迹几乎是必备的。4.4 请求上下文过长导致的“中间遗忘”这是大模型本身的注意力分布问题但 context-mode 可以通过调整消息顺序来缓解。如果你用的是 OpenAI 接口系统指令在头部、用户当前输入在尾部中间夹着长窗口历史模型对中部信息的利用率最低。我的对策是把最需要模型遵循的信息放在头部和尾部。比如用户的明确指令放尾部涉及用户画像的关键信息放头部。实测下来一组 6000 token 的上下文调整消息顺序后关键信息召回率能从 60% 提到 85% 左右算是零成本优化。4.5 调试 context-mode 的三个日志维度排查上下文问题时没有日志寸步难行。我一旦上线新的 context-mode 策略就会开三个维度日志组成结构每轮请求中系统指令、历史摘要、短期窗口、实体记忆各占多少 token内容快照随机抽样保留 5% 请求的完整上下文方便复现问题记忆变化实体记忆从旧值到新值的 diff摘要每次更新的前后对比这套日志配合可视化工具能让我在用户反馈“模型忘了”的时候快速定位是截断问题、摘要蒸发问题还是实体没抽出来。没有这套日志排查类似问题完全靠猜效率极低。5. 关于 context-mode 的进阶思考和我的个人经验聊到这里context-mode 的基础方案已经立起来了。但真实项目里它永远是动态演进的。我最后分享几个自己一直坚持的经验和判断。第一context-mode 没有银弹每种模式都有明确的能力边界。摘要记不住精确数字实体抽取记不住叙事逻辑向量检索召回的上下文可能有噪声。合格的架构是让每一层各司其职用工程手段兜住各自的短板。我见过有人想用向量数据库解决所有记忆问题结果检索回来的内容经常和当前对话毫无关联反而污染了上下文。合理的设计是「短期窗口为主 摘要兜底 实体锚定」向量检索只做补充。第二token 经济账一定要算清楚。一个完整的多轮对话系统context-mode 决定了每轮请求的 token 消耗。如果架构设计得合理每轮请求可以稳定控制在较小范围如果设计得粗糙token 消耗会随对话轮数线性增长很快超过模型上下文上限。生产环境里这个指标直接决定了你的毛利是正的还是负的。第三动态调整 context-mode 的参数是加分项。我不建议一套参数跑到底。用户第一轮提问的时候根本不需要摘要用户连续对话 20 轮之后短期窗口权重就应该让位于摘要。有些团队会做一个简单的赛跑机制根据当前轮数、消息平均长度、业务类型动态选择上下文策略。这个做起来不需要太复杂收益却很可观。最后我自己的体会是context-mode 本质上在做一个“记忆的取舍”决策而好的决策永远基于对业务场景的理解而不是对最新框架的追逐。你越了解你的用户在每轮对话里真正需要哪些历史信息越清楚模型的注意力分布在什么位置就越能设计出省钱、省心、用户还满意的上下文方案。如果看完这份梳理你能少踩几个我当时踩过的坑那这次分享就值了。