AI应用上下文模式设计：从概念到落地实现框架

这段时间在做 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 窗口的典型分配方案。

这个比例不是死的。比如你想做一个“长文分析模式”，外部检索内容就会占大头；如果你做的是“闲聊陪伴模式”，会话上下文占比可能高达 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 第一步：基于场景矩阵定模式

动手写代码之前，先做一件事：把产品会遇到的场景全部列出来，按“是否需要历史”“是否需要外部数据”“需要多详细输出”三个维度打分。这一步直接决定你要不要给产品设计三种模式。

假设我在做智能客服，场景矩阵是这样的。

做完这个矩阵，很多以前纠结的问题自然就解决了。比如“要不要把用户历史全量传给模型”，答案很简单：只有扩展模式需要，其他模式一律截断。

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_ascii=False) 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"[知识块{i+1}]\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_tokens=128000) compact = ContextModeConfig( name="compact", max_token=4000, keep_recent_turns=1, use_memory_summary=False, max_rag_chunks=0, include_environment=False ) balanced = ContextModeConfig( name="balanced", max_token=24000, keep_recent_turns=3, use_memory_summary=True, max_rag_chunks=3, include_environment=True ) extended = ContextModeConfig( name="extended", max_token=80000, keep_recent_turns=10, use_memory_summary=True, max_rag_chunks=8, include_environment=True ) 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 轮请求到底注入了哪些内容，比猜快十倍。

再给一份避坑速查表。

这里我想单独强调一下命名规范。模式命名一定要“可运维”。我最早用过 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 应用时少走一些弯路。