1. 一个让人抓狂的场景逼我认真研究 context-mode先讲个真实经历。上个月我在做一个内部知识库问答机器人一开始效果还不错单轮问答准确率能到 85%。但一旦用户连续问三五轮模型就开始失忆——明明第一轮用户就说了自己是运营部门的问到第四轮模型居然一本正经地给出建议建议您咨询运营部门的同事了解具体流程。我当时的第一反应是换更大的上下文窗口。把模型从 8K 换到 128K成本翻了好几倍结果问题只缓解了一小半。多轮对话超过十轮照样翻车。后来我才意识到问题根本不在窗口大小而在于我压根没有上下文管理这个概念——我把所有东西都往窗口里塞塞得越多模型越分不清哪些是重点。这就是我要聊的主题context-mode。这个词最近在技术圈和产品圈被反复提及但很多人对它的理解停留在上下文足够长这个层面。实际上context-mode 是一整套关于上下文如何组织、如何保留、如何更新、如何淘汰的设计模式。它决定了你的 AI 应用是越聊越懂你还是越聊越像弱智也决定了你的工具在复杂任务下是得心应手还是手忙脚乱。这篇文章不聊虚的我会从底层机制讲起结合对话应用、编程助手、本地工具三类场景手写一个轻量级的上下文管理器最后把我在实际项目中踩过的五个大坑全部分享出来。无论你是做 AI 应用开发、搞智能体编排还是单纯想理解为什么有些 AI 工具用起来聪明、有些用起来蠢这篇都值得你花十分钟看完。2. 别被长上下文忽悠了context-mode 的底层是注意力博弈很多人选模型的第一标准就是上下文窗口多大。128K、200K、1M数字越大越安心。但从工程实践看这个思路在根上就偏了。2.1 窗口大不等于记得住注意力稀释效应我之前做过一个对比实验。用同样一个模型同样一道推理题分别塞入 2K、8K、32K 的无关历史聊天记录让模型回答问题。结果是2K 组准确率 92%8K 组降到 78%32K 组只剩 61%。这个现象在业内有个通俗说法叫注意力稀释——模型在处理任务时注意力资源是有限的。你塞进去的无关信息越多模型分配到关键信息上的注意力就越少回答质量自然下降。这就好比让一个员工在一万份文件里找一句话他找是找得到但速度、准确性都大打折扣而且很容易被另一份文件里相似的话带偏。所以 context-mode 的第一个核心原则就是不是把上下文都装进去而是把该装进去的装进去不该装的坚决不装。2.2 Token 预算你要学会像算工资一样算上下文做 context-mode第一课是建立 Token 预算思维。每次请求模型你实际花的钱和延迟都跟 Token 数直接挂钩。128K 的窗口不是给你随便用的每多 1000 Token响应时间就多几百毫秒成本也线性上升。我自己的经验是给上下文分三层预算层级内容预算占比更新频率系统层角色设定、任务说明、输出格式约束10%几乎不变会话层当前任务相关的关键信息、最近的对话摘要30%每轮更新实时层当前正在处理的用户输入、最近 2-3 轮原始内容60%每轮全量替换这个分配比例不是我拍脑袋定的。系统层内容必须有但往往被无限放大——很多人喜欢把一套冗长的 system prompt 写进去占了 30% 甚至更多的预算真正给对话内容的空间反而小了。实时层留给最近的交互因为模型对最近内容的关注度天然最高。会话层是 context-mode 的核心战场后面我会详细讲它怎么做。2.3 记忆分层的本质把所有东西变成有用的东西理解 context-mode最有效的类比是大脑的工作方式。你不会把自己记事以来的所有记忆都调用出来处理一个今天中午吃什么的问题你只调用了当前的食欲、附近的餐厅、最近的饮食偏好这几类信息。AI 的 context-mode 也是同样的逻辑。它需要回答三个问题哪些信息是这次任务必需的筛选这些信息以什么形式放进上下文组织新信息来了旧信息里哪些必须删掉遗忘很多 AI 应用做得差就是因为只做了第三个问题而且用的是最粗暴的方式——超过 N 轮就把最早的对话删了。这不叫 context-mode这叫截断。真正的 context-mode 是要把对话历史、用户画像、任务状态、知识库片段多维度的信息在每一轮请求前动态重组为一个最高质量的上下文。3. 三类常见场景拆解同一个 context-mode三种完全不同的玩法context-mode 不是一个具体功能而是一套策略。同样的策略放到不同场景里落地的形态天差地别。我挑三个最常见的场景拆开讲。3.1 对话型 AI 应用从记录对话到维护状态做客服机器人、聊天助手这类应用新手最容易犯的错就是把所有历史消息原封不动地塞给模型。我见过有人直接把最近 50 轮消息全部拼进 prompt结果模型经常被用户在第三轮随口说的一句我其实是随便问问干扰后面的回答全在自我怀疑。正确的做法是把对话历史升级为多轮状态管理。每一轮用户说完话系统要提取四个东西用户意图、关键实体、情感倾向、未完成事项。比如用户说我要退掉昨天买的那个蓝色耳机太吵了状态管理就记录下意图退货申请实体蓝色耳机购买时间昨天情感不满对噪音待办生成退货流程下一轮用户说需要我提供订单号吗系统不需要重新读第一轮的原话只需要基于上面这个状态来理解同时把最新这轮的内容追加到实时层。这样即使对话持续几十轮模型的上下文始终是结构化的、干净的不会被原始聊天记录里的废话淹没。3.2 编程助手代码库上下文的目录化组织上下文模式在编程场景里更复杂因为代码的上下文不是简单的文本而是一个图结构——函数调用关系、类继承关系、跨文件引用牵一发动全身。我维护过一个 VS Code 插件功能是根据当前光标位置的函数自动生成测试用例。第一版我把当前文件全文塞进去效果很差因为被测试函数可能依赖了另外三个文件里的工具函数模型看不到这些依赖生成的测试全是 mock根本跑不通。后来我改成目录化的上下文构建方式先扫描当前文件提取被测试函数的依赖树只把依赖树涉及到的相关函数定义、关键类型、错误处理逻辑塞进上下文其他无关内容全部排除。效果立竿见影生成的测试从 30% 通过率提升到 79%。这个案例说明了 context-mode 在代码场景下的一个关键点上下文的组织方式应该跟代码的依赖结构对齐而不是跟文件路径对齐。你要的是这个任务真正相关的符号和定义不是这个目录下的所有代码。3.3 本地工具与系统级应用上下文即状态切换即成本最近还有一个趋势是把 context-mode 做进系统级工具里。比如笔记软件、浏览器插件、文件管理器它们根据用户当前在做什么自动调整工作界面的信息密度和功能入口。我在一个笔记项目里尝试过类似的东西根据用户正在编辑的文档自动把相关文档常用标签最近引用三块信息显示在侧边栏其余全部收起。这个功能用到的核心机制就是上下文管理——当用户打开一篇关于季度总结的文档时系统先通过关键词提取出主题再检索这个主题下最近活跃的文档和标签最后把结果作为新的上下文加载到界面里。跟 AI 场景相比这类系统级应用对上下文的要求更苛刻响应必须快切换必须平滑。用户在一个文档里待了半小时你不能每三十秒就重排一次侧边栏。所以我通常会在上下文切换上做防抖只在整个主题发生明显变化时才触发重排微小的编辑操作只更新局部信息。4. 手写一个轻量 context-mode 管理器完整实现与关键决策前面说了这么多理论下面来点能直接抄作业的干货。我写了一个适用于对话类应用的轻量上下文管理器代码不过两百行但里面每个设计决策都有讲究。4.1 上下文的结构化建模第一步定义上下文的数据结构。不把上下文当成一个字符串数组而是分成三个独立的领域对象from dataclasses import dataclass, field from typing import Any, Optional dataclass class SystemProfile: 系统层角色与全局约束 role: str output_format: str rules: list[str] # 可选全局用户信息如偏好、权限 user_prefs: dict[str, Any] field(default_factorydict) dataclass class SessionState: 会话层当前任务的压缩记忆 intent: Optional[str] None key_entities: dict[str, str] field(default_factorydict) pending_tasks: list[str] field(default_factorylist) # 压缩后的历史摘要每轮结束时更新 summary: str # 元信息当前会话已进行多少轮、最早轮次时间 turn_count: int 0 start_time: Optional[float] None dataclass class RealtimeContext: 实时层最近的原始轮次 recent_turns: list[dict] field(default_factorylist) max_turns: int 3 # 只保留最近3轮原文我把实时层的max_turns设置为 3这是一个经过多次实验的平衡点。保留太少模型看不到用户最近表达里的细微转折保留太多又会在 Token 预算上挤压会话层。4.2 滑动窗口 关键信息提取每一轮结束时的记忆更新核心逻辑在每轮对话结束后。旧的最原始对话不能让它们白白消失而是要把它们的精华提取出来合并进会话状态。这段代码是我这个项目里最重要的函数class ContextManager: def __init__(self, profile: SystemProfile, extractor): self.profile profile self.session SessionState() self.realtime RealtimeContext() self.extractor extractor # 信息提取器可用LLM或规则实现 def update_realtime(self, user_msg: str, assistant_msg: str): 记录本轮对话到实时层超出的轮次交给压缩逻辑处理 self.realtime.recent_turns.append({ user: user_msg, assistant: assistant_msg, }) self.session.turn_count 1 if len(self.realtime.recent_turns) self.realtime.max_turns: # 取出最早的一轮进行压缩 expired_turn self.realtime.recent_turns.pop(0) self._absorb_into_session(expired_turn) def _absorb_into_session(self, turn: dict): 把过期轮次的精华吸收进会话状态 extracted self.extractor.extract(turn) # 1) 更新意图最近的意图优先但保留历史意图列表 if extracted.get(intent): self.session.intent extracted[intent] # 2) 合并实体相同实体名则覆盖新实体则追加 for k, v in extracted.get(entities, {}).items(): self.session.key_entities[k] v # 3) 追加待办事项排除已完成 for task in extracted.get(pending_tasks, []): if task not in self.session.pending_tasks: self.session.pending_tasks.append(task) # 4) 更新压缩摘要可以用一个轻量LLM调用做摘要式的压缩 self.session.summary self._compress_summary( self.session.summary, turn )这段代码看起来简单里面藏着三个关键决策值得你注意。第一个决策实体用覆盖式合并而不是追加式。用户在第一轮说我想买个蓝色耳机第二轮说算了还是白色的吧这时候key_entities里的耳机颜色就应该从蓝色更新为白色。如果只追加不覆盖新旧信息矛盾模型会蒙圈。第二个决策意图永远取最近一次。用户可能在对话中途改变主意如果保留历史意图的堆栈模型反而不确定当前到底要干什么。经验是意图记录最近的实体保留完整的待办事项保留未完成的。第三个决策摘要压缩单独做。我这里的_compress_summary在真实项目中是用一个小的 LLM 调用实现的输入是旧摘要 新的过期轮次输出是合并后的更精炼摘要。这比单纯的截断强得多——它不只是删掉老内容而是把老内容里的关键信息永久保存下来。4.3 构建最终 prompt动态装配而非静态拼接有了三个层级的上下文数据最后一步是把它们拼装成发送给模型的 prompt。这里的次序很讲究def build_prompt(self, user_input: str) - str: 构建完整请求 prompt注意各层的顺序与措辞 blocks [] # 系统层永远在最前 sys_text f你是{self.profile.role}。\n输出格式要求{self.profile.output_format} if self.profile.user_prefs: sys_text f\n用户偏好{self.profile.user_prefs} blocks.append(f[系统设定]\n{sys_text}) # 会话层放中间用已知信息的方式陈述 session_parts [] if self.session.intent: session_parts.append(f当前用户意图{self.session.intent}) if self.session.key_entities: session_parts.append(f已知信息{self.session.key_entities}) if self.session.pending_tasks: session_parts.append(f待办事项{self.session.pending_tasks}) if self.session.summary: session_parts.append(f历史摘要{self.session.summary}) if session_parts: blocks.append([会话状态]\n \n.join(session_parts)) # 实时层放最后紧贴用户输入 for turn in self.realtime.recent_turns: blocks.append(f用户{turn[user]}\n助手{turn[assistant]}) blocks.append(f用户{user_input}) return \n\n.join(blocks)顺序为什么是这样因为模型对 prompt 开头和结尾的注意力是最高的。系统层的角色设定和约束放开头能被稳定遵守用户最新输入放结尾模型会优先响应它中间放压缩后的会话状态起到背景知识的作用既不抢注意力又能提供必要信息。这种系统层-会话层-实时层的黄金结构我测试下来比单纯的系统 prompt 所有历史消息 用户输入的平铺结构在 20 轮以上多轮对话中的表现要稳定得多有效回答率提升大约 35%-40%。5. 实测翻车记录context-mode 最容易踩的五个坑纸上得来终觉浅。下面这五个坑每一个都是我拿真金白银API 费用和时间换来的教训希望你能绕开。5.1 上下文污染旧信息覆盖新意图这是最隐蔽也最致命的坑。我做的客服机器人曾经出现过一个诡异 bug用户问我要查一下物流系统居然回答好的您需要查询的是订单退货进度对吗。排查了半天原因出在实体覆盖逻辑上。前两轮用户确实聊过退货key_entities里存了退货相关信息但当用户新开话题说查物流时提取器没有把旧的意图清理掉导致新旧信息叠加。模型的注意力被旧信息带偏了。解决方案是在提取逻辑里增加一个意图切换检测如果新意图和旧意图的语义相似度低于某个阈值就认为用户切换了任务需要清空pending_tasks并重新初始化key_entities而不是继续往上叠。上下文管理的艺术有时候是敢清零。5.2 状态不同步多端联动的噩梦我的项目后来接入了 Web 端和微信小程序端结果出现了状态不同步的问题。用户在小程序里问了半天切到 Web 端继续问系统完全不知道前面的对话。这是 context-mode 架构层面的坑会话状态必须持久化并且要跨端共享。我把SessionState序列化成 JSON 存进了 Redis以session_id作为 key每次请求从 Redis 加载状态更新后再写回。这里有个细节Redis 里存的是压缩后的会话摘要和关键实体不是原始对话记录所以存储开销很小读写也快。但你必须处理好并发——同一 session 的两个请求同时更新状态后写的会覆盖先写的需要加锁或用 Redis 的事务命令。5.3 过度压缩丢了关键细节有一次我在调摘要压缩逻辑为了让 Token 更省把摘要的最大长度从 500 字压到 150 字。结果模型开始频繁编造用户没提过的信息。原因很清楚摘要太短丢失了关键限定条件。用户明明说了只要 500 元以内的耳机压缩后摘要只留了用户想买耳机模型就把用户的口径放大成了所有耳机推荐了一堆超预算的产品。这个教训让我明白摘要压缩不是单纯的减少字数而是要有选择地保留限定性信息。现在我的压缩逻辑有一个关键词保护机制凡是实体、数字、否定词、比较级这类限定性强的词在压缩时必须原样保留不允许改写。5.4 Token 预算失控上下文膨胀的雪崩效应还有个常见问题是上下文越来越长直到触发窗口上限整个系统崩溃。尤其是当key_entities里的实体越攒越多或者摘要越写越长每轮请求的 token 数会稳步爬升。我的应对是给每个上下文块设置硬性上限。实体字典超过 20 个就触发 LRU 淘汰摘要超过 800 字就强制做一次二级压缩把摘要再浓缩成要点列表。此外每轮构建 prompt 之前会先做一次整体 Token 估算如果超过预算的 80%就优先裁剪会话层里最不重要的部分。这里推荐用tiktoken之类工具提前估算 token 数不要等请求发出去了才后悔。5.5 安全边界上下文里的敏感信息可能被带偏最后一个坑是关于安全的。我做过一个带用户实名信息的客服系统刚开始把用户姓名、手机号直接放进了key_entities结果在一次测试中模型居然在回复里完整复述了用户的手机号。这在企业场景是个合规大问题。我的解决方案是上下文管理器在存入实体时做等级标记敏感信息用脱敏占位符存储比如用户手机号138****1234只有真正需要精确信息的特定意图比如帮我修改绑定手机号才在实时层向模型提供原始值。记住上下文不只是模型的输入它还是信息的载体能少暴露就少暴露。6. 再往前一步从 context-mode 到 context engineering写到这里我想把这个话题再往上提一个维度。context-mode 说到底只是上下文管理的模式而现在的业界正在从模式走向工程——也就是把所有跟上下文相关的决策都系统化、可度量、可优化。我个人的体会是context-mode 做得好的产品用户感知是这个助手很懂我而 context engineering 做得好的团队能回答出三个更深刻的问题每个 Token 放在当前请求里的边际收益是多少哪些信息的缺失会导致任务失败率显著上升上下文结构应该跟随业务怎么进化把我这个轻量管理器继续往下做有几个值得探索的方向第一建立上下文收益的评估体系。每一轮请求之后记录模型回答的关键词和信息点和上下文里实际提供的信息做比对找出模型哪些回答依赖了上下文之外的信息——那就是上下文缺失的信号。第二把提取器从规则模型升级为专用的小模型。我现在用的提取器是一个本地部署的 7B 模型速度和效果都比大模型 API 稳定而且不上传用户数据隐私更好。第三结合向量检索做主动信息召回。当用户提到一个关键词时不依赖用户显式表达而是直接去知识库检索相关内容注入上下文。这一步做到位才是真正意义上的智能上下文。如果你正在做 AI 应用我建议从今天起就别再写把所有历史记录塞进 prompt的代码了。先画一个像第 4 节那样的上下文结构图把系统、会话、实时三层拆清楚定义好每一轮的更新逻辑再来谈效果优化。上下文管理的收益不是立刻爆发的但十轮、二十轮对话之后你和每次都从零开始的产品的差距会越来越明显最终体现在用户的留存率上。