手机上跑大模型这件事过去一年已经算不上什么新闻了。各家都在推端侧推理、本地部署把几B参数的小模型塞进旗舰机里跑从文档摘要到通话纪要再到所谓的智能体操作手机一波接一波。但我在实际落地的项目里越来越强烈地感觉到光有端侧模型是不够的。模型再聪明它每次和你对话都是“失忆”状态不知道你是谁、你喜欢什么、上次聊到哪了。真正让AI手机产生质变的是端侧长期记忆——也就是MobileMem这类方案在做的事。这篇文章我想集中聊聊端侧长期记忆这个方向。它不仅是技术问题还是产品问题、商业模式问题。为什么我会把它拔高到“AI手机时代新的关键生产要素”因为它决定了端侧AI能不能从“玩具级”走到“生产力级”。文章里我会拆解记忆系统的整体设计思路、核心实现细节、落地过程中的坑以及它对手机厂商、开发者、普通用户分别意味着什么。适合正在做端侧AI产品、本地部署应用、智能体开发的工程师和产品经理参考也适合想理解AI手机下一阶段会变成什么样的人阅读。1. 先想清楚为什么端侧长期记忆被抬到“生产要素”这个位置1.1 大模型再聪明记不住你是谁一切个性化就是空谈先做一个最简单的实验。你把手机里的AI助手叫出来说“帮我订周五晚上的老地方”。大模型会懵因为“老地方”这个词在当次对话的上下文里根本不存在。它不知道你周五晚上经常去哪家餐厅不知道你习惯订靠窗还是靠里的位置更不知道你最近是不是在控制饮食、已经不太吃那家店了。这不是模型能力不够而是架构层面的缺位。当前主流的端侧模型、云端模型本质上都是无状态的函数给它当前输入它只基于当前输入和有限的上下文窗口做推理。上一周、上个月、去年你告诉它的任何信息在这次调用里都不可见。为了让AI手机真正“懂你”必须有一层外部机制把历史信息捞回来喂给模型当上下文这就是端侧长期记忆要做的事。我个人一直用一句话概括这个问题本地大模型解决的是“智商”长期记忆解决的是“经历”。智商决定了AI能不能理解复杂指令经历决定了AI给出的回答是不是符合你这个具体的人。没有经历的部分AI手机和一台能聊天的智能音箱没有本质区别。1.2 云端记忆为什么走不通成本、延迟、隐私三座大山有人会问既然要长期记忆为什么不上云把用户数据都存在云端云端大模型直接带着历史记录推理不是更简单吗我刚开始做这个方向的时候也这么想过但算了三笔账之后就放弃了。第一笔是成本账。上下文窗口里的每一个token推理时都要参与计算。如果每次都把用户过去半年的完整交互历史塞进去几千条记忆动辄就是几万token哪怕只有百万用户每天调用十次这个计算成本都不是一个小团队能扛的。第二笔是延迟账。实时从云端拉取历史、重排、注入再推理每一步都在增加首字延迟。端侧AI的卖点就是低延迟、离线可用结果关键链路还要依赖网络往返等于自废武功。第三笔是隐私账。用户的通讯录、位置轨迹、消费偏好、情感状态这些是最敏感的个人数据。全部上传云端既面临数据泄露风险又面临越来越严的合规约束。所以结论很清晰真正长期、细致、高敏感的个人记忆只能留在端侧。云端可以做跨设备的概要同步但完整记忆的载体必须在本机。这也是MobileMem这类方案出现的基本逻辑——用端侧存储和端侧算力承担记忆的提取、存储、检索和注入。1.3 数据要素视角个性化记忆是AI时代最具独占性的资产为什么说“端侧长期记忆”是新的关键生产要素我们从生产资料的角度来理解这件事。工业时代的生产要素是土地、资本、劳动力互联网时代的生产要素是流量和数据。而AI时代数据依然是要素但最值钱的数据不再是公共互联网上那些谁都能爬到的内容而是每一台设备上独有的、由用户长期行为沉淀下来的个性化数据。这类数据的稀缺性在于它不可复制、不可从公开渠道获取、无法通过买流量获得。用户的聊天记录、日程安排、真实偏好、社交关系、情绪变化这些数据天然只存在于用户的手机里。过去它们被零散地存储在相册、备忘录、聊天App、地图足迹里彼此隔离没有统一的结构化表达。端侧长期记忆的作用就是把这一堆“沉睡资产”唤醒变成AI可直接调用的结构化知识。谁掌握了端侧记忆这层能力谁就在AI手机时代掌握了最稳固的护城河。模型可以开源、可以蒸馏、可以追赶但用户和设备之间积累起来的长期记忆关系是时间堆积出来的竞争对手没法靠堆算力快速抹平差距。2. 端侧长期记忆系统的整体设计思路2.1 记忆不是单一数据库而是一条完整流水线很多第一次接触这个方向的人会把端侧长期记忆简单理解成“在本地搞一个数据库存点用户信息”。这个理解偏差很大。数据库只是记忆系统的存储底座真正的难度在于记忆从产生到发挥作用要经过采集、抽取、结构化、存储、检索、注入、遗忘一整条流水线。我把这条流水线拆成这么几个环节采集从各种来源对话记录、应用事件、系统状态拿到原始数据。抽取从原始数据里识别出值得长期保留的信息实体比如人物的偏好、习惯、关系。结构化把抽取结果转成统一格式加上时间戳、来源、置信度、有效期等元数据。存储写入本地数据库和向量索引按类型和生命周期分类管理。检索在用户发起新的交互时根据当前意图从记忆库里召回最相关的记忆片段。注入把召回的记忆重写成对模型友好的事实陈述拼进提示词上下文。遗忘与更新定期清理过期、冲突、低价值的记忆防止库无限膨胀。这样设计的核心思想是记忆不是一次性写入后就不管了它是一个有生命周期的运营系统。好的记忆系统既要能“记住”更要能“该忘就忘”。2.2 记忆别混着存按生命周期拆成四种类型我在项目里最开始的版本把所有记忆一股脑塞进一张表里结果检索时混乱不堪。后来参考认知科学里对记忆的分类方式把端侧记忆重新划分成了四类每一类的存储策略、更新频率、检索权重完全分开。第一种是事实型记忆。这类信息变化很慢用户住在哪个城市、做什么工作、家庭成员有哪些属于长期稳定的知识。接口一旦写入基本不需要频繁更新。第二种是偏好型记忆。用户喜欢什么风格、讨厌什么口味、习惯几点工作这类信息处于中等变化频率用户可能突然改变喜好所以需要更新和废止机制。第三种是事件型记忆。这类记忆有明确的时间窗口比如“上周五晚上去看了《沙丘2》”“下周三下午三点和客户开会”。有用期短但短期内价值很高过期之后权重应快速衰减。第四种是程序型记忆。这是很多人会忽略的指用户的使用习惯和操作模式比如常用某个App完成某个任务、习惯在特定时间点查看某种信息。程序型记忆对智能体的主动服务能力特别重要。分开之后每一类记忆可以用不同的生命周期策略去管理检索的时候按场景动态调整各类记忆的权重整体效果会好非常多。2.3 核心架构摄入、存储、检索、注入四层各管一摊从工程实现角度我把整个MobileMem方案抽象成了四个核心模块模块之间通过接口解耦可以逐步替换实现。摄入层负责接收各种来源的数据事件做格式统一和初步清洗。这一层最关键的设计是摄入和抽取分离。摄入层只负责把不同来源的数据转成标准格式的原始记录不承担理解任务理解任务交给抽取模块异步去做。存储层负责两类存储结构化存储和向量存储。结构化存储用本地关系数据库保存记忆实体和元数据向量存储负责保存语义向量用于按语义相似度检索。两者通过记忆ID关联。检索层是记忆系统的核心决策点。它收到当前查询之后先做意图判断再构造多路召回的检索请求。什么情况下该用事实型记忆、什么情况下该用事件型记忆都是在这一层决定的然后通过打分融合和重排挑出这条查询真正需要的记忆片段。注入层负责把选中的记忆加工成模型能直接使用的内容。这里有个容易被忽视的点直接从库里取出的原始记录是不能直接塞给大模型的。必须经过去重、去噪、改写变成“用户偏好窗口模式办公”“用户周二下午常去家附近的咖啡馆”这样自然语言形式的事实陈述模型的吸收效果才最好。3. 端侧实现一套可用记忆模块的关键细节3.1 数据采集先管理好输入边界别指望一次性拿全量端侧记忆系统的输入来源决定了整个系统的上限。数据质量不高后面所有环节都会事倍功半。我做过一个很蠢的版本想通过后台加壳的方式把所有App的交互数据都记录下来结果权限门槛高、功耗暴涨、用户投诉率飙升根本没法上线。后来我收敛了输入边界只采集三类数据。第一类是用户和系统助手的对话记录这是结构化程度最高的记忆来源用户的偏好、计划、情绪都直接体现在自然语言里第二类是用户明确授权的应用事件比如日历日程变更、地图地点搜索、音乐播放记录这类事件数据干净、语义明确第三类是设备端的场景状态比如时间、位置、天气用来给记忆补充场景上下文。采集过程中我踩的最大的坑是相同语义的信息会在短时间内被重复采集很多次。用户一天内可能多次提到同一家餐厅、同一个会议如果每条都入库记忆库会被冲掉。所以采集层必须做粗粒度的去重比如对文本计算哈希相似度超过阈值的只更新已有记录的时间戳和置信度而不是新建一条。3.2 抽取与结构化用小模型做实体识别别硬肛规则从原始文本里抽取结构化记忆是技术含量最高的环节。很多人一开始想用正则和规则来写比如匹配“我喜欢吃XX”这个模式。这种方案看着简单遇到真实语料就知道行不通用户不会按规则说话口语里有大量指代、省略、反讽和碎片化表达。我现在的做法是端侧跑一个小规模的序列标注模型做实体识别同时用规则层做兜底和后处理。实体识别模型负责抽取人名、地点、时间、偏好谓语、偏好宾语这五类信息规则层负责处理明显的句式模板以及在模型置信度低时做过滤。举个例子用户说“最近加班太狠了周末只想在家躺着别再给我推荐户外的活动了”。模型抽取出来的是时间偏好周末倾向于宅家、行为偏好拒绝户外活动、情绪状态疲惫。其中“拒绝户外活动”是一条负偏好记忆也就是“用户不喜欢什么”这类记忆在实际检索中权重非常高因为避免推荐用户讨厌的东西往往比推荐喜欢的东西更影响体验。抽取结果入库前我会做一个置信度校验。模型对某条抽取结果的打分低于0.6就直接丢弃介于0.6到0.8之间的标记为待观察只有在后续对话中被再次印证才提升为正式记忆。这么做的目的是防止一次口误被当成长期偏好。3.3 存储设计表结构、向量索引与时间戳一个都不能少存储层的设计直接决定检索效率和数据管理效率。我采用的关系表和向量索引混搭方案关系表负责元数据和结构化查询向量索引负责语义检索。表结构大致是这样设计的字段类型说明memory_idTEXT记忆唯一标识memory_typeTEXTfact/preference/event/procedure之一contentTEXT结构化后的记忆内容自然语言陈述entity_jsonTEXT抽取出的实体列表JSON格式sourceTEXT来源conversation/app_event/systemconfidenceREAL置信度0到1之间created_atINTEGER首次记录时间updated_atINTEGER最近更新时间last_access_atINTEGER最近被检索引用的时间expired_atINTEGER过期时间为空表示长期有效access_countINTEGER被引用的次数这张表最大的作用是支撑“遗忘策略”的决策。比如定期扫描时如果发现某条事件型记忆已经超过expired_at并且access_count为0就直接归档或删除偏好型记忆如果updated_at很久没变化且access_count也在下降就降低它在检索里的权重。向量索引我选择的做法是每一条记忆内容用一个端侧可跑的embedding模型转成128维向量写入本地向量索引。关于embedding模型我用过好几个实测下来小模型虽然语义理解能力不如大模型但对于“记忆碎片召回”这个场景已经够用。128维是性能和精度的折中再高的话端侧存储和计算压力明显上升收益却很小。3.4 检索与注入按意图召回记忆并学会给上下文做减法检索是记忆系统里最见功夫的部分。检索不到准确记忆前面所有积累都白费检索到了但注入太多无用记忆又会污染大模型的上下文让模型变得又贵又蠢。我目前的检索策略是混合检索加动态重排。混合检索包含三路召回第一路用BM25做关键词匹配适合“餐厅”“健身房”这类有明确关键词的记忆第二路用向量语义检索适合“找个安静的地方加班”这种没有关键词的语义级需求第三路用元数据过滤根据当前时间、地点、场景直接筛掉与当前无关的事件型记忆。三路结果合并之后再按一个综合分重排。综合分计算公式可以参考这个思路score w1 * semantic_similarity w2 * recency_score w3 * access_score w4 * type_weight其中semantic_similarity是语义相似度recency_score基于时间衰减函数计算access_score基于access_count和last_access_at计算type_weight是根据当前意图类型调整的权重。比如用户问“周末去哪儿玩”偏好型记忆的type_weight就调高用户问“我上次开会说了什么”事件型记忆的type_weight就要领先。注入阶段要做减法。我给自己定的一个硬性规则是单次对话注入的记忆条数不超过8条总共不超过800个token。因为端侧模型的上下文窗口本来就有限如果记忆挤占了大量空间模型的正事就没法干了。注入的内容还要经过改写把数据库里碎片化的实体描述重写成“用户偏好统计数据显示……”“根据用户历史记录……”这样的自然语言陈述模型的吸收效果最好。4. 实操过程中最常踩的坑和排查经验4.1 记忆张冠李戴时间、对象、条件不对宁可不注入做记忆系统以来我遇到最多、也是最影响体验的问题就是记忆被用在了错误的时间和场景里反而产生了比没有记忆更坏的效果。举一个真实的例子。用户某次加班到很晚顺口说了句“最近好喜欢喝咖啡提神”。这句话被抽取成偏好记忆“用户喜欢咖啡”。结果两周之后用户跟朋友说“最近胃不太舒服想戒咖啡了”。系统如果还是固执地注入“用户喜欢咖啡”推荐的产品、调用的服务全部跑偏用户会觉得这个AI一点不懂他。这个问题暴露出来的是记忆缺少负例意识和有效期意识。后来我做了两项改进。第一抽取时必须同时记录记忆的“条件约束”比如“时间加班期间状态疲惫时”这条约束在注入阶段要参与匹配如果条件不吻合就降权。第二增加负偏好记忆类型系统不仅记录“用户喜欢咖啡”也记录“用户正在减少咖啡摄入”。当正负偏好出现冲突时更新日期更新的那条优先这是基于“人是会变的”这个朴素假设。在这里我想给一个比较重要的经验记忆系统要敢于“不注入”。如果当前查询和记忆之间的相关度达不到阈值就不要强行使用。没有记忆最多是答得平庸错误记忆会导致答错后者对产品口碑的伤害远大于前者。4.2 存储无限膨胀压缩、合并、遗忘机制是标配端侧设备的存储资源非常有限用户不可能允许一个AI记忆功能占用几个GB的空间。我最早一版系统上线跑了一周记忆库就膨胀到了1.2GB直接被用户卸载了。后来我做了三件事解决这个问题。第一是同类记忆合并。系统追踪到用户在短时间内输入了“我喜欢吃辣”“这家川菜不错”“无辣不欢”等多条记录通过语义相似度和实体重叠检测把这类记忆合并成一条高置信度的偏好记录而不是各存各的。第二是压缩策略。对于事件型记忆超过30天且从未被访问过的直接压缩成概要记录只保留“什么时间、什么类型、做了什么”丢弃细节内容。第三是遗忘算法。我参考了类人脑的遗忘曲线原理对每条记忆计算一个综合保留价值由时效性、引用频率、置信度三个因素加权低于阈值的自动降级或删除。经过这几轮优化单用户半年的记忆库最终稳定在80MB到150MB之间对手机来说是可接受的量级。这组数字可以作为大家的参考基线。4.3 注入后模型反而变傻上下文被污染了记忆注入之后大模型的回答质量不仅没提升反而下降了。这个问题排查起来很隐蔽因为问题不在模型而在注入的记忆内容本身。典型的场景是用户问“帮我规划明天的行程”系统注入了十几条历史记忆包括“用户喜欢蓝色”“用户家里养了一只猫”“用户三个月前订过某家酒店”。这些噪音信息完全无关但占用了大量上下文空间模型为了“迁就”这些信息生成了很多无关的铺垫或者在一些关键点上表现得很犹豫。针对这个问题我引入了注入前的重排序环节。检索阶段选出来的记忆候选集先经一个小模型打一次相关性分低于0.45的直接舍弃。这个重排序模型特意训练成“宁可漏掉、不要错杀”的风格因为漏掉只是平庸错杀是错误。另外我严格限制了注入条数宁可少一点、精一点。实测下来5条高质量记忆的效果远好过15条混杂记忆。4.4 隐私合规边界本地优先不等于不加密不授权端侧记忆还有一个绕不开的问题虽然是本地存储但不代表可以随便用。用户的通讯录数据、对话记录即使不出设备直接在本地被一个无授权的进程读取也是不合规的。我建议做三件事。第一记忆模块独立成系统级服务通过IPC接口对外提供读写能力其他应用不能直接访问底层数据库核心的敏感记忆字段用设备级密钥加密。第二所有类型的记忆采集都要求用户在设置里显式开启授权并且授权可以按来源、按记忆类型做细粒度控制。第三给用户提供一种“一行清空”的能力一键删除所有记忆。这个功能我在初期觉得没必要直到有用户反馈说“你们记录了我的所有对话这让我有点害怕”我才意识到信任感是端侧记忆产品最重要的资产。5. MobileMem带来的产业变化与落地场景5.1 系统级能力手机厂商会把记忆做成OS基础设施端侧长期记忆这个能力从技术架构上看天然适合做成操作系统级别的基础设施。就像当年的定位服务、推送服务一样最开始是某些App自研后来系统化了所有应用都能调用整个生态的体验提升了一个台阶。手机厂商做端侧大模型已经成为标配但模型本身解决不了“懂用户”的问题。厂商接下来一定会把记忆层纳入系统框架提供一个面向所有App开放的“记忆API”。应用只需要声明自己需要什么类型的记忆系统负责从全局记忆库里检索匹配的结果下发。这种模式下单个App只能看到自己业务领域内的一小部分记忆整个系统却可以用最完整的用户画像去支撑跨App协作。这也会带来新的竞争维度哪家厂商的端侧记忆系统更完善、更智能、更安全哪家手机上的AI体验就会有代差。模型开源拉平了技术门槛记忆层的差距会越来越难以用简单手段弥补。5.2 扩展一个实际场景端侧记忆如何驱动“手机AI本地部署软件”体验升级现在经常看到“手机AI本地部署软件”被用户视为一种折腾派玩法普通用户装了模型输出质量一般就没兴趣继续用了。但把端侧长期记忆加进去之后这类本地部署软件会迎来一个明显的体验拐点。举个例子用户在手机本地部署了一个带记忆层的小模型AI应用。刚开始用无感和云端大模型差距明显但用了一周、两周这个应用开始记住用户的作息时间、阅读偏好、常用工具、关注的项目进展。用户问“今天有什么值得我关注的”它不再给一个泛泛的热门资讯列表而是直接告诉用户他所在行业、关注项目的最新变化以及他同事刚提到的关键信息。这种“越用越懂你”的体验是云端通用大模型很难给到的因为云端没有用户的本地数据也不被允许跨应用获取这些信息。所以我觉得“本地部署AI”未来的核心卖点不应该是“免费”“离线”而是“它在真正地了解你”。这个转折点上端侧记忆就是最重要的引擎。5.3 开发范式从“每次对话都从零开始”到“续写你们的故事”端侧长期记忆带来的不只是性能提升它还会改变AI应用的开发范式。现在的AI应用开发本质上还是在“无状态对话”之上做文章。用户进来要么什么都不带要么靠开发者在业务层手动维护一些小状态。记忆层成为系统能力之后开发的关注点会从“如何理解单次请求”转向“如何管理长期关系”。开发者不再需要自己去维护用户画像表只需要声明“这个信息对长期关系有价值”系统负责去重、更新、归档和匹配。这很像数据库从文件系统里独立出来的过程基础设施化之后上层的业务创新会集中爆发。我把这种转变理解成“从命令式记忆到声明式记忆”。命令式的意思是开发者要自己写代码去保存、去读取、去更新记忆声明式则是开发者只需要声明哪些数据值得记住系统自动承担生命周期管理。只有走到声明式阶段端侧长期记忆才真正算得上面向应用开发者的可用能力。6. 写在最后的一点经验体会端侧长期记忆这个方向越做越往深走越觉得它不只是工程问题更是一个涉及人机协作关系的产品哲学问题。一个人愿意让AI记录自己的多少信息取决于他是否信任这个AI而AI值不值得信任又取决于它是否真正用这些记忆带来了好的体验而不是把它变成骚扰和推荐垃圾。信任和使用之间是靠每一次交互中的正反馈慢慢建立起来的。如果大家要在自己的项目里做这个方向我的建议是先别急着追求大而全。先选一个最刚需的场景比如每周日程总结、主动式生活提醒把“采集—抽取—存储—检索—注入”这条链路跑通收到真实用户反馈后再逐步扩展。另外数据积累要趁早。记忆系统是个慢变量刚上线的一两周内效果可能并不惊艳但坚持跑过一个月、沉淀了足够的有效记忆之后体验会发生指数级的提升。这个质变的点会是你整个项目最有成就感的一刻。