企业官网建设流程全解析

1. context-mode要解决的真实痛点：大模型不是“聊得越长越聪明”

我最早接触到 context-mode 这个概念，不是在看论文，而是在一个实际项目里被上下文窗口逼到墙角。当时我们做了一个文档分析助手，用户会持续上传几十页的合同、技术文档，然后连续追问。最初版本逻辑很简单：把用户每一次上传的内容、每一轮问答历史全部塞进同一个会话上下文里，直接发给模型。

问题很快就暴露了。当累积内容超过 30k token 左右，模型的回答质量开始明显下滑。不是偶发，而是稳定地变笨：开始忘记前面文档里的关键数字，开始把不同合同里的条款混在一起，甚至出现自相矛盾的结论。我们第一反应是换更大的模型、开更长的窗口，结果费用翻了将近一倍，问题只是推迟了 10k token 才出现。

后来我才意识到，这本质上不是模型能力问题，而是上下文管理的问题。你给模型看的上下文里，包含大量已经过时、互相干扰、和当前问题无关的内容，模型要在这些噪音里做推理，效果当然会越来越差。context-mode 这个模式设计的核心思路，就是打破“上下文=所有历史内容”的惯性，让系统在每一轮对话开始前，主动决策当前应该给模型提供哪些上下文、以什么形态提供、保留多少、丢弃多少。

如果你也在做大模型应用，尤其是涉及长文档、多轮对话、工具调用的场景，那 context-mode 这个概念很值得你花半小时认真理解。这篇内容不是教科书式的原理介绍，我会直接从工程落地角度拆开它，讲清楚几种模式的差异、实现逻辑、以及我在实际项目中踩过的那些坑。

2. 上下文窗口的预算模型：先算账再写代码

在讨论模式本身之前，我强烈建议你先做一个动作：把模型的上下文窗口当成一个预算池子，而不是一个仓库。这个思维方式转变，比学会任何具体实现都重要。

2.1 标称窗口不是可用窗口，先减掉三笔固定开销

很多开发者看模型参数，只看“上下文长度是 128k 还是 200k”，然后设计系统时就按这个上限去规划。这是第一个大坑。实际可用上下文远小于标称值，因为存在三笔几乎固定的开销：

第一笔是系统提示词（system prompt）。如果你做的是垂直领域助手，系统提示词里通常会包含角色设定、业务规则、输出格式约束、安全限制等，这部分少则 1k token，多则 5k token 甚至更多。第二笔是工具定义（tools schema）。如果你接入了函数调用，每个工具的描述和参数定义都会吃掉 token，我见过项目工具定义加起来超过 8k token 的。第三笔是当前轮次的用户输入和模型保留的必要格式信息。

我在一个项目里做过实测：标称 128k 窗口的模型，扣除系统提示 6k、工具定义 8k、当前轮次输入约 2k，真正能用来放历史上下文和检索结果的空间，只剩大约 110k。如果按业界常用的“安全水位 80%”来算，实际可规划预算只有 88k 左右。很多人栽跟头，就是因为从来没算过这笔账。

2.2 把预算拆成几个互不干扰的池子

有了总预算后，我建议你把它拆成几个独立的小池子，每个池子的上限由你主动控制，而不是让所有内容挤在一个池子里自然膨胀。通常我会这样拆：

• 会话级固定头（system prompt + 工具定义 + 用户画像）：这部分要严格压到最小，并且固定在 3k 以内，能精简就精简。
• 短期记忆池：存放最近 1-2 轮对话的原始内容。这是模型推理最依赖的信息，保留完整形态，预算根据模型能力给 4k-8k。
• 长期事实池：存放从历史对话和文档中提炼出来的关键事实、摘要、结构化信息，预算 8k-15k。
• 检索召回池：根据当前问题从知识库或历史记录中实时检索到的相关内容，预算 8k-20k。

这四个池子的比例不是死的，但原则是：原始历史对话永远不要无限制地堆积，长期信息必须经过“压缩”或“结构化”之后再进入上下文。context-mode 本质上就是在管理这几个池子之间的切换策略。

2.3 计算示例：一个典型请求的 token 开销明细

为了让你更有体感，我给你一组我们项目里的真实数据。假设我们的文档分析助手，使用一个标称 128k 的模型，配置了 3 个工具（合同条款检索、条款对比、金额计算），系统提示词经过反复精简后为 4.2k token。一次典型的用户追问：“第三份合同里甲方的付款义务和第 2 份合同比有什么变化？”

请求的真实构成大概是：

• 系统提示词：4.2k
• 工具定义：3.6k
• 当前用户输入：0.1k
• 短期记忆（最近 1 轮问答）：2.8k
• 长期事实池（已提炼的项目摘要、合同结构化要点）：6.5k
• 检索召回池（根据“付款义务”“变化”检索出的相关条款）：3.2k

总输入 token 大约是 20.4k。如果这个项目没有做 context-mode，全量历史对话和文档一股脑塞进去，这个数字会轻松突破 40k，而且里面混杂了很多和当前问题无关的历史讨论。差距不是两倍的问题，而是信噪比的问题。

3. 三种 context-mode 的实现原理与适用场景

现在进入正题。我把常见的 context-mode 实现归纳为三种：Level 模式、Hybrid 模式、Oriented 模式，也可以理解为渐进演进的三个阶段。很多开源框架和商业产品里看到的模式切换，本质都是这三种思路的组合变体。

3.1 Level 模式：固定窗口滑动裁剪，最简单也最粗暴

Level 模式是大多数团队最初采用的方案。核心逻辑就是维护一个固定大小的滑动窗口，新内容进入，旧内容从窗口底部移出。实现起来很简单：用 token 计数管理历史列表，超过阈值就把最老的消息裁掉。

这种模式的优点是实现成本极低、行为可预期、调试容易。适合对话流程比较短、对历史依赖不深的场景。但它有一个致命缺陷：它是纯按时间顺序裁剪，完全不看内容价值。用户可能在第 2 轮提过一个关键需求，到第 8 轮用户问“我刚才说的那个需求你记住了吗”，系统早就把那轮上下文裁掉了。

我在一个客服工单助手项目里就犯过这个错。上线一周后，运营反馈模型经常“不认账”——前一天用户明确说过的退款诉求，第二天模型就忘了。排查后发现，超长对话中较早的关键信息都被滑动窗口挤掉了。后来我们加了一个规则层：把包含关键实体（订单号、金额、日期、诉求类型）的对话标记为“重要消息”，不受窗口裁剪影响，单独存到长期事实池。这其实是向 Hybrid 模式过渡的雏形。

3.2 Hybrid 模式：摘要压缩加原文检索，兼顾时效与长期

Hybrid 模式是目前我认为性价比最高的方案，也是我们项目最终采用的方案。它同时维护两条上下文通路：

一条是滚动摘要（rolling summary）。每经过 N 轮对话，对大模型发起一次“总结请求”，把当前阶段的关键信息压缩成结构化摘要，替换掉原始历史对话。另一条是原文检索。系统维护一个完整的历史消息存储（比如存入向量数据库或带索引的 JSON 文件），当新的问题到来时，通过 embedding 在历史存储里检索与当前问题最相关的原始片段，作为实时补充。

这个模式的精妙之处在于：模型看到的长期记忆永远是“提炼后的精华+精准命中的原文”，而不是全部历史。摘要提供全局概览，检索提供局部细节，两者配合既能控制 token 消耗，又能确保关键时刻的原始信息不丢失。

实现上需要关注两个点。第一是摘要的更新频率和触发机制，不能每轮都做，否则成本翻倍；也不能隔太远，否则摘要丢信息。我们实测下来，3-5 轮做一次摘要比较合理，触发条件可以设定为“历史原始 token 超过阈值”或“出现了新的重要实体”。第二是摘要本身的长度控制，我建议把滚动摘要的上限控制在 1.5k token 以内，超过就强制要求模型做二级压缩（只保留结论和行动项）。

3.3 Oriented 模式：任务驱动路由，把上下文交给“意图路由器”

Oriented 模式是更进阶的玩法，核心思路不再是“管理已有的上下文”，而是“先决定这一轮需要什么上下文”，再动态组装。它的架构里多了一个前置模块，我习惯叫它意图路由器（intent router）。

当用户的新消息进入系统，意图路由器先做三件事：

• 判断当前消息的类型：是追问、是闲聊、是需要工具的新任务，还是对之前结论的质疑。
• 预测需要的上下文范围：比如涉及第 2 份合同的付款条款，就只需要从长期事实池中提取合同 2 的摘要，以及相关条款原文。
• 制订组装计划：哪些内容需要完整原文，哪些内容可以用摘要替代，哪些内容直接不注入。

这种模式的优势在复杂业务场景里非常明显。比如用户先问“帮我汇总三份合同的违约责任”，接着又问“其中那份补充协议的违约金计算方式是怎样的”。在 Hybrid 模式下，系统知道去检索“补充协议”相关原文，但可能仍然会带上三份合同的摘要作为冗余。在 Oriented 模式下，路由器直接判断当前问题只依赖补充协议的内容，其他两份合同的摘要完全不注入，省了 token 的同时也消除了交叉干扰。

当然，Oriented 模式的代价是引入了额外的一次模型调用（或一套规则引擎）。但如果你的业务场景消息类型复杂、上下文池巨大，这笔开销是值得的。我个人的经验是：先用 Level 跑通业务，再升级到 Hybrid 解决长期记忆问题，等对话类型分化明显后再引入 Oriented。直接上 Oriented 对工程能力要求较高，多数团队没必要走那么快。

4. 我落地 context-mode 时的工程细节与踩坑记录

原理说完了，接下来这部分是我真正想分享的干货：把一个 context-mode 系统从 demo 推到生产环境，会遇到的几个典型问题。这些坑网上很难搜到完整描述，基本都是靠线上故障换来的教训。

4.1 上下文污染：最隐蔽的质量杀手

我所说的上下文污染，指的是模型收到的上下文里包含了与当前任务无关、甚至冲突的信息。它的隐蔽性在于：模型不会报错，它只会默默地把错误信息当作事实来使用。

举一个我们真实遇到过的场景。用户先上传了一份旧版合同（版本 V1），我们系统生成了摘要 A。后来用户又上传了修订版（版本 V2），摘要更新为 B。但在一次对话中，用户的原始历史消息里还保留着对摘要 A 的引用，Level 模式下这些旧引用没有被清除。结果模型在回答“当前合同的有效期”时，同时看到了 V1 的旧摘要片段和 V2 的新摘要，它选择了旧的那条。用户立刻质疑我们“系统怎么还拿旧版说事”。

排查到最后，不是摘要逻辑错了，而是上下文组装时没有做版本一致性过滤。这个问题的通用解法是：在进入上下文之前，对每个片段打标签（来源文档 ID、版本号、生成时间），组装时按当前会话的“事实基线版本”过滤掉过期标签。这个过滤逻辑可以放在意图路由器里，也可以做成独立的预处理步骤。

4.2 历史压缩的静默失败：模型“偷懒”是硬伤

滚动摘要功能刚上线时，我遇到过一个更头疼的问题。某天线上反馈异常增多，很多用户投诉模型回答越来越“空”——不是错误，而是空洞。比如问“具体怎么操作”，模型答“建议按规范流程执行，具体细节需要参考相关文档”，完全没有实质内容。

我日志翻了大半天，最终定位到问题出在摘要压缩请求上。原来，摘要请求是周期性触发的，但压缩 prompt 里我写的是“总结用户与助手之间的对话历史”，没强调“保留所有关键数字和具体要求”。模型在压缩时偷偷做了一次“价值判断”，把大量它认为不重要的细节丢弃了，而这些细节恰恰是用户后续追问时最需要的事实。

这个问题很多人会忽略，因为在开发阶段，测试数据量小、对话简单，模型压缩时丢点细节不明显。一旦上了真实业务，对话涉及合同金额、日期、人名、政策条款，压缩损失就会立刻暴露。我的解决方案是：给压缩 prompt 加上强制保留清单，明确列出“金额、日期、负数条件、实体名称、用户明确要求”五类信息必须原样保留，并且要求模型对摘要做“事实数量校验”——如果原文中有超过 5 个具体数字而摘要中不足 3 个，视为压缩失败，需要重做。这个校验规则虽然笨拙，但非常有效。

4.3 重写 vs 截断：前缀重压缩的正确打开方式

处理超长历史时，很多开发者习惯直接截断（丢掉最老的），或者简单地把历史消息整体发一遍让模型“记住”。这两种方式我都不推荐。

截断的问题刚才已经说过，会丢关键信息。而“整体重发”的问题是成本失控，而且模型并不会因为同样的内容看了两遍就记住得更牢。更合理的方式是前缀重压缩（prefix recompression）：当历史消息即将触顶时，不是丢弃最老的部分，而是把最老的一段消息连同已有摘要一起压缩成新的摘要，然后把原始消息从存储中标记为“已归档”，只保留压缩结果。

这个操作有点像是给记忆做“整理”而不是“删除”。我踩过的坑是：压缩归档时如果不保留“原始消息存储 ID 与摘要片段之间的映射”，后续检索时会出现一种尴尬情况——检索到了某个摘要片段，但不知道它来自哪条原始消息，无法向用户展示溯源。所以务必在归档时建立一个双向映射表：摘要片段 ID 对应原始消息 ID 列表。

4.4 元数据与可观测性：context-mode 必须暴露给调试端的四个字段

说过很多次，生产环境的大模型应用，最怕的就是“黑盒”。context-mode 系统尤其如此，因为每一轮请求的上下文都是动态组装的，一旦模型回答异常，你根本不知道它当时看到了什么。为此，我要求项目在响应接口的调试日志里强制输出四个字段：

• context_mode：当前用的是 Level、Hybrid、还是 Oriented。
• context_budget_used：实际消耗的上下文 token 数、四个池子各占多少。
• context_sources：本次组装上下文时引用的片段来源列表，包含每个片段的文档 ID、摘要 ID、向量命中相似度分数。
• ignored_candidates：被路由器丢弃的候选片段及其丢弃原因。很多人忽略这个字段，但它是排查“模型为什么不知道某件事”最关键的线索。

有了这四个字段，线上问题排查时间可以缩短一个数量级。没有它们的 context-mode 系统，出了问题只能盲猜。

5. 效果验证与长期维护：数字说话，别凭感觉升级

最后聊一聊怎么验证 context-mode 到底有没有用，以及系统的长期维护清单。这里我不会给你一套验证模板，而是分享我们实际做过的对比实验和调整过程。

5.1 评测集构建：别用“聊聊天感觉变好了”来验收

我见过太多团队升级 context-mode 后，只在几个人工测试例子上跑一下，“嗯，回答更准了”，然后就上线了。这样做风险极大。context-mode 的改动会影响所有线上对话，而人工测试无法覆盖长尾场景。

我们的做法是构建三类评测集。第一类是黄金问答集：从真实用户对话中抽取 200 条典型问题，人工标注标准答案。第二类是长尾捡漏集：把线上遇到过且模型回答明显错误的对话单独整理成一个集合，用于验证模式升级是否修复了这些历史问题。第三类是 token 回归集：统计升级前后同样一组请求的平均输入 token 和响应延迟，确保我们没有用“花更多钱”换来“更准”。

上线三个月后，我们积累了这样一组可公开的对比数据：Level 模式下，模型在长对话中段的关键事实准确率只有 61% 左右；切换到 Hybrid 模式并加入摘要强制保留清单后，这个数字提升到了 84%；而在引入 Oriented 模式的意图路由后，长对话末段的准确率进一步稳定在 88% 上下。与此同时，平均每请求的输入 token 在 Hybrid 模式比 Level 模式反而降低了约 22%，原因是大量历史噪音被移除了。

5.2 维护清单：context-mode 不是“配完就完事”

最后给你一份我自己的维护清单，每两周执行一次，确保 context-mode 系统的健康度：

• 重新统计四个上下文池子的实际 token 分布，确认没有一个池子悄悄膨胀越过预设水位。
• 抽样检查滚动摘要的实体保留率，随机抽取 20 条摘要，对比原始消息中的金额、日期、实体是否齐全。
• 检查意图路由器的预测准确率。我们会在路由层记录每一次预测以及实际结果（用户是否满意），定期统计发现的失误模式。
• 复盘所有线上用户投诉中与“模型忘记/混淆信息”相关的工单，确认没有新的污染模式出现。

这套检查机制本身不复杂，但长期坚持下来，积累的收益非常大。高频地检查能让你在模型更新、提示词变更、业务规则调整时，第一时间感知到 context-mode 系统是否受到干扰，而不是等到用户大规模投诉才发现问题。

我个人做 context-mode 相关项目的最大体会是：它不是一个“配置项”，而是一整套围绕上下文预算、内容价值和检索策略的运维体系。对资源有限的团队来说，先把 Level 用明白，再逐步升级到 Hybrid，是最稳妥的路线。如果一开始就追求最复杂的 Oriented 模式，大概率会陷入调试地狱。而当你真正把 context-mode 跑顺之后，你会发现模型推理能力的上限被彻底释放了出来，很多之前需要换更大模型才能解决的问题，靠上下文优化就能完成。