这段时间在做 AI 应用里的“上下文模式”设计也就是 context-mode 这个词。它解决的痛点非常具体模型明明给了很大的上下文窗口但实际用起来总感觉模型“记不住东西”“答非所问”“关键信息被淹没”。你以为是模型笨其实大多数时候是上下文没有按模式组织好。这篇内容基本涵盖我踩过的坑、沉淀下来的分层思路以及一套可以直接拿去改动落地的实现框架适合正在做智能客服、AI Agent、知识库问答或者自己做 RPA、编辑器插件的人参考。1. context-mode 到底是什么——先拆掉认知门槛1.1 一句话说清 context-mode我见过很多朋友把 context-mode 理解成“给系统提示词准备几个模板轮到哪个场景就切哪个”这个理解太浅了。真正意义上的 context-mode不是换模板而是让系统根据当前所处环境动态决定“该拿哪些信息”“按什么顺序组装”“最终用哪种行为姿态输出”。打个比方你在家里跟家人说话、在公司跟同事说话、在项目评审会上跟老板说话语气和内容完全是三种状态。你不是“切换了人格模板”而是根据上下文自动调整了措辞的详略、关注的重点、甚至说话的节奏。Context-mode 要做的就是让 AI 应用也具备这种能力识别当前处在什么场景再决定上下文怎么组织。这个概念的适用面很广。在 LLM 应用里它表现为“什么样的提示词结构 策略来处理不同的用户问题”在传统软件/编辑器里它表现为“界面状态和可用指令随光标位置、选区内容、打开文件类型动态改变”在业务系统里它表现为“表单校验规则、必填字段、关联逻辑随用户角色和页面上下文发生切换”。1.2 context-mode 和固定模式、无上下文模式的区别先看一张我做场景梳理时经常用的对比表。模式类型信息来源行为特点典型问题无上下文模式只有当前输入每条消息独立处理不关联历史多轮对话断裂重复提问固定模式固定的系统提示词 当前输入每次行为一致稳定但僵硬无法感知场景变化同一句话在不同环节得到同样回答上下文模式动态组合系统信息、历史、外部数据、当前输入根据场景自动调整上下文构成与输出风格需要设计上下文预算与优先级复杂度更高固定模式最大的坑就是“稳定”和“僵化”是一体两面。比如客服机器人不管用户是来查订单、投诉物流还是咨询退款政策你给它同一套规则它能覆盖 70% 的场景但剩下 30% 往往就是情绪最激烈、问题最复杂的用户。上下文模式要补的正是这 30%识别用户的真实意图和所处状态把最相关的知识库片段、最近的订单记录、这几轮的对话脉络有选择地喂给模型。1.3 为什么 AI 场景里总绕不开 context-mode这里要先区分几个容易混的词上下文窗口、上下文学习、上下文工程。上下文窗口context window是模型的物理容量限制比如 32K、128K、1M token它决定了你最多能塞多少内容。上下文学习in-context learning是模型的推理能力指模型能从你给它的示例和规则中学习怎么回答新问题不需要更新权重。上下文工程context engineering就是围绕前两者做“容量管理 信息编排 策略设计”的一套方法论。Context-mode 是上下文工程里最容易落地的抓手。因为不管模型多强、窗口多大如果信息杂乱无章模型照样会懵。你会发现即使给了模型 128K 的窗口深入对话到第三四轮之后它还是会漏掉用户最初说的关键需求。这不是模型不行而是你没有用上下文模式把信息分好层、排好序。我自己的经验是凡是需要多轮交互、外部工具调用、知识库检索的 AI 应用“上下文模式”不是可选项是必选项。2. context-mode 的核心设计上下文从哪里来按什么权重分配2.1 上下文的四个信息源与优先级在具体设计 context-mode 之前先把“上下文到底包含什么”拆清楚。我总结了四个来源基本覆盖绝大多数场景。系统性上下文这是最高层级的稳定信息通常包含系统提示词、产品定位、安全规则、输出格式要求。它属于“长期记忆”应该一直存在但不宜过长。很多人觉得自己已经写了很详细的 system prompt结果模型效果还是不行。问题往往是你把太多“临时信息”塞进了系统层反而稀释了稳定的行为约束。会话性上下文这是多轮对话产生的历史记录用户之前提过什么、模型之前答过什么、中间经历过哪些操作。它属于“中期记忆”需要按需裁剪。最忌讳的是不加选择地把全部历史塞进模型。很多对话助手越到后面越“话痨”就是因为上一轮的长文本回答也原样进了下一轮上下文导致模型被迫模仿自己的啰嗦。环境性上下文这个最容易被忽略。包括当前时间、系统状态、设备信息、最近一次操作、用户画像标签等。它不是用户直接说的内容而是系统感知到的背景信息。比如一个日程助手如果你不把“今天是周五”这种时间信息注入上下文它会以为所有日程都是没有时间感知的孤立事件。环境上下文的更新频率高但占用 token 量很小性价比极高。即时性上下文这是用户当前这一次输入包括问题正文、上传的文件、选中的代码片段、触发事件。它代表“眼下的意图”优先级最高因为模型推理时最关注的必然是它。一句话总结即时上下文负责“精准响应”环境上下文负责“场景感知”会话上下文负责“连续性”系统上下文负责“行为约束”。2.2 上下文窗口预算一次调用该放多少内容有一个经常被忽视的点模型能容纳多大窗口和你“应该用满窗口”是两件事。上下文窗口越大模型处理成本越高响应延迟越大而且真正关键的信息占比会被稀释。我建议按比例而不是按绝对数量来规划上下文预算。这里给一个 128K 窗口的典型分配方案。上下文层级建议占比128K 窗口对应说明系统上下文5% - 10%6K - 13K token行为约束和格式说明会话上下文25% - 40%32K - 51K token多轮摘要 最近完整记录环境上下文3% - 5%4K - 6K token时间、设备、画像外部检索内容10% - 20%13K - 26K token知识库片段、文档、工具返回即时输入20% - 30%26K - 38K token当前问题、附件、选中内容预留缓冲5% - 10%6K - 13K token给模型推理留空间这个比例不是死的。比如你想做一个“长文分析模式”外部检索内容就会占大头如果你做的是“闲聊陪伴模式”会话上下文占比可能高达 60%。关键是你要有意识地做出分配而不是让上下文自己膨胀。我遇到过一个真实案例某知识库问答应用用户每次提问都会拼上 8 个检索出来的文档片段每个片段 2000 字总共 1.6 万字的资料。结果模型经常回答得很散甚至引用错误片段。后来我把检索数量砍到 3 个加了相关性过阈值才会进上下文效果反而大幅提升。上下文质量永远比数量重要。2.3 三种典型的 context-mode紧凑、平衡、扩展我在多个项目里验证过固定设计三档上下文模式基本能覆盖绝大多数产品场景。紧凑模式适用场景闲聊、简单问答、身份确认、格式转换。这种模式只保留系统上下文的骨架 最近 1-2 轮对话 当前输入。上下文长度控制在 2K-4K token 以内。优点是响应快、成本低、不容易跑偏。缺点是没法处理复杂任务。平衡模式适用场景日常客服、常规知识库问答、多轮信息收集。保留完整系统上下文、经过压缩但信息完整的历史摘要、最近 3-5 轮原始对话、适量外部检索结果。上下文长度控制在 8K-32K token。这是大多数应用应该默认使用的模式。扩展模式适用场景长文档分析、复杂 Agent 任务、代码审查、法律/医疗场景。这种模式会尽量利用大窗口分配更多给外部检索和会话上下文甚至允许连续多轮累积完整记录。上下文长度可达 64K 以上。设计成“三档”不是为了花哨而是为了在产品质量、成本、延迟之间做平衡。这三档对应不同的基础设施成本当你给不同客户或套餐分配不同模式时成本控制也会变得非常清晰。3. 从 0 到 1 落地 context-mode一套可直接抄的实操流程3.1 第一步基于场景矩阵定模式动手写代码之前先做一件事把产品会遇到的场景全部列出来按“是否需要历史”“是否需要外部数据”“需要多详细输出”三个维度打分。这一步直接决定你要不要给产品设计三种模式。假设我在做智能客服场景矩阵是这样的。场景需要历史需要外部数据输出详略选用模式用户打招呼/闲聊否否简短紧凑查询订单状态是最近1-2轮是订单系统数据中等平衡投诉处理是完整历史是客服工单物流记录详细、格式规范扩展退货退款政策解释否是知识库中等平衡多轮定损沟通是所有历史是图片报价详细扩展做完这个矩阵很多以前纠结的问题自然就解决了。比如“要不要把用户历史全量传给模型”答案很简单只有扩展模式需要其他模式一律截断。3.2 第二步上下文模板与注入顺序设计定好模式后要设计上下文拼接模板。我习惯用一个标准顺序基本按照“信息稳定性从高到低、重要性从低到高”排列。system 系统提示词角色、能力边界、行为规则 /system memory 压缩后的历史记忆用户偏好、关键事件、未完成任务 /memory knowledge 外部检索结果知识库片段、工具返回、参考文档 /knowledge context 环境信息 会话状态当前时间、设备、最近操作、页面来源 /context user 用户当前输入问题、指令、附件说明 /user这个顺序背后的逻辑很简单模型对越靠后越接近末尾的内容注意力权重通常更高。所以最重要的用户当前输入放最后稳定性信息放最前。中间的记忆、知识、环境信息按“是否需要模型重点参考”排序。我见过不少人把知识库片段放在用户输入后面结果模型把参考文档当成用户输入开始对文档内容做翻译、解释完全是灾难。所以记住一条铁律用户输入必须是最后一个 major block。3.3 第三步历史记忆的压缩与衰减上下文模式做起来之后一个核心问题就是“会话历史越滚越长怎么办”。我的实践是三种手段配合使用。摘要压缩定期让模型把前面的对话总结成摘要用摘要替换原始对话。比如每 6 轮对话做一次摘要保留最近 3 轮完整对话。这样既保留了关键信息又避免了 token 膨胀。分段衰减给不同时间段的信息设置不同权重。比如“5 轮之前的对话只保留结论不保留过程”或者“超过 20 轮的明细内容直接丢弃”。这种衰减规则跟人类的记忆规律很像你不需要记住三个月前每次聊天的每句话你只需要记得最终确认的结果。跨会话记忆这个适合长期用户。把用户偏好、身份信息、关键业务数据存成独立的 profile在每次新会话开始时注入系统上下文。比如用户上次反馈“喜欢简短回复”这个偏好就要永久保留不需要每次从聊天记录里翻出来。我自己做项目时总结出一个经验上下文压缩不能只靠“截断”摘要质量是上限决定的。如果摘要做不好后面的所有对话都会被带偏。所以我一般会在摘要 Prompt 里显式要求“保留数字、名称、结论、未完成事项删除客套和重复表达”。3.4 第四步用 Python 实现一个 context-mode 管理器理论讲再多不如给一份能跑的最小实现。下面是一个我用过的 context-mode 管理器简化版本。它做了三件事定义模式、组装上下文、按预算截断历史。import json from dataclasses import dataclass, field from typing import List, Dict, Optional dataclass class ContextModeConfig: name: str max_token: int # 该模式允许的上下文总预算 keep_recent_turns: int # 保留最近几轮完整对话 use_memory_summary: bool # 是否使用历史摘要 max_rag_chunks: int # 最多注入几块检索内容 include_environment: bool # 是否注入环境信息 history_ratio: float 0.35 # 历史部分占预算比例 class ContextModeManager: def __init__(self, max_total_tokens: int 128000): self.max_total_tokens max_total_tokens self._configs {} def register_mode(self, config: ContextModeConfig): self._configs[config.name] config return self def build_context(self, mode_name: str, system_prompt: str, user_input: str, chat_history: List[Dict], memory_summary: str , rag_chunks: Optional[List[str]] None, environment: Optional[Dict] None) - List[Dict]: config self._configs[mode_name] # 估算 token 数中文场景可粗略按 1 个汉字 ≈ 1.5 token def estimate(text: str) - int: return int(len(text) * 1.5) # 1. 先组装基础部分 base_parts [ {role: system, content: system_prompt} ] base_tokens sum(estimate(p[content]) for p in base_parts) # 2. 环境信息注入 if config.include_environment and environment: env_text json.dumps(environment, ensure_asciiFalse) base_parts.append({role: system, content: f[环境上下文]\n{env_text}}) base_tokens estimate(env_text) # 3. 历史摘要注入 if config.use_memory_summary and memory_summary: memory_block {role: system, content: f[记忆摘要]\n{memory_summary}} base_parts.append(memory_block) base_tokens estimate(memory_summary) # 4. RAG 知识块注入 if rag_chunks: rag_chunks rag_chunks[:config.max_rag_chunks] rag_text \n\n.join(f[知识块{i1}]\n{c} for i, c in enumerate(rag_chunks)) rag_block {role: system, content: f[参考资料]\n{rag_text}} base_parts.append(rag_block) base_tokens estimate(rag_text) # 5. 按预算计算历史还能占多少 remaining config.max_token - base_tokens - estimate(user_input) history_budget min( int(config.max_total_tokens * config.history_ratio), max(0, remaining) ) # 6. 从后往前保留最近对话直到超过预算 history_parts [] used 0 recent chat_history[-config.keep_recent_turns * 2:] if config.keep_recent_turns else [] for msg in reversed(recent): cost estimate(msg.get(content, )) if used cost history_budget: break history_parts.insert(0, msg) used cost # 7. 用户当前输入放在最末尾 final_messages base_parts history_parts [ {role: user, content: user_input} ] return final_messages # 使用示例 manager ContextModeManager(max_total_tokens128000) compact ContextModeConfig( namecompact, max_token4000, keep_recent_turns1, use_memory_summaryFalse, max_rag_chunks0, include_environmentFalse ) balanced ContextModeConfig( namebalanced, max_token24000, keep_recent_turns3, use_memory_summaryTrue, max_rag_chunks3, include_environmentTrue ) extended ContextModeConfig( nameextended, max_token80000, keep_recent_turns10, use_memory_summaryTrue, max_rag_chunks8, include_environmentTrue ) manager.register_mode(compact).register_mode(balanced).register_mode(extended)这段代码的核心思路是先保证系统、环境、记忆、知识这些“基础上下文”完整再把剩余预算分配给历史对话最后强制把用户当前输入放到队尾。实际生产环境里你还需要把estimate换成模型的 tokenizer 精确计算把摘要生成改成异步任务把注册配置抽成外部 JSON 便于运营调整。但大体骨架就是这样的。4. 常见问题速查与排查经验4.1 问题一上下文溢出关键信息最先被挤掉这是最普遍的问题。很多框架默认从最前面的内容开始丢弃结果系统提示词被截断了模型行为立刻失控。正确做法是优先丢弃知识库片段其次丢弃较早的历史对话最后才动系统提示词。更重要的是在用户输入被组装之前先做预算检查。如果预算已经不够了宁可先丢弃参考资料也不能截断系统提示词和用户当前输入。我见过最离谱的一个案例系统提示词被截到一半模型直接开始“角色崩溃”声称自己不再是客服而是“是一个 AI 语言模型”。4.2 问题二上下文污染旧话题干扰新任务上下文污染是指历史信息里包含太多与当前任务无关的内容导致模型被带偏。典型场景是用户前五轮在聊 A 产品的故障第六轮突然问“那你觉得我应该选哪款”模型却以为你还在说 A 产品。解决办法分两层。第一层模式路由检测到话题切换就把之前的历史压缩成一句“用户之前咨询过 A 产品已解决/未解决”不再保留详细过程。第二层在组装上下文时给每个历史对话块打上话题标签只保留与当前意图相关的块。这个话题标签可以用轻量分类模型或关键词匹配来生成不需要额外调模型。4.3 问题三过期上下文被当成实时事实这个问题多出在 RAG 场景。比如知识库里更新了退货政策但上下文里还留着旧的检索片段模型就按旧政策回答了。解决方法是给所有检索内容加时间戳和有效期。上下文管理器组装时检查当前时间和内容时间超过有效期的一律不注入。如果跳过这一步出的是真金白银的资损事故。我还见过有人把“昨天的库存数据”注入到今天的对话里客服照着报了一个已经售罄的商品库存用户下单后才发现没货。所以 RAG 数据的时间有效性必须写进模式配置。4.4 问题四模式切换不生效缓存和顺序在作怪模式配置没问题但实测发现模型没有按新模式行为。这种问题九成出在“缓存”上。很多 AI 应用用缓存来降低成本但缓存粒度如果设置到 prompt 字符串级别那么每次模式调整后缓存必须同步失效。建议缓存粒度设置成“模式名 上下文内容 hash”的组合而不是只按用户输入的 hash 来。另一个原因是组装顺序被某些中间层打乱。比如你在框架里加了“系统提示词自动补充”“安全过滤前置”之类的中间件它们可能在组装完之后又追加了内容。我排查过的一个项目就是安全过滤中间件在用户输入后面加了一段“免责声明”结果模型把免责声明当成需要回应的用户问题连续回答了好几句无关内容。4.5 调试建议与上下文速查表调试上下文模式最重要的一件事是“能看到每次请求实际发送给模型的完整上下文快照”。我在生产环境里都会加一个开关把每次请求的最终 messages 结构记录到日志。排查问题时直接翻日志看第 N 轮请求到底注入了哪些内容比猜快十倍。再给一份避坑速查表。检查项建议做法常见错误系统提示词长度控制在总上下文 10% 以内越写越长挤占历史空间历史保留策略摘要 最近完整轮次全量历史直接塞入用户输入位置始终放在最后一个消息知识块/历史放在用户输入之后检索内容数量平衡模式不超过 3-5 块越多越好导致注意力分散信息时间戳RAG 内容带有效时间把过期内容当事实模式命名可读、可监控compact/balanced/extended这类模式名用状态码代替请求日志记录最终 messages 快照与 token 分布只记输入输出不记中间组装结果预算控制模式配置里写死 max_token所有模式用同一个大窗口这里我想单独强调一下命名规范。模式命名一定要“可运维”。我最早用过 mode_0、mode_1 这种命名结果线上排查问题时根本不知道 mode_1 到底是给哪个套餐用的。后来统一改成场景命名比如customer_support_compact、customer_support_full日志和监控系统一看就明白。调试时还建议看 token 分布。不要只看总 token 数要看系统、历史、知识、用户输入各部分各占多少。如果历史部分占比超过 60%基本可以判断历史压缩策略出了问题如果用户输入部分只占 5%说明你把大量外部信息塞进来了模型的注意力会被严重稀释。5. 我的一点实操体会做 context-mode 这段时间我最深的感触是上下文不是越多越好而是越“对”越好。很多 AI 应用效果不好根源不在模型选型而在上下文组织太粗糙。把几千字的系统提示词、几万字的聊天记录、“可能有用”的知识库片段全都塞进去模型确实能“容忍”这么多内容但它不会替你分辨什么是重点。你必须有意识地替模型做信息分级和裁剪。我现在做新项目的第一步已经习惯先画场景矩阵再定三档模式最后写配置文件。这套流程看起来简单但对效果的提升是立竿见影的。我可以直接降低 30% 以上的 token 消耗同时把响应准确率和稳定性提上去所谓“花小钱办大事”在上下文工程上体现得最明显。最后分享一个小技巧给每个模式打一个唯一标识拼进 system prompt 第一行。比如[mode: balanced#2024.06.01]。这样看日志时一眼就能确认当前请求用的是哪个模式、哪个版本的配置。以后调试线上问题你能少翻半小时代码。Context-mode 说简单也简单说深也深。核心是别把它当成一个开关而是当成一套信息组织和行为切换的方法论。希望这篇内容能让你在设计自己的 AI 应用时少走一些弯路。