企业官网建设流程全解析

1. context-mode 要解决的问题：大模型对话的“失忆”困境

去年下半年我开始集中做一些长会话场景的 AI 应用开发，做的是一个能连续跟踪项目进度的对话式助手。最初版本逻辑很简单：把所有聊天记录一股脑丢给模型，让它自己找重点。跑通Demo的时候挺高兴，可一进入真实数据测试就露馅了。

用户连续问十几个问题之后，模型开始“顾头不顾尾”——前面确认过的技术选型、约束条件，后面全忘了，甚至出现自相矛盾的输出。更要命的是，每轮请求携带的 token 数跟着对话长度线性上涨，账单数字跳得让人肉疼。我这才意识到，长对话里的上下文处理不是一个“加长窗口就能解决”的问题，而是一整套需要专门设计的管理机制。

我最后做的这套方案，就是把这套机制打包成了一个独立模块，项目代号直接叫 context-mode。它的核心不是让模型“记住更多”，而是帮模型“记住更准”——在有限的上下文窗口里，用最经济的方式保留最关键的信息。

1.1 上下文窗口不是无限续杯

先泼一盆冷水：本地模型也好，云端接口也好，上下文窗口都有硬上限。就算把窗口做到 200K token，你也不能真的每轮都往里塞满东西。有两个原因：

第一是成本。主流模型的计费单位是 token，输入和输出分开计价。长会话场景下，每次调用都要把全部历史带上，调用次数一多，输入 token 的累计消耗非常夸张。我实测过一个简单的 30 轮对话测试任务，无脑携带全部历史的情况下，输入 token 消耗是一个精心管理方案的 7 到 12 倍。

第二是注意力衰减。这是很多第一次做长会话应用的人容易忽略的点。Transformer 的注意力机制虽然能建模长距离依赖，但在超长上下文中，模型对关键信息的敏感度会下降。有研究表明，信息位于长序列中段时，被模型“有效利用”的概率明显低于位于开头或结尾的信息。这个现象业界给它起了个形象的说法叫“lost in the middle”。

这两个问题叠加起来，逼着你必须对上下文做主动管理。context-mode 这一个模式要干的事情，本质上就是：建一个中间层，把“原始对话历史”和“送进模型的上下文窗口”分开。

1.2 上下文失控的三种典型症状

我在调试早期版本时总结过，无管理的长对话通常会出现三类问题，你可以拿来对照自己的应用：

• 复述型失忆：用户前期明确说过“数据库用 PostgreSQL”，第 20 轮询问方案细节时，模型开始在 MySQL 和 MongoDB 之间反复横跳。这是因为早期信息已被淹没在大量中间对话里。
• 冲突型混乱：模型在后半段给出的回答，和自己在第 8 轮给出的结论直接冲突，而用户并不容易察觉这种矛盾，直到人工审计才发现。
• 拖沓型冗长：上下文里塞了太多早期的寒暄、纠错、冗余表达。模型生成的内容也被带偏，开始出现大量重复陈述和无效修饰，回复质量明显下降。

如果你现在的长会话应用也出现了上面任意一条，说明你需要的不是换一个更大的模型，而是考虑引入类似 context-mode 的上下文管理机制。

2. 上下文分层：把对话记忆拆成三级

在设计 context-mode 之前，我参照的其实是操作系统里的存储层级思想：寄存器、内存、磁盘，各自承担不同角色。上下文管理也一样，不能所有信息都放在一个篮子里，要分层。

我最终把对话记忆拆成了三层：短期记忆、工作记忆、长期记忆。这三层对应着不同的信息生命周期和访问频率，处理方式也完全不同。

2.1 短期记忆：当前会话的原始输入

短期记忆指的是当前这一轮、以及最近几轮的用户输入和模型输出。它的特点是完整、未经压缩、时效性最高。这一层直接放进上下文的头部即可，不需要做任何加工。

但有一点必须明确：短期记忆不是“最近 N 轮的全部消息”。我在第一版里贪省事，直接缓存了最近 10 轮完整内容，结果上下文还是膨胀得很快。原因很简单，对话轮次的“信息密度”差异极大，有的轮是一次性说清需求，有的轮是来回纠偏，真正对后续决策有影响的可能只有其中的两三句。

所以我在 context-mode 里做了一个简单的筛选：只保留最近 2 到 3 轮完整内容，更早的内容是否保留，取决于后续分层处理后的重要程度。这条规则的核心是宁可让短期记忆短一点，也要给工作记忆腾出空间。

2.2 工作记忆：提取结构化信息注入

工作记忆是 context-mode 最关键的创新点。它的思路是：从历史对话中抽取“对后续决策依然有约束力的信息”，转成结构化的形式，放到上下文最靠前的位置。

举个例子。假设一段对话里散落着这些信息：

• “我们团队总共 6 个人”
• “后端用 Go，前端用 React”
• “目标用户是海外中小商家”
• “上线时间定在 8 月底”
• “不做会员体系，先验证核心流程”

这些信息散落在十几轮对话里，人类读者能拼出全貌，但模型很难在长上下文中同时想起所有这些。context-mode 的做法是：每轮对话结束后，用一个轻量模型或正则规则，把这些“事实类信息”抽取出来，写入一个结构化的摘要区块。这个区块会被固定注入到系统提示词后面。

我实际用的是类似这样的 Json 结构：

{ "project_constraints": [ "团队规模：6人", "技术栈：Go + React", "目标用户：海外中小商家", "上线时间：8月底", "不做会员体系" ], "current_status": "核心流程开发中，登录模块已完成", "decisions": [ "数据库采用PostgreSQL，由后端统一管理" ] }

每次请求时，把这份结构化摘要放在上下文的最前面，模型一眼就能看到。这比让它从茫茫对话里自己回忆要可靠得多。我实测过，加了这层结构化注入之后，长对话后期的“约束遗忘”问题基本绝迹了。

2.3 长期记忆：外部存储与检索

长期记忆处理的是“超过当前上下文窗口承载能力”的那部分历史。它的特点是访问频率低、总量大、不能全部保留在上下文里。我的做法是引入向量数据库，把历史对话切片后做 embedding 存储，需要时用检索召回。

这里要强调一个和很多人的直觉相反的点：长期记忆不是聊天记录的备份，而是“可检索的知识库”。它的切片粒度、索引方式，都决定了检索质量。我第一版图省事，按每 50 个字符切一块，效果很差——语义完整的陈述被拦腰截断，召回结果经常是半句话。后来改成按“语义段落”切分，每条切片至少包含一个完整意思，召回准确率明显提升。

关于这一块的具体检索策略，我在下一节的实现部分会展开。

3. 从零实现一个可用的 context-mode 管理器

有了分层思路，接下来就是落地的过程。我整个 context-mode 模块分了四层：接入层负责对接模型调用，管理层负责三种记忆的读写，压缩层负责把原始历史转成结构化信息，检索层负责长期记忆的召回。下面讲一下从第一版到第二版的主要实现路径，以及我在这个过程中踩过的关键坑。

3.1 整体架构与模块划分

先给你看一下我的模块划分方法。我没有一上来就写一个大而全的 class，而是按单一职责拆成了两个主要部分：MemoryManager（记忆管理者）和 ContextBuilder（上下文构建器）。

MemoryManager 的职责是维护三份数据：短期缓存、结构化摘要、长期向量库。ContextBuilder 的职责是每次请求前，按照固定顺序拼装出最终送给模型的上下文。这个顺序通常是：

1. 系统提示词与角色设定
2. 结构化摘要（工作记忆）
3. 向量检索召回的长期记忆
4. 最近 2 到 3 轮的原始对话

为什么是这个顺序？因为模型对开头内容的注意力最强，把最重要的约束性信息放在头部，能最大限度地保证它被利用到。实测中，这个顺序比“按时间顺序平铺所有内容”的回答准确率高出不少。

3.2 第一版：基于规则的上下文压缩

第一版的压缩机制没有用大模型，纯靠规则和正则来抽取结构化信息。因为我的场景相对固定，规则抽取的性价比很高。大模型抽取看着更聪明，但每一轮都要额外调用一次接口，既慢又花钱，而且抽取结果还有随机性。

规则抽取的核心是维护一个“关注点列表”。例如我的项目里关注点包括：技术选型、时间节点、人员分工、风险约束。每条规则对应一组关键词模式，命中后提取前后文，写入结构化摘要。实现起来不复杂，示例逻辑如下：

import re CONSTRAINT_KEYWORDS = { "technology": ["用", "技术栈", "采用", "框架"], "deadline": ["上线", "完成", "截止", "时间"], "team": ["人", "团队", "分工"], } def extract_constraints(text: str) -> list: results = [] for category, keywords in CONSTRAINT_KEYWORDS.items(): for keyword in keywords: pattern = re.compile(rf".{{0,20}}{keyword}.{{0,40}}") matches = pattern.findall(text) for m in matches: results.append({"category": category, "content": m.strip()}) return results

当然，这个正则方式很粗糙，它解决的问题是“把散落的约束捞出来”，不负责理解语义。实际使用时，我还加了一个去重逻辑：如果新抽取的内容和摘要里已有的约束在关键词上高度重叠，就跳过，避免摘要区块无限膨胀。摘要区块被限制在 600 token 左右，超过之后按添加时间淘汰最旧条目。

3.3 第二版：引入向量检索的自动召回

第一版跑通之后，我面临一个新的问题：规则抽取只能处理预设好的关注点，但真实对话里总有一些东西是我没想到的。比如用户突然聊了一个新的技术名词，不在我的关键词列表里，它就丢了。

第二版引入了向量检索来接住这部分漏网之鱼。做法是：把每一轮对话按语义段落切分后做 embedding，存储在向量数据库里。每次构建上下文之前，先用“当前用户问题 + 结构化摘要”作为检索 query，召回最相关的 3 到 5 段历史片段，拼到上下文中。

这里有一个我觉得很值得讲的细节：检索的 query 不应该只用当前问题，而应该把上一轮的模型响应也拼进去。因为用户往往会说“那这个呢”“再详细说说”，单独用这种短句去检索，召回结果大概率是错的。把上一轮响应拼进去之后，检索质量显著提升。

我用的是 ChromaDB，轻量，适合单机开发。核心代码如下：

import chromadb client = chromadb.PersistentClient(path="./context_db") collection = client.get_or_create_collection("history_memory") def save_segment(segment: str, metadata: dict): embedding = embed_text(segment) collection.add( ids=[metadata["id"]], embeddings=[embedding], documents=[segment], metadatas=[metadata] ) def recall_context(query: str, top_k: int = 5): query_embedding = embed_text(query) results = collection.query( query_embeddings=[query_embedding], n_results=top_k ) return results["documents"][0]

embed_text 我用的是 text-embedding-3-small，如果你在本地部署优先考虑离线模型的话，bge-small-zh 或者 m3e-base 也能达到差不多的效果。向量维度不用太高，对召回准确性起决定作用的更多是切分质量和 query 构造方式。

4. 上下文切换与压缩策略：模式状态下最容易翻车的地方

context-mode 在单会话场景里表现稳定，真正让我栽跟头的是多会话管理和压缩策略的边界情况。这一节把我在真实环境中遇到的三个问题和排查过程完整记录下来，希望能帮你少走弯路。

4.1 压缩时机怎么定

第一个问题是：什么时候触发压缩和摘要重建？最开始我想得简单——每满 5 轮就做一次。结果发现很别扭。有的对话 5 轮就信息爆炸，有的对话 15 轮也没新增实质信息，固定频率并不合理。

我最后采用的策略是双阈值触发：一个 token 阈值，一个信息量阈值。token 阈值是硬性的，当短期缓存里的原始对话累计超过 4000 token 时，强制触发压缩。信息量阈值是软性的，用上一个版本的关键词匹配统计，如果最近 3 轮内有超过 5 个新关注点命中，即使没到 token 阈值也会提前压缩。

这个设计的教训是：压缩不是定时任务，而是状态机里的一个主动转移条件。你需要在“上下文还不算太重”的时候就动手，不要等它溢出。

4.2 压缩丢信息：那个让我排查了一下午的 Bug

第二版上线后，有个测试会话出现了诡异现象：用户在第 6 轮提到了“客户要求所有接口返回都要加 traceId”，第 12 轮询问接口方案时，模型完全没提这个要求。我第一反应是检索没召回，于是翻日志，发现摘要里确实有这条记录，但位置在结构化摘要的尾部，而那一轮上下文总长度超过了模型窗口，ContextBuilder 做了截断，正好把尾部信息丢掉了。

问题就出在截断策略上：我当时用的是简单的“从后往前保留”法则，也就是优先保留最近对话，优先截断历史信息。这在大多数情况下没错，但结构化摘要的每条信息权重不都一样——有些约束可能这轮用不上，下轮就是关键。一刀切“保留新的”，等于把最该保护的约束信息牺牲掉了。

我从这个 bug 里总结的修复方案是：截断时引入权重标记。结构化摘要里的条目被使用时，动态提升一次权重；每次截断时，丢弃权重最低、且未被近期引用的条目。简单说，就是把“冷门但重要的信息”尽量留下，把“热门但已不相关的信息”优先淘汰。

4.3 多会话切换时的隔离问题

第三个坑是会话隔离。我的 context-mode 最开始被设计成全局单例，所有会话共用同一个 MemoryManager。多测试几个会话之后，出现了串记忆的严重问题——A 会话里用户讨论的技术选型，跑到 B 会话里影响模型输出了。

这个坑的教训非常直白：上下文管理的所有状态都必须按 session_id 隔离。向量数据库的 collection 要按会话区分，结构化摘要的缓存也要按会话区分。我当时因为急着验证效果，跳过了这个设计，结果多会话并行测试了半小时就发现问题。后来我重构成了 session-scoped 模式，每个 session_id 对应独立的 collection 前缀和独立的缓存 key，才彻底解决。

5. 实测对比与性能数据

理论讲再多，不如数据说话。我在一个 45 轮的长对话测试集上做了对比实验，测试内容包括：技术选型一致性、约束条件服从度、历史事实准确性、响应时应答质量。

5.1 测试场景设计

测试集模拟的是一个真实的软件项目咨询场景：用户逐步提出需求、调整方案、确认技术栈，中间插入了大量闲聊和重复性表达。测试分为三组：

• 组 A：无任何上下文管理，每次请求携带全部历史原文。
• 组 B：只用第一版规则压缩，不做向量召回。
• 组 C：完整 context-mode（规则压缩 + 向量召回 + 权重截断）。

每组跑 45 轮，每轮记录输出内容，最后人工评审四个维度：约束遵守率、事实冲突率、回答完整度、单次请求平均输入 token 数。

5.2 效果对比：成本下降与质量提升是同时发生的

我把结果整理成一张表，你可以直观看到差异。

组 C 比组 B 的 token 消耗略高，因为它多了向量召回内容的注入，但换来的是显著更高的约束遵守率和更低的冲突率。和组 A 比，组 C 的输入 token 成本降到原来的四分之一左右，回答质量反而明显提升。

我看完数据之后又一个更深层的感受：上下文管理节省的成本并不仅仅是 token 费用，更重要的是它把模型的能力集中到了“该用的地方”。同样的模型，在信息噪音更小的上下文中，输出质量会有一个肉眼可见的提升。这是我在做这个项目之前没有预料到的。

6. 扩展思路：context-mode 不止适用于对话助手

做到这一步，context-mode 已经解决了我最初的长对话失控问题。但它能用的场景远不止对话助手。我在做代码辅助工具的时候，把同一套分层思路迁移了过去，效果同样明显。

代码补全和问答场景里，上下文的关键不是聊天记录，而是当前文件内容、相关文件引用、项目结构、用户最近修改过的代码块。我把这些信息按照同样的三层模型组织：当前光标附近的代码是短期记忆，项目关键文件的结构化摘要（比如入口文件、配置项、对外接口）是工作记忆，git 历史文件和散落的旧代码片段放进向量库作为长期记忆。

效果很惊喜，尤其是在让模型理解多文件项目的模块依赖关系时，结构化摘要的作用比我想象的还大。如果你在做的项目涉及到代码助手、文档问答、智能客服、任何需要连续多轮交互的 AI 应用，都可以参考这套 context-mode 的分层思路。

最后说一个我听很多同行聊过的观点：大模型应用的性能瓶颈，正在从“模型能力”转移到“上下文工程能力”。同样的模型，给到不同的上下文组织方式，输出水平能差出档次。context-mode 这种模式化管理工具的意义，就是让上下文从一团杂乱的历史记录，变成一份有结构、有权重、可检索的“工作记忆”。

我做下来最实际的体会是：别让每一个新功能都从零搭建上下文管理，把它沉淀成一个可复用的模式模块，长期收益远超预期。如果你正准备做一个长会话应用，建议从第一天就把上下文管理纳入架构设计。它不像加一个模型调用那样显眼，但到了第 30 轮、第 50 轮对话的时候，你就知道这个决定有多值了。