企业官网建设流程全解析

用过ChatGPT、Claude这类产品的人大概都有这种经历：聊着聊着，模型突然忘了你半小时前说的关键信息；或者你丢了一篇很长的文档进去，它回答到后面就开始胡编。问题不在模型本身，而在于应用层对上下文的管理方式。做AI应用开发这两年，我几乎所有项目里都栽过这个跟头，直到把context-mode（上下文模式）当成一个正经模块来设计，而不是顺手拼几个变量，整条链路才算真正稳定下来。

context-mode本质上是解决一个问题：大模型的上下文窗口是有限的，但用户的对话和输入是无限的。怎么在这两者之间做取舍，决定了你的AI应用是"聪明"还是"智障"。这篇文章我会从设计思路讲到代码落地，再聊聊参数调优和踩坑实录，面向正在做大模型应用、智能客服、AI Agent的开发者，也适合刚入门想搞懂上下文机制的同学。读完你至少能判断自己项目该用哪种模式，并且能直接抄一套能跑的方案。

1. 为什么context-mode成了大模型应用的隐形瓶颈

1.1 所谓的"上下文"，其实是一笔预算

先搞清楚一个概念：大模型的上下文窗口不是内存，更像是一张白纸上的写作空间。你给它多少字，它就只能在这段文字范围内寻找线索来回答。GPT-4级别模型的窗口通常有128K甚至200K token，听起来很大，但换算一下：一个中文字大概占1到2个token，128K大概相当于8到10万字的容量。一本书呢？几十万字。一段技术文档呢？几千到几万字很正常。

所以上下文窗口不是给你无限装东西的硬盘，而是每个月要精打细算的预算。你塞进去的东西越多，模型出错的概率越高，响应越慢，成本也越高。我实测过，同一个问答任务，上下文从1万token涨到8万token，首字响应时间能慢两三秒，单次调用成本翻好几倍。这些数字背后全是真金白银。

context-mode就是一套管理这笔预算的策略：决定哪些信息放进去、哪些踢出去、哪些压缩后放进去、哪些从外部检索后再放进去。它决定了AI在长对话和大文档场景下的"记忆力"上限。

1.2 没有上下文模式，长对话必然崩

很多开发者第一版AI应用是直接拼接历史消息，全部塞给模型。短期demo没问题，一旦真实用户聊到第20轮、第50轮，问题就来了。

我接过一个智能客服项目的烂摊子：用户和机器人聊了40多分钟，中间提到了订单号、收货地址、退款金额。结果到第35轮，机器人问"您刚才说的订单号是多少？"——它忘了。不是模型笨，是前面35轮的消息把所有窗口都挤满了，模型在满屏的"嗯嗯""然后呢""好的"里根本找不到那个订单号。这就像你在一堆草稿纸里找一份重要合同，合同被埋在最底下，你当然找不到。

所以context-mode不是一个"锦上添花"的优化，而是AI应用从demo走向生产的及格线。没有它，长对话、大文档、多轮工具调用这些场景全都做不稳。

2. 三种主流context-mode实现路线

2.1 滑动窗口：最简单，也最暴力

滑动窗口的思路是：只保留最近N轮对话，更早的统统丢掉。实现起来非常直接，维护一个列表，超过长度就弹出最早的消息。

优点：实现成本低，性能好，不会引入额外的大模型调用。缺点：粗暴。用户在第2轮提到的关键信息，到第50轮早就被弹出了。它管用的是"短期记忆"，管不了"长期记忆"。适合那些聊天比较短、信息时效性强的场景，比如售后客服的当次问题处理。

2.2 摘要压缩：用模型给记忆"做笔记"

既然全部保留不现实，全部丢弃太可惜，那就折中：让模型定期把早期对话整理成摘要，用摘要替代原始内容。

打个比方，滑动窗口是"看完就忘"，摘要模式是"写课堂笔记"。你不可能把整节课的每句话都记下来，但你记下重点，期末复习时看笔记就够了。摘要模式每隔几轮触发一次，把前面的对话浓缩成几百字的要点，模型基于"笔记+最近几轮原始对话"来回答。

优点：能跨很长的时间保留关键信息，记忆容量远大于滑动窗口。缺点：每次摘要都要调用模型，成本和延迟增加；摘要本身可能丢细节；多次压缩后信息可能失真。适合长对话、长期助手类场景。

2.3 向量检索注入：只取"用得上的"记忆

第三种路线是把历史对话切成片段，做向量化存入数据库，每次提问时只检索最相关的几段注入上下文。这是RAG（检索增强生成）在对话历史上的应用。

我一般把这套方案称为"图书馆模式"：你不必把整本书背下来，但每次回答问题前，去图书馆按关键词查几页参考书。它不关心对话轮数，只关心相关性。用户提到"退款"，系统就把历史上所有关于退款的对话片段捞出来。

优点：理论上记忆容量可以无限扩展，不受上下文窗口限制，信息召回精准。缺点：架构复杂度高，需要向量数据库，检索质量直接决定回答质量，检索不到等于失忆。适合知识库问答、AI助手带长期用户画像的场景。

这三种模式不是互斥的，实际项目中我通常组合使用：滑动窗口做底层缓冲，摘要做中层记忆压缩，检索做顶层长期记忆。后面我会给出一个完整的设计框架。

3. 实操：从零实现一个可用的context-mode

3.1 先定义上下文的数据结构

动手写代码之前，先想清楚一条消息长什么样。我推荐用统一的消息结构，后面无论哪种模式都好处理：

from dataclasses import dataclass, field from typing import Optional, List import time @dataclass class Message: role: str # "user" 或 "assistant" content: str # 消息正文 msg_id: str = "" # 唯一ID，用于定位 timestamp: float = 0.0 meta: dict = field(default_factory=dict) # 扩展字段 @dataclass class ConversationState: session_id: str messages: List[Message] = field(default_factory=list) summary: str = "" # 摘要文本 last_summary_ts: float = 0.0 token_usage: int = 0 # 当前上下文估算token数

这里有个容易被忽略的点：timestamp和msg_id。很多初版代码只存角色和内容，等到要做摘要轮次判定、删除过期消息、检索定位时，才发现没有ID和时间戳寸步难行。我就是吃过这个亏，后来重写了整个状态模块。

token估算也建议做进去。不用精确到token级别，中文字符数乘以1.5、英文按空格分词再乘以1.3，粗略估算就够用。目的是在塞消息之前先判断会不会超限。

3.2 滑动窗口的核心逻辑

滑动窗口看起来简单，但有一个细节很多人做错：删除"早期消息"时，不要只按条数删，要按token数删。

def slide_window(state: ConversationState, max_tokens: int = 8000): """按token预算裁剪历史消息，保留最近的消息""" while state.messages and estimate_tokens(state.messages) > max_tokens: # 始终保留最近一条assistant回复，往前删 if len(state.messages) <= 1: break # 从最早的非最后一条消息开始删除，成对删除更好 removed = state.messages.pop(0) # 如果弹出的不是最后一条，尽量连带下一条一起删（保持对话连贯性） return state

为什么尽量成对删除user和assistant消息？因为单删一条user消息，后面assistant的回复就失去了引用的上下文，模型看到的是一段残缺的对话。当然如果消息本来就是单轮问答结构，可以按条删，但多轮对话场景务必成对处理。

窗口大小怎么定？一般取模型支持窗口的40%-60%。比如模型窗口是16K，窗口预算设在6K到8K比较稳妥。为什么不是越满越好？要给模型的回复留空间，也要给后续注入的摘要、检索结果留buffer。窗口塞到95%，模型想回答都只能写一小段，体验很差。

3.3 摘要压缩的触发与实现

摘要触发时机是个学问。我测试下来，两个触发条件组合最稳定：

• 消息累计token超过窗口的50%；
• 距离上次摘要超过5轮对话。

两者满足其一，就触发一次摘要。这样既不会频繁调用模型烧钱，也不会等到窗口爆炸才处理。

def maybe_summarize(state: ConversationState, llm_func, max_window_tokens: int = 8000): current = estimate_tokens(state.messages) if current < max_window_tokens * 0.5: return False # 远没到阈值，不处理 # 这里保留最近4轮作为"原始记忆"，更早的进入摘要 keep_recent = 4 recent_messages = state.messages[-keep_recent:] history_to_summarize = state.messages[:-keep_recent] if not history_to_summarize: return False new_summary = llm_func(summarize_prompt(state.summary, history_to_summarize)) state.summary = new_summary state.messages = recent_messages state.last_summary_ts = time.time() return True

摘要的prompt是关键。我踩过的坑是：prompt写得不够细，模型会把"用户是张三，下单了3件T恤"这种关键信息丢掉。后来我总结了一套结构化摘要模板，要求模型必须输出四块内容：

你是一个对话记忆整理员。请阅读以下对话片段，输出结构化摘要： 1. 用户目标：用户当前想完成的核心诉求 2. 关键实体：订单号、姓名、金额、地址、日期等具体信息 3. 已确认事项：双方已经达成一致的结论 4. 待办/未决事项：还没有解决的、用户期待后续处理的内容 请用简洁中文，不要遗漏具体数字和专有名词。

这样处理之后，摘要里的信息密度高了很多。之前模型会把"退款金额98.5元"写成"退款事宜已沟通"，损失巨大；要求输出关键实体后，数字就不会丢了。

3.4 向量检索注入的最小实现

如果做完整的检索模式，需要引入Embedding模型和向量数据库。很多团队在这里被复杂度劝退，但其实最小可跑版本并不复杂。我介绍一个轻量落地的做法。

先把每轮对话按一定粒度拆分，生成向量存入向量库，同时存原始文本和元信息。查询时，用用户当前的问题生成查询向量，召回TopK个片段，拼进上下文。这里有一个我反复强调的经验：不要只按对话轮切块，要按"语义段落"切块。一轮对话可能涉及三个话题，一个话题也可能跨好几轮。简单按轮切会导致检索召回噪声。

def retrieve_relevant_messages(query: str, vector_store, top_k: int = 4) -> List[Message]: query_vec = embed(query) hits = vector_store.search(query_vec, top_k=top_k) # hits 里带原始消息内容、会话归属、时间戳 return [h.raw_message for h in hits if h.session_id == current_session_id]

注入时注意顺序：检索结果放在摘要和最近对话之间，而不是最前面。放在最前面会干扰模型对"当前任务"的感知。我见过一个项目把检索片段塞在系统提示词后面，结果模型状态被带偏，回答风格都变了。正确顺序一般是：

系统提示词 → 历史摘要（如果有） → 检索到的相关历史片段（按时间正序） → 最近N轮原始对话 → 用户的当前问题

4. 关键参数怎么调：一份实测参考

4.1 各参数的作用与推荐区间

调参是context-mode的核心工作。不同项目最优参数差很多，但有一些基准参考。我整理了一张表：

这些参数不能拍脑袋决定，最好是压测后微调。我的习惯是：先用推荐值上线，然后专门构造30轮长对话测试集，观察回答准确率、上下文token均值、延迟三个指标。

4.2 三种模式的真实对比

我拿同一套多轮客服对话数据（40轮、含订单查询、售后沟通、个人信息确认），分别用三种模式跑了个对比。结果很有参考价值：

滑动窗口到了第15轮以后基本就在"裸聊"：模型只能靠最近几轮的信息答题，早期信息全丢。摘要模式在40轮内表现相当好，但跑到了80轮后，我观察到摘要开始"稀释"——第一轮的重要信息被后续摘要层层覆盖，逐渐丢细节。向量检索最稳，但前提是切块质量高、Embedding选对。

我的结论：如果你的对话平均不超过10轮，滑动窗口够用；10到50轮，摘要模式是性价比之王；50轮以上或者有长期用户画像需求，必须上向量检索。大部分商业化客服项目，摘要+检索混合已经能覆盖99%场景。

5. 常见问题与排查思路实录

5.1 模型"聊着聊着就忘了"，但日志里信息明明都在

这是最诡异的bug：检查代码，历史消息没丢，但模型就是答不对。我排查过几次之后发现，问题出在消息顺序上。有些框架的messages数组是倒序存储的（新的在前），直接拼接后模型看到的是倒叙对话，逻辑混乱。

解决办法很蠢也很简单：在发给模型之前，强制做一次messages = sorted(messages, key=lambda m: m.timestamp)，然后用debug日志打印出实际发给模型的完整prompt，人肉检查一遍顺序和内容。任何上下文诡异问题，第一步永远是dump完整prompt。我见过太多人抱着代码猜半天，最后发现是prompt拼装时漏了某个字段。

5.2 摘要"越压越失真"，关键数字丢失

摘要模式最常见的问题。有时不是prompt没写好，而是摘要多次迭代后，信息在"复述的复述"中流失。第一次摘要还留着订单号，第二次摘要把第一次的内容再压缩，订单号就没了。

我目前比较有效的方案是两层结构：第一层是"滚动摘要"——每当新摘要生成，和旧摘要合并，但prompt里明确要求"保留所有数字、订单号、金额、地址等不可压缩信息"；第二层是"关键事实库"——单独维护一个列表，凡是出现订单号、金额、身份证等强实体，直接抽取到库里，不经过摘要。查询的时候把关键事实库拼到系统提示词里。

# 关键事实抽取示例：正则+LLM结合 import re def extract_factoids(content: str) -> List[str]: facts = [] # 订单号/编号类模式 for match in re.findall(r'(?:订单号|编号|单号)[:：]?\s*[A-Z0-9]{6,20}', content): facts.append(match.strip()) # 金额类 for match in re.findall(r'(?:金额|价格|费用)[:：]?\s*[0-9]+(?:\.[0-9]+)?\s*元', content): facts.append(match.strip()) return facts

这样即使摘要做得再烂，关键数字也不会丢。

5.3 检索模式"召回了但没用上"

向量检索命中率很高，但模型还是答错。我调试了几次，发现是召回片段和当前问题的"时间线"对不上。比如用户第30轮问"之前那个退款处理好了吗"，系统召回了第5轮的退款申请片段，但没召回第20轮"退款已驳回"的片段，模型以为退款还在处理中。

解决思路：检索结果注入前，按时间戳排序，并加上时间段标注。在每条检索片段前加一行元信息：

[对话片段 第12-15轮 发生在用户询问"退款进度"之后] 用户：退款大概什么时候到账？ 客服：已提交财务，预计3-5个工作日。

加上时间锚点之后，模型对信息的先后关系判断准确多了。另外一个经验是：检索TopK不要贪多，3条高质量片段远好于8条鱼龙混杂。多了模型会捡了芝麻丢西瓜。

5.4 一个容易被忽略的性能坑

摘要和检索都是额外的大模型调用或网络IO，如果每个用户请求都同步触发，接口延迟会非常难看。我的方案是把摘要和向量化做成异步任务：用户请求进来，先用现有状态返回流式回答，后台异步更新摘要、更新向量库。下次请求自然就能用上更新后的记忆。这个"写后读"模式在并发场景下非常稳，但注意要加锁或版本号，防止两个异步任务同时写导致状态覆盖。

6. 场景化选型建议：你的项目该用哪种模式

做技术选型的时候，别急着跟风。我见过很多团队一听RAG就上向量库，结果数据量还没到一千条，白搭了整套基础设施。我的选型判断依据很简单，看三件事：对话轮数的分布、信息的时效性要求、团队能接受的运维复杂度。

短对话场景（均值5轮以内）：滑动窗口就够。别的不说，成本最低，没有额外依赖。硬上摘要或检索，属于杀鸡用牛刀，还会引入新的故障点。

中等长度对话（10-50轮）：摘要模式是甜点区。单次调用增加的时间在可接受范围，且记忆保留能力提升了几个档次。如果你的业务有订单号、账号这类强实体，再加上关键事实库的抽取，基本能做到"不忘事"。

超长对话或跨会话记忆（50轮以上/需要记住用户偏好）：上向量检索。这里我建议不要自己写向量化中间层，直接用成熟的向量数据库，把精力花在切块策略和召回质量调优上。

还有一个很多人的盲区：不同功能模块可以用不同模式。比如一个AI助手，闲聊模块用滑动窗口，资料查询模块用检索，长任务执行模块用摘要。不要试图用一种context-mode包打天下，全局统一反而在特定场景上都不够好。

7. 我最后想说的一个心得

做了这么多轮context-mode的迭代，最大的体会是：上下文管理本质上是在做取舍，而不是在做优化。你不可能同时做到"全记住""零延迟""低成本"，这三者是互相拉扯的。想清楚你的业务最在意哪个维度，然后接受另外两个维度的损失，比什么都重要。

拿我自己来说，刚开始做智能客服的时候，总觉得记忆越全越好，结果延迟上来、成本飙升，用户反而抱怨"回复变慢了"。后来把记忆策略改成"该记的记、不该记的丢"，体验反而更好了。用户根本不在乎你有没有记住他第3轮说的那句废话，他只在乎订单号、退款进度、地址这些关键信息别丢。

最后分享一个我一直在用的小技巧：上线前用一套固定的长对话脚本做回归测试，每周跑一遍，对比关键信息召回率。这个指标比什么延迟、成本更能反映context-mode的健康度。只要召回率不跌，参数随便调都不会出大问题；一旦跌了，赶紧检查是不是最近的改动动了摘要或检索的逻辑。这套方法救过我很多次，也推荐你们试试。