企业官网建设流程全解析

1. 曾让我失眠的问题：文档问答里那句“他似乎忘了我们在聊什么”

年初接了一个企业知识库问答的项目，客户要求不高，就是让员工能用自然语言查制度、查流程。我最初的做法也很“标准”，把文档切片、做向量检索，把命中的片段拼进Prompt，一次性丢给大模型。demo阶段跑得很顺，所有人都觉得上线稳了。

结果灰度测试第一周就出事了。一个员工连续问了三个问题：

• “报销差旅费需要什么材料？”
• “我们部门是市场部，申请流程有什么不同？”
• “那我上周提交的那单，财务说缺发票，还能补吗？”

第三个问题，模型答得支离破碎，甚至反问“您指的是哪一单”。原因显而易见——前面的对话历史和检索到的文档片段全被塞进同一个上下文里，互相打架，模型根本分不清哪些是“本次要处理的单据”，哪些只是“历史提问中的例子”。

那个周末我把自己关在房间里，开始认真研究一个东西：context-mode，上下文模式。

说句实话，这不是某个开源项目的名字，也不是某家大厂发布的新功能。它是你在做大模型应用时绕不开的一组设计决策——上下文窗口里的内容，到底以什么形态组织、按什么顺序排列、什么时候保留、什么时候丢弃、什么时候去外部检索。它决定了你的应用是“看着聪明”还是“真的聪明”。

这篇文章就围绕我在这个项目里踩过的坑、做过的手术和最终沉淀下来的方案展开。如果你是做RAG、智能问答、Agent这类应用，被多轮对话“失忆”、上下文溢出、成本飙升这些问题折磨过，这篇应该能给你一些能直接抄的作业。

2. 上下文窗口的三个隐藏瓶颈：长度只是第一道坎

2.1 注意力塌缩：模型真正“记住”的，远没有你以为的那么多

最开始我以为，上下文窗口就像一个更长的草稿纸，只要放得下，模型就能读到。但翻了几篇关于长上下文模型评测的论文之后，我发现事情没那么简单。

业界早就有一个被反复验证的现象，学术上叫Lost in the Middle，翻译过来就是“中间丢失”。模型对上下文开头和结尾的内容记忆最好，对中间部分的利用效率明显下降。你辛辛苦苦把一百页产品手册塞进窗口，模型真正有效利用的，可能只有前几千和最后几千token的范围内。

这意味着什么？如果你只是把历史对话、检索片段、系统指令一股脑按顺序拼接，排在中间偏后的检索内容很可能处于“视觉盲区”。它会读到这些字，但注意力和权重分配已经不够了，生成时就表现为忽略、混淆、或者答非所问。

2.2 成本与延迟的账单：每多一轮对话，都在烧钱

第二个瓶颈是算账。

我们用的是按token计费的大模型API，上下文内容要重复计费。简单算一下就能看出问题：假设一次完整回答需要生成300个token，如果上下文固定塞了8000个token，实际账单上消耗量是8300个token。看起来单次不多，但一个用户一天对话20轮，每轮都把历史全文带上，上下文还会越滚越长——第20轮的时候，可能已经带着四五万token在跑。

我拉过一次账单，纯上下文的费用占了总消耗的70%以上。更麻烦的是延迟，输入token一多，首字返回时间肉眼可见地变慢，从几百毫秒涨到三五秒。客户的反馈很直接：“这个机器人转圈圈的时间比我翻纸质手册还久。”

2.3 注入噪声：无关内容会主动拉低回答质量

第三个问题最隐蔽，也最容易忽略。你以为“内容多等于信息全”，实际上，无关的上下文对模型来说不是中性的，而是负面的。

我在测试里做过一个对照：一份技术文档里混入一段毫无关系的行政通知，结果模型在回答技术问题时，开始“一本正经”地引用行政通知里的措辞。你给它什么，它就会倾向于顺着什么风格和范围来回答，哪怕那些信息与当前问题毫无关系。

这就是context-mode里最核心的对抗点——你要控制的不是“放得下吗”，而是“该放进去吗”。上下文不是水龙头，不能只想着开大，它更像一个行李箱，每一件行李都要问一句：这次旅途真的需要它吗？

这三重瓶颈叠在一起，让我意识到，与其抱怨模型笨，不如承认自己的上下文管理模式是粗暴的。与其追求更大的窗口，不如先把手里的窗口用得好一点。

3. 一套可落地的上下文分层管理方案：我现在的标准姿势

想清楚了问题所在，我开始把上下文拆成四个层，每一层各司其职。这个方法我用了大半年，稳定性和效果都明显好过之前“一锅炖”的做法。

3.1 第一层：系统指令层，负责扮演“人设”和“铁律”

这一层是最贴近窗口开头的部分，专门放系统的固定指令，比如角色设定、回答风格、安全红线、输出格式。它全程不变，每个轮次都会携带，但因为设计得紧凑，通常能压到500到800个token以内。

这里有个容易被忽略的细节：系统指令不要写废话。“你是一个有用的AI助手”这种话纯属浪费窗口。真正有用的是约束规则，比如“如果用户问的是报销流程，必须引用知识库中的具体条款编号，不得凭经验作答”。我带过的新人常常在指令里堆形容词，结果就是指令越长，模型越抓不住重点，还不如直接给它“当A时做B，遇到C就D”这种句式。

3.2 第二层：外部检索层，按需注入而不是全量塞入

这一层放的是和当前问题强相关的文档片段、知识库结果、数据库记录，是RAG的主要战场。关键原则是“少而准”。

我在项目里把检索策略从“取Top 5片段全塞”改成了“取Top 10片段、重排后只取Top 3”。一开始大家都不放心，担心信息不够。实际上，精准的三段内容，远比五段里混着两段边角料的效果好。因为模型生成时能享受到的“注意力预算”是有限的，你把预算浪费在低相关片段上，核心信息反而得不到足够的权重。

3.3 第三层：会话记忆层，摘要滚动加关键事实提取

这一层解决多轮对话的“记忆连续感”。但我的做法不是把历史对话原文全堆进去，而是维护两条线：

• 滚动摘要：每经过若干轮，让模型用一句话总结之前的对话主线。
• 关键事实列表：抽取对话中出现过的实体和重要状态，比如“用户的市场部员工”“上周提交了一单差旅报销”“该单缺发票”。

这样，第三层始终能控制在1000个token以内。模型既知道你们聊到哪了，又不会被历史原文里的细枝末节带偏。至于具体怎么实现，我在后面第4章会展开。

3.4 第四层：工作记忆层，只服务“当前这一步”

这一层对应的是当前问题的即时上下文，包括用户刚刚输入的query、当前Agent正在调用的工具返回结果、正在处理的临时数据。它是最靠近窗口末尾的部分，也是最容易被模型“记住”的区域，所以一定要留给当前最关键的内容。

我自己的习惯是，把窗口末尾的几百个token专门留出来，只放“本次要回答的问题”和“必须完成的动作”，相当于给模型一个锚点：看到最后，你就知道自己当下要做的是什么。

这四层落地的顺序和比例，我用一张表来总结，方便你对照自己的场景做调整：

这个预算只是一个起点，关键是你要意识到：每一层都应该有明确的预算上限，而不是让上下文自由膨胀。没有了预算意识，context-mode就无从谈起。

4. 上下文压缩的实战取舍：该丢就丢，该留的必须留

4.1 三种压缩策略：摘掉什么，保留什么

分层管理解决的是“结构问题”，接下来还有一个“容量问题”——就算分了层，用了两万token窗口，对话拉长到五十轮，还是会满。这时候就需要压缩。我实际试下来，主流的压缩策略有三条路，各有各的适用场景：

• 全文摘要式压缩：把一段对话历史直接让模型总结成一两句话。优点是通用，缺点是丢细节，尤其容易丢具体的数字、日期和人物称谓。
• 关键信息抽取式压缩：不生成摘要，而是抽取对话中的结构化信息，比如“用户ID=u_1024”“订单号=SO20240311”。优点是精确、适合检索和后续处理，缺点是读起来不像自然语言。
• 裁剪丢弃式压缩：按重要性给消息排序，把低优先级内容直接丢弃。比如用户礼貌用语、无关寒暄、重复提问。优点是保留完整原文的片段，缺点是可能丢掉隐线。

我现在的做法是三者混合。寒暄和重复内容直接裁剪，剩下的对话主干做关键信息抽取，再配一条滚动摘要兜底。这样既保住了对话的“骨架”，又留了“脉络”，还不至于让摘要把细节全吞掉。

4.2 一个可用的滚动摘要实现：L1缓存式的记忆维护

这里放一段我项目里实际用过的伪代码逻辑，思路是“摘要的摘要”——每一小段对话先产出一条小结，等小结攒多了，再condense成更高层的摘要，避免每次都拿全部历史去重新总结：

class ContextMemory: def __init__(self, max_turns=6, max_summary_len=300): self.recent_turns = [] # 原始对话消息 self.rolling_summary = "" # 滚动摘要 self.key_facts = {} # 关键事实字典 def add_turn(self, user_msg, assistant_msg): # 1. 最新一轮原文进入缓存 self.recent_turns.append({"user": user_msg, "assistant": assistant_msg}) # 2. 攒满阈值就做一次摘要合并 if len(self.recent_turns) >= self.max_turns: combined_text = self.rolling_summary + "\n" + self._json_dumps(self.recent_turns) new_summary = self._summarize(combined_text, max_len=self.max_summary_len) self.rolling_summary = new_summary self.recent_turns = [] # 3. 抽取关键实体，更新事实表 entities = self._extract_key_facts(user_msg + "\n" + assistant_msg) for k, v in entities.items(): self.key_facts[k] = v # 同名实体覆盖，保留最新状态 def build_context_block(self): # 最终返回给LLM的会话记忆层文本 return { "rolling_summary": self.rolling_summary, "key_facts": self.key_facts, "recent_turns": self.recent_turns[-2:] # 只保留最近两轮原文 }

这套逻辑里的关键心法，是“摘要的摘要”而不是“全文的摘要”。每隔几轮就压缩一次，你的摘要不会因为对话太长而失控。每次压缩的输入是上一次的摘要加增量的原文，成本固定，不会随着对话轮数无限增长。

4.3 压缩的红线：这三类内容千万不能动

压缩不是万能药，我吃过的亏可以帮你画几条红线：

第一，身份与约束类信息不能压缩。比如用户一开始说了“我是公司财务部的，需要走特殊审批流程”，这类信息一旦被摘要丢掉，模型后面就可能按普通流程回答，而且你很难发现哪里错了。

第二，时间顺序不能乱。对话里的先后关系经常是隐性的逻辑链，比如“先申请、后审批、再打款”。做摘要时模型容易把顺序模糊化，所以我要求摘要中加入时间标记或步骤序号。

第三，否定与反悔信息要显式保留。用户说“我不需要发票了，改为电子凭证”，如果没有显式记录“状态变更”，模型会继续引用旧的发票规则。我把这类信息单独维护成一条“状态变更记录”，不合并到摘要里，确保每次组装上下文时它都在。

压缩的本质是取舍，而取舍的底线，是那些一旦丢失就会导致结论反转的信息。宁可多留几百个token，也不能让模型拿着一个残缺的事实去做推理。

5. 检索增强与上下文模式的协同：该“外挂”就别硬塞

5.1 判断标准：哪类内容必须走检索，哪类可以常驻上下文

很多团队的误区是：明明有向量知识库，却还是什么都往上下文里塞。我用一个简单的二分法来判断：

• 如果内容是“全局不变”的规则和指令，比如公司制度、系统操作手册，放向量库，按需检索即可。
• 如果内容是“本次会话特有”的状态和事实，比如用户刚提交的单号、用户所在部门、正在审批的环节，放上下文里的记忆层。

这个判断标准帮我解决了一个长期困惑：为什么文档一起检索出来，模型还是答不准？因为制度条文本身不会变，但用户的具体状态每轮都在变。混合在一起时，模型需要从大量静态文本里捞出动态状态，难度陡增。拆开之后，静态知识走检索，动态状态走记忆层，各管各的，准确率明显提升。

5.2 查询改写和重排：为了让检索层“听懂”当前的上下文

检索层的效果上限，很大程度上取决于你给向量库的query是什么。原始用户问题往往太口语、指代不明。比如用户问“那单后来怎么样了？”，如果直接拿去检索向量库，必然什么都匹配不到。

我在context-mode里加了一步查询改写：

def rewrite_query(user_query, context_memory): prompt = f""" 请根据已知的会话上下文，把用户的最新问题改写成一个独立的、可检索的查询。 用户问题：{user_query} 已知关键事实：{context_memory.key_facts} 输出要求：只输出改写后的查询，不要解释。 """ return llm.call(prompt)

改写完的query再去做向量检索，召回率提升明显。另一个值得注意的环节是重排，召回的Top 10片段里可能有两条都是同一个章节的重复内容，不重排的话，模型会看到两遍相同信息，新内容反而没位置。我用的工具是bge-reranker，实测下来把重排后的Top 3放进上下文，比直接塞Top 5的效果更好，而且token成本低了40%。

5.3 实测对比：一次真实的模型效果改善记录

我在项目里做过一次A/B对比。对照组是“全量历史+Top5片段”的老方案，实验组是“分层上下文+重排Top3+滚动摘要”的新方案。测试集是200个真实用户问题，由两个同事按1到5分独立打分。

数据摆出来之后，团队里最反对“动上下文结构”的同事也服了。准确率的提升其实不意外，因为模型没被噪声干扰了；延迟和成本的下降则是分层带来的意外之喜。这件事给我的启发是，做AI应用，别急着换更大参数的模型，先把上下文结构理顺，往往性价比更高。

6. 生产环境中的两次惨痛教训：并发隔离和上下文污染

6.1 多用户上下文串台：差点把A公司的数据回给B公司员工

方案成型之后，我一度觉得问题都解决了，直到上线第二周收到一个投诉——用户问“我们公司食堂补贴是多少”，机器人回答的是另一家公司的福利制度。

排查后确认，代码里用了全局单例的上下文缓存对象。两个用户共用了同一个ContextMemory实例，后一个用户的关键事实覆盖了前一个用户的。这是非常典型的“局部变量没想清楚就上线”的坑。

修复方式并不难，把上下文管理类设计成按会话ID隔离的实例池：

class ContextStore: def __init__(self): self._sessions = {} def get_session_memory(self, session_id: str) -> ContextMemory: if session_id not in self._sessions: self._sessions[session_id] = ContextMemory() return self._sessions[session_id]

但真正值得写下来的教训是：context-mode不是只在前端组Prompt，它涉及整个会话生命周期的状态管理。如果后端没有做好隔离，再精巧的上下文分层也会被数据污染瞬间击穿。上线之前，多用户并发压测是你必须做的事。

6.2 工具调用把上下文撑爆：当Agent开始调用一连串API

第二个坑是我做Agent化改造时遇到的。流程是用户提问、Agent规划、调用API查数据、把结果写进上下文、再让模型生成答案。听起来没问题，但一个复杂的查询可能触发五六个工具调用，每个工具返回几千token的数据。所有返回都堆进上下文之后，窗口瞬间爆掉。

我最终的解决思路是两层：

• 给工具返回设置上限：单次工具返回超过一定长度就强制截断或先做摘要，只把结构化关键字段留在上下文里。
• 不把工具结果直接当最终答案的素材，而是作为中间数据。模型需要先基于工具结果生成一个“brief”，再基于brief做最终回复。

这一层改动之后，Agent在复杂任务里的稳定性提高了不少。工具调用的本质是“外挂”外部系统，和检索一样，也要遵守“按需注入”的原则，不能因为接了API就让上下文的胃口跟着变大。

6.3 上下文健康度监控：量化指标带我避开“悄悄变差”

最后再分享一个我最常推荐给身边人的习惯——给上下文建立监控指标。不要等用户投诉了才去翻日志，我日常盯三个数字：

• 上下文总token数：超过预算的90%就告警，说明压缩策略没跟上。
• 每次请求的检索命中率：检索层拿回来的片段如果经常不相关，先检查query改写和重排。
• 多轮会话的“信息熵”：同一会话内，关键事实表的条目数是否只增不减，如果摘要越压越短但关键事实没增长，说明系统正在遗忘重要上下文。

这些指标不需要什么重型监控平台，用最朴素的日志统计就能做。但有了它们，context-mode就不再是设计时的一次性工程，而是运行时可观测、可调节的系统能力。

7. 关于context-mode，我最后想说的三句话

踩过那么多坑之后，我对context-mode的理解已经不只是“把上下文管理好”这么简单了。它本质上是在做信息资源的分配：模型每一轮能获得的注意力是有限的预算，系统设计者的工作，就是把这笔预算花在最值当的地方。

我在项目里也犯过“过度设计”的错，把分层搞得极其复杂，最后维护成本比收益还高。所以如果你刚开始改造，我建议从最简单的两件事入手：一是把系统指令精简到只留行为约束，二是把多轮历史改成滚动摘要加关键事实。这两步做完，你大概率就能感受到明显变化。

在动手调整时，还有三个小建议值得记在工位上：

• 每次改动上下文结构，都要准备至少几十条真实用户问题做回归测试，光靠两三句demo验证不出问题的。
• 上下文管理的代码要单独抽成模块，不要散落在业务逻辑里，否则后面换模型、调策略时会痛不欲生。
• 多关注模型在不同窗口位置的表现差异，把最重要的信息放在开头和结尾，别让它在中间地带“等死”。

技术迭代很快，今天的主流做法可能过半年就会被新方案替代，但“如何分配模型的注意力”这个问题，会一直存在。如果你也在做类似的项目，希望这篇踩坑记录能让你少走几步弯路。