端侧长期记忆：AI手机的新生产要素与工程实践

这两年只要聊到AI手机，大家讨论的无非是跑分、端侧大模型参数、拍照消除路人这种“点状功能”。我自己的真实感受是，这些能力看起来很热闹，但离“手机越来越懂你”还有很远。直到我开始折腾MobileMem这类端侧长期记忆方案，才意识到一个问题：AI手机真正的分水岭，可能不是谁能把模型跑得更快，而是谁的手机能把关于你的信息记得更久、用得更准。长期记忆，正在从一句产品口号，变成端侧AI硬实力的一部分，甚至可以说，它就是AI手机时代新的关键生产要素。

这篇文章我想从MobileMem这个切入点展开，聊聊它解决什么问题、底层是怎么设计的、端侧部署时有哪些绕不开的工程细节，以及我们在实际落地时踩过哪些坑。如果你正在做手机本地AI部署、端侧AI Agent，或者只是好奇“AI手机下一步到底卷什么”，这篇文章应该能给你一些比发布会PPT更实在的东西。

1. 为什么说长期记忆会成为AI手机的“新生产要素”

1.1 现在的AI手机缺的不是算力，而是“记得住”

先别急着聊架构，我们先想清楚一个产品问题：用户在手机上使用AI，到底希望它做什么？

大部分人现在能接触到的AI手机功能，我大致可以分成三类。第一类是单轮工具型，比如“帮我把这段录音转成文字”“把这张照片里的路人抹掉”，这类功能一次调用结束，不需要记住上下文。第二类是简单会话型，比如手机厂商内置的语音助手，能连续聊几句，但一旦锁屏或者隔了一天，它就把你忘了，重新开始。第三类是云侧知识问答，能回答很多百科类问题，但它不认识你，不知道你昨天跟谁吃了饭，不知道你反复设过几次凌晨六点的闹钟。

这三类功能的问题都一样：它们没有“记忆”。没有记忆意味着什么？意味着AI对用户的理解永远停留在表层。你说“帮我找个安静的地方办公”，它不知道你平时喜欢去咖啡厅二楼靠窗的位置；你说“提醒我别忘带钥匙”，它不知道你每天几点离家，也不知道你上个月已经忘过三次。

我最早关注MobileMem，是因为它把这个问题的解法从云端搬到了端侧。所谓端侧长期记忆，就是让手机在本地持续记录用户的行为、偏好、日程、关系、习惯，并通过端侧大模型对这些信息进行结构化建模和随时召回，让AI从一个“临时工”变成一个“特别了解你的长期助理”。这个思路不是锦上添花，而是把AI手机从“工具”推向“生产力”的关键一步。

1.2 端侧记忆和云端记忆，本质上是两种产品

有人可能会问，云端记忆不是更简单吗？让大模型在服务器上存用户画像，能力又强、存储又无限，为什么要死磕端侧？

这个问题的答案，我做了对照实验之后体会特别深。云端记忆方案的问题首先是隐私边界模糊。你愿意让手机厂商知道你的聊天记录、日程安排、健康数据都传上云端吗？不管厂商怎么承诺“加密”“脱敏”，用户心理上那道坎始终存在。而且合规层面的压力也会越来越大，一旦涉及跨境传输或者超范围收集，产品流程会变得非常重。

其次，云端记忆有一个被忽视的时效性问题。很多记忆是实时的、场景化的，比如“我刚才在停车场拍了一张照片，电梯口在左边”，这类信息如果走云端，一轮往返就是几百毫秒甚至几秒，等记忆写回来，场景早就变了。

端侧记忆的核心逻辑是“我的数据不出设备，我的记忆模型长在本地”。这样做的好处有三个。第一是隐私可控，信息不必离开设备就已经被加工成结构化的记忆。第二是响应极快，把记忆检索和推理全部放在本地，时延可以有效压缩到几十毫秒级别。第三是离线可用，在地铁、飞机上也能正常工作。

所以我的判断是，长期记忆和端侧AI硬件部署是天然绑定的。MobileMem这种方案，本质上不是在现有AI手机上打补丁，而是在重新定义AI手机“记忆”的归属权。当数据不出手机、记忆不被平台垄断时，用户才能真正拥有属于自己的AI资产，这也正是它被称为“生产要素”的原因——在AI手机时代，谁掌握记忆，谁就掌握了个性化服务的源头。

2. 一个端侧长期记忆系统内部是怎么运作的

2.1 记忆的完整生命周期

很多人以为记忆系统就是“存下来，再查出来”，实际操作下来远没有那么简单。MobileMem这类系统的内部，至少包含五个阶段：感知、提炼、存储、检索、应用。

感知阶段负责采集信息。这里的难点不是能不能拿到数据，而是拿什么数据、不拿什么数据。系统需要判断哪些信息值得进入记忆，哪些属于噪声。比如用户每天解锁手机300次，如果每次都记，既浪费存储也没意义。所以一般会设置事件触发器，只有当发生“有语义价值的事件”时才记录，比如用户完成一次支付、设置一次日程、搜索一个地点、在对话里提到某个重要人物。

提炼阶段是整个系统的灵魂。原始数据太粗糙，不能直接扔进记忆库。比如系统检测到用户今天下午三点在“高新区某咖啡馆”待了一个半小时，这个原始事件怎么变成有用的记忆？端侧会调用一个小型大模型或专门的抽取模型，把时间、地点、人物、意图、情绪等要素抽出来，生成一句结构化摘要：“用户喜欢在高新区XX咖啡馆进行下午办公，偏好靠窗位置。”这一步做完，记忆才真正具有价值。

存储阶段解决的是“记忆放在哪”。因为信息形态非常多样，只靠一种存储肯定不够，所以大多采用混合存储方式。结构化信息（比如生日、常去地点、关系人）用关系型数据库；语义信息（比如某段对话的含义、某篇文章摘要）转换成向量存进向量库；原始文本则保留在轻量级全文索引中，方便精确检索。

检索阶段决定“AI能不能想得起来”。光存进去没有用，关键是在用户需要的时候把最相关的记忆捞出来。实际工程里会结合用户当前意图，先做一个意图理解，再生成检索条件，比如搜索关键词＋限定时间窗口＋限定实体类型，最后通过向量相似度、时间衰减因子、重要性权重混合排序，挑出当前最该用的记忆。

最后是应用阶段。记忆被召回后，注入到大模型的上下文里，让AI的回答和行动都有依据。这一步看起来简单，但上下文窗口有限，一次到底注入几条记忆、按什么顺序排，直接影响输出质量。我试过把历史记忆不分青红皂白全塞进去，结果模型被大量无关信息干扰，效果还不如不塞。

2.2 记忆的分层与编码方式

记忆不是一个单一的概念，它需要分层。我对MobileMem架构里记忆分层的理解，可以类比我们自己的大脑运作方式：有工作记忆、情景记忆、语义记忆。

工作记忆是当前会话内的临时上下文，比如用户刚说“帮我查下周五去上海的车票”，这里的“周五”“上海”就是工作记忆。它的特点是生命周期短、明确度高，一般只需要在对话状态里维护，不落盘。

情景记忆是长期记忆中最重要的部分，记录的是具体发生过的事情：“周三晚上和Allen在老街吃了火锅”“上周五下雨没带伞”。这类记忆的特点是包含时间、地点、人物等实体，适合用事件图谱或结构化表单来存。它的召回往往依赖事件索引和实体关联。

语义记忆是抽象出来的规律和偏好：“用户不吃香菜”“开会前习惯喝美式”“工作日通勤通常走南二环”。它不以单一事件存在，而是从多个情景中归纳出来的。语义记忆往往决定AI服务的主动性，比如到了中午就自动推荐健康餐，因为系统从过去两周的用餐记录里得知用户正在控制碳水。

在编码方式上，MobileMem这类系统会把记忆改写成统一的“记忆条目”格式，每条包含：唯一ID、内容摘要、实体列表、时间戳、重要度评分、来源、访问频次。这种结构化的编码方式，方便后续查询、更新、去重和衰减。比如用户常去的一家咖啡馆倒闭了，系统会通过实体识别找到相关记忆，做一次“记忆修正”，而不是让旧信息一直占据一级优先级。

2.3 端侧记忆系统的整体架构

如果要把上面的设计落地，端侧记忆系统需要一个整体架构来支撑。我的理解是，它应该分为四个模块：

采集与事件总线模块，负责从系统层、应用层、传感器层收集事件，并做初步清洗。这个模块和操作系统结合最深，需要系统级权限配合。比如Android上要监听日程、通话、位置、应用使用等事件，往往要做系统级应用或者申请特殊权限。这里要特别注意权限合规，每次采集都需要用户明确授权，系统里要有可视化面板让用户看到“哪些记忆被存了”。

提取与更新模块，核心是一个常驻的端侧小模型，负责对原始事件做信息抽取、摘要生成、语义融合。这个模块的计算量不小，所以一般不会把所有数据都做实时处理，而是设计成“低优先级任务”，利用手机空闲时段或者连接电源时批量执行。我见过一些方案利用夜间充电时间做记忆整理，效果不错，既不打搅用户，也让手机在闲置时把碎片信息整理成体系。

存储引擎模块，在手机上通常是一个轻量级数据库加一个向量索引库。传统方案会用SQLite存结构化数据，用专门为移动端优化的向量检索组件提供近邻搜索。现在很多方案开始把两者合并，比如直接在SQLite里挂向量索引插件，这样事务一致性和查询便利性都会好很多。

召回与注入模块，负责把大模型的请求转换成查询条件，去存储引擎里捞出记忆，再按相关性、时效性、重要性排序，最后拼装成上下文发给大模型。这个模块要做得非常轻，因为它直接决定用户每次交互的响应速度。我实测下来，一次包含50条候选记忆的检索排序，在主流中端SoC上应该控制在30毫秒以内，否则对话会有明显的迟滞感。

3. 端侧部署的工程选型与性能参数拆解

3.1 模型选择与量化对内存占用的影响

说完了架构，来聊点真正动手时躲不开的问题：在手机上部署记忆相关的大模型，到底要多大参数量，占多少内存？

我的经验是，记忆提取和检索理解这两类任务，不一定非要大模型。像实体抽取、摘要、意图理解这些工作，3B以下的模型经过量化后完全可以胜任，有些专门的抽取小模型甚至只需要几百MB的存储。MobileMem这类端侧长期记忆系统，往往采用“一大一小”的模型组合：小的负责轻量信息抽取和意图分类，常驻内存；大的只在需要复杂推理和生成时才加载，用完即释放。

以目前主流的中端手机为参考，一个3B模型做INT4量化之后，权重大约占用1.7GB左右；如果再把推理过程中需要的KV Cache和中间激活算进去，峰值内存大概在2.5GB上下。这对现在的手机来说是可以接受的，但前提是做好模型的人格化和按需加载。我建议把模型文件放在支持内存映射的格式里，不要一次性把整个模型读入内存，用mmap方式让系统按页加载，实测可以显著降低冷启动压力。

3.2 推理引擎与端侧向量检索的选型

端侧要跑LLM，绕不开推理引擎的选择。目前第三方方案比较主流的是llama.cpp系列，支持多种移动端后端的推理，也有MediaPipe LLM Inference这种偏应用层封装的组件。如果芯片厂商有开放的SDK，比如高通的SNPE或者联发科的NeuroPilot，建议直接走厂商的NPU加速链路，能效比会好很多。

向量检索这块，很多人第一反应是把FAISS移植到手机端，我劝你冷静。FAISS依赖较多，移动端交叉编译麻烦，而且对ARM NEON指令集的优化并不全面。我实际在手机端用过体验较好的方案是sqlite-vec，直接把向量索引做进SQLite表里，跟业务数据同库管理，整个集成成本很低。如果你有更复杂的相似度召回场景，也可以考虑HNSW类库的轻量移植版本。

选型时一定要考虑推理的增量特性。语言模型的生成是逐token的，每生成一个新token，之前的KV Cache都要参与计算。如果你把上下文窗口设得很大，比如一次注入20条记忆，那么首token时延会明显上升。我的经验是，上下文长度要根据任务动态调整：简单摘要用1024就够，复杂推理再跳到2048，不要无脑拉满。

3.3 功耗、发热和系统资源占用

端侧长期记忆系统不是跑一次就结束，它可能在线程后台常驻、定期整理、实时监听。这就带来一个必须面对的问题：功耗和发热。

我实际调优时的主要手段有三个。第一，把信息抽取和记忆整理任务放到后台低优先级线程，并且只在充电、锁屏、设备温度低于阈值时执行，避免和用户前台操作抢资源。第二，尽量用NPU而不是CPU跑特征提取向量化，能效差距非常大，同样一批文本向量化，NPU的能耗可能只有CPU的三分之一左右。第三，对传感器和应用事件做合并采集，减少唤醒次数。

系统资源占用上，要小心两个隐形杀手。一个是后台模型常驻的内存，很多端侧模型哪怕不推理，进程保活也会占几百MB，容易被系统杀掉。另一个是数据库膨胀，记忆如果只增不减，一两年下来可能堆积几十万条，查询会越来越慢。所以必须有记忆清理机制，比如按重要度淘汰低频旧记忆，或者定期把细粒度事件合并成抽象偏好，把原始细节删除。

我可以给一个参考的缓存策略。记忆的访问频率像一个长尾分布，绝大多数记忆可能一辈子都不会被用第二次。我习惯把它们分三级：热记忆驻留在内存缓存，秒级访问；温记忆存在SQLite里，毫秒级查询；冷记忆只保留核心摘要和向量，平时不加载。这样既能保证常用记忆的响应速度，又能控制存储总量不失控。

4. 实操：给手机端AI助手加上长期记忆

4.1 搭建端侧推理底座

前面的理论讲再多，不动手总觉得虚。接下来我以一个Android端的AI助手项目为例，走一遍给手机AI助手加上长期记忆的完整流程。这个项目我跑过很久，整体方案没有用到特别的硬件，一台带8GB内存的普通手机就够了。

第一步是把推理底座搭起来。我选了llama.cpp作为推理引擎，模型用一个量化后的2B级开源模型，它的常识和指令遵循能力在端侧场景下够用。模型文件编译成.so库，通过JNI调C接口。这里有个小技巧：编译时一定要把-DNDEBUG加上，否则日志输出会拖慢推理速度；同时开启ARM NEON优化，生成速度能提升30%以上。

初始化的时候不要一启动就把模型全量加载。我会先做一次轻量检查，看当前是否处于低负载状态，如果是，加载模型并预热；如果不是，推迟加载，最多等30秒再尝试。预热也很重要，先跑两个短句子让KV Cache和线程池暖起来，否则第一次正式推理会慢得离谱。

4.2 定义记忆Schema与抽取管线

推理底座跑通之后，第二步就是定义记忆的数据结构。我的记忆表设计大致如下：

CREATE TABLE memories ( id INTEGER PRIMARY KEY AUTOINCREMENT, memory_type TEXT NOT NULL, -- 'event', 'fact', 'preference' content TEXT NOT NULL, -- 结构化摘要内容 entities TEXT, -- JSON数组，记录实体 scene TEXT, -- 场景标签，如 work/food/health importance REAL DEFAULT 0.5, -- 重要度 0-1 created_at INTEGER NOT NULL, last_access_at INTEGER, access_count INTEGER DEFAULT 0, expired_at INTEGER -- 可选过期时间 );

这个Schema的重点在于把记忆类型、实体、场景独立出来，方便后面做条件检索。抽取管线主要跑在端侧，用之前预热好的小模型做实体抽取和摘要，输入是一段原始事件文本，输出是结构化的JSON。比如原始文本是“今天中午在楼下重庆小面吃的午饭，老板娘说辣椒酱是她自己做的”，抽取后得到事件摘要“用户常去楼下重庆小面吃午饭，提及店家自制辣椒酱”，实体包含“重庆小面”“老板娘”，场景标签是food。

抽取结果会经过一层置信度过滤，低于阈值的记录不写入，避免垃圾进垃圾出。我遇到过模型把用户随口说的“下次不来了”当成偏好记录，导致后面推荐逻辑出错，后来加了一条规则：带否定词且无后续动作的文本，不写入偏好。这类启发式规则看似笨拙，但比纯靠模型靠谱得多。

4.3 记忆注入与检索增强生成

第三步是让记忆参与AI助手的生成过程。我的做法是先在每次对话前创建一个“记忆召回请求”，请求里包含当前对话的最后几轮内容、当前时间、可见的应用场景。然后用端侧模型给请求生成几个检索关键词，并判断时间范围。比如用户问“我上次跟Allen吃饭是什么时候”，意图理解模块会识别出实体“Allen”、事件类型“吃饭”，时间范围不限，然后去数据库里用SQL查structured信息，同时用关键词的embedding去向量库做语义召回。

召回结果经过混合排序后，取前五到十条最相关的记忆，拼成一个“记忆上下文块”，插入到System Prompt里。这一步比较关键，我通常会在记忆上下文块前面加一行说明：“以下是助手对用户的长期记忆，请结合这些记忆回答，但不要主动暴露记忆内容。”实测加上这句能让模型更自然地使用记忆，而不是生硬地报出“根据我的记忆”。

为了控制上下文长度，我还会对注入的记忆做截断，每条不超过三句话；时间相关的内容会在前面加上相对时间描述，比如“三天前”。模型拿到的是经过加工的“人类可读记忆”，而不是原始的JSON结构，这样生成的回答会自然很多。

4.4 实测结果与参数回调记录

整条链路跑通之后，我在真实使用中做了几轮测试，最有参考价值的是这三组数据：

第一组是记忆召回准确率。在50条测试记忆、10个用户询问的前提下，端侧方案Top-5召回准确率能达到83%左右。听起来不错，但20%的漏检率在关键场景下依然致命，比如用户问“我的医保卡放哪了”，如果系统恰好没召回这条记忆，会让用户觉得AI完全不记得。所以我在召回阶段做了双通道：先走SQL精确查实体，再走向量语义查近似，最后用规则合并去重，准确率能提升到91%。

第二组是端到端响应时延。冷启动（模型未加载）时，首次对话生成需要约2秒；热启动后对话响应稳定在600到900毫秒。这个数据距离系统级“零感知”还有差距，但作为App内助手已经可以接受。

第三组是存储增长曲线。我连续使用两周后，记忆表只增加了约2000条记录，占磁盘空间约4MB。关键是因为抽取管线做了充分的合并和去重，原始日志会被删除，只保留提炼后的摘要。这种设计让长期运营成本可控，不会因为用久了就卡顿。

参数修正上，我调过两个影响最明显的值。第一个是召回数量，试过Top-20注入，模型回答会变啰嗦；Top-3则经常漏关键信息，最后稳定在Top-7。第二个是重要度阈值，低于0.3的记忆基本不参与召回，这样可以过滤掉大量“吃过一顿外卖”级别的琐碎信息。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

长期记忆系统在实际运行中，问题比想象中多。我把高频问题整理成一张速查表，都是自己或同事在项目里真实遇到过、并已解决的案例。

每一个问题我在排障过程中都养成一个习惯：先看日志，再看数据，最后才怀疑代码。很多看似是算法问题，查到最后其实是数据的坑。比如“张冠李戴”那个案例，当时我排查了很久，最后发现是用户常去的两家店用同一个简单称呼，实体归一化没做，两条记忆被并成了一个。

5.2 几条亲测有效的避坑经验

聊到避坑，有几条经验是普通文档里不太会写的，但实际操作中没有它们真的会走弯路。

第一，别迷信大模型抽取能力。端侧模型受参数量限制，抽取结果不会太稳定。我建议对抽取结果做“二次校验”：把抽取的关键实体回填到原句中，做一个简单的包含检查。如果实体在原句中都找不到，多半是抽错了，直接丢弃。这个规则成本极低，但能过滤掉大量幻觉样本。

第二，记忆更新的优先级要大于新增。用户对同一地点的偏好其实会漂移，如果只做增量不更新旧记忆，会让AI逐渐变得“记忆混乱”。我会在写入新记忆时先查一遍旧记录，对同一实体加上时间衰减权重，然后决定是覆盖、合并还是并存。很多端侧记忆项目后来出问题，不是记不住，而是记了太多互相矛盾的东西。

第三，一定要做记忆的“过期归档”。端侧存储空间是有限的，我建议给每条记忆设一个生命周期。日程类的记忆保留七天到一个月，偏好类的保留一到两年，而身份类的可以长期保留。归档不是删除，而是降级到冷存储，不进热检索，保证日常查询永远走最精简的数据集。

第四，千万注意电池优化白名单。端侧长期记忆系统是一个需要后台Service支撑的应用，国产手机的省电策略非常激进，默认状态下后台任务很快会被杀死。我在交付项目时都会附带一段配置说明，提醒用户把App加入电池优化白名单，同时开一个通知栏常驻通知，告诉用户“AI记忆正在后台整理数据”。这既是技术需要，也是产品透明度的一部分。

6. 从MobileMem看端侧记忆生态的走向

6.1 从“功能调用”到“记忆主权”

聊完工程细节，再回到MobileMem这个方向本身。我越来越觉得，端侧长期记忆改变的不仅是AI对话的体验，更是人和手机之间的关系。

现在的手机AI大多是“功能调用者”，用户说一个指令，它执行一个动作。但当长期记忆真正跑起来之后，手机AI开始变成“主动的服务者”。它知道你的习惯、你的计划、你的重要关系，能提前准备好你需要的信息，甚至在你忘记的时候提醒你。这种转变，会让用户对手机产生更深度的依赖，也会让手机厂商的竞争从“硬件参数”转向“记忆能力”。谁的手机更能记住你、更懂你，谁就可能留住用户。

这里面有一个耐人寻味的点：当记忆被放在端侧，并且格式和接口足够开放时，用户实际上是获得了“记忆主权”的。他们可以随时查看自己的记忆、导出、删除，甚至带着这些记忆跨平台迁移。相比之下，云端记忆虽然强大，但用户无法真正控制它。MobileMem这类端侧方案，等于把AI手机个性化的底座交还给用户，这个趋势我觉得挡不住。

6.2 开发者现在能做什么

对于正在做端侧AI、AI Agent、手机本地部署的开发者，我的建议很简单：现在就动手做记忆模块，不要等系统级别方案成熟。

系统级方案落地还需要很长的周期，而且一定会倾向于服务厂商自家生态。但散落在应用层的记忆机会，现在是敞开的。你可以做一个会议记录App，让它在本地记住每一个参会者的偏好；你可以做一个健身助手，记住用户每一周的身体数据和训练感受；你甚至可以做一个通用的“个人记忆库”，把用户看过的文章、去过的地方、聊过的话题全部沉淀在本地，再通过开放接口给其他App调用。

技术上，MobileMem这么一套基于端侧大模型加混合检索的记忆系统，在这个时间段已经具备落地条件。你需要准备的东西无非是一个量化好的小模型、一个带向量插件的移动端数据库、一组抽取和召回的逻辑，再加上对手机系统层面的调优经验。这些我在前面都拆开讲过了，照着我这套方案改一改，完全可以在现有手机上跑出一个像样的端侧长期记忆Demo。

我在实际使用中发现，长期记忆最打动人的地方，不是它记住了一切，而是它在恰当的时机轻声提醒你那些你自己都快要忘掉的事。这种“被理解”的瞬间，比任何炫酷的生成效果都更有价值。而要做到这一点，把记忆放在端侧、把主权交给用户，几乎是唯一可行的路线。如果你也在做端侧AI或者AI Agent，我建议把长期记忆当成一个独立模块尽早规划进去，等生态成熟再入场，就真的晚了。