2024 年到 2025 年AI 行业出现了一个有趣的变化大模型的参数竞争慢慢进入平台期反而是一个听起来很“软”的方向开始拿融资、出产品、进企业项目这就是“给大模型做记忆”。郝建业团队半年完成三轮融资就是一个非常典型的信号。为什么资本会连续下注这个方向因为大模型在本体设计上是无状态的它天生不记得用户说过什么、之前做过什么决策而几乎所有真实业务场景都在要求模型“记得住”。这篇文章不写融资八卦重点拆解三件事大模型记忆到底解决什么问题当前主流技术路线有哪些以及一个最小可运行的记忆层怎么落地。文章会先讲清楚“无状态”这个底层前提再给出技术分层和路线对比然后用三份可以直接复制的代码演示云端 API 和本地大模型两种接入方式。最后还会补充记忆生命周期、影响范围分析、常见排错和工程建议。如果你想在企业知识库、智能客服、Agent 或本地部署大模型项目里引入“记忆能力”这篇内容可以给你一个相对完整的参考。1. 为什么“给大模型做记忆”越来越重要1.1 无状态背后是隐藏成本很多人第一次接触大模型时会有一种错觉模型能记住我前面说的话。这不是错觉而是工程上做了大量“讨巧”的处理。模型每次接收请求时只看到当前传入的 tokens 和模型权重它不会因为你昨天问过某个问题就在今天自动保留那段记忆。你感觉到的“记忆”其实是调用方把对话历史重新拼进 prompt让模型重新读一遍。这种方案在短对话里没问题但在真实业务里很快就会暴露短板。以智能客服为例用户说“帮我查一下我名下所有订单”客服机器人把订单列表返回后用户接一句“第三个订单现在到哪了”。如果上一轮上下文没有传进去模型根本不知道“第三个订单”指的是什么。于是工程上必须把十几轮对话完整拼进 prompt每轮都重复传一遍。对话越长Token 成本越高响应延迟越大一旦超出上下文窗口最早的对话就被截断用户又回到了“模型失忆”的状态。这就是大模型记忆的第一层价值把“每次临时塞历史”改成“关键信息提取后外部持久化”。从成本角度看它省的是大量重复 Token从体验角度看它解决的是跨会话记忆从架构角度看它把大模型从“无状态 API”变成了“有状态系统”。这三点叠加起来足够解释为什么资本开始集中关注这个方向。1.2 记忆是 Agent 和应用层的地基再向下看一层Agent 类应用对记忆的依赖比聊天场景更强烈。Agent 在执行一个多步任务时往往需要调用多个工具、读取多份数据、做多次判断。假设 Agent 正在处理“整理本季度客户反馈并生成分析报告”这个任务它先查询客户数据库再调用舆情接口再读取历史工单。如果每一步之间不共享状态任务在第二步中断后就没有办法恢复现场。所以业界的共识逐渐清晰没有记忆的 Agent 是不可靠的。它就像一个只有短期记忆的员工做着做着就忘记自己为什么做这一步。记忆层一旦建立Agent 就能在暂停后继续执行在多次交互后积累用户偏好甚至在多个会话之间保持统一的业务口径。这也是为什么很多团队把“记忆”列为 Agent 工程的核心模块优先级甚至高于提示词优化。1.3 融资信号背后是真实的客户痛点回到郝建业团队半年三轮融资这件事。在整体融资环境偏谨慎的情况下能从投资方拿到连续注资通常意味着项目已经卡在明确的客户痛点上而不是只有一个宏大叙事。企业客户买大模型 API 或者本地部署私有模型之后很快会发现调用模型本身并不难难的是让模型在接入企业知识时保持一致性。传统 RAG 只能做到“查询时喂知识”但企业更需要的是“跨会话积累客户偏好、项目状态、历史决策依据”。这些数据散落在关系数据库、工单系统、CRM 和聊天记录里模型每次只能看到孤立的片段没法形成连续理解。简单说企业里真正值钱的不是模型的一次性回答而是围绕业务形成的长期记忆。谁把这一层做好谁就能在大模型应用链路上占据一个不可替代的位置。这不是短期的热点而是 AI 基础设施的一个新分支。2. 大模型记忆的技术分层与核心概念2.1 短期记忆与长期记忆给大模型做记忆不能只停留在“加一个向量库”这种笼统概念上。更合理的做法是先做技术分层。从工程角度看记忆至少应该分成两层短期记忆和长期记忆。短期记忆的载体是上下文窗口、System Prompt、KV Cache 和会话缓存。它的生命周期很短往往只存在于一次会话或几轮对话里。优点是实现简单缺点是每次请求都会重复传递成本高而且受窗口大小限制。长期记忆的载体是向量数据库、知识图谱、外部缓存和普通的业务数据库。它可以在多次会话之间持久保留写入一次、按需检索不用每次都把完整历史塞进 prompt。这里特别要提一下 KV Cache。KV Cache 是推理阶段的中间缓存用来避免重复计算注意力权重它确实提升了推理速度但它不等于我们讨论的“记忆”。把 KV Cache 单独拿出来说是因为很多文章会把缓存、记忆、上下文三个概念混在一起容易让新手产生误解。简单判断标准看数据是否存在模型外部是否跨会话复用。如果只是当前请求内部加速那是缓存如果能在下次会话被检索出来那才是记忆。2.2 关键概念Embedding、向量检索、RAG要把记忆落到系统里有三个概念绕不开。第一是 Embedding也就是文本向量化。它把一段文本转换成一组浮点数语义相近的文本在向量空间里距离也更近。常用模型包括 OpenAI 的 text-embedding-3-small、本地的 nomic-embed-text 等。第二是向量检索。用户的查询先被转成向量然后在向量库里找最相似的历史记忆按相似度分数返回 top-k 条。工程上常见实现有 faiss、chromadb、pgvector甚至可以用 numpy 写一个最小版本。第三是 RAG检索增强生成。它的核心思想是在生成回答之前先从外部知识库检索相关片段再把这些片段拼进 prompt。RAG 解决的是“模型不知道的知识”比如企业内部的规章制度、产品文档、技术手册。很多人会把 RAG 和记忆层混淆。严格来说RAG 主要做查询时的知识检索而记忆层做的是跨时间的状态积累。实际项目中两者经常组合RAG 负责外部知识记忆层负责对话历史和用户画像。理解这个边界比单纯选一个框架更重要。3. 主流实现路线对比3.1 五条路线横向对比给大模型做记忆并没有统一标准答案。当前工程界大致有五条主流路线各有侧重下面用一张表做横向对比技术路线核心思路优势风险典型场景长上下文扩展扩大窗口把更多历史塞进 prompt实现简单不需要额外存储成本高、长文关键信息稀疏、仍会触顶小型工具、临时会话RAG 外挂知识库查询时检索文档片段再回答可更新、可控性高不能解决跨会话对话记忆企业知识库问答向量记忆层把对话和画像写入向量库按语义检索跨会话持久化、成本低写入策略和更新策略复杂智能客服、个人助手知识图谱记忆抽取实体关系形成结构化知识网络可解释、精确、可追溯构建成本高、更新困难金融、医疗等强监管场景记忆 Agent 框架用虚拟上下文自动管理短期和长期记忆自动化程度高框架较重、黑盒控制多复杂多轮 Agent 任务3.2 路线选择判断从投入产出比看我建议多数团队走“RAG 加向量记忆层”的组合路线。理由很实际RAG 负责企业静态知识向量记忆层负责动态对话积累两者互补技术栈通用成本可控。知识图谱不是不好而是在大多数业务里维护成本偏高适合对准确性要求极高、数据类型相对稳定的行业。长上下文扩展则更像一块“补丁”可以解决临时需求但长期使用并不划算。从资本角度看大模型记忆方向之所以能连续融资也侧面验证了路线正从概念走向工程化。将来各家的差异大概率不在“有没有记忆”而在“记忆写得好不好、检索准不准、忘得对不对”。4. 环境准备与前置条件4.1 安装 Python 依赖本文的示例代码使用 Python 3.9 以上版本主要依赖只有两个openai 和 numpy。如果你走本地大模型路线还需要安装 requests。先创建一个测试目录并初始化虚拟环境推荐命名和路径保持一致方便后续复制操作。mkdir llm-memory-demo cd llm-memory-demo python -m venv .venv source .venv/bin/activateWindows 的 PowerShell 请换成.venv\Scripts\activate然后安装依赖pip install openai numpy requests pandaspandas 和 requests 不是必须的。pandas 只在“从关系数据库加工记忆”的演示里使用requests 只在调用本地 Ollama 时使用。如果你只想跑通最小示例一行命令就够pip install openai numpy4.2 选择大模型和 Embedding 模型代码里涉及两类模型对话模型和 Embedding 模型。云端方案可以使用 OpenAI 兼容接口Embedding 模型可以用 text-embedding-3-small维度是 1536。本地方案推荐用 Ollama 部署对话模型可以选 qwen2.5:7bEmbedding 模型可以选 nomic-embed-text维度是 768。有一点必须提前提醒向量维度必须一致。如果写入记忆时用的是 1536 维检索时用 768 维相似度计算会直接报错。记忆层代码里要预留维度校验或者在初始化时统一读取并保存维度信息。5. 完整示例实现一个带长期记忆的对话层5.1 项目结构本文示例由三个文件和一组数据文件组成llm-memory-demo/ ├── memory_layer.py # 极简记忆层序列化到 JSON ├── demo_chat.py # 云端大模型 记忆层示例 ├── local_chat.py # 本地 Ollama 记忆层示例 └── memories.json # 记忆数据文件运行后自动生成