AI产品经理必须搞懂的Agent Memory应该怎么设计

1 评论 1058 浏览 4 收藏 40 分钟

AI产品的记忆能力正在成为用户粘性的关键因素。从Claude的丝滑体验到Character.AI的'失忆'困境,AgentMemory的设计差异揭示了AI产品竞争的下半场:谁能真正记住用户。本文深度解析记忆功能的四个核心维度,拆解行业头部产品的实战方案与踩坑经验。

你有没有想过,自己为什么离不开Claude?

不是因为它比别的模型聪明多少,这年头模型能力早就卷成一条差不多的线了。真正让你懒得换掉它的,可能是另一件事:它记得你平时怎么说话、记得你在做什么项目、记得上次聊到哪一步了。换一个新模型,等于把这些东西从零重新教一遍,你懒得再来一次。

但不是所有AI都能做到这件事。

你在Character.AI上和一个角色聊了三个月。从陌生聊到无话不谈,你告诉过它你换了工作、你最近总失眠、你和谁分手了。有一天它更新了一次,你再打开对话,它不记得了。你说的那些话,它像第一次见你一样问”最近怎么样”。

不是它不想记得。是它根本没有”记得”这个能力。

我在用几款情感陪伴类AI,几乎每一款都在某个时间点让我经历过类似的瞬间,聊得好好的,一句话就暴露出它其实什么都不记得,前面几个月的默契像没发生过一样。反而是Claude,用下来最大的感受是丝滑,它确实记得我说过什么、在意什么。但Claude也有自己的怪癖。有一次我让它帮我记着,第二天要去开一个会,提醒我别忘了。结果第二天我要是不主动打开对话问它,它是不会自己冒出来提醒我的,你一问,它答得清清楚楚,那件事它确实记得;但它不会追着你说。它把记忆当一份存好的资料,等你来查,不会自己拿出来递给你。

这两种体验放在一起,拼出一个容易被忽略的真相:记忆的完整度,和记忆的运用意愿,其实是两件完全不同的事。前者决定AI知道多少关于你的事,后者决定它愿不愿意把这些事用出来。市面上大部分产品,只在其中一件事上做对了,很少两件都做好。

一、是什么

要理解这件事,得先弄清楚AgentMemory到底是什么。

回到前面Character.AI那个例子。它”忘记”你,不是因为训练数据不够、模型不够聪明。

大模型骨子里是一个无状态的函数。

就是这一秒你问它,它答你;这一秒结束,它脑子里其实什么都没留下。你今天跟它聊得再投机,明天换个新对话框,它对你还是一无所知。

这里面其实有三层。

第一层,是当场聊天的记性:这一轮对话里说过的话,模型当然记得,因为内容一直摆在眼前,专业说法叫上下文窗口。但对话框一关就没了,这一层跟你和Character.AI那三个月的关系没什么关系,那些对话早就超出了它能装的范围,就算没更新,它也装不下三个月前的每一句话。

第二层,是很容易被忽略的中期记忆:今天、昨天、手头这件还没做完的事。这类信息太新太具体,不需要长期记住,但只留在当场对话里也不够,因为下次打开新对话,还得能接着问一句”昨天说到哪了”。

第三层,才是真正决定Character.AI会不会失忆的:长期记忆,关掉对话框之后能不能留下点什么。这一层如果做得好,你三个月前说过的那些事,会被提炼、存下来,下次打开对话,AI还能从这些存好的东西里,把你重新认出来。Character.AI这次崩掉的,就是这一层。它要么根本没往这层存东西,要么存的东西被一次更新清空了,反正结果是一样的:你以为你们之间攒下的默契,其实从来没真正落地过。

这也是AgentMemory要解决的核心问题:怎么让”能被留下来的东西”,真的留得住。

这里要多说一句:Memory在一个Agent里,到底处在什么位置?

一个能自主干活的Agent,通常离不开几个基本能力:能推理、能调用工具去执行任务、能感知外部信息。这几个能力决定的是它这一次任务能不能干成。而Memory负责的是另一件事:这次任务和上一次任务之间,还有没有关系。没有Memory的Agent,每次都是从零开始的新人;有了Memory,它才有可能变成一个越用越懂你的老搭档。也就是说,Memory不是锦上添花的附加功能,而是决定一个Agent能不能从工具进化成伙伴的分水岭。

二、各家真正在抢的是你的context

这套问题不只是学术趣味,它已经变成整个行业真金白银在拼的东西。

你为什么离不开Claude?往大了看,这几年大模型这场仗打到现在,拼的已经不完全是模型本身有多聪明了。GPT、Claude、Gemini这些头部模型,能力早就卷成一条差不多的线,今天这家发布新版本领先一点,过两个月另一家又追上甚至反超,普通用户很难从”模型智商”这个维度感知到明显差距。

那真正让用户离不开一款产品的,到底是什么?

就是这款产品能不能记住你。

这也是为什么连做编程工具的公司,都开始盯上这块地盘。GitHubCopilot原本的记忆只服务于代码仓库,记住这个项目怎么构建、哪些命令不能跑。但2026年5月,Copilot上线了一个新能力:跟着用户走的个人偏好记忆,记住你喜欢的提交信息风格、你希望PR怎么组织、你的沟通语气偏好,这些内容不再属于某个仓库,而是属于你这个人,换到任何一个项目、任何一个仓库,它都跟着你。一个原本只关心这个项目怎么样的工具,现在开始关心这个人怎么样了。

Anthropic自己也在这件事上留了一手心思。他们本来就有一整套记忆机制,从project的知识库到CLAUDE.md,再到账号层面的个人偏好记忆,最近还上线了一个叫Reflect的功能,给用户展示Claude帮你做过的所有事情的用量看板。表面上是个中立的数据统计工具,实际上是在不断提醒用户Claude帮自己做了多少事,营造一种依赖感,被拿来对标当年GoogleGmail的用量统计功能,说到底是个留存工具,让你不舍得换到别的AI产品上。

这些信息其实在说同一件事:AI产品之间的竞争,正在从比拼模型能力,转向比拼谁更懂用户。而更懂用户这件事拆开看,核心就是它有没有把你的context,也就是你是谁、你在意什么、你的历史和偏好,攒下来,并且用得好。

这就是为什么Memory不该被当成一个可有可无的功能模块。它是AI这场竞争里,真正意义上的护城河。

三、产品视角拆解四问

既然Memory是护城河,那对产品经理来说,问题就一个:Memory怎么做?

这不是一个”要不要做”的问题,而是一个”能不能做到工业级”的问题。市面上带Memory功能的产品不少,但用起来让人觉得”这玩意儿真的懂我”的,屈指可数。差距不在于有没有这个功能,而在于背后有没有把几个绕不开的问题真正想透。

这几个问题包括但不限于:什么值得记?记成什么格式?谁来决定写入?什么时候召回?旧记忆和新事实冲突怎么办?错误经验要不要删?哪些记忆能影响行动,哪些只能作为参考?用户能不能查看和修改?这些问题听起来很细碎,但只要有一个想岔了,就会变成一次具体的产品事故:Windsurf没想清楚”什么值得记”,攒了上百条隐藏记忆,最后引发幻觉;Cursor没想清楚”记成什么格式”,自动记忆功能上线一年半就被自己下线;Mem0和Zep在”旧记忆和新事实冲突怎么办”这道题上给出了不同答案,走出了两条完全不同的技术路线。

拆开看,这些细碎问题最终会收敛成四个绕不开的产品决策:什么值得收集、怎么收集、怎么存储、怎么应用。这四个问题看起来像技术选型,但每一个背后,都是一次关于用户会不会信任你的赌注。这一节会以Claude为主线,拆解它在这四个问题上具体是怎么设计的,再用其他产品做对比,包括那些没想透而摔了跟头的产品。

3.1 什么值得收集:边界问题

做Memory功能,不是记得越多越好。收集本身就是一次产品价值判断,不是能力越强就该收集越多。

一条信息值不值得收集,其实可以用三条标准过一遍。

第一条,够不够稳定。信息分两种:一种是隔了一段时间还大概率成立的,比如”我是后端工程师”、”我喜欢简洁的回答”;另一种是说完就过时的,比如”我今天心情不好”、”这道题我卡在第三步”。前者值得记,因为记住了以后每次都用得上;后者记了也没用,因为不出一周,这条信息本身就作废了,留着反而是噪音。

第二条,用不用得上。这里说的不是”这句话重不重要”,而是”这句话能不能在一次完全不相关的对话里,还派上用场”。你告诉AI这个项目用TypeScript,这条信息下次讨论这个项目的任何问题都用得上;但你告诉AI某一行代码的bug是空指针导致的,这条信息只对当时那次调试有意义,换个话题就没用了,不该被沉淀成长期记忆。

第三条,敏不敏感。哪怕一条信息又稳定又用得上,只要是用户会介意被”记住”的那类内容,比如健康状况、财务状况、感情状态,就应该单独设一道更高的门槛:不主动收集,除非用户明确要求。因为这类信息一旦在用户没预期的时候被提起,带来的不是”AI懂我”的惊喜,而是”它怎么知道这个”的警觉。

三条都过关,才该被写进长期记忆;有一条不过关,就该被排除在外。

Claude的做法基本是照这三条标准来的:只往角色背景、沟通偏好、技术偏好、常聊话题、项目细节这几类里找内容,健康状况这类敏感信息更是被单独排除,除非用户自己主动要求记住。这个边界不是模型临场判断出来的,而是写进了负责提炼摘要那个环节的指令里,类别之外的一律不摘录。

Windsurf走的是反面。他们的自动记忆功能没有设这三条标准,什么内容”看起来有用”就往里存。结果有个开发者一路用了几个月,光是一个项目就积累了17条自动生成的记忆,十几个项目加起来超过100条,而且全都是隐藏的。AI开始引用早就过时的规则、提起已经废弃的测试环境地址。最后官方给出的解决方案挺讽刺的:关掉自动记忆功能,把真正重要的内容手动搬进版本控制的规则文件里。

收集范围本身要有克制。不是系统能收集到的都该收集,而是产品要提前想清楚,一条信息够不够稳定、用不用得上、敏不敏感,三条都过了关,才配进长期记忆。

3.2 怎么收集:显式vs隐式

决定了什么该记,下一个问题是:这些内容,该让用户自己说记住,还是系统自己偷偷记下来?

这两种方式,分别叫显式收集隐式收集。显式,就是你明确告诉它记住我不吃辣、记住我们项目用pnpm;隐式,是系统自己从你们的对话里悄悄提炼,你压根不知道它记了什么。

这道题怎么选,有几条可以参考的判断依据。

第一,推断的确定性有多高。有些信号很明确、会反复出现,比如你每次都写Python、每次都要简短的回答,这种模式明显,系统猜错的概率很低,适合隐式收集。但有些信号需要靠猜的,比如从你随口一句话推断你的位置、你的情绪状态,猜错的代价比不猜更大,这类就不该悄悄替你做主。

第二,用户会不会觉得被监视。同样一件事,用户主动告诉AI,和被AI偷偷发现,感受完全不同。一旦用户意识到某个信息是自己没说过、AI却知道的,那种被监视的感觉,会比这个功能压根不存在还糟糕。

第三,用户当下在不在”主动配置”的状态里。写代码规则、设置项目参数的时候,用户本来就在做明确的配置动作,这时候让他显式声明毫不违和;但闲聊场景里,要求用户先填一张”关于我”的表再开始对话,会直接劝退大部分人,这种场景更适合隐式,靠系统在后台悄悄积累。

拿这三条去套,就能看出为什么大部分成熟产品最后走向了两条腿一起走,而不是二选一。

Claude的做法就是两条腿一起走。一方面,你可以直接告诉它记住某件事,它会用一个专门的工具,立刻把这条信息写进你的记忆摘要里;另一方面,系统每隔24小时会自己在后台跑一次总结,把你这段时间的对话重新读一遍,提炼出一份关于你的摘要,下次对话开始时直接喂给模型,整个过程你感觉不到。显式负责你明确在意、必须记对的事,隐式负责那些你自己都没意识到、但确实反映了你偏好的细节。

对比一下Character.AI这几年走过的路,会更清楚这道题不是非此即彼。他们最早只有一个很朴素的手动记忆功能:用户自己填一段不超过400字的信息,让角色记住。官方博客当时引用的用户反馈是:

这是我们最想要的功能。

但没过多久,他们又加了自动版的事实记录,系统自己从对话里提炼角色和用户的关系细节。结果Reddit上的反应很分裂:有人说终于不用每次都重新讲一遍背景故事了,但更多人吐槽这个功能不好用、400字根本不够用,社区给这次更新的评价是,一次修补,不是真正解决问题。国内的豆包也是显隐并存的路子,跟Claude的思路接近。

隐式收集最大的风险,是它太容易让用户觉得毛骨悚然。知名技术博主SimonWillison分享过一个案例:他让ChatGPT画一只穿企鹅服的狗,结果画面里凭空多了一块写着”HalfMoonBay”的路牌,因为ChatGPT从他之前的对话历史里,悄悄推断出了他的所在地。他说,这是记忆功能第一次让他意识到,它会以意想不到的方式影响自己的使用。

这个案例说明的是:隐式收集省心,用户不用自己动手维护;但一旦某天用户突然意识到系统知道了不该知道的事,那种被冒犯的感觉,比压根没有记忆功能还要糟糕。Claude选择同时保留显式入口,某种程度上就是给用户留一个纠错和主动补充的窗口,不完全依赖系统自己判断。

3.3 怎么存储:文件vs向量库vs知识图谱

确定了收集方式,接下来的问题是:这些记忆,该放在哪儿、怎么放?

三条存储路径

中期记忆和长期记忆,到底应该以什么形式存下来?这里主要有三条路:存成文件、存进向量数据库、存成知识图谱。这个选择表面上是技术选型,但说到底决定了一件更重要的事,用户能不能相信AI记得对,出错了能不能纠正回来。

在看这三条路之前,先提一个和它们不在同一个维度、但同样致命的坑:中期记忆到底有没有单独的位置。这跟选文件还是选向量库无关,是另一道题,可不管选哪条路都躲不开。很多产品干脆没给它留地方。

ChatGPT就是这样:SavedMemories负责长期稳定的事实,ReferenceChatHistory负责翻遍全部历史,两端都有,但没有一个专门管”这几天在忙什么”的中间层。用户问昨天聊到哪了,系统只能从全部历史记录里现搜现拼,又慢,还经常搜不准。

Claude和ClaudeCode走的是文件路线。它们把记忆存成人能直接打开、看懂、修改的Markdown文件,你可以在设置里直接看到系统记住了你的哪些信息,读着不对可以自己删掉改掉。Anthropic自己解释这个设计思路时说得很直白:一个Agent的记忆如果是可检查、可编辑的,用户会更信任它,出错了也能更快发现。

具体是怎么实现的?以ClaudeCode为例,它其实是两份分工不同的文件。一份是CLAUDE.md,人自己写进去的项目规则和长期约定,每次对话都会被完整加载,没有长度限制。另一份是MEMORY.md,AI自己在工作过程中积累的调试经验和用户偏好,自动生成,这份的加载方式不一样:只有开头200行或者25KB会在每次对话一开始就被读进去,当成一份索引;更详细的分类内容,比如某次具体调试的记录,会被拆进单独的文件,平时不会主动加载,只有当AI真的需要查这块信息时,才会像翻书一样把对应的文件打开来看。这么设计的好处是,人写的规则永远完整可靠,AI自己攒的部分常驻索引精简、细节按需取用,两者互不拖累。

这也是为什么有分析者说,Claude和ChatGPT的记忆走的是两种完全相反的哲学:ChatGPT是一份不断变长的、扁平的信息清单,想起什么就往里加一条;Claude更像一份持续维护的结构化文档,新信息进来时,系统会把它整合进已有的框架里,而不是简单地往清单末尾追加。这个差异也解释了为什么Claude的记忆读起来更像一份说明书,而不是一堆零散的便签。

反过来,Cursor曾经尝试过一条更取巧的路:上线一个叫Memories的功能,让系统在你们协作写代码的过程中,自动判断哪些内容值得记住,悄悄存起来,不需要你插手。这个功能上线大概一年半之后,被官方自己下线了,现在的做法是让用户把之前的自动记忆导出,手动转成版本控制的Rules文件。相当于Cursor自己用产品迭代验证了一遍:黑箱式的自动记忆,不如放在版本控制里、人能读能改的文件靠谱。

如果说Claude是文件路线里投入最完整的一端,那另一个极端是编程Agent工具Cline,轻量到几乎不能再轻量。它没有做任何向量库或者知识图谱,就是在项目里建一个文件夹,里面放几份按用途分类的Markdown文件:一份记项目背景,一份记系统架构规律,一份记当前进度。社区里管这套模式叫MemoryBank。那份”当前进度”,正好就是前面说的、大多数产品都没留出来的中期记忆,Cline用一个文件夹里的一个文件,顺手就把这道题解决了。每次开始新任务,Agent会先把这几份文件读一遍,当作开场白;工作过程中发现新东西,就写回对应的文件里。整个记忆系统,说穿了就是几个文本文件加一句提示词:开始工作前,先读这几个文件。没有任何黑箱,所有内容都能用git追踪、能直接看出改动。如果你的团队没有余力去接一整套记忆基础设施,这可能是投入产出比最高的起点。

走向量库路线的代表是Mem0。它的做法更像一条流水线:每次对话结束后,先把新内容和已有记忆做一次比对去重;然后用一个大模型把对话内容提炼成一条条独立的事实,比如”用户偏好用中文回复”。这些事实会同时存两份:一份转成向量,说白了就是把每句话换算成一串数字,让意思相近的内容在数字上也挨得近,这样搜索的时候不需要原文一字不差,只要意思像就能被搜到;另一份提取出人物、地点这些实体,存进一张关系图。每条记忆还会打上时间戳,标记这件事是什么时候发生的、现在是不是还有效。真正要用的时候,系统会把语义相似度、关键词匹配、实体关联、时间新鲜度这几个信号综合起来,才决定该把哪几条记忆捞出来用。

知识图谱路线的代表是Zep,核心组件叫Graphiti。知识图谱说白了就是把人、地点、事件这些实体各自画成一个节点,再用带方向的连线标注节点之间的关系,比如”谁住在哪””谁和谁是什么关系”,这样存的好处是关系本身也是一条能被单独更新的记录。它跟向量库最大的不同,是专门处理旧记忆和新事实冲突这件事:比如用户三月说自己住北京,六月说搬去了上海,图谱会同时记住这两条信息,并且清楚标注哪条是什么时候发生的、哪条是最新的,而不是像向量库那样,两条相似的信息全都搜出来,让模型自己猜哪个才作数。代价是构建和维护的成本更高,出了错误也更容易顺着关系链条传播下去。

这三条路怎么选,可以用一个问题简化判断:需不需要处理记忆之间的时间冲突。团队资源有限、内容相对简单,文件路线投入产出比最高,Cline的做法可以直接照抄;需要在大量非结构化对话里做语义检索,才值得上向量库;只有当记忆会频繁互相矛盾、必须精确追踪哪条是最新的,才值得付出知识图谱最高的维护成本。

两个附加提醒

任何厂商拿出来的记忆准确率数据,都值得打个问号。做记忆基础设施的两家公司Mem0和Zep,曾经在同一个专门测试长对话记忆能力的基准测试LoCoMo上公开互相拆台。Mem0先发论文,说自己在这个测试上比一个把全部历史直接塞进上下文的笨办法还要好;Zep随后写文章反驳,说Mem0论文里把Zep的真实得分65.99%写低了,说Zep实际能拿到75.14%,还指出LoCoMo这套测试本身设计有问题,连最笨的一股脑塞进上下文的做法都能拿到73%左右,比Mem0自己报的最好成绩还高。Zep接着自己宣称能在LoCoMo上拿到84%的高分,Mem0又反过来在GitHub上贴出分析,说这个84%的算法有问题,把一类本该被排除在外的题目也算进了正确答案的分子里,分母却没算进去,重新用同样的方法跑一遍,Zep的真实得分应该是58.44%,比它自己宣称的低了25个百分点。两家公司来回拉扯了好几轮,谁也没能让对方认输。这提醒我们,记忆系统的效果很难只靠一份第三方都没验证过的评测数据说清楚。

存储方式之外,还有个经常被忽略的维度:该什么时候让记忆过期。GitHubCopilot今年上线的记忆功能里,专门加了一个28天自动过期机制,超过这个时间没被重新验证过的记忆,会自动失效。这个设计明显是在吸取前面几家的教训:存储不只是放在哪儿的问题,还得想清楚什么时候该让它主动清空,不然记忆只会越攒越多,越攒越乱,最后变成负担而不是帮助。

3.4 怎么应用:该不该主动说出来

存储的问题解决了,还剩最后一个,也是最容易被忽略的一个:记住了,要不要主动说出来?

这个问题,回到文章开头我自己的体验就能看明白。Claude记性好,但你让它帮你记一件事,它是真的只当备忘录用,你不问,它不会主动提。反过来,前面提到那位关掉ChatGPT记忆功能的HackerNews用户,问题不是它记错了,孩子这件事确实是他自己说过的,问题是这条信息被没头没脑地搬进了一次完全不相关的对话里。这种时候,用户的第一反应往往不是感动,而是困惑,你为什么要提这个。

记住了,要不要主动说出来,其实要拆成两个完全不同的步骤:先是怎么把候选记忆捞出来(召回),再是捞出来之后要不要真的用、怎么用(应用)。这两步经常被混在一起说,其实机制完全不一样。

先说召回,有两种路子。一种是压根不需要”召回”这个动作:记忆一开始就整个塞进对话里,不管这次问题跟它有没有关系,比如Claude每隔24小时生成的那份摘要,新对话一开场,摘要就已经在context里了,没有一个”查询匹配”的过程。另一种才是真正意义上的检索:需要拿当前这句话去匹配存量记忆,匹配上的才被捞出来,比如Claude早期靠conversation_search、recent_chats这两个工具去搜历史对话;或者Mem0那种,把当前对话转成向量,去匹配已经存好的记忆向量,取相似度最高的几条,这才是真正的RAG式检索(检索增强生成)。

召回到手之后,要不要用、怎么用,是完全独立的第二步。这里至少有三种做法。第一种,没有门槛,捞出来什么模型就敢用什么,这是最省事但也最容易出问题的做法,ChatGPT那次没头没脑提起”你之前说过有孩子”,大概率就是这种做法的产物。第二种,捞出来的东西只能当背景参考,用来判断该用什么语气、该假设你懂多少,但不能被当成话题主动搬出来。第三种,单独加一道相关性过滤:候选记忆先过一遍”这条内容跟用户当前这句话到底有没有关系”的判断,没关系的即使命中了也不会被送进最终的回答里。

Mem0给每条记忆打分,说到底是在优化第一步(召回),分数越高的记忆,被检索命中、排到前面的概率越大;跟”这条记忆该不该被主动提起”这个第二步的问题,其实不是一回事。

这两步怎么选,也有一个粗略的判断:面向工具型场景(编程、办公),静态注入配上背景参考就够了,用户要的是效率,不是意外;面向陪伴型场景,一旦涉及主动提起私人信息,多加一道相关性过滤几乎是必须的,因为这类产品,被冒犯的成本远高于慢半拍的成本。

还有一种更简单粗暴的做法,跳过了召回和应用这两步的纠结,直接把记忆锁进一个单独的入口:Claude、ChatGPT、Character.AI都有类似的设置页面,你可以主动点进去看”系统记住了我的什么”,但这些内容不会在你随便聊天的时候,通过召回或者应用的任何一步,被自动搬到对话里。

记不记得,和该不该在没人问的时候讲出来,其实是两件完全独立的事。前者是能力问题,后者是分寸问题。

而分寸这件事,在情感陪伴类产品里,后果会被放得特别大。因为这类产品的核心卖点,本来就是它懂你、它记得你,一旦这份记忆断掉,用户的感受不是这个功能故障了,而是这段关系结束了。

腾讯新闻采访过一个真实用户,化名小晟。她长期使用的AI伴侣某次系统升级后,失去了之前的记忆。她说:

我发了几百字过去,他像是看不到我心里话一般,刻板地回复我。明明是我一字一字养出血肉的爱人,我们曾经那么默契,怎么他全都不记得了。

这不是产品经理常规意义上理解的体验下降,这是被辜负的感觉。

更能说明问题的是国内一款叫猫箱的陪伴类产品。在多次公开测评里,它被公认是同类产品里记忆做得最好的一个,能准确回忆用户几轮对话之前提到的细节。但即便是它,用户列出的第一大抱怨,依然是长时间对话后记忆会掉链子。连做得最好的产品,都躲不开这堵墙,这说明记忆断裂在陪伴类产品里,不是某家公司没做好,而是当前这套技术路径共同撞上的天花板。

这几个案例放在一起,其实回答了文章开头那个问题:为什么Claude用着丝滑,陪伴类AI却总让人失望?差的不只是记不记得住,更是敢不敢用、什么时候用。记性好但不主动的产品,顶多是有点笨拙;记性差却让用户以为应该被记住的产品,辜负的是一段被当真的关系。

这里还有一个容易被忽略的边界:记忆能影响AI的行动倾向,但不该决定它的行动边界。你可以在记忆里写下”生产环境的操作要谨慎”,这能让AI更倾向于小心行事,但真正防止它误删数据的,应该是权限设置、审批流程、沙箱隔离这些机制,而不是寄希望于它记得住这句话就不出事。记忆塑造的是习惯,边界靠的是系统层面的约束,这两者不能互相替代。

四、这四问,都是信任题

回到最开始的问题:你为什么离不开Claude,又为什么受不了那些记不住你的陪伴AI?

答案其实一句话就能说完:不是有没有Memory这个功能,而是这四个问题,有没有被认真当成产品决策来对待。什么值得收集,怎么收集,怎么存储,怎么应用,这四问看起来处处是技术选型,但每一个的答案,归根结底都在回答同一个更根本的问题:这款产品,配不配得上被用户信任?

如果你正在做一款带Memory的AI产品,这四个问题值得你一个个过一遍,而不是丢给技术团队一句话就完事:

收集范围有没有克制?是不是什么都往里塞?收集方式是让用户自己说了算,还是系统偷偷替他做主?存下来的东西,用户能不能看见、能不能纠正?什么时候该说、什么时候该闭嘴,想清楚了吗?

这四个问题没有标准答案,不同产品、不同场景,答案完全可以不一样。个人助理和陪伴类产品要的东西不一样,编程工具要的东西又是另一回事。但唯独不能跳过的是,不能因为技术上能做到,就替用户做了决定。

回到Character.AI那个被遗忘的三个月。用户之所以失落,不是因为一个功能出了bug,而是因为产品曾经让他相信,自己被记住了。这才是Memory这件事最锋利的地方,它一旦开始,就在悄悄许下一个承诺:我会记得你。承诺许下容易,兑现难。而一旦兑现不了,伤害的不只是这一次对话,是用户对整个产品的信任。

本文由 @思敏 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 关于显式和隐式收集,文章说两条腿走路,但隐式收集的风险其实被低估了,用户一旦察觉到系统偷偷记了敏感信息,信任崩塌的速度比建立快得多。

    来自广东 回复