企业官网建设流程全解析

1. context-mode到底要治哪个病：先聊聊我那次"上下文失控"现场

先讲一个真实的翻车案例。上个月我在调试一个偏客服场景的AI助手，需求很简单：用户可以在对话框里连续提问，AI要记得前面聊过的订单号、退款诉求、用户语气偏好。一开始干净利落，问什么答什么，准确率看着很舒服。等对话超过20轮之后，场面开始失控——它把前面已经确认过的"退款金额是378元"算成"3780元"，把另一个用户的历史订单当作当前用户的需求，甚至在几轮之后突然说出一句"根据您之前提到要退货，但您还没告诉我订单号"——可订单号明明在第7轮就报过了。

我第一反应是模型不行，换更大的模型，结果只是把"忘事"从第20轮推迟到第30轮。后来我静下心复盘，发现问题的根子压根不在模型参数上，而在我的应用层没有一个真正管理上下文的机制。所有历史消息全部原封不动地塞进窗口，模型要在这堆越来越长的文本里自己找重点，它当然会眼花。

这就是我被"context-mode"这个概念狠狠教育了一课的过程。其实说白了，context-mode不是什么高深莫测的框架，而是一套关于"AI对话中哪些信息该进上下文、以什么形式进、什么时候该被淘汰"的工程实践。它解决的核心矛盾非常简单：上下文窗口是有限的，但对话产生的内容是无限的。谁掌握了把无限内容塞进有限窗口的调度权，谁才能在长对话场景里保住回答质量。

为什么这个词最近越来越热？因为大量应用已经从"玩一玩大模型"进入到"认真做产品"的阶段。过去大家只关心提示词写得好不好、模型选得大不大，现在真正卡脖子的恰恰是上下文管理。你写再多提示词模板，用户连续聊上几十轮之后，该死记的记不住、该忽略的又乱入，产品体验还是崩。所以context-mode能成为技术热词，本质上是行业进入深水区之后的必然结果。

我做这个项目时踩了不少坑，今天就把我从"无脑塞全部历史"到"建立分层上下文管理"的完整过程梳理出来，包括三种主流模式的对比、一套能直接落地的模块设计、以及实测数据。文章会偏向工程实现，适合正在做AI应用、尤其是对话类和Agent类产品的开发者参考。你要是刚接触大模型开发，也能借此知道上下文窗口背后还有很大一片值得动手优化的空间。

2. 三种主流的上下文管理模式：截断、压缩、检索，没有银弹但有优先级

2.1 滑动窗口截断：最朴素也最容易误伤

先说我最早用的方式：滑动窗口截断。逻辑很简单，设定一个最大轮数或最大token阈值，超过就把最早的对话从消息数组里删掉。比如窗口上限是20轮，第21轮进来，第1轮就被挤出去。代码实现十分钟就能搞定，但副作用立竿见影。

最典型的场景是"被挤掉的信息恰恰是关键信息"。用户在第2轮报了订单号，第5轮问退货运费，等到第18轮终于问"那总共退多少钱"，订单号早就被挤出了窗口，模型只能尴尬地反问。我一开始尝试调大窗口，从20轮加到50轮，表面上撑住了更多场景，但token消耗水涨船高，响应延迟也跟着翻倍。更麻烦的是，窗口越大，模型越容易被无关的早期闲聊干扰，甚至出现"看到A用户的地址却当作当前用户收货地址"这种串台问题。

这个模式真正的适用场景非常狭窄：短对话、单轮决策、对历史信息依赖极低的任务。给模型喂一个固定大小的上下文窗口，本质上是在赌"关键信息一定出现在最近N轮里"，可现实业务从来不会这么配合。

2.2 摘要压缩：用信息密度换token效率

截断不行，我开始试摘要压缩。思路是用一次额外的模型调用，把已经滚出窗口的早期对话"提炼"成一段几百字的摘要，再和最近的原始消息一起喂给主模型。

听起来很美，实际操作起来有几个躲不过去的坑：

• 摘要会有损。模型在压缩时天然倾向于保留事件主干，丢掉数字、语气、隐含条件这些细节。"退款378元"可能被压成"退款已处理"，等到后面要精确金额时，摘要里根本查不到。
• 摘要会累积误差。第10轮基于第1-5轮的摘要再生成新摘要，第20轮又基于第10轮的摘要生成新摘要，多层嵌套之后，信息失真是指数级放大的。
• 多一次模型调用，成本和延迟都要认真算账。如果你在做一个高并发的在线服务，每轮对话都额外请求一次摘要模型，API账单会给你上一课。

但摘要压缩并非一无是处。它特别适合处理"背景性信息"——用户在第1轮说"我是老客户，之前买过你们家三台空气净化器"，这类对话与当前问题的关联是宏观的、态度性的，不需要精确到字段值。把这类上下文压成摘要，把订单号、金额、日期这类结构化信息单独提取出来存好，这个思路反而非常接近我最后采用的方案。

2.3 检索增强：把上下文变成可被查询的资产

检索增强是我踩了一圈坑之后觉得最值得投入的方向。核心思路变了：不再是"把尽可能多的历史塞进窗口"，而是"按需把最相关的历史捞出来塞进窗口"。每轮对话来临时，应用层先对历史消息做一次检索，挑出与当前问题最相关的几条，拼进上下文。窗口里永远是最新消息加上几条被检索命中的高价值历史。

这个模式的优势在于精准投放token。我在一个偏技术FAQ的助手场景里实测过，一个200轮的长会话，用滑动窗口截断至少需要保留最近50轮才勉强不翻车，而用检索增强每轮只喂最近10轮加检索到的5条历史，回答质量反而更高、延迟更低。

但检索增强也New出两个新麻烦：

• 你必须真的去做索引。历史消息要存下来、要切块、要向量化或倒排索引，这一整套基建不是加一个if-else能搞定的。
• 检索不一定准。关键词重叠度高但语义无关的消息，或者用户表达过于口语化，检索结果都会偏离真实需求。这一步的工程质量，直接决定context-mode的上限。

2.4 我的选型结论：按信息类型分层管理

三种模式都试过之后，我的结论是：它们不是互斥的，而是应该按信息类型分层使用。任何一个真实的对话场景里，上下文信息天然分成几类：

• 最新对话流：直接保留原始消息，保真度最高
• 背景性信息：摘要压缩，保留宏观语义即可
• 事实型信息：如订单号、金额、日期、用户ID，从消息里抽出来结构化存储，需要时精确检索
• 长期记忆：比如用户偏好、历史投诉记录，通常跨会话存在，单独建一张记忆表

这个分层思路，就是我后面落地那套context-mode模块的核心依据。它本质上是把"上下文窗口"这个线性容器，改造成了"按需装配的组件库"。

3. 自建一套context-mode：从需求拆解到模块落地

3.1 上下文生命周期：写入、活跃、归档、召回

动手写代码之前，先把生命周期的模型想清楚，这套模块一共管四种状态。

• 写入（Write）：每一轮用户消息和AI回复产生后，立刻进入上下文系统，同时触发后续的归档流程。
• 活跃（Active）：刚产生的内容放在活跃区，也要喂给模型。活跃区的上限由一个token预算控制，超出部分会被清理或压缩。
• 归档（Archive）：活跃区放不下的历史消息，按类型分别进入摘要文件、结构化事实库或向量索引库。
• 召回（Recall）：每一轮新提问来临时，根据问题从归档区检索出最相关内容，重新注入活跃区。

这个划分看起来像玩概念，实际实现后你会发现，它把"上下文管理"从被动裁减变成了主动调度。每次请求来的时候，系统的任务不是"删掉什么"，而是"装配什么"。

3.2 核心数据结构：活跃区、摘要库、事实库、向量索引

我把这几类数据模型直接列出来，你照着建表就能跑。

活跃区最直观，就是一个带token计数的消息队列，我用Python的deque实现，每压入一条消息就累加token估算值，超出预算就从左侧弹出最旧的消息。这里说的token估算可以用tiktoken这类分词库做，不追求精确，但误差要稳定。

摘要库本质是一张表，记录摘要的层级和对应的消息范围。我用了两级摘要：第一级把10轮左右压成一条摘要，第二级再把若干条一级摘要压成一条更粗粒度、时间跨度更大的摘要。这样模型总是能拿到"昨天聊了大概什么"和"刚才聊了具体什么"两个层级的视图。

事实库是整套系统里性价比最高的部分。利用模型从历史消息里抽取结构化数据：订单号、金额、偏好、状态变更，存储成JSON文档。召回时用规则匹配加轻量语义匹配，效率非常高。比如用户问"我之前那个退款的单子呢"，规则命中"退款"，直接查事实库中状态为退款中的订单，准确率惊人地高。

向量索引库放在最后，是因为它最重但也最灵活。我把归档消息切成256字的块，用embedding模型转成向量，存入向量数据库。召回时先向量检索topK，再做一轮重排。这块适合处理那些既不属于事实也不适合摘要的开放性问题，典型的如"我之前有没有提过对噪音敏感"这类模糊查询。

3.3 关键实现：分层管理器和召回器的协作

这一节给一个可运行的骨架代码，核心是ContextManager类的设计。

import json from collections import deque from dataclasses import dataclass, field from typing import Optional @dataclass class FactRecord: fact_type: str # order_id / user_pref / status_change content: dict # 结构化字段 occurred_at: int # 消息序号 source_msg: str # 便于追溯 @dataclass class ContextManager: active_window: deque = field(default_factory=deque) active_tokens: int = 0 max_active_tokens: int = 4000 summary_store: dict = field(default_factory=dict) # {level: [summary_str]} fact_store: list[FactRecord] = field(default_factory=list) vector_store: list = field(default_factory=list) # (vector, msg_id, text) def add_message(self, role: str, content: str, tokenizer): tokens = len(tokenizer.encode(content)) self.active_window.append({"role": role, "content": content, "tokens": tokens}) self.active_tokens += tokens # 超出预算：归档最旧消息 while self.active_tokens > self.max_active_tokens: oldest = self.active_window.popleft() self.active_tokens -= oldest["tokens"] self._archive(oldest) def _archive(self, message: dict): fact_records = extract_facts(message["content"]) # 模型抽取 self.fact_store.extend(fact_records) # 进入向量索引 chunks = split_text(message["content"], chunk_size=256) for ch in chunks: vec = embed(ch) self.vector_store.append((vec, message["content"], ch)) # 触发摘要更新 self._update_summaries(message) def build_prompt(self, question: str, top_k: int = 5) -> str: # 召回：先向量检索，再精确匹配事实库 hits = self._vector_search(question, top_k=top_k) fact_hits = self._match_facts(question) # 装配：摘要库总览 + 检索命中块 + 事实记录 + 活跃区最新消息 prompt_parts = [] prompt_parts.append(self._get_summary_view()) prompt_parts.append("【相关历史片段】") for h in hits: prompt_parts.append(h) prompt_parts.append("【结构化事实】") for f in fact_hits: prompt_parts.append(json.dumps(f.content, ensure_ascii=False)) prompt_parts.append("【最近对话】") for m in list(self.active_window)[-10:]: prompt_parts.append(f"{m['role']}: {m['content']}") return "\n".join(prompt_parts)

说几个骨架代码里值得注意的设计决策：

• 活跃区的token预算我设为4000，配合大模型总窗口，给召回内容和系统提示词留出足够空间。这个数字不是随便拍的，后面实测章节我会给出不同预算下的质量对比。
• build_prompt的装配顺序有讲究。先给模型一个摘要视角，再给具体证据，最后给最近对话流，模型更容易理解"哪些是长期背景、哪些是即时消息"，比一股脑全堆上去要好。
• 每次add_message时同步做归档，而不是攒一批批处理。好处是均匀分摊计算开销，避免某次请求突然迟延。

4. 实测数据：三种模式在真实任务上的表现对比

4.1 测试任务与评价指标

光说思路不给数据，跟耍流氓差不多。我把三种模式放在同一个客服问答场景里做了两周的A/B测试。任务设计是模拟一个交易纠纷处理流程，用户会按照脚本提供订单号、反馈问题、补充细节、询问进度，一共20轮。评测指标选了三个：

• 事实准确率：AI回复中的订单号、金额、日期是否与脚本一致
• 连续性：AI是否记得自己上一轮给出的处理方案
• token效率：每轮平均消耗的输入token数量

模型统一用同一个商用大模型API，温度设为0，避免随机性干扰结论。历史消息都来自同一个脚本，只在上下文管理策略上做差异。

4.2 token消耗和响应延迟的具体数据

先看token表现。滑动窗口截断使用最近20轮原始消息，每轮平均消耗约4200个token。摘要压缩把早期10轮压成摘要，每轮平均约2600个token，省了接近四成。检索增强最省，活跃区只用最近6轮加检索召回内容，每轮平均1800个token，比截断少了57%。

延迟方面，检索增强因为需要查询向量库并做一次重排，在装有30条归档消息的小库上多花了约80毫秒。但模型输入token少了，主模型生成响应的时间反而快了，总体端到端延迟反而比截断模式低了约15%。摘要压缩是最吃亏的，每次对话都要先额外请求一次摘要模型，多了一到两秒的等待，在交互式场景里体感很明显。

4.3 质量评测：为什么截断在复杂任务上输得那么惨

事实准确率差异非常惊人。滑动窗口截断在20轮对话里，关键事实（订单号、金额）出错率高达27%，而且错误越到后面越频繁。原因也很直白：脚本里的订单号在第2轮出现，到第10轮就被窗口挤掉了，模型只能靠猜。摘要压缩稍好，出错率11%，主要错在金额这类精确数值上，摘要无法保留完整的数字细节。检索增强表现最好，出错率降到3.5%，仅有的错误来自用户消息中未准确提取到事实库的口语化表述。

连续性上的差距同样明显。截断模式在需要多轮协作的任务里，经常出现"上一轮说要发退款链接，这一轮又推荐用户去后台自行申请"的自我矛盾。摘要压缩因为保留了宏观语义，这个问题改善不少。检索增强在跟踪方案连续性上表现最佳，因为活跃区虽然只保留最近6轮，但每次都把上一轮AI给出的处理方案作为状态记录，通过事实库精确召回。

我把三类模式的核心表现整理成一张对照表：

这张表基本验证了我之前的判断：省token、提质量、控延迟，三个目标要靠检索增强同时解锁，但它也需要你为它搭一套周边基建。

5. 最容易翻车的边界情况：上下文污染、过期信息、误召回

5.1 上下文污染：模型把不该关注的内容当成重点

vector检索的痛点不会缺席。最典型的翻车场景是"关键词污染"——用户当前问的是"你们家物流一般几天能到"，检索系统在历史记录里发现有另一条消息是用户抱怨"上次物流用了6天才到"，语义相关度极高，于是把它召回并喂给模型。模型看到这条抱怨，生成回复时容易带着安抚语气，甚至把那次远超预期的物流时效当作当前标准来回答，造成事实偏差。

我的补救措施是给每一条归档消息打标签：情绪型消息、事实型消息、操作指令型消息。召回时如果要回答的是客观查询，就降低情绪型消息的排序权重。这个规则用起来很稳，模型回复里的主观倾向性明显降低。实现上就是在归档消息的元数据里加一个message_type字段，在重排阶段加一个过滤分支。

5.2 过期信息：昨天的结论干扰今天的判断

比污染更隐蔽的是信息过期。我遇到过用户在第5轮说"我不退款了，改成换货"，事实库如果还保留之前抽取的"退款请求"状态，就会在后续对话中不断把旧状态召回，导致回答出现前后矛盾。关键问题是：事实库的记录应该如何处理状态更新？

我现在采用的做法是给事实记录加置信度衰减和版本链。每条事实记录带一个superseded_by字段，指向更新它的新记录。召回时查询版本链末端，如果用户明确说了一句"我改成换货了"，新记录生成，旧记录自动标记失效。失效的记录不会被喂给模型，但会被保留用于审计和追溯。这个设计帮我把跨轮次状态更新的错误率从17%压到了2%以下。

5.3 误召回：检索得分高不等于真的相关

还有一类翻车场景来自"字面相似但意图不同"。用户问"你们的退货地址是哪里"，历史记录里有一条"退货地址已通过短信发送"，字面上完全命中关键词，召回得分很高。但模型其实更需要知道的是具体的地址内容，而不是"地址已经发过了"这个状态。这种答案根本没法满足用户。

为了处理这个问题，我在召回之后加了一步意图对齐。对用户当前问题先做一个轻量分类，判断类型是"查询事实""询问状态""操作请求"还是"情绪吐槽"，然后对召回到的结果做对应类型的相关性打分。查询事实类的问题，就优先召回包含具体实体信息的消息；询问状态类的，优先召回状态变更记录。这一步用规则加少量示例就能做，不必上多复杂的模型。

实际跑下来，加了三层过滤（情绪过滤、版本链、意图对齐）之后，retrieval的精确率从68%提升到了89%。如果你也在做类似系统，建议从一开始就把"召回不等于可用"这条记在心里。检索只是第一步，后面保证"召回来的内容能正确服务于当前生成"才是重头戏。

6. 最后的经验沉淀：二八法则、可观测性、落地建议

6.1 二八法则：80%的收益只需要20%的复杂度

很多朋友看完上面的内容，第一反应可能是"这也太重了，我还是继续用截断吧"。我的真实建议是：整条链路里最值得优先做的是结构化事实提取加精确匹配召回，它带来的收益占整个context-mode体系的七成以上。摘要库和向量检索是后续的增强选项，可以在系统已经跑通、观察到真实需求之后再逐渐补上。

具体到落地顺序，我建议从四步走起：

• 第一步：把上下文的token消耗可视化成日志，知道钱花在哪了、配置项在哪
• 第二步：写一个从消息中抽取结构化事实的模块，产品侧只需要最核心的实体
• 第三步：在关键对话节点把命中事实注入提示词，用最朴素的手段替换无脑塞历史
• 第四步：遇到模糊检索需求时再引入向量库，用独立索引隔离实验风险

这样既不陷入重架构的泥潭，也能快速看到效果。我身边有不少同行就是这样两周内完成改造的。

6.2 可观测性：没有日志就没有上下文管理

在所有技巧里，我最想强调的反而是最不性感的日志系统。第一次做上下文管理时，我花了大量时间调算法、调参数，但真正让我把问题定位清楚的是给系统加了详细的trace日志。

每条请求的日志至少要记录以下信息：

• 当前活跃区实际包含的消息ID和token数
• 召回了哪些历史片段，各自的得分来源
• 事实库匹配到了哪些记录
• 最终拼装进提示词的消息清单

有了这个日志，你才能在用户反馈"回答不对"时迅速判断是"没召回相关内容"还是"召回了但被模型无视了"还是"模型理解错了"。这三个问题对应的解决办法完全不同。没有日志的context-mode，本质上还是盲人摸象。把这个观测层加上去，系统就有了迭代优化的方向盘。

6.3 针对不同场景的选型建议

最后给一个务实的选型建议。你不用每个场景都上全套，以下是我在三种典型产品形态里的推荐组合：

• 高频短对话型，比如FAQ机器人：只需要活跃窗口加规则召回，连向量库都不用上，控制响应延迟是关键
• 长会话交易型，比如客服系统：结构化事实库必须做，版本链必须做，这是硬需求，摘要库可以后面补
• 复杂Agent型，比如多步骤规划Agent：事实库加向量库同时上，还要增加工具调用记录的归档和召回，否则Agent会在多步操作中迷失

根据你的场景定位选起点，别一上来就追求大而全。上下文管理最忌讳的就是为了用新技术而动用新技术。

做context-mode这段时间，我最大的体会是：窗口大小本身不是问题，问题是窗口里装的东西是不是用户当下真正需要的东西。把一个线性窗口改造成一个调度系统，看起来只是工程上的摆弄，实际上改变的是AI应用对信息的基本组织方式。就像从前端开发的"全量渲染"演进到"虚拟滚动"，底层逻辑完全不一样了，性能表现自然也就拉开了档次。如果你也在被长对话质量下滑折磨，不妨先从这一条开始，把你当前窗口里真正有用的信息挑出来，你会立刻感受到差别。