企业官网建设流程全解析

聊到AI手机，今年有个词绕不开：端侧长期记忆。MobileMem这个方向被不少厂商和开发者反复讨论，核心其实就一句话——让手机真正记住你，而不是每次对话都从零开始。过去我们习惯把记忆交给云端，但端侧长期记忆意味着你的习惯、偏好、上下文都留在本机，快、私密、不依赖网络，更贴近“AI手机”的日常使用逻辑。

这篇文章聊两层：第一层把MobileMem这套架构为什么有价值、关键机制是什么讲透；第二层给出一套可落地的参考方案，包括数据结构、检索逻辑、提示词注入模板，以及我实际调试时踩过的坑。想给手机App接上记忆能力、做智能助手或本地知识库的开发者，应该都能从中找到直接能用的东西；正在规划AI手机产品的朋友，也可以拿这份思路判断该在哪条技术路线上投入。

1. MobileMem在解决什么问题：从“AI很聪明”到“AI记得我”

1.1 为什么AI手机必须有自己的记忆

先回想一个场景。你对着手机说：“明早8点提醒我吃药。”第二天早上又问：“我今天几点需要吃药？”很多传统助手会卡壳，因为上一轮对话在会话结束后就被清掉了。现在的端侧大模型很聪明，但如果没有记忆，本质还是“金鱼脑”——每次都聪明，但每次都从零开始。

这不只是体验问题，而是决定AI手机价值上限的问题。手机里的AI要真正成为“贴身助理”，必须跨会话理解用户。它包括几个层次：知道你是谁、知道你关心什么、知道你最近在处理什么，以及知道哪些事情在什么时间点需要主动提出来。这些信息只靠云端通用大模型提供不了，因为云端模型对每个用户是“一视同仁”的，而端侧长期记忆恰恰提供了“千人千面”的个性化底座。

我在做原型时的体会是，没有记忆的AI手机，就像雇了一个高学历但失忆的助理；能力很强，但完全不了解你。装上端侧记忆以后，才真正有了“助理”的感觉。MobileMem这个命名的价值，就是把记忆从云端会话里抽出来，变成手机本地的一项基础设施。

1.2 云端记忆为什么替代不了端侧记忆

很多人会问：记忆放云端不一样吗？反正模型也能调用。这个疑问很自然，但实际情况差很远。

一是延迟。端侧记忆的读取发生在本地，几毫秒就能完成；走云端意味着每一次记忆问答都依赖网络，信号差的时候体验断崖式下跌。二是隐私。情绪记录、健康信息、人际关系、上下班路线，这些数据用户只愿意放在自己手机里，上传到云端很容易触碰红线，而且很多地区的合规要求也不允许随意上传。三是成本。云端存储和Token调用都有持续成本，如果每个用户每天都产生大量交互记忆，这笔账多数产品扛不住。

这里也要说清楚：端侧记忆和“手机AI本地部署软件”是两件事，但高度相关。今年本地部署热度很高，很多人以为模型跑在本地就够了，实测下来发现，没有记忆的本地模型和云端模型一样金鱼脑。本地部署解决的是模型跑哪里，端侧长期记忆解决的是数据从哪来、怎么沉淀。你可以用端侧模型配端侧记忆，也可以用云端模型配端侧记忆，MobileMem这套范式把记忆层独立出来，正好补上了本地部署最缺的那块拼图。

1.3 端侧长期记忆的三个关键约束：存储、算力、隐私

端侧记忆不是“把日志存下来”那么简单，它要面对手机真实的资源约束。

存储约束：手机存储虽然已经做到256G甚至1T，但不可能让AI记忆无限占用。以实用为目标，一份成熟的端侧记忆库应该控制在几十MB级别，而不是几个G。这意味着不能原文全存，必须抽摘要、提实体、做结构化。

算力约束：记忆的写入要做语义抽取和向量化，召回要做相似度计算，这些步骤跑在手机CPU/NPU上，单次操作必须控制在几十毫秒到百毫秒级，否则用户会明显感到卡顿。模型要量化，向量维度要控制，索引要紧凑。

隐私约束：这是底线。密码、支付信息、身份证号、医疗详情等敏感数据默认不记录；记忆库要能加密存储；用户要能随时查看、删除、关闭记忆功能。

所以我理解MobileMem真正的工程挑战不是“能不能记住”，而是在这三种约束下“怎么记、记多少、怎么忘”。这也决定了它会有独立的架构设计，而不是简单调个API。

2. 端侧长期记忆的核心机制拆解

2.1 记忆从“生成”到“沉淀”：采集与抽象

把对话原文直接写进记忆库，是我见过最常见的错误。1个小时的聊天记录可能有几百行原文，10个用户就能撑爆存储。真正的做法是“先抽象，再存储”。

比如用户说“我下周一下午要去医院复查，顺便帮我看看有没有时间吃个饭”，系统不应该存下这句口语全文，而应该抽取成结构化的语义单元：

• 日期：下周一（对应具体日期）
• 时段：下午
• 事项：医院复查
• 关联意图：可能需要时间规划

这个抽取过程可以交给端侧小模型做，也可以用一个“规则+模型”的混合管线。规则负责兜底，比如匹配日期、时间、地点等实体；模型负责理解意图和关系。实际项目中我建议最先跑规则，因为日期/时间这种高频实体，规则几乎100%准确；意图抽取再交给模型，能省掉不少Token调用。

抽象之后还需要做“去重”。用户今天说“我喜欢喝美式咖啡”，明天又说“咖啡我要美式”，这两条应该合并成一条，而不是存两条。去重逻辑可以简单点：同分类、同实体、语义向量的余弦相似度超过0.9，就当作重复内容，更新原条目的访问时间即可。

2.2 结构化存储与向量检索：让记忆能被找到

记下来只是第一步，关键在“能被想起来”。这里需要两条腿走路：结构化字段用来做精确过滤，向量检索用来做语义召回。

我用SQLite做载体，示例表结构是这样的：

CREATE TABLE memories ( id INTEGER PRIMARY KEY AUTOINCREMENT, content TEXT NOT NULL, category TEXT DEFAULT 'general', importance REAL DEFAULT 0.5, embedding BLOB, created_at INTEGER, last_access_at INTEGER, access_count INTEGER DEFAULT 0, expire_at INTEGER ); CREATE VIRTUAL TABLE memories_fts USING fts5(content, category);

每个字段都有用途。content是压缩后的记忆原文，category用来区分偏好、日程、人物、习惯等类型，importance是重要度分数，embedding存向量，created_at和last_access_at管生命周期，access_count记录被命中的次数，expire_at做过期清理。FTS5是SQLite自带的全文索引，做关键词精确匹配时效率很高。

向量检索我建议用嵌入式方案。比如sqlite-vec，或者把向量直接存在BLOB字段里、自己算余弦相似度。数据量在1万条以内时，全量线性扫描也只需要几毫秒，完全够用。不要一上来就上重型向量数据库，手机端没有必要。

2.3 记忆的遗忘与更新：长期可用的关键

人类记忆会遗忘，AI端侧记忆也要会“忘”。如果只记不忘，三个月后记忆库里塞满大量过期信息，召回的准确率会明显下降。

我的做法是给每条记忆算一个“综合优先级”：

• 相似度分（当前查询和记忆向量的余弦相似度），权重约0.6；
• 重要度分（这条记忆本身的重要性，写库时评估），权重约0.25；
• 活跃度分（距离last_access_at越近分越高），权重约0.15。

排序时按这三项加权求和。效果是：既保证语义匹配优先，又让高频使用过的重要记忆排到前面，长时间不用的低价值记忆逐渐沉底。

定期压缩也很必要。每天晚上把当天新增的零散记忆做一次合并摘要，比如用户一天里聊了三次关于项目A的事，合并后只保留一条“今天重点推进了项目A的XX模块”。超过90天没被访问且重要度低于0.3的条目，直接删掉。这一步做完，记忆库体积能稳定在很小范围，召回质量反而更高。

3. 实操落地：给手机App接上端侧记忆的完整方案

3.1 落地场景与工程选型：我为什么选SQLite加FTS5加Embedding

先说场景。我做的是一个“AI个人助手”参考应用，覆盖三类典型需求：问偏好（“我一般几点睡”）、查日程（“明天下午有什么安排”）、话题续聊（“上次说的那个方案后来怎么样了”）。

工程选型上我推荐一套朴素但能打的组合：SQLite负责结构化存储，FTS5负责关键词精确检索，一个轻量Embedding模型负责向量化召回，端侧LLM负责信息抽取和生成。这套组合的优势是：SQLite是移动端标配，几乎零额外依赖；FTS5不需要单独装服务；Embedding模型量化后只有几十MB，手机跑得动。以下示例用Android/Kotlin风格给出，iOS用Core Data加类似思路完全可以平移。

3.2 第一步：记忆写入，把对话变成结构化数据

记忆写入是关键路径，大概是这个流程：

1. 用户在对话中透露信息；
2. 端侧模型做意图识别和实体抽取；
3. 检查重复；
4. 评估重要度；
5. 生成Embedding向量；
6. 写入数据库，同时更新FTS索引。

核心代码逻辑大致如下：

fun saveMemory(rawText: String) { val extracted = extractor.extract(rawText) ?: return // 抽不出有效信息就不记 if (deduplicator.isDuplicate(extracted)) { memoryDao.touch(extracted.id) return } val importance = importanceScorer.score(extracted) val vector = embeddingModel.encode(extracted.content) memoryDao.insert( MemoryEntry( content = extracted.content, category = extracted.category, importance = importance, embedding = vector, createdAt = System.currentTimeMillis(), lastAccessAt = System.currentTimeMillis() ) ) }

这里我特别强调两个容易被忽略的细节。第一，信息抽取模型的输出要限定为JSON结构，内容要短，比如控制在20个token以内，这能让下游流程稳定不少。第二，重要度不是简单拍脑袋，可以基于意图类型给默认值：健康、财务、家庭相关的消息重要度最高，生活吐槽和闲聊最低，默认给0.5。

3.3 第二步：记忆召回，让AI想起来你是谁

召回的质量直接决定用户体验。我采用的是“向量召回+全文检索+加权融合”方案。

fun retrieveMemories(query: String, topK: Int = 10): List<MemoryEntry> { val queryVector = embeddingModel.encode(query) val vectorHits = memoryDao.searchByVector(queryVector, limit = 30) val keywordHits = memoryDao.searchByKeyword(query, limit = 30) return mergeAndRank( query = query, vectorHits = vectorHits, keywordHits = keywordHits ).take(topK) }

光用向量召回会漏掉专有名词。比如用户查询“我女儿豆豆多大了”，如果记忆库里的原文是“孩子今年6岁”，向量相似度可能不够，但FTS对“豆豆”做关键词命中，能把这条例外捞回来。所以向量和关键词要双通道召回，合并后按综合优先级排序。

排序公式我在上一节提过，实操中还要加一个过滤条件：importance < 0.2且 近期未被访问过的条目，不参与召回。这能避免大量噪音抢占上下文窗口。

3.4 第三步：记忆注入提示词，效果才真正显现

召回结果最终要送进大模型。这步做得不好，前面全白费。

我的提示词模板大概是这个结构：

你是用户的端侧AI助手。请根据用户当前问题和以下历史记忆回答。 如果历史记忆与问题无关，直接回答当前问题，不要强行引用记忆。 相关历史记忆： - 用户偏好：喜欢喝美式咖啡，不加糖，最近在控制咖啡因摄入。 - 日程安排：今天下午15:00有项目周会。 - 人物关系：用户的女儿叫豆豆，今年6岁。 当前问题：我今天什么时候开会？

记忆条目的顺序很关键。相关性高的放前面，因为模型会更关注前面的内容。数量上我建议最多注入8到10条，超过这个量，模型会“看不过来”，也容易产生幻觉。如果召回结果超过10条，只取排序最靠前的10条，不要贪多。

3.5 把记忆做成一个可观察的模块

端侧记忆最怕的就是变黑盒，记了什么、为什么这么回答，用户和开发者都看不到。我强烈建议在原型阶段就加一个“记忆面板”，用列表展示当前记忆库里的所有条目，标出重要度、来源时间、最近命中时间。测试时随时打开它，就能判断“这数据到底写对没有”“上次召回为什么没中”。后续上线时，这个面板还可以直接做成用户可管理记忆的功能入口。

4. 调优路上的坑：记忆不生效、体积膨胀怎么办

4.1 召回不中：先查Embedding与查询改写

“记了像没记”是最高频的问题。我排查时的顺序是这样的：先确认数据库里有没有数据；再确认Embedding模型在当前查询上有没有输出有效向量；然后检查查询词是不是太短或太口语化。

一个很典型的坑：用户问“我今天有啥事”，而记忆里存的是“用户下午三点参加产品评审”。向量相似度可能只有0.5左右，不够排进TopK。解决办法是加一层轻量查询改写：把“今天有啥事”改写成“今天的日程安排、待办事项、会议”，再用改写后的Query做召回。改写模型可以很小，十几MB的参数能力足够。

4.2 存储膨胀：压缩、分片与定期合并

原样存对话日志是最快的撑爆存储方式。假设一次问答平均200个Token，每天交互50次，一天就是1万Token，一个月30万Token。直接存原文，很快就能膨胀到几十MB甚至上百MB，而且大部分是无效信息。

应对方式，一是抽象存储，只留实体和语义摘要；二是分片管理，按天存储、按月归档；三是定期合并，把同一主题的碎片合成一条概括性记忆；四是TTL过期，低重要度条目超期自动清理。我建议把目标定在“单用户记忆库长期稳定在20MB以内”，这个目标用上面的策略完全能达到。

4.3 隐私红线：记忆不是“越全越好”

我在调试过程中最慎重的一条红线：能记住日常，但绝不能碰敏感数据。银行卡号、密码、身份证号、医疗诊断结论，这几个类别要直接放进黑名单，不写入记忆库。用户主动说出口也不行，端侧模型要做一次敏感信息识别，发现命中了就只当轮对话使用，不落库。

另外，记忆库默认要加密存储。Android上可以用Keystore里的对称密钥加密整个数据库文件，iOS用Keychain。哪怕数据不出手机，也不能明文躺在磁盘上。

4.4 常见问题速查表

5. 从记忆到主动智能：MobileMem能扩展的方向

5.1 端侧记忆驱动的主动提醒

记忆积累到一定程度，就不只是“被问时回答”了，它可以主动做事。用户上周提了一句“周五下午去复查牙齿”，到了周五早上，手机基于端侧记忆里的日程和偏好，自动推送一条提醒：“今天下午复查，医院停车场较挤，建议提前出发。”

这件事的关键在于，主动提醒必须懂“轻重”。这就要用到记忆里的重要度和时效性字段。重要度高的日程类记忆，才能触发主动服务；闲聊类记忆，最多用于回答，不主动打扰。这个分权设计，决定了用户会不会留下这个功能。

5.2 多模态记忆：把语音、图片和操作行为记下来

对话只是记忆的一种输入，端侧还可以记录更多模态。语音备忘录转成文字后抽取摘要；截图发生日邀请函，OCR之后提取时间地点；用户在App里的高频操作，也能沉淀为“习惯”类记忆。

这些能力接入的原则和文本一样：先抽取、再结构化、再进同一个记忆库。多模态只是丰富输入渠道，核心引擎不需要变。

5.3 跨应用记忆与个人智能中枢

更远一步，端侧记忆可以成为整个手机系统的“个人智能中枢”底座。在取得用户明确授权的前提下，日历、备忘录、相册、聊天记录里的信息经过端侧抽取后，统一进入个人记忆库。用户问任何一个问题，都能得到跨App的答案。

这里最关键的仍然是隐私授权和端侧处理。我个人判断，谁能把跨应用记忆的授权机制和安全边界做好，谁就能在AI手机体验上拉开身位。MobileMem这类端侧记忆框架，正好提供了这个底座的可能性。

最后分享一点实际体会

我在本机跑了两周端侧记忆原型，最大的感受不是它记住了多少，而是它“忘”得对不对。最初我把所有对话都塞进记忆库，结果一次回复里注入四五条无关记忆，体验非常差。后来把重要度阈值调高、加上时间衰减清理，整个效果才正常。

所以，端侧长期记忆的设计核心不是“存”，而是“取舍”。拿不准该不该记的，先别记；拿不准该不该给模型看的，先不给。这条原则，比任何花哨的模型和算法都更管用。MobileMem真正要打磨的，是让手机在有限的存储和算力里，记住最值得记住的事，并在最合适的时机想起来。