很多人第一次听到context-mode这个词大概率是在做AI应用、写提示词、或者调对话机器人的时候。但真把它当回事、认真研究过的人不多。我一开始也是这样——总觉得上下文嘛不就是把聊天记录一股脑塞给模型吗直到实际做项目被敲打了几次才意识到上下文模式四个字背后藏着的是对话系统、Agent、文档处理这些场景里最容易被忽略、却又最决定体验上限的东西。这篇文章我想从自己的实操经验出发把context-mode这件事讲透它到底是什么、为什么单独拎出来说、有哪些典型实现思路、怎么写代码落地以及那些文档里不会告诉你的坑。适合正在做LLM应用、写对话机器人、搞AI工作流的朋友也适合想搞懂为什么我的AI总是记不住事的初学者。1. 什么是context-mode别把它当成简单的聊天记录拼接1.1 核心需求的本质context-mode直译是上下文模式但如果你以为它只是把历史消息拼起来再发给模型那就太低估它了。在实际开发中上下文管理的本质是在一个有状态、有交互、有时间跨度的系统里如何组织、筛选、压缩、传递信息给模型让模型在每一步都拿到刚刚好的信息而不是越多越好。我常用一个生活类比来跟朋友解释你找一位新同事帮忙处理事情不可能把过去十年的所有邮件都丢给他也不应该只给一句话。你需要做的是挑出相关的背景、加上最新的诉求、必要时附上之前已经确认过的事实。context-mode就是这套挑背景、加诉求、附事实的自动化机制。在AI应用里上下文至少包含三类信息对话历史用户跟系统之间过往的交流记录决定了一轮对话的连贯性。系统约束角色设定、规则边界、输出格式要求这是模型行为稳定性的底牌。外部数据知识库片段、用户画像、实时工具返回结果让模型不只是空谈。一个真正可用的context-mode要能对这三类信息做统一管理而不是简单地把所有字符串拼在一起。1.2 为什么单独谈模式而不只是上下文我刚入行时有个疑问上下文就是上下文为什么还要聊模式后来做了几个真实项目才发现上下文回答的是有什么模式回答的是怎么用。同一个项目里不同阶段对上下文的需求完全不同。举个例子。我做过一个长文写作助手在系统里需要处理三种场景用户刚打开页面时模型只需要知道任务目标和文档大纲不需要把整本小说都塞进去。用户选中某段文字要求改写时模型需要看到选中的段落、附近段落、以及全文的文体约束。用户问我前面提到的那个人物后来怎么样了时模型需要快速检索全文找到相关片段再回答。如果对这三种场景用同一种上下文策略要么浪费token要么答非所问。这就是模式存在的意义根据当前交互的类型动态调整上下文的构成权重和传递方式。我把这是为上下文路由或上下文策略本质上是把怎么用上下文这件事从业务逻辑里抽出来做成可配置、可复用的一层。2. context-mode的几种典型实现路径2.1 基于窗口的滑动上下文这是最简单、最暴力的实现方式。思路是维护一个消息队列固定保留最近N轮对话。新消息进来老的就被挤出去。很多早期聊天机器人、以及不少LLM API的简易封装默认就是这个逻辑。示例伪代码如下from collections import deque class SlidingWindowContext: def __init__(self, max_rounds10): self.history deque(maxlenmax_rounds) def add_message(self, role, content): self.history.append({role: role, content: content}) def build_prompt(self, system_prompt, user_input): return [ {role: system, content: system_prompt}, *self.history, {role: user, content: user_input}, ]这种模式的优点是实现成本极低、token占用可控、不会出现无限膨胀。缺点也很明显它用时间最近代替了信息重要一旦关键信息出现在较早的轮次就会被无情截掉。我拿它做过一个客服机器人用户在第5轮报了订单号第15轮再问进度时模型已经完全失忆体验非常糟糕。适用场景短对话、无状态的问答、对连贯性要求不高的工具型任务。2.2 基于摘要的结构化上下文为了解决滑动窗口一刀切的问题比较自然的进化方向是摘要压缩。核心思路是老对话不直接丢掉而是定期让模型把前面的内容浓缩成摘要再和最近几轮完整消息一起放入上下文。这里有一个非常关键的参数摘要触发轮次。我的经验是当总消息数超过某个阈值比如8轮就开始触发摘要并且摘要本身也要维护层叠结构——旧摘要和近期摘要放在一起形成蒲公英式的信息组织。让模型既有浓缩的背景又有完整的近期细节。代码层面大概长这样class SummarizingContext: def __init__(self, llm_fn, summary_threshold8): self.llm_fn llm_fn self.summary_threshold summary_threshold self.summary self.recent [] def add_message(self, role, content): self.recent.append({role: role, content: content}) if len(self.recent) self.summary_threshold: self.rollup() def rollup(self): combined f旧摘要{self.summary}\n新消息{self.recent} self.summary self.llm_fn( f请把以下内容压缩为新的摘要保留关键事实\n{combined} ) self.recent [] def build_prompt(self, system_prompt, user_input): return [ {role: system, content: system_prompt}, {role: system, content: f对话摘要{self.summary}}, *self.recent, {role: user, content: user_input}, ]摘要模式比滑动窗口聪明很多但要注意一个隐性成本摘要本身会引入信息失真。模型压缩时天然保留它认为重要的东西而用户真正关心的细节可能恰恰被丢掉。我踩过的一个坑是用户问了某个数字摘要里只留下了用户提到一个金额具体数字早就被压没了。所以后来我坚持在摘要之外额外维护一个关键实体表专门存订单号、金额、日期这种高价值信息。2.3 分层上下文设计再往上走就是支撑复杂Agent和大型应用的分层上下文。说白了把信息按生命周期和价值分成几个层级静态层角色设定、系统规则、全局知识。基本不变化每次请求都带上。会话层本次对话的目标、当前任务列表、阶段性结论。会话内动态更新。记忆层用户偏好、历史事实、跨会话的长期记忆。由外部存储数据库/向量库管理。即时层最近几轮完整消息、工具返回结果、当前用户输入。不同层级的读取策略也不同。静态层每次必读会话层按需注入记忆层通过检索触达只在相关时才放进来即时层全量保留。这套设计的好处是从给模型喂什么变成了给模型按需配比什么。我做过一个多步骤数据分析Agent如果没有分层设计每轮都会把一堆SQL查询结果重复塞给模型最后token爆炸不说模型反而被冗余信息干扰。改成分层后全局规则放静态层当前分析目标放会话层中间结果只保留精简版效果立刻上了一个台阶。3. 手把手实现一个简洁的context-mode模块3.1 需求与接口设计很多人看到分层上下文觉得复杂其实最小可用版本并不难。我建议不要一上来就搞分布式存储和向量检索先从单机内存版开始把接口设计好后面再逐步替换存储层。先明确需求支持多会话隔离不同用户的上下文不互相干扰。支持不同类型消息的分类存储系统、用户、工具结果、摘要。支持按需构建prompt不同调用方可以指定包含哪些层。支持配置上下文长度上限超出后自动压缩。接口可以设计成class ContextManager: def __init__(self, session_id, configNone): self.session_id session_id self.config config or {} self.messages [] def add(self, role, content, metaNone): ... def build_prompt(self, layersNone, include_key_entitiesTrue): ... def compact(self, strategysummary): ...3.2 核心代码落地我直接给出一份可运行的最小实现语言用Python存储用内存字典适合单机小项目或原型验证。import json from datetime import datetime class ContextMode: def __init__(self, max_tokens4096, compact_threshold0.8): self.max_tokens max_tokens self.compact_threshold compact_threshold self.sessions {} def _ensure_session(self, sid): if sid not in self.sessions: self.sessions[sid] { static: [], dialogue: [], key_entities: {}, summary: , updated_at: None, } return self.sessions[sid] def add_static(self, sid, content): session self._ensure_session(sid) session[static].append({content: content, ts: datetime.now().isoformat()}) def add_dialogue(self, sid, role, content): session self._ensure_session(sid) session[dialogue].append({role: role, content: content, ts: datetime.now().isoformat()}) session[updated_at] datetime.now().isoformat() def add_key_entity(self, sid, key, value): session self._ensure_session(sid) session[key_entities][key] value def _estimate_tokens(self, text): # 中文场景粗略估算约1.5个字符算1个token英文约4个字符1个token # 这里为了稳定性统一按字符数估算 return len(text) def _compact(self, session): # 把早期对话合并进摘要 dialogue session[dialogue] keep_count max(1, int(len(dialogue) * 0.3)) to_summarize dialogue[:-keep_count] to_keep dialogue[-keep_count:] combined_text \\n.join( f{item[role]}: {item[content]} for item in to_summarize ) # 这里接入任意LLM摘要函数真实项目中建议用异步 session[summary] f[摘要] {combined_text[:200]}... session[dialogue] to_keep def build_prompt(self, sid, user_input, use_summaryTrue): session self._ensure_session(sid) # 注入前先估算token static_text \\n.join(item[content] for item in session[static]) dialogue_text \\n.join( f{item[role]}: {item[content]} for item in session[dialogue] ) summary_text session[summary] or entities_text json.dumps(session[key_entities], ensure_asciiFalse)[:500] total_text static_text dialogue_text user_input summary_text entities_text estimated self._estimate_tokens(total_text) if estimated self.max_tokens * self.compact_threshold: self._compact(session) prompt [] if static_text: prompt.append({role: system, content: static_text}) if summary_text: prompt.append({role: system, content: f历史摘要{summary_text}}) if entities_text and entities_text ! {}: prompt.append({role: system, content: f关键信息{entities_text}}) prompt.extend(session[dialogue]) prompt.append({role: user, content: user_input}) return prompt这份代码最核心的设计有两点一是token估算前置。我先粗略估算整个prompt的长度逼近阈值时就触发压缩而不是等到请求发出去了才发现超限。估算方式虽然粗糙按字符数但在原型阶段完全够用。真要精确可以接入tokenizer。二是关键实体单独存储。我特意把key_entities独立出来而不是混在对话里。这样即使对话被压缩摘要订单号、人名、金额这些硬信息依然能稳定注入prompt降低摘要失真带来的风险。3.3 关键参数怎么定这里分享几个我反复调出来的经验值供你参考max_tokens指的是构建出的prompt预估上限而不是模型的全部上下文窗口。不要设太满留出20%的空间给模型输出。比如模型支持8K上下文prompt上限建议设在6000左右。compact_threshold我习惯设0.8意思是token占用达到上限80%时就开始压缩。太早压缩会频繁触发摘要浪费摘要请求的成本太晚压缩可能直接超限报错。keep_count比例压缩时保留最近30%的完整对话。这个比例不是死的如果最近对话里有大量代码块或表格比例要再降一些否则完整对话本身就会撑爆上下文。key_entities数量不要贪多控制在10个以内。如果长期记忆要存更多应该走检索而不是全量注入。4. 常见问题与排查技巧4.1 上下文截断后模型失忆这是我遇到最多的问题。现象是对话变长之后模型突然不记得前文的关键信息了。排查思路按顺序来先看压缩逻辑是否被触发。在日志里打印每次构建prompt前后的估算token数和压缩动作。很多时候是阈值设得太低一段长代码就触发了压缩。再看摘要是否保留了关键信息。不要只看摘要字数要看摘要里有没有包含硬信息。我自己习惯在摘要生成后用一段校验提示词比如请判断摘要中是否包含用户提到的订单号没有则列出缺失项。最后检查关键实体表是否有更新。实体表更新往往依赖额外的抽取逻辑如果抽取没跑实体表就是空的那和没存一样。4.2 摘要压缩成本过高摘要模式很吃LLM调用次数。每压缩一次就是一次额外的模型请求既有token成本也有延迟成本。我的优化思路是只压缩需要压缩的部分而不是全部历史。摘要请求的模型可以用更小的模型比如主对话用大模型摘要用快速模型质量损失不大。摘要不一定要在对话过程中实时触发可以放在空闲时异步完成。比如用户停顿的间隙、或者定时任务先把旧对话预处理好。4.3 分层上下文在多用户场景下的扩展上面的示例代码是单机内存版一旦上了生产环境多实例部署就出问题了——用户A的会话在实例1下次请求被负载均衡到实例2内存里的上下文就丢了。解决方案是把session存储抽出来放到Redis或数据库里保持接口不变替换存储实现即可。我建议在设计阶段就把ContextManager做成无状态的服务session_id作为参数传入而不是在类内部持有全局字典。这样后续对接Redis、MongoDB都很顺。别问我为什么这么强调因为我自己当初就是没这么做上线第二天就被运维叫醒改代码的。4.4 一个小技巧给上下文加版本随着迭代我养成了一个习惯在session里加一个context_version字段记录当前上下文策略的版本号。一旦新代码有bug可以快速把线上请求回滚到旧策略而不是整个发布回退。这招在关键业务上救过我两次花的时间成本几乎为零收益却很大。5. 个人经验与扩展方向说实话context-mode这个概念看起来简单真正做深了会涉及很多工程细节。我自己踩过最大的坑是过度设计——一上来就上了向量检索和知识图谱结果小项目根本撑不住复杂度反而拖垮了迭代速度。后来学乖了从滑动窗口做起一步步迭代到摘要、分层每个阶段都能看到明确的收益。如果你现在正在做AI应用我建议从最朴素的方案开始但一定要在一开始就把接口设计得清晰一点。因为上下文策略迟早要升级接口不稳后面全是返工。另外一个很有价值的扩展方向是上下文可观测性。我现在会在每次构建prompt时记录各层的token占比、压缩次数、命中实体数做成一个简单的仪表板。有了数据优化就不再靠猜。你会发现很多直觉其实不对比如你以为用户关心整段对话实际上90%的问题只需要最近两三轮加上几个关键实体就够了。最后分享一个受益很久的小习惯每次调完上下文策略不要只看一两个case就收工至少拿三五十条真实对话回归一遍。特别是长对话场景把压缩前后的prompt都打印出来对比着看。context-mode这东西效果好不好试过才知道。