企业官网建设流程全解析

做LLM应用的时间一长，你会发现一个特别讽刺的现象：同样一个模型，别人调出来是“懂王”，你调出来是“人工智障”。大部分差异不是模型本身的问题，而是卡在context-mode这块。这东西不是新鲜概念，但很多人把它当成一个开关，觉得打开就一切搞定，结果一上线就撞墙——要么答非所问，要么上下文爆掉，要么费用高到离谱。

这篇文章不打算跟你聊论文里那些公式，而是把这几种主流上下文管理模式拆开揉碎了讲清楚，包括底层到底在做什么、选型逻辑是什么、参数怎么配、线上问题怎么排查，以及我个人踩了无数坑之后总结出来的一套默认配置。适合正在做AI应用开发、智能客服、知识库问答、Agent工具的工程师，也适合刚接触大模型API、想搞清楚“为什么上下文窗口总是不够用”的产品和技术负责人。

1. context-mode 的底层逻辑：它不是开关，而是策略

1.1 先理解上下文窗口的物理限制

大模型本质是一个基于注意力机制的序列预测器。每一轮推理，模型都要把当前输入的token序列读一遍，计算它们之间的相关性。系统层面对应的就是为每个token维护一份KV Cache。窗口越长，Cache越大，显存占用涨得越夸张。

举个例子你会更直观。假设你的应用每轮对话向模型发送4000个token，这4000个token经过多层Transformer，每一层都要维护键值缓存。你单独测一轮4000 token的请求，体感没什么问题。但如果你的业务是一个客服机器人，每轮提问都携带之前10轮的完整对话记录，那请求体量就是几千token乘以10倍。你会发现响应延迟和费用一起涨，而且涨得你怀疑人生。

这就是为什么不能无脑把历史记录全部塞给模型。context-mode要解决的第一个问题，就是物理窗口的有限性。模型不是硬盘，它没有无限存储，它每一次都只能看到你喂进去的那点内容。窗口再大也是有限度的，而且你喂进去的内容还未必都能被有效利用。

1.2 三个核心矛盾：窗口有限、注意力分散、成本失控

我做过的项目多了之后，总结下来context-mode本质是在解决三个矛盾。

第一个矛盾是窗口有限 vs 信息无限。对话系统的历史记录、知识库的文档、工具返回的JSON，所有这些信息量远远超过模型的上下文窗口。你不能全都塞进去，就必须做出取舍。

第二个矛盾是注意力分散 vs 目标聚焦。模型不是你说什么它就一字不差地关注什么。你给它的上下文越长、越杂，它对关键指令的注意力权重就越低。很多开发者的痛点是“我明明把知识都给它了，它怎么还是答不对”。原因往往不是知识不对，而是知识淹没在了一堆无关紧要的上下文里，模型根本不知道该看哪里。

第三个矛盾是成本 vs 体验。大模型API是按token计费的。输入token越高，成本越高。每轮对话都全量发送历史，等于是在持续烧钱。很多创业团队早期不关注这个，等月底账单出来才傻眼。

这三个矛盾，是设计任何上下文策略时的出发点。context-mode的每种模式，本质上是在这三个维度之间做取舍。

1.3 策略思维的转变：从“塞满窗口”到“精准投放”

很多人的第一反应是：既然窗口有限，那我是不是应该把窗口全部填满？这恰恰是最容易踩的坑。

context-mode的核心思路不应该是“塞满”，而应该是“该看的给它看，不该看的别给它看”。这里的“该看”和“不该看”不是拍脑袋决定，而是有一套判断标准。比如，当前用户提问的核心诉求是什么？这个问题需要哪些知识背景？历史对话里哪些信息对当前问题有直接影响？这些应当在进入模型之前就已经被筛选和处理过。

我见过太多做砸的知识库问答项目，他们的失败原因惊人的一致：文档库几十万字，全部塞进上下文，结果模型每次都在“大海捞针”。用了context-mode的检索策略之后，几千字相关片段就够了，而且效果比塞全部文档好了好几倍。

所以请你记住这句话：**上下文管理不是“存储”，而是“投放”。**你是在有限曝光量下，决定用户的信息广告位怎么分配。想通了这点，才算真正入门。

2. 四种主流 context-mode 配置方式与实操

2.1 直通模式：最粗暴也最费钱的“全量拼接”

直通模式就是最简单粗暴的玩法：不裁剪、不检索、不摘要，把系统提示词、历史对话、外部知识一股脑拼起来，发给模型。

我用代码示例来表现一下。假设你用的是常见的OpenAI兼容API：

from openai import OpenAI client = OpenAI() def chat_with_full_context(user_input, history, system_prompt): messages = [{"role": "system", "content": system_prompt}] messages.extend(history) messages.append({"role": "user", "content": user_input}) response = client.chat.completions.create( model="your-model-name", messages=messages, temperature=0.7 ) return response.choices[0].message.content

这个模式的优势是简单，对历史信息没有任何丢失，代码只要十几行就能跑起来。但它的问题也摆在明面上：如果history很长，token消耗爆炸；上下文逼近窗口上限时，可能出现请求直接失败；而且注意力被分散，模型容易被历史里无关紧要的内容带偏。

直通模式只适合两类场景：一是你刚接API，还在跑demo阶段，先把链路打通；二是核心业务对历史依赖极强，且对话轮数一定不会超过5轮。除此之外，我不建议任何生产环境直接裸奔用直通模式。

2.2 滚动窗口模式：只保留最近N轮，防止“记忆残影”

滚动窗口的思路是：只保留最近N轮对话，超过N轮的旧消息直接丢弃。这个模式在业界非常普及，因为它简单，而且对大多数短对话场景效果足够。

代码层面可以这样处理：

def build_messages_with_window(user_input, history, max_rounds=5): # 只保留最近 max_rounds 轮对话 recent_history = history[-max_rounds*2:] # 每轮有user和assistant两条 messages = [{"role": "system", "content": "You are a helpful assistant."}] messages.extend(recent_history) messages.append({"role": "user", "content": user_input}) return messages

这里有个关键点你得注意：如果你在应用层存了session，每轮对话都把整段历史存进数据库，然后在调用大模型API时做切片，那max_rounds*2这个逻辑是关键。因为每条消息占一个元素，一轮对话通常是user+assistant两条，所以取最近N轮要乘以2。

滚动窗口最大的优势是控制成本，让请求长度恒定，不会随着对话轮数增加而无限膨胀。但问题也很明显：模型会“失忆”。用户在第1轮提到的重要信息，到了第20轮就完全没影了。如果业务场景是对多轮信息有持续依赖的，比如客服处理复杂工单，滚动窗口就会让模型表现得像个刚睡醒的傻子。

2.3 检索注入模式（RAG）：把知识库做成外挂“记忆柜”

如果说滚动窗口是“被动遗忘”，那检索注入就是“主动挑选”。它的核心做法是：不把所有知识塞进上下文，而是先根据用户问题检索出最相关的片段，再把片段以临时上下文的形式注入模型。

我把整个链路拆开讲。第一环节是文本向量化，把知识库文档切分成小段，因为整体向量化会丢失细节，段落越细，后续越容易精准命中，但切得太碎又会导致检索结果缺乏上下文连贯，所以通常控制在300到500字。第二环节是存储和索引，切分好的文本块送入向量数据库。第三环节是query向量化，用户问题同样做向量化，去库里做相似度检索，找到最相关的Top K块。第四环节是注入，构建prompt时把检索结果作为“参考资料”拼进messages，再附上用户原始问题。

代码上大概长这样：

def build_rag_messages(user_input, vector_store, top_k=3): query_vector = embed(user_input) docs = vector_store.search(query_vector, top_k=top_k) context_text = "\n\n".join(docs) system_prompt = f"""基于以下资料回答用户问题。如果资料中不含相关内容，请如实告知。 资料： {context_text} """ messages = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_input} ] return messages

这种模式最大的优势是用极低的token成本，覆盖了极大的知识量。代价是你引入了额外的检索链路，需要处理检索质量的问题。检索不准，模型就无米下锅。这个可以后面在问题排查章节仔细说。

2.4 摘要压缩模式：先浓缩再看，保留“骨架记忆”

摘要模式解决的是滚动窗口“遗忘”和直通模式“爆量”的中间问题。它的思路是：把超长历史变成一个越来越短的摘要，每次拼入上下文的是“旧的浓缩摘要 + 最近几轮的完整对话”。

实操中会维护一个记忆摘要变量。会话初期它是个空串；每轮对话结束后，把“当前摘要 + 本轮新增对话”发送给一个专用模型，让它输出浓缩后的新摘要；下一轮对话时，把这个摘要作为对话的“前情提要”拼进messages。

summary = "" # 全局记忆 def update_summary(user_input, assistant_output): global summary prompt = f"""请将以下对话内容压缩为简洁的摘要，保留事实信息：人名、事件、决策、用户偏好等。 已知摘要： {summary} 新对话： 用户：{user_input} 助手：{assistant_output} 请输出更新后的摘要：""" new_summary = call_llm(prompt) summary = new_summary return summary def build_messages_with_summary(user_input, recent_history): messages = [ {"role": "system", "content": f"前情提要：\n{summary}"} ] messages.extend(recent_history) messages.append({"role": "user", "content": user_input}) return messages

摘要模式在很多Agent系统里我很推荐，因为它在长对话场景里性价比非常高。但也有代价：摘要过程是不可逆的压缩，关键信息可能在压缩中被丢失。越长的对话，摘要丢失的细节越多。另外，每一轮都调用一次摘要LLM，多了一重延迟和成本。优化办法是每隔N轮做一次摘要更新，而不是每轮都做。

2.5 模式选型对比表：按场景直接套用

根据我实际项目经验，可以给你一张选型表。这里说的“深度使用”是指对历史信息依赖度非常高的场景，比如法律顾问、数据分析、用户画像维护；“轻度使用”则是闲聊、导购、文案生成这类对历史依赖低的场景。

这个表不是绝对的，项目如果你预算充足、对效果要求高，也可以“滚动窗口+摘要+RAG”三合一混用。

3. 关键参数与成本调优方法

3.1 影响上下文效果的四个核心参数

不管用哪种模式，有几个参数你必须心里有数。

第一个是max_tokens。它限制的是模型生成回复的最大token数，不是输入。但很多人把它误设为输入上限，导致模型回答到一半被截断。

第二个是temperature。它控制随机性。在摘要压缩和RAG检索场景，我通常调低到0到0.3之间，让模型的输出更稳定、更忠于事实。而在开放创意写作场景，则可以调高到0.7以上。

第三个是窗口阈值。所有上下文策略最后都要有一个“触发线”，比如对话轮数超过10轮开始启用摘要，历史token超过2000时丢弃最旧消息等。

第四个是top_k检索条数。RAG模式下，返回3到5条通常比较合适。太少，信息不足；太多，容易引入噪声。而且top_k直接影响输入token数，要配合成本一起考虑。

3.2 内容优先级策略：信息该留该删

做上下文管理，本质上是在做内容分级。我的分级标准有四档。

第一优先级是系统指令和用户当前意图。这是不可压缩的，必须始终在上下文中，并且保持在显眼位置。很多框架会把system prompt放在消息列表最前面，这没问题，因为模型对头部指令有更强的“锚定效应”。

第二优先级是与当前问题直接相关的历史事实。比如用户之前说过“我家地址是杭州西湖区XX路XX号”，现在问“帮我叫个车”，那这条历史信息就是关键，不能丢。

第三优先级是当前任务的过程上下文。比如用户在走一个“商品咨询→下单→付款”的流程，中间每一步的决策记录要保留。

第四优先级是业务无关的闲聊和寒暄。这类内容可以直接删，对模型决策毫无用处。

在代码实现中，建议给每条历史消息打一个priority标签，然后做保留时按标签裁剪。

def filter_messages_by_priority(messages, min_priority=3): # 优先级：1最高，4最低 kept = [m for m in messages if m.priority <= min_priority] return kept

3.3 一个完整的成本估算示例

我直接用RAG场景给你算一笔账。假设知识库每篇文档平均2000字，切分为4个块，每块约500字。每次用户提问，检索Top 3块注入上下文，那么每次调用的输入token约为：系统提示语300 token + 3块文档约2000 token + 用户问题100 token = 约2400 token。

如果用户每天有1万次调用，以某常见大模型API约每百万token数美元的价格计算，每天的输入成本就是2400万token，大概在几十美元量级。

对比直通模式：如果每轮对话塞入完整对话历史5000 token加知识文档5000 token，每次输入约1万+ token，同样1万次调用，每天成本直接翻几倍。

这就是为什么我反复强调：context-mode不只是效果优化问题，也是纯纯的经济学问题。

4. 线上环境最常见的4个问题与排查方案

4.1 请求超时，上下文悄悄溢出

有个现象很隐蔽：API不报错，但响应明显变慢，甚至频繁超时。我排查后发现是上下文没做“退役”机制。用户聊了30轮，每个messages都带上完整历史，token数从几百涨到了五六千。虽然没超过最大窗口，但KV Cache和推理耗时一直在涨。

解决思路很简单：设置一条硬性token阈值线，在把messages发送给模型前做一次token统计。超了就触发裁剪策略。

def estimate_tokens(messages): # 基础估算：中文约1字≈1.5 token，英文约1词≈1.3 token total = 0 for msg in messages: total += len(msg.get("content", "")) * 1.3 return int(total) def ensure_context_limit(messages, hard_limit=4000): while estimate_tokens(messages) > hard_limit: # 从第二新的消息开始丢弃（保留系统指令和最后一条用户消息） if len(messages) <= 3: break messages.pop(1) # 丢弃最早的非系统消息 return messages

这里有个坑要注意：系统指令永远不要被滑动窗口淘汰。很多人裁剪时没保护好system prompt，结果模型行为变得不可控。

4.2 模型“失忆”，摘要模式丢关键信息

摘要模式的副作用就是“压缩失忆”。用户在第3轮提到“我喜欢靠窗的位置”，到第15轮摘要里可能就没了，结果模型推荐了一个包厢。

我的排查经验是：在摘要更新时，不能只靠模型的自觉。你要在prompt里显式要求保留特定类型的信息。比如做客服场景，prompt里明确写“保留用户联系方式、地址、情绪状态、具体诉求”。这四类信息绝对不能丢。

除此之外，可以给摘要设定“最低长度”阈值，比如摘要必须不少于100个token。太短的摘要信息密度不够，压缩比例太高，要警惕关键信息丢失。

最稳妥的组合拳还是“摘要+RAG混合”：摘要负责整体“记住聊了什么”，RAG负责在需要细节时去原始历史里捞具体内容。这样既不会让上下文爆炸，也不会丢失关键细节。

4.3 开放域问答不准，检索注入失效

RAG模式最常见的问题是：检索回来的文档跟用户问题完全对不上。这一般有三个原因。

第一，是切块太粗，一个块里混杂了多个主题，向量化之后“焦点模糊”。这种情况要把切块大小从1000字下调到300字左右，提高检索粒度。

第二，是query和文档的语义表示方式不匹配。用户问的是口语化表达，库里存的是书面语，向量距离远，检索不到。这种情况下可以做两类优化：一是对用户query做一次“改写”或“扩展”，再去做检索；二是调整embedding模型，选择对短文本和口语更友好的模型。

第三，是检索到的块数量太少。我建议开始时把top_k调大到10，先看召回率，再逐步压缩到3~5。

排查RAG质量时，强烈建议你做一次“白盒测试”：把每次检索回来的Top K文档都打印到日志里，看接口实际拿到的是什么。如果日志显示检索结果没问题但模型答错，那是prompt或模型的问题；如果日志显示检索结果本身就离谱，那是向量检索链路的问题。分清楚这两个环节，你的排查效率会高很多。

4.4 会话越长越慢，延迟快速恶化

即使你用了滚动窗口，如果窗口长度太大，每次请求需要重新处理的历史token还是会让服务变慢。这里有个很反常识的点：有些开发者在每个用户消息里都放上千字的系统指令，明明系统指令根本没有变化，却每次都全量重发。

解法是提示词缓存。目前很多主流大模型平台都支持对重复前缀做KV Cache缓存。你在构建messages时，应该尽量保持“前缀不变”，把变化的内容放在后面。比如系统指令+固定知识库导语放在最前面，用户问题放在最后面。这样每次请求都只需要重新计算多变的那部分，延迟能降很多。

另外，如果业务允许，尽量让系统提示词保持精简。那些又臭又长的“人设铺陈”，对用户体验没有实际帮助，只会让延迟和成本飙升。

5. 调参心得与默认配置参考

我自己在项目里用过的默认配置，给你做个参考。这个组合不保证适合所有业务，但至少是一个经过验证的起点。

对于知识库问答，我一般用“RAG+滚动窗口”组合：系统指令恒定，知识检索Top 3注入，历史只保留最近6轮。这样单轮输入控制在3000 token以内，成本和延迟都可控。

对于客服场景，我用“滚动窗口+摘要”组合：窗口保留最近10轮，每5轮触发一次摘要更新。摘要里强制要求保留用户诉求、时间地点、情绪等关键字段。

对于Agent工具类场景，我用“完整任务上下文”模式：因为Agent执行任务时，每一步的工具返回都可能是下一步决策的依据，不能随意裁剪。但我要严格做步骤限制，防止Agent陷入无限调用。

最后再说一个小技巧，如果你发现自己总是在“输入太多”和“模型记不住”之间摇摆，建议先给项目加一个“信息提取层”：不管用户聊了什么，先提取出结构化的用户画像、关键实体、未完成事项，然后用这些结构化数据来构建上下文。这比在原始文本上反复裁剪要可靠得多。

context-mode这个东西，说穿了就是从“给模型喂东西”变成“替模型选东西”。它不舒服的地方在于，你需要为每一种业务重新思考哪些信息值得进入上下文，哪些必须被丢弃。但这个思考过程的价值，往往比换一个更强模型的效果还要明显。至少在我做过的所有项目里，那些把上下文策略调明白的系统，稳定性和成本表现都远好于那些只会堆参数的系统。