1. 手机端Agent为什么不能照搬云端RAG那套做过云端RAG的人第一次接触手机Agent的记忆系统最容易犯的一个错误就是直接把服务端那套向量库检索拼接的架构平移过来。我一开始也是这么想的结果在真机上跑了两周就发现根本行不通。手机端Agent面临的约束和服务端完全不是一个量级内存要控制在百兆级别、存储空间用户随时可能清理、推理延迟必须压到毫秒级、还要考虑电量消耗和隐私合规。这些约束叠加在一起意味着你必须重新思考记忆这件事在端侧到底应该怎么组织。Agentic-RAG这个概念最近被讨论得很多但真正落到手机Agent场景它的含义和云端有本质区别。云端RAG的核心矛盾是检索精度和知识覆盖而手机端Agent的核心矛盾是记忆的时效性和资源占用之间的平衡。用户今天早上说了一句帮我记一下下午三点开会这条记忆如果到晚上还没被正确召回或者正确遗忘那这个Agent就是失败的。它不需要知道全世界所有知识它只需要在正确的时刻想起正确的那件事。我在实际项目中总结出一个判断标准如果一个记忆条目在7天内没有被任何一次对话触发召回那它大概率应该被降权或者归档。这个标准听起来简单但背后涉及的是端侧记忆系统的整套生命周期管理——写入、索引、召回、衰减、归档、清理。每一个环节都要在资源受限的前提下做出取舍。下面我会把这套系统的设计思路、踩过的坑、以及实测有效的方案完整拆开讲。2. 端侧记忆系统的分层架构设计2.1 为什么不能只做一层向量检索很多人理解的RAG就是把文本转向量存进向量库查询时做相似度匹配。这套方案在云端可行因为云端有足够的算力和存储去维护一个百万级甚至千万级的向量索引。但在手机端你不可能在用户设备上维护一个持续增长的向量库——存储会爆检索延迟会随条目数线性增长而且每次App冷启动都要重新加载索引用户体验直接崩掉。我的做法是把记忆系统拆成三层热记忆层、温记忆层、冷记忆层。热记忆层只保留最近24小时内产生的高频记忆用轻量级的键值对结构存在内存里检索走精确匹配加简单模糊匹配延迟控制在5毫秒以内。温记忆层存最近30天的记忆用压缩后的向量表示存在本地数据库里检索走近似最近邻延迟控制在50毫秒以内。冷记忆层是超过30天的归档记忆只在用户主动查询历史时才触发加载平时不占用常驻内存。这个分层策略的核心逻辑是记忆的价值随时间衰减但衰减曲线不是线性的。刚产生的记忆价值最高24小时内如果没被召回价值会快速下降但如果一条记忆在30天内被反复召回说明它对用户很重要应该被提升到热记忆层而不是按时间一刀切地归档。所以我在分层之上又加了一个召回频次计数器每次记忆被命中就加一连续7天零命中的记忆自动降层。2.2 记忆写入时的预处理管线端侧写入记忆不是简单地把用户说的话存下来。原始对话文本里包含大量噪声语气词、重复表达、指代不明的代词、以及和当前任务无关的闲聊。如果直接把这些原始文本向量化检索出来的结果会非常糟糕。我设计了一条四步预处理管线第一步是意图过滤。用一个小型的分类模型判断这句话是否包含值得记忆的信息。比如今天天气不错这种话就不需要进入长期记忆而我下周三要去外地出差就必须记住。这个分类模型我用的是蒸馏后的轻量级模型参数量控制在10M以内推理耗时不到3毫秒。第二步是指代消解。用户说帮我把它加到购物车这个它指的是什么必须结合上下文把指代补全否则这条记忆存下来就是废的。端侧做指代消解不能用大模型我的方案是维护一个最近5轮对话的实体栈用规则加轻量级模型结合的方式做消解。第三步是结构化抽取。把非结构化的自然语言转成结构化字段时间、地点、人物、事件、动作。这一步是为了后续的精确检索服务的。比如用户说提醒我周五下午给张工回电话抽取出来的结构是{时间: 周五下午, 对象: 张工, 动作: 回电话}。有了这些字段检索时就可以做多路召回而不是只依赖向量相似度。第四步是向量化与压缩。端侧向量化不能用大模型我用的是一个经过领域微调的小型编码器输出维度压到128维再用乘积量化压缩到32字节。这样一条记忆的向量存储成本不到100字节一万条记忆也才1MB左右完全在可接受范围内。2.3 召回时的多路融合策略检索环节是整个系统最考验工程能力的地方。纯向量检索在端侧有两个致命问题一是小模型编码器的语义表达能力有限长尾query的召回率很低二是向量检索对精确匹配不敏感用户问上周三那个会议向量检索可能返回一堆语义相似但时间不对的结果。我的方案是三路召回加权融合结构化字段召回如果query里包含明确的时间、地点、人物等实体直接走结构化字段的精确匹配。这条路召回率不高但精度极高。关键词召回对query做分词后走倒排索引适合处理专有名词和特定术语。向量召回走近似最近邻适合处理语义模糊的query。三路结果出来后用一个轻量级的排序模型做融合打分。排序模型的输入特征包括各路召回分数、记忆的时间衰减因子、历史召回频次、以及记忆类型权重。这个排序模型我训练时用的样本量不大大概两万条人工标注数据但效果比单纯加权求和好很多。实测经验三路召回的权重不是固定的要根据query类型动态调整。如果query里检测到时间实体结构化召回的权重应该从默认的0.3提升到0.6以上。这个动态权重策略让整体召回准确率提升了将近18个百分点。3. 记忆衰减与遗忘机制的工程实现3.1 为什么必须做遗忘这是我在项目初期最纠结的一个点。好不容易存下来的记忆为什么要主动忘掉后来想明白了不遗忘的系统最终会被自己的记忆淹没。手机端存储空间有限用户用一年下来可能产生几万条记忆如果全部保留且全部参与检索检索延迟会从毫秒级退化到秒级用户体验直接归零。但遗忘不能是简单的删除。用户可能三个月后突然想起我之前让你记过一个什么东西这时候如果记忆已经被物理删除Agent就彻底失忆了。所以我的方案是分级遗忘先降权再归档最后才考虑物理删除。降权后的记忆仍然可以被检索到只是排序分数会很低除非query非常精确地匹配到它否则不会出现在结果里。3.2 衰减函数的参数调优衰减函数我试过好几种形式最终选定的是改进的艾宾浩斯曲线score base_score * exp(-λ * days_since_last_recall) * (1 α * recall_count)其中λ是衰减系数α是召回频次增益系数。这两个参数的调优过程很有意思。λ太大记忆衰减太快用户会觉得Agent记性差λ太小记忆衰减太慢检索结果里会混入大量过时信息。我最终把λ定在0.05意味着一条记忆如果30天没被召回分数会降到初始值的22%左右。α的调优更微妙。如果α太大一条被偶然召回多次的记忆会长期霸占检索结果顶部即使它已经不再相关。我最终把α定在0.1并且加了一个时间窗口限制只有最近90天内的召回才计入recall_count超过90天的召回记录会被清零。这个设计是为了防止僵尸记忆——那些曾经重要但现在已经过时的信息。3.3 归档与冷启动的平衡归档记忆的加载策略是另一个容易踩坑的地方。我一开始的做法是App启动时把所有归档记忆的索引加载到内存结果冷启动时间从1.2秒涨到了3.5秒用户直接感知到卡顿。后来改成懒加载预取结合启动时只加载归档记忆的元数据索引大概占几十KB当用户query触发了归档记忆的召回时再异步加载对应的完整记忆内容。预取策略是基于用户行为模式的。我统计发现用户在工作日上午更可能查询会议相关的历史记忆在晚上更可能查询生活类记忆。所以系统会根据当前时间段预取对应类别的归档记忆索引进一步降低首次召回的延迟。4. Agentic-RAG中Agentic到底体现在哪4.1 从被动检索到主动记忆管理传统RAG是被动的用户提问系统检索返回结果。Agentic-RAG的核心区别在于Agent会主动管理自己的记忆。这意味着系统不只是等待query来触发检索而是会主动做几件事第一主动识别记忆冲突。用户上周说我下周五有空这周说我下周五要出差这两条记忆是冲突的。Agent应该主动检测到冲突并在检索时优先返回最新的那条同时把旧的那条标记为已过时。第二主动做记忆聚合。用户可能在不同时间点分别说了我喜欢喝美式、我一般不加糖、我下午喝咖啡会失眠这三条记忆单独看价值有限但聚合起来就是一条高价值的用户画像用户喜欢美式不加糖但下午不宜摄入咖啡因。Agent应该主动做这种聚合而不是等用户来问。第三主动做记忆验证。有些记忆是有时效性的比如我下周三要去外地。到了下周四这条记忆就应该被标记为已过期不再参与常规检索。Agent应该主动做这个验证而不是等用户来纠正。4.2 记忆冲突检测的实现细节冲突检测的难点在于判断两条记忆是否真的冲突。表面上看下周五有空和下周五出差是冲突的但如果是不同人说的或者是在不同语境下说的可能并不冲突。我的方案是用一个轻量级的自然语言推理模型做冲突判断输入是两条记忆的结构化表示输出是{冲突, 不冲突, 不确定}三分类。对于不确定的情况系统不会自动处理而是会在下次相关对话中主动向用户确认。比如Agent会说我之前记了您下周五有空但后来又记了您下周五要出差请问以哪个为准这种主动确认的行为是Agentic-RAG区别于传统RAG的重要特征。4.3 记忆聚合的触发时机记忆聚合不能太频繁否则会消耗过多算力也不能太稀疏否则聚合价值体现不出来。我的策略是事件驱动定时补偿结合事件驱动当同一主题下的记忆条目超过阈值我设的是5条立即触发一次聚合。定时补偿每天凌晨设备空闲时对过去24小时新增的记忆做一次全量聚合检查。聚合本身用的是规则加模板的方式而不是生成式模型。因为端侧生成式模型的推理成本太高而且聚合结果需要稳定可预期。比如时间类记忆的聚合就是取并集加冲突标记偏好类记忆的聚合就是取交集加权重排序。5. 端侧推理的性能优化实战5.1 模型量化与算子融合端侧跑RAG最大的瓶颈是推理速度。我用的编码器原始版本是FP32的单次推理要40毫秒完全不可接受。经过INT8量化后降到12毫秒再做算子融合后降到8毫秒。量化的过程不是一帆风顺的直接做PTQ训练后量化会导致召回准确率下降5个百分点左右。后来我用了QAT量化感知训练在训练阶段就模拟量化误差最终准确率只下降了不到1个百分点。算子融合主要是把LayerNorm和Attention的矩阵乘融合在一起减少内存访问次数。这个优化在端侧效果特别明显因为端侧的内存带宽是瓶颈计算单元反而经常处于空闲状态。5.2 缓存策略的设计端侧推理的另一个优化点是缓存。我设计了两级缓存Query缓存对用户query做归一化后哈希如果命中缓存直接返回结果。这个缓存的命中率大概在15%左右主要覆盖用户重复提问的场景。Embedding缓存对高频出现的实体和短语预计算embedding检索时直接查表而不是重新编码。这个缓存让平均检索延迟降低了30%以上。缓存的失效策略也很关键。Query缓存的TTL设的是5分钟因为用户的意图可能在短时间内变化。Embedding缓存用的是LRU加时间衰减最近最少使用的条目会被优先淘汰。5.3 内存占用的实测数据经过上面这些优化最终系统的资源占用情况如下模块常驻内存峰值内存说明热记忆层2MB5MB最近24小时记忆温记忆层索引8MB15MB30天记忆向量索引冷记忆层元数据0.5MB2MB归档记忆索引编码器模型15MB20MBINT8量化后排序模型3MB5MB轻量级排序运行时缓存5MB10MB两级缓存合计33.5MB57MB这个占用水平在中端手机上完全可以接受不会对系统造成明显压力。作为对比我见过一些直接移植云端方案的实现常驻内存动辄上百MB在低端机上直接OOM。6. 隐私合规与数据安全的端侧方案6.1 为什么端侧RAG天然有隐私优势云端RAG最大的隐私问题是用户数据要上传到服务器。即使做了脱敏和加密用户仍然会担心我的对话被存到了别人的服务器上。端侧RAG天然解决了这个问题所有记忆都存在用户设备上不上传、不共享、不用于训练。这个优势在手机Agent场景下特别重要因为手机承载的是用户最私密的数字生活。但端侧方案也有自己的隐私挑战。比如设备丢失后记忆数据如何保护我的方案是记忆数据加密存储密钥由设备的硬件安全模块管理即使有人拿到了存储文件也无法解密。另外敏感类记忆比如涉及健康、财务的会额外加一层应用级加密需要用户生物认证才能访问。6.2 记忆的权限隔离手机Agent可能同时服务多个场景工作、生活、娱乐。这些场景的记忆应该做权限隔离工作场景的Agent不应该能访问生活场景的记忆。我的实现方案是记忆打标签访问控制列表。每条记忆在写入时都会被打上场景标签检索时只返回当前场景有权限访问的记忆。这个隔离不是绝对的安全边界因为用户可能在同一句话里同时涉及工作和生活。对于这种跨场景记忆我的处理方式是拆分成多条单场景记忆分别存储检索时再按需聚合。这样虽然增加了存储开销但保证了权限隔离的清晰性。6.3 用户对记忆的可控性Agentic-RAG的一个伦理问题是Agent主动记忆用户的行为用户是否有足够的控制权我的设计原则是用户必须能随时查看、修改、删除任何一条记忆。系统提供一个记忆管理界面用户可以看到Agent记住了什么可以手动删除不想要的记忆也可以标记某些记忆为永久保留。这个设计不只是为了合规也是为了建立用户信任。实测发现当用户知道自己的记忆是可控的他们反而更愿意让Agent记住更多东西。这是一个正向循环信任带来更多记忆更多记忆带来更好的服务更好的服务带来更多信任。7. 演进方向与踩坑复盘7.1 从规则驱动到学习驱动的过渡我最初版本的记忆管理系统是纯规则驱动的什么条件下写入、什么条件下召回、什么条件下遗忘全部是硬编码的规则。这套方案上线后暴露了两个问题一是规则覆盖不全很多边界情况处理不了二是规则之间会冲突维护成本越来越高。后来我逐步引入了学习驱动的组件用分类模型替代写入规则用排序模型替代召回规则用强化学习优化遗忘策略。这个过渡不是一蹴而就的我的策略是先规则后模型模型只替换规则中表现最差的部分。这样既保证了系统的稳定性又逐步提升了效果。7.2 几个印象深刻的坑第一个坑是向量维度选择。我一开始用了256维觉得维度越高表达能力越强。结果发现端侧编码器在256维下训练不充分很多维度是噪声反而拉低了召回准确率。降到128维后效果反而更好而且存储和计算成本都降了一半。这个教训是端侧模型不是越大越好要和训练数据量、算力预算匹配。第二个坑是时间衰减的时区问题。用户跨时区旅行时记忆的时间戳会混乱导致衰减计算错误。后来我统一用UTC时间戳存储展示时再转本地时间解决了这个问题。第三个坑是冷启动时的记忆加载顺序。我一开始按时间倒序加载结果最近但最不重要的记忆先加载重要的历史记忆反而排在后面。后来改成按重要性分数排序加载重要性分数由召回频次、记忆类型、时间衰减综合计算得出。7.3 下一步可以探索的方向目前系统还有一个明显的短板跨设备记忆同步。用户可能在手机和平板上都使用Agent但两边的记忆是独立的。理想情况下记忆应该跟随用户而不是设备。但跨设备同步涉及隐私、冲突解决、带宽消耗等一系列问题我还在探索阶段。另一个方向是记忆的可解释性。现在Agent召回一条记忆后用户不知道Agent为什么召回这条。如果能给出解释——因为您刚才提到了张工而这条记忆里也涉及张工——用户会对Agent的行为更有信任感。这个方向需要做召回路径的可视化技术上可行但会增加一定的计算开销。最后分享一个实操心得端侧记忆系统的调优没有银弹必须基于真实用户数据反复迭代。我建议在项目初期就埋好数据采集点记录每次召回的结果和用户的反馈比如用户是否点击了召回的记忆、是否纠正了Agent的回答。这些数据是后续优化的基础没有它们所有的调优都是盲猜。
