#上下文管理专题总览

很多 AI 应用上线后，最先遇到的问题不是模型不会回答，而是模型不知道应该依赖哪些信息。

用户刚才说过的约束没有被记住，历史会话越堆越长，知识库片段和用户偏好混在一起，工具结果被旧消息覆盖，系统为了“更聪明”不断塞上下文，最后成本、延迟和错误一起上升。

上下文管理不是把所有信息都放进 prompt。它更像一次工程判断：

• 哪些信息是当前任务必须使用的？
• 哪些信息只是有帮助，但可以缺省？
• 哪些信息过期、越权或容易误导模型？
• 上下文变长以后，质量收益是否覆盖成本和延迟？
• 用户是否知道系统记住了什么、忘记了什么？
• 错误上下文导致的输出，谁来发现和纠正？

这篇总览先分析上下文问题的场景和类型，再给出从简单到复杂的方案阶梯。核心观点很简单：上下文管理的目标不是“让模型记住一切”，而是让模型在合适的任务里拿到刚好足够、可信、可控的信息。

#先看具体场景

上下文问题在不同产品里表现很不一样。

在客服助手里，用户会连续描述问题、补充订单号、纠正前一次说法。模型如果只看最新一条消息，会漏掉关键约束；如果把整段对话全部塞进去，又可能把已经被用户否定的信息当成事实。

在代码助手里，模型需要理解当前文件、相关调用、项目规范、最近报错和用户目标。上下文不足时，它会写出不符合项目约定的代码；上下文过多时，它可能被无关文件和旧方案干扰。

在销售或客户成功助手里，模型需要知道客户行业、套餐、历史沟通、当前商机阶段和联系人偏好。这里的收益来自个性化和连续性，但风险是把过期记录当成当前事实，或把一个人的偏好错误套到整个组织。

在学习产品里，模型可以根据用户水平、错题、学习目标和节奏调整讲解。记忆能明显提升体验，但如果记住了错误能力标签，后续推荐会持续偏离。

在多步骤自动化里，模型需要跟踪任务状态、工具结果、失败原因和下一步动作。这里上下文不是聊天记录，而是工作流状态。把状态只放在自然语言对话里，会让系统难以恢复、审计和回放。

这个图不是精确坐标，而是提醒团队：上下文依赖越强、错误成本越高，越不能只靠“把历史消息都带上”。

#上下文类型不是一个东西

“上下文”经常被混成一个词，但工程上至少要拆成几类。

最容易出问题的是把这些类型放进同一个自然语言 prompt，既没有来源、时间、权限，也没有优先级。模型看到一堆文字后，只能根据语言相关性猜哪些更重要。

#场景分析：上下文问题的五类失败

第一类是缺上下文。模型不知道用户说的“它”“刚才那个方案”“按上次的格式”指什么，于是回答泛化、追问过多或做错对象。

第二类是脏上下文。历史里有错误信息、用户后来纠正过的说法、过期政策、失败工具结果，模型却继续引用。

第三类是上下文冲突。用户消息、系统记录、知识库和工具返回值互相矛盾。例如用户说“我已经付款”，订单系统说“未支付”。这时不能让模型自由选择一个看起来顺的说法。

第四类是上下文过载。系统把聊天记录、文档片段、用户画像、工具日志全部塞进去，导致延迟和成本上升，模型注意力被稀释，关键约束反而被忽略。

第五类是越权上下文。模型拿到了当前用户不该看到的历史、文档或组织数据。越权上下文一旦进入 prompt，后续再要求模型“不要泄露”就太晚了。

#问题类型

上下文管理通常包含多个 AI 任务类型，不能只看“聊天历史”。

模型擅长理解语言和压缩信息，但不应该负责所有上下文治理。权限、保留策略、schema、版本、冲突优先级和审计，都应该由系统显式控制。

#收益和成本判断

上下文管理的收益很明显：

• 减少用户重复输入。
• 提升连续对话体验。
• 让回复更贴合用户、任务和业务对象。
• 支持跨会话继续工作。
• 降低模型误解指代和目标的概率。
• 让多步骤任务可恢复、可审计。

但它也会引入成本：

• 更高 token 成本和延迟。
• 上下文组装、压缩、检索和存储成本。
• 隐私、权限和数据保留风险。
• 过期或错误记忆带来的持续错误。
• 调试难度上升：同一个问题可能因为不同上下文得到不同答案。
• 评估复杂度上升：需要评估“上下文是否选对”，不只是答案是否好。

可以用四个问题快速判断是否值得升级：

低风险、短会话、用户可编辑的功能，可以先用最近消息和简单摘要。高风险、跨会话、多数据源、涉及操作的功能，则需要结构化状态、检索、记忆治理和观测。

#方案阶梯

上下文管理也应该从简单到复杂逐级升级。

第一层是最近消息窗口。适合短对话、低风险、当前轮任务。只保留最近 N 轮消息，成本最低，也最容易调试。

第二层是滑动窗口和截断策略。按照角色、时间、重要性和 token 预算保留信息。它解决窗口超限，但仍然不能理解长期目标。

第三层是对话摘要。把早期对话压缩成摘要，保留目标、事实、决定、待办和未解决问题。它适合会话较长但结构不复杂的场景。

第四层是结构化抽取。把姓名、偏好、订单号、约束、决策、任务状态等抽成字段。它适合需要稳定消费上下文的业务流程。

第五层是检索式上下文。历史会话、文档、项目记录不再全部塞入 prompt，而是按当前问题检索相关片段。它适合信息量大、跨会话、多知识源的场景。

第六层是任务状态机。对于多步骤流程，状态应该保存在系统里，而不是依赖模型从聊天记录里推断。它适合审批、工单、自动化、代码修改等任务。

第七层是记忆系统。把用户记忆、任务记忆和长期记忆分层存储、更新、过期和删除。它适合强个性化、长期协作和跨会话连续性。

第八层是 Eval + Ops。上线后需要评估上下文命中率、摘要失真率、记忆误写率、成本延迟和权限风险。没有观测，上下文系统会变成难以解释的隐形变量。

#什么时候简单策略足够

以下情况通常不用做复杂记忆系统：

• 会话短，任务在 3 到 5 轮内完成。
• 输出只是草稿、润色、总结，用户会编辑。
• 上下文只来自当前页面或当前文档。
• 错误不会进入下游系统。
• 个性化只是语气偏好，不影响事实和业务决策。
• 用户每次任务目标都不同，长期记忆价值低。

这时可以使用最近消息、明确的系统提示词、少量页面上下文和用户可见的重新生成入口。越早保持简单，越容易验证产品价值。

#什么时候需要工程方案

以下情况应该升级：

• 用户需要跨会话继续同一个任务。
• 上下文来自多个系统，需要权限过滤。
• 任务有明确状态流转和失败恢复。
• 输出会触发工具、写入数据库或影响业务流程。
• 历史信息量大，必须检索和排序。
• 记忆会影响默认选项、推荐、报价、审批或专业建议。
• 团队需要复盘“模型为什么这样回答”。

这时应该把上下文当成产品数据来设计：有 schema、来源、时间、权限、优先级、版本、日志和删除机制。

#方案选型表

#反模式

第一种反模式：把上下文窗口当数据库。

上下文窗口只是一次模型调用的输入，不是可靠存储。业务状态、用户偏好、工具结果和审批记录都应该有自己的数据模型。

第二种反模式：越长越好。

长上下文会增加成本和延迟，也会让模型更容易被无关信息干扰。好的上下文管理是选择和排序，不是堆料。

第三种反模式：摘要不分事实和推测。

摘要里写“用户对价格敏感”可能只是模型推断，不是用户明确表达。如果后续销售策略依赖这个判断，就会放大错误。

第四种反模式：记忆默认永久有效。

用户偏好、项目目标、政策和组织关系都会变化。没有过期、确认和删除机制，记忆系统会逐渐变成污染源。

第五种反模式：权限过滤放在生成之后。

敏感信息一旦进入 prompt，就已经暴露给模型链路。权限过滤必须发生在上下文检索和组装之前。

第六种反模式：没有上下文 trace。

线上回答出错时，如果不知道本次调用带了哪些消息、摘要、记忆、检索片段和工具结果，就无法判断是模型问题还是上下文问题。

#工程清单

• 场景边界：当前能力是否需要跨轮、跨会话或跨系统上下文。
• 上下文类型：最近消息、摘要、结构化状态、检索片段、记忆和工具结果是否分层。
• 来源记录：每条上下文是否有来源、时间、版本和可信度。
• 权限控制：检索和组装前是否完成用户、租户、角色和对象权限过滤。
• 冲突处理：用户输入、系统数据、知识库和记忆冲突时，优先级是否明确。
• 压缩策略：什么时候截断、摘要、抽取或检索，是否有 token 预算。
• 结构化输出：需要进入系统的数据是否有 schema、校验、重试和人工修正。
• 记忆治理：写入、更新、过期、删除、用户可见和用户可控机制是否完整。
• 可观测性：是否记录上下文包、摘要版本、检索结果、记忆命中和工具结果。
• 评估体系：是否评估上下文命中、摘要失真、记忆误写、延迟和成本。
• 安全合规：是否处理敏感信息、日志脱敏、越权检索和 prompt injection。
• 降级策略：上下文缺失、检索失败、记忆冲突时是否能追问、拒答或转人工。

#小结

上下文管理不是一个“塞多少历史”的问题，而是 AI 应用的状态、数据和权限设计问题。

低风险短任务可以从最近消息和简单摘要起步；长对话需要压缩；业务流程需要结构化抽取和状态机；大量历史和知识需要检索；长期个性化需要记忆系统；生产环境还必须补齐评估、观测和权限治理。

这个专题的后两篇会继续展开：

• 对话压缩：什么时候只保留最近消息，什么时候做摘要，什么时候做结构化抽取。
• 记忆系统：用户记忆、任务记忆、长期记忆分别带来什么收益、风险和成本。