这两年Agent 这个词被讲得太热了。一开始大家讨论的是模型会不会调用工具。后来讨论的是它能不能自己拆任务、跑代码、查网页、操作浏览器、调用 API。再往后大家开始讨论多 Agent、工作流、MCP、Computer Use、代码助手、个人助理、企业数字员工。但如果你认真用过一段时间 Agent会发现一个很朴素的问题它经常忘。你上周告诉它项目用 pnpm它今天又给你写 npm install。你昨天刚纠正过接口权限逻辑它今天又犯同样的错。你反复强调公众号文章要深入浅出、不要堆术语它下一次还是写成论文摘要。你让它帮你做长期项目它干到一半开始忘记最初目标。所以很多人会说Agent 需要记忆。这句话当然对。但问题在于很多人对记忆的理解太窄了。一提到 Agent 记忆最常见的反应是不就是把历史对话存进向量库然后相似度检索出来塞回 prompt 吗这个答案不能说错但它只讲到了第一层。如果 Agent 只是一个聊天机器人向量检索可能够用。但如果 Agent 要变成一个长期协作者一个能持续理解你、理解项目、理解组织规则、理解过去失败经验的系统记忆就不再是一个简单的存储 检索问题。它会变成一个更复杂的问题什么值得记记成什么格式谁来决定写入什么时候召回旧记忆和新事实冲突怎么办错误经验要不要删哪些记忆能影响行动哪些只能作为参考用户能不能查看和修改企业能不能审计和隔离如果把这些问题放在一起看你会发现Agent 记忆不是向量库而是一套管理过去的操作系统。它的任务是在正确的时间想起正确的东西同时知道什么时候该忘。这篇文章试着系统讲清楚 Agent 记忆机制。我们会从最基础的上下文窗口讲起一路讲到短期记忆、长期记忆、向量检索、结构化 profile、知识图谱以及 Claude Code、OpenClaw、LangGraph、Mem0、Zep、Letta、CrewAI 等框架到底在做什么。你可以把它当成一张 Agent 记忆地图。先拆掉一个误解大模型本身并不记得我们平时说模型记得上下文其实容易产生误解。大模型本质上是一个无状态函数。每一次调用接收输入输出响应。下次调用若不将历史内容重新作为输入提供模型并不知道此前发生过任何交互。所谓记得是应用层在背后做了几件事保存最近对话保存当前任务状态压缩旧上下文检索相关历史把这些内容重新放进 prompt模型并不凭空想起过去而是在回答前重新看见了过去。这个区别很重要。如果你以为模型本身有持久记忆就会把问题想得很神秘——好像只要模型越来越强长期记忆会自然解决。但如果明确记忆发生在模型外部就会立刻意识到Agent 记忆是一个工程架构问题。它需要存储系统、检索系统、上下文构造器、写入策略、更新策略、遗忘机制和权限治理。这也是为什么 Mem0、Zep、Letta、Supermemory、Honcho、Cognee 等记忆框架会独立成为专门基础设施。它们都在解决同一问题如何让一个本来无状态的模型表现得像一个可以长期协作的主体最原始的记忆上下文窗口最简单的记忆就是把历史直接放进上下文窗口。一个聊天 Agent 可能这样组织输入System Prompt 用户最近 N 轮消息 助手最近 N 轮回复 当前用户问题一个 Coding Agent 可能这样组织System Prompt 项目规则 当前任务目标 已读文件摘要 最近工具调用结果 当前计划 用户最新指令这就是短期记忆也叫工作记忆。它的特点是对当前任务很有用但生命周期短。任务结束后大部分可以丢掉。但它有两个天然限制第一容量有限。不管上下文窗口是 32K、128K 还是 1M token真实任务总有一天会撑爆它。第二长上下文 ≠ 好上下文。上下文越长模型越容易被无关信息干扰成本越高延迟越大。更大的问题是旧信息可能已经过时却依然混在上下文里影响判断。比如你早期说项目用 npm后来改成了 pnpm两条同时存在时模型不知道该信哪条。所以 Agent 记忆的第一课是不要把塞更多上下文当成记忆能力。真正的记忆能力是选择。摘要记忆用压缩换连续性当上下文太长时最直接的办法是总结。系统会把旧对话压缩成摘要只保留主线用户正在研究 Agent 记忆机制。已经讨论过 Claude Code、OpenClaw、LangGraph。偏好中文、结构化、深入浅出。下一轮对话时只放历史摘要 最近几轮原文这就是滚动摘要记忆rollup summary。Claude Code、OpenClaw、LangGraph、LlamaIndex 这类系统里都有某种形式的 compaction 或 memory flush。摘要记忆的优势便宜、简单、可解释。但风险也很明显风险说明丢细节模型觉得不重要的内容可能恰恰是未来任务的关键引入错误模型总结时可能把推测写成事实把临时结论写成最终决策错误滚雪球一旦摘要出错后续在错误基础上继续压缩记忆逐步偏离真实历史所以摘要适合承载主线不适合承载证据。低风险聊天场景没问题但在代码修改、医疗、金融、合同等需要追溯原始证据的场景不能只靠摘要。向量检索很多人以为这就是全部向量检索是目前最常见的长期记忆实现。流程如下向量检索流程典型实现代码以 ChromaDB 为例from uuid import uuid4import chromadbfrom sentence_transformers import SentenceTransformerembedder SentenceTransformer(all-MiniLM-L6-v2)collection chromadb.Client().create_collection(agent_memory)def add_memory(text): embedding embedder.encode(text).tolist() collection.add( ids[str(uuid4())], embeddings[embedding], documents[text] )def recall(query, k5): query_embedding embedder.encode(query).tolist() results collection.query( query_embeddings[query_embedding], n_resultsk ) return results[documents][0]这套机制允许 Agent 处理大规模历史数据按语义召回而非简单关键词匹配与 RAG、知识库、文档问答天然兼容。但它有一个根本限制向量检索解决的是相似不是可信。相似 ≠ 相关 ≠ 正确 ≠ 最新 ≠ 应被当前决策采用。举个例子。你过去和 Agent 说过三件事1. 我们准备用 npm。2. 团队后来决定改成 pnpm。3. 临时排查问题时可以试一下 npm install。当你问怎么安装依赖向量库可能把三条都召回。它们语义都相关但行动含义完全不同第一条是历史决定第二条是当前决定第三条是临时备选。如果没有时间排序、决策状态、冲突处理Agent 就可能做出错误判断。这就是为什么越来越多的 memory framework 不再满足于向量库 top-k而是开始加入更丰富的机制增强机制解决什么问题metadata filtering按作用域/时间/类型过滤recency weighting按时效加权旧记忆降权importance scoring区分哪些信息更关键entity extraction从文本中抽取实体和关系temporal graph表达事实随时间的演化memory consolidation合并重复、整合碎片contradiction handling检测并处理新旧冲突provenance tracking追溯每条记忆的来源user-editable memory用户可查看、修改、删除向量库仍然重要但它只是记忆系统里的一个器官不是整个人。结构化 Profile从碎片到用户画像如果 Agent 每次都从历史片段里猜用户偏好效率很低也不稳定。更常见的做法是把对话中稳定的信息抽取成结构化 profile{ language: zh-CN, role: 全栈开发者主力 TypeScript, project: my-saas-app, preferences: [ 项目使用 pnpm不要用 npm, API 路由统一放 src/routes/, 提交信息用英文格式遵循 Conventional Commits, 修改代码前先跑一遍测试 ]}ChatGPT 的 saved memories、Claude 的 memory、Mem0 的 user memory、Supermemory 的 user profile都有类似思想。结构化 profile 的优势优势说明可控Agent 直接读取字段无需从几十段历史中猜可编辑用户可以看到系统记住了什么可以修改或删除省上下文一份 500 字 profile 可替代数万字历史对话但 profile 有一个很大的工程难题更新。用户说我喜欢短文后来又说这篇我要万字长文。这到底是偏好变化还是某一次任务的特殊要求用户说项目用 React后来某个子项目用 Vue。系统应该覆盖原记忆还是增加作用域以下是一个冲突解决决策表情景处理策略“我喜欢短文” → “这篇我要万字长文”区分偏好 vs 特殊任务特殊任务不更新全局 profile“项目用 React” → 子项目用 Vue增加作用域字段scope不覆盖全局“准备马拉松” → “脚踝受伤暂时不跑”保留历史目标标记旧目标为 suspended同一来源、时间晚者冲突按时间覆盖保留旧值作为历史证据不同来源、置信度不同保留双方标记来源和置信度一个成熟的 profile 记忆系统至少要处理这些维度作用域全局偏好 / 项目偏好 / 会话偏好时间长期稳定状态 / 近期状态 / 临时约束冲突新旧事实如何合并置信度用户明确说的 vs 模型推断的来源用户 / 文件 / 工具 / 第三方敏感性是否应该保存所以 profile 记忆看起来简单真正做好很难。情节记忆记住自己做过什么对个人聊天助手来说记住事实很重要。但对工具型 Agent 来说记住自己的经历更关键。这就是情节记忆episodic memory对过去特定经历的记录。比如一次代码修复的任务轨迹{ task: 修复登录失败,context: 用户反馈线上 401 错误增多,plan: 检查 auth middleware 和 refresh token,actions: [读取 auth.ts, 运行 auth 测试],observations: [refresh token 判断条件写反],fix: 调整判断逻辑,outcome: 测试通过,lesson: 遇到 401 时优先检查 refresh 分支,timestamp: 2026-06-13T10:00:00Z,successful: true}它记录的是一段完整的任务轨迹。下次遇到类似问题Agent 可以检索这段经验作为行动参考。这类记忆对 Coding Agent、运维 Agent、数据分析 Agent、自动化工作流 Agent 尤为关键。因为它们不只是回答问题而是执行任务。它们需要知道上次怎么成功的、上次哪里失败了、哪些工具有效、哪些路径应避免。但情节记忆也有风险坏经验会污染未来。如果 Agent 曾经用一种错误方案解决了问题后续召回该经验可能重复错误。所以一段好的情节记忆至少要包含任务是什么 → 环境是什么 → 采取了什么动作→ 观察到什么 → 是否成功 → 用户/测试如何反馈→ 这段经验是否仍然适用否则它不是记忆而是风险。程序性记忆从记住事情到改变做事方式人类记忆里有一种很重要的类型叫程序性记忆procedural memory。它记住的是怎么做事骑自行车、打字、排查问题的流程。Agent 也需要这种记忆修改代码前先读相关文件。遇到测试失败先复现再定位再修复。用户要求 review 时先列风险和 bug再给总结。这些是反复使用的行为规则。Claude Code 的CLAUDE.md是非常典型的程序性记忆。开发者把构建命令、测试命令、代码风格、团队约定写进去Claude 每次会话启动时加载它就像读取项目的工作手册。OpenClaw 的SOUL.md、AGENTS.md、skills 也有类似作用既能记住事实也能塑造 Agent 的人格、工具使用方式和工作习惯。LangGraph 文档也把 procedural memory 列为三类长期记忆之一可以是系统 prompt、agent code、工具规则或通过 reflection 生成的新指令。程序性记忆的价值很大——它能让 Agent 越用越顺手。但它的风险也最大事实记错了影响一次回答规则记错了持续影响行为。如果 Agent 把用户临时允许跳过测试记成以后都可以不跑测试后果很严重。所以程序性记忆需要更强的治理哪些规则可以自动写入哪些必须用户确认是否需要版本记录和回滚是否区分项目级/用户级/组织级这里要特别注意一个区分记忆不是权限系统。你可以在记忆里写不要删除生产数据但真正防止删除的应该是权限、沙箱、审批和审计而不是希望模型乖乖遵守一段文字。记忆塑造行为倾向权限决定行为边界。两者不能混。三类长期记忆速查把前面三类长期记忆放在一起对比维度语义记忆Semantic情节记忆Episodic程序性记忆Procedural记什么事实、偏好、状态任务轨迹、经历行为规则、工作流示例“用户偏好中文”“上次修 401 的完整过程”“修改代码前先读文件”存储方式Profile 向量库事件日志 向量库规则文件 System Prompt召回策略按作用域直接读取相似任务匹配 时间窗口会话启动时加载核心风险推断当事实坏经验污染未来规则记错持续影响行为典型框架Mem0、ChatGPT MemoryHindsightClaude Code CLAUDE.md更新难度中冲突合并高经验评价高行为治理一个成熟的 Agent 记忆系统通常需要同时支持这三类。记忆的完整生命周期把以上机制抽象起来一个完整的 Agent 记忆系统有六个环节记忆系统六大环节很多系统只做了 Store 和 Retrieve所以看起来像向量库。但真正的难点集中在另外四端。捕获Capture什么信息值得写入记忆候选来源包括用户对话、助手回复、工具调用结果、文件内容、代码 diff、测试结果、环境状态。今天北京下雨对天气助手可能重要对代码助手没意义。编码Encode同一段信息可采用不同编码形态编码形态示例适用场景原始文本“用户说以后默认用 pnpm”可追溯适合证据保留结构化字段{project: app, pkg: pnpm}稳定读取适合 profile程序性规则“安装依赖时优先使用 pnpm”影响行为适合规则注入事件记录2026-06-13: npm → pnpm时间推理适合时序分析存储Store可选介质包括 prompt 上下文、本地文件、SQLite、Postgres、Redis、向量数据库、图数据库、对象存储、专用 memory service。召回Retrieve当前任务需要记忆吗需要哪类召回多少放在 prompt 哪个位置是否显示来源召回少了像失忆多了被噪声淹没。更新Update长期记忆的核心。用户说我不做这个项目了系统如何处理旧的项目偏好客户状态从潜在变已签约旧状态保留吗不能只 append-only也不能简单覆盖。遗忘Forget遗忘不是缺陷是能力。它可以是删除、降权、归档、过期、标记废弃。没有遗忘机制的长期记忆最终会变成长期污染。知识图谱的回归过去几年RAG 让向量数据库变得很流行。但 Agent 记忆发展到一定阶段知识图谱会重新变重要。原因很简单真实世界不是一堆相似文本而是一张不断变化的关系网。企业场景尤其典型客户 A 属于 金融行业客户 A 使用 产品 B产品 B 依赖 服务 C服务 C 最近出现 故障 D销售 E 负责 客户 A合同 F 将在 下个月 到期如果问“哪些下个月要续约、但最近受故障影响的金融客户需要销售优先跟进”——这不是向量检索能优雅解决的问题。它需要实体、关系、时间和多跳推理。以下是一个 Cypher 查询示例Neo4jMATCH (c:Customer)-[:BELONGS_TO]-(i:Industry {name: 金融}), (c)-[:USES]-(p:Product), (p)-[:DEPENDS_ON]-(s:Service), (s)-[:HAD_INCIDENT]-(inc:Incident), (c)-[:HAS_CONTRACT]-(ct:Contract)WHERE inc.time datetime(2026-05-01) AND ct.expires datetime(2026-07-01) AND ct.expires datetime(2026-08-01)RETURN c.name, inc.description, ct.expires图谱记忆可以表达谁和谁有关、关系何时建立、关系是否仍然有效、哪些事实互相冲突。当然图谱不是银弹构建成本高实体抽取错误会传播查询比向量检索更重。但在企业 Agent、CRM Agent、项目管理 Agent 等场景中图谱几乎是迟早要面对的方向。维度向量检索知识图谱核心能力语义相似度匹配实体关系 多跳推理适合场景“找一段相似文本”“理解一个动态世界”查询类型Top-K 近邻结构化图查询时间推理弱需额外机制强边带时间戳冲突处理无可能召回矛盾双方有可标记事实有效期构建成本低高代表框架Chroma、PineconeZep/Graphiti、Cognee产品实例对比不同 Agent 怎么做记忆理解具体产品会比抽象概念更直观。Claude Code代码库中心的记忆Claude Code 的记忆围绕代码仓库repo展开CLAUDE.md → 人写的项目说明和长期规则.claude/rules/ → 项目级规则文件auto memory → Agent 自动积累的调试经验和用户偏好session context → 当前会话的工作状态compaction → 超出窗口时的摘要策略它本质上是 repo-centric memory主要解决这个代码库怎么构建、哪些目录放什么、修改前要跑哪些测试、团队有什么约定、用户上次纠正过什么。通用个人 Agent跨场景的记忆面向个人日常协作的 Agent 需要更宽的记忆范围跨越多个工作场景和较长时间跨度。典型机制包括长期用户画像、每日笔记、混合检索关键词 向量、记忆整合短期信号晋升为长期记忆。这类 Agent 的关键是跨渠道、跨时间、跨工作流地理解你也就是 workspace-centric personal memory。企业 Agent业务上下文的记忆面向企业场景的 Agent 还需要关注用户日程和 App 使用习惯、企业系统状态、多角色 profile 隔离、本地数据处理、移动端上下文感知。强调不同用户角色之间的隔离与权限管控也就是 device/business-profile-centric memory。三者的核心差异维度Coding Agent个人助理 Agent企业 Agent记忆中心代码库个人工作空间设备 业务 profile核心内容构建规则、代码风格用户偏好、跨对话上下文日程、ERP、角色隔离记忆载体CLAUDE.md auto memory日志 向量库 人格定义本地数据 权限系统生命周期项目周期用户长期使用周期企业运营周期代表产品Claude CodeOpenClaw、Mem0Zep、Honcho这三个方向会长期并存。主流框架的记忆设计思路理解具体产品之后再来看框架。当前的 Agent 记忆框架设计思路差异很大。与其比谁更好不如看它们各自从哪个角度切入通用框架多 Agent / 通用应用记忆只是其中一个模块框架核心机制AutoGPTscratchpad 向量记忆 文件工作区早期自主 Agent 样本MetaGPTRole memory SOP 共享产物多 Agent 软件开发LlamaIndexChatMemoryBuffer VectorMemory SummaryRAG 深度集成AutoGenMemory protocoladd/query/update_context协议层抽象CrewAI统一 Memory 类LLM 推断 scope/importance多角色协作LangGraphcheckpoint store retriever instruction工程化最完整其中 LangGraph 的记忆设计最值得研究。它把状态、存储、检索、线程、命名空间都拆开了明确对应人类记忆的三类semantic事实、episodic经历、procedural规则。专门记忆框架记忆本身就是产品设计思路代表框架核心特点检索增强型Mem0、LlamaIndex Memory把信息存好需要时搜出来操作系统型Letta (MemGPT)、MemOS像操作系统管理内存和硬盘一样管理记忆认知推理型Hindsight、Honcho不止存和搜还要推理和更新信念协作共享型CrewAI多个 Agent 之间共享记忆图谱时序型Cognee、Zep/Graphiti 、Supermemory实体关系 时间推理理解动态世界这些框架共同指向一个趋势记忆系统正在从检索模块变成可学习、可演化、可治理的认知层。设计记忆系统前先问 8 个问题如果你正在做 Agent 应用不要一上来就选向量库。先问这 8 个问题问题 1你的 Agent 需要记住谁个人助手要记用户偏好。Coding Agent 要记 repo 规则。企业 Agent 要记组织知识和权限边界。不同对象需要不同 scope。问题 2需要记住什么类型事实 → 用户偏好、项目背景、业务状态经历 → 过去任务轨迹、失败案例、工具调用结果规则 → 工作流、行为约束、编码习惯不要把三者混在一个向量库里就完事。问题 3哪些记忆会影响行动有些记忆只是背景“用户喜欢简洁表达”。有些记忆会影响行动“生产环境必须审批后才能写”。后者不能只靠记忆要进入权限系统和审批机制。问题 4写入策略是什么策略适用场景自动写入低风险偏好、稳定事实用户确认行为规则、敏感信息从不写入临时信息、高隐私内容分层写入普通偏好自动记行为规则需确认问题 5如何处理冲突策略适用场景时间优先later wins偏好和状态的正常演进来源优先用户明说 模型推断 第三方作用域隔离同一实体的不同上下文显式决议高风险冲突如安全规则问题 6如何召回召回不是单纯 top-k。你可能需要综合语义相似度、关键词、时间、重要性、作用域、实体关系、当前任务、风险级别。问题 7如何遗忘遗忘可以是删除、过期、降权、归档、标记废弃、从当前 profile 移出但保留历史证据。问题 8用户如何控制记忆用户应该能知道 Agent 记住了什么、哪些记忆影响了这次回答、能不能改、能不能删。这是长期信任的基础。评估记忆系统不能只看召回率评估 Agent 记忆不能只看能不能找到历史片段。真正要看的是评估维度核心问题示例事实一致性能否正确回答过去明确说过的事实“上次说项目用 pnpm现在问用什么”时间推理是否理解事实随时间的变化一月说训练马拉松、三月说恢复低强度多跳推理能否跨多个记忆片段连接关系客户→产品→服务→故障哪些客户需安抚行动改善记忆是否降低了重复错误率Coding Agent 同类错误重犯率是否下降成本与延迟检索 p50/p99、token 消耗增量记忆系统不能又慢又贵可控性用户能否查看/修改/删除企业能否审计生产环境中比 benchmark 分数更重要7 个最常见的坑#坑表现解法1什么都记写入所有内容召回时噪声淹没信号实现重要性评估和写入过滤2只做向量检索向量库无法处理冲突、时间、权限融合 metadata、时间加权、冲突检测3没有作用域项目 A 的偏好污染项目 B增加 scope 字段查询时强制过滤4推断当事实“用户最近有点忙→ 存为用户偏好短回复”区分来源保存置信度5没有过期旧会议安排仍被召回实现 TTL、时间衰减或主动过期6记忆不可见用户不知道 Agent 记住了什么召回时附来源提供记忆查看界面7让记忆承担安全职责记住不要删生产数据就完事安全靠权限、沙箱、审批、审计记忆只辅助提醒结尾工具调用让 Agent 从会说变成会做规划能力让 Agent 从单步反应变成多步执行。记忆机制要解决的是另一个问题让 Agent 变成一个可以长期协作的伙伴。一个真正可靠的 Agent应该能记住你的稳定偏好忘掉过时的信息从失败中总结经验在相似任务中复用策略解释它为什么想起某段历史并且让你控制它能记什么、不能记什么。但这件事比想象中难。因为记忆不是越多越好。人类也不是靠记住一切来思考的。我们会压缩、抽象、遗忘、修正把经历变成经验把经验变成规则把规则再放回行动。Agent 也正在走这条路。从上下文窗口到摘要到向量检索到结构化 profile到情节记忆到程序性记忆到知识图谱到可推理的记忆网络。方向其实很清楚Agent 记忆正在从存历史走向管理过去。未来的 Agent 竞争模型强弱、工具多少、上下文长短是一方面记忆系统是否可靠同样关键。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】