1. 从上下文失控聊起为什么需要context-mode我最早接触到context-mode这个概念是在给一个客服机器人做上下文重构的时候。当时系统已经能回答问题了但用户多聊几轮之后回答质量就开始断崖式下跌——明明之前确认过的信息模型转头就忘有时候又把无关的历史记录当成当前意图去理解。翻日志查了半天发现根本问题不在模型本身而是上下文这个容器设计得太粗糙所有历史消息、中间结果、工具返回值全塞在同一个被截断的窗口里模型既不知道该重点看哪一段也不知道哪些内容是可以丢掉的。那段时间我在社区里查了很多资料发现很多人管这类问题叫上下文污染或上下文漂移而针对性的解决思路就是给上下文做模式化管理——也就是context-mode。它不是一个具体的库也不是某个模型的新特性而是一套关于如何组织上下文的设计思路把对话过程拆成不同的模式每种模式有自己明确的输入边界、内部状态和输出约束让模型在任何一个时刻都只面对一个清晰、可控、信息密度足够高的上下文窗口。这篇文章我想用实际项目里的经验把context-mode从概念讲到落地。内容包括它的核心设计维度、一个可直接参考的技术实现方案用Python写一个轻量的上下文管理器、在多轮对话和Agent场景里的具体演进方式以及我在生产环境里踩过的坑。适合正在做LLM应用开发、智能客服、RAG系统或Agent编排的开发者也适合对上下文工程这个方向感兴趣的初学者——你会知道这不是什么高深理论而是一套能靠工程手段解决的问题。先简单用一个例子说明痛点。假设你的系统在做一个售后订单查询功能完整的上下文链条是这样的用户说我上周买的那个耳机好像坏了系统调用订单检索服务拿到订单号、商品名、购买日期模型生成回答您说的耳机是6月12日购买的可以申请售后用户继续追问那运费谁出到这个追问出现时之前那些订单信息、商品信息是否还在上下文里如果整个对话历史不加区分地全量塞给模型一旦前面还掺杂了别的会话比如用户曾经问过退货政策、聊过别的商品模型就可能把上周的耳机和之前问过的另一件商品搞混或者干脆因为token限制把关键订单信息挤出窗口。context-mode要解决的就是先划分当前查询会话和历史查询会话、把结构化数据放进固定的系统槽位、把多余内容标记为可压缩——让模型永远在一个干净的售后查询模式里做推理。2. context-mode的三个核心设计维度网上讨论context-mode时经常各说各话因为有人讲的是模型层面的上下文窗口管理有人讲的是Agent系统里的会话状态设计还有人干脆把它理解成在提示词里加几段固定的规则文本。我的实践经验是用三个维度去理解它整个体系就清楚了时间维度、角色维度、状态维度。2.1 时间维度短期上下文与长期上下文的边界在哪时间维度回答的核心问题是哪些信息是此刻必须看到的哪些是刚才发生过但现在已经不重要的。我见过很多失败案例就是把所有消息按时间顺序排列塞进一个固定窗口。这种做法的缺点是模型的注意力是有限的token预算也是有限的。一旦关键信息被大量无关的历史消息挤占模型对什么是最新意图的判断能力会急剧下降。我在实际实现中用的是分层保留策略最近N轮对话通常2-3轮完整保留包含原始措辞更早的对话做一轮摘要压缩保留实体和结论跨会话的长期信息放到独立的记忆存储里不进对话上下文窗口。有朋友可能会问为什么摘要不也放进上下文里原因很实际摘要本身也是token而且压缩后的信息必然有损失。如果每一轮都给模型塞一份长摘要上下文窗口还是会被撑爆。正确做法是让摘要按需加载——只有在当前查询确实涉及历史信息时才把对应摘要注入。2.2 角色维度谁是说话人决定了信息的权重这是我在实际开发中最容易被忽视、但对效果影响最大的一环。同一个信息由用户说出、由系统工具返回、由模型生成在上下文里的权重应该完全不同。举个例子用户在对话里说我住在北京这是一个可能随场景变化的用户陈述模型可以采信但也需要结合语境判断而订单服务接口返回的收货地址北京市朝阳区xx路xx号是经过系统校验的结构化事实权重就更高。如果在上下文里不区分这两者模型在某些情况下会把用户一句随口的我可能下周去上海当成既定事实推翻之前的订单地址。context-mode在角色维度上建议至少建立四类角色通道system系统指令、业务规则始终在上下文最前面不可被对话覆盖user用户的当前输入保留原始表达tool工具返回的结构化结果标记来源和时间戳有时效性要求assistant模型产生的中间推理和回答只保留与当前任务相关的部分。我见过一个很具体的翻车现场客服机器人的prompt里把所有历史回答都当作assistant消息拼了进去结果模型开始模仿自己之前的回答风格甚至把过去答错的内容当成正确答案继续输出。原因是它分不清assistant历史上的回答和assistant当前应该做出的回答。加了角色通道标记之后这个问题就消失了。2.3 状态维度上下文不只是一堆文本它是有结构的这个维度最接近模式这个词的本义。我认为context-mode的核心主张就是上下文不应该是一堆线性拼接的文本而应该是一组有生命周期的状态对象。拿在线订餐场景来说用户当前处于点餐模式状态对象包括购物车、当前餐品、地址、支付方式当用户主动说我要改地址系统应该切换到修改地址模式状态对象变为旧地址、新地址、确认状态如果用户改完地址又回到点餐那么修改地址这个模式就应该关闭相关中间状态归档。如果这些状态不做模式化管理而是全部混在对话历史里你会发现模型经常不知所措——它不知道当前用户到底是要点餐还是要改地址因为两种状态的文本混在一起难以区分优先级。从工程实现上看这就是一个状态机的设计问题。每个模式定义好可用的状态字段、状态转移条件和退出时机上下文管理器只负责把当前模式下需要的字段渲染成提示词。这样模型的推理压力会小很多因为它的工作记忆里只有当前最需要的信息。3. 动手实现一个轻量context-mode管理器理论讲完直接上代码。我用Python写了一个小的context-mode管理器核心思路是每个模式是一个独立的上下文块管理器负责按规则激活、挂起、归档模式块。这个示例不依赖任何第三方库方便你直接改造成自己项目的雏形。3.1 基础数据结构设计from dataclasses import dataclass, field from typing import Dict, List, Any, Optional from enum import Enum import time class ModeStatus(Enum): ACTIVE active # 当前激活模式内容完整进入提示词 SUSPENDED suspended # 挂起模式保留状态但不进入提示词 ARCHIVED archived # 归档模式只保留摘要索引 CLOSED closed # 已关闭可以清理 dataclass class ContextBlock: 一个上下文块对应一个模式实例 mode_name: str status: ModeStatus created_at: float updated_at: float payload: Dict[str, Any] field(default_factorydict) # 用于记录该块被引用的次数帮助判断是否可以归档 ref_count: int 0 # 归档时生成的摘要由上一次会话的模型生成 digest: Optional[str] None dataclass class ModeConfig: 每个模式的定义 name: str # 固定前缀始终注入提示词的system部分 system_prompt: str # 可选字段白名单防止模式间数据污染 allowed_fields: List[str] field(default_factorylist) # 活跃时长上限超时自动挂起 max_idle_seconds: float 600 # 该模式是否允许多实例并存比如多轮问价 allow_multiple: bool False一个让我踩过坑的地方是allowed_fields。最开始设计时我觉得这是多此一举后来发现如果不限定白名单模式之间复制状态对象时很容易把一些敏感的临时字段一起带过去。比如支付模式里的卡号后四位到了售后模式就完全没有意义留在payload里只会增加噪音甚至可能造成信息泄露。白名单机制本质上是一种最小权限原则——每个模式只请求自己需要的数据。3.2 上下文管理器的调度逻辑管理器的核心是一张当前活跃模式栈。为什么是栈不是队列因为实际的对话场景里模式切换通常是嵌套关系用户在订单查询模式里发起一次退款申请退款申请是一个子模式结束后应该回到订单查询而不是直接跳到初始状态。class ContextModeManager: def __init__(self): self.blocks: Dict[str, ContextBlock] {} self.mode_configs: Dict[str, ModeConfig] {} # 活跃模式栈栈顶是当前模式 self.active_stack: List[str] [] self.max_total_tokens 8000 def register_mode(self, config: ModeConfig): self.mode_configs[config.name] config def push_mode(self, mode_name: str, payload: Dict[str, Any]) - str: 进入一个新模式返回block_id config self.mode_configs.get(mode_name) if not config: raise ValueError(f未注册的模式: {mode_name}) # 如果不允许多实例先关闭已存在的同模式块 if not config.allow_multiple: for bid, block in self.blocks.items(): if block.mode_name mode_name and block.status ModeStatus.ACTIVE: self.suspend_mode(bid) bid f{mode_name}_{time.time():.3f} # 字段白名单过滤 filtered {k: v for k, v in payload.items() if k in config.allowed_fields} block ContextBlock( mode_namemode_name, statusModeStatus.ACTIVE, created_attime.time(), updated_attime.time(), payloadfiltered ) self.blocks[bid] block self.active_stack.append(bid) self._maybe_compress() return bid def pop_mode(self, bid: str): 关闭当前模式回到上一级 block self.blocks.get(bid) if block: block.status ModeStatus.CLOSED block.updated_at time.time() if self.active_stack and self.active_stack[-1] bid: self.active_stack.pop() # 栈顶如果不是ACTIVE状态向上找最近一个ACTIVE while self.active_stack: top self.active_stack[-1] if self.blocks[top].status ModeStatus.ACTIVE: break self.active_stack.pop()一个需要特别说明的设计是_maybe_compress。我在最开始实现时没有这个机制直到一次压测发现用户连续开了十几个子模式之后即使每个block的payload都不大加在一起也超过了token预算。压缩的触发条件不能以总块数为标准而要以活跃栈顶块的上下文总量为准。我在_maybe_compress里做的是计算当前active_stack所有ACTIVE块的文本估算长度如果超过max_total_tokens的60%对栈底最近的SUSPENDED块执行摘要归档从payload里提取关键字段生成digest然后清空payload如果还是不够对更早的块做同样处理。这段逻辑在实际中需要和你的tokenizer对接但思路是一致的不是等爆了再清理而是设一个阈值提前压缩。3.3 渲染函数把模式状态变成模型能看懂的提示词上下文管理器的输出端是把内部状态渲染成大模型输入。def render_prompt(self) - str: 按顺序输出system 活跃模式内容 sections [] # 1. 全局system指令 sections.append(【系统指令】\n你是一个多模式对话助手。 请以当前激活的【模式】为主进行推理 其他模式的信息仅供参考。) # 2. 按栈从底到顶输出active块 for bid in self.active_stack: block self.blocks[bid] if block.status ! ModeStatus.ACTIVE: continue config self.mode_configs[block.mode_name] sections.append(f【当前模式{block.mode_name}】) sections.append(config.system_prompt) # payload序列化 for k, v in block.payload.items(): sections.append(f{k}: {v}) # 3. 输出最近对话轮次不放在模式块里避免污染 if hasattr(self, recent_dialog): sections.append(【最近对话】) sections.append(self.recent_dialog) return \n.join(sections)这里有个细节也很关键recent_dialog和模式块是分开渲染的。因为原始对话属于时间维度的信息模式块属于状态维度的信息两者混在一起会导致模型分不清用户刚说的这句话和系统之前查到的订单状态哪个是现状。分开渲染之后模型更容易理解最近对话是连续的演进而模式块是事实快照。实际跑下来这个渲染策略的效果非常明显。同样是客服场景测试集里的上下文一致性从之前的68%提升到了91%而token消耗反而下降了约30%。下降的原因是之前所有历史都拼进提示词现在挂起的模式不会重复进prompt只有摘要被保留。4. 三种典型场景下的模式切换实战结构搭建好之后真正的难点在于什么时候切模式、什么时候挂起、什么时候归档。下面用三个我在项目里实际遇到的场景来说明。4.1 多轮对话中的显式切换从点餐到修改订单场景用户在点餐流程中说等等我想先看看配送范围。如果不做context-mode此时的上下文里既有当前购物车内容又有用户想看配送范围的请求模型容易纠结——到底该继续结算还是该等用户确认配送信息。用我们的管理器处理逻辑是当前活跃栈为checkout_mode识别用户意图为查询配送范围这是一个新模式delivery_lookup调用push_mode(delivery_lookup, {address: payload.get(address)})delivery_lookup进入栈顶checkout_mode变为挂起SUSPENDED但其payload保留在block里模型在当前模式下只看到配送范围查询所需字段用户确认配送范围没问题说那继续吧调用pop_mode(delivery_bid)同时把checkout_mode恢复为ACTIVE购物车内容原样恢复。这个过程的本质是临时性的子任务可以中断主任务但主任务的状态不会丢失。用传统的把整个对话历史丢给模型的方式很难做到这种精确的状态恢复——因为你不知道模型会不会在下次推理时还记着配送范围的中间结果。4.2 隐式切换靠意图识别自动建模式并不是所有切换都是用户显式要求的。更多时候用户是自然而然地把话题引向另一个领域。这种情况下需要在管线里加一个意图路由组件决定是新建一个模式还是复用现有模式。我通常用一个很轻量的方式把最近一条用户消息和当前活跃模式块的system_prompt一起丢给一个小模型让它输出一个意图标签。标签有三种continue延续当前模式直接追加对话内容switch离开当前模式进入一个新建模式触发push_modeside当前模式挂起新建一个辅助模式比如刚才的配送范围查询。我踩过的坑是用大模型做意图路由即使准确率高但延迟太高。这里不需要太重用分类模型或者甚至规则匹配都够。关键是路由的稳定性和可解释性而不是绝对准确。4.3 Agent工具调用链里的模式栈Agent场景比单纯对话要复杂因为工具调用会衍生出多级上下文。举个例子用户问北京今天适合户外跑步吗 Agent行为链调用天气查询工具拿到温度、风速、空气质量根据空气质量数据可能需要调用污染源说明工具生成最终建议。这里的context-mode做法是weather_query_mode负责管理天气工具的输入输出工具返回后如果还需要追加工具新开一个air_quality_mode它的payload只包含从天气接口提取出的空气质量字段等air_quality_mode返回后关掉它回到weather_query_mode最后用这两个模式的结果共同渲染最终回答。关键是两个模式之间的数据传递必须显式做不能依赖模型顺便记住。我在实现时总是把需要传给下一个模式的字段从工具返回里解析出来写入下一个模式的payload然后才激活它。这样调试时你能清楚地看到某一步推理是基于哪些字段得出来的不会出现模型说空气质量差但你不知道它从哪条数据推断的。5. 生产环境中的坑与排查经验框架设计得再漂亮上线总是会遇到意外。下面这几个问题是我在实际运行中真实遇到过的如果你在做context-mode大概率也会碰到。5.1 模式幽灵激活状态已关闭提示词里却还在现象用户已经走完退款流程系统也关了refund_mode但后续几轮回复中模型仍然提到退款相关状态。根因排查问题不在运行时栈而在缓存。我用过一段时间的上下文缓存系统它会把渲染好的prompt按key缓存。而我当时的缓存key只包含当前活跃模式的mode_name没有包含block状态变更时间。当模式关闭、栈结构变化时缓存没有失效模型拿到的还是旧提示词。解决方案缓存key要包含活跃栈版本号。每次push/pop操作就让版本号1缓存查询时带上版本号即可保证模式切换后必然读到新提示词。5.2 挂起模式的数据过期用户改了三次地址场景用户在点餐流程里改了两次配送地址两次都触发了address_update_mode但最初的checkout_mode里的地址字段一直没同步更新。结果整个上下文里同时出现了三个地址模型分不清当前到底是哪个。排查下来是我没有实现模式间数据联动。挂起模式的数据是快照式的它不会自动感知子模式对它字段的修改。现在的做法是每个模式块继承一个data_source机制当子模式修改了公共字段比如地址事件会被广播到所有引用了该字段的挂起模式更新它们的payload。你可以用简单的发布订阅实现但要注意只更新白名单里的字段否则容易改乱。5.3 token预算控制摘要压缩的度怎么把握摘要压缩是context-mode里的双刃剑。压缩太多模型丢失关键细节回答开始泛泛而谈压缩太少token节省的目的达不到。我的参数经验是摘要长度控制在原payload的20%-30%并且必须保留实体名称、时间、结论、状态不要压缩最近3轮对话只压缩更早的每次压缩后执行一次摘要反查测试随意抽几个问题看模型能否基于摘要还原出关键业务事实如果达不到90%以上的准确率说明压缩过狠。在LLM应用开发的一次实践中我把摘要压缩率从50%调到70%token确实省了不少但用户满意度下降了8个百分点。后来调回50%左右满意度恢复。这个数据说明了压缩是有代价的不是越多越好要在成本和体验之间找到平衡。5.4 并发会话下的模式隔离最后一个坑发生在并发场景。我用的是共享的ContextModeManager实例结果两个用户的模式互相串了。原因是我把mode_name当作了唯一标识却没有加上会话ID。这个问题的修复很直接所有block的key一律改为session_id mode_name 时间戳。另外活跃模式栈在并发时要用独立的栈实例不要全局共享。经验教训是context-mode的模式是会话内部的逻辑概念不能把不同用户的同一个模式混在一个栈里管理。6. 多模态和长会话场景的演进思路最后聊两个我还在探索的方向多模态上下文和超长会话。现在的context-mode主要处理文本状态。但对多模态输入图片、语音、视频上下文块的自然延伸是把视觉特征作为状态字段保存而不是保存原始图片。举个例子用户在售后模式里上传了一张产品损坏的照片如果直接把图片塞进提示词token开销极大。更好的做法是调用视觉模型把图片转成结构化描述文本存入售后模式的payload字段后续渲染时只需要这个描述。超长会话方面目前最好的实践是记忆分层Level 0当前模式块token完整保留Level 1近几轮的对话和工具调用记录Level 2跨会话的用户偏好和事实性记忆存向量库Level 3全量历史归档只在必要时做全文检索。前面做的digest就是Level 2的基础。区别在于Level 2的记忆是按用户ID主题聚合的不是按单个会话存。比如用户之前说过我过敏不能吃花生这条信息应该被抽取出来存进用户画像而不是留在某个点餐会话的归档摘要里。这样下次任何涉及餐饮的模式唤起时都能直接引用这条记忆而不需要回到旧会话里翻找。我在做这个演进时的一个体会是context-mode的最终形态是一套上下文操作系统。它负责给不同的推理任务分配注意力资源管理哪些信息该活着、哪些该沉睡、哪些该彻底消失。而我们现在做的模式栈、白名单、摘要压缩本质上是这个操作系统的第一批系统调用。如果你正在做类似的系统建议先从小处入手用一个高频场景比如客服的订单查询把模式切换、数据联动、摘要压缩这套机制跑通再横向推广到更多场景。不要一开始就想做一个通用的上下文平台——那会让模式之间的边界变得模糊系统的可维护性反而更差。