记录留在本地，AI 请求去了哪里？
作者 Clifford · 产品研究
本文由 Memex 团队撰写。Memex 客户端源码和 Ollama 文档已于 2026 年 10 月 19 日核对。这是基于源码的解释，未进行网络抓包、服务端审计或特定商店版本验证。
假设你在晚餐后记下一段话，附上一张收据照片。Memex 的记录库保存在本地工作区。启用的工作流请模型整理这顿晚餐时，应用还会向配置的接口提交请求。
请求里的内容可能比这一条记录更多。之前的对话、记住的偏好、工具读到的其他记录，都可能影响发送内容。追踪这些新增材料，比只问日记是“本地”还是“云端”更有用。
先看路径，再看模型名称
本次检查的 Memex 客户端通过模型配置选择客户端类型、模型，以及相应类型支持的基础接口地址。不同 Agent 可以解析各自的模型配置，或使用默认配置。一个熟悉的模型名称，不能说明从手机到推理之间涉及的所有机构。
下面画的是模型请求路径，并非应用或操作系统全部连接的清单。也要核对启用的工作流何时开始调用模型：记录输入与 AI 处理可能属于同一次交流。响应沿配置的服务连接返回，但记录库与请求各有自己的生命周期。
直接连接服务商
- 手机应用
- 所选服务商 API
服务商收到组装后的请求。这假定配置的端点确实属于该服务商，且没有额外模型网关。
模型服务或网关
- 手机应用
- 配置的模型服务
- 若有转发：上游模型
服务端点收到请求。下游提供方及处理方式，需要另查该服务的说明。
另一台设备上的模型
- 手机应用
- 你的电脑端点
- 按配置进行本地推理
数据离开手机。应核对电脑确实在本地运行模型，而非把请求转给云端模型。
服务商收到的内容，可能多于你刚输入的文字
模型接收的是应用组装的请求。里面可能包含指令、对话历史、相关记录、附件和先前工具返回的结果。在 Memex 的 SuperAgent 源码中，用户记忆会作为上下文加入 Agent 状态，Agent 也具备回查记录和读取文件的工具。
这不等于每次都上传整个记录库。它意味着“我只选了一条记录”描述的是你的动作，不能证明整次运行被强制限制在这条记录内。模型选择工具之前，就可能已经有记忆上下文；之后的工具结果还会增加材料。实际请求取决于这次运行的状态与操作。
| 材料 | 如何进入工作流 | 核对什么 |
|---|---|---|
| 当前记录 | 作为任务文字加入。 | 准备发送的原话，以及其中的人名、日期。 |
| 记忆与历史 | 作为补充上下文或先前对话加入。 | 新消息不一定意味着空白上下文。 |
| 照片或音频 | 作为所选模型路径支持的媒体附件加入。 | 远端处理的是媒体字节、提取的文字，还是两者。 |
| 工具结果 | 来自检索记录或上一步的输出。 | 后续请求可能含有首次请求中没有的信息。 |
直接连接与模型服务，是两种选择
直接连接时，请求发往该客户端配置的服务商接口。如果改用兼容网关，即使模型名称没变，接收方也变成了网关。自带 API key 不能证明正在使用哪条路径，还需要查看实际生效的接口地址。
Memex 也有可选的 Memex AI 服务配置。客户端从账号服务取得接口地址和凭据，再据此保存模型配置。因此，接收请求的模型服务端点也属于处理边界。仅凭客户端代码，无法证明它的上游路由、提示词保留时间或训练政策。
不要把它与配置中的可选网络代理字段混为一谈。传输代理和应用层模型网关承担不同角色。只看到“代理”二字，不能判断中间方是否能看到解密后的提示词。
Ollama 地址不能证明推理只在手机上完成
手机连接笔记本上的 Ollama 时，是笔记本收到请求。只有服务实际运行所选本地模型时，推理才在笔记本上进行，而日记可以留在手机。接口必须能被手机访问；手机上的 localhost 指向手机本身，不是身旁那台电脑。
Ollama 文档同时介绍了本地和云端模型，包括通过本地服务使用云端模型。在把路径称为本地推理之前，应核对实际模型及服务器配置。文档也提供了关闭云端功能的方法。下载模型文件又是另一项网络操作，与发送日记内容做推理不同。
本地转写之后，文字仍可能发往远端
语音很适合说明这个问题，因为同一段录音可以经过不同步骤。核对的 Memex 实现有本地语音识别和云端转写两条路径。本地路径使用下载到设备的模型；云端路径会编码音频，连同转写指令一起提交给聊天 Agent 所配置的模型。
如果识别在设备上完成，这个转写步骤不需要把录音发给云端模型。但转写文本之后仍可能交给使用远端模型的 Agent。要分别核对转写和后续分析。选了一个纯文本模型，也不等于所有媒体功能都能正常使用。
工具、日志与备份也各有去向
读取本地记录，与把该记录发回模型，是两个操作。如果启用的工作流带有远端工具，工具输入就多了一个接收方；更换主要模型，不会自动改变工具的目的地址。应检查实际工具，不能假定所有工作都走聊天接口。
核对的源码还会写入本地诊断日志，也能把工作区数据、数据库和设置打包进备份。备份的范围比导出一条记录更大。诊断包和备份文件都应视为可能包含敏感内容，在分享或存入其他服务之前检查其中的内容。
服务商处理、内容保留与用于训练，是分别需要回答的问题。本次检查的源码不能替其他运营方证明服务端做法。删除一条本地记录，也不会自动撤回已经发送的请求、清除备份，或一定移除记忆上下文。每份副本都需要自己的生命周期与删除机制。
先用虚构记录追踪一次
使用虚构内容，例如“周二在示例咖啡馆吃了晚餐”，不要附真实收据。记下要使用的功能、负责工作的一个或多个 Agent、实际模型连接、接口运营方及中间服务，再列出可能的载荷：文字、历史、记忆、媒体和工具结果。
如果包含语音，单独核对转写设置。如果希望本地推理，要确认接收请求的主机和它运行的模型。新开一段对话可以简化检查，但不能据此证明没有记忆与检索。
这份笔记也应允许留下未知项：服务当前的保留条款、尚未识别的下游提供方，或尚未检查的附件路径。它是路径清单，不是网络抓包。要确定完整载荷，需要在受控条件下检查请求组装或流量，只用虚构数据并保护凭据。本文未执行这样的设备端追踪。
测试用的请求路径笔记
功能与负责的 Agent：
实际模型与接口运营方：
模型网关或网络代理（如有）：
包含的文字／历史／记忆／媒体：
本地还是云端转写：
其他工具的目的地址：
生成的备份或日志：
尚未核实的项目：留下记录，选择要交给 AI 的工作
开源让你能检查请求如何组装；可选模型让你能选择处理连接。实际价值是路径可以被检查和调整。这两个标签，都不能替代核对当前生效的配置和即将使用的功能。尝试另一个配置好的接口，不需要把原始记录库搬到该服务。
即使今天不再分析，晚餐记录也仍有保存价值。以后，一个小问题也许值得把一些上下文交给信任的模型。把保存记录与开展分析分别考虑，才能同时容纳个人记录库和有用的 AI。