做 AI Agent 时很多人很快会遇到一个问题Agent 到底要不要记忆如果没有记忆它每次都像第一次见用户。用户前面说过的偏好、已经完成的步骤、失败过的尝试、业务里的关键上下文都要重新讲一遍。但如果什么都记它又会变得很危险。旧信息会污染新任务错误结论会被反复引用隐私数据会被长期保存向量库里一堆碎片最后谁也不知道哪条该信。所以 Agent 记忆不是“把聊天记录存起来”这么简单。一句话先压住Agent 记忆的核心不是存更多东西而是让系统在正确时间找回正确信息并且知道这条信息能不能信。记忆设计做得好Agent 会像一个靠谱同事知道背景记得偏好理解进度不重复犯错。记忆设计做得差Agent 就会像一个把所有便签都贴在脸上的人什么都看过但分不清新旧、真假、轻重。为什么普通聊天记录不等于记忆最直觉的做法是把所有历史对话都塞回上下文。这在很短的任务里可以工作。比如用户连续问三轮问题模型需要知道上一轮提到的变量名、文件名、产品名。直接保留聊天记录就够了。但 Agent 一旦进入长任务聊天记录会马上暴露问题。第一太长。Agent 每一步都会产生新内容模型思考、工具调用、工具结果、错误日志、用户确认、文件 diff、测试输出。如果全部塞进上下文成本会越来越高重点会越来越稀。第二太乱。聊天记录是按时间排列的但决策需要的是按任务结构排列的材料。模型要知道当前目标、已完成事项、待办事项、关键约束、失败原因而不是重新读一遍流水账。第三真假混在一起。对话里有用户猜测、模型草稿、工具真实结果、旧计划、已废弃方案。如果系统不区分它们模型很容易把“曾经的假设”当成“已经验证的事实”。第四旧信息会过期。用户上周说“默认用 A 方案”今天可能已经改成 B。企业制度、接口文档、业务状态也会变化。记忆不是写进去就永远有效。所以聊天记录只是原始材料不是可用记忆。一个更好的 Agent 记忆系统至少要把记忆拆成几类。第一类短期记忆短期记忆解决的是当前任务的连续性。它类似工作台上的材料当前目标是什么刚才做了什么下一步准备做什么哪些文件已经看过哪些命令已经跑过哪些假设已经被否定。短期记忆通常应该放在当前上下文或任务状态里而不是永久写入长期存储。比如一个代码 Agent 正在修测试目标修复 UserServiceTest 中的空指针失败 已查看UserService.java、UserRepository.java、测试输出 发现失败发生在 createUser 时 profile 为空 已尝试加默认 profile测试仍失败 下一步检查测试 fixture 是否缺少 profile 初始化这比塞一整段日志有用得多。短期记忆的关键是“压缩但不丢决策信息”。它不需要保留所有原文只要保留当前任务继续推进所需的状态。常见内容包括当前目标任务计划已执行动作工具结果摘要已验证事实已否定假设待办事项用户刚确认的约束。短期记忆通常有生命周期。任务结束后它要么被丢弃要么被整理成少量可复用经验再进入长期记忆。第二类长期记忆长期记忆解决的是跨任务复用。比如用户偏好、项目约定、团队规范、长期事实、反复出现的问题、已经确认的业务背景。这些信息不应该每次都让用户重讲。但长期记忆必须更克制。因为一旦写进去它就会影响未来很多次任务。适合长期记忆的内容一般有几个特征稳定不是临时状态可复用不只对当前一步有用已确认不是模型猜测范围清楚知道适用于哪个用户、项目或业务不包含不该长期保存的敏感信息。比如用户偏好技术博客使用“先一句话压住再分层解释”的结构。 项目约定文章封面使用 1200x675 信息图风格PNG 放在 covers 目录。 团队规范生产接口返回统一 envelope不直接返回裸数组。这些就比较适合长期记忆。不适合长期记忆的内容包括一次性的临时命令输出未验证的猜测过期的错误日志用户随口提到但没有确认的偏好密码、token、身份证、完整支付信息会频繁变化的业务状态。长期记忆的难点不是存而是写入策略。系统必须决定什么能写、谁确认、保存多久、什么时候删除。最偷懒但靠谱的原则是默认不写长期记忆只有稳定、确认、可复用的信息才写。第三类向量记忆向量记忆是最容易被误解的一类。很多人一说 Agent 记忆就想到向量数据库把历史对话切块转成 embedding之后相似问题来了就召回。这确实有用但它不是完整的记忆系统。向量记忆擅长解决的是“语义相似召回”。用户现在的问题和过去某段内容很像系统可以把那段内容找回来。比如用户问“之前我们怎么规定文章参考资料格式”向量检索可能召回过去一次关于博客格式的讨论。但向量记忆有几个天然限制。第一它不理解权威性。相似不等于可信。一个旧草稿、一条错误结论、一次用户吐槽都可能和当前问题很相似。第二它不天然处理时间。向量距离不会自动知道哪个版本更新。没有 metadata旧规则可能覆盖新规则。第三它不擅长精确状态。“当前任务做到第几步”“某个测试是否已经通过”“用户今天是否确认了发布”这些更适合结构化状态而不是向量搜索。第四它容易召回噪声。对话切得太碎会丢上下文切得太大又会带入无关内容。召回 top-k 也不代表 top-k 都该进模型上下文。所以向量记忆应该被看成一种检索工具而不是 Agent 的大脑。比较稳的做法是向量库只存可被召回的文本材料每条记忆带 metadata来源、时间、作用域、可信等级、是否过期召回后再 rerank 或过滤进入上下文时标注“这是历史记忆不一定适用于当前任务”关键事实不要只靠向量记忆最好有结构化来源。第四类结构化状态很多 Agent 需要的不是“记忆”而是状态。状态和记忆不一样。记忆是过去的信息状态是当前系统事实。比如当前订单是否已退款当前任务是否完成某个文件是否已修改用户是否授权执行写操作测试是否已通过当前 workflow 走到哪一步。这些东西不应该放在自然语言记忆里也不应该靠模型回忆。它们应该放在数据库、任务表、状态机、日志或文件系统里。比如一个客服 Agent 不能因为“记得用户想退款”就直接说“退款已完成”。它必须查订单系统确认退款状态。一个代码 Agent 不能因为“记得测试好像通过了”就结束任务。它必须有真实测试命令的返回码。结构化状态的好处是可验证、可查询、可审计。模型可以读取和解释状态但不能替代状态本身。这是 Agent 工程里很重要的一条边界能用数据库、状态机、日志解决的东西不要交给模型记。模型负责理解和决策系统负责保存真实状态。记忆什么时候进入上下文有了记忆之后下一步问题是什么时候给模型看最差的做法是每次都把所有记忆塞进去。这会制造上下文污染。更好的做法是按任务需要取记忆。比如一次技术写作任务可能只需要用户写作风格、已有文章目录、封面规范。它不需要用户上个月调试数据库的记录。一次代码修复任务可能需要项目规范、最近失败日志、相关文件摘要。它不需要用户的内容偏好。所以记忆注入应该有筛选当前任务属于什么类型当前用户是谁当前项目是什么是否需要长期偏好是否需要历史案例是否需要结构化状态召回记忆是否足够新、足够可信、足够相关。注入到上下文时也要给模型讲清楚记忆的性质。不要这样用户喜欢短文章。更好的写法是长期偏好用户确认于 2026-07-09技术博客偏好开头先给核心判断正文分层解释结尾一句话总结。加上来源、时间、作用域模型就不容易把一条模糊记忆误用到所有场景。记忆最怕什么Agent 记忆最怕三件事。第一记错。模型把一次临时指令总结成长期偏好或者把未验证假设写成事实。以后每次都会被这条错记忆污染。第二记太多。什么都存最后召回出来的都是噪声。记忆系统会变成第二个垃圾上下文。第三忘不掉。用户偏好会变项目规则会变敏感信息应该过期错误经验应该删除。不能删除的记忆迟早会成为风险。所以记忆系统必须有删除和覆盖机制。一个简单实用的设计是给每条长期记忆加几个字段content记忆内容 scope适用范围用户级 / 项目级 / 组织级 source来自用户确认 / 文档 / 工具结果 / 人工录入 confidence可信等级 created_at创建时间 updated_at更新时间 expires_at可选过期时间不需要一上来做很复杂。先把这些字段想清楚已经能避开很多坑。一个最小可用的 Agent 记忆设计如果从零做一个 Agent不建议第一天就上复杂记忆系统。一个最小可用版本可以这样做第一当前任务状态单独存。保存目标、计划、已完成步骤、关键工具结果、待办项。任务结束后清理。第二长期记忆默认人工确认。模型可以建议“这条信息适合记住”但真正写入要用户确认至少在早期产品里应该这样。第三向量记忆只做辅助召回。召回出来的历史材料必须带来源和时间不能直接当事实。第四结构化事实查系统。订单状态、权限状态、测试结果、部署状态都从真实系统查不靠模型记。第五支持删除。用户可以查看和删除记忆。项目规则变更时可以覆盖旧记忆。这已经能覆盖大多数早期 Agent 产品不需要一开始就做“类人长期人格记忆”。最后总结一下Agent 记忆不是把所有历史聊天都存进向量库。短期记忆负责当前任务连续性长期记忆负责跨任务复用向量记忆负责语义召回结构化状态负责真实系统事实。它们解决的问题不同不能混成一锅。最重要的原则是少记、准记、可删、可验证。一句话总结Agent 的记忆不是为了让模型什么都想起来而是为了让它在需要的时候拿到可信的上下文同时不要被旧信息拖下水。