大模型上下文管理实战：context-mode架构、常见坑与调参方法

1. 先搞清楚"断片"发生在哪：context-mode 解决的问题边界

如果你做过聊天机器人、AI 助手、企业知识库问答这类产品，一定听过用户这样吐槽："它是不是把我忘了？""昨天刚说过的需求，今天又当作新问题处理""同一个问题换个说法，答案就完全不一样了。"在早期阶段，我会把这些归咎于模型能力不行，但做的时间越长越发现，真正的问题往往出在上下文上。而 context-mode，就是一套专门解决"模型该记住什么、该忘掉什么、用哪部分上下文来回答"的设计方案。

先把这个概念说清楚。大模型本身是无状态的，它每一次回答都是基于当前输入的一段文本，上一次聊了什么，如果你不主动喂给它，它根本不记得。所谓 context-mode，就是你在应用层实现的一系列机制：把历史对话、用户画像、业务规则、检索到的知识等，按照一定策略打包成模型能理解的内容，再塞进提示词里。它不只是"把对话历史带上"这么简单，还要考虑带多少、带哪些、按什么顺序带、什么时候该丢弃。

我见过很多团队把 context-mode 理解成"多轮对话"，这是个常见的误区。多轮对话通常是面向一次会话内，把用户说的话和助手回复按顺序拼接起来；而 context-mode 的视野更大，它要处理的是跨会话的长期记忆、不同用户之间的信息隔离、系统级规则和会话级信息的优先级冲突。一句话概括：多轮对话是记忆的容器，context-mode 是记忆的管理器。

那这篇文章适合谁看？如果你正在做基于大模型的产品，并且开始遇到"回复不稳定、上下文混乱、用户信息串号"这类问题，那这篇文章基本就是为你写的。我会从问题边界、三层上下文结构、生产级落地方案、踩坑排查链路、多智能体扩展、以及效果评估与调参这几个角度，把我实际做过的项目经验完整拆开来讲。顺便说明一句，文中的方案和参数都是基于我个人的工程实践，你可以把它当作一个经过验证的参考基线，不必照抄。

1.1 没有上下文时，用户到底在抱怨什么

把用户的抱怨归类之后你会发现，"没有上下文"其实是一个笼统的说法，背后对应着完全不同的技术缺口。我梳理过一线反馈，出现频率最高的差不多是这四类：

• "它不知道我是谁"：用户已经在小程序里登录了账号，但助手仍然把他当作陌生人，不记得他的岗位、偏好和权限。
• "昨天说的事今天忘了"：上次会话里已经确认过的结论，这次打开又从头问起，用户需要反复陈述一遍背景。
• "我换个说法它就听不懂"：用户第一次说"请帮我把季度汇报改得精简些"，第二次说"上次那份报告你帮我压缩一下"，系统无法把两次表达关联到同一个对象。
• "同一个问题每次答案都不一样"：同样的提问，上午一个版本，下午一个版本，甚至 10 分钟内两次提问得到截然不同的说法，用户会直接质疑系统的可靠性。

这四类问题分别对应不同的上下文层次：第一类缺的是用户级画像，第二类缺的是跨会话持久记忆，第三类缺的是语义关联和实体抽取，第四类缺的是系统级规则一致性。你可以做一个简单的映射表，作为设计 context-mode 时的需求清单：

我建议你在做任何技术方案之前，先做这个归类动作。很多项目一开始就上重技术，直接接向量数据库、搞 RAG，结果发现用户投诉的还是"它不知道我是谁"。原因很简单：向量检索解决的是知识召回，解决不了身份识别。context-mode 的优先级应该是先补齐身份和规则，再做知识召回。

1.2 context-mode 与传统多轮对话的区别

这里值得单独展开，因为我从面试和同行交流里发现，不少人对这两个概念的边界是模糊的。传统多轮对话的实现，通常是一个消息数组，你一言我一语地往上堆，堆到超过模型窗口再暴力截断。它的优点是简单，缺点也很明显：没有主次之分，没有时效之分，更没有安全边界。

context-mode 在架构上会引入"管理"动作。比如同样面对 20 轮历史对话，传统做法是把 20 轮全部塞进去；context-mode 的做法是先判断这些历史里，哪些是"用户确认过的关键决定"，哪些是"已经过时的中间讨论"，哪些是"与当前问题无关的寒暄"，然后只保留前三类里的前两类，中间讨论用一句摘要替代。这套"取舍 + 优先级"的机制，就是 context-mode 与普通多轮对话的本质差异。

举个我实际做过的例子。我们给企业运维团队做过一个故障排查助手，第一个版本就是简单的多轮对话，把最近几轮历史拼进提示词。上线第二天就出了问题：用户上午报告了一个网络故障，排查到一半去吃午饭，下午回来继续追问另一个数据库问题，结果因为历史里还带着上午的网络故障记录，助手把两个故障混在一起分析，给出了一堆莫名其妙的建议。后来我们改成 context-mode，用一个"会话主题切换检测"来识别用户是否开启了新议题，一旦检测到新主题，就把旧主题压缩成一行摘要并降权，问题立刻缓解。所以传统多轮对话解决的是"连续的上下文"，而 context-mode 要解决的是"动态变化的上下文"。

2. context-mode 的三层结构：会话、用户、系统级上下文怎么分工

做 context-mode 最忌讳的是一股脑把所有信息丢给模型。不同信息有不同的生命周期、不同的敏感程度、不同的更新频率，把它们混在一个袋子里，模型的表现必然不稳定。我习惯把它拆成三个层次：会话级、用户级、系统级，每一层单独存储、单独控制注入逻辑。

2.1 三层上下文模型

会话级上下文，指的是当前这次对话内的内容，包括用户最近的提问、助手给出的答案、工具调用的结果。它的特点是生命周期短，通常会话结束就可以丢弃，最多留一个摘要给下次会话作为"开场白"。用户级上下文，指的是跨会话存在的用户画像，比如用户所在部门、常用术语、历史偏好、权限范围。它的生命周期是长期的，要写入持久化存储，并且要允许用户主动查看和修改。系统级上下文，指的是产品层面的固定规则、术语表、安全红线、知识库索引，所有用户在所有会话里都应该遵守的那部分内容。

三者的分工可以用一个生活化的类比来理解。会话级上下文是"两个人当下在聊什么"，用户级上下文是"你对这位朋友的长期了解"，系统级上下文是"聊天双方共同遵守的社交礼仪和话题边界"。三个都缺一不可，但它们的存储方式差别很大：

在实操时有一点特别重要：用户级上下文不要整包注入。一个老用户的画像可能有几百条事实，全塞进去既浪费 token，又会让模型抓不住重点。正确做法是每次请求时先做一次"画像相关度筛选"，只挑出与当前问题相关的 5 到 10 条事实注入。比如用户问报销流程，你就注入他的部门、报销偏好、历史审批人；用户问服务器部署，你就注入他的环境权限和常用集群，而不是把他在系统里留过的所有信息都搬出来。

2.2 上下文窗口与 token 预算的取舍

三层上下文都往提示词里塞，很快就撞上模型上下文窗口的天花板。很多团队一上来就买大窗口模型，觉得窗口大了问题就解决了，但窗口大不等于效果好，窗口大反而更容易让模型注意力分散。我自己做项目时的原则是：窗口再大，也要像一个吝啬的房东一样，把每一寸空间都规划好用途。

有一版我们用的模型上下文窗口是 128K，看似很大，但我仍然把单次请求的 token 预算控制在一个范围内，因为窗口里要同时容纳系统指令、检索到的知识片段、工具调用的中间结果，以及模型要生成的回答空间。我的通用预算分配是这样的：系统规则占 20% 到 30%，用户相关画像占 10% 到 15%，会话历史占 40% 到 50%，外部检索来的知识占 10% 到 20%，剩下至少留 10% 给模型生成输出。你可以把它想象成一次多人会议，系统规则是主持人的开场白，用户画像是参会者的名牌，会话历史是刚才的争论记录，检索知识是摆在桌上的参考资料，而你不可能让会议纪要占掉所有时间，总得给结论留出空间。

具体到计算，假设某次请求可用输入窗口是 8K token，我会这样切分：输出预留 800，系统规则留 1800，用户画像留 800，会话历史留 3000，检索知识留 1600。如果某次检索到的资料特别多，我不会硬塞，而是先做一遍重排，只取与当前问题最相关的片段。这里面的核心逻辑是：模型的注意力资源是有限的，你喂给它的信息越杂乱，它越容易把一些无关的历史细节当作当前指令执行，导致所谓的"上下文污染"。宁可少带，也要精带。

3. 一个生产级 context-mode 的落地方案：存储、打包与注入

理论说完了，下面进入实战部分。我以一个企业知识库助手为例，完整讲讲我是怎么把 context-mode 落到生产环境的。这个项目的要求是：员工可以问内部制度、IT 流程、报销规则等相关问题，系统需要记住员工上次问到哪里、是否已确认过某个关键结论，同时还要根据员工的部门和职级显示不同的信息。

3.1 需求定义与场景拆解

先做需求拆解。我们把场景抽象成三类：

第一类是"新问题问答"：员工问一个从未问过的制度问题，系统需要去内部知识库检索并给出答案。这种场景下主要用到系统级上下文和检索知识。第二类是"追问与确认"：员工就上一个问题继续深入，比如先问"年假怎么算"，再问"那离职时未休的年假能折算吗"。这里需要带上会话级上下文，让模型理解"那"指的是什么。第三类是"跨会话延续"：员工上次问完没有结束，今天继续问同一个主题，甚至引用上次得到的结论，"你说按工龄分档，我是 8 年工龄，应该休几天"。这里就必须引入用户级上下文和会话摘要。

拆完之后，我们给每一类场景定了不同的 context-mode 策略。新问题问答走"精简模式"，只注入系统规则和检索知识；追问与确认走"完整模式"，注入最近 10 轮对话；跨会话延续走"摘要模式"，注入上次会话摘要加上用户画像中的关键事实。不同模式之间由后端一个意图识别模块自动切换，用户无感。这个设计的关键是不要对所有请求都用同一套上下文打包策略，否则低成本的简单问题也会背上沉重的历史包袱，既浪费 token，又增加出错概率。

3.2 存储选型：内存、Redis、向量库、关系库怎么选

上下文要存储，存储选型是绕不开的一步。我在这类项目里见过四种主流方案，各有适用场景，放在一起对比会更直观：

这个项目里我们最终用了组合方案：Redis 存会话数据和最近摘要，关系库存用户画像和权限，向量库存内部制度文档的切片。有朋友问过我，既然向量库也能存东西，为什么不全塞进去？原因有两个：第一，向量检索是"按语义相似度召回"，它不是精确查询，你把员工工号、部门这类确定信息放进去，检索结果可能张冠李戴；第二，向量库的元数据过滤能力普遍弱于关系库，做权限控制时很容易漏。所以我的经验是：确定性的上下文放确定性的存储，语义型的上下文放向量库，两者各自发挥优势，不要互相替代。

3.3 核心实现：上下文打包与注入策略

存储定下来之后，关键在代码层面的上下文管理器。我写过一个比较通用的实现思路，核心逻辑是先分层记录，再按预算裁剪，最后按固定顺序拼接：

import json import re from typing import List, Dict class ContextManager: MAX_INPUT_TOKENS = 8000 OUTPUT_RESERVED = 800 TOKEN_ESTIMATE_RATIO = 3.2 # 中英文混合场景，平均每个token约3.2个字符 def __init__(self, redis_client, db_client, vector_client): self.redis = redis_client self.db = db_client self.vector = vector_client def _estimate_tokens(self, text: str) -> int: return int(len(text) / self.TOKEN_ESTIMATE_RATIO) + 1 def _build_system_prompt(self) -> str: # 系统级上下文：固定规则，每次最先注入 return load_system_rules() def _build_user_profile(self, user_id: str, query: str) -> str: # 从关系库读取用户事实，做一个简单的相关度过滤 facts = self.db.query_user_facts(user_id) relevant = [f for f in facts if any(k in query for k in f.keywords)] return "用户已知信息：" + json.dumps(relevant[:8], ensure_ascii=False) def _load_recent_history(self, session_id: str, max_rounds: int = 10) -> List[Dict]: return self.redis.lrange(f"session:{session_id}:history", -max_rounds * 2, -1) def _build_retrieved_knowledge(self, query: str, top_k: int = 5) -> str: docs = self.vector.search(query, top_k=top_k, threshold=0.72) return "\n".join(f"[知识{i+1}] {d.content}" for i, d in enumerate(docs)) def build_prompt(self, user_id: str, session_id: str, query: str) -> str: parts = [] budget = self.MAX_INPUT_TOKENS - self.OUTPUT_RESERVED system_prompt = self._build_system_prompt() parts.append(("system", system_prompt, self._estimate_tokens(system_prompt))) profile = self._build_user_profile(user_id, query) parts.append(("profile", profile, self._estimate_tokens(profile))) knowledge = self._build_retrieved_knowledge(query) parts.append(("knowledge", knowledge, self._estimate_tokens(knowledge))) history = self._load_recent_history(session_id) history_text = "\n".join( f"{'用户' if msg['role'] == 'user' else '助手'}: {msg['content']}" for msg in history ) parts.append(("history", history_text, self._estimate_tokens(history_text))) final_parts = [] used = 0 # 按优先级依次放入，预算不足时先截断会话历史，而不是牺牲系统规则 for name, content, tokens in parts: if used + tokens > budget: if name == "history": content = self._trim_history(content, budget - used) elif name == "knowledge": content = content[: max(1, (budget - used) * self.TOKEN_ESTIMATE_RATIO)] else: continue final_parts.append(f"{name}_marker:{content}") used += self._estimate_tokens(content) return "\n\n".join(final_parts)

这段代码里有一个容易被忽略的设计：拼接顺序。我固定把系统规则放在最前面，然后是用户画像、检索知识，最后才是会话历史。这么做的原因有两个。第一，模型对提示词前部的注意力通常更强，系统规则这种必须遵守的内容要放在显眼位置，否则容易被后面的长历史稀释；第二，会话历史的优先级最低，一旦 token 预算不够，第一个被裁剪的就是它，而不是系统规则。很多新手把历史放在最前面，结果模型越聊越被带偏，往往就是这个顺序问题。

注入策略上还有一个细节：不要在每轮对话里都把"用户画像"完整更新一遍。画像写入应该由独立的事件触发，比如用户明确说出偏好、系统确认了一个关键事实，而不是把每一次用户发言都当成画像素材。否则画像会迅速膨胀，里面充满大量低质量噪音。我们的做法是设置一个画像置信度机制，同一个事实被用户确认两次以上才写入长期存储，单次出现的事实只放在会话级上下文里，随时可被丢弃。

4. 上线后最容易被低估的四个坑：污染、过期、串号与越权

context-mode 这层设计，平时看似风平浪静，真正出问题的时候往往很隐蔽。我在上线后陆续踩过不少坑，挑四个最有代表性的展开讲，其中第一个我给出完整的排查链路，后面几个讲清楚根因和修复方式。

4.1 一次上下文污染事故的完整排查过程

背景是这样的：系统上线第三周，有用户反馈，他问一个跟"年假申请"相关的问题，助手却突然提到了"会议室预订流程"。这个回答从单句看是通的，因为两个流程里都提到了"提交审批"这个共同动作，但从业务上看完全是两码事。用户当时就说了一句"这个助手有点精神分裂"，这让我们非常紧张。

我当时的排查思路是沿着数据链路一步步追，没有直接改模型提示词，因为问题大概率不在模型，而在喂给模型的上下文。第一步，查模型调用日志，确认这次请求实际注入的提示词内容。日志显示，系统规则没问题，会话历史也基本对得上，可疑的是检索知识部分，里面混入了一段标题为"审批流程常见问题"的通用文档，其中一个大段讲的是会议室预订。第二步，定位这段知识是怎么被检索出来的。我去向量库查了这次的检索候选列表，结果发现相似度最高的 5 个片段里，前 3 个确实是年假相关，第 4 个和第 5 个是审批流程通用片段，里面包含了预订流程的内容，而我的召回阈值设的是 0.6，太低，把这两个无关片段也放行了。第三步，检查元数据过滤，发现这两个片段属于一个公共文档集合，没有绑定部门和场景标签，所以被当成了万能知识提供给所有用户。

根因浮出水面：不是模型错，而是检索召回范围太宽、阈值太低、元数据过滤缺失。修复动作有三步：一是把检索阈值从 0.6 调到 0.72，重新跑一遍历史问题集，确认没有明显漏召回；二是给所有知识切片补齐场景标签，检索时强制按场景过滤；三是在注入知识时对候选片段做一次重排，剔除与当前问题明显不同主题的内容。这个事故给我最大的教训是：context-mode 的每一路输入都要可追溯，日志里必须能看到"到底哪一段上下文最终被使用了"，否则排查起来就是大海捞针。

4.2 过期信息、角色混淆与越权读取

第二个坑是信息过期。用户级上下文里存了一条"用户所在部门是市场部"，三个月后他转岗到产品部，系统还在用旧画像回答，导致所有涉及权限的答案都是错的。修复方案是给每条长期记忆加上更新时间戳，回答涉及的关键事实要做时效校验；同时在用户主动告知变更时，必须走一次"事实确认"流程，而不是直接覆盖。

第三个坑是角色混淆。同一个用户，他在对外场景是客户，在对内场景是员工，两条身份对应的权限完全不同。有一次助手把内部员工的休假制度讲给了外部客服人员听，其实就是因为只按 user_id 取上下文，没有区分"当前场景身份"。我后来把所有用户级上下文都改成复合键：场景维度加身份维度，比如 external:customer:10001 和 internal:employee:10001 两套上下文互相隔离。

第四个坑是越权读取。多用户共享同一套系统级知识时，A 用户检索到的内容可能包含面向 B 用户的私有信息。我在代码里加了一层强制过滤：所有知识切片在进入提示词之前，先按当前用户的权限标签做一次交集运算，没有权限标签的切片直接丢弃。这一步绝对不能省，尤其在涉及薪资、绩效、合同这类敏感内容的场景里。这四类坑我用一张表收一下，方便你对照自查：

5. 进阶：从单人对话到多智能体协作的上下文隔离设计

如果 context-mode 只服务一个对话场景，做到上面那一步基本就够了。但我在做项目后期，发现它真正复杂的地方是在多智能体协作里。多个智能体各自有分工，又要共享一部分高层信息，上下文如果一刀切共享，会产生严重的串扰；如果一刀切隔离，又会让协作失去同步。这一节讲我摸索出来的一套隔离与共享规则。

5.1 让上下文带上"角色视角"

我最早做的多智能体场景是一个内容创作团队：一个策划智能体负责定主题，一个写作智能体负责写初稿，一个润色智能体负责改稿。最初我把三个智能体共用一套完整上下文，效果很差：策划阶段生成的灵感发散内容会干扰写作阶段的严谨表达。后来我给上下文加了一个"角色视角"字段，每个智能体只读取与自己职责相关的部分内容。策划智能体看用户需求和市场信号，写作智能体看策划结论和素材库，润色智能体看初稿和风格指南。

实现上其实不复杂，就是在提示词模板里按角色做条件拼接。角色视角的本质是：不要把所有上下文都视为"客观事实"，有些上下文只是某个角色的中间产物。比如策划智能体说"这篇稿件可以走幽默风格"，这句话对于写作智能体是有效指令，但对于润色智能体可能只是背景信息。把所有上下文一律当成事实喂给所有智能体，是很多协作失败的根本原因。

5.2 多智能体之间如何共享与隔离上下文

我采用的是一种"黑板模式"。所有智能体共享一个公共上下文区，里面只放经过确认的结论和任务状态，比如"主题已确定""素材已收集完成""初稿等待润色"。而每个智能体的私有上下文区，存放的是它自己读取到的原始信息和中间推理过程。公共区与私有区严格分开，私有区内容不允许被其他智能体直接读取，其他智能体只能看到公共区里对外公开的结论。

这样做的好处是显而易见的。第一，中间推理过程的噪音不会被传播出去，比如写作智能体在思考时提到的某个备选标题，不会干扰策划智能体的判断；第二，公共区的信息经过确认，可信度高，避免了一个智能体把另一个智能体的随口推测当成事实；第三，权限边界清晰，每个智能体只拥有它需要知道的上下文。这套设计在考试里有个类似的表达叫"最小知识原则"，应用到生产线也同样成立。

从存储角度看，我在逻辑上加了一个复合键来唯一标识一条上下文归属：三元组格式是agent_id + scope_type + owner_id，其中scope_type只有两个取值，public表示公共区，private_owner表示某个智能体的私有区。代码层面就是往 Redis key 里拼前缀，成本非常低，但决策边界非常清晰。如果后续智能体数量多了，还可以在这个三元组之上再加一层命名空间，方便按团队隔离。

6. 用数据说话：context-mode 上线后的效果复盘与调参记录

最后这部分是效果复盘。很多人做完 context-mode 觉得"感觉变聪明了"，但这不能作为交付标准，我习惯用指标说话，并且把上线后的调参过程记录下来，下面是那套企业知识库助手的实际复盘。

6.1 评估指标怎么定：不要只盯着 BLEU 或 ROUGE

生成式模型的评估如果只看 BLEU、ROUGE 这类文本重叠指标，在 context-mode 场景里会有严重误导。因为用户满意的回答往往不是和标准答案逐字接近，而是"正确利用了上下文"。我更看重这几个指标：

• 上下文命中率：在回答中确实使用了历史信息或用户画像的比例，用人工抽检加日志标记的方式统计。
• 重复提问率：用户在多轮对话中对同一个问题追问超过一次的占比，这个指标下降说明上下文记忆有效。
• 信息串扰率：回答中混入与当前主题无关的历史信息的比例，这是 context-mode 特有的负面指标。
• 身份与权限准确率：涉及用户身份和权限的回答是否正确，这是安全底线，要求做到 100%。

我比较推荐的做法是：每一条线上回答都打上"使用了哪些上下文来源"的日志字段，然后按周做人工抽检，把抽检结果和日志字段做关联分析。这样你能知道哪些上下文来源最可能导致错误，进而做针对性调整。

6.2 最影响体验的三个参数

运营了大半年之后，我总结出三个最影响体验的参数，你可以把它当作调参起点。

第一个是检索阈值。阈值调低，召回多但噪音也大；阈值调高，精度提升但可能漏掉有用信息。我们在实验集上跑了一圈，0.72 是一个不错的平衡点，比初始的 0.6 降低了大量污染，同时召回率只损失了约 3%。

第二个是历史保留轮数。历史保留越多，模型对"当前话题"的判断越稳定，但也更容易被无关内容带偏。我们验证下来，普通问答场景保留最近 6 到 10 轮效果最好；超过 10 轮，信息串扰率会明显上升；少于 6 轮，用户追问时模型又容易失去前文线索。

第三个是会话摘要触发间隔。不是每轮都做摘要，而是当对话达到一定长度或检测到主题切换时才做。我们的配置是：对话超过 12 轮未结束时，把前 8 轮压缩成一个结构化摘要；或者当主题切换检测置信度超过 0.8 时，立刻对上一主题做摘要。直接压缩整个上下文而不分主题，是很多摘要方案失败的原因。

6.3 我的调参记录与最终效果

这里贴一段当时的调参记录，省得大家重复走弯路。第一版上线时检索阈值 0.6，上下文串扰率不到一周就报警；我把阈值调到 0.7，串扰率明显下降，但出现了"该召回没召回"的情况，比如用户问"报销上限"时，相关文档没有进入检索结果。后来我意识到问题不在阈值，而在知识切片时把"报销规则"和"报销流程"切成了两个片段，导致语义表达不完整。调整切片策略，按章节层级切片，而不是按固定字数切片之后，再把阈值定到 0.72，效果才稳定下来。

历史保留轮数的调整也有类似过程。最初保留 20 轮，用户满意度反而低于保留 6 轮时，因为模型被大量旧信息干扰，经常把一个多小时前的话题当作当前主线。我们加入主题切换检测之后，才敢把保留轮数重新放开到 10 轮，同时配合会话摘要，才做到"该记得的都记得，该忘的都能忘"。

最终那一版的脱敏数据大概是这样：上下文命中率从开源的 41% 提升到 76%，重复提问率下降了约 32%，信息串扰率从 18% 降到 4% 以内。这个结果不算惊艳，但对我们这种中小规模团队，已经是稳定可用的状态。说实话，这套机制跑到现在，我最大体会是 context-mode 从来不是模型本身的问题，而是工程取舍问题：你愿意花多少 token、多少存储、多少排查成本，去换取一段"看起来真的记得你"的用户体验。而判断一个 context-mode 设计得好不好，就一条标准——用户不需要主动解释自己，系统也能把事办对。能做到这一点的团队，基本都在上下文管理上下了真功夫。