AI Agent 的记忆系统远不止“记住更多”那么简单。当学习助理被过期记忆绑架，用旧判断指导新行为，产品体验反而更糟。本文深入拆解记忆的六种机制、类型与作用域，揭示真正的记忆系统如何在写入、召回与更新中做出选择，让 Agent 成为跨越时间的长期合作者。

假设你在用一个 AI 学习助理。

第一次见面，你告诉它：“Python 基础我已经学过了，别再讲变量和循环。我想用三周做出一个能跑的项目，讲解直接一点，发现我错了就指出来。”

当天的体验很好。它跳过入门知识，给你安排了异步请求、异常处理和项目拆分。可一周后，当你新开一个会话，它又从“什么是变量”讲起。你提醒它，它道歉；再过几天，它又忘了。

于是产品团队给它加上“长期记忆”。这回，它确实记住了你“Python 基础薄弱”。问题是，这条判断来自第一次摸底，之后一直没有更新。哪怕你已经能独立写异步请求，它仍然按初学者的方式安排课程。

前一种失败让人烦，后一种失败更隐蔽：Agent 看起来很懂你，实际上被一条过期记忆绑架了。

这正是 Agent 记忆系统最容易被低估的地方。很多方案把问题描述成“怎样让模型记住更多”，随后接入聊天记录、向量数据库或更长的上下文窗口。信息确实存下来了，产品却未必更好用。它可能在错误的时间想起一件正确的事，也可能把一次随口表达固化成长期偏好，甚至用旧信息替用户做出今天已经不合适的决定。

真正的记忆系统始终在做选择：什么值得留下，以什么形式留下，什么时候应该被想起，出现矛盾时相信谁，何时降低权重，何时彻底删除。存储只是其中一环。

如果模型决定 Agent 的能力上限，工具决定它能做什么，那么记忆决定了它能否跨越时间，成为一个不用每次重新认识的长期合作者。

没有记忆会重复询问，缺少治理的记忆则会持续放大旧判断。

一、Agent 说的“记忆”，究竟是什么

讨论记忆之前，先要澄清一个常被忽略的事实：大模型的一次推理，本身并不知道“上一次发生了什么”。

应用每次调用模型时，会把系统指令、当前消息、部分历史对话、工具说明和检索到的资料一起交给模型。模型只根据这次收到的输入生成下一段输出。下一次调用若不再提供这些内容，它不会凭空延续此前的关系。

所以我们日常感受到的“它还记得”，通常是应用层在背后做了工作：保存会话、重放历史、压缩旧消息、检索相关资料，或把提炼后的信息重新放回当前输入。

这里至少有六种机制经常被混在一起。

这张表里最关键的分界，不是数据存在哪里，而是它为什么存在。

聊天记录回答“过去说过什么”；知识库回答“外部世界有哪些资料”；会话状态回答“这件事做到哪一步”；记忆则要回答“过去的哪些信息，值得在未来某个时刻改变 Agent 的行为”。

因此，把全部聊天记录放进向量库，不会自动得到一套记忆系统。它只是获得了一个可搜索的历史仓库。仓库里可能同时存在“我每天六点起床”和“我最近改成夜班”两条记录；搜索能把它们找出来，却不会替产品判断哪条仍然有效。

更长的上下文窗口也没有消除这个问题。窗口变大，意味着桌面能摊开更多材料，但桌面不会替你决定哪一页最重要。论文《Lost in the Middle》发现，模型使用长输入时会受到信息位置影响，相关内容放在中间时，表现可能明显下降。近年的模型已经在改善长上下文能力，厂商也提供压缩、编辑和缓存等机制，但官方文档仍反复强调同一件事：更多上下文不自动等于更好的结果，过期和无关内容会分散注意力、增加延迟与成本。

Prompt Cache 更容易被误解。缓存复用的是已经计算过的相同输入，优化的是账单和响应时间。它不会理解“这条偏好已经变了”，也不会在缓存过期后留下可治理的长期信息。

可以给 Agent 记忆下一个更实用的定义：

Agent 记忆，是系统将过去的信息跨时间保留下来，并在合适的未来场景中有选择地提供给 Agent，从而影响判断或行动的一套机制。它必须同时具备形成、保存、召回、使用、更新和遗忘能力。

这个定义里，“影响未来”比“永久保存”重要得多。一条记录即使在数据库里躺了三年，只要从未在正确场景被调用，它对 Agent 来说就等于不存在；反过来，一条错误记忆若被频繁调用，会比完全失忆更糟。

几种机制可以协作，但承担的产品责任不同。

二、从人的记忆，走到 Agent 的记忆地图

人类记忆提供了一套很有启发性的词汇。心理学里，工作记忆负责临时保存并加工当前任务所需的信息；情景记忆让人回想经历；语义记忆保存事实与概念；程序记忆与“怎样做”有关；前瞻记忆则帮助我们在未来某个时间或条件出现时执行此前形成的意图。

Agent 研究借用了这些分类，但需要克制。服务器里没有海马体，向量数据库也不是电子大脑。类比的价值，在于提醒产品经理：不同信息承担的任务不同，不能全塞进一个“memory”字段里。

回到那位学习助理。

当用户正在完成“给请求增加超时重试”这道练习时，题目、当前代码、刚才的报错和已经尝试过的方案属于工作记忆。它们只在眼前这项任务里高频使用，任务结束后大部分都可以退出活动上下文。

上周用户第一次成功写出异步请求，过程中在哪一步卡住、用了什么提示、最终如何解决，这是一段情景记忆。它保留的是一次经历。未来遇到相似问题时，这段经历可以提供例子，也能帮助 Agent 避免重复使用无效的讲法。

“用户已经掌握 Python 基础”“更喜欢先看案例再听解释”“当前目标是完成一个小项目”，更接近语义记忆。这些内容被提炼成相对稳定的事实、偏好和关系，不需要每次还原完整对话。

“讲解新概念时，先给最小可运行例子，再指出容易出错的地方”“代码连续两次运行失败后，先检查环境而不是继续改业务逻辑”，属于程序记忆。它保存的是完成一类任务的方法，可能来自产品预设，也可能来自 Agent 对过往结果的总结。

“下周开始练异常处理”“项目完成后回头复盘三类常见错误”则带有前瞻记忆的性质。它不只是一条事实，还包含未来触发条件。若没有时间、事件或状态触发机制，这类信息即使被存下来，也很难在正确时刻转化成行动。

分类只是第一张坐标轴。另一张更容易被忽略的坐标轴，是作用域：这是谁的记忆，在什么边界内有效。

同一句“回答尽量简洁”，可能是某个用户的长期偏好，也可能只是本次任务的临时要求；“所有报告使用统一日期格式”可能是一个项目的约定，也可能是整个组织的规则。如果作用域没有区分，原本正确的记忆一旦跨边界使用，就会变成污染。

常见作用域至少包括：

• 会话级：只对当前对话有效，例如临时角色分工。
• 任务级：跨几次会话持续，任务结束后归档，例如一份研究报告的进度。
• 用户级：跟随同一用户长期存在，例如稳定偏好和明确目标。
• 项目级：只在一个项目内共享，例如项目术语、决定和限制。
• 组织级：多个用户或 Agent 共用，例如制度、模板和安全规则。

公开产品已经在强化这类边界。ChatGPT 的 project-only memory 会把可引用的上下文限制在同一项目；健康场景又使用独立记忆空间，避免健康信息流回普通对话。它们展示了一个非常朴素的原则：记忆的价值来自连续性，记忆的安全来自边界。

把“类型”和“作用域”交叉起来，才得到一张真正可用的记忆地图。产品经理讨论“要不要做长期记忆”时，最好把问题改成：“哪个作用域里的哪种记忆，需要保留多久，并在什么情况下被调用？”问题一旦这样问，方案会立刻具体很多。

同一条信息必须同时回答“它是什么记忆”和“它属于谁、在哪生效”。

三、一条记忆是怎样被写入、想起和改变的

现在让学习助理收到一句新消息：

“异步请求我已经能自己写了。昨天连续调试了两个小时，最后发现是环境变量没加载。下周我想重点练异常处理。”

最省事的做法，是把这句话原样存起来。可一句话里混着至少四种信息：能力变化、一次失败经历、可复用的排查经验和未来计划。它们的稳定程度、用途和有效期完全不同。

一套完整的记忆系统，会让这句话经历一条生命周期。

第一步是观察。系统保存原始事件，包括用户原话、发生时间、所属会话、相关任务和工具结果。原始事件是证据，不等于最终记忆。保留它的意义，是将来能够回答“这条记忆从哪里来”。

第二步是形成候选记忆。系统可以抽取出四个候选：用户已能独立写异步请求；曾因环境变量未加载导致长时间调试；排查类似错误时应先检查环境；下周计划练异常处理。至于“昨天调了两个小时”，是否值得长期保留，要看产品场景。对学习进度可能有用，对下一次代码问答未必有价值。

第三步是经过写入判断。一条候选信息不能因为“模型抽出来了”就直接成为事实。系统要考虑它是否明确、未来是否可能复用、是否足够稳定、能否追溯、是否与已有记忆重复，以及保存它会不会带来隐私或安全风险。

第四步是编码。通过写入判断的信息会被整理成适合长期使用的形式。与其保存整段对话，不如形成一条带来源和时间的能力状态：“用户已能独立完成基础异步请求，证据来自 7 月 16 日练习结果。”未来计划则应该写成包含触发条件的意图：“下一个学习阶段开始时，优先安排异常处理练习。”

第五步是去重、冲突处理与巩固。系统发现旧记忆里还有“用户处于 Python 入门阶段”，便不能简单把两条都留下。更稳妥的方式是保留历史，但标注旧状态何时失效，新状态从何时开始生效。几次相似经历还可以被总结成更高层经验，例如“遇到配置类报错时，用户容易直接修改业务代码；应先引导检查运行环境”。

第六步才是存储。有些信息需要常驻上下文，例如当前学习目标；有些适合放在结构化数据库里，例如阶段状态和时间；有些适合用向量检索，例如相似的历史练习；有些关系随时间变化，图结构更容易表达。选择介质之前，先要知道未来准备怎样查询和更新它。

第七步是召回。一周后，用户说“给我安排下一阶段”。系统先识别当前意图和作用域，再查找尚未完成的计划、最近能力变化、稳定学习偏好和相关失败经验。召回结果并非相似度最高的几段文本，而是这次决策真正需要的最小证据集。

第八步是注入与使用。记忆进入上下文时，还要经过压缩、排序和格式化。相比把一周前的长对话整段塞回去，给模型一段清楚的说明更有效：“基础异步请求已掌握；下一阶段目标为异常处理；用户偏好直接反馈；最近一次卡点来自环境配置。”

最后是反馈、更新和遗忘。如果用户完成了异常处理练习，前瞻任务应该被标记为已完成；如果用户纠正“我不是喜欢直接反馈，只是那天赶时间”，旧偏好需要降级或失效；如果某条信息长期未使用、风险高且价值低，就应进入过期或删除流程。

原始事件经过筛选、编码和巩固后成为记忆，再通过召回、使用和反馈持续变化。

这条链路可以分成快慢两条路径。

快路径发生在当前交互中。用户明确说“请记住我对花生过敏”，系统需要立刻保存或进入确认流程；回答眼前问题前，也可能需要即时召回相关记忆。它的优势是及时，代价是增加响应延迟，而且模型容易在任务尚未结束时草率下结论。

慢路径在后台完成。系统等一段对话结束，再统一抽取、去重、合并和压缩。它不会拖慢当前回答，也更容易结合完整结果判断什么值得留下；问题是更新存在滞后，新会话可能暂时看不到刚形成的信息。

真实产品通常会混合使用：明确偏好、安全约束、用户纠正走快路径；会话总结、经验巩固、低频事实抽取走慢路径。LangChain 的记忆文档也把写入区分为 hot path 和 background 两类。

走到这里，记忆服务与数据库的分工已经清楚了。数据库负责可靠保存；记忆服务围绕时间做一整套决定：哪些事件转成记忆，怎样组织，何时取回，如何解释来源，怎样改口，以及如何让用户真正删除它。

四、产品经理真正要做的，是六个决定

做 Agent Memory 需求时，最容易从“选向量库还是知识图谱”开始。这个顺序常常倒了。存储方案必须服从产品问题，而产品问题可以收敛为六个决定。

第一道决定：什么值得记。

一个简单判断框架是：未来价值、稳定程度、区分度、可验证性越高，越值得保存；敏感风险、错误代价、重复程度越高，越应该谨慎。

这不是要求产品团队真的计算一个精确分数，而是强迫方案回答几个问题：这条信息未来会改变什么行为？它是用户明确表达，还是模型推断？一个月后还可能成立吗？如果记错，用户付出的代价是什么？已有系统是否已经保存了权威版本？

通常值得优先考虑的，是用户明确要求记住的内容、稳定偏好、持续目标、关键安全限制、未完成事项、用户纠正和经过验证的任务经验。相反，短期情绪、随口假设、模型对人格的猜测、能从权威业务系统实时查询的事实，以及未经允许的敏感信息，都不适合被默认固化。

尤其要警惕“有用，所以保存”这句看似正确的话。很多信息在当前对话里有用，却没有跨会话价值。用户说“今天只给我简短答案”，可能只是正在开会；把它升级成永久偏好，下次需要详细解释时反而造成伤害。

第二道决定：什么时候写。

写入大致有三种触发方式。

最可靠的是用户显式触发，例如“记住这件事”“删掉刚才那条”。它可解释、可控，适合记忆功能的第一版。其次是确定性规则，例如任务状态从进行中变为完成、用户在设置页修改偏好、订单系统确认地址变更。这些信息不必交给模型猜。最后才是模型自动抽取，它能覆盖对话中的隐含信息，但必须配合置信度、敏感信息过滤、冲突检查和抽样评测。

一个稳健的 MVP，往往不是第一天就自动记住一切。先让用户主动保存，再让系统提出候选记忆供确认，等团队积累了误写数据和评测集，才逐步扩大自动写入范围。

第三道决定：记成什么。

同一段历史可以有不同表达：原始事件适合追溯，摘要适合快速恢复上下文，结构化事实适合更新与过滤，实体关系适合处理人物和项目之间的联系，程序规则适合指导行动，未来意图则需要触发条件。

无论采用哪种形式，一条可治理的记忆至少要说明内容、类型、作用域、来源、时间、置信度、敏感等级和当前状态。下面不是数据库建表规范，而是一张产品语义清单。

如果系统只保存一句文本和一个向量，它会很难回答三个关键问题：这是谁的记忆？现在还是真的吗？为什么相信它？

第四道决定：存在哪里。

没有一种存储能包办所有记忆。

Letta 同时提供常驻上下文的 Memory Blocks 与按需搜索的 Archival Memory；Anthropic 的 Memory Tool 直接使用客户端文件；Graphiti 通过带有效时间和来源的关系表达变化事实；主流框架也普遍支持结构化过滤、向量召回和重排。它们指向同一个结论：存储不是信仰问题，而是查询和治理问题。

对大多数产品，更现实的是混合方案。结构化存储保存权威状态和权限，向量检索负责从大量非结构化经历中找候选，原始事件用于追溯，必要时再用图关系处理复杂实体和时间变化。没必要为了“架构先进”把每一种都上齐。

第五道决定：什么时候取，以及取多少。

召回不是在记忆库里搜索一句相似的话，而是在有限上下文里分配注意力预算。

系统先识别当前任务：用户是在继续旧任务、询问事实，还是要求执行动作？然后根据用户、项目、任务和权限过滤作用域，再结合关键词、语义、实体关系和时间条件找出候选。候选还要重新排序：与当前目标有多相关，是否仍在有效期内，来源有多可靠，最近是否被用户纠正，使用后可能造成什么风险。

向量相似度只能回答“文本意思像不像”，无法单独回答“现在该不该用”。“我准备开始跑马拉松”和“我脚踝扭伤暂停训练”都可能与“本周训练计划”高度相关，但对行动的含义相反。

召回之后还要决定怎样注入。把十段历史原文全部塞给模型，会把检索问题变成新的上下文问题。更好的做法，是提供少量经过排序、带时间和来源的记忆，并明确哪些是事实、哪些是偏好、哪些只是待确认推断。必要时让 Agent 二次查询，而不是一次加载全部历史。

第六道决定：怎样改口，什么时候忘。

长期记忆真正困难的地方，不是第一次写入，而是变化发生后如何退出旧结论。

用户说“我最近不跑步了，改成游泳”，系统至少有四种处理方式：直接覆盖旧偏好；保留旧记录但标记失效；把两条都保留，交给模型自行判断；向用户确认这是暂时调整还是长期变化。选择取决于场景和错误代价。

可以建立一个简单的证据优先级：用户明确纠正，高于经过验证的行为结果；经过验证的结果，高于反复出现的稳定模式；稳定模式，高于一次对话中的模型推断。高风险场景里，即使证据很强，也应把关键更新交给用户确认。

遗忘也不只是删除按钮。至少要区分：不再召回但保留审计的失效记录；到期后自动降权或清理的短期记忆；用户要求删除后从所有可使用副本中移除的硬删除；以及出于安全与合规需要保留但禁止 Agent 使用的隔离记录。

公开产品提供了值得参考的交互：用户能查看记忆摘要、直接纠正一段记忆，或开启不读写记忆的临时会话。Anthropic 的 Managed Agents Memory 还为每次改动保留不可变版本，支持审计与时间点恢复。这些并非后台运维细节，它们直接决定用户是否敢让 Agent 长期记住自己。

至此，记忆系统的产品骨架才算完整：它既要会记，也要会解释、会怀疑、会更新、会退出。

数据库选型位于“记成什么、存在哪里”之下，不能替代另外五项产品决策。

五、把一套记忆系统放进真实产品，会发生什么

继续看开头那个学习助手。

第一周，用户说：“Python 基础我学过，但还没完整做过项目。工作日晚上能学四十分钟，周末不固定。”助手给出实践计划，并把这段更细致的描述压成了“Python 初学者”和“工作日晚间四十分钟”。当时看不出问题。

第二周，用户连续完成了函数、文件读写和异步请求，还明确说：“基础语法可以跳过了，我现在更容易卡在环境配置和异常处理。”如果系统只保留第一周的标签，“初学者”就会继续支配后面的回答；如果系统把第二周的每句话都存下来，下一次召回又会出现大量重复、甚至互相冲突的描述。

更合理的处理，是把这一周的经历保留为情景记忆，同时更新语义层的用户状态：Python 基础已通过近期任务验证；当前薄弱点是环境配置和异常处理；“初学者”这个粗标签降级为历史状态，不再作为默认判断。原始对话依然可以追溯，但不会每次都进入上下文。

第三周，用户说：“最近临时加班，先把计划暂停，下个月再恢复。”这句话不是学习能力变化，却会改变短期行动。系统应新增一条带有效期的计划状态，而不是把“工作日晚间四十分钟”永久删除。到了恢复日期，助手可以询问是否重启计划，而不能假设用户一定有空。

三周里，用户只说了几句自然语言，记忆系统却要完成四种不同工作：保存相对稳定的偏好、用行为证据更新能力判断、维护短期状态、在未来条件满足时提醒。若把它们都压成一句“用户画像”，迟早会互相污染。

现在比较三种产品做法：

这也解释了为什么“自动记忆”不能只做成一个后台开关。用户真正需要的是一组清晰的产品能力。

第一，写入要有反馈，但不必每次弹窗。低风险偏好可以用轻提示，例如“已记住：回答先给结论”；高影响判断则应确认，例如“你希望我以后都跳过 Python 基础内容吗？”如果每一句都询问，记忆会变成权限弹窗；如果完全静默，错误又会悄悄固化。产品要按影响分级。

第二，记忆要可见。记忆管理页不应只是长长的句子列表，而应按作用域和状态组织：关于我的稳定偏好、某个项目的背景、正在进行的计划、系统根据行为形成的待确认判断。用户最好能看到来源、最近使用时间和有效范围。

第三，纠正要比新增更容易。用户说“不是这样”时，系统不能只追加一条反向记忆，让两条冲突信息长期并存。纠正入口应直接指向被使用的那条记忆，允许修改、限定范围、暂时停用或彻底删除。

第四，回答要能解释记忆从哪里来。这里不需要展示完整推理过程，只要回答三个问题：用了哪条记忆，它来自哪里，用户怎样改变它。尤其当记忆影响推荐、计划和自动执行时，这个解释是信任的一部分。

第五，系统要允许“这次别记”。临时会话、敏感话题和借用设备等场景，都需要同时关闭读取和写入。只停止写入却继续读取旧记忆，仍可能暴露用户不希望出现的背景；只停止读取却继续沉淀新内容，也不符合用户直觉。

这些交互看起来不像模型能力，却决定了记忆系统是否真的可用。用户并不要求 Agent 永远正确，但会要求它知道自己凭什么记得、记错后能不能改、该忘时能不能忘。

六、怎样判断记忆真的有效，而不是“看起来更懂我”

很多团队评测记忆，只问一个问题：历史事实能不能答对。这个指标重要，却远远不够。

一个系统可能准确记得用户上个月说过“喜欢跑步”，却没能用上昨天新增的“脚踝受伤”；也可能成功召回两条信息，却在回答中采纳了错误的一条；还可能给出正确建议，但额外暴露了另一个项目里的私密背景。单看事实问答，这些问题很容易被漏掉。

LongMemEval 把长期记忆能力拆成信息抽取、多会话推理、时间推理、知识更新和拒绝回答等维度；LoCoMo 用超长、多轮对话检验长期理解；更新的 LongMemEval-V2 和 Mem2ActBench 又把问题向前推进了一步：Agent 不仅要“想起”，还要在真实任务和行动中正确使用过去经验。对产品经理而言，这些研究最有价值的地方，不是一张排行榜，而是提醒我们把评测从召回率扩展到完整任务。

可以建立五层指标：

这里有两个容易被忽视的指标。

一个是“不该答时能否停下来”。记忆库里没有可靠答案，或不同来源互相冲突时，系统应该承认不确定并发起确认。拒绝回答并非能力不足，而是长期系统防止错误扩散的刹车。

另一个是时间。很多事实没有永久真值，只有在某段时间内成立。Temporal Semantic Memory 的研究区分了“对话发生时间”和“事实有效时间”：用户今天说“我下周在上海”，这条信息的写入时间是今天，有效时间却在下周。如果产品只保存一个时间戳，未来很难判断它究竟何时可用。

正式上线前，测试集至少应包含以下几类连续故事：用户明确改变偏好；新事实覆盖旧事实；短期状态到期；同名实体属于不同项目；用户先表达意见、后来明确纠正；助手从行为中形成了一个错误推断；删除后重新询问；当前问题与历史高度相似但不应引用；敏感信息只允许在特定空间使用；多条记忆都相关但彼此矛盾。

别把测试样本拆成互不相干的单轮问答。记忆的问题往往不是一句话答错，而是某次误写在几周后被召回，再影响一次真实行动。评测也要沿着“写入—变化—召回—使用—纠错”的时间链走一遍。

上线后，还要观察三类信号。

第一类是用户主动纠正。“我没说过”“那是以前”“别再提这件事”，都比普通的差评更接近根因。第二类是系统异常使用，例如某条记忆被频繁召回却很少真正采纳，可能说明它过于宽泛；一条记忆长期压制其他证据，可能说明权重设计失衡。第三类是边界事件，包括跨用户、跨项目和跨隐私空间的错误召回。这类问题即使发生率很低，严重性也足以阻止自动化范围扩大。

个性化还会带来一个更隐蔽的风险：系统可能因为“了解用户”而放松原有判断，把记忆当成替高风险行为开绿灯的理由。近期安全研究已开始专门评估个性化记忆对模型行为边界的影响。产品规则应该明确：记忆可以改变表达方式和任务上下文，不能绕过安全、权限与事实核验。

从“有没有写进去”一直评到“是否形成长期信任”，越往下越接近真实产品价值。

七、不同 Agent，需要的是不同记忆

“要不要做长期记忆”不能脱离场景回答。记忆的收益，来自任务对连续性的需求；记忆的风险，则取决于错误被使用后的代价。

个人助理通常需要较广的跨会话连续性，但权限和透明度必须更强。客服场景更像受约束的任务记忆，工单之外的内容未必应该长期保留。编程 Agent 对“过程经验”很敏感：一次失败命令可以避免重蹈覆辙，也可能因为环境已经变化而误导后续工作。教育产品不能用静态画像替代成长过程。健康等敏感领域则应采用独立作用域和更严格的写入、访问、删除规则；已有公开产品也开始将健康记忆与普通对话空间隔离。

多 Agent 场景尤其容易把“共享记忆”理解成大家共用一个库。真正需要共享的通常只有任务事实和经过确认的决策。某个 Agent 对用户形成的推断、某个子任务的草稿、包含敏感信息的原始记录，不应因为技术上可检索就自动向所有 Agent 开放。共享记忆需要清楚标记所有者、写入者、允许的使用者和有效期限。

还有一些场景，根本不值得上长期记忆。

一次性工具、公开信息查询、结果可由权威数据库实时获得的任务，优先做好检索和状态管理即可。低频使用且每次任务相互独立的产品，记忆带来的维护成本可能高于重复交代背景的成本。错误代价极高、又无法提供可靠确认和审计能力的场景，也不宜急着自动沉淀。

判断方法可以很朴素：如果不记忆，用户会不会反复付出明显成本？如果记错，系统能否在造成损失前发现并纠正？如果用户要求删除，团队能否说清楚删了什么、哪里还保留、何时生效？前一个答案是否定的，或后两个答案是否定的，长期记忆都不应成为当前版本的卖点。

八、从零到上线：别先造一颗“大脑”，先闭合一个小循环

记忆系统最稳妥的上线方式，不是一次推出自动画像、无限历史和主动执行，而是逐步扩大系统的决定权。

第一阶段看起来不够“聪明”，却能逼团队先把最难补的基础做好：用户身份、项目边界、数据结构、来源、删除和审计。第二阶段开始验证写入判断，但把最后决定留给用户。第三阶段才适合放开低风险自动化。第四阶段的重点也不是记得更多，而是从经历中形成可复用经验，并在真正需要时使用。

如果只给产品经理一张设计画布，可以留下九个格子：

1. 连续性问题：用户因为系统遗忘，正在重复付出什么成本？
2. 记忆对象：事实、经历、偏好、能力、方法、计划，究竟是哪一种？
3. 作用域：这条记忆属于当前会话、任务、项目、用户还是组织？
4. 写入门槛：谁决定保存，依据是什么，是否需要用户确认？
5. 证据结构：原话、行为、模型推断如何区分，来源能否追溯？
6. 召回规则：什么任务会触发，怎样处理时间、冲突和权限？
7. 使用边界：它只改变表达，还是会影响推荐、计划与行动？
8. 纠错退出：如何更新、失效、删除、隔离和恢复？
9. 成功标准：减少了什么重复成本，改善了什么任务结果，又新增了什么风险？

在需求评审会上，再用下面这份清单做最后一道检查：

• 是否清楚区分上下文、会话状态、外部知识和长期记忆？
• 是否只保存能在未来改变回答或行动的信息？
• 是否为每条记忆记录作用域、来源、时间、置信度和状态？
• 是否规定模型推断不能伪装成用户事实？
• 是否能识别重复、冲突、变化和过期？
• 是否先过滤权限和作用域，再做相关性检索？
• 是否限制每次注入的记忆数量和长度？
• 是否允许用户查看、纠正、停用、删除，并知道删除何时生效？
• 是否支持不读也不写记忆的临时空间？
• 是否用连续故事测试写入、召回、使用和纠错，而非只测单轮问答？
• 是否监控跨用户、跨项目和跨敏感空间的错误调用？
• 是否证明记忆改善了任务结果，而不只是让回答多了几句个性化措辞？

回到开头。真正的问题从来不是那个学习助手有没有记住“Python 初学者”五个字，而是它能否理解这条信息来自什么时候、依据是什么、现在是否仍成立，以及该在什么任务中使用。

没有记忆，Agent 只是一次次重新认识用户；记得太多，它又会被过去拖住。好的记忆系统站在两者之间：它从经历中保留对未来有用的部分，也为变化、不确定和遗忘留下位置。

这是一套产品秩序，不是一块外挂硬盘。

当 Agent 能把经历转化为可验证、可更新、可调用、可退出的资产，它才开始拥有真正的长期性。那时，用户感受到的也不只是“它记得我”，而是更重要的一件事：它能跟上我。