手机端与服务器端 Agent：技术、体验与未来
作者 Clifford · 产品研究
本文由 Memex 团队撰写。平台文档与 Memex 源码已于 2026 年 10 月 17 日核对。这是架构讨论，未进行耗电、速度或后台可靠性对照测试。文中的混合架构设想不是 Memex 已发布的功能。
散步后，你录下一句话：“春天可以去京都，但我不想再过一次行程排得满满的假期。”此刻，你只是想留下这个念头，或把它和之前的记录联系起来。几个月后，你才可能需要 Agent 查日期、找旅行方案。记录的价值，比任务出现得更早。
这两种交流可以发生在同一个聊天窗口里。一种贴近你正在经历的生活，另一种可能需要在你放下手机后继续。Agent 在哪里执行，会改变这段时间里能发生什么，也会改变工作停下时，应用需要向你交代什么。
三个位置，三项独立的决定
Agent 的协调程序读取输入、询问模型、调用工具，再保存结果。协调程序可以在手机应用里运行，同时向模型服务商请求推理。记录存储又是第三个位置：日记留在手机上，并不能说明模型在哪里运行。工具操作也有自己的执行边界：手机上的协调程序既可以修改本地文件，也可以调用远端日历 API。
“本地模型”也需要说明是哪台设备上的本地。如果笔记本上的 Ollama 服务实际运行所选本地模型，推理才发生在笔记本上；手机连上该端点本身，既不能证明推理在手机内完成，也不能排除云端转发。下面比较的是协调程序及其工具的执行位置，不假定三层必须一起移动。
| 设计决定 | 手机端协调程序 | 服务器端协调程序 |
|---|---|---|
| Agent 循环 | 在应用的执行环境中运行。 | 在远端工作程序或服务中运行。 |
| 记录 | 可以使用应用本地记录库。 | 需要授权访问相关记录，或接收提供的副本。 |
| 模型推理 | 可以使用设备端模型或远端接口。 | 可以使用主机上的模型或独立接口。 |
| 手机应用关闭后 | 取决于系统运行时间与恢复机制。 | 如果主机与任务系统可用，可以独立继续。 |
| 工具与权限 | 受应用权限和操作系统约束。 | 受主机工具、凭据及明确的设备连接约束。 |
后台执行需要遵守平台的规则
在 iOS 上，应用不能把任意循环变成永久服务，后台运行时间由系统管理。iOS 和 iPadOS 26 增加了 BGContinuedProcessingTask，让用户明确发起的工作在进入后台后继续，配有可见进度、取消和到期处理机制。它扩大了应用能完成的工作范围，却没有赋予任意无人值守任务随时启动的权利。
Android 区分普通异步工作、持久任务和前台服务。WorkManager 用于持久任务，前台服务则有可见性和启动限制。一些服务类型还有随系统版本、目标版本而变化的时间额度。只把函数写成 async，并不会获得这些执行权限。
服务器让协调程序不再直接受手机应用生命周期支配。但它仍需要可用的主机、调度器或队列、有效凭据、故障处理和监控。托管云服务与家中持续开机的电脑都可以承担这个角色，只是运维责任不同。
任务被保存，不等于操作能精确续跑
假设一个工具创建了日历事项。事项已经创建成功，响应却在 Agent 记下成功之前丢失了。重试工具，可能再创建一个相同事项。把协调程序搬到服务器，并不会消除这种不确定性。
可靠恢复既需要持久任务状态，也需要处理状态之外的实际操作。如果目标 API 支持，稳定的操作标识能让它识别同一次请求的重试；否则，Agent 可能需要先核实究竟发生了什么，再决定是否操作。AWS 关于幂等 API 的文章解释了调用方提供请求标识的重要性。
队列可以记住一个任务尚未完成，但处理这个任务的程序仍可能从头执行。若要从每次模型调用或工具步骤继续，就需要额外状态和针对工具的保证。“中断后能恢复”，不能悄悄变成“每个操作都只发生一次”。
技术差异会出现在屏幕上
做一次简短回顾时，手机端协调程序可以读取选中的本地记录，趁你还记得当时的想法继续追问。它也不能自动查看其他所有应用，访问仍受权限和可用接口约束。如果最新记录从未同步，服务器 Agent 就需要一个明确的通道才能获得同样的上下文。服务器可以配备浏览器和命令行工具，但这些工具不会赋予它访问手机独有内容的权限。
等到后来真的要研究旅行方案，远端执行可以支持“做好后我再回来”。结果可以等手机重新联网后再送达。但应用仍应给出有意义的状态：正在调查、等待网络、已暂停、失败，或需要你回答。执行已经停止，屏幕上的加载图标却还在转，会把任务最重要的事实藏起来。
协调程序在本地，并不保证回答更快。如果两种方案调用同一个远端模型，推理与网络延迟可能占据大部分等待。设备端推理则把计算移到手机，受到具体设备的内存、能耗和散热限制。同样，离线保存记录与离线完成一个依赖远端模型的流程，是两种能力。
隐私与成本取决于工作走过的路径
手机端协调程序可以选取少量相关段落，而不必先把整个记录库复制到执行服务器。但这些段落仍可能随着模型请求离开设备。服务器也可以采用严格的权限范围和有限保留时间。评估两种设计，都应该追踪记录、提示词、工具输出、日志和备份的去向，而不只看循环跑在哪台机器上。
模型选择是另一项决定。选择接口，就是选择一种处理边界，并不意味着每个服务商都私密或支持离线。增加工作服务器可能带来计算和维护成本；手机执行消耗设备资源，也仍可能产生 API 费用。没有明确工作负载与实测数据，无法给出普遍成立的“更便宜”或“更高效”。
Memex 源码能支持哪些判断
本次查看的源码版本中，Memex 有持久的本地任务队列，包含任务状态、执行所有权、停滞任务恢复和可配置重试。后台协调程序把任务活动与应用生命周期连接起来。Android 有通过 WorkManager 处理队列的路径；iOS 桥接层包含后台处理任务，以及带进度和到期处理的 iOS 26 继续处理路径。
后台工作程序也会记录暂停状态，并可安排再次尝试。这些机制用来管理中断，不能证明程序始终运行、每个内部步骤都精确续跑，或所有外部操作都不会重复。源码检查不等于安装到设备后的测试，具体发行版本是否支持，也需要单独核对。
开源让这些边界可以被检查，也给开发者留下修改空间。Memex 的起点是个人记录，以及贴近这些记录的可配置工作流。偶尔出现的个人需求，不必全部变成一个永久运行的服务器任务。
一种未来协作方式：交出任务，留下历史
未来的设计可以把原始记录留在手机，把范围明确的调查交给另一台主机。以旅行请求为例，手机可以发送选定的日期、预算和相关偏好，服务器返回附有来源的候选方案，而不需要长期保存每一篇日记。
交接需要任务标识、输入快照、允许的工具、费用上限，以及下一步由谁负责。假设任务执行期间，你把“安静的旅行”改成了“和朋友一起旅行”，返回的清单应该说明它使用的是之前的偏好，并让你决定是否修改，而不是默默覆盖新的计划。
取消也要区分停止后续调查与撤销已经发生的操作。返回的草稿可以审阅；真正预订则需要独立的批准边界和识别重复请求的方式。这些是设计设想，不是 Memex 已发布的手机到服务器委派功能。更好的设备端模型不会取消系统生命周期规则，更多服务器算力也不会自动补齐缺失的个人上下文。
先想想，你希望留下什么
一段语音记录，即使没有后续长任务，也应该值得保存。对许多日常时刻，有用的交流就是记录、一小段对话，以及以后还能回看的内容。让这条路径贴近手机，符合这些材料本来抵达的方式。
散步几个月后，旅行调查需要的起点已经在那里：你当时希望什么，用自己的话写下，带着日期和后来的修改。运行时间更长的工作程序可以接手偶尔的调查，而日常记录给了它值得据以工作的材料。