最近一直在做AI应用的工程化，试了好几个方案之后最大的体会是：Prompt技巧其实没那么难学，真正决定一个应用能不能扛住长对话、高轮次、多来源资料的，是上下文管理。我为此开发了一个实验项目，名字就叫context-mode，用来统一处理大模型交互时的上下文生成、缓存、压缩和切换。context-mode不是什么新算法，它是一层很薄的策略中间件，解决的问题非常具体：同一个应用里既有单轮问答、多轮对话，又有长文档总结、知识库检索时，不能让每个业务各自写一套截断和拼装逻辑。如果你正在做AI助手、知识库问答、长文档分析这类东西，这篇文章值得看完，我会把设计取舍、关键实现、实测数据和踩过的坑全部摊开讲。
1. 为什么对话类应用需要一个统一的上下文模式层
1.1 上下文到底指的是哪些东西
很多人一说到上下文就只想到“历史消息”，但真正接入过大模型API的人都知道，送到模型里的内容是一套很杂的拼盘：系统提示词、用户当前问题、之前的多轮对话、工具返回的结果、知识库检索出来的文档片段，有时候还有视觉输入的图片描述。这些东西全部挤在一块，才有可能让模型理解“现在应该做什么”。
这里有个很朴素的工作台类比：上下文窗口是桌面，模型一次只能看到桌面上摆着的材料。桌面越大，能摆的东西越多，但桌面永远不会无限大——至少在成本上它不是无限的。摆放什么东西、旧材料什么时候收进抽屉、抽屉里的东西怎么整理，这些琐碎决定以往都散落在各业务代码里。时间一长，每个功能模块都有自己的一套“凑上下文”的办法，很多人甚至直接在调用接口前做一次字符串拼接。
1.2 没有统一管理时常见的三类混乱
我最初是在一个内部实验项目里做的相关功能，那个项目拆成了问答、总结、检索三个入口，三个月后代码就乱成一锅粥。第一类混乱是接口形态不一致：有的模块习惯传消息数组，有的模块习惯直接拼一段文本，导致后面的功能根本不知道应该按哪种风格来对接。第二类混乱是截断策略各自为政：负责问答的人把历史保留最近十轮，负责总结的人一次性把整份文档塞进去，负责检索的人拿到什么片段就放什么片段。结果同样是“上下文”这个词，在不同模块里是完全不同的东西。
第三类混乱最隐蔽，就是多轮对话和单次任务混用。有的场景应该让模型记住上上轮的修正意见，有的场景则需要模型完全不受历史影响，只盯住当前查询。可一旦所有请求都走同一条对话历史拼接逻辑，就会出现“模型突然把旧话题带回到新问题里”的奇怪行为。context-mode就是在这些混乱里出生的：它把上下文构建和调度收敛到一个公共层，业务方只声明自己希望使用哪种模式，剩下的截断、压缩、索引、注入全都由这一层接管。
1.3 这个中间层适合谁
它适合的场景很明确：你已经有一个能跑通的AI功能，但发现上下文相关的代码越来越难维护；又或者你准备同时做多个入口，想避免一开始就踩进重复逻辑的坑里。context-mode本身不依赖特定的大模型服务，也不依赖特定框架，它抽象的是一组约定：你给我一条用户查询和一段会话记录，告诉我你想用窗口、摘要、检索还是全局模式，我给你拼出一个符合预算的上下文包。如果你还没有任何AI功能，读这篇文章可能偏早；如果你已经在做相关开发，下面这几章应该能直接对口。
2. 窗口、摘要、检索与全局：四种模式的设计取舍
2.1 窗口模式：最直观，但也最容易丢关键信息
窗口模式是很多人默认的做法，逻辑非常直白：保留最近N轮对话，时间久远的消息直接扔掉。它的优点是便宜且快，不用做任何索引或摘要，特别适合那些“用户问一句、系统答一句”的任务型对话，比如查快递状态、开门禁、查询天气这类每轮相对独立的场景。
问题在于窗口的“长度”用什么衡量。如果按轮数截断，轮与轮之间长短差异会非常大。有人一说话就是五百字，有人就发一个“好的”，按轮截断在极端情况下会把一整段长文档讨论直接切成两半，模型拿到的内容残缺不全。我后来在context-mode里规定窗口模式也必须按token数预算执行，而不是按轮数，代码里维护一个滑动的消息列表，不断从头部弹出旧消息，直到整个上下文落在预算内。
窗口模式真正让人头疼的坑是“话题切换瞬间丢失关键约束”。常见的表现是：用户问完了A问题，提出了几个条件，接着跳到B问题，窗口只保留最近几轮，于是B问题背后依赖的A条件已经不在上下文中。模型回答B时完全不知道前面的约束，给出一个看似正确但实际不满足用户隐含要求的答案。所以窗口模式只推荐用在任务独立性强的场景，别指望它承担复杂的跨文档推理。在需要长时间记忆的产品里，窗口只能是最后兜底，不是最优解。
2.2 摘要模式：用信息损失换取可控长度
摘要模式解决的是“历史必须保留，但物理上放不下”的矛盾。它的基本思路是：把较早的对话递归地压成一段摘要，新对话继续以原始形式追加。比如用户已经聊了三十轮，系统可以把前二十轮压缩成“用户正在策划一场线下活动，场地定在城西，预算约两万，嘉宾名单待确认”，后十轮保留原样。
这个模式在长对话场景里表现比窗口模式好很多，因为它保留了更多语义层面的关键信息。代价也很清晰：摘要一定会丢东西。不是摘要模型能力不行，而是“压缩”这个动作本身就在做取舍，次要不重要的细节被删掉，被删掉的那部分恰恰可能在下文被用户重新提及。
我试过在两个连续摘要迭代里丢失一个关键条件。用户第一轮说“不考虑周二”，这个信息进入第一版摘要时被写成了“时间待定”；第二轮又谈了几轮时间后，系统基于已失真的摘要继续压缩，最终模型认为“周二可以”。这个错误如果在真实产品里，就是一次明显的功能事故。因此context-mode里摘要模式会额外维护一份“关键锚点”列表，把对话中出现的强约束词、实体和数值单独抽取出来，在每次生成摘要时强制拼接进去。绝不能天真地只依赖模型把整段历史压缩成一段话。
2.3 检索模式：让上下文按需进入窗口
检索模式是知识库问答的标配：不用把所有资料塞进上下文，而是先把用户问题和文档片段都转成向量，查询时先做相似度召回，把最相关的几段喂给模型。它在长文档场景里优势极其明显，理论上可以让模型使用远超单一上下文窗口的文档总量。context-mode对检索模式的做法是：一个查询进来，先做向量召回，再做一次相关性阈值过滤，最后把命中的片段拼入上下文。
这里有个经常被忽略的执行细节：检索出来的不是“越多越好”。很多人以为召回二十段比召回五段强，实测下来往往相反。模型目标集中在一个问题，如果塞进二十段来源不同、说法相近甚至互相矛盾的文本，很容易被低相关片段带偏，回答变得又长又摇摆。我在项目里给检索器加了一个“相关性截断线”，低于阈值的片段即使召回也不会进入上下文。这样做的副作用是可能漏掉有效信息，但综合效果比完全照单全收好。
检索模式还有一个隐藏成本：它依赖索引的构建质量。如果文档切片方式不合理，或者切出来的片段语义不完整，再好的检索算法也救不回来。这个模式不是“搭进去就能用”，需要配合切片策略和召回评估反复调。它适合那些用户意图明确、底层数据量大的产品，比如企业知识库、操作手册问答、政策查询，不适合开放闲聊。
2.4 全局模式：用完整视角解决高价值场景
全局模式在四者里最简单也最昂贵：把当前会话相关的全部内容一次性组装成一个超大上下文交给模型。它只适用于一种情况——项目整体数据量不大，但回答质量必须非常完整，用户愿意承担token成本。
我通常把这个模式留给两类场景：合同审查和关键设定确认。合同长但可控，全文塞进去，让模型同时对照前面和后面的条款，有没有矛盾一目了然；关键设定确认则要保留整段决策过程，避免模型在长对话后半段“忘记”前面敲定的细节。全局模式其实也承载着一个兜底功能，当前面三种模式的上下文构建结果明显不可靠，至少还有一个“全量直送”的选项能把质量拉回安全区。
全局模式的实现压力主要在API侧的窗口上限。真遇到一个几十万字的资料库，全局模式必然超窗，这时候只能做前置压缩或退回到检索模式。在我设计的架构里，全局模式更像一个声明，底层会自动检查token总量，一旦超预算就转用摘要模式构建，尽量不让用户在运行时感受到截断。
2.5 四种模式的选型思路
选型没有银弹，核心是判断“这条请求对历史完整性的依赖程度”和“底层数据量的大小”。窗口适合短平快，摘要适合长对话省钱保语义，检索适合大知识库，全局适合小体量高价值场景。最理想的状态不是让调用方硬选，而是让context-mode根据运行状态自动切换，同时允许业务显式覆盖。自动切换的逻辑我在下一章详细展开。
3. context-mode的骨架：注册表、调度器和压缩器的协作方式
3.1 整体模块划分
context-mode在代码结构上分成四个部分：调度器、模式注册表、上下文构建器和压缩器。它们的职责划分得很干净：注册表负责登记“有哪些模式可用”；调度器负责决定“本次请求用哪个模式”；构建器负责把原始材料组装成模型需要的上下文包；压缩器则是最低层的资源保障，负责让上下文长度不超过预算。
这种分层最大的好处是可替换性。我不想在业务代码里写大量if mode == "summary"这种分支，而是希望每个模式自带一套构建逻辑，注册表里按名字拿就行。这样新增一种上下文策略时不用改调度器，只要注册一个新的构建器并声明它适合什么场景即可。
3.2 注册表和模式声明
我用Python写了一个很轻量的注册表，核心逻辑类似一个字典映射。每个模式注册时提供三样东西：模式名称、接收原始参数并返回上下文包的构建函数、以及该模式的token预算上限。为了让后面的调度器能做出决策，注册时还可以额外声明一些标签，比如“适合长文档”“需要索引”“支持多轮”。
# registry.py 核心结构示例 MODES = {} def register_mode(name, *, builder, budget, tags, default=False): MODES[name] = { "builder": builder, "budget": budget, "tags": tags, "default": default, } def get_mode(name): return MODES[name]实际使用中注册几个模式非常直观：
register_mode( "window", builder=build_window_context, budget=8000, tags=["fast", "low_cost"], default=True, ) register_mode( "summary", builder=build_summary_context, budget=12000, tags=["long_conversation"], ) register_mode( "rag", builder=build_rag_context, budget=10000, tags=["need_index", "large_corpus"], ) register_mode( "global", builder=build_global_context, budget=20000, tags=["full_view", "high_quality"], )3.3 调度器如何决策
调度器不搞复杂规则，我给它设计的逻辑按照重要程度从上到下依次判断。先说结论：如果业务方在请求里显式指定了模式，就直接尊重业务方，不自动干预；如果业务方没有指定，则根据当前会话的轮数、话题变化信号、检索召回的可用性和剩余token预算来推断。
调度器里最关键的一项是“话题突变检测”。我之前在窗口模式吃亏之后，实现上增加了一个轻量判断：拿当前用户问题跟上一轮用户问题做一个相似度计算，相似度低就认为发生了话题切换。话题切换通常意味着旧上下文里的很多信息马上失效，此时自动转向检索模式或重置上下文，成功率明显高于继续沿用窗口滚动。
def resolve_mode(session, request): if request.mode is not None: return request.mode if session.has_topic_shift(request.text): return "rag" if index_available else "window" if session.tokens >= session.total_limit * 0.8: return "summary" return "global" if request.require_full_view else "window"这个话题切换检测不能做得太重，否则每个请求都要额外等待一次相似度计算。我实测用轻量文本表征模型，几百毫秒内就能完成，加上缓存后整个过程几乎无感。有了这个信号之后，窗口模式误伤历史的概率降低了非常明显。
3.4 构建器和压缩器的工作流
构建器负责把“会话记录、检索结果、系统指令”组装成一个符合当前模式定义的上下文包。比如窗口模式的构建器负责滑动截取历史，检索模式的构建器负责把召回片段和最近的对话历史合并，摘要模式的构建器负责读取压缩后的历史摘要再拼接新轮次。
压缩器放在构建器之下，作为最终防线。理论上构建器已经保证了长度，但API返回的内容可能超出预期，比如某次搜索结果特别长，或者用户一条消息就塞满了整个预算。这种情况下压缩器发挥作用，它的行为根据模式不同而变化：窗口模式直接硬截断，摘要模式做快速单轮摘要，检索模式则按相关性把最不相关的片段先移出。
def build_rag_context(query, session): chunks = retrievers.retrieve(query) filtered = [c for c in chunks if c.score >= session.threshold] recent = session.recent_turns(k=6) return assemble( system_prompt, documents(filtered), messages(recent), )这个流程看起来简单，但它真正解决了一个工程问题：各业务方不再需要知道“今天到底用哪个模型接口、上下文窗口多大、截断策略是什么”。他们只需要告诉context-mode自己的调用意图，剩下的全部由注册表、调度器、构建器和压缩器隐式完成。这让新业务接入的成本低了很多，也从源头上减少了各模块之间标准不一致的问题。
4. 跑数据后的结果：token成本、延迟与上下文质量的平衡
4.1 用token预算而不是轮数来判定
第2章提到过按轮数截断不可靠，这里再深入一点。我统计过实验项目里的真实对话，一轮最短的只有一个词，最长的一次消息抵得上十来轮普通对话。如果统一按“最近十轮”截断，同一个逻辑在不同会话上的实际输入长度能差出几倍。后来我把所有模式里的截断判断都改成预算制：每次构建上下文前，先估算替换token量，按估算值决定保留多少内容，并给模型输出预留出固定空间。
这个改动带来的直接收益是可预期的成本。测试前跑一轮长对话可能突然被一条长消息打好几倍的token费用，预算制上线后，单次请求的输入长度被限制在一个相对固定的范围内，成本曲线终于变得可控。实际线上做预算时还需要把系统提示词和可能的工具返回也算进去，不能只盯着对话历史算。
4.2 回归集与质量评估
只压缩成本不评估质量等于耍流氓。我建了一个大约两百条问题的回归集，分成三类：单轮事实问答、多轮条件约束、长文档对比审查。每次调整上下文策略后，跑一遍回归集，人工对每条回答做“完整度”和“一致性”两个维度的打分，完整度指关键信息有没有覆盖，一致性指回答跟用户提供的背景材料有没有矛盾。
这种评估方法不追求学术严谨，但它非常能发现问题。比如有一次我把窗口预算从8000提高到10000，完整度没有明显变化，一致性反而下降了，原因是多塞进去的旧对话把话题带偏了。如果不跑回归集，这种隐性退化往往出现在线上用户反馈里，那时候已经晚了。
4.3 实测数据对比
我在实验项目里用固定测试集跑了三种主要模式，得到一组有代表性的数据。窗口模式的输入token平均在1.2万左右，单轮延迟约1.8秒，完整度得分78；摘要模式输入token降到0.5万，但延迟因为摘要生成涨到2.4秒，完整度88；检索模式输入token在0.9万左右，延迟2.1秒，完整度87。全局模式由于直接塞入了完整长文档，token消耗经常超过3万，延迟最高，但完整度能到93。
| 模式 | 平均输入token | 单轮平均延迟 | 完整度得分 | 一致性得分 |
|---|---|---|---|---|
| 窗口模式 | 约12000 | 1.8秒 | 78 | 74 |
| 摘要模式 | 约5000 | 2.4秒 | 88 | 86 |
| 检索模式 | 约9000 | 2.1秒 | 87 | 85 |
| 全局模式 | 约31000 | 3.6秒 | 93 | 92 |
如果只看token消耗，摘要模式最省；如果看成本和准确率的综合收益，检索模式在知识库场景里性价比更高；如果用户明确要求“必须给我完整对照”，全局模式虽然慢但最稳。这些数据让我确信一点：没有一种模式通吃所有场景，真正合理的方案是把选择权从开发者手里部分移交给上下文策略层自动判断。
4.4 缓存与并发下的额外收益
统一上下文层还有一个容易被忽略的好处：缓存能复用。以前各模块自己拼上下文，即使同一份文档被反复引用，每次也都在重复做切片和拼接；context-mode把所有构建流程收口后，我可以在构建器外层加一层基于内容哈希的缓存。相同的文档片段、相同的主题摘要，第二次请求直接命中缓存，省掉了重复的检索和压缩耗时。
并发场景这点尤其重要。当多个会话同时触发摘要压缩时，如果没有统一层，每个会话都会各自调用压缩接口产生一份新摘要，既浪费资源又不一致。我在调度器里为摘要增加了会话标识与主题标识的组合锁，同一主题的压缩任务并发时只允许一个执行，其余等待结果。实测下来并发高峰期的压缩耗时降低接近一半，代价是代码多了一层状态管理，这部分恰好也埋进了第5章要讲的坑里。
5. 我在开发context-mode时踩过的坑
5.1 模式切换后留下了上下文残留
我最早实现自动切换时犯过一个经典错误：会话从窗口模式切换成检索模式后，没有清理之前窗口模式留下的历史。结果模型在第一次检索回答中突然说出“根据我们之前讨论的……”这种话，把旧话题带进了新任务里。这个现象在排查时非常难定位，因为请求本身没有任何异常，token量也没超限，唯一的异常就是模型“话变多了”，出现了旧上下文里的实体名。
问题根源在于上下文包本身是干净的，但我在服务层把整个会话对象原封不动传给了构建器，而构建器在检索模式下只应该取最近几轮，却仍然在系统提示词里顺带提到了整个会话的全局摘要。修法并不复杂：每次模式切换后，由调度器主动重置会话中与模式相关的缓存标记，构建器构建新的上下文包时只读取当前模式需要的字段，不读取历史全量数据。我的体会是：上下文管理难在“清理”比“堆积”更关键，模式切换必须当成一次状态重置来设计。
5.2 摘要模式反复压缩导致信息失真
摘要失真这个坑我在第2章简单提过，这里把排查链路完整写出来。现象是用户在一个四十多轮的会话里反复询问某个具体日期，但模型每次回答的日期都不对。我起初怀疑是模型能力问题，后来把摘要结果打印出来才确认，第一次摘要就把原始日期写成了“一个周末”，第二次摘要直接丢失了这个信息，后续所有回答都在错误的前提上运行。
这个问题暴露了两层设计缺陷：第一，摘要压缩没有保留关键数值和实体；第二，连续压缩没有把上一轮摘要和原始对话做交叉校验。我的修复方式是在压缩器里增加“锚点抽取”步骤，每次生成摘要前先跑一个轻量信息抽取，把日期、金额、人名、否定词等单独拎出来，作为固定片段拼到摘要前面。修改后连续压三轮测试，关键锚点的保留率从不到六成提升到九成以上。给同行一个建议：做摘要模式时，要先列出“绝对不能丢”的信息类型，而不是让模型自由发挥。
5.3 检索召回一堆相似内容反而干扰了回答
检索模式的坑更多。我第一次接入检索模式时，发现模型回答变长了，但答案里频繁出现同一份文档的多个片段，措辞相似、细节重叠。原因是向量召回只追求相似度，没有做去重和互斥，两个几乎重复的片段同时进入上下文，模型被重复信息“洗脑”，回答里翻来覆去就是那几句话。
修法是三层过滤：先按相似度阈值过滤，再按片段来源去重，最后看片段之间的信息重叠率，重叠过多的只保留一个。同时把召回数量从二十条下调到五到八条，模型回答反而更简洁准确。这个教训让我记住一个定律：召回质量比召回数量重要得多，无效上下文只会平白占用token还拉低准确率。
5.4 并发会话之间的状态串扰
上下文模式层一旦变成公共组件，就必须严肃对待状态隔离。我最初把会话管理器设计成模块级单例，结果在高并发测试里出现了一个诡异问题：A会话的摘要跑了，B会话的检索结果却拿到了A会话的索引片段。查到最后发现是检索结果的缓存key没有加入会话维度，两个会话命中了同一段缓存。
这类问题最麻烦的是它只在特定并发时序下出现，普通单请求测试完全正常。我给出的方案是：所有缓存key必须包含会话标识和模式标识；跟增量写入相关的存储不能复用单例对象；会话状态尽量放在请求上下文对象中传递，不要保存在模块全局变量里。顺带把回归集加了一条“多会话并发”用例，专门测试A、B两路请求同时跑时结果会不会交叉，保证后续改动不会再引入同类问题。
6. 一点扩展思路：让四种模式真正混合起来
说句实话，现在单纯做“一次请求选一个模式”只是第一步，真正的上下文管理应该是一个持续演化、可混合的过程。我在实验版本里试过让检索模式和摘要模式同时生效：系统先做一次检索召回，把召回的片段交给摘要生成器往下压缩，压缩结果再和原始片段一起进入上下文。这种混合方案在长文档问答里完整度更高，代价是延迟会明显增加。
对我个人来说，把context-mode这一整套逻辑单独抽出来写成工具层，比把上下文代码继续堆在业务代码里舒服得多。每次新业务要接入大模型功能时，先评估它更依赖哪种上下文类型，再决定注册新模式还是复用已有模式，至少省去了大量反复试错的时间。如果你正打算写自己的上下文管理方案，不需要一上来就做得像我这么重，可以只做窗口模式和摘要模式，先把核心接口跑通，后面等数据量上来了，再把检索和全局模式加进来。上下文管理这个事情没有一个完美解，每一层取舍都是在成本、速度和质量之间做权衡，真正重要的是让这个权衡过程可控、可观察、可回滚。
