企业官网建设流程全解析

我上周差点把一台已经平稳运行两周的AI客服服务回滚掉。现象很典型：用户问“帮我查一下上个月的订单”，模型却回答“好的，根据您刚才提到的生日派对，我建议选择草莓蛋糕”。从接口日志看，模型确实读到了用户之前聊生日派对的记录，但它把这些旧上下文当成了当前任务的主要依据。排查到最后，问题根本不在模型能力，而在我没有设计好context-mode——也就是“模型在当前这一刻该看什么、以什么方式看”的上下文管理模式。这个案例让我把之前散落在各个项目里的上下文处理经验重新串了起来，所以这篇文章专门聊聊context-mode的设计、实现、选型和踩坑。

如果你正在做大模型应用、Agent编排、AI客服/知识库助手，或者只是想让自己的ChatGPT类套壳项目在长对话里不犯傻，这篇文章都值得看完。我会从最底层的问题讲起，逐步给出一套可以直接落地的上下文管线设计，以及我在实际项目中验证过的模式切换逻辑和调参方法。

1. context-mode到底在解决什么问题

1.1 不是“窗口越大越好”，而是让模型看到该看的

很多刚开始接触大模型应用的人，对上下文的朴素理解是：只要把能塞的信息都塞进上下文，模型就一定回答得更准。这个直觉在聊十句话以内基本成立，但一旦对话拉长、任务变多、信息来源变杂，问题就来了。你塞进去的不只是“有用的背景”，还有“干扰性的噪音”和“已经过期的决策依据”。

我见过最典型的一次翻车，是给一个Agent同时接入了用户画像、订单记录、商品库和聊天历史。结果模型在回答“现在有什么促销”的时候，把用户三天前的投诉情绪当成了当前状态，回复一上来就道歉，把用户搞得很懵。原因就是：模型确实理解能力强，但它没法自动判断“哪些上下文属于当前意图”。

context-mode的核心价值，恰恰是把“模型该看什么”从隐式猜测变成显式策略。它不是简单地把窗口调大调小，而是一套关于上下文范围、粒度、时效和排序的规则。你给它一个模式，它就按照这个模式去组织信息，让模型看到的是一份经过整理的任务简报，而不是一个乱七八糟的资料堆。这跟做饭备菜一个道理：把需要的食材提前切好分类，炒菜时才不会手忙脚乱；把整个冰箱搬到灶台上，反而找不到葱在哪儿。

1.2 每个上下文都有生命周期，需要模式来管理

我习惯把一次完整对话中的上下文理解成四个阶段：采集、组织、传递、回收。采集阶段决定哪些原始信息进入系统（比如用户消息、数据库查询结果、工具返回值）；组织阶段决定这些信息如何排序、截断、摘要或检索；传递阶段决定最终拼装成什么样的消息结构发给模型；回收阶段则决定任务结束后哪些信息要归档、哪些要清空。

这四个阶段里，最容易被忽略的是“回收”。很多上下文问题其实不是采集少了，而是旧的上下文没有及时退出活跃区，一直占用模型的注意力。举一个我实测过的例子：一个代码审查Agent，第一次任务要求“审查登录模块”，第二次任务变成“分析支付流程”。如果上下文模式没有在任务切换时清除上一轮的代码片段，模型极有可能在分析支付流程时继续引用登录模块的变量名，产出一份驴唇不对马嘴的报告。

所以，context-mode在工程上其实是围绕上下文生命周期做的一系列开关和策略组合。它要回答的问题包括：这个任务该用哪些信息源？历史消息保留多少条？超长内容要不要压缩？压缩后的摘要什么时候过期？任务切换后哪些状态必须重置？这些问题没有统一答案，只能靠模式来适配不同场景。

1.3 context-mode不是单一开关，而是三个维度的组合

我最开始设计context-mode时犯过一个错：以为它就是一个布尔开关，开就是全量上下文，关就是空上下文。后来在真实项目里跑了一轮才发现，真正好用的模式设计必须在三个维度上同时做决策。

第一个维度是广度，也就是上下文的覆盖范围。单体对话、跨会话记忆、知识库、外部工具返回结果，哪些进入当前上下文。第二个维度是粒度，也就是信息保留的精细程度。保留原文、保留关键词、保留摘要、还是只保留结构化字段。第三个维度是时效，也就是信息多久内有效。有些上下文一分钟后就该失效，有些则需要长期保留，如果没有时间意识，很容易出现新旧信息打架。

我在项目里一般会把这三个维度写进一个配置对象，而不是散落成一堆if-else。比如“客服场景”的配置可能是：广度=当前会话+用户画像，粒度=最近10轮原文+订单记录，时效=用户画像长期有效，聊天记录仅3小时有效。这样当业务方说“帮我调一下上下文”，我改的是配置而不是代码逻辑。

2. 四种常见的context-mode实现，以及各自适用的场景

2.1 直通模式：全部原始消息原样发送

直通模式是最简单的一种context-mode，把上下文相关的内容原封不动地拼进Prompt发给模型。不截断、不摘要、不检索，模型看到的就是完整的原始输入。

这种模式适合单轮问答、代码补全、短文档翻译等场景。因为它保留了所有细节，不会因为摘要或截断而丢信息。尤其在代码场景里，一个变量定义可能在30行之前，摘要模式很容易把它压没，而直通模式不会。

但直通模式的问题也很明显：token消耗大、响应速度慢、噪音多。我做过一个粗略统计，同样一个知识库问答任务，直通模式下平均需要3200个token，而检索增强模式只要900个token，回答质量却相差不大。更麻烦的是，当历史消息超过几十轮，直通模式就会撞上窗口上限，不得不面临“截哪头”的尴尬。

实践建议是：不要把直通模式当成默认选项，它应该是一种“高保真但有代价”的特例。我一般只在单轮任务、代码分析、或者需要逐字引用原文的场景下启用它。

2.2 滑动窗口模式：用最少的token守住最近的意图

滑动窗口模式在实现上很直接：保留最近N条消息，更早的消息直接丢掉。用一个deque就能实现，代码朴素得像算法课的入门作业。

from collections import deque class SlidingWindowContext: def __init__(self, max_messages: int = 10): self.max_messages = max_messages self.messages = deque(maxlen=max_messages) def add_message(self, message: dict): self.messages.append(message) def build_prompt(self): return [{"role": m["role"], "content": m["content"]} for m in self.messages]

这个模式的逻辑是：绝大多数多轮对话中，最近的几轮包含了用户当前的主要意图。比如用户在客服对话中先问“退货政策”，再发来一张订单截图，最后问“我这个能不能退”，模型并不需要记住用户三小时前抱怨过物流慢。只保留最近几轮，既能理解当前意图，又能控制token开销。

滑动窗口最大的坑是“过早遗忘”。如果任务需要依赖早期的关键信息，比如用户在一开始声明了“我是企业客户，要企业价”，后续聊了很多产品细节，滑动窗口会在十几轮后把“企业客户”这个关键设定挤出去。模型这时候可能给出个人版的报价，造成很严重的业务错误。

我一般在需要多步骤推理的Agent场景里，会给滑动窗口加一个“持久信息区”：把用户身份、任务目标等关键字段单独存放，不参与窗口滑动。这样窗口只管对话流本身，持久信息始终保留在系统提示里。

2.3 摘要压缩模式：处理超长对话的兜底方案

当对话轮数远超滑动窗口能覆盖的范围，直接截断又会丢关键信息时，摘要压缩模式就该登场了。它的思路是把早期对话先让模型读一遍，产出一段结构化摘要，然后只保留摘要和最近几轮原文明细。

实现时不能只做一层摘要就完事。我在一个实际项目里做过测试：一个50轮的对话，如果只保留“最近10轮原文+前40轮一份摘要”，回答质量会明显下降，因为用户前40轮里其实包含了多个不同主题，一篇笼统摘要无法支撑后期所有可能的追问。

更稳妥的做法是分段摘要。比如每10轮生成一份摘要，然后把多份摘要再汇总成一层总摘要。这样既能控制token总量，又保留了主题之间的区分度。而且每份摘要必须带时间范围标记，否则后边的问答根本不知道这份摘要对应的是哪段时期。

def summarize_segment(segment): prompt = ( "请将以下对话压缩为结构化摘要，保留：用户意图、" "已确认的关键信息、未完成的待办项。\\n\\n" f"{json.dumps(segment, ensure_ascii=False)}" ) return call_llm(prompt)

摘要压缩模式最推荐的启用时机是：当检测到历史消息总长度超过某个阈值（比如6000字或超过20轮），且任务类型为“需要长期记忆的连续对话”。但要注意，摘要本身也是要花钱花时间的，如果每来一条消息就重新生成一遍全部摘要，成本和延迟都吃不消。我通常会做增量摘要，只对新增的对话片段生成摘要，再和旧摘要合并。

2.4 检索增强模式：按需召回最相关的片段

检索增强模式是目前我用的最多的模式，也是RAG在context-mode层面的落地。它的核心不是把上下文一股脑塞进去，而是先把大量背景知识放进向量库，等用户提问后，再去库里找回和问题语义最相关的Top-K条内容，拼进Prompt。

这种模式在知识库问答场景里效果拔群。举个例子，一个企业内部的规章制度问答机器人，规章文档可能有几十万字，直通模式根本塞不下，摘要模式又会丢失大量精确条款。检索增强模式则能把问题映射到向量空间，找出最相关的几段条款，再让模型基于这些条款作答。实测下来，回答准确率能到90%以上，token开销还只有直通模式的四分之一。

但检索增强模式也有自己的陷阱。最常见的是“语义相关≠问题解决”。比如用户问“年假没休完怎么办”，向量检索可能召回了关于“请假流程”的片段，因为两者在语义上有相似性，但真正的答案在“未休假补偿规定”里。所以我在实际工程里会加一个重排序层，在向量召回后，用更精确的匹配模型或者规则做二次筛选，而不是直接信任embedding的Top-K。

3. 我在自己的AI助手项目里落地context-mode的完整过程

3.1 项目背景与需求拆解

这个项目是一个面向个人用户的AI知识库助手，用户会把自己的笔记、文档、收藏链接导入进来，然后像聊天一样提问。需求看起来很常规，但跑起来就发现复杂度被低估了。

第一个需求是长期记忆。用户昨天问过的东西，今天再问时应该还记得，不能每次都从头解释。第二个需求是多来源整合。同样一个问题，既可能牵扯到用户上传的PDF，也可能牵扯到我们内置的操作教程。第三个需求是成本可控，不能因为一次提问就把整个知识库全塞进上下文。这三个需求正好对应了摘要模式、检索增强模式和窗口策略的配合。

我一开始天真地打算用一套“万能Prompt”搞定，只要把用户所有历史消息和知识库文档都拼进去就行。结果第一次联调就崩了，模型输出质量极不稳定，还经常在回答里混淆不同文档的观点。那一刻我才意识到，这个项目必须配套一套真正的context-mode模块。

3.2 数据结构设计：让上下文变得可操作

为了让上下文被灵活编排，我没有直接用“字符串拼接”的方式组装Prompt，而是定义了一套带元数据的上下文条目。每条消息不光是role和content，还额外携带时间戳、来源类型、会话ID、任务ID等字段。

@dataclass class ContextItem: role: str # system / user / assistant / tool content: str ts: datetime # 产生时间 source: str # chat / memory / retrieval / tool_result session_id: str task_id: str = "" # 任务会话标识，用于隔离

这个设计的意义在于，context-mode的每个模式在执行时都可以基于这些元数据做筛选。比如滑动窗口模式可以直接按ts排序取最近N条；检索增强模式可以只命中source为“memory”的条目；回收阶段则可以按task_id把上一任务的条目全部标记为无效，而不需要物理删除。我后来接新项目时把这个数据结构原封不动地拷了过去，因为它足够通用。

3.3 一套管线打通三种模式

在实际代码里，我没有为每种模式各写一套消息组装逻辑，而是设计了一条上下文管线：策略解析 → 候选收集 → 模式执行 → 最终组装。策略解析拿到配置对象；候选收集从缓存、数据库、向量库中取出所有对应当前会话的原始条目；模式执行根据当前模式对候选做过滤、排序、截断或摘要；最终组装把结果转成OpenAI或本地模型要求的消息格式。

class ContextPipeline: def __init__(self, policy: ContextPolicy): self.policy = policy def build(self, session_id: str, query: str) -> list[dict]: candidates = self.collect_candidates(session_id) processed = self.policy.execute(candidates, query) return self.assemble(processed)

模式逻辑被封装在Policy对象里，每个Policy内部实现自己的process方法。直通模式返回全部候选；滑动窗口模式只保留最近K条；混合模式则先做向量召回，再拼上摘要和最近几轮。调用方完全不关心内部差异，只需要传入session_id和query。这套设计让后续加新模式变得很轻松，我后来只用两天就接入了“按用户画像优先级排序”的第五种模式。

3.4 模式切换的判定逻辑

模式不是用户手动选的，而是系统根据当前状态自动判定，这也是整个context-mode模块最核心的地方。我的判定逻辑分为三步。

第一步判断任务类型。如果检测到“知识问答”意图（比如问题中包含知识库关键词、文档名），就走检索增强模式；如果检测到“多轮任务”意图（比如用户说“继续”“下一步”），走滑动窗口+持久信息区；如果对话历史已经很长，就走摘要+最近轮次的混合模式。

第二步判断历史长度。一旦未压缩的历史消息总量超过我设定的阈值（我通常设为8000字符），就强制对早期消息做增量摘要，防止token溢出。

第三步做兜底。如果用户在消息里显式说“根据我上次说的”“还记得我之前问的吗”，我会把检索召回范围从当前会话扩展到历史摘要库，确保早期信息能被重新拉起来。

def decide_mode(query, history, session): if session.has_long_memory and is_memory_query(query): return "retrieval" if estimate_tokens(history) > 8000: return "summary_window" if is_chained_task(query, history): return "sliding_window" return "direct"

这里有一个经验：模式判定逻辑一定要做成可观测的，也就是每次判定完之后，要把“当前用了哪个模式、为什么用这个模式”记录到日志里。否则一旦回答质量下降，你根本不知道是模型问题还是模式切换问题。我后来能在半天内定位一次回答偏差问题，靠的就是这份模式决策日志。

3.5 实测效果与成本对比

项目跑通后，我用一套固定的20个问题集做了对比测试，分别跑直通模式、滑动窗口模式、摘要模式和检索增强模式。结果如下：

最明显的一个结论是：直通模式在长上下文下不仅贵，质量还差。原因就是输入里的噪音过多，模型注意力被稀释了。最终我把线上默认策略定为混合模式，单次问答成本只有直通版的十分之一，用户满意度反而明显上升。这也验证了我一直以来的看法：context-mode优先解决“上下文可信度”，而不是“上下文长度”。

4. 配置context-mode时最容易踩的坑

4.1 上下文污染：上一轮任务还在影响当前回答

上下文污染是我踩过最深的一个坑，现象是模型把不同任务的上下文混在一起，回答张冠李戴。我做客服机器人时就遇到过：用户先投诉“发货太慢”，客服介入处理完后，用户问了一句“现在还有什么优惠”，模型居然先道歉然后才推荐商品。原因就是，投诉相关的上下文还没被清除，被模型当成了当前会话的主要情绪基调。

根因在于会话隔离没有做好。很多初学者以为只要session_id不一样，上下文就不会串，但同一个session_id下可能有多个任务，这些任务之间也需要隔离。我的解决方案是在每个ContextItem上挂task_id，任务结束时把对应task_id的所有条目移出活跃窗口，同时往系统提示里注入一条“当前任务已切换，请忽略与上一任务相关的历史信息”。这招实测对GPT-4、Claude和国产模型都有效。

另一个容易被忽视的污染源是工具返回结果。Agent调用工具后，返回的大段JSON如果直接拼进上下文，里边的无关字段会严重干扰后续回答。我后来给工具返回结果加了一层精简策略：只保留模型决策所需的字段，把原始JSON存到外部日志，不进Prompt。

4.2 截断位置不对：开头真相 vs 结尾真相

用滑动窗口和截断策略时，很多人的第一反应是“直接保留最后N轮”。但我发现不同模型对上下文不同位置的注意力权重并不一样，尤其是当上下文很长时，模型往往会忽略中间部分，只有开头和结尾的信息能被稳定利用。

这个现象在工程上有两个直接推论。第一，不要把关键约束放在Message列表的中间位置。比如用户一开始的意图、任务的核心目标，要放在system prompt或非常靠前的位置，并且最好重复强调一次。第二，当内容超长需要截断时，不能简单地从中间一刀切。我常用的做法是保头保尾：保留用户最初的需求描述作为头，保留最近几轮交互作为尾，中间部分用摘要代替。

有一次我做一个合同审查助手，把一份50页的合同全文塞进上下文，然后让模型找违约条款风险点。结果合同中间某个关键页被模型完全忽略，导致漏报了一条重要风险。后来我把合同按章节切片，允许模型按需检索指定章节上下文，问题立刻解决。如果你的应用也涉及超长文档分析，别指望模型自己“通读全文”，它读不到，也读不全。

4.3 摘要逻辑偷懒：把摘要当永久记忆，却没有时间戳

摘要压缩模式做久了，很容易把摘要当成“永久记忆”来用。我一开始也是这么干的：每隔几轮生成一次摘要，然后无脑拼进下一次请求。直到有一次用户问“我上周说的那个想法你还记得吗”，模型回了一段完全错误的内容，我才发现摘要库里同时存在两个互相矛盾的版本，而模型分不清哪个是上周的、哪个是昨天新产生的。

问题出在摘要没有时间意识。正确的做法是，每条摘要必须记录覆盖的时间范围以及生成时间；使用时按时间排序，并且在做最终组装时提醒模型“新摘要优先于旧摘要”。我在数据结构里给memory类型加了两个字段start_ts和end_ts，拼接时按end_ts从新到旧排列，效果立竿见影。

还有一个容易被忽略的点：摘要本身的生成质量。如果摘要生成时模型没读全、或者把猜测当事实写进去，后续所有依赖摘要的回答都会错。所以我会在摘要中加入来源标记，比如“基于用户原始消息第5条到第12条生成的摘要”，这样可以在出错时追踪到原始来源。

4.4 检索召回反而带来噪音

检索增强模式不是上了向量库就万事大吉。我调过很多次，最难解决的其实是“召回结果太多太杂”。向量检索有一个特性，它返回的Top-K在语义上可能都很接近，但其中一部分只是“字面接近”，并不是当前任务真正需要的支撑材料。

举个具体例子，用户问“你们支持哪些支付方式”，向量库同时召回了“支付流程帮助文档”和“支付的国际合规说明”。后者虽然包含“支付”这个词，但对回答这个问题的帮助几乎为零，反而会把模型带偏，让模型开始讲合规风险。解决这个问题的核心是给检索加上一层“回答价值判定”，先用大模型或者规则模型对召回片段做个快速打分，只保留能直接支撑答案的片段。

另外，召回的片段应该保留足够的上下文边界。我只截取向量命中的所在段落，而不是把一个很大的章节整体塞进去。段落级的召回既能保留上下文信息，又不会让无关内容混进来。实测中，召回段落数从Top-8降到Top-4，回答准确率反而提升了10%左右，因为噪音少了。

5. 一些值得复用的调参与验证技巧

5.1 建立你自己的“上下文审计”用例集

很多团队调context-mode只靠“多聊几轮感觉还不错”，这完全不够。我在项目里建立了一套专门的审计用例集，用来专门验证上下文管理是否正常。用例集不需要很大，但必须覆盖几个关键场景。

第一类是长对话稳定性：连续对话30轮以上，每轮都追加新信息，看模型是否还能坚持最初的核心目标。第二类是任务切换：A任务进行到一半，强行插话切换到B任务，再切回A，看是否还记得A的进度。第三类是歧义提问：在上下文高度丰富的情况下提出一个模糊问题，看模型是选择追问，还是武断地从某个上下文片段猜测。第四类是数据混淆：把两条高度相似但结论不同的知识同时放进知识库，看模型能否区分。

每跑一轮审计用例，我会把失败的具体原因记录下来，标注是“上下文丢失”“上下文污染”“检索噪音”还是“模型本身能力不足”。只有分清楚这些原因，才不会被表象误导。比如我遇到过一种情况：模型回答很差，看似是context-mode没配好，但把所有上下文清空后单轮提问，模型依然答不对，那就是模型能力问题，跟上下文无关。

5.2 用“提示词自报家门”快速定位上下文问题

上下文管理是典型的“黑盒难debug”。 Prompt到底组成了什么样？模型到底看到了哪些内容？有一条非常快的检查方法，就是让模型自己复述它看到的上下文。

具体做法是在系统提示里嵌入一句话：“请先不要回答用户问题，请列出你当前看到的前5条消息的角色、时间戳和主要内容”。我实测下来，这个技巧能在几秒钟内暴露三个典型问题：第一，被遗忘的早期关键信息，模型会说你没给它；第二，被污染的上下文，模型会列出你根本不想让它看到的旧任务内容；第三，消息顺序错乱，模型列出来的顺序会和你的预期完全不一样。

这个技巧还有一个变体：让模型以JSON格式输出它认为的“当前任务目标”和“已获取的关键信息”。这比直接问“你理解了吗”可靠得多，因为模型在结构化输出时更难糊弄。我每次调完context-mode的配置，都会先跑一遍这个自报家门，再跑正常问答，能省下大量盲调时间。

5.3 上线前必须做的回归测试清单

context-mode的改动往往影响面很大，你以为只是调了摘要阈值，可能连带影响检索、窗口、任务隔离等逻辑。所以我把相关的回归检查事项整理成了一张清单，每次上线前逐项过一遍。

这套清单执行下来，每一次拍板上线都有了依据，不再靠感觉。我还习惯把每次调参前后的用例集运行结果保存起来，这样即使过了两个月，也能清楚知道某次参数改动到底带来了什么影响。

说回开头那个差点被回滚的客服项目。我后来给它的context-mode模块加上了任务隔离和模式决策日志，再配合上面的审计用例集做了两轮完整回归，上线后连续一周没有发生一次上下文章串台。如今我接手任何大模型应用项目，第一件事就是先问一句：你们的context-mode是怎么设计的，能不能画出上下文从采集到回收的完整链路？如果一个项目答不上来这个问题，那么不管模型选得多强、Prompt写得花哨，线上迟早会出幺蛾子。我个人有个习惯，会把所有context-mode的配置都做成长得像菜单的JSON，每加一个新场景就复制一份配置再微调，而不是去改公共代码。这样多项目复用下来，既稳又灵活。最后再分享一个最实用的小技巧：每次改完context-mode的配置，先用最小成本跑一遍开头的“自报家门”提示词，再跑正常任务。这十几秒的检查，能拦下80%的上下文事故。