最近在做一个人机对话相关的项目核心功能的代号就叫“context-mode”。说起来挺玄乎其实本质就是动态管理对话上下文的一组策略。折腾了几天下来我最大的感受是很多AI应用跑不起来、答非所问、聊几轮就“失忆”八成不是模型不行而是上下文没管好。这篇就把我在项目里踩过的坑、用过的方案、最终沉淀下来的可复用设计原原本本分享出来。1. context-mode到底在解决什么问题1.1 从一段真实踩坑经历说起项目刚开始的时候我做了一个简单的客服问答机器人。第一版非常朴素用户每次提问直接把问题拼到Prompt里发给大模型接口拿回答案就完事。单轮问答跑得挺顺一到多轮对话就露馅了——用户说“那第二个方案呢”模型根本不知道“那”指的是什么回答得驴唇不对马嘴。后来我翻了翻对话历史发现问题出在“无状态”上。每轮对话都是独立的模型看到的信息只有当前这轮的问题没有前文的支撑。这就像你跟一个人聊天对方每句话都当第一次见面压根接不上茬。改起来也不难把历史消息一股脑全塞进Prompt就行。我给每条消息带上角色标记拼成一个数组传上去多轮效果立竿见影。可没过多久新的麻烦来了对话一长Token开销蹭蹭往上涨到了第50轮发一次请求要等十几秒账单数字也变得很难看。1.2 有上下文和无上下文的本质区别所谓context-mode说穿了就是一套“该记什么、记多久、怎么记”的管理规则。纯单轮问答是零上下文模式适合查天气、算算术这类独立任务完整上下文模式则把整个对话历史全部保留适合长聊、深度分析。但实际场景里这两者都不是最优解大部分需求落在中间——记住该记的丢掉不该记的。我后来把常见的上下文模式分成了五类实际项目里几乎都在这些模式之间来回切换模式名称记忆范围适用场景成本特点零上下文只保留当前输入单轮问答、独立任务最低但无法多轮短窗口模式只保留最近3~5轮客服接待、快速问答低易丢失早期信息长窗口模式保留最近20~50轮深度对话、代码审查高窗口容易打满摘要模式只保留浓缩后的要点超长文档分析、跨天会话中等依赖摘要质量混合模式近期原文远期摘要复杂业务系统、长期助手较高但效果好看到这你应该明白了context-mode不是某个具体的算法更不是某个平台的专属能力而是一套围绕“上下文”做的取舍方案。后面的章节我会把从设计到落地的完整过程都拆开讲。2. context-mode的核心设计拆解2.1 上下文到底由什么构成动手之前先把“上下文”这个黑盒子拆开。它不只是聊天记录至少包含三层任务信息层指用户当前的目标和约束条件比如“帮我写一封辞职信语气要缓和”历史对话层指之前几轮里用户的提问和助手的回答外部状态层指当前时间、用户画像、业务数据等环境信息。我在设计时还额外加了一层叫“隐性上下文”包括用户的语气倾向和常用词习惯。第三层很容易被忽略。举个我项目里的例子用户问“今天天气适合爬山吗”如果模型不知道“今天”是几号、被问的人当前在哪个城市即使记住所有历史对话也难以给出准确回答。所以做context-mode的第一步不是写代码而是画出“上下文清单”——先想清楚你丢给模型的每一段信息属于哪一层。没有这个清单后面所有策略都是空谈。2.2 三种主流记忆策略滑动窗口、摘要压缩、混合分层确定了有哪些信息之后接下来要回答“怎么记”。我在项目里重点比对了三种策略。滑动窗口最容易理解像一列火车新消息进来最老的消息就出站。假设窗口被设为10条消息系统只保留最近10条。它实现简单、性能稳定但问题也明显用户在第3轮提到的“我的预算是3万以内”到第15轮可能已经被挤出去了模型就彻底忘了这个约束。摘要压缩不保留原始对话而是定期让模型把前面的内容总结成一段精炼的文字。每聊10轮就触发一次压缩把10轮对话浓缩成一段话。它解决了滑动窗口丢失远期信息的问题但摘要本身有损耗模型总结时可能把关键数字或用户偏好丢掉而且每一次压缩都要额外调用一次大模型延迟和费用都上去了。混合分层是前两者的结合把对话分成“近期”和“远期”两层近期对话用滑动窗口保留原文远期对话用摘要保留浓缩信息。我最终在正式项目里选的就是这个方案效果是目前最稳的。2.3 为什么模式切换是刚需大部分教程只讲“怎么选一种上下文模式”却忽略了真实场景里上下文模式应该是动态切换的。同样是客服机器人用户刚进来时用零上下文模式就够了开始咨询具体型号和价格时切到短窗口模式用户开始描述复杂故障场景、需要结合之前所有信息时再切到混合模式。判断“什么时候该切”可以用两个信号对话轮次和话题漂移度。我通常用会话涉及的不同实体数量来衡量后者比如一台电脑、一个价格区间、一个物流单号实体数量超过5个时就该升级模式了。再比如用户突然问“我刚才说的那个型号还有货吗”里面带着“刚才”“那个”这类指代词说明必须至少启用短窗口模式否则模型根本答不上来。这个切换逻辑其实就是一套简单的状态机。我在代码里用分数制来做触发判断每条新消息进来累加一定的上下文复杂分数超过阈值就自动调高窗口级别。这样既不用人工干预也不会频繁抖动。3. 实操记录把context-mode一步一步落到代码里3.1 基础数据结构设计所有故事的开头都是数据结构。我定义了一个叫ContextUnit的基础对象每个单元代表一条对话消息字段包括role、content、timestamp还有一个importance字段用来标识这个消息的重要程度。from dataclasses import dataclass from typing import List, Optional dataclass class ContextUnit: role: str # user, assistant, system content: str # 消息正文 timestamp: float # 时间戳用于排序和时效判断 importance: float # 重要程度 0.0 ~ 1.0 class ContextStore: 一个极简的上下文存储容器负责维护全部消息序列。 技术细节上我用一个 List 来保存全部消息 并时刻维护 total_tokens 近似值和最近 N 条索引。 def __init__(self, max_units: int 100): self._units: List[ContextUnit] [] self._max_units max_units self._total_tokens 0 def append(self, unit: ContextUnit): self._units.append(unit) self._total_tokens estimate_tokens(unit.content) self._trim_if_needed() def _trim_if_needed(self): while len(self._units) self._max_units: removed self._units.pop(0) self._total_tokens - estimate_tokens(removed.content)estimate_tokens这个函数不必非常精确因为最终请求大模型时消息还是以原始文本形式送出的这个估算只是用于判断窗口是否接近上限。中文场景里我一般按一个汉字约等于1.5个Token来估算一段500字的对话大约750个Token跟实际相比误差能控制在10%以内。3.2 上下文构建与模式切换的核心实现接下来就是重头戏怎么把原始消息组装成大模型真正能看到的Prompt。我封装了一个ContextBuilder输入是ContextStore和当前模式输出是标准消息数组。class ContextBuilder: def __init__(self, config): self.config config # 包含 mode, window_size, summary_gap 等参数 def build(self, store: ContextStore, mode: str) - List[dict]: units store.get_all() if mode zero: # 只保留最后一条用户消息 return [self._to_msg(units[-1])] elif mode short_window: return [self._to_msg(u) for u in units[-self.config.window_size:]] elif mode long_window: return [self._to_msg(u) for u in units[-self.config.long_window_size:]] elif mode summary: summary summarize(units) # 调用LLM做压缩 return [{role: system, content: summary}] elif mode hybrid: recent units[-self.config.window_size:] earlier units[:-self.config.window_size] summary_text summarize(earlier) if earlier else result [] if summary_text: result.append({role: system, content: f早期对话摘要{summary_text}}) result.extend([self._to_msg(u) for u in recent]) return result else: raise ValueError(funknown context mode: {mode}) staticmethod def _to_msg(unit: ContextUnit) - dict: return {role: unit.role, content: unit.content}这段代码看起来简单但里面的门道不少。summary模式的summarize函数是耗性能大户每次压缩都是额外一次大模型调用。我在这里做了一个极简缓存同一个会话、同一个时间窗口内的摘要结果以窗口起始时间为key缓存起来10分钟内不重复压缩。这能省下不少调用量。真正的模式切换不放在build里而是放在一个独立的decide_mode函数中。我会根据会话轮次、最近消息里的指代词数量、以及消息重要性均值三个维度做判断。def decide_mode(store: ContextStore) - str: units store.get_all() n len(units) if n 2: return zero recent units[-6:] mention_refs 0 for u in recent: if any(w in u.content for w in [这个, 那个, 刚才, 上面, 之前, 它, 其]): mention_refs 1 avg_imp sum(u.importance for u in units) / max(n, 1) if mention_refs 2 or avg_imp 0.6: return hybrid if n 20: return short_window return long_window这个函数的逻辑考虑了三种场景开头一两个来回直接用零上下文最省用户使用了指代词说明在引用前文此时启用混合模式保底对话超过一定长度后也要逐渐升档。这套决策规则我跑了差不多两周准确率能覆盖八成场景剩下的两成主要靠下面的兜底策略去解决。3.3 参数怎么调才适合你自己的业务聊参数之前必须强调一个问题参数不是越合理越好而是越贴近你的流量成本模型越好。很多人照抄别人的配置结果自己的业务场景根本不适用。窗口大小是最关键的参数。做在线客服时我把短窗口设为8条长窗口设为40条做代码审查工具时短窗口设为12条长窗口设为60条。为何会有差异因为代码片段里的每条消息较长如果窗口设得太小根本覆盖不了一段完整代码的上下文。判断标准是最长的单条消息Token数乘以窗口条数估算总Token数要小于模型最大上下文的一半。超过一半留的余量就不够了。还有摘要压缩的触发间隔。太频繁会费钱太稀疏又容易在远期内丢失关键信息。我实际测试下来的推荐值用户平均每条约150 Token时约每隔15轮做一次压缩最划算如果业务场景里消息普遍较长每10轮就要压缩一次。温度系数这种采样参数也要随之微调。经验是上下文越丰富温度越高对话越发散上下文很单一时温度反而要保守。我这个项目里模式越高档温度越低混合模式设0.6零上下文模式反而敢放到0.9。3.4 一套可直接抄的封装模板为了让团队其他人快速接入我最终把上面的逻辑封装成一个类对外只暴露两个方法add_message和get_prompt。class ContextModeProcessor: 对外统一入口。内部自动完成上下文存储、模式决策、消息构建。 使用者只需要: - add_message(role, content) - get_prompt() - messages def __init__(self, configNone): self.config config or { max_units: 100, window_size: 8, long_window_size: 40, summary_gap_units: 15, temperature: 0.7 } self.store ContextStore(max_unitsself.config[max_units]) self.builder ContextBuilder(self.config) self.mode_history [] def add_message(self, role: str, content: str, importance: float 0.5): self.store.append(ContextUnit(rolerole, contentcontent, importanceimportance)) def get_prompt(self) - List[dict]: mode decide_mode(self.store) self.mode_history.append(mode) return self.builder.build(self.store, mode)接入方只需要维护一个ContextModeProcessor实例每收到一条新消息就调add_message要请求模型前调get_prompt拿到消息数组剩下的逻辑全部自动完成。这个模板的另一个好处是易于测试因为模式决策是确定性的只要给定同样的消息序列永远返回同样结构的结果。4. 常见问题与排查技巧实录4.1 上下文溢出和静默截断开发context-mode过程中遇到频率最高的问题是上下文溢出。大模型都有最大Token限制虽然代码里设置了max_units100但每条消息长短不一100条消息的总Token数就可能超过8K或32K的上限。更危险的是某些服务端会静默截断超长部分错误信息却不报出来。我的排查方法很笨但很有效在_trim_if_needed里打日志观察被淘汰消息里是否有重要约束。后来就加上了一个主动预警机制当_total_tokens超过最大限制的80%时即使还没到窗口条数上限也强制触发摘要压缩。核心代码如下TRIGGER_RATIO 0.8 def _check_token_limit(self): max_tokens self.config.get(max_tokens, 8192) if self._total_tokens max_tokens * TRIGGER_RATIO: self.compress_early()4.2 话题漂移和指代断裂比溢出更隐蔽的是“模型没报错回答却跑偏了”。典型症状是用户说“那价格呢”模型回复“你说的是哪个价格”。这说明模型没有把“那”和之前提到的商品建立关联。我用了一个非常传统的方法来抓根因记录每次模型输出中被判定为“指向不清”的问句。当模型回答末尾包含“你说的是哪个”“能提供更多信息吗”这类话且当前窗口里的上下文少于5条时基本可以断定是上下文太短要控制好指代的衔接。另外在decide_mode里检测到指代次数的逻辑已经帮了大忙这类问题的发生频率下降了六成以上。4.3 摘要模式的三大陷阱摘要模式一开始我以为最简单结果它反而是最坑的。第一个坑是摘要把约束条件丢掉——用户说“预算3万以内最好2万5左右”模型摘要时直接变成“用户对预算有要求”金额信息全没了。处理方法是在摘要Prompt里明确列出“必须保留所有数字和否定词”例如“不低于”“不超过”都要原样保留。第二个坑是摘要重复压缩导致信息失真。每次摘要都是在前一次摘要基础上再总结越缩越模糊。解决办法是摘要永远基于原始消息而不是上一次的摘要结果。实现上我在ContextStore里额外维护了一份source_units的只读备份。第三个坑是摘要时效性问题。一次会话从早上持续到下午上午的摘要一直没变但用户上午说“明天到货就行”下午改口“今天必须拿到”模型只看到摘要看不到用户的更新以为还是“明天”。我在hybrid模式下做了一条规则如果新消息里包含明确的时间词或变更词同时近期窗口里找不到对应的旧结论就要重新触发一轮摘要刷新。4.4 单测与调试建议context-mode这类模块本质上是状态转换逻辑非常适合写单元测试。我建议至少覆盖这几类用例测试场景输入预期行为空会话无消息返回空数组不崩溃短会话1~2条消息模式切换为零上下文指代触发消息含“那个”自动升档为混合模式大消息挤占多条超长消息触发早期压缩摘要缓存同一窗口两次请求第二次不重新调用压缩调试时还有一个细节大模型接口返回的usage字段里带这次请求实际消耗的Token数应该定期回连到你估算的数字上做误差校正。我花了一晚上把估算系数从1.5修正到1.35后全流程成本下降了大概一成这个校准步骤千万别跳过。5. context-mode在终端环境里的另一个形态5.1 按目录自动切换的项目上下文上面聊的都是AI对话场景但在开发工具链里context-mode也有一个很有意思的落地形态——为终端工具按当前工作目录自动加载上下文。还是从实际需求说起我维护了好几个项目有Python的有前端的还有几个部署脚本。每次切目录都要手动设置环境变量、切换虚拟环境、改各种配置文件忘一次就得折腾半天。后来我把context-mode的思路搬到了Shell层写了一个钩子函数每次cd切换目录时自动检测项目类型加载对应的环境配置。这个形态的核心是“用路径作为上下文的key”就像AI对话用会话ID作为上下文的key一样。5.2 Shell函数实现思路实现思路其实不复杂。定义一个project_context.zsh文件用chpwd钩子函数在目录切换时自动注册PROJECT_CONTEXT_DIR${HOME}/.project_context detect_project_type() { if [[ -f pyproject.toml || -f requirements.txt ]]; then echo python elif [[ -f package.json ]]; then echo node elif [[ -f go.mod ]]; then echo go elif [[ -f Makefile ]]; then echo makefile else echo unknown fi } load_project_context() { local type type$(detect_project_type) case $type in python) if [[ -d .venv ]]; then source .venv/bin/activate; fi export PYTHONDONTWRITEBYTECODE1 ;; node) export NODE_ENVdevelopment export PATH${PWD}/node_modules/.bin:${PATH} ;; go) export GOFLAGS-modmod ;; esac echo [context] activated for ${type} project } autoload -U add-zsh-hook add-zsh-hook chpwd load_project_context load_project_context # 首次启动时也执行一次这段脚本踩过一个大坑在PATH前面拼当前的node_modules/.bin会导致切过三四个项目后PATH里出现一堆旧目录。后来我改成每次切换前先把PROJECT_CONTEXT_DIR下记录的旧PATH恢复再重新拼接问题才算解决。这个思路在团队里推广后大家又加了不少插件比如按分支名切换云环境变量、按项目类型调整编译参数、读取项目里的.contextrc文件执行自定义钩子。这也算是context-mode在工程效率方向上一个很值得复制的场景。6. 我个人在实操中沉淀的几个体会项目做到后期我对context-mode的理解已经从“一段代码”变成了“一套方法论”。它本质上是在回答一个问题系统在每一个时刻应该携带多少过去的信息来做决策。这个问题的答案不是越大越好也不是越简单越好而是越匹配场景越好。我在实际测试里留下的一个习惯是每改一版上下文策略就把同一批测试问题再跑一遍对比回答质量的变化。因为上下文管理的效果很难靠肉眼衡量必须用固定的问题集回归验证。到现在我手里已经积累了一套50条问题的回归集涵盖指代消解、约束保持、话题切换、长对话稳定性几大类任何策略调整都必须过这50条才有资格上线。最后分享一个经常被忽视的小技巧上下文模块一定要能单独开启和关闭并且要加上观测接口。因为对话AI的线上表现是动态的你永远无法预测用户会聊出什么新花样。把context-mode的决策过程全部打到日志里出了问题才能回溯是哪一步丢了关键信息。我这套方案的日志格式很粗糙就是每轮记下当前模式、窗口条数、估算Token数、触发切换的原因。就靠这四行日志线上问题定位时间至少缩短了一半。如果你也要在项目里做类似的功能不用急着把我上面的代码全部照搬。先梳理清楚自己的消息有哪些层级、用户最长会聊多少轮、模型的最大上下文有多大然后再选模式、调参数。方向对了细节总能磨出来。