企业官网建设流程全解析

做过AI应用接入的朋友，大概率都遇到过这种尴尬：对话明明聊得挺顺，模型突然像失忆一样答非所问；请求体越堆越胖，最终撞上长度上限；你想让它记住用户说过的一个关键需求，它却在第五轮之后彻底忘干净。这些问题表面上是“模型不够聪明”，但根子往往在于上下文处理方式太粗糙。我后来专门整理了一套“context-mode”的设计思路，把上下文管理拆成有条理、可落地的模式，才算是把这类问题真正按住。这篇文章就围绕这个主题，把我实际调通、验证过的方法、代码和坑一起讲透，适合正在做AI助手、客服机器人、RAG检索应用，或者单纯想把提示词工程做得更扎实的开发者参考。

1. context-mode到底是什么，为什么值得单独设计

1.1 从一次翻车经历说起：上下文失控的典型症状

我先说一次真实翻车。有段时间我在做一个电商客服助手，最初的实现方式特别简单：把用户每一轮消息原封不动拼进提示词，然后发给模型。前几轮效果不错，用户问“有没有支持快充的充电宝”，模型能答上来；但聊到第八轮、第十轮，用户说“那刚才那个白色的呢”，模型直接懵了，因为它看到的上下文里有三四个充电宝型号，根本不知道“白色的”指的是哪一个。

再往后更夸张：用户提了一个售后需求，客服机器人先承诺“可以退货”，后来又改口“需要审核”，因为前面的承诺被后面的历史消息挤出了可见范围。用户当场炸毛，这个会话的满意度直接一落千丈。

这类问题的共同特征，是上下文本身失控了——不是模型能力不够，而是它“看到的内容”没有经过任何设计。原始对话记录堆在一起，就像把一整箱档案倒在地上，重要信息淹没在噪声里。后来我意识到，上下文不应该是一堆字符串的堆叠，而应该是一个“有模式、有衰减、有优先级”的结构化状态，这就是我所说的context-mode。

1.2 三种最实用的上下文模式

context-mode不是一个具体的API接口，而是一类处理策略的总称。根据任务特性，我通常会把它拆成三种最实用的形态，对应不同场景。

第一种是固定窗口模式，也就是只取最近N轮对话作为上下文。它实现最简单、成本最低，适合大部分轻量客服、闲聊、简单问答场景。缺点是老信息会突然消失，如果用户中途提过重要条件，窗口滚动之后就再也找不回来。

第二种是摘要压缩模式，也叫滚动摘要。每次对话达到一定规模时，让模型把当前内容压缩成一段摘要，后续只保留摘要和最近几轮原始消息。适合需要长期记忆、但预算有限的长会话，比如“用户连续七天咨询项目方案”的场景。

第三种是检索增强模式，也就是把关键信息抽出来做向量化，后续根据用户新问题动态召回。它可以理解为给上下文外挂了一个记忆库，适合知识库问答、RAG类应用，或者在会话中穿插大量事实性内容的场景。

这三种模式并不是互斥的。我实际项目里，最常见的组合是“窗口模式+检索模式”并行：最近对话用滚动窗口，关键中间结果用向量召回。context-mode本身就是围绕这种组合策略形成的设计框架，帮你用有限的token预算，做最大化的有效记忆。

1.3 哪些人真正需要关注这个设计

我自己总结了三类最需要关注context-mode的人。

第一类是做AI客服或对话助手的。这类产品天然依赖连续多轮交互，用户会不断追加条件、修改偏好、补充背景，如果上下文管理不到位，产品体验就是一场灾难。

第二类是做RAG问答应用的。这类应用虽然大量调用检索，但往往忽略“聊天过程中的上下文继承”。用户问了A问题，检索了知识库，下一轮问“那它和B比怎么样”，这里的“它”如果没有上下文支撑，检索就等于盲人摸象。

第三类是做大模型应用框架和中间件的开发者。你会发现自己最终不是在“调模型”，而是在“设计状态管理”。把context-mode做成一等公民，后面加功能、换模型、调参都会轻松很多。

说白了，只要你的应用需要“记住点什么”，就值得专门为上下文设计一套模式，而不是随手拼接字符串。

2. 设计context-mode前必须先想清楚的三个问题

2.1 你的上下文是“会话感”还是“事实感”

这是我在设计任何上下文模式之前，第一件要明确的事。如果搞反了，后面几乎一定会出问题。

什么是“会话感”？它指的是那些为了维持对话自然度而产生的信息，比如“用户刚刚问过什么”“助手刚才回答了什么”“对方情绪怎么样”。这种信息的特点是时效性强，一旦对话推进，旧内容的价值就快速衰减。它更适合用窗口模式，保证最近几轮的信息完整，老的直接丢弃。

什么是“事实感”？它指的是那些跨轮次仍然有价值的稳定信息，比如“用户的公司规模”“他坚持的预算上限”“他提过的技术栈”。这些信息不会因为聊到第五十轮就失效，反而可能成为整个会话里最核心的锚点。如果也按窗口滚动切掉，就会造成前面说的“失忆”问题。

我建议在项目初期就做一个简单分类：在消息流进入上下文管理器时，先判断这条消息里有没有“未来还会用到的事实短语”。有，就送入事实层；没有，就留在会话层。实际代码里，可以用一个很轻的规则来做初筛，也可以把判断逻辑交给小模型自动抽取。总之，别把两种信息混在一个容器里无差别处理。

2.2 token预算决定模式上限

第二个问题更现实：你的模型上下文窗口是多少，单次请求允许花多少token。很多团队上来就想要“无限记忆”，可真算一笔账就清醒了。

假设你的模型窗口是128K token，看起来很大了吧？但如果用户每天聊两千轮，每轮平均800 token，光原始对话就是1.6M token，无论如何都塞不下。所以token预算不是可选项，是硬约束。它直接决定了你的模式能激进到什么程度：预算小的，只能做最近几轮过滤；预算大的，才可以安全地承载滚动摘要和多次召回。

我通常会用一个公式来约束设计：单次请求最大token = 系统提示词 + 用户新输入 + 上下文包 + 模型输出预留。上下文包必须留出至少50%的余量，否则一旦输入稍长，接口直接报错，整个会话就断层了。

基于这个约束，我还会提前定一个阈值。比如上下文包预算只有2000 token时，窗口模式最多放最近6轮；如果最近6轮本身就超了，就触发摘要压缩，把更早的内容揉成一段150字的概述。整个过程像给行李箱打包，放不下的东西要么叠起来，要么留在酒店，不能硬塞。

2.3 状态存哪里：内存、文件还是向量库

最后一个设计前置问题是状态存储。context-mode本质上要维护一份“会话状态”，这份状态放在哪里，决定了整个系统的扩展性和稳定性。

最简单的阶段是放内存。单进程、单实例、流量不高的场景，一个内存字典足够。好处是零依赖、响应快，坏处是一重启全丢，多实例部署时每个实例各记各的，用户请求一旦被负载均衡分发到不同机器，上下文立刻错乱。

稍微正规一点的做法是放Redis之类的外部存储。以会话ID为key，以JSON或消息序列化为value，读写都很快，多实例共享，重启也不丢。代价是你要处理并发写、过期时间、数据一致性。我推荐项目只要超过一台服务器部署，就直接上Redis，不要在内存方案里挣扎太久。

至于向量库，它更适合用来存放“事实层”内容，而不是当主存储。我通常把原始对话存Redis作为备份，把抽出来的关键事实做向量化后放向量库，后续按语义召回。这样既保留了完整会话记录，又不用每次做全量载入。

3. 手把手实现一个最小可用的context-mode

3.1 先定义消息数据结构

不管选哪种模式，底层的数据结构最好先统一。我个人的习惯是：每一条消息最少包含四个字段——role（是用户还是助手）、content（正文内容）、timestamp（时间戳）、meta（元信息，如来源、标题、重要性标记）。

from dataclasses import dataclass, field from typing import Optional import time @dataclass class Message: role: str # "user" / "assistant" / "system" content: str timestamp: float = field(default_factory=time.time) meta: dict = field(default_factory=dict) def token_estimate(self) -> int: # 粗略估算：中英文混合按字符数除以2保守估计，实际应接入tokenizer return max(1, len(self.content) // 2)

这里有一个容易忽视的点：token估算不要拍脑袋。很多项目图省事，用“字符数除以4”来估算，结果接口返回超限时一脸懵。不同模型的tokenizer差异很大，英文和中文、代码和自然语言的字符占比也不同。最靠谱的方式是直接调用模型的tokenizer接口；如果没有，宁可把估算系数调保守一点，比如中文按len(content)作为估算结果，并且预留更多余量。

你还会发现，加上timestamp后，很多功能做起来顺手很多。比如“最近30分钟内的内容优先保留”“超过2小时的寒暄消息直接压缩”，这些时间相关的策略都建立在可靠的时间戳上。

3.2 窗口模式实现：滑动窗口与优先级裁剪

窗口模式是理解context-mode的入门钥匙。核心逻辑不复杂：维护一个消息列表，新消息不断追加，总量超过限制时，从最旧的开始裁剪。

class WindowContextMode: def __init__(self, max_messages: int = 20, max_tokens: int = 4000): self.max_messages = max_messages self.max_tokens = max_tokens self.messages: list[Message] = [] def add_message(self, msg: Message) -> None: self.messages.append(msg) self._trim() def _trim(self) -> None: # 第一优先级：按条数裁剪 while len(self.messages) > self.max_messages: self.messages.pop(0) # 第二优先级：按token总量裁剪 total = sum(m.token_estimate() for m in self.messages) while total > self.max_tokens and len(self.messages) > 1: # 不裁掉最后一条用户消息，保留最新语义 self.messages.pop(1) # 从第二条开始删，保留第0条系统提示 total = sum(m.token_estimate() for m in self.messages) def build_prompt(self, user_input: str) -> list[dict]: self.add_message(Message(role="user", content=user_input)) return [{"role": m.role, "content": m.content} for m in self.messages]

这个实现里有个小技巧：当我需要裁剪token时，我不会从第0条开始删，而是从第1条开始。第0条通常放的是系统提示词，它定义了模型的人设和行为规则，是整个上下文里最不该丢掉的部分。如果你把它裁了，模型可能连“你是客服助手”这件事都会忘记，回答质量立刻滑坡。

还有一点要注意：窗口模式下，max_messages和max_tokens要同时设置，不能只设一个。只设条数，可能某条消息特别长，把预算全部占满；只设token数，又可能出现消息条数太少，模型看不到足够的前后文。双阈值互相兜底，是更稳的做法。

3.3 摘要压缩模式实现：分层压缩与回读

窗口模式的局限很明显：旧消息被硬性丢弃，一旦用户后续问题需要老信息，就再也拿不回来。摘要模式就是为了缓解这个问题。

它的思路是：当窗口快要溢出时，先不要直接丢弃旧消息，而是把这些旧消息交给模型压缩成一段摘要，然后用摘要替换掉原始消息。

class SummarizeContextMode: def __init__(self, llm_call, max_window: int = 10, summary_threshold: int = 6): self.llm_call = llm_call # 函数签名: llm_call(messages) -> str self.max_window = max_window self.summary_threshold = summary_threshold self.long_term_summary: str = "" self.recent_messages: list[Message] = [] def add_message(self, msg: Message) -> None: self.recent_messages.append(msg) if len(self.recent_messages) >= self.max_window: self._summarize_old() def _summarize_old(self) -> None: # 保留最近summary_threshold轮作为原始消息，把更早的全部压缩 old = self.recent_messages[:-self.summary_threshold] recent = self.recent_messages[-self.summary_threshold:] combined = self.long_term_summary + "\n".join( f"{m.role}: {m.content}" for m in old ) summary_prompt = [ {"role": "system", "content": "你是会话摘要助手。请把下面的对话内容压缩成200字以内的要点摘要，保留用户偏好、关键决定、未完成事项、已提供的具体承诺。"}, {"role": "user", "content": combined} ] self.long_term_summary = self.llm_call(summary_prompt).strip() self.recent_messages = recent def build_prompt(self, user_input: str) -> list[dict]: self.add_message(Message(role="user", content=user_input)) prompt = [{"role": "system", "content": f"历史摘要：{self.long_term_summary}"}] prompt.extend({"role": m.role, "content": m.content} for m in self.recent_messages) return prompt

这段代码里最值得讲的是那个summary_prompt。我明确告诉模型“保留用户偏好、关键决定、未完成事项、已提供的具体承诺”，因为普通摘要模型默认会倾向于保留聊天的“情节”，但这些情节对后续任务往往毫无价值。你要让它抽的是“决策事实”，不是“对话流水账”。

我建议摘要触发要设置一个提前量。这里我设的是len(recent_messages) >= max_window时才触发，也就是快满了才压缩。但实际上更好的体验是塞一个水位线，比如总消息数到max_window * 0.8就开始预压缩。这样能避免用户某次连发几条长消息后，突然触发压缩、产生明显延迟。

3.4 检索增强模式实现：对外挂知识的按需召回

检索增强模式解决的是另一个问题：信息不一定在当前会话里，可能在历史会话、知识库、或者一堆辅助文档中。你需要把“所有上下文”变成“用户当前最需要的上下文”。

最简单的落地方式，是把抽出来的关键事实向量化，存到向量库，每次用户发新消息时，先用这条消息去检索最相关的历史片段，再把这些片段注入提示词。

class RetrievalContextMode: def __init__(self, embed_fn, vector_store, top_k: int = 3): self.embed_fn = embed_fn # 函数签名: embed_fn(text) -> vector self.vector_store = vector_store self.top_k = top_k def add_fact(self, fact_text: str, metadata: dict = None) -> None: vec = self.embed_fn(fact_text) self.vector_store.add(vec, payload={"text": fact_text, "metadata": metadata or {}}) def retrieve(self, query: str) -> list[str]: q_vec = self.embed_fn(query) hits = self.vector_store.search(q_vec, top_k=self.top_k) return [h.payload["text"] for h in hits] def build_prompt(self, user_input: str, conversation: list[Message]) -> list[dict]: related = self.retrieve(user_input) context_block = "\n".join(f"- {r}" for r in related) prompt = [{"role": "system", "content": f"以下是检索出的相关背景信息：\n{context_block}"}] prompt.extend({"role": m.role, "content": m.content} for m in conversation[-6:]) prompt.append({"role": "user", "content": user_input}) return prompt

我在实际项目里不会把原始对话全部塞进向量库，那样噪声太多，召回结果一塌糊涂。我会在收到消息后先过一个抽取步骤，只把“用户明确表达的偏好”“助手给出的确定性结论”“用户透露的限制条件”这三类事实抽出来，再写入向量库。这个抽取步骤可以由大模型完成，也可以用基于关键词的规则模板，视成本而定。

检索数量的选择也别拍脑袋。top_k=3是我常见起步值，但如果你检索到的信息本身每个都很长，3段就把上下文撑满了；如果信息零散，3段又可能不够用。我会额外做一个重排：检索出前10个候选，再用一个轻量打分模型或规则，根据与当前查询的重叠度筛出最合适的3个。这个步骤的成本比多召回来得划算。

4. 踩坑实录与调优速查

4.1 七个我实际遇到的坑

第一个坑是系统提示词被滚动窗口误删。我早期直接在裁剪逻辑里pop(0)，结果系统提示词被删掉，模型的角色设定全乱，回答语气和格式完全偏离。后来我把系统提示词单独隔离，永远不参与滚动裁剪，这个坑才算填上。

第二个坑是时间戳参与排序导致乱序。多轮并发写入时，消息的到达顺序并不等于实际时间顺序。如果错误地按时间戳排序去裁剪，可能留下旧消息、裁掉新消息。我的对策是写入时用单调递增的序列号作为主排序字段，时间戳只作为辅助决策信息。

第三个坑是摘要压缩导致关键数字失真。模型压缩摘要时，很可能会把“预算不超过3万元”压成“预算有限”，把“库存剩12件”省略掉。这恰恰是最不能丢的信息。我的处理方式是，在压缩提示词里强制要求“所有数字必须原样保留，不得省略或改写”，并在压缩完成后做一个数字一致性检查，如果发现原文中出现了摘要中没有的数值，触发二次修正。

第四个坑是向量召回内容同质化。当你连续检索多次时，召回的往往是同一段话的不同变体，占满了上下文却提供不了增量。解决方式是做去重，计算新增片段与已有上下文的余弦相似度，超过0.85就跳过。

第五个坑是token估算误差导致接口报错。我一度用字符数除以4估算，结果中文文本的实际token数量远超预期，频繁触发超限。后来直接调用tokenizer，估算误差从30%以上降到5%以内。如果你的项目还没有接tokenizer，建议尽早接上。

第六个坑是多实例部署状态不同步。单机版跑得好好的，一上多实例就疯狂出现“我是谁、刚才聊了啥”的问题。根因就是内存字典不共享。后来我把会话状态统一放到Redis，虽然多了一次网络往返，但一致性收益远大于性能损失。

第七个坑是摘要触发的卡顿感。第一次压缩需要等待模型输出摘要，用户体验上会有一个明显的停顿。我的优化办法是异步预压缩：在对话空闲时提前把旧消息压缩好，请求进来时直接读缓存，把延迟从几百毫秒降到几十毫秒。

4.2 参数速查：窗口大小、召回数量与摘要阈值

我把上面三种模式的关键参数整理成一张速查表，方便你直接抄作业。

这些参数没有一个能一劳永逸。我的习惯是每次调整只改一个变量，观察至少50条真实对话的效果，再动下一个。同时把每次调整前后的案例存下来，做成一个回归测试集，防止“修好A问题、弄坏B问题”的情况。

4.3 什么时候别用context-mode

说了这么多，我也泼一盆冷水：并不是所有场景都需要复杂的context-mode。

如果你的应用只是单轮问答，比如“翻译一句话”“生成一个标题”，用户不期待任何连续记忆，那窗口模式都不用做，直接把当前输入发给模型就行。加再多的上下文管理，都是多余的成本和延迟。

如果你的模型本身支持非常长的上下文，而且单轮输入很短，那也可以暂时不做滚动摘要，直接用“长窗口+全量保留”撑住。我见过不少项目，128K窗口下全量放几十轮对话毫无压力，这时候引入摘要反而压缩失真。

最需要context-mode的场景，是上下文长度超出模型窗口、或者历史信息重要但稀疏这两类矛盾的交叉点。只有在哪个时候，你才会真正体会到“模式设计”带来的差距。

我个人在这些项目里最大的体会是：context-mode与其说是一段代码，不如说是一种思维方式——它逼你分清哪些信息值得留、哪些可以丢、怎么在token预算内最大化保留关键决策事实。如果你正准备做一个需要记住用户上下文的产品，别急着堆对话记录，先花半小时把模式选型定下来，后面会省掉无数返工。最后再分享一个小技巧：给每种模式增加一行调试日志，把每次裁剪、压缩、召回的决策过程和token统计打出来，你在调优时会发现，它比任何研报都更能帮你发现问题。