企业官网建设流程全解析

"context-mode"这个词，我关注它挺久了。最近在做一个 AI 对话类应用的时候，被这个功能折腾得够呛，一开始以为不就是把聊天记录多传几轮嘛，真正做进去才发现，这里面的坑比想象中多得多。如果你也在做聊天机器人、AI 助手或者任何需要"记住上下文"的产品，这篇东西应该能帮你少走不少弯路。我尽量把从设计思路到代码实现再到线上踩坑的完整过程都写清楚，照着做不敢说一步到位，但至少能让你避开我趟过的那些雷。

1. 为什么需要 context-mode：先搞清楚你在解决什么问题

1.1 AI 应用的"失忆症"到底从哪来

市面上大多数大语言模型（LLM）本身就是"无状态"的。什么意思？就是你每次调用 API，模型都是从头开始理解你的问题，它不知道你五分钟前问过什么，也不知道你在这个对话框里已经输入过三页纸的背景信息。这不是模型笨，而是它的设计机制决定的——模型的注意力机制只在单次请求内生效，请求结束，这次对话的所有中间状态就清零了。

但是用户在真实使用场景里，几乎不会只用一句话跟 AI 交流。比如你在用 AI 写一份市场分析报告，第一轮你说"帮我梳理一下行业背景"，第二轮你说"再结合刚才的行业背景，整理竞争格局"，第三轮你说"把前面两部分整合成 PPT 大纲"。如果 AI 没有记忆，第二轮它就只能看到一句孤零零的"再结合刚才的行业背景"，它怎么知道你"刚才"说的是什么？结果就是你得把第一轮的内容重新复述一遍，甚至复述得不够准确，AI 给出的回答就会跑偏。

这就是"失忆症"的根源：模型无状态，但用户的工作流是有状态的。context-mode 要解决的，说白了就是把这个"状态"从用户脑子里搬到程序里，替用户记住该记住的东西。我最初做这个功能的动机特别朴素——用户在我的应用里反馈最多的就是"怎么越聊越傻""我刚才不是说了吗你怎么又忘了"，这类反馈本质上都是上下文丢失导致的。

1.2 context-mode 与普通对话模式的本质区别

很多人以为 context-mode 就是把聊天记录全部塞给模型，这其实是最大的误解。普通对话模式下，应用只是简单地把用户最后一句话发给模型，模型基于这句话单独生成回复。而 context-mode 下，应用做的是"上下文组装"——把系统预设、历史对话、检索到的相关资料、用户当前问题，按照一定的策略和优先级组装成一个完整的请求，再发给模型。

两者的差别，打个比方就很好理解：普通模式像一个新来的实习生，你每次交代任务都只给一句话，他做完就忘，下一次你再交代，他还得从头问起；context-mode 像一个带笔记本的老员工，你跟他聊过什么他都记着，你一个"继续说"他就知道接着哪个话题往下说，你问"刚才那个方案还有没有别的问题"，他能立刻定位到你指的是哪个方案。

所以 context-mode 的本质不是"多传几轮历史记录"这个简单动作，而是一整套关于信息的筛选、组织、压缩和更新机制。我做完这个功能之后回头总结，它其实包含三个核心环节：记忆的采集（怎么记录）、记忆的筛选（哪些该进上下文）、记忆的更新（进不了上下文的怎么处理）。这三个环节任何一个做不好，context-mode 都会变成鸡肋甚至拖后腿的功能。

2. context-mode 的整体设计思路

2.1 上下文到底该由哪些部分构成

在设计 context-mode 之前，我先把"上下文"这个概念拆解了一遍。所谓上下文，并不只是聊天记录。在实际的 AI 应用里，一份完整的上下文至少包含四层信息：

第一层是系统预设，也叫 System Prompt。这一层是给模型定调的，规定了它的角色、语气、能力边界、输出格式要求。这层信息跟具体对话无关，是常量，但也是上下文的基础底座。

第二层是历史对话记录。这是大多数人理解中的"上下文"，即用户和 AI 之前的每一轮问答。历史对话决定了模型能否理解当前问题的来龙去脉。

第三层是检索增强信息。这一层是可选的，如果应用接入了知识库或者 RAG（检索增强生成），那么跟当前问题相关的文档片段、数据库查询结果，也应该被组装进上下文。这层信息能帮模型回答那些不在它训练数据里的问题。

第四层是用户当前输入。也就是用户在最新一轮里说的一句话或一段话，这是模型的直接指令，优先级应该最高。

四层信息的组装顺序和权重，直接决定了模型输出的质量。我的经验是：系统预设放在最前面，紧接着是检索到的相关资料，然后是压缩后的历史对话，最后才是用户当前输入。这样模型在生成回复时，能先理解自己的角色和背景资料，再结合对话脉络，最后聚焦在用户当前问题上。顺着这个顺序，模型输出的连贯性是最稳的。

2.2 选择什么样的上下文策略

把上下文的结构想清楚之后，第二个问题是要选择具体的上下文管理策略。我在调研和实测中，整理出三种比较主流的方案，它们各有利弊，适用于不同的场景。

第一种是"滑动窗口"策略。这是最简单直接的方案，就是把最近的 N 轮对话塞进上下文，更早的一律丢弃。N 的取值取决于你用的模型上下文长度和单轮对话的平均 token 消耗。比如你的模型上下文上限是 8K token，平均每轮对话消耗 1K token，那 N 取 5 左右比较稳妥。这种策略的好处是实现简单、响应快、成本可控；坏处是"记忆"只有短期，用户聊得稍微久一点，早期信息还是会丢。

第二种是"摘要压缩"策略。当历史对话超过窗口上限时，先把早期对话交给模型做一轮摘要，用一个简短的"记忆摘要"替代原始对话，继续留在上下文里。这种策略能保留长期记忆，但实现复杂度高，而且每次摘要本身也要消耗模型调用和 token，延迟和成本都有所上升。

第三种是"检索增强"策略。把所有历史对话向量化存入向量数据库，每次用户提问时，根据问题的相关性检索出最相关的几段历史对话，动态组装进上下文。这种策略最聪明，能保留几乎无限期的记忆，而且不浪费上下文空间，但工程复杂度最高，需要维护向量索引和检索服务。

我的建议是：如果你的应用刚起步、用户单次会话时间普遍不长，先用滑动窗口方案，它足以覆盖 80% 的场景。如果用户会话深度明显超出窗口范围，再叠加摘要压缩。检索增强适合知识库类产品或者需要跨会话记忆的产品，不建议一上来就上。

2.3 上下文管理的核心指标

做 context-mode 不能凭感觉，你得有数据来验证效果。我整理了四个核心指标，每次调整上下文策略之后，都会盯着这几个数据看：

第一个是单次请求的平均 token 消耗。这个直接关联成本。上下文塞得越多，token 消耗越大，账单越难看。第二个是平均响应延迟。上下文越长，模型处理时间越久。第三个是上下文命中率，也就是模型在回答中正确引用历史信息的次数占比，这个可以抽样对话记录人工评估，也可以让模型自己打分。第四个是用户会话深度，看用户平均在一轮会话里能聊多少轮不放弃，这是 context-mode 价值的直接体现。

上线 context-mode 之后，我观察到的数据变化很有意思：用户平均会话轮数从原来的 4 轮左右提升到了 9 轮以上，听起来很好；但同时 token 消耗涨了将近一倍，延迟也多了几百毫秒。这就是 context-mode 的甜蜜与代价——它确实提升了用户体验，但你不能无视它的成本。后面我在做优化时，所有决策几乎都是围绕这四个指标做权衡，哪里该省 token，哪里该保效果，心里有数，改动起来就不慌。

3. 核心实现细节与实操要点

3.1 上下文构建的完整管线

理论设计得再好，落地才是关键。我实际搭建的 context-mode 上下文构建管线大致分五个步骤，每一步都有需要注意的细节。

第一步是消息归一化。不管用户的输入来自网页、App 还是 API，统一转换成内部的消息结构。我用的结构类似于 OpenAI 的 messages 格式，每个消息包含 role（system、user、assistant）和 content 两个字段。这一步看似简单，但很容易踩坑——比如用户上传了图片或者文件，你需要先预处理好，转成模型支持的格式，否则后面组装时会报错。

第二步是窗口裁剪。按照设定的滑动窗口大小，从历史对话中截取最近 N 轮消息。这里有一个细节：裁剪的时候，最好保证窗口内最后一条消息是 user 角色，这样整个上下文的结尾是落在用户问题上，模型生成时能自然衔接。我一开始没注意这个，裁剪后的窗口刚好以 assistant 消息结尾，结果模型经常在用户还没提问的时候就先"回答"了一通，非常尴尬。

第三步是摘要合并。如果窗口裁剪之后还有更早的有价值信息，就把它们交给模型生成摘要，摘要插入到窗口之前。这一步我单独维护了一个"memory"字段，不跟原始历史消息混在一起，方便后续更新。

第四步是检索注入。如果启用了 RAG，根据用户当前问题去向量库检索相关片段，按相似度排序后，插入到系统预设和历史对话之间。注入的数量要控制，我一般控制在 3 到 5 段，太多了会挤占其他信息的空间，太少了检索意义不大。

第五步是组装请求。把系统预设、检索片段、记忆摘要、裁剪后的历史对话、用户当前输入按顺序拼接，加上 max_tokens、temperature 等推理参数，形成最终的 API 请求。

这五步每一步都不复杂，但串起来之后，整体逻辑就会清晰很多。我把这套管线封装成了一个独立的模块，上层业务只需要调用一个 build_context(user_input, session_id) 函数，传两个参数进去，就能拿到组装好的请求体。

3.2 token 预算与窗口管理

Token 预算管理是整个 context-mode 里最容易出问题的地方。模型上下文窗口是硬上限，超了直接报错；但就算不超，窗口被塞得太满，模型的处理质量和速度都会明显下降。

我采用的 token 预算分配方案是这样的：假设模型上下文上限是 8K token，我会设置一个 80% 的安全线，也就是实际使用不超过 6.4K token，留出 20% 给模型生成回复的空间。在 6.4K 的有效预算里，系统预设固定占用约 500 token，检索片段最多占用 1.5K token，记忆摘要占用约 500 token，剩余 3.9K 左右全部留给历史对话和用户输入。

这里的核心问题是怎么预判一截文本的 token 数量。不同模型的分词方式不一样，一个英文单词可能拆成 0.6 到 1.3 个 token，一个中文字符大约是 0.6 到 1 个 token 的消耗。最稳妥的做法是直接调用对应模型的 tokenizer 来计算，而不是用"字符数除以 4"之类的粗略估算。我一开始就是偷懒用字符数估算，结果组装出来的请求时不时触发超限报错，后来老老实实换成模型官方 tokenizer 才稳定下来。

窗口管理还有一个要点：当历史对话超出窗口时，不能简单地从最前面删掉，因为最前面的消息往往包含了用户在会话早期交代的重要背景。我的做法是"渐进式遗忘"——把最早的消息先交给摘要模型，生成一段凝练的记忆摘要；如果摘要也塞不下了，再考虑是否丢弃。这样既控制了 token 占用，又尽可能保留了核心信息。

3.3 记忆压缩与摘要策略

摘要压缩是 context-mode 里最有技术含量的一环。你让模型"总结一下之前的对话"，听着简单，做起来全是细节。

第一个细节是摘要的粒度。我见过有人只生成一段全局摘要，对话内容长了之后，这段摘要会变得非常笼统，丢失大量细节。我的做法是分层摘要：每小时左右生成一个阶段摘要，一天左右生成一个天级摘要，天级摘要由阶段摘要再压缩而成。需要用到早期记忆时，优先取天级摘要，如果模型觉得信息不够，再往下翻阶段摘要。这种分层结构兼顾了 token 效率和信息密度。

第二个细节是摘要的更新策略。用户跟 AI 聊到一半，对话又增加了几轮，这时候全局摘要不能重新生成——每次都重新生成，成本太高。我的做法是采用"增量摘要"：读取已有的记忆摘要，结合新增的对话内容，让模型生成一份新摘要。这样每次摘要的输入只有新旧两份内容，token 开销小得多，而且摘要质量比从头生成更稳定。

第三个细节是摘要的触发时机。我建议不要每轮都做摘要，那样太频繁了。我实测下来的经验是：当历史对话超过窗口上限的 60% 时触发一次摘要，之后每增加 20% 再触发一次。这个频率既能保证记忆不丢，又不会频繁打断主流程。

做摘要还有一个隐含的收益：它相当于主动帮用户"划重点"。我发现，同样的信息，放进摘要里的关键信息比堆在原始历史里的信息，在后续问答中对模型的影响权重更高。后来我干脆在摘要指令里加了一句"保留与用户目标相关的关键事实和数据"，效果立竿见影，模型对早期关键信息的回忆准确率提升了不少。

4. 实操过程与关键环节实现

4.1 实现一个最小可用的 context-mode

纸上谈兵这么久，来点实在的。我分享一套最小可用的实现代码，基于 OpenAI 接口，但思路是通用的，换成其他模型也只需要改调用方式。

首先定义消息结构和会话存储。我用 Redis 存历史消息，key 是 session_id，value 是消息列表的 JSON。

import json import redis import tiktoken r = redis.Redis(host='localhost', port=6379, db=0) def append_message(session_id: str, role: str, content: str): key = f"session:{session_id}" msg = {"role": role, "content": content} r.rpush(key, json.dumps(msg, ensure_ascii=False))

接下来是核心的上下文构建函数。这里我把 token 计算、窗口裁剪、摘要检查都放进去了，逻辑比较完整，可以直接抄走改改用。

def build_context(session_id: str, user_input: str, system_prompt: str, max_context_tokens: int = 5000): enc = tiktoken.encoding_for_model("gpt-4") key = f"session:{session_id}" raw_messages = [json.loads(m) for m in r.lrange(key, 0, -1)] # 添加用户当前输入 raw_messages.append({"role": "user", "content": user_input}) # 从后往前裁剪，保证上下文不超预算 selected = [] total_tokens = len(enc.encode(system_prompt)) + len(enc.encode(user_input)) for msg in reversed(raw_messages[:-1]): # 排除当前输入，先处理历史 msg_tokens = len(enc.encode(msg["content"])) if total_tokens + msg_tokens > max_context_tokens: break selected.append(msg) total_tokens += msg_tokens selected.reverse() # 恢复正确的时序 messages = [{"role": "system", "content": system_prompt}] + selected + [{"role": "user", "content": user_input}] return messages

这段代码的核心思路是从最近的对话往前扫描，塞得下就保留，塞不下就停止。这样实现的好处是永远不超 token 上限，坏处是会丢早期信息。所以紧接着补上摘要逻辑：如果发现 raw_messages 里存在被裁剪掉的消息，就调用摘要模型把它们压缩进 memory。

def summarize_old_messages(old_messages, existing_summary=""): if not old_messages: return existing_summary content = existing_summary + "\n" + json.dumps(old_messages, ensure_ascii=False) prompt = f"请将以下对话内容压缩为简洁的中文摘要，保留与用户目标相关的关键事实和数据：\n{content}" # 调用模型生成摘要，这里省略具体 API 调用代码 return call_llm(prompt, max_tokens=500)

上面这套实现里最有用的一个设计是：system prompt 和 user_input 的 token 是优先保证的，无论历史对话怎么裁，这两部分永远不被挤掉。因为系统预设决定了模型的能力范围，用户当前输入决定了本轮的任务目标，这两个是刚需，历史对话才是可压缩的内容。

4.2 接入 RAG 扩展长期记忆

如果你的 context-mode 需要跨会话记忆，或者需要结合企业知识库回答问题，纯靠摘要是不够的，得接 RAG。RAG 的核心是向量检索：把文档和对话拆分、向量化、存入向量库，查询时用用户问题做语义搜索，找到最相关的片段注入上下文。

我用的是 OpenAI 的 embedding 接口配合 Chroma 向量库，代码量不大：

import chromadb from openai import OpenAI client = OpenAI() collection = chromadb.Client().get_or_create_collection("memory_store") def add_to_memory(session_id, text): vec = client.embeddings.create(model="text-embedding-3-small", input=text).data[0].embedding collection.add( documents=[text], embeddings=[vec], metadatas=[{"session_id": session_id}], ids=[f"{session_id}-{len(collection.get()['ids'])}"] ) def search_memory(query, session_id, top_k=3): vec = client.embeddings.create(model="text-embedding-3-small", input=query).data[0].embedding results = collection.query( query_embeddings=[vec], n_results=top_k, where={"session_id": session_id} ) return results["documents"][0]

接入 RAG 之后，context-mode 的构建管线就多了一步：先拿用户当前输入去检索相关记忆，把检索结果插到系统预设和历史对话之间。这一步的顺序非常关键——检索结果必须放在历史对话前面，让模型先看到"背景资料"，再看到"对话过程"，最后看"当前问题"，这样信息层次最清晰。

不过 RAG 也不是万能的。我踩过的一个坑是向量检索的结果和当前问题"表面相关、实质无关"，比如用户问"报告里的预算部分怎么改"，检索出来的却是另一份完全无关报告里的预算表。解决的办法是加一层 rerank 重排，用模型对检索结果做一次相关性打分，过滤掉低质量片段。这个操作会增加一次模型调用，但会明显提升注入片段的质量。

4.3 实测效果对比

代码写完，理论说了一大堆，最终还是得看实测数据。我整理了一份 context-mode 开启前后的对比数据，用的是同一个测试集，包含 50 组多轮对话场景。

从结果看，context-mode 开启后，模型的上下文连贯性打分从 3.2 提升到了 4.6（满分 5 分），历史信息准确引用率从 41% 提升到了 78%。最明显的变化是回答中"我不知道你之前说了什么"这类问题的大幅减少，以及在涉及前文信息的追问中，模型给出的回复不再自相矛盾。

同时我也记录了代价：单轮请求平均 token 消耗从 600 涨到了 2100，延迟从 1.2 秒涨到了 2.1 秒。这个增幅在我的场景里是可以接受的，但如果你的应用对延迟特别敏感，或者模型调用量大，就要在上下文长度和成本之间做更精细的平衡，可以考虑用更小规模的历史窗口，或者对部分请求关闭 RAG 检索。

我还做了一组有趣的对比：同一段多轮对话，分别测试了"完整历史注入""摘要注入"和"滑动窗口丢弃早期信息"三种策略。完整历史注入的效果最好，但 token 消耗最高；摘要注入的效果接近完整历史，token 消耗降低约 60%，性价比最高；滑动窗口丢弃早期信息在对话超过 6 轮之后效果明显下滑。所以如果你的模型上下文窗口够大，优先用完整历史；窗口紧张，用摘要注入；实在没有摘要能力，才退而求其次用滑动窗口。

5. 常见问题与排查技巧实录

5.1 上下文越界与截断问题

我上线 context-mode 后遇到的第一个线上事故，就是用户聊到第 20 轮时，请求直接抛出了 context length exceeded 的错误。排查过程很有意思，因为我明明写了 token 预算控制，理论上不该超，问题出在哪里？

后来发现，问题出在 max_tokens 的预留上。我的预算算法只算了输入侧的总 token，没算输出侧。当用户的单轮输入非常长、或者我用模型生成摘要时消耗了较多输出 token，整体就超出了模型硬上限。解决办法是双保险：一方面在 build_context 里把系统提示和用户输入也计入预算，另一方面在请求层做一次最终校验，如果总 token 超过模型上限的 85%，就对历史对话做进一步裁剪。

另一个容易忽略的细节是，不同模型的 tokenizer 不同。我用 gpt-4 的 tiktoken 来估算其他模型的 token，结果某些模型实际 token 数比估算高 20% 以上，导致隐性越界。后来统一改成用各模型官方 tokenizer 计算，再没出过这个问题。

5.2 上下文污染与相关性下降

上下文越界是明枪，上下文污染是暗箭。污染指的是：上下文里塞入了太多跟当前问题无关的信息，模型反而被这些信息带偏。

最典型的一个案例：某用户在一轮会话中先聊了旅游攻略，又聊了股票投资，再问"你觉得哪个更值得做"。由于 context-mode 把前面所有对话都注入了上下文，模型搞不清"哪个"指的是旅游项目还是股票，回答起来左右摇摆。这就是没有做好相关性过滤导致的上下文污染。

我的解决方案是给历史对话做"相关性标注"。在组装上下文时，先用轻量级模型对每段历史消息进行相关性分类，与当前问题高度相关的保留完整内容，中度相关的压缩成一句话，不相关的直接丢弃。这样虽然多一步处理，但显著提升了模型的回答精准度。实测下来，相关性标注能让模型在复杂话题切换场景下的表现提升约 30%。

还有一个污染源是系统预设里的冗余信息。有些团队习惯把大段的产品说明、公司介绍塞进 system prompt，数量一多就会挤占历史对话的空间。建议定期审查系统预设，凡是跟当前任务无关的内容一律移除，保持精简。

5.3 成本失控与延迟飙升

context-mode 是一把双刃剑，用好了提升体验，用不好钱包流血。我的应用接入 context-mode 的头一周，模型调用成本直接翻了一倍多，排查下来发现三个原因。

第一个原因是摘要触发的频率过高。我最初的设计是每轮对话后都检查是否需要摘要，结果在长对话里，摘要模型的调用次数比主模型还多。后来改成"历史对话超过窗口的 60% 才触发摘要"，调用量立刻降下来了。

第二个原因是检索注入的片段太多。每次检索默认返回 5 个片段，但大部分场景下 2 到 3 个片段就够用了。减少注入数量后，token 消耗下降明显，回答质量几乎没受影响。

第三个原因是调试期的日志记录。为了排查问题，我把每次请求的完整上下文都打日志了，这本身不影响模型成本，但日志量巨大，间接拖慢了系统。建议日志只记录 token 数量和消息元信息，不记录完整内容。

延迟方面，最有效的优化是"预热"：对高频用户，提前构建好上下文并缓存，用户发消息时直接取缓存结果，省去重复构建的时间。实测能降低 30% 到 50% 的端到端延迟。

5.4 排查工具箱

做 context-mode 的调试，没有趁手的工具真的会崩溃。我推荐几个常用的排查手段，都是我在实践中验证过的。

第一是上下文可视化工具。把每次请求的上下文导出来，逐条查看消息的角色、内容、token 数、来源标记。我写了一个简单的 Python 脚本，能统计上下文中每部分（系统、检索、历史、当前）的占比，画成柱状图。一图胜千言，很多问题一眼就能定位。

第二是 A/B 测试框架。context-mode 的每一项调整，都不要直接全量上线。我习惯把用户分成 A/B 两组，一组用旧策略，一组用新策略，观察两组的会话深度、满意度评分、token 消耗变化。用数据说话，才能避免上了线又不确定改动是好是坏。

第三是黄金对话集。准备 30 到 50 组覆盖典型场景的多轮对话，每次改动后跑一遍，对比输出质量。这个对话集是人工标注过标准答案的，能把"感觉变好了"变成"覆盖率从 72% 提升到了 81%"。

第四是熔断机制。如果 context-mode 模块出现异常（比如异步摘要任务超时、向量库不可用），要能自动降级为普通对话模式，保证用户体验不中断。我在系统里加了一个开关，RAG 服务连续三次超时就自动关闭检索注入，只保留历史对话和摘要，等服务恢复后再自动开启。

这些工具搭起来成本不高，但能在关键时刻救你一命。尤其是黄金对话集，它帮我在一次代码重构后立刻发现了上下文组装顺序的回归问题，如果没有它，这个问题可能要线上跑一周才能被用户反馈出来。

做 context-mode 这件事，我最大的体会是：它不是一个一锤子买卖的功能，而是一个需要持续调优的系统。别指望上线了就完事，用户的对话场景千奇百怪，今天你觉得"窗口 5 轮够了"，明天就有个用户在第 8 轮时告诉你"你怎么忘了我说过我喜欢简约风格"。多留几手后路，把摘要、检索、降级机制都准备好，遇到问题才有得打。

最后再分享一个小技巧：context-mode 的调优不要只盯着模型效果，也要看用户的行为数据。如果用户在使用 context-mode 后，主动说"你记得真清楚"这类话的频率提升了，说明你方向对了；反过来，如果用户开始大量复制粘贴前文内容，说明你的上下文机制还没真正帮到用户。用这些信号来校准你的优化方向，比任何指标都真实。