AI应用上下文管理实战：五种模式设计与Token优化策略

花了大半年时间做AI应用，前后迭代了十几版，最后发现真正决定产品体验上限的，往往不是模型选得多强、Prompt写得有多花哨，而是**上下文（Context）**这条暗线有没有理顺。项目代号“context-mode”，说白了就是一套围绕大模型上下文的管理模式。这篇文章不聊空泛的概念，直接把我在项目里落地的方案、踩过的坑、调参的经验全部掰开揉碎讲清楚，适合正在做 AI Agent、智能客服、知识库问答，或者任何涉及多轮对话场景的开发者参考。

1. context-mode是什么：一次关于“记忆”的架构选型

1.1 从一次线上事故说起

项目上线后的第三周，我们收到了一堆用户投诉：对话超过二十轮后，AI开始“失忆”，把用户两轮前提过的信息忘得一干二净，甚至开始重复问同样的问题。排查了很久，问题不复杂——我们把所有的对话历史一股脑塞进 Prompt，Token 超限后直接截断，结果最前面的关键信息被丢掉了。

这个问题的本质，是没有一套明确的上下文管理模式。模型每请求一次都是“无状态”的，它的记忆完全靠你在请求里带了什么。只带最近几轮，它会忘掉开头用户交代的背景；全量带上，成本飙升、响应变慢，还可能超出窗口导致报错。所以所谓“context-mode”，就是你要显式地决策：每轮请求里，到底该让模型看到哪些信息，用什么样的结构组织这些信息，超限时又该怎么降级。

从架构上讲，这套模式可以分为四个核心模块：上下文采集、上下文存储、上下文组装、上下文压缩。我在项目里把它们做成了一个独立的服务，不耦合具体业务逻辑，这样任何需要对话能力的模块都能接入。

1.2 为什么单独为“上下文”立一个模式

很多团队一开始都不重视上下文管理，觉得“把history数组传进去不就好了”。但一旦产品进入真实使用，你会发现几个躲不掉的问题。

首先是Token预算问题。GPT-4级别的模型，即便使用128K窗口版本，真正高质量处理的输入也就是几十K Token。而一个活跃用户一天对话几百轮，历史消息早就能撑爆窗口。再叠加系统提示词、检索到的参考文档、工具返回结果，输入空间极其紧张。

其次是信息层次问题。用户的对话历史里，不是所有内容都值得让模型看到。寒暄、重复确认、无效指令，这些信息不仅浪费Token，还会干扰模型的注意力——上一轮用户随口说的“算了不重要”，模型可能真的把它当作需求去执行。所以我们需要的不是“所有历史”，而是“值得让模型知道的信息”。

最后是成本与延迟问题。每多传一千个Token，请求的延迟就会显著增加，成本则成比例上升。如果你的应用日请求量是几十万，这里随便优化一点，省下的都是真金白银。把上下文管理从“随手处理”提升为“核心模式”，本质上就是在为这些维度做工程化收敛。

2. 五种上下文模式的设计与取舍

2.1 零上下文模式：最简单但最容易误用

零上下文模式就是每次请求都完全独立，不带任何历史，只依靠单轮Prompt。它最适合那些“翻译一句话”“生成一段文案”“单张图片识别”这类天然无状态的任务。好处是无论多少轮，响应质量和成本都完全可预测，绝不出现上下文污染。

但很多人误用了这个模式——在一个对话产品里，用户明明说“刚才说的那个方案，再帮我细化一下”，结果系统没有任何历史，模型完全不知道“那个方案”是什么。这种体验可以说是灾难级的。所以我的经验是：零上下文模式只适用于“请求本身就包含全部必要信息”的场景，比如通过接口传入完整参数，而不是靠模型“记住”任何东西。

在实现上，零上下文模式意味着服务端不需要保存任何会话状态，架构最清爽，也最容易做水平扩展。如果你的业务允许，尽量把更多的任务设计成无状态请求，这是降本增效的第一步。

2.2 全量上下文模式：小规模场景的“暴力解法”

全量模式就是把从会话开始到当前轮的所有对话消息，全量拼入 Prompt 传给模型。它的实现最简单，信息也最完整，模型不会因为缺上下文而出错。我最早的原型就是这个方案，确实省心。

但这种模式有几道硬伤，几乎无法回避：

• Token 超限：窗口是固定的，对话是无限增长的，总有一刻会爆掉。128K窗口看着大，遇到频繁工具调用、大文档检索，几轮就满了。
• 成本非线性上涨：每轮请求都带着全部历史，随着对话增长，单轮成本越来越高，最终高到离谱。
• 信噪比下降：大量无关消息淹没了关键信息，模型反而更容易“迷失重点”，表现为回答偏离主题、重复提问。

所以全量模式只适合内部调试、短会话（不超过10轮）或低并发场景，不建议直接用在正式的多轮对话产品里。我甚至建议，即使要用，也一定要设一个硬性的轮数上限，超过之后强制切换到摘要或滑窗模式。

2.3 滑动窗口模式：兼顾效率与实现的均衡解

滑动窗口模式的核心思路很简单：只保留最近N轮对话，更早的一律丢弃。比如配置窗口大小为10轮，那么第1轮到第10轮结束后，第11轮的请求就只带第2轮到第11轮的消息，始终保持最近10轮。

这个模式的优点非常突出：

• 实现成本极低，只维护一个固定长度的队列；
• Token消耗稳定，不会因为会话变长而无限增长；
• 模型始终能看到相对新鲜的上下文，对多轮任务的连续性有基本保障。

但它的代价也显而易见——窗口之外的信息被永久丢弃。用户的初始意图、几天前提过的偏好、某次操作的历史记录，都会从模型视野中消失。所以在我的实现里，滑动窗口模式永远不会单独使用，而是作为基础层，向上叠加摘要模式和检索模式。如果你的应用场景是“即时但不需要长期记忆”的对话（比如一次售后会话），滑窗是一个足够好的起点。

2.4 摘要模式：用“浓缩记忆”对抗窗口限制

一旦对话超过窗口上限，与其粗暴截断，不如做信息蒸馏：把早期对话通过模型生成一段结构化的摘要，作为后续请求中的固定前缀。这样既保留了关键背景信息，又控制了Token量。这是项目里最核心的压缩手段，也是“context-mode”能真正在长会话场景落地的原因。

具体实现是双层的结构：

• 长期摘要：维护一份全局摘要，每次触发压缩时，把当前摘要和新增对话一起让模型重新生成一份更完整的摘要。
• 滚动摘要：当单次超限时，用当前摘要替换最老的一部分消息，保证整体仍在窗口内。

实际写代码时，摘要的触发条件不要只盯着“是否超限”，还要考虑信息的有效期。比如用户昨天聊过的事情，今天再提起来，模型如果没有摘要就无法回答。所以更强的做法是引入时间衰减：对每一条历史消息设定权重，时间越近权重越高，超过窗口时优先丢弃低权重的消息，而高权重的关键信息即使较老也会被摘录取代而不是直接删除。

2.5 结构化上下文模式：让关键信息“持久化”下来

在做的过程中，我逐渐意识到：对话历史只是上下文的一部分，还有很多其他信息同等重要，比如用户实名信息、偏好设置、正在操作的任务状态、业务规则等。于是我把上下文拆成了“会话历史、持久化用户画像、当前任务状态”三层结构。

这也就是结构化上下文模式的核心思路：不要把所有信息都塞进对话文本里，而是把它们组织成结构化的数据结构，在请求组装时动态注入。比如用户是会员，这个信息在注册时就存在用户表里，下次请求自动拼入“用户等级：VIP”，模型自然知道怎么处理。

实现上我维护了一个ContextState对象，分三个字段：profile存用户属性，task存当前任务执行状态，history存对话记录。每次组装Prompt时，按固定模板把这些字段填充进去。这个模式在接入Agent工具调用时价值尤其大——模型能通过状态对象明确知道“当前已经完成了哪几步、还差哪几步”，而不是靠文本反复推理。

3. 实操：从零实现一个可用的上下文管理器

3.1 整体架构与数据模型

我最终采用的不是一个单一模式，而是动态混合模式：基础层用滑动窗口保证响应时效，叠加摘要层完成长程记忆的沉淀，再根据实时字段判断是否需要临时进入结构化模式。这样既能控制成本，也能保证体验。下面给出核心的数据结构和类设计。

from dataclasses import dataclass, field from typing import Optional, Callable import time @dataclass class Message: role: str # "user" / "assistant" / "system" / "tool" content: str timestamp: float = field(default_factory=time.time) @dataclass class ContextState: profile: dict = field(default_factory=dict) # 用户画像 task_state: dict = field(default_factory=dict) # 当前任务状态 history: list = field(default_factory=list) # 对话历史 class ContextManager: def __init__(self, max_tokens=6000, history_limit=20): self.max_tokens = max_tokens self.history_limit = history_limit self.summary = "" # 长期摘要缓存 self.state = ContextState() def add_message(self, role: str, content: str): self.state.history.append(Message(role=role, content=content)) self._trim_history() def _trim_history(self): # 滑动窗口的基本裁剪 if len(self.state.history) > self.history_limit: overflow = len(self.state.history) - self.history_limit # 把超出的消息先交给摘要逻辑处理 self._condense_messages(self.state.history[:overflow]) self.state.history = self.state.history[overflow:]

这个类看起来很简单，但它已经是整个模式最小的核心了。三个关键点值得解释：max_tokens是组装Prompt时的硬上限，history_limit控制滑动窗口的消息条数，summary保存跨轮次的关键记忆。所有消息都带时间戳，为后续的“时间衰减策略”留好了扩展位。

3.2 上下文组装：把“状态”渲染成模型能理解的Prompt

组装阶段的任务，是把ContextState翻译成模型输入。我用的模板大致如下：先放系统指令，再放用户画像和任务状态（结构化上下文），接着放长期摘要，最后才是最近的会话历史。这样模型在生成每一步时，背景信息永远在最前面，不容易被后面的长文本冲淡。

def build_prompt(self, system_prompt: str, user_input: str) -> list[dict]: messages = [{"role": "system", "content": system_prompt}] if self.state.profile: messages.append({ "role": "system", "content": "用户画像：" + self._dict_to_text(self.state.profile) }) if self.state.task_state: messages.append({ "role": "system", "content": "任务状态：" + self._dict_to_text(self.state.task_state) }) if self.summary: messages.append({ "role": "system", "content": "历史摘要：" + self.summary }) for msg in self.state.history: messages.append({"role": msg.role, "content": msg.content}) messages.append({"role": "user", "content": user_input}) return messages

注意这里一个细节：summary我放在history之前，是作为“全局背景”存在的；而user_input永远放在最后，保证模型最先关注最新的指令。消息数组的排列顺序直接影响注意力分布，如果你在项目里发现模型“看不到”某些信息，先检查它们是不是被淹没在了中段位置。

3.3 Token估算与压缩阈值计算

组装完Prompt后，不能盲目发给模型，必须先做Token估算。我一直用tiktoken库来做这件事，比简单按字符数估算准确得多。

import tiktoken encoding = tiktoken.get_encoding("cl100k_base") def count_tokens(text: str) -> int: return len(encoding.encode(text)) def is_exceeding_limit(messages: list[dict], max_tokens: int) -> bool: total = 0 for m in messages: # 每条消息额外+4 token，OpenAI对chat格式的固有开销 total += count_tokens(m["content"]) + 4 total += 2 # 会话层级的辅助token return total > max_tokens

估算的目的是触发压缩。我在每次附加新消息前都会估算一次，如果超过max_tokens的88%，就进入压缩流程。为什么是88%而不是100%？因为要给模型回复预留空间——最大输出Token数如果设置为1024，那总预算里就要先扣掉这部分，否则容易出现“请求成功但响应被截断”的情况。这个比例是压了很多次线上问题后才定下来的。

3.4 摘要压缩算法的完整实现

摘要压缩的核心是一个_condense_messages方法。它接收一批旧消息，调用模型生成摘要，并把摘要合并到全局summary里。这里唯一需要注意的是：摘要不能无限膨胀，否则这就是把滑窗问题换了个形式重演。所以每次生成摘要后，还要对summary本身做一次Token检查，超过阈值就再压缩一次（递归式摘要）。

def _condense_messages(self, messages: list[Message]): if not messages: return text = "\n".join(f"{m.role}: {m.content}" for m in messages) summarize_prompt = ( "请把下面这段对话压缩成简洁的中文摘要，保留所有关键信息，" "包括用户明确的偏好、任务要求、已确认的决策。不超过300字。\n\n" + text ) new_summary = call_model([{"role": "user", "content": summarize_prompt}]) if self.summary: self.summary = call_model([{ "role": "user", "content": f"以下是已有摘要：\n{self.summary}\n\n以下是最新补充对话的摘要：\n{new_summary}\n\n请合并成一份连贯的总摘要。" }]) else: self.summary = new_summary if count_tokens(self.summary) > 500: # 摘要自身过长，二次压缩 self.summary = call_model([{ "role": "user", "content": f"请把以下摘要进一步压缩到200字以内，只保留最关键的事实：\n{self.summary}" }])

这个实现里有一个非常容易被忽略的技巧：摘要合并时，一定要把“已有摘要”和“新摘要”都传给模型，而不是只传新摘要。最开始我图省事，只对新对话做摘要再追加字符串拼接，结果格式混乱、逻辑断层。让模型重新生成一份连贯的总摘要，虽然多花一次调用，但长期的准确性收益远大于成本。

3.5 自动模式选择：按场景切换上下文策略

最后一个值得分享的实操点，是我在项目中做的“模式自动路由”。不把所有逻辑都写死，而是在每次请求时，根据几个关键指标来动态决定用哪种模式：

1. 如果会话轮数小于3，直接全量模式，不引入摘要噪声；
2. 如果轮数在3到15之间，滑窗模式+结构化上下文，保证新鲜度；
3. 如果轮数超过15，启用摘要模式，并且把滑窗长度降低到10轮；
4. 如果当前任务状态字段变化频繁（比如连续多次工具调用），优先保证任务状态的注入，而非增加历史消息。

def route_mode(self) -> str: rounds = len(self.state.history) if rounds < 3: return "full" elif rounds <= 15: return "sliding" else: return "summary"

这里的阈值不是拍脑袋定的，而是根据模型的“遗忘曲线”测出来的。我在测试集里对比了不同窗口长度下模型的召回率，发现超过15轮后，即使把历史全部塞进去，模型对早期信息的利用率也在明显下降。与其无效占用Token，不如把这些信息压缩成摘要，反而提升准确性。

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

4.1 上下文“串味”：模型把旧对话当成当前指令

这是多轮对话里最让人头疼的问题。用户第一轮说“帮我写一份合同”，后面聊到别的，十分钟后又回来说“改一下第三条”，模型可能真的去改了第一轮的合同——如果你没有显式区分哪条信息是当前任务，模型自己会乱猜。

我的排查方法是：在组装Prompt前，打印当前ContextState中的task_state字段，看看它是否被旧会话覆盖了。这个问题的根源，往往是用户在对话中途换了主题，而task_state没有跟着更新。解决思路是增加一个“意图漂移检测”：当新输入与当前任务无关时，清空任务状态，开启新任务上下文，而不是把新话题的内容继续叠加到旧任务上。

4.2 Token超限但就是不报错

有一种隐蔽的故障：请求没有报错，但模型回答质量断崖下降。打开日志一看，才发现历史消息里混入了好几轮工具返回的长JSON，单条消息就有几千Token，窗口早就被撑爆了，系统自动截断了末尾消息——可会话中间还有很多有价值的上下文，直接全丢了。

这个问题告诉我们两件事：第一，工具返回值必须单独做摘要，不能原样塞进历史；第二，裁剪逻辑不能只从队首丢消息，要按权重判断。我给每条消息加了一个importance字段，工具调用返回的消息默认降低权重，用户明确强调的信息手动抬高权重。裁剪时优先丢低权重消息，再丢最老消息，这样能将信息损失降到最低。

4.3 摘要模式下的“事实漂移”

摘要模式用久了，我注意到一个现象：模型对用户初始意图的记忆，会随着摘要的不断压缩而逐渐扭曲。比如用户最初说“预算不超过5000”，经两次摘要压缩后变成了“预算在5000左右”，再到后来变成了“预算可以到5000以上”。这就是所谓的事实漂移。

应对的方案，是给关键约束做“固化”。在写入摘要时，不允许模型自由改写这些数据型的事实。我会在摘要Prompt里强制规定：“所有数字、日期、金额、名称必须原样保留，不得修改，如有不确定必须标注”。更进一步，我会把这类硬约束同步存放一份在profile或task_state中，摘要只是给模型看的文本，真正的一致性校验靠结构化字段来兜底。

4.4 Prompt长度与推理延迟的平衡

很多人只关心窗口上限，忽略了上下文长度对延迟的影响。实测下来，当输入Token从2K涨到10K时，在某些模型上，首Token时间会翻倍以上。所以优化上下文模式，不只是省钱，也是在救响应速度。

我在项目里加了一个“Token预算总控”，它按照比例分配给四个部分：系统提示词占15%、结构化上下文占25%、摘要占20%、近期历史占40%。超出预算时，优先压缩近期历史（把20轮压成10轮），再去考虑减少结构化上下文里非必要的字段。这个预算比例不是固定的，你可以根据自己场景调整，但有了总控意识，你的上下文管理才算真正闭环。

4.5 多用户隔离与会话复用

最后一个坑，是多会话场景下的上下文串线。我在开发初期为了图方便，用一个全局列表模拟了所有用户的对话记录，测到第三个用户时就彻底乱了。后来把ContextState改成以session_id为Key的字典存储，并加了一层超时清理机制，才算稳定下来。

class SessionStore: def __init__(self, ttl_seconds=3600): self.sessions: dict[str, ContextState] = {} self.ttl = ttl_seconds def get_or_create(self, session_id: str) -> ContextState: now = time.time() if session_id not in self.sessions: self.sessions[session_id] = ContextState() # 过期清理 self.sessions.pop(session_id, None) # placeholder return self.sessions[session_id] def cleanup(self): expired = [sid for sid, state in self.sessions.items() if time.time() - state.history[-1].timestamp > self.ttl] for sid in expired: del self.sessions[sid]

这个清理函数很关键。不用的会话如果不释放，内存占用会持续上涨，存储成本也会让整体方案变得不可规模化。按会话存活时间做TTL清理，是最简单的兜底策略。

5. 模式评估：什么样的场景该选什么模式

为了让你对照自己的业务快速选型，我把五种模式整理成了一张对比表：

从我的实战经验看，大多数生产级应用最终都会走到“滑窗+摘要+结构化”的混合形态。单独一种模式很难同时满足“信息不丢、成本可控、响应快”这三个目标。混合模式的复杂度确实高一些，但它换来的是你在用户体量增长后，不需要推翻重来。很多团队一开始贪图简单，全量模式上线，做到几千用户就得重写对话模块，这个迁移成本远比一开始搭建上下文体系要高。

另一个很深的体会是：上下文模式是产品形态驱动出来的，不是算法驱动出来的。你需要先想清楚，产品里用户是以什么样的方式和AI长期互动的，是单次问答、连续对话，还是一个持续数天的项目协作？这个问题的答案，直接决定了你的上下文管理策略。不要在没有明确用户行为画像时，盲目追求“长上下文模型能搞定一切”，128K窗口也是要成本的。

6. 后续演进：从上下文模式走向上下文工程

项目做完了，但我觉得这个方向其实还有很大的延展空间。“context-mode”只是第一步，解决的是“怎么管”，下一步要解决的是“怎么让模型真正用好”。

首推的方向是自动摘要分层：不只做一版摘要，而是做多级摘要（对话级摘要、主题级摘要、用户级摘要），在组装时按需动态调用。比如用户问“我上周问过的那件事”，系统先查主题级摘要，定位到相关对话，再取出那一段具体内容拼进Prompt——这比把所有摘要都塞进去要精准得多。

另一个值得尝试的方向是上下文检索增强：为历史对话建立向量索引，只检索与当前输入最相关的几条历史消息，动态加入Prompt。这个方案比摘要分层更进一步，能处理超长周期的记忆，但对基础设施的要求也更高，需要维护向量数据库和Embedding流水线。

就我自己而言，下一步会先把多级摘要和向量检索融合起来：先用摘要层级快速定位可能相关的对话区间，再用向量检索精确命中关键内容，最后把命中的原文片段和摘要一起注入Prompt。这套组合拳打下来，理论上可以把模型的有效记忆窗口从“几十轮”拉到“几个月”，而Token开销几乎不涨。

最后再分享一个小的实际心得：你在实现这些复杂功能之前，先在本地把“组装后的Prompt”完整打印出来看几遍，你就知道上下文管理哪里容易出问题了。每一次模型表现不对，先Debug Prompt，再Debug模型逻辑。上下文模式的本质不是玄学，就是扎扎实实的工程问题，理顺了它，后面的Agent、复杂任务拆解都会顺很多。