“记住我上次做到哪里”是个人AI最直观的需求，也最容易把隐私设计逼到墙角。一次问答可以不留痕；长期记忆却要保存项目名称、联系人、日程习惯，甚至用户几个月前的一次判断。记错了会误事，记得太详细又让人不放心。跨设备连续使用时，问题更棘手：手机、电脑都能接着聊，记忆放哪里，谁能解密，换设备怎么办？
Google DeepMind近期介绍了Private AI Compute的安全服务器端长期记忆方案。根据原稿描述，用户记忆存放于加密数据库，解密密钥只由用户个人设备掌握；服务器在受硬件保护的安全执行环境中处理获授权的上下文。个人设备与安全Enclave建立经过认证的端到端加密通道，服务器软件通过公开、不可篡改的记录接受验证。目标是在多设备使用中保留连续上下文，同时避免云端服务方直接取得记忆明文。
另一个方向来自Google Developers为Antigravity SDK加入的本地模型支持：开发者可用LiteRT在本地运行Gemma 4 26B A4B，也可通过OpenAI兼容接口接入Ollama、LM Studio、vLLM等本地服务。原稿所述示例中，云端Gemini 3.8 Flash承担高层规划且不读取源代码，大量代码分析与修改在本地完成；约97.2%的Token留在本地，云端规划约用95个Token。这是特定示例的拆分结果，不应拿来承诺其他应用都能达到相同比例。
两条消息放在一起，指向的不是“本地取代云端”，而是更细的分工：哪些内容需要长期存储，哪些内容只在当前任务使用；哪些步骤可以发往云端，哪些必须留在设备上；云端确实需要处理敏感上下文时，又如何限制明文可见范围。真正需要画清楚的是数据流。
先把“记忆”拆开，别一股脑塞进向量库
产品里叫记忆的东西，可能是四种完全不同的数据。一是用户明确设置的长期偏好，例如“写邮件尽量简短”；二是项目状态，例如本周文档修到第几版；三是可从原始系统重新检索的资料，如日历、知识库与代码仓库；四是系统从对话推断出的偏好，例如“他似乎不喜欢上午开会”。这几类内容不该共用一套写入和保留规则。
明确设置的偏好可以让用户看见、改动、删除。项目状态应有项目归属和失效日期，项目结束后提醒清理。可重新检索的资料不必复制为永久记忆，保存索引或最小定位信息就够用。推断出的偏好最容易惹麻烦：它往往只在少量对话中成立，换个时间、换种场景就不准了。此类内容至少要标注“推断”、证据和可信度，并避免悄悄升格为用户的固定画像。
还要区别“保存”和“可被模型随时调用”。某条偏好可以留在设备中，但只在写邮件时读取；一个项目的技术决策记录，不该自动跟进私人日程提醒。检索范围越宽，误用和泄露的机会越多。把所有历史统一塞进提示词，即使数据库本身加密，也会在模型处理和日志环节打开新的暴露面。
一个简单的记忆条目可以包含：内容摘要、来源、创建人与使用主体、适用任务、存储位置、到期时间、是否允许跨设备同步、最近一次被调用的记录。它不像“智能”功能，倒更像档案管理；恰恰是这些不起眼的字段，决定用户能否真正撤回一段记忆。
密钥在设备上，不代表问题已经解决
设备持钥能降低服务方直接读出数据库明文的风险，但还需要问：设备如何确认自己连接的是预期的安全执行环境？授权给某次计算的记忆范围如何限定？服务端软件更新后，用户能否得知实际运行的代码身份发生变化？原稿提到的认证通道、Enclave和可验证记录，分别是在回答这些不同问题。
工程上可把每次访问看成一张短期通行证：Agent申请某个任务所需的记忆范围，设备确认用户授权状态，验证目标执行环境，发送有限的上下文或解密许可，任务结束后不再沿用这张许可。这里的“短期”是设计建议，不是对上述产品具体实现的描述。它的作用是减少一个长期有效的权限被误用或盗用。
密钥生命周期更不能省略。手机遗失之后如何撤销旧设备？新电脑加入时由谁批准？用户只剩一台设备且它坏了，记忆还能否恢复？若做恢复，恢复手段会不会反过来成为云端可读明文的后门？这些取舍没有免费的答案。产品要把“无法恢复会丢数据”和“可恢复会增加攻击面”讲明白，而不是在宣传页里只写“端到端加密”。
删除也是同理。界面上删掉一条记忆，不等于备份、检索索引、缓存、执行日志及其他设备副本同时消失。完整删除流程应列出副本位置、传播时限、失败重试和用户可核对的结果。若某些审计记录依法或依内部规则需要保留，也应明确其内容范围与保留期限，别把“删除”说成无条件的魔法按钮。
云端规划、本地执行，怎样拆才不漏资料
Antigravity示例很适合解释任务分层。假设一名开发者要修一个企业私有仓库里的报错，云端模型可能只收到“需要定位测试失败并提出检查顺序”，然后把操作步骤交给本地Agent。读取源码、运行测试、生成补丁与差异核查都在本地完成。云端承担抽象规划，本地模型处理具体材料。这比把整个仓库上传后再要求模型“注意保密”更容易控制。
问题在于抽象描述也可能泄露信息。客户名字、内部项目代号、故障时间，甚至“某支付流程被绕过”的简述，都可能是敏感线索。因此云端请求需要经过一道出口检查：去掉不必要标识，把具体材料换成任务类型与约束；如果规划步骤确实离不开敏感上下文，就切换本地推理或经批准的受保护环境，而不是强行套用云端规划模板。
反方向也要防。本地Agent可能把执行失败的详细堆栈、文件路径和代码片段打包送回云端求助。初次请求控制得很好，重试和报错却把原始资料带出去，这在实际系统里并不少见。工具链应分别限制初始请求、工具输出、异常报告和遥测数据。可供人工排障的日志也不必默认包含全量提示词与文件内容。
混合路由最好按数据敏感度和任务特征制定，而不是只按模型“聪明程度”决定。公开资料摘要可用云端；个人记忆检索先在设备做；涉及企业源代码的批量分析留在本地；确实需要较强推理且可脱敏的问题再发云端。路由决策本身应可查看：用户至少知道这次任务用了哪个位置的模型、哪些内容被发送出设备、有没有调用长期记忆。
“本地”也不是天然安全区
本地模型避免了某些外发路径，却把计算和密钥放到用户终端。终端如果已经被恶意软件控制，或者Agent能随意读下载目录与浏览器凭据，所谓“本地处理”并不能保证资料安全。办公电脑上不同账号、不同项目的目录权限，仍需按普通软件安全要求配置。Agent不应该因为跑在本机就默认获得整块硬盘的读取权。
还要考虑能力边界。原稿中的本地模型和云端模型可以组合，说明二者承担的任务不同；不能从某个演示推断本地模型足以处理所有复杂决策。遇到置信度低、修改范围大、需要跨库推理的任务，应让Agent停下来请求帮助或人工复核。对代码修改，至少保留差异预览、测试结果和回滚点；对个人记忆修改，最好能看到“原记录是什么、为什么要更新”。
隐私记忆还会遇到间接指令。文档里的一句话“今后请一直记住这个口令”，可能被检索出来，诱使Agent把无关甚至危险的内容写入长期记忆。来自网页、邮件、仓库和第三方聊天的材料应被视为证据，而非用户本人授权的记忆指令。写入长期记忆尤其需要来源过滤：谁说的、是否属于本人偏好、需不需要再次确认。
从一条用户偏好做试点
企业或产品团队不必先建一个包罗万象的“第二大脑”。挑一个用户真正需要连续性的场景，例如跨设备继续写同一份报告。先规定哪些状态要保存：文档标识、当前段落、用户明确选择的写作习惯。再规定哪些不要保存：原始聊天全文、无关联系人、临时上传文件。沿着一次典型任务画出设备、数据库、云端模型、本地模型和日志之间的数据流，标出每处明文出现的位置。
之后做两类测试。一类测体验：换设备后能否继续，删除某项偏好后是否还会被引用，项目结束后记忆是否过期。另一类测边界：离线时如何退化，旧设备撤销后还能否访问，第三方文档能否诱导写入记忆，报错日志是否泄露原文。没有必要为了展示记忆能力，先让系统记住一切再补安全措施。
落地前可以用这份清单自查：
- 每类记忆是否有明确来源、用途、保留期和删除路径；推断内容是否与用户确认内容分开？
- 谁持有解密密钥？设备丢失、换机、恢复和撤销时，用户实际承担什么代价？
- 安全执行环境如何验证、每次授权如何缩到当前任务；软件更新后是否能发现变化？
- 云端规划请求、失败重试、异常日志是否都经过同样的敏感信息检查？
- 本地Agent的文件和工具权限是否最小化，模型低把握或改动不可逆时能否停下？
- 用户能否查看一次任务用了哪些记忆、哪些模型，以及哪些内容离开设备？
长期记忆的价值是真实的：反复解释同一个项目，会把人耗得没有耐心。但“记住得更多”不该是唯一指标。让用户知道什么被记住、在哪里用、什么时候消失，才有可能把连续体验做成能长期使用的服务。
本文依据
本文仅依据《2026年9月25日三篇日报》中的AI技术每日分析扩写。Private AI Compute与Antigravity SDK的产品信息及演示数字沿用原稿；具体路由、密钥生命周期与测试清单属于技术设计建议，不代表相关产品已实现全部机制。