企业官网建设流程全解析

1. 为什么我建议每个做 AI 应用的人都认真对待 context-mode

做 AI 应用开发这几年，踩过最大的坑不是模型选型，也不是 Prompt 写不好，而是“上下文”管理一团糟。很多人一开始觉得，把用户的历史消息一股脑塞给大模型就完事了，结果 ChatGPT 这类产品看着挺聪明，自己做出来的应用却像个“金鱼脑”——问两句就忘，问多了还乱答。真正的问题出在 context-mode，也就是上下文管理模式上。这个关键词看着专业，说白了就是一句话：你要以什么方式、把哪些历史信息、以什么形态喂给模型。它决定了你的应用是“记得住”还是“记不住”，是便宜还是贵，是流畅还是卡顿。

我最早是在做一个客服机器人的时候被逼着认真研究 context-mode 的。当时用户抱怨最多的就是：“为什么我前面说过的地址它记不住？”我一看日志，发现我把最近 20 轮对话全部塞进 Prompt，结果模型确实“记住”了地址，但每轮请求的 token 数暴涨，响应时间从 1 秒变成 4 秒，月底账单更是吓人。后来我花了三周时间重构上下文管理，把 context-mode 从单一的全量模式改成“短期窗口 + 摘要沉淀 + 关键实体抽取”的组合模式，效果立刻不一样了：响应快了一半，成本降了 40%，用户满意度反而上来了。

这篇内容就是想把我在 context-mode 上的完整理解、设计思路、落地代码和踩坑记录都写出来。适合正在做对话机器人、AI Agent、知识库问答，或者任何需要“长期记忆”的 AI 应用的开发者参考。里面没有玄学，只有可以抄作业的方案。

1.1 先把 context-mode 的本质说透

context-mode 不是某个框架里的一个开关，而是一整套关于“模型输入上下文”的组织哲学。它回答的核心问题有三个：第一，保存哪些信息？第二，用多长的信息窗口？第三，以什么粒度、什么形态把信息重新组织后送给模型？

我拿人来做类比。你和朋友聊天的时候，不会把相识以来的每句话都在脑子里回放一遍再回答对方。你会有选择地调用记忆：最近几轮聊天的细节记得最清楚，更早的事情你只会记得大概意思。如果聊到某个关键人物，你会从长期记忆里把他拎出来，补充这个人的背景。“金鱼脑”就是只保留最近几轮；而把所有历史都塞给模型，等于让一个短时记忆容量有限的人强行背下整本聊天记录，他一定会消化不良，模型也一样。

所以 context-mode 本质上是在模拟人的记忆分层机制。基础的单轮模式只关心当前这句用户输入，多轮模式开始维护一个短期对话缓冲区，再往上走，就涉及把历史对话做摘要、提取结构化信息、建立向量索引这些更精细的手段。每一层解决不同问题，也付出不同复杂度的代价。理解了这个，就不会被各种高级名词绕晕。

1.2 context-mode 的典型适用场景

不同业务对上下文的需求差异非常大。在线问答这种“一问一答”场景，理论上甚至可以不做上下文管理，但一旦涉及多轮信息确认、用户信息收集、形态持续变化的业务状态，context-mode 就成了刚需。

我整理下来最适合采用完整 context-mode 方案的场景有这三类：

• 客服机器人 / 销售助理：用户会持续补充诉求，比如“我再加一个 XX 型号的报价”“刚才那个地址改成另一个”，模型必须记住前面说了什么，还要能识别改的是哪一部分。
• AI Agent / 多步骤任务代理：Agent 拆解任务、调用工具、返回结果，整个过程会产生大量中间数据。如果上下文管理不好，Agent 会在中途忘记原目标，产生“做着做着跑偏了”的现象。
• 个性化陪伴 / 角色扮演：这类应用要求模型记住用户的姓名、偏好、人生经历等长期信息，而且对话往往持续几个月甚至更久。光靠滑动窗口根本不可能，必须引入长期记忆机制。

如果你发现自己做的应用“偶尔聪明、经常失忆”，大概率不是模型不行，而是 context-mode 根本没设计。

2. context-mode 的核心设计：记忆分层与信息取舍

真正开始设计 context-mode 之前，有一件事你必须先想明白：你要让模型记住哪些东西，以及你打算为这些“记忆”付出多少 token 成本。这两件事直接决定了你的技术选型。我见过很多团队一上来就搞向量数据库，做得很重，结果业务场景根本不需要那么深的记忆。我也见过不少单机小应用，全靠暴力拼接上下文，最后被成本压垮。

我的建议是，先按“记忆层次”拆解需求，再决定每一层用什么手段实现。这套思路是我在生产环境验证过无数轮的骨架，也是理解后续所有代码实现的基础。

2.1 第一层：短期会话窗口，相当于人的“工作记忆”

短期会话窗口是最直观的 context-mode。实现上通常是一个 deque 或者 list，保存最近 N 轮用户消息和助手回复。轮到新请求时，把窗口里的消息与当前输入拼在一起，作为 Prompt 发给模型。

为什么不能无限加大 N？因为 token 限制和响应延迟双双制约着你。我实测过，GPT-4 类模型在 Prompt 超过 3000 token 之后，首字延迟肉眼可见地增加。另外，窗口过大还有个隐蔽问题：模型对 Prompt 中部的信息注意力最弱，这个在行业里叫“lost in the middle”。历史信息被淹没在超长的 Prompt 中间，模型要么忽略它，要么产生幻觉，反而比不提供更糟。

所以短期窗口的 token 预算我一般控制在总上下文窗口的 30%-50% 之间。比如模型支持 8K 上下文，留给短期窗口的只在 2K 到 4K 左右，剩下的留给当前指令、工具结果和摘要。具体数字看你的业务形态：纯闲聊可以放更多历史；需要大量工具调用结果的，历史就得让路。

这里给一个可参考的窗口设计思路：

• 最近 1-2 轮：完整保留原文，因为用户通常会在这里做轻微修正，漏了细节就接不上
• 中间 8-10 轮：优先保留与当前主题相关的部分，不相关的按时间顺序淘汰
• 更早的内容：只保留摘要或者关键实体，不进入短期窗口

2.2 第二层：会话摘要，相当于人的“情节记忆”

摘要模式是我陆陆续续推荐给所有要做长期对话的团队的方案。它解决的问题很朴素：历史太长了放不下，那我们就让模型把历史压成一段话。

具体做法是：每经过一定轮数（我常用 6-8 轮），触发一次摘要更新。把旧的历史消息和上一版摘要一起发给模型，要求它提炼出仍然重要的信息，生成新摘要。下次请求时，不再携带原始历史，而是只携带这份摘要。

这里有一个关键细节，很多人会做错：摘要不是“重写一遍”，而是“增量合并”。你每次都要把旧摘要拿出来，让模型看完旧摘要和新对话后，输出“仍然重要的旧信息 + 值得记录的新信息”。否则摘要会一直丢东西，聊到后面模型连用户叫什么都不记得了。

我踩过一个大坑：一开始让模型只对“新对话”做摘要，不加旧摘要进去。结果用户在第 30 轮问“还记得我一开始说的使用场景吗”，模型一脸茫然。后来改成增量合并，把旧摘要作为输入的一部分，模型才能把早期关键信息一直带下去。

摘要在 context-mode 中的定位，是“把握全局”而非“精确复述”。它牺牲了细节，换来了超长对话的可行性和可控的 token 消耗。如果你的应用需要精确记住用户说过的一串数字、一个具体地址，摘要是做不到的，那就需要下面这层——关键实体抽取。

2.3 第三层：关键实体与结构化记忆，相当于人的“语义记忆”

实体抽取是我在 context-mode 里最推荐投入的一层。它跟摘要不冲突，反而是互补关系。摘要负责“记住大概”，实体负责“钉死关键”。常见的做法是从每轮对话中抽取出结构化信息，比如姓名、地址、日期、商品编号、偏好、价格上限等，存成 JSON 或者键值对。每次生成请求时，把这些实体信息作为前置背景注入 Prompt。

好处非常明显。你不需要在摘要里反复强调“用户地址是北京朝阳区 XX 路 88 号”，只要在第一次出现时抽出来，之后每轮请求都带上这份结构化的用户画像即可。不仅准确，而且 token 占用极低。

我在一个电商售前机器人项目里，就用了一个简单的规则正则 + LLM 二次校验，把用户提到的商品型号、预算区间、收货城市全部抽出来。效果是：对话进行到第 20 轮，模型还能准确说出“用户想看的是 E5 系列的 1TB 款，预算 7000 左右，人在上海”。这是纯摘要模式很难做到的。

实体抽取的设计难点在于实体的时效性。比如用户先说“预算 5000”，后来又改成“预算可以到 8000”。你需要决定是覆盖旧值还是保留历史轨迹。我的经验是分两类处理：一类是稳定属性（姓名、城市、爱好），直接更新覆盖；一类是动态状态（当前预算、当前目标型号），必须保留旧值的同时标记新值，让模型能理解这是更新不是矛盾。

2.4 三种模式的选型策略：别一上来就全都要

选型策略这件事，我见过太多反向案例了。有人做个天气查询机器人，愣是上了向量数据库加长期记忆，维护成本高到吓人。也有人做高复杂度的工作流 Agent，却只用最简单的滑动窗口，导致 Agent 频繁失忆。

我的建议是，根据“对话时长的需求”和“信息精度需求”两个维度来选型，分辨出自己到底需要哪种 context-mode：

我现在做新项目，默认起步方案永远是“短期窗口 + 摘要 + 实体抽取”三层组合，但每一层的容量和触发频率会根据业务调。比如纯内容创作助手，实体抽取可以弱一点；CRM 类应用，实体抽取就是命根子。等跑起来有真实数据了，再优化每一层的参数。

3. 手把手实现一个可用的 context-mode 管理器

理论讲完，接下来是实操。我会带着你从零实现一个轻量的 context-mode 管理器，支持短期窗口、增量摘要、实体抽取三层能力。不用任何重量级框架，核心依赖就是 Python 3.9+ 和 OpenAI SDK（有能力的可以平替到任意大模型接口）。整个代码可以直接抄走改。

为了让代码有真实感，我下面用一个“家政服务预约机器人”作为示例场景。用户会和机器人多次对话，约定服务时间、地点、服务项目，中途还会改时间。你看完代码后，可以把这个场景换成任意你正在做的业务。

3.1 设计数据结构：会话对象是 context-mode 的基石

不管用哪种 context-mode，你都需要一个统一的数据结构来承载会话状态。我在生产环境里通常把它定义成一个 Session 对象，包含以下核心字段：

• session_id：会话唯一标识
• messages：短期窗口内的消息列表，每项包含 role 和 content
• summary：历史对话的滚动摘要
• memory：从对话中抽取出的关键实体/用户画像，以 JSON 存
• metadata：其他业务需要的状态信息

这样整个 context-mode 的状态就收敛到一个对象里。无论是存 Redis、存数据库，还是多机共享状态，都只用序列化这一个对象就行。

3.2 基于 token 预算的上下文组装逻辑

组装上下文，是整个 context-mode 的核心调度环节。我的做法是：先定总预算，再按优先级分配。

假设模型上下文上限是 8000 token，我会做这样的预算分配：

• 系统指令：固定 800 token（角色设定、回复格式等）
• 实体记忆：固定 300 token（JSON 结构注入）
• 工具/检索结果：最多 1500 token（如果有）
• 近期对话窗口：最多 2500 token
• 历史摘要：在剩余空间中自适应，一般给到 800-1200 token

这段逻辑用代码写出来是这样：

class ContextModeManager: def __init__(self, max_tokens=8000): self.max_tokens = max_tokens self.system_prompt = "你是家政服务预约助手，负责收集用户的服务需求。" self.short_term_window = [] # 短期窗口消息 self.summary = "" # 历史摘要 self.memory = {} # 关键实体 self.tokenizer = self._get_tokenizer() def build_context(self, current_input): """ 组装发给模型的完整消息列表，按优先级分配 token """ budget = self.max_tokens - 800 # 预留给系统指令 # 第一优先级：实体记忆 memory_payload = self._format_memory(self.memory) budget -= self.tokenizer(memory_payload) # 第二优先级：短期窗口（自适应截断） window_messages = self._fit_window_into_budget( self.short_term_window, budget ) # 第三优先级：历史摘要 summary_payload = self._fit_summary_into_budget(self.summary, budget) return [ {"role": "system", "content": self.system_prompt}, ] + summary_payload + window_messages + [ {"role": "user", "content": current_input} ]

这段代码的核心思路是：按优先级裁剪，而不是按先后顺序裁剪。实体记忆永远不丢，短期窗口优先保留最近几轮，摘要实在放不下了才截断。我试过反过来先放摘要后放窗口，模型对最近内容的敏感度会下降不少，遇到用户临时改需求就容易出错。

3.3 增量摘要的触发时机与更新实现

摘要更新不是每轮都做的，那样既浪费 token 又破坏上下文连续性。我的生产经验是：当短期窗口内的消息总 token 数超过阈值时，触发一次摘要合并。阈值我通常设为短期窗口预算的一半，比如预算 2500 token，那么窗口超过 1250 就触发。

更新摘要时，把旧摘要和当前窗口内的全部消息拼起来，让模型产出一个新的摘要。这段逻辑的实现：

def update_summary(self): """ 增量摘要：旧摘要 + 新消息 -> 新摘要 """ if not self.short_term_window: return merge_prompt = f""" 这是此前的对话摘要： {self.summary if self.summary else '（无）'} 这是最近几轮的新消息： {"".join( f"{m['role']}: {m['content']}\n" for m in self.short_term_window )} 请生成一份更新后的摘要。要求： 1. 保留此前摘要中仍然重要的信息 2. 把新消息中的重要信息合并进来 3. 用简洁的中文概括，100字以内 """ new_summary = self._call_llm(merge_prompt) self.summary = new_summary self.short_term_window = [] # 窗口清空，等待新一轮积累

这里有个细节：更新后短期窗口我选择清空，而不是保留一半。原因是不清空的话，下次组装上下文时同一批信息既出现在摘要里又出现在窗口里，等于重复计费，而且模型容易被冗余信息干扰。如果你担心窗口清空后短期记忆缺失，可以把更新时间点选在语义边界上，比如用户说完一个完整需求之后。

3.4 实体抽取的实现与更新策略

实体抽取我建议先用关键词正则做一轮粗筛，再用 LLM 做细化和更新。全量走 LLM 的话延迟高、费用高；只走正则的话，又处理不了用户口语里的复杂说法。

低配版实现（正则 + JSON 模板）：

import re def extract_entities_rule_based(text): """从一条用户消息中抽取基础实体""" entities = {} city_pattern = r"([\u4e00-\u9fa5]{2,8}?(?:市|区|县))" match_city = re.search(city_pattern, text) if match_city: entities["city"] = match_city.group(1) date_pattern = r"(今天|明天|后天|周[一二三四五六日]|\d{1,2}月\d{1,2}日)" match_date = re.search(date_pattern, text) if match_date: entities["service_date"] = match_date.group(1) return entities

高配版实现（LLM 合并更新）：

def update_memory_with_llm(self, user_input): prompt = f""" 现有用户记忆（JSON形式）： {json.dumps(self.memory, ensure_ascii=False)} 用户最新消息： {user_input} 请从中抽取所有可结构化存储的信息，并更新到记忆里。 注意： - 如果新消息与旧信息冲突，以新消息为准，用 updated 标记 - 只输出 JSON，不要输出额外文字 """ result = self._call_llm(prompt) try: self.memory = json.loads(result) except json.JSONDecodeError: # 如果模型输出不干净，做一次容错提取 self.memory = self._extract_json_from_llm_output(result)

实际跑下来，规则抽取负责“快”，LLM 负责“全”，两者配合后，基本能在一次响应内完成记忆更新，不需要额外排队任务。

3.5 完整请求流程的串联示例

所有组件就位后，一次带 context-mode 的完整请求流程是这样的：

def handle_user_message(session, user_input): # 1. 更新短期窗口 session.short_term_window.append({"role": "user", "content": user_input}) # 2. 更新关键实体记忆 session.update_memory_with_llm(user_input) # 3. 判断是否触发摘要更新 if session._count_window_tokens() > session.window_budget // 2: session.update_summary() # 4. 构建上下文并请求模型 context = session.build_context(user_input) reply = call_llm(context) # 5. 把回复写入短期窗口 session.short_term_window.append({"role": "assistant", "content": reply}) return reply

整体串联起来，就是一个最小可用的 context-mode 实现。开发过程中建议每一步都打日志，特别是 token 消耗和窗口长度，后面调优全靠这些数据说话。

4. 真实项目里的 context-mode 调优与问题排查

代码能跑通只是第一步。我在线上项目里真正花时间最多的，是各种奇奇怪怪的上下文问题。这里挑几个出现频率最高的记录一下，每个都是我真实踩过的坑，不是网上抄来的理论。

4.1 上下文截断后语义断裂

这是最隐蔽的一个问题。短期窗口满了之后，我一开始直接砍最旧的消息。结果用户上一轮说“把刚才那个方案改成 B 版”，这轮说“价格多少？”——模型根本不知道“刚才那个方案”是指 A 还是 B，因为我刚好把包含 A/B 方案的那轮给裁掉了。

后来我改成了“语义相关优先”的裁剪策略。具体做法是：维护一个简单的关键词索引，当需要裁掉超长窗口内容时，优先保留与当前轮关键词重合度高的历史消息。技术上不复杂，用一个 TF 词频统计就能实现，但效果立竿见影。上下文截断不是按时间一刀切，而是要按与当前话题的相关度来切。

4.2 摘要越滚越薄，早期关键信息丢失

摘要模式跑久了，会出现“信息蒸发”。一开始摘要里还有用户姓名，滚了 20 轮之后，姓名就消失了。我排查后发现原因在摘要更新的 Prompt 上：我只说了“保留重要信息”，但没定义什么是重要，模型倾向于保留最新消息里的宴细节。

解决办法是给摘要更新加一个“关键信息清单”，让模型逐项检查：

KEY_ENTITY_CHECKLIST = """ 检查以下信息是否存在于旧摘要或新消息中，存在则必须在新摘要中保留： 1. 用户姓名 2. 服务/商品类型 3. 预算或价格 4. 时间地点 5. 用户明确表达的偏好 """

把这份清单拼进摘要更新的 Prompt，问题就解决了。后来我干脆把这五项做成结构化字段，每次更新摘要时单独输出这些字段，再随摘要一起存下来，可靠性更高。

4.3 实体记忆冲突没有兜底

用户先说了“预算 5000”，后来又说了“太贵了，能不能便宜点”。第三个问题来了：“我到底说了多少次贵？”实体更新逻辑里，我直接覆盖了预算字段，但丢了“用户对价格敏感”这个状态。

现在我的实体记忆模型分两层：静态属性和动态状态。静态属性直接覆盖，动态状态保留最近三条变更轨迹：

"memory": { "budget": { "current": 5000, "history": [ {"value": 5000, "time": "2024-01-10 10:20"}, {"value": "未明确", "time": "2024-01-10 10:15"} ] } }

这样模型既能知道用户当前预算，也能看出来源历史，判断用户“是否反复修改预算”时就有了证据。如果做销售转化类的 Agent，这类历史轨迹几乎是必备的。

4.4 请求上下文过长导致的“中间遗忘”

这是大模型本身的注意力分布问题，但 context-mode 可以通过调整消息顺序来缓解。如果你用的是 OpenAI 接口，系统指令在头部、用户当前输入在尾部，中间夹着长窗口历史，模型对中部信息的利用率最低。

我的对策是把最需要模型遵循的信息放在头部和尾部。比如用户的明确指令放尾部，涉及用户画像的关键信息放头部。实测下来，一组 6000 token 的上下文，调整消息顺序后，关键信息召回率能从 60% 提到 85% 左右，算是零成本优化。

4.5 调试 context-mode 的三个日志维度

排查上下文问题时，没有日志寸步难行。我一旦上线新的 context-mode 策略，就会开三个维度日志：

• 组成结构：每轮请求中，系统指令、历史摘要、短期窗口、实体记忆各占多少 token
• 内容快照：随机抽样保留 5% 请求的完整上下文，方便复现问题
• 记忆变化：实体记忆从旧值到新值的 diff，摘要每次更新的前后对比

这套日志配合可视化工具，能让我在用户反馈“模型忘了”的时候，快速定位是截断问题、摘要蒸发问题，还是实体没抽出来。没有这套日志，排查类似问题完全靠猜，效率极低。

5. 关于 context-mode 的进阶思考和我的个人经验

聊到这里，context-mode 的基础方案已经立起来了。但真实项目里，它永远是动态演进的。我最后分享几个自己一直坚持的经验和判断。

第一，context-mode 没有银弹，每种模式都有明确的能力边界。摘要记不住精确数字，实体抽取记不住叙事逻辑，向量检索召回的上下文可能有噪声。合格的架构是让每一层各司其职，用工程手段兜住各自的短板。我见过有人想用向量数据库解决所有记忆问题，结果检索回来的内容经常和当前对话毫无关联，反而污染了上下文。合理的设计是「短期窗口为主 + 摘要兜底 + 实体锚定」，向量检索只做补充。

第二，token 经济账一定要算清楚。一个完整的多轮对话系统，context-mode 决定了每轮请求的 token 消耗。如果架构设计得合理，每轮请求可以稳定控制在较小范围；如果设计得粗糙，token 消耗会随对话轮数线性增长，很快超过模型上下文上限。生产环境里，这个指标直接决定了你的毛利是正的还是负的。

第三，动态调整 context-mode 的参数是加分项。我不建议一套参数跑到底。用户第一轮提问的时候，根本不需要摘要；用户连续对话 20 轮之后，短期窗口权重就应该让位于摘要。有些团队会做一个简单的赛跑机制：根据当前轮数、消息平均长度、业务类型，动态选择上下文策略。这个做起来不需要太复杂，收益却很可观。

最后，我自己的体会是：context-mode 本质上在做一个“记忆的取舍”决策，而好的决策永远基于对业务场景的理解，而不是对最新框架的追逐。你越了解你的用户在每轮对话里真正需要哪些历史信息，越清楚模型的注意力分布在什么位置，就越能设计出省钱、省心、用户还满意的上下文方案。如果看完这份梳理，你能少踩几个我当时踩过的坑，那这次分享就值了。