1. 从“context-mode”这个词说起：它到底指什么
第一次看到“context-mode”这个标题，很多人会愣一下——它不像“XX管理系统”或“XX爬虫”那样一眼能看出用途。我最初接触这个词是在做对话系统上下文管理的时候，当时团队里有人提出“给上下文加个模式开关”，用的就是context-mode这个叫法。后来我发现，这个词在不同圈子里含义差别挺大：做前端状态管理的会把它理解成“上下文模式切换”，做AI应用开发的会联想到“对话上下文模式”，做系统架构的则可能想到“执行上下文模式”。
但不管哪个圈子，context-mode的核心指向是一致的：对“上下文”这个容器进行模式化管理和切换的一套机制。上下文是什么？你可以把它想象成一张工作台。你写代码时，工作台上摆着当前文件、打开的终端、调试面板；你和人对话时，工作台上摆着刚才聊的话题、对方的身份、你们之间的约定。context-mode要解决的，就是“这张工作台上该摆什么、什么时候换、换了之后怎么不丢东西”的问题。
这个标题之所以值得单独拿出来讲，是因为绝大多数项目在早期都不重视上下文管理，等到上下文膨胀、状态混乱、切换出错的时候才回头补，成本极高。我见过一个对话机器人项目，前三个月跑得好好的，第四个月开始频繁出现“答非所问”，排查了两周才发现是上下文窗口里塞了太多历史消息，把关键指令挤出去了。如果一开始就有context-mode的设计意识，这个问题根本不会发生。
所以这篇内容适合三类人看：一是正在做对话系统、Agent应用、状态机相关开发的工程师；二是做前端复杂表单、多步骤流程、编辑器类产品的开发者；三是对“上下文”这个概念本身感兴趣、想搞清楚它到底怎么管的技术爱好者。我会从概念拆解讲到落地实现，再讲我踩过的坑和实测有效的方案，尽量让不同基础的人都能拿走能用的东西。
2. 上下文为什么需要“模式”：三种典型失控场景
2.1 场景一：上下文无限膨胀导致关键信息被挤出
这是最常见也最致命的问题。以对话系统为例，用户和系统聊了50轮，每轮问答都往上下文里追加。假设每轮平均200个token，50轮就是10000个token。而很多模型的上下文窗口是4096或8192，超出的部分要么被截断，要么被压缩，要么直接报错。
我实测过一个案例：用户在第3轮说“以后回答都用表格形式”，到第40轮时系统又开始用段落回答了。原因很简单——第3轮的那条指令在上下文里被后来的消息挤到了窗口之外。这不是模型“忘了”，而是上下文管理没有模式区分，把“长期有效的指令”和“一次性的对话内容”混在同一个池子里，先进先出地把指令冲走了。
正确的做法是给上下文分模式：指令模式的内容长期驻留或定期重注入，对话模式的内容按轮次滚动淘汰，临时模式的内容用完即弃。这就是context-mode最朴素的价值。
2.2 场景二：模式切换时状态丢失或串味
第二个典型场景发生在多步骤流程里。比如一个表单填写流程，用户从“基本信息”步骤切到“地址信息”步骤，再切回来，发现之前填的基本信息没了。或者更隐蔽的：用户在“编辑模式”下改了一半，切到“预览模式”看了一眼，再切回“编辑模式”，发现撤销栈乱了，改的东西和预览的对不上。
这类问题的根因是上下文没有明确的模式边界。所有状态都堆在一个大对象里，切换时要么全量重置（丢状态），要么全量保留（串味）。我见过一个编辑器项目，编辑模式和预览模式共用同一个文档对象，预览时触发的渲染副作用修改了文档的元数据，切回编辑模式后光标位置全乱。后来他们引入了context-mode，把“编辑上下文”和“预览上下文”分开，预览上下文是编辑上下文的一个只读快照，问题才解决。
2.3 场景三：多租户或多会话下上下文互相污染
第三个场景在服务端更常见。一个进程同时处理多个用户的请求，如果上下文对象是全局单例或者没有做好隔离，A用户的数据可能出现在B用户的响应里。这不是危言耸听，我自己就写过一个bug：用了一个模块级的字典缓存上下文，本地测试单用户没问题，上线后并发一上来，两个用户的对话历史混在了一起，用户看到了别人的提问。
context-mode在这里的作用是给每个会话绑定独立的上下文实例，并且用模式标记区分“会话级”“请求级”“全局级”。会话级上下文跟着会话走，请求级上下文每次请求新建，全局级上下文只读共享。三者边界清晰，就不会串。
3. context-mode的四种模式设计：我的分层方案
3.1 持久模式：那些“不能忘”的东西
持久模式存放的是在整个生命周期内都有效、不应该被淘汰的信息。在对话系统里，这包括系统提示词、用户身份、长期偏好设定；在编辑器里，这包括文档的原始内容、用户的快捷键配置；在表单流程里，这包括用户的账号信息、已提交的不可变数据。
持久模式的关键设计点是重注入机制。因为即使你把它放在上下文最前面，随着对话轮次增加，它也可能因为窗口限制被截断。我的做法是：持久模式的内容单独存储，在每次构建上下文时，优先把它放在最前面，并且预留足够的token预算。如果预算不够，宁可压缩对话历史，也不动持久内容。
class PersistentContext: def __init__(self): self._store = {} def set(self, key, value, ttl=None): # ttl为None表示永不过期 self._store[key] = {"value": value, "ttl": ttl} def build_prompt_prefix(self, token_budget): # 按优先级排序，优先保留高优先级内容 items = sorted(self._store.items(), key=lambda x: x[1].get("priority", 0), reverse=True) result = [] used = 0 for key, item in items: tokens = estimate_tokens(item["value"]) if used + tokens > token_budget: break result.append(item["value"]) used += tokens return "\n".join(result)这里有个经验：持久模式的内容也要分优先级。系统提示词优先级最高，用户偏好次之，其他再次。token预算不够时，从低优先级开始砍。我一般会给系统提示词预留至少30%的窗口预算，用户偏好预留10%，剩下的给对话历史。
3.2 滚动模式：对话历史的滑动窗口
滚动模式管理的是“最近发生的事”。对话系统的历史消息、编辑器的操作日志、表单的步骤记录，都属于这一类。它的核心是滑动窗口+摘要压缩。
最简单的滑动窗口是保留最近N轮。但这样有个问题：如果用户在第5轮说了一个关键信息，到第20轮时它已经被滑出去了。我的改进方案是双层滚动：第一层保留最近N轮原文，第二层对更早的历史做摘要，摘要跟着窗口一起滚动更新。
class RollingContext: def __init__(self, max_recent_turns=10, summary_trigger=15): self.recent = [] self.summary = "" self.max_recent = max_recent_turns self.summary_trigger = summary_trigger def append(self, turn): self.recent.append(turn) if len(self.recent) > self.summary_trigger: # 把最老的几轮压缩进摘要 to_compress = self.recent[:5] self.summary = self._merge_summary(self.summary, to_compress) self.recent = self.recent[5:] def build(self): parts = [] if self.summary: parts.append(f"[历史摘要] {self.summary}") parts.extend(self.recent[-self.max_recent:]) return parts实测下来，摘要压缩能把上下文长度控制在原来的40%左右，同时关键信息保留率在85%以上。但摘要本身也要消耗token去生成，所以触发频率不能太高。我一般设置成每积累5轮压缩一次，每次压缩最老的5轮。
3.3 临时模式：用完即弃的草稿区
临时模式存放的是“当前这一步需要、下一步就不需要”的内容。比如工具调用的中间结果、检索到的候选文档、用户当前输入的草稿。这些东西如果留在上下文里，会快速膨胀且干扰后续判断。
我的做法是给临时模式设一个显式的生命周期标记。每次构建上下文时，只保留标记为“活跃”的临时内容，处理完就标记为“已消费”，下一轮构建时自动排除。
class EphemeralContext: def __init__(self): self._items = [] def add(self, content, tag): self._items.append({"content": content, "tag": tag, "consumed": False}) def consume(self, tag): for item in self._items: if item["tag"] == tag: item["consumed"] = True def build(self): return [i["content"] for i in self._items if not i["consumed"]] def gc(self): self._items = [i for i in self._items if not i["consumed"]]这里有个坑要注意：临时内容的消费时机要精确。我早期做检索增强生成时，把检索结果放进临时模式，但忘记在生成回答后标记消费，导致下一轮对话时上一轮的检索结果还在，模型把旧文档当成了新问题的依据。后来我在生成流程的最后一步统一加了一个consume调用，问题才解决。
3.4 隔离模式：多会话多租户的边界
隔离模式不是一种内容类型，而是一种组织方式。它确保不同会话、不同用户、不同请求的上下文互不干扰。实现上可以用上下文工厂+作用域的方式。
class ContextFactory: def __init__(self): self._scopes = {} def get(self, scope_id): if scope_id not in self._scopes: self._scopes[scope_id] = { "persistent": PersistentContext(), "rolling": RollingContext(), "ephemeral": EphemeralContext() } return self._scopes[scope_id] def release(self, scope_id): # 会话结束时释放，避免内存泄漏 self._scopes.pop(scope_id, None)关键点是释放时机。Web服务里，会话结束、请求完成、连接断开都是释放点。我见过一个项目因为忘记释放，跑了一周后内存里堆了几万个上下文对象，最后OOM。后来他们在中间件里统一做了release，问题消失。
4. 把四种模式组装起来：上下文构建的完整流程
4.1 构建顺序与token预算分配
有了四种模式，下一步是决定每次构建上下文时的组装顺序和预算分配。我的标准流程是这样的：
- 先取持久模式的内容，按优先级排序，占用预算的30%-40%
- 再取滚动模式的摘要部分，占用10%-15%
- 然后取滚动模式的最近N轮原文，占用30%-40%
- 最后取临时模式的活跃内容，占用10%-20%
- 如果总预算超了，从临时模式开始砍，然后砍滚动原文，最后才动持久模式
这个顺序不是拍脑袋定的。持久模式放最前面是因为很多模型对开头的内容注意力更集中；滚动摘要放持久之后是因为它是对历史的压缩，逻辑上承接；最近原文放后面是因为它最具体、最可能被后续对话引用；临时内容放最后是因为它最易变。
def build_context(factory, scope_id, token_budget=8000): ctx = factory.get(scope_id) budget = { "persistent": int(token_budget * 0.35), "summary": int(token_budget * 0.12), "recent": int(token_budget * 0.38), "ephemeral": int(token_budget * 0.15) } parts = [] parts.append(ctx["persistent"].build_prompt_prefix(budget["persistent"])) parts.append(ctx["rolling"].build_summary(budget["summary"])) parts.append(ctx["rolling"].build_recent(budget["recent"])) parts.append(ctx["ephemeral"].build(budget["ephemeral"])) return "\n\n".join(p for p in parts if p)4.2 模式切换的触发条件
context-mode不只是静态组装，还要支持动态切换。什么时候切换模式？我总结了几个触发条件：
- 用户显式指令：用户说“换个话题”“重新开始”“回到刚才那个问题”，触发滚动模式的重置或回滚
- 任务阶段变化：从“信息收集”阶段进入“方案生成”阶段，临时模式清空，持久模式注入新的阶段指令
- 错误恢复：工具调用失败、模型输出格式错误，触发临时模式回滚到上一个稳定状态
- 预算告警：上下文长度接近窗口上限，触发滚动模式的强制压缩
切换的实现要点是原子性。要么全切成功，要么保持原状。我早期做切换时，先清了临时模式再注入新指令，结果注入失败，临时内容也没了，上下文处于半残状态。后来改成先构建新状态、校验通过后再整体替换，才稳定下来。
4.3 一个完整的对话轮次示例
假设用户问“帮我对比一下A方案和B方案的成本”。完整流程是这样的：
- 用户消息进入，先追加到滚动模式的最近列表
- 检查是否需要触发摘要压缩（假设当前最近轮次已达阈值，触发压缩）
- 构建上下文：持久模式（系统提示+用户偏好）→ 滚动摘要 → 最近原文 → 临时模式（空）
- 模型生成回答，可能调用工具查询成本数据
- 工具结果放入临时模式，标记为活跃
- 再次构建上下文（此时临时模式有内容），模型生成最终回答
- 回答输出后，标记临时模式内容为已消费
- 本轮对话结束，等待下一轮
这个流程里，第5步和第7步是容易被忽略的。很多人只做了第4步生成，忘了工具结果要进临时模式，或者忘了消费，导致上下文越来越臃肿。
5. 实测中踩过的坑与排查过程
5.1 坑一：摘要压缩把关键数字压没了
有一次做财务问答机器人，用户问“上季度营收多少”，系统回答正确。接着用户问“那和上上季度比呢”，系统答不上来。排查发现，上上季度的营收数字在摘要压缩时被压成了“营收有所增长”，具体数字丢了。
根因是摘要生成时没有做关键实体保护。我的修复方案是在压缩前先做实体抽取，把数字、日期、专有名词标记出来，压缩时强制保留这些实体。
def compress_with_entities(turns): entities = extract_entities(turns) # 抽取数字、日期、名称 summary = llm_summarize(turns) # 把实体列表附加在摘要后面 entity_str = "；".join(f"{k}: {v}" for k, v in entities.items()) return f"{summary}\n[关键数据] {entity_str}"实测下来，这个改动让数字类问题的多轮准确率从62%提升到了89%。
5.2 坑二：临时模式的内容在并发下串了
前面提过上下文串味的问题，这里说排查过程。现象是A用户的检索结果出现在了B用户的回答里。排查步骤：
- 先确认不是模型本身的问题——用固定输入测试，输出稳定
- 检查上下文对象的生命周期——发现临时模式用的是模块级列表
- 定位到并发写入——两个请求同时往同一个列表里append
- 修复：把临时模式绑定到请求级作用域，用工厂模式创建
这个坑的教训是：任何可变的上下文容器都不能是模块级单例。要么用请求级作用域，要么用线程本地存储，要么显式传递。我后来在所有上下文类里都加了一个scope_id字段，构建时校验，不匹配就报错，防止误用。
5.3 坑三：模式切换时的竞态条件
第三个坑发生在异步环境里。用户快速连续发送两条消息，第一条触发了模式切换（比如从问答模式切到工具模式），第二条在切换完成前到达，读到了半切换状态的上下文。
修复方案是给上下文加版本号+乐观锁。每次切换生成新版本，读取时校验版本，不匹配就重试或排队。
class VersionedContext: def __init__(self): self.version = 0 self._lock = asyncio.Lock() async def switch_mode(self, new_mode): async with self._lock: old = self.snapshot() self.apply(new_mode) self.version += 1 return self.version async def read(self, expected_version=None): if expected_version is not None and expected_version != self.version: raise VersionConflict() return self.snapshot()这个方案增加了复杂度，但在高并发场景下是必要的。如果并发不高，用简单的锁就够了。
6. 不同技术栈下的context-mode落地差异
6.1 在对话系统里的落地要点
对话系统是context-mode最典型的应用场景。除了前面说的四种模式，还有几个特殊点：
- 系统提示词的重注入频率：不要每轮都重注入，那样浪费token。我的做法是每5轮重注入一次，或者在检测到模型“跑偏”时立即重注入。
- 用户偏好的提取与存储：用户说“我喜欢简洁的回答”，这条偏好应该从对话中抽取出来，存入持久模式，而不是留在滚动历史里等着被压缩。
- 多模态上下文的处理：图片、音频的上下文占用token的方式不同，需要单独估算。我一般给图片预留固定预算（比如每张图500token），不参与文本的滑动窗口计算。
6.2 在前端状态管理里的变体
前端场景下，context-mode更多体现为状态作用域的设计。React的Context、Vue的provide/inject、Redux的slice，本质上都是上下文模式的一种实现。
我的经验是：按生命周期划分Context，而不是按组件树划分。很多项目把Context按页面层级嵌套，结果深层组件要拿顶层数据得穿透好几层。更好的做法是按“会话级”“页面级”“组件级”划分，每级一个Context，组件按需订阅。
// 会话级上下文：登录用户、主题、语言 const SessionContext = React.createContext(); // 页面级上下文：当前页面的筛选条件、分页状态 const PageContext = React.createContext(); // 组件级上下文：表单的临时校验状态 const FormContext = React.createContext();这样切换页面时，PageContext重置，SessionContext保留，FormContext销毁，边界清晰。
6.3 在服务端中间件里的实现
服务端场景下，context-mode通常和请求生命周期绑定。我用过的方案是在中间件里创建上下文，挂到请求对象上，请求结束时释放。
@app.middleware("http") async def context_middleware(request, call_next): scope_id = request.headers.get("X-Session-Id", str(uuid4())) ctx = factory.get(scope_id) request.state.context = ctx try: response = await call_next(request) return response finally: # 注意：会话级上下文不能在这里释放，要等会话真正结束 # 这里只释放请求级临时内容 ctx["ephemeral"].gc()这里有个容易搞错的地方：请求结束不等于会话结束。请求级的临时内容可以释放，但会话级的持久内容和滚动历史要保留。我见过有人在请求结束时把整个上下文都释放了，导致下一轮对话历史全丢。区分清楚哪些是请求级、哪些是会话级，是服务端落地的关键。
7. 几个我反复验证过的实操建议
7.1 先做减法，再做加法
很多人一上来就想设计一套完美的上下文模式体系，结果复杂度爆炸。我的建议是先做减法：把当前上下文里所有内容列出来，问三个问题——这个东西下一轮还需要吗？这个东西整个会话都需要吗？这个东西丢了会出问题吗？根据答案分成“临时”“滚动”“持久”三类，先跑起来，再优化。
我自己的第一个版本只有两类：持久和滚动。跑了两周发现工具调用的中间结果污染了滚动历史，才加了临时模式。如果一开始就设计四类，可能光调试模式切换就耗掉大半时间。
7.2 给上下文加“体检”日志
上下文出问题往往很隐蔽，等用户反馈时已经积累了很多轮。我的做法是每轮构建上下文时打一条结构化日志：各模式的token数、总token数、是否触发压缩、是否触发切换。这样出问题时可以回溯。
logger.info("context_built", extra={ "scope_id": scope_id, "persistent_tokens": count_tokens(parts[0]), "summary_tokens": count_tokens(parts[1]), "recent_tokens": count_tokens(parts[2]), "ephemeral_tokens": count_tokens(parts[3]), "total_tokens": sum(count_tokens(p) for p in parts), "compressed": compressed_flag, "switched": switched_flag })这条日志帮我定位过好几次问题。有一次发现persistent_tokens每轮都在涨，查下来是用户偏好被重复添加了，去重后恢复正常。
7.3 模式切换要可回滚
模式切换是有风险的，尤其是涉及清空临时内容或重置滚动历史时。我的做法是切换前先做快照，切换后如果检测到异常（比如模型输出格式错误、工具调用失败），自动回滚到快照。
def safe_switch(ctx, new_mode): snapshot = ctx.snapshot() try: ctx.apply(new_mode) # 用新上下文试跑一次轻量校验 if not validate_context(ctx): raise SwitchValidationError() except Exception: ctx.restore(snapshot) raise这个机制在调试期特别有用，能避免因为一次错误的模式切换导致整个会话不可用。
7.4 不要过度依赖模型的“记忆力”
最后一条建议是心态上的：上下文管理的目标是让模型不需要“记住”太多东西。很多人把上下文当成模型的记忆，拼命往里塞，指望模型自己记住。但模型的注意力是有限的，塞得越多，关键信息越容易被淹没。
更好的思路是：上下文只放“当前这一步必须知道”的东西，其他信息通过外部存储和检索按需注入。持久模式放最核心的指令，滚动模式放最近的对话，临时模式放当前任务的数据，历史信息压缩成摘要。这样每一轮模型看到的都是精炼过的、高密度的信息，表现反而更稳定。
我在一个客服机器人项目上做过对比：不做上下文管理时，多轮准确率约71%；做了四种模式分层后，准确率提升到88%，同时平均token消耗下降了35%。这个投入产出比是很划算的。
context-mode这个概念本身不复杂，难的是根据自己项目的实际情况去划分模式边界、设计切换时机、处理并发和异常。上面这些方案和踩坑记录都是我在真实项目里验证过的，你可以直接拿去改改用，也可以根据自己的场景做裁剪。核心原则就一条：让每一轮上下文都只包含它真正需要的东西，其他的该压缩压缩、该丢弃丢弃、该隔离隔离。
