企业官网建设流程全解析

做 AI 应用半年，我踩过最深的坑，就是对话上下文的管理。记得第一次把带聊天记忆的客服机器人丢上测试环境，用户问了三轮“你们怎么退款”，模型第三轮开始一本正经地推荐起隔壁竞品来——原因很简单：前两轮的对话内容被塞爆了，最新的系统指令被硬生生挤出了上下文窗口。从那天起我才明白，context-mode不是参数面板里一个可以随便拨的开关，而是决定 AI 应用能不能真正落地的那条生命线。

这里我讲的 context-mode，指的是在 LLM 应用开发中，针对“上下文窗口”的读取策略、组织方式和淘汰机制所形成的一套配置体系。它直接决定了模型能“记住”什么、该忽略什么，也直接关系到应用的响应质量、Token 成本和并发性能。这篇文章会把我在多个项目里用到过的 context 方案完整拆开：四种主流模式怎么选、窗口参数怎么算、混合模式怎么落地，以及那些文档里不会写的翻车事故和排查思路。适合正在做聊天机器人、文档问答、智能体（Agent）应用的开发者参考，不管你现在用的是哪家大模型 API，这套思路都是通用的。

1. context-mode 到底是什么，为什么我劝你一定要重视它

1.1 从一个翻车现场说起

先还原一下当时的真实场景。客户要求做一个“带记忆”的售后客服机器人，我的第一版实现非常简单粗暴：把整个对话历史原封不动地拼进 API 请求里，一起发给模型。跑通 demo 的时候一切正常，模型聊得头头是道，客户也很满意。结果一到真实对话，用户七拐八绕聊了三四十句，问题来了。

我用的模型上下文窗口是 8K（约 8000 token），消息内容一长，请求就报错context_length_exceeded。我开始手动截断，只保留最近几轮对话。可模型开始“失忆”：用户第一次提问时留了订单号，到第五轮问“那我这笔单什么时候能退”时，模型已经完全想不起来订单号这回事。

后来翻了模型官方文档，我才意识到一个扎心的事实：开发者自定义的 system prompt 和用户早期输入的历史消息，在模型眼里地位是一样的。谁的 token 先用完，谁就先被挤出去。当时我为了塞进更多聊天记录，把 system prompt 里的业务规则压缩得只剩一句“你是客服助手”，结果模型遇到稍微超出规则的问题就自由发挥，回复口径完全失控。

这个翻车案例基本把 context-mode 要解决的三大问题全暴露了：窗口溢出、关键信息丢失、系统指令被稀释。所以后面我做所有 AI 应用，第一件事就是先定义“这条对话里到底什么东西永远不能丢”，再去谈实现。

1.2 context-mode 的本质是在管理两样东西

说到底，context-mode 就是在管理两样东西：信息优先级和Token 预算。

信息优先级解决的是“什么该留、什么该扔”。一段对话里，信息天然分为几层：全局固定层（系统提示词、用户画像、业务规则，几乎不变）、会话记忆层（本次对话里用户提过的关键事实，比如订单号、地址、偏好）、短期缓冲层（最近几轮问答的具体措辞，用来保持语气连贯），以及临时噪声层（客套话、重复内容、离题话）。一个设计良好的 context-mode，本质上就是给这几层信息分配合适的“座位”，保证优先级高的永远不被挤走。

Token 预算解决的是“窗口就那么大，怎么分”。这里的核心不是“塞满”，而是“留白”。我自己的经验是：任何情况下，请求里的 token 总量不要超过模型窗口上限的 70%——剩下 30% 要留给模型的推理空间。这个 70% 是经验值，不是官网参数：窗口是模型计算时能“看到”的极限，但生成回答也需要占 token，如果请求体把窗口塞到九成满，模型来不及组织答案就被截断了。

明白了这两件事，再看市面上各种 context 方案，思路就会清晰很多。它们本质上都是“不同优先级策略 + 预算分配策略”的组合，没有哪个绝对最好，只有适合不适合你的场景。

2. 四种常见上下文模式，每种都有它的脾气

2.1 滑动窗口模式：最直观但最“健忘”

滑动窗口（Sliding Window）的逻辑是人最容易理解的：只保留最近 N 轮对话，更早的全部丢弃，相当于队列，先进先出。

实现上也很简单。每次请求前，从消息数组尾部往前数 N 条，拼起来发给模型：

def build_sliding_window(messages, max_rounds=6): recent = messages[-max_rounds:] if len(messages) > max_rounds else messages return [{"role": "system", "content": SYSTEM_PROMPT}] + recent

这套方案最大的优点是便宜、快、实现零成本。但它的“健忘”是硬伤。用户在第 2 轮说了“我住在朝阳区”，等聊到第 10 轮问“附近有什么餐厅”，模型根本不知道“附近”是以哪里为中心。很多团队把这种模式用在闲聊型机器人上，效果还行，因为闲聊本身就不需要极强的记忆。

不过有一个细节很多人会忽略：滑动窗口的“N”不能只按轮数算，还要按 token 算。有段时间我固定取最近 8 轮，用户机翻式长文本提问，一次发来上千 token，8 轮直接把预算吃穿。后来改成按 token 总量逆向截取，消息从尾部往前累加，达到预设 token 阈值就停，比按轮数更稳：

def build_token_budget_window(messages, max_tokens=3000): result = [] used = 0 for msg in reversed(messages): cost = estimate_tokens(msg["content"]) + 4 # 角色开销 if used + cost > max_tokens: break result.insert(0, msg) used += cost return result

2.2 摘要压缩模式：让模型自己给自己写笔记

滑动窗口的进阶版是摘要压缩（Summarization / Recursive Summarization）。核心思路不复杂：把早期对话定期“浓缩”成一段摘要，塞进上下文里当背景信息，完整的历史则丢到外部存储。

我第一次在一款数据分析助手里用了这个模式。用户和助手连续聊了两天，每天产生大量图表操作记录，如果全量塞进窗口，系统早就崩了。后来我只保留一个不断更新的“对话纪要”，每次对话开始前，把昨天的纪要 + 今天最近几轮原文拼在一起发给模型。

实现时要解决一个关键技术点：摘要的“摘要”怎么生成。方案是递归摘要：每积累到一定轮数，把旧摘要和新消息一起丢给模型，让模型生成一份全新摘要。下面这段是我实际在用的 prompt 模板：

summary_prompt = """ 你是一个对话记录员。请阅读以下旧摘要和新对话，生成一份新版摘要。 要求： 1. 保留所有具体数值、专有名词、用户明确表达过的偏好 2. 删除寒暄、重复、离题内容 3. 总长度不超过 {max_tokens} token 4. 只输出摘要，不要输出任何解释 旧摘要： {old_summary} 新对话： {new_messages} """

摘要压缩模式解决了长周期记忆问题，但它有一个致命缺点：摘要行为本身会造成“信息坍缩”。模型在压缩时一定会丢弃一些“它认为不重要”的信息，而这些信息往往恰好是后续对话里需要翻出来的关键。比如用户说过“我不吃香菜”，摘要模型可能因为上下文里菜谱信息太多，把这句随手带过的话压缩没了。

所以我现在只有在“对话周期长 + 单轮价值密度低”的场景才用纯摘要模式，比如长期陪伴类助手、日志分析 Copilot。如果单轮对话包含强事实约束（比如订单号、价格、地址），我会换下一种模式。

2.3 检索扩展模式：让上下文“按需加载”

检索扩展模式，也就是常说的 RAG（Retrieval-Augmented Generation）思路：不把全部历史或全部知识塞进上下文，而是根据用户当前的问题，先从外部存储里“捞”出最相关的片段，再拼进请求。

这个模式在文档问答场景里几乎是标准答案。我做过一个内部知识库机器人，知识库里有几百份 PDF，总量超过 20 万 token，根本不可能全塞进上下文。我当时的方案是：

1. 把知识库切成固定长度的 chunk（我用的 500 token 重叠 50 token，效果比较理想）。
2. 用 embedding 模型把每个 chunk 转成向量，存进向量数据库（用的是 pgvector，省得引入额外组件）。
3. 用户提问时，把问题转成向量，做相似度检索，取 top 5 chunk。
4. 把检索到的 chunk 作为“参考资料”拼进 system prompt 或 user message。

def build_rag_context(question, top_k=5): embedded_q = embed(question) chunks = vector_db.search(embedded_q, top_k=top_k) ref_text = "\n\n".join([f"[文档片段{i}]: {chunk}" for i, chunk in enumerate(chunks)]) return f""" 请根据以下参考资料回答用户问题。如果资料中没有相关信息，请明确回答“资料库中未找到”。 参考资料： {ref_text} """

检索扩展模式最大的优势是成本可控、知识面无限扩展。但坑也很深：检索效果直接决定回答质量，而检索的“相关性”本身就是一个难优化的指标。用户问“这个月还能不能报销”，chunk 里全是“报销流程”“报销制度”“报销限额”，向量相似度可能反过来把“报销流程”排在最前，把真正写着“月底截止”的那一条挤到后面去了。

用这个模式必须配套做召回评估，不能只看单个问题答得准就上线。我后面专门用一组 50 条的真实用户问题做了评测集，每条标注正确答案对应的 chunk ID，再调 embedding 模型和 chunk 切分方式，才把召回率从 62% 拉到 85% 以上。

2.4 混合分层模式：生产环境最常见的落地方案

到了真正上生产的复杂应用，我几乎不会用上面任何一种单一模式，而是混合分层。

什么叫混合分层？就是把全局指令、会话摘要、短期窗口、检索片段按优先级和角色拼进同一个请求，每一层只占一个预设的 token 预算。

下面是我在一个人力资源问答助手里用过的分层配置样例：

{ "context_mode": "hybrid", "layers": [ { "name": "system_rules", "source": "static", "max_tokens": 800 }, { "name": "user_profile", "source": "database", "max_tokens": 300 }, { "name": "conversation_summary", "source": "live_update", "max_tokens": 1200 }, { "name": "recent_messages", "source": "sliding_window", "max_tokens": 1500 }, { "name": "retrieved_chunks", "source": "vector_search", "max_tokens": 1000 } ], "total_budget": 4800 }

这个配置的含义是：系统规则固定在顶部，用户资料从库里实时加载，早期对话用摘要呈现，最近几轮按原文保留，遇到特定咨询触发知识库检索。然后所有层加起来控制在 4800 token 以内，给生成回复留出约 1400 token（按 8K 窗口算）。

混合模式的优势很明显：不同信息各归其位，不太容易出现“关键信息被挤出去”的极端情况。但代价是构建逻辑变复杂，每一层何时触发、何时降级、各层之间互相冲突时谁优先，都要明确规则。比如用户资料的 token 预算被占满时，是裁掉用户画像还是裁掉会话摘要？我的答案是优先保留最新且与当前轮相关的信息，这种取舍要写进代码，不能每次运行时重新决策。

3. 实操示例：给文档问答助手设计一套 context-mode

3.1 明确你的“上下文预算”

有了前面四种模式的铺垫，这一步来做个完整的实操演练。目标应用是一个电商客服文档问答助手，主要任务是根据售后政策文档回答用户问题，同时要记住用户在本次会话里交代过的订单号和个人信息。

先确定用的是 GPT-4o 的 8K 上下文窗口（128K 窗口的模型也同理，按比例计算就行）。直接拉满用是不行的，我按下面这个公式分配：

这里多说一句，为什么留 2000 token 给生成？实测经验是：文本生成的 token 数不是固定值，客服回复短则一两百，长则接近千 token。如果生成预算只留 500，一旦模型回答稍长就会“截断”，返回的 content 戛然而止，用户端拿到的是一段没说完的话。2000 的余量对客服场景来说比较稳。如果你做的是代码生成或长文写作，这个预留值要再上调到 3000-4000。

3.2 消息结构设计与上下文填充逻辑

确定预算之后，我把发给模型的messages设计成四段，顺序很重要：

messages = [ {"role": "system", "content": SYSTEM_RULES}, # 1. 全局指令 {"role": "system", "content": MEMORY_DIGEST}, # 2. 会话记忆摘要 {"role": "user", "content": RETRIEVAL_CONTEXT}, # 3. 参考资料（以 user 身份注入） # 4. 真实对话轮次，按 token 预算逆序填充... ]

为什么参考资料要以user身份而不是塞进 system？我踩过一次坑。原本我把检索片段和系统规则拼在同一个 system 里，结果模型经常把“参考资料”也当成“必须遵守的规则”，回答口吻变得很怪，有时还把资料里的不同来源冲突当成规则矛盾，反复道歉。后来改成单独一条 user 消息，前面标注“以下是参考资料”，模型就明白这是“背景知识”而非“行为准则”。

会话摘要的生成时机，我设在每个对话轮次结束时判断：如果累积的原始消息 token 超过了 3000，就触发一次摘要更新。摘要本身不删旧摘要，而是“旧摘要 + 新消息 → 新摘要”，保证信息不重复丢。这一步会额外消耗几百 token，但对比重发全部历史来说，省得多。

3.3 完整实现流程（从输入到回复）

整条链路我分成了六步，线上跑起来非常稳定：

第一步，接收用户消息，先查会话存储（我用 Redis，key 是session:{id}:history），确认当前会话有没有历史摘要和近期消息。

第二步，把新进来的用户消息追加到 Redis 的近期消息列表，同时更新“最后活跃时间”。

第三步，根据当前问题的类型决定是否需要检索。我设了一个简单的规则：问题里出现“能不能、怎么、是否、规定、流程、多久”这些词，就触发知识库检索；出现“我的订单、我买了、我上次”之类，则优先从会话摘要里提取信息，不触发检索。

第四步，执行检索（如果触发了），把命中的 chunk 按设定好的格式拼接成参考资料块。

第五步，按预算组装 messages。这个过程要写成一个纯函数，输入是摘要、近期消息、检索块，输出是拼好的 messages 数组。组装时用一个 token 计数器来算，超出预算就从“近期消息”里从旧到新丢弃，绝不能动摘要和检索块。

第六步，调用模型 API。拿到回复后，把回复也追加进近期消息，再次检查 token 累计值，决定是否触发摘要更新。

def assemble(session, retrieval_blocks=None): budget_system = 600 budget_summary = 800 budget_recent = 2000 budget_retrieval = 1000 messages = [ {"role": "system", "content": SYSTEM_RULES}, {"role": "system", "content": session.summary}, ] if retrieval_blocks: messages.append({"role": "user", "content": retrieval_blocks}) recent = session.recent_messages used_tokens = sum(estimate_tokens(m["content"]) for m in messages) for msg in reversed(recent): cost = estimate_tokens(msg["content"]) if used_tokens + cost > budget_recent: continue messages.append(msg) used_tokens += cost return messages

3.4 复杂度与成本估算

有朋友问过我这套方案的成本怎么样。拆开算一笔账：假设每次请求最终发送的 token 量在 5000 左右，模型回复约 300 token。按 ChatGPT 的价格一进一出合计约 5300 token，按 1K token 0.0025 美元算，单次对话约 0.013 美元。如果每天 1 万次请求，一天约 130 美元。

这套方案和“全量历史直接塞”相比，省下来的主要是历史越长越惊人的输入费用。我做个对比：完全不管理上下文的应用，聊到 30 轮时每次请求输入可能涨到 1.5 万 token，单次成本翻三倍不止。而且模型处理长度越长，首字延迟越高，用户端体感就是“越聊越卡”。context-mode 省的不只是钱，还有延迟。

4. 六个高频事故与排查经验速查

4.1 事故一：模型“突然失忆”，多轮对话答非所问

现象很典型：前三轮还好好记住用户的订单号，第四轮问“那可以改地址吗”，模型反问“什么订单号”。

排查路径我固定分三步。第一步，打开 API 请求日志，核对发给模型的 messages 里到底有没有订单号。很多时候你会惊讶地发现，订单号在摘要压缩时被吞了，或是在滑动窗口淘汰时被弹出去了。第二步，如果消息里确实有，再看 token 顺序：订单号是不是被放得离问题太远，被大量的中间轮次稀释了注意力——这是真实存在的情况，模型“中间丢失”现象在长上下文中非常明显。第三步，如果是摘要导致丢失，那就需要调整摘要 prompt，给“订单号、金额、地址、截止时间”这类字段设强制保留规则。

我的解决动作是在摘要 prompt 里加了一句“任何数字、金额、单号、日期、地址、人名必须原样保留”，实测摘要丢关键信息的概率降了很多。

4.2 事故二：Token 统计和真实消耗对不上

我一度用len(content)当 token 估算，结果模型动不动报超限。后来才搞明白，中文字符一个可能等于 1 到 2 个 token，代码和特殊符号另算，模型 API 的 tokenization 规则和我猜的完全不是一回事。

正确的做法是用模型提供方的 tokenizer 库来算。如果你用 OpenAI 的模型，tiktoken是标配：

import tiktoken enc = tiktoken.encoding_for_model("gpt-4o") def estimate_tokens(text): return len(enc.encode(text))

如果用的是其他模型，至少也要找到对应的 tokenizer，不要用字符数乘系数来糊弄。我见过一个排查了很久的问题，就是线上服务用字符数估算，用户的英文订单号加标点全是按 1 算的，实际 token 膨胀了快两倍，导致真实请求超限，报错时人们都一脸懵。

4.3 事故三：摘要压缩后数据丢失

递归摘要跑久了，有一个隐蔽问题：摘要再摘要，细节一层层磨损。第一次摘要还能保留 80% 细节，第二次基于旧摘要生成，可能只剩 60%，压缩三轮之后，连用户最初问的主题都变得模糊。

排查这类问题要看摘要变更记录。我给摘要对象加了一个version字段，每次更新时递增。如果发现某个关键字段在某个版本出现、在下一个版本消失，基本就是摘要 prompt 或者压缩策略的问题。解决方案不是把摘要无限加长，而是给摘要设置“强制保留字段”+“外部结构化存储”双保险：订单号、用户名这类结构化信息，直接从对话里抽出来存进数据库字段，不依赖摘要去记。

4.4 事故四：检索出来一堆“看似相关”但没用

这是 RAG 场景最普遍的坑。当时我把知识库切成 500 token 的 chunk 后，发现用户问“退货要多久”，检索命中的前三条全是“退货政策概览”“退货流程”“退货常见问题”，看起来相关，但真正写了“收到退货后 3 个工作日内退款”的句子藏在一个大 chunk 的中部，向量相似度被 chunks 里其它无关句子拉低了。

解决思路有两个方向。第一，改 chunk 策略：切得更小（256 token），让每个片段主题更集中；第二，用更大的 top_k，比如从 3 扩到 5，让更多 fragment 被召回再让模型筛选，但注意这占用了检索块 token 预算。第三，我给每个 chunk 写了 summary tag，检索时优先匹配 tag 再匹配向量，召回精度有明显提升。这里的教训是：RAG 不是一个 embedding 模型就完事的系统，chunk 策略、索引结构、召回线都需要单独调。

4.5 事故五：上下文注入顺序导致模型被带偏

有一个很有意思的现场。我把新的用户问题放在最前面，检索资料放在最后，结果模型把“检索资料里的旧说法”当成了当前目标，回答内容被绕偏。

大语言模型对消息顺序非常敏感，靠近开头和结尾的内容更容易被记住，中间部分容易“滑过去”。所以在组装 messages 的时候，《当前用户的最新问题》一定要放在最后一条，也就是模型要直接“回应”的位置；检索资料作为参考资料放在它前面即可。如果检索块和系统规则冲突（例如知识库文档更新了，规则没同步改），模型多半会优先听 System Prompt 的，必须留意这种优先级带来的“信息僵化”。

4.6 事故六：并发场景下 Session 上下文串线

这个事故最隐蔽。高并发下我为了省 Redis 连接，给 Session 存储加了个全局缓存，结果 A 用户的摘要被 B 用户请求读到了。用户问“我买的红色那件什么时候发货”，模型回答“您的蓝色订单明天送达”，简直社死现场。

排查之后确定是缓存 key 设计问题：只用了简单的自增 ID，没加会话维度隔离。修复方案：缓存 key 必须包含session_id，且每次读写都要做二次校验，绝不能把用户维度信息放在全局池子里。同时给会话摘要、最近消息、检索块的缓存分别设置不同的过期时间，避免一个 session 的数据异动影响其它 session。这个事故给我们的提醒是：context-mode 不是单请求的逻辑，它是一整套围绕“会话生命周期”的状态管理方案。

5. 一点个人心得：别把 context-mode 当成事后补救

做过的项目越多，越觉得 context-mode 应该是在需求分析阶段就确定的设计决策，而不是上线前用来“救火”的补丁。你甚至可以在产品 PRD 阶段就问三个问题：这个应用需要记多久的对话？哪些信息丢了会出事故？单次回答最长要写多长？答案一出来，适合的上下文模式基本就定了一半。

我个人的偏好是：任何面向用户的正式产品，都从混合分层模式起步，哪怕第一版只用其中两层。因为后续迭代要加记忆功能时，有分层骨架在，扩展起来数据库和检索层可以直接挂进去；如果一开始就用简单的滑动窗口，后面改的时候几乎要把整个会话模块重写一遍。

另外还想给一个小建议：context-mode 要配套可观测性。光看模型回复好不好是不够的，要记录每次请求发送出去的 messages 结构、各层 token 占比、摘要更新历史、检索命中的 chunk ID。遇到线上问题，这些日志能让你十分钟定位到是上下文哪一层出了岔子，而不是翻半天代码也找不到头绪。我就因为这些日志救回过两个差点回滚上线的版本，这个习惯值得每一位做 LLM 应用的同行养成。