企业官网建设流程全解析

做过上下文相关的项目同学，大概率都遇到过这么一幕：对话一长，模型突然开始“失忆”，前面明明交代过的偏好，后面就像从来没发生过；或者一个工具调用参数被截断，整个流程直接崩掉。我最初以为这是模型能力的问题，后来踩了无数次坑才发现，症结往往出在context-mode——也就是上下文管理模式的设计上。简单说，context-mode不是一个开关，而是一套处理对话记忆的动态策略，它决定了哪些信息留在窗口里、哪些被压缩、哪些被转移到长期存储。这篇文章就是把我在实际项目里落地context-mode的完整思路、代码雏形和排障经验摊开来讲，适合正在做聊天机器人、AI Agent、代码生成助手，以及任何被上下文长度困扰的开发者参考。

1. 上下文模式到底在解决什么问题

1.1 不只是一个窗口，而是一套记忆策略

大模型的能力边界之一是上下文窗口，比如8K、32K、128K tokens。很多人以为窗口够大就万事大吉，实际上窗口越大只是把“遗忘”延后了，并没有解决“有效使用”的问题。你把半本《红楼梦》塞进去，模型照样会漏掉关键细节，因为注意力在整个长序列上被摊薄了。context-mode的核心任务是：在窗口有限、成本有限、延迟有限的前提下，把最有价值的信息放到模型最容易触达的位置。

我做第一个对话机器人时，用的是最粗暴的办法：把聊天记录全部拼接，然后一股脑丢给模型。前几十轮还好，到了两三百轮，首尾信息开始互相打架，模型把用户两个小时前说过的需求错误地理解成最新的指令，业务方差点让机器人把订单状态改错。后来我意识到，问题不在于“全部放进窗口”，而在于没有“分级”。context-mode就是把上下文按照重要程度、时效性、检索频率划分成不同层级，让模型每次读取时只面对整理好的精简版本。

这套策略听起来抽象，但在工程上非常具体：你需要一个窗口管理器、一个压缩器、一个记忆存储，再配一条路由规则。窗口管理器负责动态调整当前会话里保留的消息条数；压缩器负责把过期但有用的信息提炼成摘要；记忆存储负责保存跨会话的长期事实；路由规则则决定什么时候该走检索、什么时候该走完整记录。这些组件合在一起，才是真正意义上的context-mode。

1.2 最常见的三类翻车场景

先聊我实际遇到过的三类典型场景，你对照一下就知道自己是否需要引入context-mode。

第一类是长对话遗忘。用户在一个客服机器人里连续咨询，前5轮说了“我的是企业版账号”，到第20轮机器人却在推荐个人版功能。原因很简单：那条关键信息早就被挤出了上下文窗口，或者被后面的消息淹没在中间位置。模型不是没有能力理解，是压根没看到。

第二类是工具调用参数被截断。AI Agent在执行多步骤任务时，需要反复调用查询接口和写入接口。有一次我发现，某个Agent在调用一个更新接口时，总是把系统返回的成功标识误判为失败，反复重试。排查到最后，发现是上下文里塞了太多中间过程的调试日志，把真正的工具返回值挤到了窗口末尾，模型生成参数时参考了被截断的噪声数据。

第三类是跨会话语义断裂。用户第一次会话里详细描述过自己的写作风格，第二次会话开头说“继续”，如果系统没有把上次会话的关键信息持久化下来，模型就只能瞎猜。这也是很多“AI助理”看起来不够智能的重要原因：它们把“上下文”默认成了“当前会话上下文”，而不是“用户全生命周期上下文”。

这三种场景看起来各不相同，但本质一致：上下文没有被管理，只是被堆积。引入context-mode之后，处理方式就变成——关键事实进核心记忆，长对话分批压缩，工具调用保留最新状态，跨会话从持久化存储恢复。

2. 模式设计与核心机制

2.1 滚动窗口模式：最朴素但最可靠

滚动窗口是context-mode的入门方案，也是很多生产系统的兜底策略。它的逻辑很简单：始终保留最近N条消息，超出的旧消息直接丢弃，或者只留下摘要。实现起来非常直白，但我见过不少团队连这一步都没做好。

比如一个常见的错误是：按照消息条数保留，却不看token长度。用户消息很短，工具返回却可能几千字，结果窗口里存了同样数量的消息，实际长度翻了几倍，费用和延迟都失控。我后来统一改成“按token预算分配”，滚动窗口优先保留最近的消息，再往前只保留压缩摘要。具体可以用一个简单的优先级策略：最近20轮完整保留，20轮之前每10轮合并为一条摘要。

下面是我在一个项目里用过的滚动窗口维护逻辑，缩写成伪代码：

def rolling_window(messages, max_tokens): budget = max_tokens result = [] # 从最新消息往前遍历，保留完整消息直到预算耗尽 for msg in reversed(messages): cost = estimate_tokens(msg) if cost <= budget: result.insert(0, msg) budget -= cost else: break # 剩下的预算交给摘要 recent_msgs = result older_msgs = messages[:len(messages) - len(recent_msgs)] summary = summarize(older_msgs) if older_msgs else None return summary, recent_msgs

滚动窗口的优点是稳定、容易理解、不依赖复杂的检索系统，缺点是“记忆”随着窗口滚动很快消失。如果用户在第3轮提过一个关键要求，到第100轮时这个要求可能已经被挤掉，模型行为自然漂移。所以它适合对话深度不深、单轮交互为主的场景，比如表单填写、短客服会话。

2.2 摘要压缩模式：用成本换记忆

摘要压缩模式解决的是滚动窗口丢记忆的问题。核心思路是：当旧消息快要被挤出窗口时，用一次额外的LLM调用，把一段长对话压缩成带有结构化字段的摘要。这个摘要代替原始消息占据历史位置，从而保留长期信息。

我第一次实现时走了一个弯路：等到窗口快满的时候才去做压缩。结果在峰值流量下，压缩请求和用户请求同时争抢模型配额，延迟飙升。后来我改成“提前压缩”：设置一个压缩阈值，比如当历史消息总长超过窗口的60%时，就把前面的消息段异步送去压缩，而不是卡在用户请求的同步路径上。

压缩不是简单说“把这段话总结一下”，而是要面向后续提问。我会要求摘要包含用户关键偏好、已经确认的事实、未完成事项、明确拒绝过的方案。我常用的压缩prompt结构是这样的：

你是上下文压缩器。请把下面对话压缩为结构化摘要，保留： 1. 用户身份与偏好 2. 关键事实与状态变更 3. 已执行和未执行的任务 4. 模型此前的承诺 不要保留寒暄、重复提问、调试噪声。

压缩摘要其实是在用成本换记忆：每一次摘要都要花token，摘要质量好坏还会直接影响后续上下文的准确性。所以我会在摘要末尾加一个“置信度”字段，让下游环节知道这段信息是压缩出来的还是原文保留的，便于排查矛盾。

2.3 分层记忆模式：核心记忆、工作记忆、外部记忆

如果你做的不是单轮客服，而是真正的AI助手或Agent，建议直接上分层记忆。这是我认为目前最接近人类记忆机制的方案，它把上下文分成三层：核心记忆、工作记忆、外部记忆。

核心记忆是跨会话稳定不变的事实，比如用户的企业账号类型、工作领域、常用工具偏好。它的特点是一个字都不能丢，必须常驻系统提示词或独立缓存。工作记忆是当前会话中的短期状态，比如正在处理的任务步骤、最近一次工具返回结果，这部分会随着会话推进持续更新。外部记忆是历史会话的完整或摘要记录，平时放在数据库或向量库里，等需要时再检索回来。

一个很形象的类比是冰箱：核心记忆是贴在冰箱门上的便利贴，每天都能看到；工作记忆是灶台上正在炒的菜，手边材料要随手拿得到；外部记忆是冰箱冷冻层里的存货，要吃的时候才翻出来解冻。很多失败的Agent项目，问题不是冰箱太小，而是全部食材都堆在灶台上，火一开就糊了。

我在工程上的落地方式如下：核心记忆存Redis，有效期设为30天以上，每次会话开始时加载；工作记忆存内存，随着工具调用结果不断覆盖；外部记忆用向量数据库按会话分块存储，用户在新会话里说“上次那个方案”时，先做一次相似度检索，把相关历史片段拉回来注入上下文。这套结构改起来也不难，关键是每轮结束要做一次“记忆更新”，把新确认的事实回写进核心记忆，否则下次会话又得从头积累。

2.4 内容感知路由：让系统自己决定用什么模式

滚动窗口、摘要压缩、分层记忆不是单选题，更多时候要组合使用。我搭的context-mode里有一个router模块，专门负责根据当前请求的特征选择策略。它要回答的问题很简单：这一次请求，该用完整历史、摘要、还是向量检索？

我的路由判据有三个维度。第一是会话时长：新会话少于10轮，直接全部保留；超过20轮，进入摘要模式；超过50轮，先检索外部记忆再拼摘要。第二是任务复杂度：如果Agent需要连续调用超过三个工具，我会保留工具的最近一次返回结果和用户的最终目标，而不是把所有工具日志全堆进去。第三是引用密度：如果消息里频繁出现“之前说过”“上次提到的”这类代词，说明需要更强的记忆恢复，路由会把权重偏向外部检索。

实际开发中不要一开始就设计一个需要十路分支的超级路由器，那是过度设计。先写一个简单的规则引擎，能识别三种状态就够用了：EXHAUSTIVE（全量）、SUMMARY（摘要）、RETRIEVAL（检索）。跑一段时间，收集真实流量日志，再看看哪些规则不准确，慢慢细化。路由本身也是推理，频繁调用大模型来决策会拖慢响应，所以我尽量用轻量规则或者小模型判断，只有真正的关键请求才走大模型路由。

3. 实操落地：构建一个可供生产的context-mode

3.1 技术选型与模块划分

把context-mode做成生产级功能，我一般划分五个模块：context_router、window_manager、compressor、memory_store、injector。它们各管一摊，接口之间有清晰的输入输出，方便单独压测和替换。

context_router负责决定当前请求的上下文策略；window_manager负责维护当前会话的消息顺序和token预算；compressor调用大模型把旧消息压成摘要；memory_store是持久化层，存核心记忆和外部记忆；injector负责把最终整理好的上下文拼装成模型API需要的格式。

技术选型上，如果团队规模小，可以用Redis加内存队列起步。Redis存放核心记忆和最近会话，内存里放工作记忆。等到跨会话检索需求变强，再引入向量数据库。我见过有人一开始就上完整向量库和Agent框架，结果问题没解决，倒是引入了一堆运维负担。记住一句话：context-mode的本质是数据管道的设计，不是某个框架的插件。

模块之间通信我建议用简单的JSON结构，不要搞复杂的事件总线。下面是一个内部统一的上下文数据格式：

{ "session_id": "abc123", "mode": "summary", "core_memories": ["企业版账号", "偏好邮件沟通"], "working_memory": {"task": "查询订单", "last_tool_result": "success"}, "history": { "recent": [ {"role": "user", "content": "...", "ts": 123} ], "summary": "用户在前20轮确认了发货地址，并拒绝了加急选项。" } }

3.2 与LLM API的交互协议

与模型API的交互，我习惯把最终上下文组装成统一的message list。这里有几个重要的设计细节，稍不注意就会让context-mode白干。

第一，系统提示词要拆成“静态系统指令”和“动态记忆区”。静态指令是模型遵循的行为准则，动态记忆区是核心记忆和摘要。两条混在一起会导致记忆频繁变化时，模型对指令的遵循也出现波动。

第二，工具调用要用独立的消息角色标记，不要塞进普通文本。很多模型API给工具返回单独的消息槽位，放着不用，硬把工具返回拼进assistant消息，会让模型分不清哪段是工具输出、哪段是模型回答。context-mode里尤其要谨慎，因为压缩摘要时很容易把工具结果和对话文本混在一起，造成语义污染。

第三，对过期的工具返回要做标记。我会在工具返回前加一句前置说明，例如“以下结果来自5分钟前的查询，可能已过期”，这样模型在生成新请求时就不会盲目复用陈旧数据。

组装消息的伪代码如下：

def build_messages(state): messages = [] messages.append({"role": "system", "content": static_system_prompt}) if state.core_memories: messages.append({"role": "system", "content": "核心记忆：" + ", ".join(state.core_memories)}) if state.summary: messages.append({"role": "system", "content": "历史摘要：" + state.summary}) for m in state.recent_history: messages.append({"role": m.role, "content": m.content, "name": m.get("name")}) if state.working_memory.get("tool_result"): messages.append({"role": "tool", "content": state.working_memory["tool_result"]}) return messages

3.3 上下文预算的计算方式

token预算如果不算清楚，context-mode一定会出幺蛾子。我一般把一次完整请求的token预算切成四块：系统指令、核心记忆与摘要、近期对话、预留输出与工具调用。

假设模型的上下文上限是32K tokens，我的分配方案是这样的：系统指令控制在2K以内；核心记忆和摘要合计不超过8K；近期对话不超过12K；剩余大概10K留给模型输出、工具定义和临时预留。需要注意，不同的模型对系统提示词和工具定义计费方式不同，有些模型的工具定义要按每个工具几百token算，调用工具多的时候，仅工具定义就能吃掉不少预算。

有一个值得反复测试的细节：模型输出token不是固定上限，而是动态变量。如果你把max_tokens设成8192，那模型实际生成可能远低于这个值，但API预留的额度仍然是8192，这会影响输入token的实际可用空间。所以我在组装输入上下文时，不会把窗口占满，而是留出20%的缓冲。这是我用便宜模型踩过坑之后学到的：窗口算得满打满算，一旦输出稍微长一点，API直接报context_length_exceeded，重试成本更高。

预算分配的参考表如下，你可以根据自己的场景微调：

3.4 核心流程实现步骤

一个典型的context-mode处理流程，我会分成六步。第一步，接收用户请求，解析session_id；第二步，从memory_store加载核心记忆和外部记忆索引；第三步，调用context_router判断当前模式；第四步，window_manager根据预算和模式组装消息；第五步，调用LLM并拿到结果；第六步，更新工作记忆，把必要的事实回写核心记忆。

这套流程里，最容易写崩的是第四步和第六步。第四步容易出现“装多了”或“装少了”两个极端，装多了浪费token，装少了模型信息不足。我的建议是先做一个离线回放工具，把历史真实请求作为输入，记录每次系统拼装的上下文，对比模型输出质量，以此调预算比例。第六步则容易变成“每轮都写核心记忆”，导致核心记忆被低频事实灌满。我加了一个规则：只有当用户明确表述一个稳定偏好，或者系统确认完成一项重要状态变更时，才允许写入核心记忆。

下面是一个简化的流程实现：

def handle_request(session_id, user_message): state = load_state(session_id) mode = context_router.route(state, user_message) if mode == "retrieval": related = memory_store.search(user_message) state.external_context = related summary, recent = window_manager.assemble(state, mode) messages = build_messages(state) response = llm.chat(messages) memory_store.update_working_memory(session_id, response, user_message) return response

4. 常见问题排查与评测

4.1 上下文污染的症状与修复

context-mode上线后，最常见的故障不是“模型能力不行”，而是上下文被污染。污染有几个典型症状：模型突然用旧会话的人称说话；工具调用老带上上一轮的参数；回答内容里混进摘要注释文本。有一次我的模型在回答里出现了“[压缩摘要开始]”这种字样，一看就是注入格式写得不严谨，被模型当成正文了。

我排查污染问题时，第一件事永远是打印最终发给模型API的完整消息列表。这个方法虽然笨，但能快速定位问题出在哪个环节：是core memory写重了、摘要里有角色标签、还是recent history塞进了重复的tool call。看完再修，比盲目改prompt高效得多。

修复方案我总结成三条。第一，所有动态注入内容要加明确边界标识，并且这些标识不要和对话内容混在同一段文本里。第二，tool消息和普通消息分开存储，在组装阶段也不要合并成一个字符串。第三，给每条记忆加时间戳和来源字段，如果发现记忆冲突，按“核心记忆优先、近期对话其次、摘要最后”的优先级处理。

4.2 摘要丢失关键信息怎么处理

摘要压缩模式最大的痛点是：摘要丢信息。有些信息对用户重要，但压缩器觉得不重要，比如用户随口提过的“下周不在办公室”，在后续行程安排里却是关键约束。这个问题靠“更好的prompt”只能缓解，不能根治。

我现在的做法是加一条“关键事实抽取”的旁路。每次会话结束时，我会让压缩器先别急着写摘要，而是先用一个独立步骤抽取“事实三元组”，把用户偏好、状态变化、承诺事项归类。摘要只负责保留叙事线索，事实三元组则被单独存进memory_store。后续组装上下文时，摘要用于理解上下文，事实三元组用于精准决策。

如果用户回头询问一个摘要里确实丢失的细节，比如“我两周前让你记过报销账号”，该怎么办？我加了一个反馈回路：把用户的提问转成检索请求，去向量库里翻历史消息原文，而不是去摘要里找。只要原始消息还在外部存储里没删，就有机会恢复。所以我建议不要把旧消息彻底丢弃，而是压缩后放进冷存储，一旦用户追问，可以随时按session_id和原文检索。

4.3 性能指标与成本观测清单

做context-mode一定要有可观测性，否则优化无从下手。我会重点关注四个指标：有效token率、压缩成本占比、检索命中率、用户可感知延迟。

有效token率是指“模型生成最终答案时真正用到的输入token”占全部输入token的比例。这个指标没法直接测，但我用代理来判断：把输入的摘要和近期对话清空，只留核心记忆，看模型回答质量下降多少。如果下降不多，说明之前塞了大量无效信息。

压缩成本占比需要盯紧。摘要压缩本身也是一次LLM调用，如果不限制频率，压缩成本可能比正常推理还高。我设定了一条规则：只有历史消息的token数超过阈值，或者session进入新的会话时，才执行压缩。压缩调度做成异步队列，绝不阻塞用户请求。

检索命中率的观察方法相对简单：在外部记忆检索的日志里记录每一次拉取结果是否真的被模型引用。如果检索结果频繁注入但模型从来不提，或者回答质量没有变化，说明查询向量和对话场景不匹配，需要调整嵌入规则或者路由触达条件。

4.4 评测集与迭代方法

最后说说评测。context-mode这类系统，不能只在线上看反馈，还必须建一个离线评测集。我建评测集时固定三种难度：简单场景是10轮内的短对话，要求模型准确回答事实；中等场景是30轮长对话，穿插多个话题反转；困难场景是跨会话任务，用户在第一段会话里给过约束，在第二段会话中要求执行。

评测方法我建议用“关键行为校验”而不是“相似度打分”。例如，设计一个用例：用户A说要企业版，用户B要个人版，系统能否在共享会话背景下区分权限。这种用例只看模型是否给出正确操作，不看生成文本是否漂亮。跑分时我会对比不同context-mode配置的结果：纯滚动窗口、滚动+摘要、分层记忆三种方案各跑一遍，记录准确率和平均token消耗。

我自己的经验是：不要同时改多个变量。很多团队上线一周后，发现效果变差了，但说不清是摘要prompt改坏了还是路由阈值变了。因为这个系统是链路式的，变量一多，互相干扰，根本没法定位。我的习惯是每次只调整一个参数，跑两天观察期，再决定下一次改动。

5. 进阶思路与个人经验

5.1 从context-mode走向长期记忆

context-mode做好之后，最自然的延伸方向是把短期会话记忆演变成长期用户记忆。之前我记忆库里存的是“这个会话发生过什么”，后来我把它升级成“这个用户还需要什么”。做法是定期离线扫描已完成会话，抽取出稳定的用户偏好和业务约束，写入全局用户画像。

离线扫描通常放在低峰期执行，比如凌晨两点。扫描进程会读取一天内全部完成的会话，调用压缩器生成一份“长期记忆草稿”，再由规则引擎筛选出符合更新条件的内容。筛选条件包括：该事实在会话中出现两次以上，用户明确肯定过，或者与核心业务字段直接相关。以此避免把偶然话题当成长期偏好。

5.2 我在生产环境学到的几个实践心得

第一条心得是：先记录，再优化。context-mode上线前最好先埋点一两个星期，收集真实对话长度、token消耗、检索延迟等数据。没有这些基线数据，任何优化都是在猜。

第二条心得是：给所有记忆打版本。记忆不是单纯的键值对，它有生命周期，会更新、会过期。我在核心记忆里加了一个version字段，每次更新都会自增。这样当线上出现行为漂移时，我能快速判断到底是哪一次记忆更新引起的。

第三条心得是：小步快跑，别追求完美路由。现在这个项目里的context-mode，已经迭代了三个月，最初的版本只有滑动窗口和关键词替换，后来才一点一点加上摘要、检索和分层记忆。每次只加一个机制，配合评测集跑分，确认收益大于成本后再往下走。这种做法听起来不酷，但胜在稳，尤其适合生产环境里不能随便“重构一把梭”的团队。

如果你正在被上下文溢出、Agent状态错乱、长对话失忆折磨，可以先别急着换更大的模型，老老实实把context-mode的四个组件搭出来：窗口管理、摘要压缩、分层存储、内容路由。按这套思路落地，哪怕初期只先做滚动窗口和摘要，你也会明显感觉到模型“记性”变好了。