AI 后端上下文存储：会话历史不是简单追加
一、上下文会变成后端状态
大模型应用看起来是一次请求一次回答，但只要支持多轮对话、文件分析、任务继续执行，上下文就会变成后端状态。很多系统最初把会话历史简单追加到数据库，等数据量、成本和隐私问题出现时，才发现上下文存储不是日志表那么简单。
会话历史不是简单追加。它要支持检索、裁剪、隔离、审计和删除。
二、先拆上下文类型
flowchart TD A[上下文] --> B[用户消息] A --> C[模型回答] A --> D[工具调用] A --> E[文件摘要] A --> F[系统决策]不同上下文的保存策略不同。用户消息涉及隐私，工具调用涉及审计，文件摘要涉及版本，系统决策涉及回放。全部混成一列 JSON，后续治理会很痛苦。
context_store: user_message: encrypted model_answer: retained tool_call: audited file_summary: versioned system_prompt: hashed分类清楚，才能制定生命周期。
三、上下文要有裁剪策略
模型上下文窗口有限，不能无限塞历史。后端需要决定哪些内容进入下一次请求，哪些只保留在存储中。常见策略包括最近 N 轮、摘要压缩、重要事件保留和检索补充。
record ContextWindow( List<Message> recentMessages, List<String> pinnedFacts, String conversationSummary ) {}裁剪不能只按长度，还要按任务语义。用户明确指定的约束、工具执行结果、失败原因，比闲聊式历史更重要。
四、隔离和删除不能后补
多租户系统里，上下文必须按租户、用户、会话隔离。删除账号、撤回文件授权、清理敏感内容时，要能定位并处理相关上下文。
context_isolation: tenant_id: required user_id: required conversation_id: required source_resource_id: optional如果上下文引用了文件、知识库或外部系统结果，还要保存来源关系。文件被删除后，相关摘要是否还能使用，必须有规则。
最后，上下文存储要进入观测体系。每个会话平均上下文大小、裁剪率、检索命中率、存储成本，都应该可见。否则成本会悄悄长成架构问题。
还要设计读写路径。用户发送消息时，原始消息、检索片段、模型回答和工具结果不一定要同步写入同一张表。核心链路应尽量短，体积大的上下文可以异步归档，避免一次对话请求被存储系统拖慢。
context_write_path: critical_message: sync_write large_tool_result: async_archive vector_summary: async_index上下文还要支持审计回放。线上出现错误回答时，后端需要知道当时拼给模型的上下文窗口是什么，而不是只看到数据库里保存的一堆历史消息。请求级 prompt 快照、检索命中和裁剪原因都应该能追溯。
最后，压缩摘要要谨慎。摘要可以省 token，但摘要错误会把后续对话带偏。重要事实最好有原始来源引用，不能只依赖模型生成的总结。
五、总结
AI 后端上下文存储要拆分消息类型、制定裁剪策略、支持租户隔离、来源追踪和删除治理。
会话历史不是简单追加。上下文一旦成为状态，就要按后端核心数据来设计。
