给大模型做记忆听起来不像是个“硬核模型”项目但在 Agent、私有化部署和 To B 落地的语境里这几乎是必须跨过去的一道坎。郝建业团队半年内完成三轮融资给这个方向又添了一把火。资本关注的是“记忆”能不能成为大模型的基础设施而技术人更关心的是另一件事记忆到底怎么存、怎么取、怎么和大模型接口接起来以及我自己的服务器上能不能跑一套。这篇文章不做资本复盘先讲清楚大模型记忆的技术本质它分几类、开源实现有哪些、本地部署怎么搭、Agent 怎么通过 API 读写记忆、批量任务怎么做以及最容易踩哪些坑。如果你正在做大模型应用开发、Agent 工作流或者准备给私有大模型加长期记忆这篇可以直接当参考。先说结论大模型本身是无状态的记忆能力必须靠外部系统补。主流的做法是“大模型 向量数据库 记忆管理模块”再往上就是带记忆的 Agent 框架。下面从规格开始拆。1. 大模型记忆核心能力速览能力项说明解决的核心问题让大模型跨会话、跨任务记住用户偏好、历史操作、业务规则和项目上下文技术本质外部记忆系统 检索增强 上下文管理不修改模型权重主要实现方式上下文窗口拼接、向量数据库、知识图谱、LangChain Memory、LangGraph Checkpoint大模型选型本地可用 Ollama、vLLM 部署开源模型商业场景可接云端大模型 API硬件门槛取决于模型参数量仅跑 Embedding 和向量检索时 CPU 也可承担显存占用需按实际模型和推理参数测试无固定值支持批量任务支持文本切块、向量化入库、记忆压缩都可批量处理是否提供 API各框架通常提供 Python API自建服务可用 REST API 封装适合场景Agent 长期任务、私有大模型知识问答、用户画像记忆、自动化工作流版权与隐私边界记忆内容涉及用户数据时必须脱敏、授权并控制访问范围从规格上看这个方向不挑显卡也不依赖某个特定大模型。你完全可以用一个小的开源模型做推理再配一个向量库负责记忆存取整体门槛比微调低得多。这也解释了为什么资本市场会看好“给大模型做记忆”它不是重资源游戏而是一个能快速落地的工程层机会。2. 为什么大模型需要记忆从无状态到有状态大模型默认是无状态的。你发一句“帮我写一份周报”它返回结果然后对话结束。下一次你再发起请求时它不会记得你上周做了什么不会记得你偏好的语气也不会记得你之前已经在对话里确认过的项目信息。对普通聊天场景这个问题可以靠“多轮对话上下文拼接”解决因为模型输入里会把最近几轮对话一起塞进去。但真到了 Agent、企业知识库、自动化流程里这种“临时上下文”远远不够。典型的问题有三个。第一会话一断上下文全丢。浏览器刷新、任务超时、服务重启之前聊的所有内容都消失了。用户必须重新描述一遍背景Agent 也必须重新初始化状态。第二长任务做不下去。一个 Agent 要执行“调研市场 - 写方案 - 做 PPT - 给用户过目 - 按反馈修改”这种多步骤任务中间任何一次模型调用的上下文都是有限的。模型记不住前面调研的结论后面写方案就是瞎写。第三用户级记忆缺失。同一个用户今天问“我要预算偏保守的方案”明天再问“做一版激进点的”如果系统不记得用户偏好每次都要用户重新交代。这在 To B 场景里非常影响体验。所以“给大模型做记忆”的本质是把模型从无状态的函数变成有状态的服务。实现思路不是去改模型参数而是在模型外面加一层记忆管理层写入、存储、检索、更新、过期然后在你调用模型接口之前把相关的历史记忆取出来拼进上下文里。这个思路和 RAG 很像但比单一 RAG 更全面——RAG 偏向“知识检索”记忆系统还要处理“用户偏好”“任务进度”“多轮状态”这些动态信息。3. 大模型记忆的分类短期、长期、工作记忆在具体落地之前先把记忆分类理清楚。不同种类的记忆存储方式和读取时机完全不同。记忆类型典型内容存储方式读取时机短期记忆当前会话的对话历史、临时状态模型上下文窗口、内存变量每次请求全部携带或滑动窗口截取长期记忆用户偏好、历史行为、业务配置向量数据库、关系数据库、键值存储根据当前输入检索出最相关的部分工作记忆Agent 当前任务执行进度、中间结果状态存储、任务队列、文件任务流每个步骤开始时恢复语义记忆知识库、文档、规则、术语表向量数据库、图数据库用户提问时检索增强情景记忆用户与系统之前的交互记录事件日志、时序数据库按时间或场景回放工程上最常见的组合是短期记忆靠上下文窗口长期记忆靠向量检索工作记忆靠状态机或 Checkpoint。这里要特别提醒一句不要把长期记忆做成“把全部历史都塞给大模型”。上下文窗口再大也有上限而且塞得越多模型注意力越分散响应越慢成本越高。长期记忆的正确做法是“按需检索”——根据当前问题从记忆库里取最相关的一小段而不是把整库倒进提示词。4. 主流开源记忆框架速览目前给大模型加记忆的开源方案不少下面几个是社区里讨论最多、与“大模型记忆”热搜词直接相关的方向。4.1 LangChain Memory 模块LangChain 是接触最多的 Agent 开发框架它把记忆抽象成几个常用类ConversationBufferMemory 保存所有对话记录ConversationSummaryMemory 用模型历史对话生成摘要并保存ConversationBufferWindowMemory 只保留最近 N 轮VectorStoreRetrieverMemory 把历史对话向量化后存储检索时取相关片段。对于快速做 DemoLangChain Memory 是最省事的。from langchain.memory import ConversationBufferWindowMemory from langchain.chains import ConversationChain from langchain_ollama import ChatOllama memory ConversationBufferWindowMemory(k5, return_messagesTrue) llm ChatOllama(modelqwen2.5:7b) conversation ConversationChain(llmllm, memorymemory) print(conversation.run(我叫小王负责服务器运维。)) print(conversation.run(你还记得我是谁吗))上面是一个最简示例实际项目中 memory 的存储方式可以替换成 Redis、数据库或向量库。需要注意的是LangChain 不同版本的 API 有差异使用时以项目文档为准。它适合单机快速验证但生产环境的长期记忆还是建议用下面的 LangGraph 做持久化。4.2 LangGraph Checkpoint 持久化记忆LangGraph 更贴合“有状态 Agent”这个需求。它把 Agent 执行过程建模成一张图图中每个节点的状态变化可以被 Checkpoint 记录到 SQLite、Postgres 或 Redis 里。任务中断后可以从最近的 Checkpoint 恢复属于典型的工作记忆实现。和 LangChain Memory 相比LangGraph 更强调跨任务的状态恢复适合多步骤、可中断的复杂 Agent。from langgraph.graph import StateGraph from langgraph.checkpoint.sqlite import SqliteSaver # 使用 SqliteSaver 做 Checkpoint 持久化 with SqliteSaver.from_conn_string(checkpoints.db) as saver: graph StateGraph(SomeStateSchema) # 添加节点和边 app graph.compile(checkpointersaver) # 每次执行时传入 thread_id 作为会话标识 config {configurable: {thread_id: task-001}} result app.invoke(initial_state, configconfig)这个方案解决了“任务执行到一半服务重启”的问题。需要注意的是Checkpoint 保存的往往是原始对话状态和数据如果涉及敏感业务数据落库前先做脱敏。4.3 向量数据库 RAG 长期记忆长期记忆的底层存储现在的主流是向量数据库。常见选择包括 Chroma、FAISS、Milvus、Qdrant、pgvector。流程是用 Embedding 模型把文本转成向量存入向量库查询时把用户输入也转成向量做相似度检索把 TopK 结果拼进提示词。from langchain_ollama import OllamaEmbeddings from langchain_community.vectorstores import Chroma from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.docstore.document import Document # 初始化 Embedding 模型 embeddings OllamaEmbeddings(modelnomic-embed-text) # 构造一个记忆文档 doc Document( page_content用户小王偏好预算保守的运维方案常用语言是中文关注费用和稳定性。, metadata{user_id: xiaowang} ) # 切分并入库 splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) docs splitter.split_documents([doc]) vectorstore Chroma.from_documents(docs, embeddings, persist_directory./memory_db) # 检索 results vectorstore.similarity_search(小王选择方案时最看重什么, k3) print(results)这套组合的优势是模型可以随时换记忆库独立存在用户历史数据积累后不需要重新训练模型批量导入历史知识只需要跑一次离线 Embedding。缺点是向量检索的质量取决于 Embedding 模型和切块策略不是“丢进去就能用”。5. 本地部署大模型并添加记忆环境准备无论用哪个框架本地部署大模型 记忆系统都遵循同一套流程启动推理模型、启动 Embedding 模型、选择存储介质、配置记忆读写逻辑。以下给出通用步骤具体版本和路径按实际项目调整。先看环境清单检查项说明操作系统Linux 服务器或 Windows/WSL 均可推荐 LinuxGPU有 NVIDIA 显卡最好没有也可用 CPU 跑小模型内存8GB 起步跑 7B 模型建议 16GB 以上磁盘模型文件 5GB 到 20GB 不等另留存储空间Python3.9 到 3.11 均可模型运行器Ollama 或 vLLM向量库Chroma、FAISS、Milvus 等端口规划Ollama 默认 11434自建服务预留独立端口如果只做记忆功能验证不需要一开始就上大显存显卡。Embedding 模型非常轻量CPU 跑完全没问题推理模型可以先用 1.5B 或 3B 的小模型验证流程通了以后再换大模型。6. 安装部署与启动方式6.1 快速启动 Ollama 模型服务Ollama 是目前本地部署大模型最方便的工具之一支持一键下载模型并暴露 API。以 Linux/macOS 为例# 安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 拉取推理模型 ollama pull qwen2.5:7b # 拉取 Embedding 模型 ollama pull nomic-embed-text # 启动服务默认端口 11434 ollama serve启动后可以测试接口是否正常curl http://127.0.0.1:11434/api/generate -d { model: qwen2.5:7b, prompt: 你好用一句话介绍你自己 }注意如果 Ollama 已经在后台运行ollama serve会提示端口被占用直接访问 11434 即可。模型文件默认存储在~/.ollama/models下磁盘空间不足时可以设置OLLAMA_MODELS环境变量改路径。6.2 在 Windows 上部署Windows 推荐使用 Ollama 官方安装包安装后直接执行ollama pull qwen2.5:7b ollama pull nomic-embed-text ollama serve然后打开浏览器访问 http://127.0.0.1:11434 确认服务状态。如果你用的是老显卡建议先确认驱动是否支持 CUDA如果不支持就选 CPU 推理的小模型。6.3 vLLM 高并发部署如果需要更高并发或批量推理可以用 vLLM。它是专门为高吞吐推理设计的框架适合把大模型部署成 API 服务# 安装 vLLMLinux CUDA 环境 pip install vllm # 启动 OpenAI 兼容 API 服务 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --host 127.0.0.1 \ --port 8000启动后客户端可以用 OpenAI SDK 风格调用。vLLM 的显存占用和模型量化精度有关系首次启动会做 warmup实际显存以任务管理器或nvidia-smi观察为准。6.4 自建记忆服务推理模型启动后还需要一个“记忆服务”来统一管理写入和检索。最简单的做法是写一个 Python FastAPI 服务内部依赖向量库和 Embedding 模型。from fastapi import FastAPI from pydantic import BaseModel from langchain_ollama import OllamaEmbeddings from langchain_community.vectorstores import Chroma app FastAPI() embeddings OllamaEmbeddings(modelnomic-embed-text) vectorstore Chroma( persist_directory./memory_db, embedding_functionembeddings ) class MemoryItem(BaseModel): user_id: str content: str class QueryRequest(BaseModel): user_id: str query: str top_k: int 5 app.post(/memory/write) def write_memory(item: MemoryItem): vectorstore.add_texts( texts[item.content], metadatas[{user_id: item.user_id}] ) return {status: ok} app.post(/memory/query) def query_memory(req: QueryRequest): docs vectorstore.similarity_search(req.query, kreq.top_k) results [ {content: d.page_content, metadata: d.metadata} for d in docs ] return {results: results}启动这个服务后大模型应用就可以通过 HTTP 接口写入用户记忆和读取相关记忆了。生产环境建议用 Milvus 或 Qdrant 替代本地 Chroma并加上用户权限过滤。7. 给大模型应用接入记忆功能测试与效果验证框架搭好之后下面做一套简单的功能测试验证记忆是否真的生效。测试目标不是看模型多聪明而是确认“写入的记忆能查到查到的内容能进入提示词”。7.1 记忆写入测试先写入一条明确的用户偏好curl -X POST http://127.0.0.1:8000/memory/write \ -H Content-Type: application/json \ -d { user_id: xiaowang, content: 小王是运维负责人喜欢预算保守的解决方案关注系统稳定性。 }预期返回{status: ok}。如果失败检查记忆服务是否启动、向量库目录是否可写、Embedding 模型是否可用。7.2 记忆检索测试再查询这条记忆curl -X POST http://127.0.0.1:8000/memory/query \ -H Content-Type: application/json \ -d { user_id: xiaowang, query: 小王选方案时在意什么, top_k: 3 }预期结果里应该包含“预算保守”“稳定性”这些关键词。如果没有检索到先看提问表述和原文差异是否过大再调整切块大小和 TopK 参数。7.3 带记忆的大模型问答测试检索到记忆后把它拼进提示词再让大模型回答curl http://127.0.0.1:11434/api/generate -d { model: qwen2.5:7b, prompt: 根据以下记忆信息回答问题。\n记忆信息小王是运维负责人喜欢预算保守的解决方案关注系统稳定性。\n问题请为他推荐一个监控方案。, stream: false }判断成功的标准回答里出现了“稳定性”“成本控制”等与记忆匹配的内容。如果模型完全没用到记忆说明提示词拼接逻辑需要调整或者检索到的记忆片段和问题不相关。7.4 批量记忆导入测试长期记忆不可能一条条手写通常要批量导入历史对话、业务文档或用户标签。推荐流程是文本切块 - 批量 Embedding - 批量入库 - 人工抽检检索效果。import requests docs [ 用户A偏好使用 Grafana 展示监控数据。, 用户A的告警阈值是 CPU 使用率超过 80% 时通知。, 用户A所在的团队有 5 名运维工程师。, ] for doc in docs: resp requests.post( http://127.0.0.1:8000/memory/write, json{user_id: user_a, content: doc}, timeout30, ) print(resp.status_code, resp.json())批量导入的重点不是“全量入库”而是导入后的检索准确率。建议每导入一批就抽几条和业务相关的 query 测试检索结果必要时调整切块策略或重选 Embedding 模型。8. 接口 API 与批量任务设计如果要把记忆能力集成到现有系统里不能只停留在 Python 函数调用层面。推荐把记忆服务封装成独立 API方便不同业务模块调用。接口方法用途/memory/writePOST写入一条用户记忆或文档记忆/memory/queryPOST查询与输入最相关的记忆/memory/deletePOST删除指定用户或指定内容的记忆/memory/clearPOST清空一个用户的所有记忆/memory/batch_importPOST批量导入历史对话或文档/memory/statsGET查看当前记忆库规模、向量数量批量任务设计上要注意三个点。第一批量导入建议异步执行用任务队列接住避免一次性阻塞 API。第二每条记忆都加user_id、timestamp、source等元数据方便后续做权限控制和过期清理。第三记忆库要有幂等机制同一批数据重复导入时不能产生大量重复向量否则检索结果会被重复片段污染。下面是一个异步批量导入的简单示意from fastapi import BackgroundTasks def do_batch_import(items): for item in items: vectorstore.add_texts( texts[item[content]], metadatas[{user_id: item[user_id], source: import}] ) app.post(/memory/batch_import) async def batch_import(payload: dict, background: BackgroundTasks): items payload[items] background.add_task(do_batch_import, items) return {status: accepted, count: len(items)}这个接口适合处理“历史聊天记录一次性导入”“知识库全量重建”等场景。需要注意的是异步任务要搭配日志和重试机制不然大量导入时中途挂了很难排查。9. 资源占用与性能观察“给大模型做记忆”并不等于只跑一个大模型。实际系统里有推理模型、Embedding 模型、向量库、记忆服务四部分资源占用要分开看。推理模型占大头。7B 模型在 GPU 上通常需要 6GB 左右显存在 CPU 上则取决于内存和量化等级。显存不足时可以换量化版本或改用 1.5B 小模型。Embedding 模型非常轻量。比如 nomic-embed-text 这类模型CPU 也能跑批量向量化时主要吃内存。向量库Chroma 本地模式占用很小Milvus、Qdrant 这类独立服务要单独计算内存和磁盘。记忆服务FastAPI 这类轻量服务占用很小主要瓶颈在向量检索并发。观察资源占用的方法GPU 显存nvidia-smi -l 2每隔两秒刷新一次。CPU 和内存top或htop。向量库磁盘du -sh ./memory_db。接口耗时在记忆服务里给每个查询加计时日志。如果发现检索速度慢优先查这几个方向索引类型是否选对、向量维度是否过大、单次查询返回的 TopK 是否过高、向量库有没有分区。检索慢和大模型推理慢是两回事先定位瓶颈再调优。降低显存占用的通用手段包括模型量化GGUF/Q4、使用更小模型、减小上下文长度、关闭非必要工具进程、给 embedding 和推理模型分机部署。具体数值必须以本机实际测试为准不建议照搬网上的“某某卡占用几 G”的结论。10. 常见问题与排查方法问题现象可能原因排查方式解决方案模型下载慢或失败网络不稳定、磁盘空间不足检查磁盘剩余空间和网络换镜像源或用离线文件导入模型Ollama 端口无法访问服务未启动或端口被占用curl 127.0.0.1:11434lsof -i重启服务或修改OLLAMA_HOST显存不足导致生成失败模型过大或并发太高nvidia-smi查看显存换量化模型降低并发减小上下文记忆写入成功但检索不到文本切块不合理或 Embedding 效果差直接打印检索结果检查关键词调整切块大小换 Embedding 模型检索到的记忆和问题无关向量相似度区分度不够检查 TopK 和阈值加相关性阈值或给记忆加标签过滤批量导入重复数据没有幂等机制查看入库记录按source content hash去重接口调用报 502 或超时服务崩溃或负载过高查看日志、检查并发加负载控制任务改异步Agent 任务中断后状态丢失没有做 Checkpoint查看是否有持久化状态存储使用 LangGraph Checkpoint 或自建任务状态表排查思路只有一条先确认服务是否活再确认数据是否在最后确认检索链路是否通。不要一上来就怀疑模型能力大多数记忆失效问题出在存储和拼接阶段。11. 最佳实践与使用建议给大模型做记忆工程上建议遵守下面几条。第一记忆和业务数据分离。不要把用户的所有原始聊天记录都塞进记忆库更不要把密码、密钥、身份证号等敏感信息写入长期记忆。记忆库里只保留“对后续任务有用的摘要化信息”。第二权限控制必须前置。不同用户的数据要隔离查询时带上user_id过滤条件。如果自建服务面向内部使用至少限制访问 IP 和端口如果部署在公网必须加认证。第三先小参数测试再上全量。第一次跑通记忆链路时用最小模型、最小数据量、单用户测试。链路没有问题后再扩展模型规模和用户量。第四保留一个最小可运行配置。把启动 Ollama、启动记忆服务、安装依赖的命令和版本记录成文档。环境坏了可以快速恢复不用重新踩坑。第五定期清理过期记忆。长期记忆不是只增不减。用户偏好会变业务规则会更新旧记忆如果不清理不仅占存储还可能干扰检索结果。建议给记忆加时间戳按业务需要做过期策略。第六涉及人脸、声音、用户行为、版权内容时必须确认授权和合规边界。这是底线问题不是技术问题。大模型记忆系统里如果存了用户的历史对话和偏好需要履行告知义务并允许用户删除。12. 总结与下一步郝建业团队半年内完成三轮融资说明“给大模型做记忆”已经从一个技术概念变成了被资本认可的基础设施方向。对于技术人来说这个方向最大的价值在于它不需要你去训练模型只需要在模型外面搭一层记忆管理层就能让大模型在真实业务里“记住”该记住的东西。这篇文章给出的路线是用 Ollama 或 vLLM 部署推理模型用 Embedding 向量库做长期记忆存储再用 FastAPI 封装成记忆服务通过 HTTP 接口接入大模型应用或 Agent 工作流。整套方案可以本地部署支持批量导入也支持按用户隔离。下一步你可以先做三件事第一用一个小模型跑通“写入记忆 - 检索记忆 - 拼接提示词”的最小闭环第二导入你自己的历史对话或文档抽几条真实问题测试检索准确率第三把记忆服务封装成 API接到你现有的 Agent 或聊天机器人里观察是否解决了“换会话就失忆”的问题。最容易踩的坑有两个一是把长期记忆理解成“所有历史都塞进上下文”导致成本和效果双双恶化二是只做存储不做检索质量验证结果记忆库建好了真正查询时却拿不到有用信息。先把这两点做好大模型记忆就算真正落地了。 大模型记忆技术解析：从向量数据库到LangGraph实战
给大模型做记忆听起来不像是个“硬核模型”项目但在 Agent、私有化部署和 To B 落地的语境里这几乎是必须跨过去的一道坎。郝建业团队半年内完成三轮融资给这个方向又添了一把火。资本关注的是“记忆”能不能成为大模型的基础设施而技术人更关心的是另一件事记忆到底怎么存、怎么取、怎么和大模型接口接起来以及我自己的服务器上能不能跑一套。这篇文章不做资本复盘先讲清楚大模型记忆的技术本质它分几类、开源实现有哪些、本地部署怎么搭、Agent 怎么通过 API 读写记忆、批量任务怎么做以及最容易踩哪些坑。如果你正在做大模型应用开发、Agent 工作流或者准备给私有大模型加长期记忆这篇可以直接当参考。先说结论大模型本身是无状态的记忆能力必须靠外部系统补。主流的做法是“大模型 向量数据库 记忆管理模块”再往上就是带记忆的 Agent 框架。下面从规格开始拆。1. 大模型记忆核心能力速览能力项说明解决的核心问题让大模型跨会话、跨任务记住用户偏好、历史操作、业务规则和项目上下文技术本质外部记忆系统 检索增强 上下文管理不修改模型权重主要实现方式上下文窗口拼接、向量数据库、知识图谱、LangChain Memory、LangGraph Checkpoint大模型选型本地可用 Ollama、vLLM 部署开源模型商业场景可接云端大模型 API硬件门槛取决于模型参数量仅跑 Embedding 和向量检索时 CPU 也可承担显存占用需按实际模型和推理参数测试无固定值支持批量任务支持文本切块、向量化入库、记忆压缩都可批量处理是否提供 API各框架通常提供 Python API自建服务可用 REST API 封装适合场景Agent 长期任务、私有大模型知识问答、用户画像记忆、自动化工作流版权与隐私边界记忆内容涉及用户数据时必须脱敏、授权并控制访问范围从规格上看这个方向不挑显卡也不依赖某个特定大模型。你完全可以用一个小的开源模型做推理再配一个向量库负责记忆存取整体门槛比微调低得多。这也解释了为什么资本市场会看好“给大模型做记忆”它不是重资源游戏而是一个能快速落地的工程层机会。2. 为什么大模型需要记忆从无状态到有状态大模型默认是无状态的。你发一句“帮我写一份周报”它返回结果然后对话结束。下一次你再发起请求时它不会记得你上周做了什么不会记得你偏好的语气也不会记得你之前已经在对话里确认过的项目信息。对普通聊天场景这个问题可以靠“多轮对话上下文拼接”解决因为模型输入里会把最近几轮对话一起塞进去。但真到了 Agent、企业知识库、自动化流程里这种“临时上下文”远远不够。典型的问题有三个。第一会话一断上下文全丢。浏览器刷新、任务超时、服务重启之前聊的所有内容都消失了。用户必须重新描述一遍背景Agent 也必须重新初始化状态。第二长任务做不下去。一个 Agent 要执行“调研市场 - 写方案 - 做 PPT - 给用户过目 - 按反馈修改”这种多步骤任务中间任何一次模型调用的上下文都是有限的。模型记不住前面调研的结论后面写方案就是瞎写。第三用户级记忆缺失。同一个用户今天问“我要预算偏保守的方案”明天再问“做一版激进点的”如果系统不记得用户偏好每次都要用户重新交代。这在 To B 场景里非常影响体验。所以“给大模型做记忆”的本质是把模型从无状态的函数变成有状态的服务。实现思路不是去改模型参数而是在模型外面加一层记忆管理层写入、存储、检索、更新、过期然后在你调用模型接口之前把相关的历史记忆取出来拼进上下文里。这个思路和 RAG 很像但比单一 RAG 更全面——RAG 偏向“知识检索”记忆系统还要处理“用户偏好”“任务进度”“多轮状态”这些动态信息。3. 大模型记忆的分类短期、长期、工作记忆在具体落地之前先把记忆分类理清楚。不同种类的记忆存储方式和读取时机完全不同。记忆类型典型内容存储方式读取时机短期记忆当前会话的对话历史、临时状态模型上下文窗口、内存变量每次请求全部携带或滑动窗口截取长期记忆用户偏好、历史行为、业务配置向量数据库、关系数据库、键值存储根据当前输入检索出最相关的部分工作记忆Agent 当前任务执行进度、中间结果状态存储、任务队列、文件任务流每个步骤开始时恢复语义记忆知识库、文档、规则、术语表向量数据库、图数据库用户提问时检索增强情景记忆用户与系统之前的交互记录事件日志、时序数据库按时间或场景回放工程上最常见的组合是短期记忆靠上下文窗口长期记忆靠向量检索工作记忆靠状态机或 Checkpoint。这里要特别提醒一句不要把长期记忆做成“把全部历史都塞给大模型”。上下文窗口再大也有上限而且塞得越多模型注意力越分散响应越慢成本越高。长期记忆的正确做法是“按需检索”——根据当前问题从记忆库里取最相关的一小段而不是把整库倒进提示词。4. 主流开源记忆框架速览目前给大模型加记忆的开源方案不少下面几个是社区里讨论最多、与“大模型记忆”热搜词直接相关的方向。4.1 LangChain Memory 模块LangChain 是接触最多的 Agent 开发框架它把记忆抽象成几个常用类ConversationBufferMemory 保存所有对话记录ConversationSummaryMemory 用模型历史对话生成摘要并保存ConversationBufferWindowMemory 只保留最近 N 轮VectorStoreRetrieverMemory 把历史对话向量化后存储检索时取相关片段。对于快速做 DemoLangChain Memory 是最省事的。from langchain.memory import ConversationBufferWindowMemory from langchain.chains import ConversationChain from langchain_ollama import ChatOllama memory ConversationBufferWindowMemory(k5, return_messagesTrue) llm ChatOllama(modelqwen2.5:7b) conversation ConversationChain(llmllm, memorymemory) print(conversation.run(我叫小王负责服务器运维。)) print(conversation.run(你还记得我是谁吗))上面是一个最简示例实际项目中 memory 的存储方式可以替换成 Redis、数据库或向量库。需要注意的是LangChain 不同版本的 API 有差异使用时以项目文档为准。它适合单机快速验证但生产环境的长期记忆还是建议用下面的 LangGraph 做持久化。4.2 LangGraph Checkpoint 持久化记忆LangGraph 更贴合“有状态 Agent”这个需求。它把 Agent 执行过程建模成一张图图中每个节点的状态变化可以被 Checkpoint 记录到 SQLite、Postgres 或 Redis 里。任务中断后可以从最近的 Checkpoint 恢复属于典型的工作记忆实现。和 LangChain Memory 相比LangGraph 更强调跨任务的状态恢复适合多步骤、可中断的复杂 Agent。from langgraph.graph import StateGraph from langgraph.checkpoint.sqlite import SqliteSaver # 使用 SqliteSaver 做 Checkpoint 持久化 with SqliteSaver.from_conn_string(checkpoints.db) as saver: graph StateGraph(SomeStateSchema) # 添加节点和边 app graph.compile(checkpointersaver) # 每次执行时传入 thread_id 作为会话标识 config {configurable: {thread_id: task-001}} result app.invoke(initial_state, configconfig)这个方案解决了“任务执行到一半服务重启”的问题。需要注意的是Checkpoint 保存的往往是原始对话状态和数据如果涉及敏感业务数据落库前先做脱敏。4.3 向量数据库 RAG 长期记忆长期记忆的底层存储现在的主流是向量数据库。常见选择包括 Chroma、FAISS、Milvus、Qdrant、pgvector。流程是用 Embedding 模型把文本转成向量存入向量库查询时把用户输入也转成向量做相似度检索把 TopK 结果拼进提示词。from langchain_ollama import OllamaEmbeddings from langchain_community.vectorstores import Chroma from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.docstore.document import Document # 初始化 Embedding 模型 embeddings OllamaEmbeddings(modelnomic-embed-text) # 构造一个记忆文档 doc Document( page_content用户小王偏好预算保守的运维方案常用语言是中文关注费用和稳定性。, metadata{user_id: xiaowang} ) # 切分并入库 splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) docs splitter.split_documents([doc]) vectorstore Chroma.from_documents(docs, embeddings, persist_directory./memory_db) # 检索 results vectorstore.similarity_search(小王选择方案时最看重什么, k3) print(results)这套组合的优势是模型可以随时换记忆库独立存在用户历史数据积累后不需要重新训练模型批量导入历史知识只需要跑一次离线 Embedding。缺点是向量检索的质量取决于 Embedding 模型和切块策略不是“丢进去就能用”。5. 本地部署大模型并添加记忆环境准备无论用哪个框架本地部署大模型 记忆系统都遵循同一套流程启动推理模型、启动 Embedding 模型、选择存储介质、配置记忆读写逻辑。以下给出通用步骤具体版本和路径按实际项目调整。先看环境清单检查项说明操作系统Linux 服务器或 Windows/WSL 均可推荐 LinuxGPU有 NVIDIA 显卡最好没有也可用 CPU 跑小模型内存8GB 起步跑 7B 模型建议 16GB 以上磁盘模型文件 5GB 到 20GB 不等另留存储空间Python3.9 到 3.11 均可模型运行器Ollama 或 vLLM向量库Chroma、FAISS、Milvus 等端口规划Ollama 默认 11434自建服务预留独立端口如果只做记忆功能验证不需要一开始就上大显存显卡。Embedding 模型非常轻量CPU 跑完全没问题推理模型可以先用 1.5B 或 3B 的小模型验证流程通了以后再换大模型。6. 安装部署与启动方式6.1 快速启动 Ollama 模型服务Ollama 是目前本地部署大模型最方便的工具之一支持一键下载模型并暴露 API。以 Linux/macOS 为例# 安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 拉取推理模型 ollama pull qwen2.5:7b # 拉取 Embedding 模型 ollama pull nomic-embed-text # 启动服务默认端口 11434 ollama serve启动后可以测试接口是否正常curl http://127.0.0.1:11434/api/generate -d { model: qwen2.5:7b, prompt: 你好用一句话介绍你自己 }注意如果 Ollama 已经在后台运行ollama serve会提示端口被占用直接访问 11434 即可。模型文件默认存储在~/.ollama/models下磁盘空间不足时可以设置OLLAMA_MODELS环境变量改路径。6.2 在 Windows 上部署Windows 推荐使用 Ollama 官方安装包安装后直接执行ollama pull qwen2.5:7b ollama pull nomic-embed-text ollama serve然后打开浏览器访问 http://127.0.0.1:11434 确认服务状态。如果你用的是老显卡建议先确认驱动是否支持 CUDA如果不支持就选 CPU 推理的小模型。6.3 vLLM 高并发部署如果需要更高并发或批量推理可以用 vLLM。它是专门为高吞吐推理设计的框架适合把大模型部署成 API 服务# 安装 vLLMLinux CUDA 环境 pip install vllm # 启动 OpenAI 兼容 API 服务 python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --host 127.0.0.1 \ --port 8000启动后客户端可以用 OpenAI SDK 风格调用。vLLM 的显存占用和模型量化精度有关系首次启动会做 warmup实际显存以任务管理器或nvidia-smi观察为准。6.4 自建记忆服务推理模型启动后还需要一个“记忆服务”来统一管理写入和检索。最简单的做法是写一个 Python FastAPI 服务内部依赖向量库和 Embedding 模型。from fastapi import FastAPI from pydantic import BaseModel from langchain_ollama import OllamaEmbeddings from langchain_community.vectorstores import Chroma app FastAPI() embeddings OllamaEmbeddings(modelnomic-embed-text) vectorstore Chroma( persist_directory./memory_db, embedding_functionembeddings ) class MemoryItem(BaseModel): user_id: str content: str class QueryRequest(BaseModel): user_id: str query: str top_k: int 5 app.post(/memory/write) def write_memory(item: MemoryItem): vectorstore.add_texts( texts[item.content], metadatas[{user_id: item.user_id}] ) return {status: ok} app.post(/memory/query) def query_memory(req: QueryRequest): docs vectorstore.similarity_search(req.query, kreq.top_k) results [ {content: d.page_content, metadata: d.metadata} for d in docs ] return {results: results}启动这个服务后大模型应用就可以通过 HTTP 接口写入用户记忆和读取相关记忆了。生产环境建议用 Milvus 或 Qdrant 替代本地 Chroma并加上用户权限过滤。7. 给大模型应用接入记忆功能测试与效果验证框架搭好之后下面做一套简单的功能测试验证记忆是否真的生效。测试目标不是看模型多聪明而是确认“写入的记忆能查到查到的内容能进入提示词”。7.1 记忆写入测试先写入一条明确的用户偏好curl -X POST http://127.0.0.1:8000/memory/write \ -H Content-Type: application/json \ -d { user_id: xiaowang, content: 小王是运维负责人喜欢预算保守的解决方案关注系统稳定性。 }预期返回{status: ok}。如果失败检查记忆服务是否启动、向量库目录是否可写、Embedding 模型是否可用。7.2 记忆检索测试再查询这条记忆curl -X POST http://127.0.0.1:8000/memory/query \ -H Content-Type: application/json \ -d { user_id: xiaowang, query: 小王选方案时在意什么, top_k: 3 }预期结果里应该包含“预算保守”“稳定性”这些关键词。如果没有检索到先看提问表述和原文差异是否过大再调整切块大小和 TopK 参数。7.3 带记忆的大模型问答测试检索到记忆后把它拼进提示词再让大模型回答curl http://127.0.0.1:11434/api/generate -d { model: qwen2.5:7b, prompt: 根据以下记忆信息回答问题。\n记忆信息小王是运维负责人喜欢预算保守的解决方案关注系统稳定性。\n问题请为他推荐一个监控方案。, stream: false }判断成功的标准回答里出现了“稳定性”“成本控制”等与记忆匹配的内容。如果模型完全没用到记忆说明提示词拼接逻辑需要调整或者检索到的记忆片段和问题不相关。7.4 批量记忆导入测试长期记忆不可能一条条手写通常要批量导入历史对话、业务文档或用户标签。推荐流程是文本切块 - 批量 Embedding - 批量入库 - 人工抽检检索效果。import requests docs [ 用户A偏好使用 Grafana 展示监控数据。, 用户A的告警阈值是 CPU 使用率超过 80% 时通知。, 用户A所在的团队有 5 名运维工程师。, ] for doc in docs: resp requests.post( http://127.0.0.1:8000/memory/write, json{user_id: user_a, content: doc}, timeout30, ) print(resp.status_code, resp.json())批量导入的重点不是“全量入库”而是导入后的检索准确率。建议每导入一批就抽几条和业务相关的 query 测试检索结果必要时调整切块策略或重选 Embedding 模型。8. 接口 API 与批量任务设计如果要把记忆能力集成到现有系统里不能只停留在 Python 函数调用层面。推荐把记忆服务封装成独立 API方便不同业务模块调用。接口方法用途/memory/writePOST写入一条用户记忆或文档记忆/memory/queryPOST查询与输入最相关的记忆/memory/deletePOST删除指定用户或指定内容的记忆/memory/clearPOST清空一个用户的所有记忆/memory/batch_importPOST批量导入历史对话或文档/memory/statsGET查看当前记忆库规模、向量数量批量任务设计上要注意三个点。第一批量导入建议异步执行用任务队列接住避免一次性阻塞 API。第二每条记忆都加user_id、timestamp、source等元数据方便后续做权限控制和过期清理。第三记忆库要有幂等机制同一批数据重复导入时不能产生大量重复向量否则检索结果会被重复片段污染。下面是一个异步批量导入的简单示意from fastapi import BackgroundTasks def do_batch_import(items): for item in items: vectorstore.add_texts( texts[item[content]], metadatas[{user_id: item[user_id], source: import}] ) app.post(/memory/batch_import) async def batch_import(payload: dict, background: BackgroundTasks): items payload[items] background.add_task(do_batch_import, items) return {status: accepted, count: len(items)}这个接口适合处理“历史聊天记录一次性导入”“知识库全量重建”等场景。需要注意的是异步任务要搭配日志和重试机制不然大量导入时中途挂了很难排查。9. 资源占用与性能观察“给大模型做记忆”并不等于只跑一个大模型。实际系统里有推理模型、Embedding 模型、向量库、记忆服务四部分资源占用要分开看。推理模型占大头。7B 模型在 GPU 上通常需要 6GB 左右显存在 CPU 上则取决于内存和量化等级。显存不足时可以换量化版本或改用 1.5B 小模型。Embedding 模型非常轻量。比如 nomic-embed-text 这类模型CPU 也能跑批量向量化时主要吃内存。向量库Chroma 本地模式占用很小Milvus、Qdrant 这类独立服务要单独计算内存和磁盘。记忆服务FastAPI 这类轻量服务占用很小主要瓶颈在向量检索并发。观察资源占用的方法GPU 显存nvidia-smi -l 2每隔两秒刷新一次。CPU 和内存top或htop。向量库磁盘du -sh ./memory_db。接口耗时在记忆服务里给每个查询加计时日志。如果发现检索速度慢优先查这几个方向索引类型是否选对、向量维度是否过大、单次查询返回的 TopK 是否过高、向量库有没有分区。检索慢和大模型推理慢是两回事先定位瓶颈再调优。降低显存占用的通用手段包括模型量化GGUF/Q4、使用更小模型、减小上下文长度、关闭非必要工具进程、给 embedding 和推理模型分机部署。具体数值必须以本机实际测试为准不建议照搬网上的“某某卡占用几 G”的结论。10. 常见问题与排查方法问题现象可能原因排查方式解决方案模型下载慢或失败网络不稳定、磁盘空间不足检查磁盘剩余空间和网络换镜像源或用离线文件导入模型Ollama 端口无法访问服务未启动或端口被占用curl 127.0.0.1:11434lsof -i重启服务或修改OLLAMA_HOST显存不足导致生成失败模型过大或并发太高nvidia-smi查看显存换量化模型降低并发减小上下文记忆写入成功但检索不到文本切块不合理或 Embedding 效果差直接打印检索结果检查关键词调整切块大小换 Embedding 模型检索到的记忆和问题无关向量相似度区分度不够检查 TopK 和阈值加相关性阈值或给记忆加标签过滤批量导入重复数据没有幂等机制查看入库记录按source content hash去重接口调用报 502 或超时服务崩溃或负载过高查看日志、检查并发加负载控制任务改异步Agent 任务中断后状态丢失没有做 Checkpoint查看是否有持久化状态存储使用 LangGraph Checkpoint 或自建任务状态表排查思路只有一条先确认服务是否活再确认数据是否在最后确认检索链路是否通。不要一上来就怀疑模型能力大多数记忆失效问题出在存储和拼接阶段。11. 最佳实践与使用建议给大模型做记忆工程上建议遵守下面几条。第一记忆和业务数据分离。不要把用户的所有原始聊天记录都塞进记忆库更不要把密码、密钥、身份证号等敏感信息写入长期记忆。记忆库里只保留“对后续任务有用的摘要化信息”。第二权限控制必须前置。不同用户的数据要隔离查询时带上user_id过滤条件。如果自建服务面向内部使用至少限制访问 IP 和端口如果部署在公网必须加认证。第三先小参数测试再上全量。第一次跑通记忆链路时用最小模型、最小数据量、单用户测试。链路没有问题后再扩展模型规模和用户量。第四保留一个最小可运行配置。把启动 Ollama、启动记忆服务、安装依赖的命令和版本记录成文档。环境坏了可以快速恢复不用重新踩坑。第五定期清理过期记忆。长期记忆不是只增不减。用户偏好会变业务规则会更新旧记忆如果不清理不仅占存储还可能干扰检索结果。建议给记忆加时间戳按业务需要做过期策略。第六涉及人脸、声音、用户行为、版权内容时必须确认授权和合规边界。这是底线问题不是技术问题。大模型记忆系统里如果存了用户的历史对话和偏好需要履行告知义务并允许用户删除。12. 总结与下一步郝建业团队半年内完成三轮融资说明“给大模型做记忆”已经从一个技术概念变成了被资本认可的基础设施方向。对于技术人来说这个方向最大的价值在于它不需要你去训练模型只需要在模型外面搭一层记忆管理层就能让大模型在真实业务里“记住”该记住的东西。这篇文章给出的路线是用 Ollama 或 vLLM 部署推理模型用 Embedding 向量库做长期记忆存储再用 FastAPI 封装成记忆服务通过 HTTP 接口接入大模型应用或 Agent 工作流。整套方案可以本地部署支持批量导入也支持按用户隔离。下一步你可以先做三件事第一用一个小模型跑通“写入记忆 - 检索记忆 - 拼接提示词”的最小闭环第二导入你自己的历史对话或文档抽几条真实问题测试检索准确率第三把记忆服务封装成 API接到你现有的 Agent 或聊天机器人里观察是否解决了“换会话就失忆”的问题。最容易踩的坑有两个一是把长期记忆理解成“所有历史都塞进上下文”导致成本和效果双双恶化二是只做存储不做检索质量验证结果记忆库建好了真正查询时却拿不到有用信息。先把这两点做好大模型记忆就算真正落地了。