企业官网建设流程全解析

做AI应用的人，几乎都撞过同一堵墙：模型明明很强，但聊着聊着就开始“失忆”，要么把上一个客户的事记到下一个客户头上，要么为了让模型记住一点背景，把所有历史记录一股脑塞进提示词里，钱花了、延迟上去了、效果反而更差。我后来在好几个项目里都改成用 context-mode（上下文模式）来做会话管理，才算是把这堆烂摊子理顺——所谓 context-mode，本质上是给大模型的对话过程套一层“模式开关”，让系统在不同阶段、不同任务下，按需选择性地组装上下文，而不是每次都让模型面对一锅乱炖。

这个关键词在网上被频繁检索，多半也是因为大家在各种AI对话产品、低代码平台、智能体框架里见到这个词。我打算用一个具体的实践视角把 context-mode 讲透：它是什么、为什么需要、怎么在自己的应用里落地，以及我从“能跑”到“跑得稳”之间踩过的那些坑。适合正在做AI产品原型、做智能体工作流，或者被上下文管理折腾到快没脾气的开发者参考。

1. 先把 Context Mode 说清楚：它到底是什么

1.1 一句话定义与场景类比

上下文模式最直白的理解，就是给AI对话系统增加一个可切换的“记忆工作台”。模型本身没有长期记忆，它每次接收到的 prompt 就像一张白纸，你给它什么，它就基于什么回答。context-mode 要做的，不是让模型“记住更多”，而是让系统在正确的时间，把正确的信息放到这张白纸上。

拿餐厅点单来类比：普通聊天窗口像是客人坐在桌边跟服务员口述需求，服务员每次都要从头听一遍完整故事。Context Mode 则像是给服务员配了一张点单板，上面已经写好了桌号、忌口、已点的菜品，服务员只需要在客人追加菜品时更新点单板，不用把整本菜单重新念给后厨听。

所以在实际项目里，我一般不把 context-mode 当成一个神秘算法，而是把它当成一套“上下文装配流程”。它决定了三件事：哪些信息必须带、哪些信息可以压缩、哪些信息干脆不带。

1.2 从“聊天窗口”到“模式切换”：真正解决的问题

为什么不能一直用最简单的“把聊天记录全部发回去”方案？因为上下文一旦膨胀，代价会从三个方向同时冒出来。

第一是 token 成本。假设用户每轮对话消耗 500 token 的输入，聊到第 10 轮，单次请求就要携带约 5000 轮历史 token。看起来不多，但如果每天有 1 万个会话，乘以 10 轮，成本立刻从“可以忽略”变成“需要核算”。

第二是信息噪音。历史记录里充斥着“嗯”“好的”“谢谢”这类无意义内容，也有早期用户随口说但后来已经推翻的需求。模型分不清哪些是当前任务的关键指令，就会被噪音带偏。

第三是响应延迟。Prompt 越长，模型处理时间越长，尤其在高并发场景下，首 token 延迟会明显拉高。用户感知到的不是“模型更聪明”，而是“怎么转圈半天还没反应”。

Context Mode 的核心价值就是在这三者之间找到平衡。它不是一个开关，而是一组策略。比如：用户首次进入时走全量说明模式，后续追问走精简模式，跨天回访走摘要模式，管理员查询走全局模式。每种模式对应不同的上下文组装规则，互不干扰。

这个表格是我在几个项目里反复对比后得出的直观感受。说白了，前一种方案是“能用”，后一种方案才是“能用得久”。

2. Context Mode 是怎么运作的：经典路由结构拆解

2.1 三条主路径：短上下文、长上下文、全局上下文

我见过的 context-mode 实现，大部分可以归纳成三条路径，对应三种不同的上下文需求。

短上下文路径（Short Context）：只保留当前会话最近 N 轮对话，适合高频、短交互的场景。比如商品问答、翻译助手、填表辅助，这类任务里用户每轮提问都比较独立，历史参考价值有限，保留太多反而费钱。

长上下文路径（Long Context）：需要跨会话记忆或跨多个文档联合推理时使用。它不直接拼接原始历史，而是通过摘要和检索两步走：把历史会话先压缩成结构化摘要，再根据当前问题做向量检索，把最相关的 3-5 个片段拿出来。适合客服工单跟进、文档问答、项目复盘这类场景。

全局上下文路径（Global Context）：与具体对话无关但必须始终存在的信息，比如系统提示词、用户画像、业务规则、合规约束、插件权限说明。全局上下文通常在每次请求都注入，但它必须足够精简，只放“不变的规则”，不放“变化的记录”。

三条路径不是互斥的。实际请求经常会叠加使用：先注入全局上下文，再根据当前模式决定是否追加短上下文或长上下文片段。

2.2 一个可落地的“路由 + 组装器”架构

在工程实现上，我习惯把 context-mode 拆成两个模块：路由选择器（Context Router）和上下文组装器（Context Assembler）。

路由选择器负责回答一个问题：本次请求应该走哪条路径？判断依据可以是显式参数，也可以是隐式规则。显式参数比如用户在界面上手动勾选了“专业模式”，前端把 mode 字段传给后端。隐式规则比如系统检测到当前会话超过 20 轮，自动从短路径切换到摘要增强路径。

上下文组装器负责回答另一个问题：确定路径后，具体往 prompt 里放什么？它会执行三步操作：先从存储层拉取候选信息，再按 token 预算裁剪，最后按固定模板拼接成完整 prompt。

整体流程用文字描述就是：请求进入 → 路由选择器读取会话状态和模式标识 → 决定上下文类型 → 组装器拉取全局信息 → 根据需要拉取摘要或检索片段 → 做 token 裁剪 → 拼装 prompt → 交给模型。

这个架构最大的好处是把“放什么”和“怎么选”解耦。后续要调策略，只需要改路由规则；要换存储，只需要改组装器内部的取数逻辑，两边互不影响。

2.3 先搞清楚：用户真的需要长上下文吗

这是我做 context-mode 时最常被问倒的问题，也是我自己掉过坑的地方。很多产品经理提需求时会说“用户希望模型记住之前所有内容”，但拆开来看，用户真正想要的往往是“模型不要忘记关键信息”。

关键信息是什么？是用户的名字、偏好、核心诉求、上一次做到哪一步。这些东西用两三百 token 的结构化字段就能存下来，根本不需要几千 token 的原始对话记录。

所以我在设计路由之前，会先带着需求方做一次“上下文必要性审查”。方法很简单：让产品列出五个“必须记住”的信息点，然后逐个追问这些信息是来自历史对话、用户画像、业务规则还是外部数据源。做完这一步，你往往会发现，所谓的长上下文需求，有一半可以被“关键字段持久化”替代，剩下的一半才真正需要摘要或检索。

这样的前置分析，能避免把 context-mode 实现成“把所有东西都塞进去再慢慢删”的笨方案。毕竟模式再多，也架不住基础信息架构一团糟。

3. 动手实现一个 Context Mode 路由（附代码示例）

3.1 项目目录与基础数据结构

下面我用一个最小可跑的 Python 示例来说明核心实现。不考虑框架，重点看思路。

context_mode/ ├── router.py # 路由选择器 ├── assembler.py # 上下文组装器 ├── storage.py # 模拟存储层 └── main.py # 示例入口

先定义会话和上下文的数据结构。为了演示简洁，这里用字典模拟，实际项目里通常用数据库或向量库。

# storage.py # 模拟存储层，实际项目可替换为 Redis、PostgreSQL、向量数据库等 SESSION_DB = {} def get_session(session_id: str) -> dict: return SESSION_DB.get(session_id, { "history": [], "summary": "", "user_profile": {}, "business_rules": [], }) def save_session(session_id: str, session: dict) -> None: SESSION_DB[session_id] = session

这里的关键点是：一个会话对象里同时保存了原始历史、压缩摘要、用户画像、业务规则四类数据。context-mode 的不同模式，本质上就是对这些字段做不同的组合和取舍。

3.2 核心实现：上下文策略选择器

路由选择器只需要输出一个字符串标识，代表当前请求应该使用哪种模式。

# router.py def route(session_id: str, message: str, history_count: int, user_explicit_mode: str | None = None) -> str: # 1. 显式模式优先 if user_explicit_mode in ("short", "long", "global"): return user_explicit_mode # 2. 消息包含跨会话关键词时，切换到长上下文模式 cross_session_keywords = ["上次", "之前", "前几次", "那个客户", "上个月"] if any(kw in message for kw in cross_session_keywords): return "long" # 3. 会话轮数超过阈值，自动降级为摘要增强模式 if history_count > 20: return "long" # 4. 常规情况走短上下文 return "short"

这个函数展示了三类典型的判断依据：用户手动指定、关键词触发、轮数阈值触发。实际项目中，你还可以加入意图识别模型、业务时段、A/B 实验分组等更复杂的规则。

有一点要注意：关键词匹配非常不严谨。比如用户说“这次就算了，下次再说”，如果系统把“下次”当成跨会话关键词，就会误切到 long 模式。所以我通常会把关键词匹配的结果当候选信号之一，而不是唯一依据，后面会专门讲这个坑。

3.3 上下文组装与模型调用示例

路由确定后，组装器负责真正拼 prompt。

# assembler.py def assemble_prompt(session: dict, mode: str, message: str, max_tokens: int = 3000) -> str: parts = [] # 全局信息：无条件注入 business_rules = "；".join(session["business_rules"]) parts.append(f"[系统规则] {business_rules}\n") user_profile = session["user_profile"] if user_profile: parts.append(f"[用户画像] 称呼：{user_profile.get('name', '未知')}，偏好：{user_profile.get('preference', '未知')}\n") # 按模式注入不同上下文 if mode == "short": history = session["history"][-6:] # 最近6轮 history_text = "\n".join(f"用户：{h['user']}\n助手：{h['assistant']}" for h in history) parts.append(f"[最近对话]\n{history_text}\n") elif mode == "long": # 长上下文模式：摘要 + 最近少量对话 if session["summary"]: parts.append(f"[历史摘要] {session['summary']}\n") history = session["history"][-4:] history_text = "\n".join(f"用户：{h['user']}\n助手：{h['assistant']}" for h in history) parts.append(f"[最近对话]\n{history_text}\n") elif mode == "global": # 全局模式只放规则和画像，不放历史，适合管理员、系统查询等场景 pass parts.append(f"[当前输入] {message}\n") prompt = "".join(parts) # token 预算裁剪：超出部分优先丢最旧历史 if len(prompt) > max_tokens * 3: # 粗略按字符数估算 token，实践中建议用 tokenizer prompt = prompt[-max_tokens * 3:] return prompt

在 main.py 里把路由和组装串起来：

# main.py from router import route from assembler import assemble_prompt from storage import get_session, save_session def handle_message(session_id: str, user_message: str, explicit_mode: str | None = None) -> str: session = get_session(session_id) session["history"].append({"user": user_message, "assistant": ""}) mode = route(session_id, user_message, len(session["history"]), explicit_mode) prompt = assemble_prompt(session, mode, user_message) # 模拟模型调用。真实场景这里是 llm.chat(prompt) import hashlib reply = "【模式:" + mode + "】基于当前上下文的回复占位符" session["history"][-1]["assistant"] = reply save_session(session_id, session) return reply

跑一遍示例就能看到，同一句话在 short 模式下只包含最近几轮，在 long 模式下会带上摘要和历史片段，在 global 模式下只保留规则和画像。这就是 context-mode 最核心的动作：同样的模型，不同的输入组合，产生更贴合场景的回答。

3.4 参数怎么定：窗口预算、阈值选型与实测复盘

我给出两组经过验证的初始参数，你可以直接拿去当起点。

Token 预算分配：如果模型窗口是 8192 token，我建议 Prompt 控制在 3000 token 以内，其中全局上下文占 300-500，摘要占 300-800，对话历史占 1500-2000，给模型输出的空间留足 4000 以上。很多问题不是模型不会答，而是你把它的思维空间挤没了。

轮数阈值：短上下文保留 6-10 轮是我测下来收益最高的区间。低于 6 轮，多轮语义容易断裂；高于 10 轮，边际收益明显下降，但 token 消耗加速上升。自动切换长上下文模式的历史轮数阈值，我建议从 20 轮起步，低频客服场景甚至可以放到 40 轮。

摘要更新时机：不要在每轮对话后都重新摘要，太贵。我采用“每 8 轮更新一次摘要 + 会话空闲超过 30 分钟强制刷新”的策略。你可以先照抄这个方案跑一周，观察成本和问答质量的曲线，再做微调。

还有一点提醒：上面代码里的 token 裁剪是粗糙的字符截断，只适合演示。真实项目里一定用模型自带的 tokenizer 做精确计算，不然很容易把一个句子从中间拦腰截断，导致上下文语义残缺。

4. 实操过程中的 5 个高频问题和排查技巧

4.1 上下文被截断，模型答非所问

症状很明显：用户问了 A 话题，模型回答里却混着 B 话题的内容，或者干脆只说“根据提供的信息，我无法回答”。

排查思路先看落盘数据。打开会话记录，检查组装器实际输出的 prompt 末尾，是不是被粗暴截断了。我之前就遇到过：摘要字段本身超过预期长度，叠加最近对话后没有及时裁剪，系统把后续的内容全部截掉，模型只看到了“半句话”。

解决方式有两个：一是在写入摘要时就限制单条摘要的最大长度，比如 500 token，超长就分段；二是在组装器里对每个输入源分别设配额，而不是拼完再整体截断。分来源设配额比整体截断更可靠，因为整体截断永远是从末尾开始丢，很可能会把“当前输入”本身丢掉。

4.2 多轮对话之后响应越来越慢、越来越贵

这个问题的根源多半是短上下文路径没有兜底。当路由逻辑过于简单，比如只判断轮数大于 20 就切 long，系统在高频轮次下会把摘要和最近对话一起塞进去，导致 prompt 缓慢变大。

我的做法是给不同模式设“硬性上限”。short 模式最多注入最近 10 轮，long 模式最多注入 5 轮原始对话加 800 token 摘要，global 模式不注入任何对话历史。路可以切换，但每个路口的车流量必须限死。

另外检查一下摘要更新逻辑。如果用同步调用且摘要模型本身很慢，那么用户每发一条消息，系统都要先等摘要跑完才能返回，体验会非常差。改成异步更新是个可行的解法：先带着旧摘要回复用户，后台再刷新摘要，下次对话启用新摘要。

4.3 用户手动切换模式反而更混乱

我在一个客服工单项目里给过用户“简洁模式/详细模式”的切换按钮，结果发现不少用户选了详细模式后，上传了大量无关文档，模型回答质量反而下降。原因很简单：用户以为“详细”就是“把所有东西都带上”，但系统不知道哪些详情对当前问题有用。

后来我把用户侧的模式名改成了场景名：比如“投诉处理”“订单查询”“产品咨询”，每个场景对应内部的路由策略，而不是暴露底层技术模式。用户不需要理解上下文机制，只需要表达“我现在在做什么事”。这个改动直接让误切换率下降了一大截。

4.4 关键词匹配把上下文塞错

前面提到了“下次”这个词。实际操作中，我见过更离谱的：用户说“我不喜欢上次推荐的那个东西”，系统把“上次”识别为跨会话信号，加载了另一个客户的工单记录，因为关键词匹配只认文本不认语义。

要避免这个问题，最小可用的方案是把关键词列表收敛到“会话身份强相关”的词，比如“之前那个工单”“上次那个客户”“我上回说的”。同时要在组装器里加一道校验：检索出来的上下文片段必须与当前会话的用户 ID 一致，不一致就丢弃。

如果项目预算允许，也可以用轻量意图分类替代关键词匹配。不需要很大的模型，一个可以本地跑的中文意图分类模型就够了，但成本会比关键词高，适合对准确率有硬性要求的场景。

4.5 排查清单与监控指标

我每次排查 context-mode 问题都会过一遍五个检查点：路由判断是否正确返回预期的模式标识；组装器是否注入了重复内容；摘要是否停留在旧版本未更新；token 裁剪是否切断了关键信息；检索片段是否出现了越权或分类错误。

监控指标上，最值得盯的是三个：平均 prompt token 数（衡量成本与延迟），用户主动重试率（衡量回答质量），模式切换分布情况（衡量路由规则的合理性）。这三项数据如果长期异常，说明系统里有结构性缺陷，不是临时调参能解决的。

5. 真实场景里我踩过的坑和设计取舍

5.1 第一个坑：把摘要功能当成万能药

刚开始做 context-mode 时，我以为只要有了“摘要”，长对话问题就解决了。结果摘要经常把关键细节压掉，比如用户说过“周二下午三点到四点之间不要打电话”，自动摘要变成“用户对通话时间有要求”，具体的时间窗口全部丢失。

后来我在设计摘要时引入了“结构化字段 + 自由文本”双轨制。像时间、地点、金额、电话号码这类高价值信息，单独抽取并存储在结构化字段里；剩余信息才走自由文本摘要。这样即使摘要再粗，关键参数也不会丢。这个改动听起来简单，但对下游问答准确率的影响是决定性的。

5.2 第二个坑：历史记录全量拉取导致超时

有段时间我在组装器里图省事，直接执行了一条 SQL 把该用户的全部对话一次性查出来，再在内存里做裁剪。用户聊得越久，查询越慢，最终某个大会话直接把接口拖到超时。

现在我的原则是：优先做“定点取数”。short 模式只查最近 N 条；long 模式先查摘要字段，再针对当前问题做检索，而不是全量拉历史。存储层如果走 Redis，可以用固定长度的列表结构保证历史记录只保留最近 100 轮，从源头控制数据量。

5.3 第三个坑：上下文里混入过期信息

用户改过密码、换过诉求、撤销过订单，但历史摘要里还是旧数据。模型看到旧信息和新输入冲突时，通常会选择更详细的那一方，结果就是回答错误。

我现在会在每个上下文片段上打“时间戳参考线”。组装器注入摘要时，同时携带这条摘要的生成时间；如果摘要生成时间早于某条关键操作时间，就标记为低优先级，优先使用更新的信息。相比让模型自行判断新旧，这个方法更稳定。

5.4 小技巧：给上下文打上“版本号”

最后分享一个让我省心很多的做法：为整个提示词模板设置一个版本号字段，比如 prompt_version = "v3_short"。这样当模型回答异常时，我可以直接根据日志里的版本号判断问题出在模板结构、路由策略还是数据层，而不是靠猜。

版本号还可以配合线上实验。我在两个项目里用过去参数对照：A 组走 v1 模板，B 组走 v2 模板，观察一周后的 token 消耗和用户满意度，再决定哪个版本上线。这让每次调整都有数据支撑，而不是“我觉得这样更好”。

根据我个人的使用体会，context-mode 并不是一个需要写几千行代码的高级功能，它更像一套思考方式：先想清楚每个场景里模型需要哪些信息，再用路由和组装两个动作把信息按需送进去。你在自己的项目里实现时，我建议把最简版本跑通后再逐步加规则，不要一开始就追求复杂的自动化判断。先用一句话记录上一次的方案是哪个模式，再慢慢验证。