从上下文到真记忆：DeepSeek Agent记忆落地指南

看到DeepSeek这轮新论文，我第一反应不是又刷榜了，而是终于有团队开始认真对待“记忆”这件事。过去大家把上下文窗口越做越大，以为这就是记忆，实际用过就知道，上下文是缓存，记忆是索引和组织过的缓存。这次论文给我的感觉是：把短期记忆和长期记忆真正拆开，让Agent知道自己该记住什么、该忘什么。这篇文章不聊论文公式，就聊聊从这套思路里我们能拿出什么能直接用的东西，包括Agent记忆框架怎么选，短期记忆、长期记忆和永久记忆在工程上怎么落地，以及结合DeepSeek API和Harness工具给Agent装记忆的完整配置过程。适合正在做AI Agent、想解决多轮对话丢上下文问题的朋友，也适合准备把DeepSeek接入本地工具链的开发者。

1. 新论文到底在解决什么问题

1.1 现在的模型不是没记性，是根本没有“记”这个动作

先说痛点。大模型上下文窗口现在动辄128K甚至1M，但你把一段很长的对话丢给它，它在第二天的会话里依旧不记得你是谁。上下文窗口只在“这一次请求”内有效，属于典型的工作内存。真正的问题是模型没有“写入—存储—召回”这条链路。

我们平时用软件里的记忆是什么？写入数据库，建立索引，下次按条件查出来。可是LLM的对话天然是流式的、非结构化的，你不能直接把所有内容塞进上下文，成本高且注意力会被稀释。DeepSeek这次公开的智能体训练方法，主攻的就是在模型层面加入记忆模块，让Agent能跨会话记住用户意图、任务状态和关键事实。

这里要强调一点，很多开发者在本地跑Agent时遇到“答非所问”，第一反应是换更大的模型，其实问题往往出在记忆链路缺失。模型本身能力再强，没有历史轮廓，也只能像个刚认识的陌生人一样重新寒暄。新论文想解决的，正是这种“每次对话都失忆”的尴尬。

1.2 为什么“上下文窗口”不背锅

很多人问：都1M上下文了，还不够记？问题不在容量，而在检索。如果每一次请求都把上百万tokens重新读一遍，费用和延迟都爆炸。更麻烦的是，信息一多，模型抓不住重点，经常把用户一周前随口说的一句话当成当前指令。

这就像一个人把所有日记都摊在桌上，反而找不到昨天写了啥。记忆系统要做的是在你需要时把那页日记翻出来，而不是把整个房间堆满纸。DeepSeek这轮思路给我的启发是：记忆不是“存得多”，而是“取得准”。你给Agent塞两万行历史，不如让它具备在关键时刻检索三行关键信息的能力。

论文里提到的一个细节很关键：模型如果只是被动接收长上下文，信息的权重会被均匀稀释，重要事实反而容易被忽略。所以要做记忆机制，让系统主动挑选“哪一段历史值得进入模型视野”，而不是把所有历史一股脑丢进去。这也是“真正的记忆”和“上下文缓存”的本质区别。

1.3 双网络记忆模型是什么

论文里比较核心的概念是双网络记忆模型。简单说就是设置两条记忆通路：一条负责短期记忆，也就是工作记忆，会话内及时更新；一条负责长期记忆，跨会话的稳定知识，通过摘要和向量化沉淀。短期网络读得快、写得快，长期网络负责压缩和沉淀。

两个网络之间还有一个“门控”逻辑，决定哪些信息值得从短期升级到长期，哪些直接丢弃。类似人脑海马体对记忆的筛选，不是所有事都值得记一辈子。这个思路其实在传统LSTM里就有影子，LSTM用门控控制信息流，但那是网络内部隐状态，而今天Agent记忆要处理的是外部世界的事实、用户偏好、工具状态，维度完全不一样。

我在实际项目里会把它翻译成一个很简单的数据流：对话进来 → 短期记忆区暂存 → 判断是否重要 → 重要则写入长期记忆库 → 下次会话启动时，把长期记忆库中相关的部分加载回短期区。这套流程听起来不玄，但正是论文里“双网络”想表达的东西。你不用去背论文里的公式，把这个数据流搭出来，效果已经很接近了。

2. Agent记忆体系拆解

2.1 从瞬时到永久：四层记忆的边界

日常做Agent，我把记忆分成四层：瞬时记忆、短期记忆、长期记忆和永久记忆。瞬时记忆是当前请求里的输入、工具返回结果，用完即弃。短期记忆是当前会话内的消息序列，通常保留最近N轮。长期记忆是跨会话可复用的用户偏好、事实信息，存在数据库里。永久记忆是身份、安全策略、核心规则，几乎不更新。

这个分层不是论文术语，是工程上最实用的划分。你设计的记忆框架越早明确这层边界，后面越不容易乱。比如“用户说他喜欢Python”这种信息，属于长期记忆；“用户刚刚问天气”这种信息，属于短期记忆；“系统禁止访问某目录”这种信息，属于永久记忆。如果全混在一起，系统要么过度记住无关紧要的内容，要么把安全规则忘了。

我见过有人把API Key也写进短期记忆，结果模型在输出时把密钥带出来了。正确做法是密钥放环境变量，永远不进记忆库。记忆分层的意义不只是性能优化，更多是权限和边界管理。

2.2 每层记忆的存储与召回策略

不同记忆层要用不同的存储介质和召回方式。直接给一个可以照抄的表格：

存储介质不要一上来就上向量数据库。很多场景用SQLite加一个关键词索引就够，只有语义模糊查询才值得上向量库。比如用户说“之前讨论过的那个性能问题”，如果记忆库里有“性能优化”相关记录，关键词就能匹配。但如果用户说的是“那个让我头疼了很久的东西”，你就需要向量检索来理解语义。

我在项目里通常是SQLite和向量库同时用：SQLite存结构化事实，比如用户名、项目名、订单号；向量库存非结构化描述，比如“用户不喜欢太长的回复”。两套数据在加载时合并注入系统提示词。这样既保证精确匹配，又兼顾语义召回。

2.3 记忆的写入、更新与遗忘机制

记忆不是写进去就完事，还要有更新和遗忘。论文里强调“可遗忘性”，这点我特别认同。如果一条记忆长期不访问，它会占用检索空间，甚至产生误导。比如用户之前喜欢长文，后来明确说“改看短文”，旧记忆就要被覆盖。

工程上可以做一个简单策略：

• 信息出现次数超过阈值，比如同一事实在三个会话中出现，从短期升级到长期。
• 用户显式说“记住”或“以后都要”，直接写入长期记忆。
• 系统判断该信息影响核心任务结果，比如用户在金融项目里提到“风控等级”，立即写入。
• 长期记忆超过一定时间未命中，比如30天没有被召回，自动降级或删除。

这些规则不需要写论文级的公式，用几个if条件就能实现。但千万别省略，否则记忆库会变成一个垃圾桶。记忆系统最大的风险不是“记不住”，而是“记住了一堆错误的东西还拿它当依据”。

3. 记忆框架选型：该不该上框架，怎么选

3.1 裸写、框架和Harness的区别

现在做Agent记忆，常见方案有三类：裸写、框架、Harness。裸写就是自己维护messages数组，塞进API请求，适合快速试验。框架比如LangChain、LlamaIndex里的Memory模块，封装了会话历史和向量召回。Harness/Agent运行时，比如社区里常说的DeepSeek Harness、Claude Code这类工具，提供Skill、记忆、工具调用的完整编排。

三者的区别可以用做饭类比：裸写是备好菜直接下锅，灵活但每一步都要自己来；框架是半成品料理包，省事但口味固定，想改汤汁得翻源码；Harness是一套完整厨房管理流程，从食材采购到出锅都是规范化操作，适合长期维护。

我的建议是：如果只做一个Demo，裸写也能跑。如果做正式项目，至少要有一个抽象层把记忆、工具和模型解耦。DeepSeek Harness这类工具热度高，核心是它把“记忆文件”和“工具调用”都变成可管理的资源，Agent启动时加载，不需要你每次手工拼消息。

3.2 选型时真正要看的四个指标

选型别只看GitHub Star数，要看这四个指标：召回延迟、存储成本、可观测性、切换成本。

召回延迟直接影响体验，记忆召回不能超过100毫秒，否则用户在对话里明显感觉到卡顿。存储成本要算上向量数据库和嵌入模型的费用，别只盯着主模型的价格。可观测性决定你排查问题时的效率，记忆是被谁写入的、什么时间写入的、为什么被召回，都需要能查。切换成本更关键，框架绑死之后，想换模型或换存储都很难。

我之前试过一个重型框架，记忆结构写死在内部，想加一个自定义字段要改源码。后来拆出来，花了两天时间把所有记忆逻辑重写成独立模块，从那以后换模型、换存储都很快。所以选型时优先选“记忆逻辑与模型调用解耦”的方案，哪怕功能少一点都行。

3.3 一套轻量可落地的组合方案

目前我用得顺手的组合是：DeepSeek Chat API + 自研Harness轻量封装 + SQLite记忆库 + 可选向量检索。DeepSeek负责理解和生成，Harness层负责编排，SQLite管事实记忆，向量库管语义记忆。

Harness层只做三件事：把对话历史、记忆摘要、工具结果统一组装成messages；决定哪些记忆需要写入；在工具调用时循环处理结果。这个封装不需要多复杂，几百行代码就能跑通。反而重型框架一上来就是几十个类，排查问题的时候特别容易绕进去。

如果不想自己写，也可以找现成的Harness项目，重点看它是否支持记忆文件、工具调用循环、以及模型接口是否兼容OpenAI格式。DeepSeek API完全兼容OpenAI风格，所以市面上大多数Harness只要改BASE_URL和Key就能用，替换成本很低。

4. 实操：给DeepSeek装上记忆

4.1 DeepSeek Harness的安装和初始化

先说我这边常用的一套初始化流程。这里的Harness可以是现成项目，也可以是自己封装的轻量脚本，核心步骤差不多。第一步克隆项目、安装依赖、复制环境变量模板：

# 示例，按你自己的项目来源执行 git clone <harness-repo> cd deepseek-harness pip install -r requirements.txt cp .env.example .env

在.env里填上DeepSeek API Key，设置BASE_URL为https://api.deepseek.com/v1，模型名用deepseek-chat。如果你的接入方是硅基流动或其它中转服务，BASE_URL换成对应的地址即可，参数结构不变。

初始化完成后，先跑一个最简单的不带记忆的对话，确认模型连通。我见过很多人上来就配记忆，结果连模型都调不通，问题还找半天。先跑通最小链路，再加记忆，是排查问题的最快路径。

4.2 用记忆文件实现永久记忆

Harness通常支持一个memory.md或AGENTS.md式的记忆文件。你可以把长期事实写在这里，每次请求自动注入。例如：

# 用户偏好 - 回复要短，不超过3段 - 代码示例用Python - 项目代号：Phoenix，当前阶段：架构设计

启动Agent时，Harness把整个文件作为系统消息的一部分发给模型。这就是永久记忆的简单实现。注意文件别塞太多，超过一定字数反而干扰模型判断。我一般控制在500字以内，超过就需要拆分或摘要。

永久记忆里只放“不可变或者极少变”的内容。比如用户身份、团队规范、项目目标、安全红线。像“今天天气不错”这种话放进去就是浪费。写永久记忆时要问自己：这个信息三个月后还需要吗？如果不需要，它就该活在短期或长期记忆里。

4.3 短期记忆的滑动窗口和自动摘要

会话内的短期记忆通常用一个窗口数组实现。我常用的是保留最近20轮，超过后按token数裁剪，同时把更早的内容做一条摘要替换。伪代码如下：

def build_messages(user_input, history, max_rounds=20): recent = history[-max_rounds:] if len(history) > max_rounds: older = history[:-max_rounds] summary = summarize_with_llm(older) # 用DeepSeek做摘要 recent.insert(0, {"role": "system", "content": f"此前对话摘要：{summary}"}) recent.append({"role": "user", "content": user_input}) return recent

摘要动作可以用DeepSeek跑，输入是一段历史messages，输出是精简的事实列表。比如“用户提到项目在4月底上线；用户偏好使用FastAPI；已确认数据库用SQLite”。这个摘要会注入下一轮对话作为背景。

实测下来，摘要策略能把超长会话的token占用降低60%以上，而且模型对摘要中关键信息的把握往往比原文更好。因为摘要是“提取过”的事实，不再夹带无关闲聊。记住，摘要不是压缩聊天记录，而是提取事实和决策，这个心智模型很重要。

4.4 工具调用结果的即时追加

Agent装记忆不只是记录对话，还要把工具调用结果写进去。比如查询订单后返回订单号，这个订单号应该写入短期记忆，否则下一轮模型就忘了。这里要特别注意OpenAI兼容接口的规范：如果模型返回tool_calls，你必须把工具结果立刻作为role: "tool"的消息追加回去，再发第二次请求，否则会报messages tool calls need immediate results。

from openai import OpenAI client = OpenAI(base_url="https://api.deepseek.com/v1", api_key="YOUR_API_KEY") def run_with_tools(messages, tools): resp = client.chat.completions.create( model="deepseek-chat", messages=messages, tools=tools, tool_choice="auto", ) msg = resp.choices[0].message messages.append(msg) while msg.tool_calls: for call in msg.tool_calls: result = run_tool(call.function.name, call.function.arguments) messages.append({ "role": "tool", "tool_call_id": call.id, "content": result, }) resp = client.chat.completions.create( model="deepseek-chat", messages=messages, tools=tools, ) msg = resp.choices[0].message messages.append(msg) return messages

这段代码是基础中的基础。很多线上事故都出在这个while循环里，常见的就是工具结果没及时追加，或者忘记把assistant的消息先加进去，导致模型不知道工具对应哪次调用。

工具结果可以顺便做一次结构化提取，把关键字段转成一句话再写入记忆。比如工具返回一个很大的JSON，提取出“订单状态：已发货；预计到货：明天”，然后用这一句话作为下次对话的背景。不要把原始大JSON塞进记忆，模型容易被无关字段带偏。

4.5 长期记忆的向量召回

当长期记忆的量上来之后，每次把几百条全塞给模型不现实。正确做法是用向量检索取TopK。

import sqlite3 import numpy as np def recall_memory(user_id, question, embedding_fn, top_k=5): # 1. 把用户问题转成向量 query_vec = embedding_fn(question) # 2. 从记忆表取该用户的所有记忆向量 rows = query_memory_by_user(user_id) # 3. 计算余弦相似度并取TopK scored = [ (cosine_similarity(query_vec, row["vector"]), row["content"]) for row in rows ] scored.sort(key=lambda x: x[0], reverse=True) return scored[:top_k]

这份代码里嵌入模型可以用本地的小模型，也可以用API。实测下来，用1024维的嵌入模型，一万条记忆的相似度检索在几十毫秒内能完成，完全够用。不要把向量库想得太复杂，SQLite加一个向量扩展或者用NumPy做暴力检索，小规模场景足够。

向量召回的时机也有讲究，不是每一轮对话都要召回。我通常在新会话的第一轮用户输入后做一次召回，把结果注入系统提示词；后续对话中只有检测到新话题，或者用户提到“之前”这类词，才重新召回。减少召回频率可以明显降低延迟和成本。

4.6 把DeepSeek接进编辑器和CLI

除了API调用，很多人还会把DeepSeek接进VS Code或Codex类CLI工具。思路都一样：在配置里把模型端点指向https://api.deepseek.com/v1，模型名填deepseek-chat，然后让工具通过OpenAI兼容协议调用。

以VS Code里的Continue或Cline为例，配置里通常有一个models字段，填入DeepSeek的BASE_URL、API Key、模型名即可。接入之后，你之前配好的Harness记忆文件也会在对话中生效，因为编辑器和CLI本质上还是走OpenAI兼容接口，记忆逻辑在上层。

这套连好后，我平时的开发流程是：VS Code里写代码遇到问题直接问DeepSeek，Agent通过Harness加载项目记忆文件，自动带上项目架构、代码风格偏好，回复质量比裸调模型高一个档次。很多“代码风格不一致”的问题，其实就是记忆文件里写了“用Python”“不用类”这类约束，模型自然照做。

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

5.1 记忆都串了，A用户的问题变成B用户的背景

这是最常见的错误。根因是记忆库没有按会话或用户隔离。解决方案：所有记忆表都要带user_id和session_id字段，查询时强制过滤。我踩过坑后直接在Harness层封装了一个memory.for_user(user_id)方法，任何记忆读写都必须从该方法入口走。

排查方法也很简单：打开记忆表，看看某条记录的user_id是不是正确。如果暴露了串号问题，优先检查是不是在加载记忆时用了全局变量存储，多线程并发时全局变量最容易串。记得把记忆数据绑定到请求上下文里，而不是绑定到一个单例对象上。

5.2 上下文越拉越长，费用飙涨

如果短期记忆一直没有裁剪，每次请求都在重复发送同样的历史，费用涨得很快。建议在Harness层做token统计，超过阈值就触发摘要压缩。另外可以把工具调用中的超长返回结果（比如JSON列表）先存到内存，只把结果摘要放回messages。

一个比较容易忽略的点是系统提示词里塞了太多静态内容。有些人喜欢在系统提示词里写几十条规则，再加永久记忆文件，再加召回结果，光系统消息就占了几千token。这些内容每一轮都要计费，而且会稀释模型注意力。建议定期精简系统提示词，只留必要约束。

5.3 messages tool calls need immediate results

这条报错是OpenAI兼容接口的规范错误。含义是：模型发出了工具调用，但你在同一轮请求里没有把工具结果作为tool角色消息返回。解决方式就是上面代码里的while循环，保证每次工具调用后立即追加结果，再继续对话。

还有一个小细节：工具结果的content必须是非空字符串。如果工具返回空，转成"OK"再塞回去。另一个坑是工具调用ID必须严格对应，不能把第一个工具调用结果附加到第二个工具调用的消息上，否则模型会混乱，甚至报找不到匹配的tool_call_id。

5.4 API与本地部署如何切换

本地部署DeepSeek可以用vLLM或Ollama，好处是数据不出内网、可以自由改模型，但显存和运维成本高。API方式简单，需要额外处理隐私和费用。我的习惯是：开发阶段全部走API，模型调通后，如果确实有隐私要求，再把关键链路切成本地部署。

两者用的是同一个OpenAI兼容协议，代码切换成本很低，只需要改base_url和模型名。我封装过一个配置项，把LLM_BASE_URL和LLM_MODEL做成环境变量，切换时改两个值就行。唯一要注意的是本地部署的上下文长度可能受显存限制，记忆窗口策略要对应调整，别用API时的20轮窗口直接跑本地小模型。

5.5 工具返回数据的格式陷阱

工具返回时间、金额这类变量时，模型容易记错。建议在工具函数里直接返回格式化后的文本，比如"订单20250315金额198.00元，创建时间2025-03-15 14:30:00"。不要让模型去解析原始时间戳。这类细节看起来不起眼，但直接影响下一轮记忆写入的准确性。

另外要留意时区问题。如果工具返回的时间是UTC，模型不知道转时区，可能写进记忆的本地时间就差了几小时。我的做法是在工具函数里完成时区转换，输出内容已经是业务时区，模型只负责读取和复述，不承担计算责任。

6. 一些实际经验

第一，记忆系统一定从“最小可用”开始。我最初只用一个memory.json存全部历史，跑通了才逐步换成SQLite、向量库。如果一开始就上复杂架构，多半会在排查问题时被框架绕晕。能跑起来的简单系统，永远比设计完美的复杂系统更有价值。

第二，给模型看的记忆摘要要写清楚来源时间。比如“2025年4月，用户提到希望回复控制在300字内”，模型才能真正理解哪条记忆更优先。没有时间戳的记忆，就像没有日期的日记，模型只能靠猜测决定该不该信。

第三，DeepSeek在工具调用和多轮记忆场景下表现很稳，但你要记得在prompt里明确“不要编造记忆”。如果你把一条空记忆当成用户真实说过的话，模型会顺着编。写入记忆前，最好预留一个人工确认或规则过滤的步骤。我在Harness里加了一个简单规则：所有记忆写入前必须包含至少一个动词和一个名词，比如“用户喜欢Python”合法，“用户喜欢”不合法，这个规则能过滤掉不少无效记忆。

第四，别迷信论文里的术语。双网络记忆模型再漂亮，落到你的项目里可能只需要一个short列表和一个long表。先把骨架搭出来，再去对标论文逐步优化。这也是我看了DeepSeek这轮新论文后最大的体会：真正的记忆不是靠更大的上下文，而是靠更聪明的取舍。你不需要一步到位，先让Agent记住该记住的，忘掉该忘的，就已经比大多数裸调模型强出一大截了。