企业官网建设流程全解析

如果你最近在折腾AI助手、智能问答系统，或者哪怕只是深度用过几款AI编程工具，应该都遇到过这个场景：同样的背景信息，你得反复跟它说，稍微复杂一点的任务，它就开始答非所问。这个问题的根源，就是上下文（context）没管好。今天想分享的这个项目，是一个叫 context-mode 的上下文管理模式——它不是某个开源库，也不绑定特定平台，而是一套我实际落地过的系统化方法，专门解决“AI怎么知道该记住什么、该忘掉什么、该从哪儿翻出旧信息来回答你”的问题。

context-mode 的核心思路很简单：把上下文当成一等公民来管理。传统做法是把所有对话历史一股脑塞给模型，而 context-mode 要做的是——主动感知、按相关性筛选、动态编排之后再注入。这样做的好处非常直接：回答准确率明显提升、token消耗下降、多轮对话不再“失忆”。这套模式适合正在做智能客服、知识库问答、AI编程助手、或者任何依赖大语言模型多轮交互场景的开发者。就算你只是日常重度使用AI工具，理解 context-mode 也能让你更清楚AI为什么有时聪明、有时犯傻。

下面我按自己这次从零到落地全过程来拆解，包括设计思路、核心原理、可复现的代码实现，以及我在实际调试中踩过的坑。整个过程不依赖特定框架，你用现成的LangChain也好，自己拼装也好，思路都能直接用。

1. 整体设计思路：为什么需要一种专门的“上下文模式”

1.1 从一次失败的原型实验说起

最早我做过一个内部用的文档问答助手，当时的架构很天真：把用户最近20轮聊天记录全部拼进prompt，然后丢给模型回答。初期demo跑起来效果还行，问题一多就露馅了——用户问“上周说的那个库存方案怎么样了”，模型完全不知道“那个”指的是什么；更常见的是用户中途切换话题，旧的10轮无关内容还在prompt里占地方，模型反而被带偏，开始回答一些莫名其妙的东西。

最惨的一次，我在prompt里塞了接近2万字的参考文档，结果模型在规定长度内没法给出关键结论，反复强调“根据提供的资料”。那一刻我意识到：上下文不是越多越好，关键是让模型在正确的时间看到正确的信息。这就是 context-mode 要解决的第一个问题——上下文的结构与时效管理。

所谓 context-mode，本质上是对输入给模型的所有信息做一次“面向当前问题”的重整理。它不是简单拼接历史，而是由系统判断：哪些信息跟当前问题相关、相关度有多高、应该以什么顺序出现、哪些信息必须丢弃。就像你给一个新同事交接工作，不是把三年来所有邮件都塞给他，而是基于他当前要解决的问题，给他一份精准的背景资料包。

1.2 context-mode的核心分层

整个模式我设计成三层，职责边界非常清晰：

• 采集层（Context Collector）：负责从多个来源抓取原始上下文，包括对话历史、外部文档、代码片段、用户画像、系统状态等。这一层只负责“收”，不做判断。
• 管理层（Context Manager）：核心层，对原始上下文做清洗、去重、评分、裁剪、排序，并维护短期记忆和长期记忆两种存储。这一层决定“留什么、丢什么”。
• 注入层（Context Injector）：把最终筛选出的上下文按模板格式化，插入到prompt的合适位置，同时生成必要的元数据（如时间戳、来源标签）。

可以把这三层理解成一个知识助理的服务流程：采集层是前台接待，把电话、邮件、文件都收进来；管理层是助理大脑，判断哪些事情重要、优先级怎么排；注入层是汇报环节，整理成一张干净的一页纸，放到老板桌上。

这种分层的最大好处是每一层都可以独立升级。比如采集层要接入新的数据源，不影响后面两层；管理层换更聪明的评分模型，采集和注入层不用动。实际开发中，这种解耦让调试成本低了很多。

1.3 方案选型：为什么用“显式上下文”而不是“全量历史”

在设计方案时，我对比了两条技术路线：

我最终选择了第二条路线，核心原因是成本。线上流量起来之后，token费用是实打实的成本，而全量历史方案在长会话场景下的token浪费极其严重。更关键的是，模型的理解能力不是“越多越好”的——当有效信息淹没在噪音里，模型的表现反而是下降的。

这个取舍背后其实是一个朴素的道理：上下文管理的本质是信息检索，而不是信息堆积。你检索得越准，模型回答得越好，花的钱越少。

2. 核心细节解析：上下文怎么“感知”和“保鲜”

2.1 上下文采集：不止记录对话历史

很多实现只记录对话历史，但 context-mode 里的“上下文”范围要大得多。我最终把采集对象分成五类：

• 显式交互上下文：用户对话历史、指令、反馈（点赞/点踩）。
• 外部文档上下文：被引用的文档片段、知识库条目、网页正文。
• 代码与结构上下文：代码仓库中的相关文件、函数定义、依赖关系。
• 用户画像上下文：用户偏好、历史行为、权限级别（对客服和推荐场景特别重要）。
• 环境上下文：当前时间、系统版本、设备信息、任务状态。

采集策略上，我用了“事件驱动 + 定时快照”的组合。事件驱动就是每次用户发消息、每次工具返回结果时都会触发一次采集入库；定时快照则保证像“当前热门问题Top10”这类随时间变化的信息能定期更新。两种方式互补，避免实时事件遗漏，也避免频繁全量抓取浪费性能。

下面是一个简化版的数据模型，我用 Python dataclass 定义：

from dataclasses import dataclass, field from typing import Optional import time @dataclass class ContextItem: item_id: str # 唯一标识 content: str # 上下文内容 source_type: str # "dialog", "doc", "code", "user_profile", "env" timestamp: float # 产生时间 score: float = 0.0 # 与当前问题的相关度，由管理层计算 metadata: dict = field(default_factory=dict) # 来源、权限、过期时间等 @dataclass class ContextWindow: items: list[ContextItem] = field(default_factory=list) max_tokens: int = 2048 # 上下文预算上限 total_tokens: int = 0 # 当前已用token估算值 def add_item(self, item: ContextItem, token_count: int): self.items.append(item) self.total_tokens += token_count

这个模型本身不复杂，但它解决了一个关键问题：让上下文每一项都有据可查。调试时看到模型回答不对，可以直接查看注入了哪些 ContextItem，而不是对着黑盒prompt猜。

2.2 相关性评判与裁剪：如何控制token爆炸

上下文采集进来之后是“原料”，不能直接给模型用。管理层要做的第一件事是给每个 ContextItem 算相关度分数。我采用了双通道评分：

• 关键词通道：用 BM25 这类经典算法，计算上下文与当前查询的词法重合度。好处是快、可解释，不依赖外部模型。
• 语义通道：对查询和上下文分别做embedding，计算余弦相似度。好处是能处理“同义不同词”的问题，比如用户问“怎么退款”，文档里写的是“取消订单并返还费用”，语义上其实是匹配的。

两个通道的分数最后做一个加权融合：

final_score = alpha * bm25_score + (1 - alpha) * semantic_score

alpha 我一开始设 0.4，后来在调试中调到 0.3——因为实测下来，语义通道在长文档场景下更稳定，而关键词通道容易把“提过某词但没有实际信息量”的片段排到前面。具体调参过程后面在第3章详细说。

筛选出候选集之后，就是预算分配。这个环节不能简单按分数从高到低取前N条，因为不同类型的上下文对回答质量的影响不是线性的。我最终用了“类别配额 + 分数排序”的组合策略：

• 对话历史最多占 20% 预算；
• 外部文档最多占 50% 预算；
• 用户画像最多占 15% 预算；
• 环境信息最多占 10%；
• 剩余 5% 留给系统指令或临时插入的信息。

这个配额的来源是我做了几组对比实验后总结的经验值。文档占比最大，因为知识类问答本来就依赖外部资料；对话历史只保留与当前问题直接相关的片段，不为了“连贯”而把旧账全翻出来。这里贴一段核心的筛选代码（简化版）：

def select_context(candidates: list[ContextItem], current_query: str, budget: int = 2048): # 1. 计算相关度 for item in candidates: item.score = fused_score(item, current_query) # 2. 按类别分组，并按分数排序 groups = defaultdict(list) for item in candidates: groups[item.source_type].append(item) for src_type, items in groups.items(): items.sort(key=lambda x: x.score, reverse=True) # 3. 按配额选择，并用token估算器控制总量 quota = {"dialog": 0.2, "doc": 0.5, "user_profile": 0.15, "env": 0.1, "other": 0.05} selected = [] used = 0 for src_type, ratio in quota.items(): limit = budget * ratio for item in groups.get(src_type, []): token_count = estimate_tokens(item.content) if used + token_count > budget: break if used_within_group + token_count > limit: continue selected.append(item) used += token_count used_within_group += token_count return selected

token估算我用的tiktoken库，具体用哪种编码取决于你的模型，但核心思想是一致的：估算要快，精确值不是必须的，误差在10%以内都能接受。

2.3 上下文保鲜与失效机制

上下文是会“过期”的。用户昨天关心的事，今天可能已经不重要了；文档的新版本发布后，旧版本再可用就是误导。所以 context-mode 里必须要有一套时效机制。我做了三层：

短期记忆（Short-term）：会话内的上下文，按滑动窗口管理，超出窗口或隔天自动清理。这里不做复杂逻辑，因为短期记忆的核心是“快”。

工作记忆（Working）：跨会话但短期有效的信息，比如用户说“我正在处理订单编号A12345的售后”，这个信息在接下来几小时内都应该被当作默认上下文。工作记忆有过期时间（默认24小时），临近过期时分数会打折扣。

长期记忆（Long-term）：跨天、跨周仍然有效的知识，比如用户偏好、项目背景、已经确认的技术决策。长期记忆需要显式写入，不能自动从对话中提取，否则会产生大量脏数据。

失效机制上，除了显式的过期时间，我还有一套“软失效”规则：如果某个 ContextItem 连续3次没有被检索命中，它的基础分数会乘一个0.8的衰减因子；连续5次未命中，不再参与候选。这套规则本质上是一个 LRU 思想，但应用在相关性评判上而非存储容量上。这样做的好处是：系统会逐渐“忘掉”那些不再重要的信息，但又不会彻底删除，万一哪天又相关了，还能从原始存储里捞回来。

3. 实操过程：从零实现一个context-mode模块

3.1 准备工作与环境搭建

这个模块我用的技术栈偏向轻量：Python 3.10 + FastAPI（用来跑服务接口）+ SQLite（存储原始上下文）+ Redis（缓存短期上下文，可选），外部依赖主要是tiktoken和sentence-transformers。如果你不想引入重模型，也可以只用 BM25 关键词通道，效果在垂直领域其实也不差。

目录结构我按分层思想组织：

context_mode/ ├── collector/ │ ├── dialog_collector.py │ ├── doc_collector.py │ └── env_collector.py ├── manager/ │ ├── scorer.py │ ├── selector.py │ └── memory.py ├── injector/ │ └── prompt_builder.py ├── models.py └── api.py

这里的核心依赖并不是某个框架，而是我前面提到的数据模型 — ContextItem 和 ContextWindow。所有模块都围绕这两个数据结构工作，接口自然清楚。

3.2 核心流程实现：采集、评分、注入

整个流程跑起来之后，处理一次用户请求大概分为三步。

第一步：采集。用户发来问题，我先把它包装成一个 ContextItem（source_type="dialog"），同时从 Redis 里取当前会话的短期记忆、从 SQLite 里查长期记忆和外部文档。这个环节没必要把所有历史都查出来，先用一个粗粒度的元信息过滤，比如只看最近N天的文档、当前项目下的代码文件，减少后续评分的计算量。

def collect(query: str, user_id: str, session_id: str) -> list[ContextItem]: items = [] # 当前问题本身 items.append(ContextItem( item_id=f"q_{time.time()}", content=query, source_type="dialog", timestamp=time.time() )) # 短期记忆 items.extend(memory.get_short(user_id, session_id, limit=50)) # 长期记忆：按用户ID和当前会话主题粗筛 items.extend(memory.get_long(user_id, limit=50)) # 外部文档：从知识库索引中粗筛 items.extend(doc_index.search(query, top_k=20)) return items

第二步：评分与选择。调用第2章说的双通道评分，然后做配额裁剪。这个环节是整个 context-mode 的心脏，也是最耗CPU的步骤。如果走语义通道，embedding 计算会占比较大，所以我加了缓存——同一个文档片段对不同查询的 embedding 是固定的，提前算好存起来，查询时直接读缓存。实测下来，加了缓存之后的P95延迟降低了40%左右。

第三步：注入。注入不是简单地把筛选后的内容拼到prompt后面。我用了结构化的注入模板，让模型知道“哪段是参考资料、哪段是历史对话、当前问题是什么”，这样模型在推理时能正确区分信息来源。下面是一个实际使用的prompt模板：

你是一个智能助手，请基于以下上下文回答用户最新问题。 【用户画像】 {user_profile_context} 【相关文档片段】 {doc_context} 【历史对话（按时间排序）】 {dialog_context} 【环境信息】 {env_context} 【当前用户问题】 {user_query} 要求： 1. 优先参考【相关文档片段】回答，如果文档中无相关信息，明确说明“根据现有资料无法确认”。 2. 不要重复历史对话中已经说过的内容。 3. 回答控制在合理长度，如无必要不要列点。

注入层唯一要做好的就是格式化和排序，把context窗口里的内容按模板填进去。这个模板看起来简单，但每个字段的占位顺序我是试过很多版本的——文档片段放在对话历史之前，模型引用文档的概率会更高；用户画像放最前面，模型的语气会更贴合用户习惯。

3.3 效果验证与调优

我搭了一套有200多个问题的测试集来验证，分布大概是：单轮文档问答（40%）、多轮追问（30%）、跨会话召回（20%）、闲聊与无关问题（10%）。初始版本跑下来，结果还算有料，但问题也不少。

第一版效果指标：

看到这个结果之后，我做了几轮针对性优化。

第一轮优化调整了融合权重 alpha，从默认0.5改到0.3。这个改动主要影响文档问答场景——原本关键词评分权重太高，导致一些“字面匹配但语义不相关”的文档片段排到前面。调整后准确率提高到82%。这一轮也让我意识到，语义通道在这个场景下确实更可靠。

第二轮优化重点解决了多轮追问的代词指代问题。我发现问题不在评分，而在历史对话的排序和截断策略——最相关的一句历史对话可能因为位置靠后而被截掉了。修改策略为“不按时间排序，而按相关度排序，但保留相邻句的原始顺序”，也就是把命中的历史对话片段连同它的前后一两句一起搬进来，而不是只搬孤立的一句。多轮追问准确率升到73%。

第三轮优化针对跨会话召回。长期记忆的失效因子太激进，导致一些重要背景信息被“遗忘”。我把衰减因子从0.8放宽到0.95，视觉上变化不大，但实际效果明显——跨会话召回准确率从52%升到69%。

最终版本指标：

token消耗对比最初的“全量历史”方案，同场景下平均下降了约40%，这个收益在线上流量放大后非常可观。

4. 常见问题与排查技巧实录

4.1 上下文溢出：总提示超长怎么办

最直观的问题就是prompt太长，调用模型接口直接报超长错误，或者被系统截断后丢失关键信息。我的排查经验是：不要只调大max_tokens，那是治标不治本。先用日志把每次注入的ContextWindow打出来，看看token都花在了哪里——很多时候你会发现，某个在for循环里塞进来的文档片段，每条都占了2000+token。

解决办法有两个方向。第一是降低配额：把所有上下文类型的预算整体下调，让系统更“克制”。第二是换细粒度切分：把长文档按段落而不是按整篇来作为ContextItem，这样评分时能更精准地选中最相关的那一段，而不是把整篇文档都拉进来。我实测过，段落级切分后token用量直接降了31%，准确率反而升了4%。

4.2 上下文污染：模型被无关信息带偏

有时候上下文窗口明明在预算内，但模型回答还是偏了。打开注入日志一看，出现了一个高分但明显与当前问题无关的ContextItem——这就是上下文污染。污染来源通常是两类：一类是用户画像里积累了错误的历史推断，比如用户在某次对话中提了一句“我不喜欢小米”，系统就把所有小米产品相关的回答都默认排斥；另一类是外部文档索引命中错误，把标题含关键词但内容无关的章节拉了进来。

排查污染问题，我强烈建议在日志中记录“每个ContextItem的命中理由”——是哪个关键词命中的、语义分数是多少。有了这个信息，你就能快速定位是哪一路召回出了问题。修复上，用户画像类的污染我用“置信度阈值”解决，低于阈值的信息不进注入列表；文档类的污染则靠优化索引的粗筛条件，保证章节标题和内容双重匹配。

4.3 调试黑盒：如何看清“模型到底看到了什么”

做prompt工程或者说上下文管理，最怕的就是“猜”。模型返回一个错误答案，你根本不知道它是基于什么逻辑得出这个结论的。我的做法是：在开发环境打开“上下文dump模式”——每次请求完成后，把完整注入的ContextWindow、评分明细和最终回答都存到一个JSON文件里。

{ "request_id": "8f8a1c02...", "query": "我们数据库连接池为什么老是打满", "context_items": [ { "item_id": "doc_231", "source": "knowledge_base", "score": 0.87, "content_preview": "连接池最大连接数配置为...", "reason": "keyword:hikari, semantic:0.82" } ], "final_prompt": ".....", "answer": "你的连接池打满很可能是因为..." }

有了这个dump文件，复现问题时直接搜索request_id，就能还原模型当时看到的所有内容。这个方法大大减少了“盲调”的时间。我还习惯在每次修改评分或裁剪逻辑之后，跑到这组case上看前后diff，防止某个改动影响了其他场景。

4.4 问题速查表

这套速查表我是基于自己的场景整理的，不同项目不一定每个都适用，但排查路径是通用的——先确认注入层到底注入了什么、再检查组件的过滤逻辑、最后才是调prompt内容。顺序不要反，否则效率极低。

5. 扩展应用：context-mode还能用在哪些地方

5.1 AI编程助手中的上下文管理模式

在编程场景里，context-mode 的上下文范围更广也更结构化。代码不是纯文本，它有函数、类、变量、依赖关系、git历史、issue链接。如果把“当前光标所在文件”作为唯一上下文，模型经常会写出调用了一个不存在的方法；如果把整个代码库塞进去，又超过了任何模型的上下文上限。

我见过一个有效的做法是：把 context-mode 里的文档切分替换为“符号级切分”——按函数和类为单位建立索引，并用调用关系图来决定哪些符号需要一起进入上下文窗口。比如用户问“为什么登录接口一直报超时”，系统会把登录接口函数、它调用的依赖函数、相关的配置文件片段一起拉进来，按调用顺序排列，模型就能更准确地进行代码级推理。这就是 context-mode 在代码场景下的变体：采集层从文件系统换成AST解析器，管理层从关键词评分换成调用链重要性评分。

5.2 客服机器人与智能知识库

客服机器人是 context-mode 受益最明显的场景。没有上下文管理时，用户说“我上次问过退货的事情了”，机器人一脸茫然；有了长期记忆，它知道用户上次的问题是“退货包不包邮”，以及当时的答复是什么。

在客服场景中，上下文不只是对话历史，还包括用户当前的订单状态、物流轨迹、会员等级、是否有未完结工单。这些信息必须在注入层按优先级整理——用户问“我的货到哪了”时，当前订单的物流信息优先级要远高于用户画像里的“喜欢用微信支付”这类长期记忆。context-mode 的“类别配额”思路在这里稍加调整就能应对：按业务字段维度而不是文档类型来分配预算。

5.3 自动化工作流里的隐式上下文

还有一个我最近在探索的方向：把 context-mode 应用到自动化工作流中，作为不同工具之间的“隐式上下文传递层”。比如一个自动生成周报的工作流，需要整合本周的代码提交、会议记录、任务进度，单看每一份数据都是孤立的。context-mode 可以扮演一个“总装车间”——把各系统采集到的信息统一做一次相关性评分，再按模板注入到写给下游的提示中，让下游agent不用面对杂乱无章的原始数据。

这个方向还在早期，但它揭示了一个趋势：上下文管理的边界正在从“提示词工程”扩展到“系统与系统之间的信息编排”。未来的agent与agent协作，可能不再需要每次把大量数据传来传去，而是共享同一个带评分的上下文窗口。到那时候，context-mode 的采集、管理、注入三层结构，或许会成为一个被广泛接受的基础设施模式。

回到项目本身，当初我做这个模块时，最庆幸的是没有急着堆功能，而是先把“上下文是什么、怎么评分、怎么保鲜”这几个问题想清楚了。它不复杂，难点在于得克制住“塞更多信息”的本能。最后再分享一个小技巧：每次上线调参前，先跑一遍回归测试，保证新改动没有破坏已经调好的场景。上下文管理这个领域，牵一发动全身，回归测试是最便宜的安全网。