DeepSeek 多轮对话“失忆”源于上下文管理不当：网页端依赖前端内存和 Cookie，刷新即清空；API 调用需手动传全量 messages（含 system + 有序 user/assistant 对），并显式标注持久记忆与指令切换。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
DeepSeek 的多轮对话“失忆”不是模型坏了，而是上下文没传对、没留够、没标清楚——它支持百万 token 上下文，但不会自动猜你哪句话该记住、哪段该丢。
网页端连续会话为什么一刷新就忘
官方网页靠浏览器会话 Cookie 维持对话生命周期，所有历史消息都存在前端内存里，不上传服务端。一旦刷新、关标签、点【新对话】，messages 数组就被清空，后端收不到任何历史。
- 必须用 Chrome 或 Edge 最新版，禁用无痕模式和广告拦截插件（它们会阻止 Cookie 持久化）
- 左侧“对话历史”里看到的会话标题要是手动改过的（比如“iOS 18 适配问题”），不是“新对话”——后者代表未持久化的临时会话
- 想引用前三轮提过的参数，别只说“那个 API”，要在新问题开头补一句：“如之前提到的
POST /v2/submit_task接口”
API 调用中 messages 列表必须手动追加
/chat/completions 接口是完全无状态的，服务端不存任何上下文。你传什么，它就看什么；少一组 {"role": "assistant", "content": "..."}，它就真不知道自己上一句说了啥。
Unified LLM Gateway - One API for 70+ AI models. Route to GPT, Claude, Gemini, Qwen, Deepseek, Grok and more
下载
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
- 初始化时只设一次
system，后续绝不能重复插入或修改——否则角色会漂移，还浪费 token - 每次请求前，
messages必须包含全部历史：至少一个system+ 若干user/assistant对，顺序不能乱 - 提取响应内容时，务必用
response.choices[0].message.content，而不是.text或其他字段，否则可能取到空值或格式错误字符串
本地部署时滑动窗口和持久记忆要分层用
就算你喂了 80 万 token 进去，KV cache 也会随长度增加出现注意力稀释，越早的轮次越容易被“忽略”。单纯堆消息不管用，得人工干预信息权重。
- 把用户明确声明的长期信息（如“我的项目代号是
Atlas-9”）单独缓存进persistent_memory字典，每轮拼接上下文时前置插入，格式为【持久记忆】项目代号: Atlas-9 - 滑动窗口建议设为 5–7 轮，超出部分只保留带
【关键锚点】标记的句子，其余丢弃 - 避免在
user消息里塞大段日志文件——先用本地 LLM 做摘要，再把摘要+结论传给 DeepSeek，否则有效信息会被噪声淹没
系统提示词固化与指令切换的边界在哪
system 提示词只在首轮生效，且语义不可覆盖。你想让它“突然变专家”，不能重发 system，而要靠当前 user 消息里的显式指令标记触发行为切换。
- 初始
system应聚焦角色稳定性，例如："你是一名 Python 工程师，所有回答必须基于已确认的代码逻辑，不虚构未出现的变量名" - 临时切模式写成：
"【指令切换】现在请以安全审计身份，检查以下代码中的硬编码密钥"，模型能识别这种标记并调整推理路径 - 如果在
user消息里混写业务描述和指令（比如“帮我修 bug，顺便用 SQL 写个查询”），模型可能只执行后者——指令必须独立、前置、带明确标识
真正难的不是传多少上下文，而是让 DeepSeek 分清哪些是“这次要算的”，哪些是“永远不能忘的”。前者靠滑动窗口控制长度，后者靠人工标注 + 结构化拼接。没有自动记忆这回事，只有你主动设计的记忆链。
