把 OS 做成 Agent：一台没有应用网格的原型手机

在 Reddit 上，一位开发者展示了自己做了几个月的原型手机项目 Nagi，并抛出一个相当直接的问题：这样一台手机，你真的会带在身上吗？

产品构想：主屏不是应用网格，而是 Agent

Nagi 的核心设定很激进——它没有一整屏应用图标。你点亮屏幕看到的，是一个正在替你干活的 Agent：它在处理什么、已经完成了什么、哪些事情需要你拍板。交互方式回到最原始的"说"或"打字"，剩下的交给它执行。

这个思路和当前主流的"AI 助手塞进系统"有本质区别。大多数厂商的做法是在既有应用生态上加一层语音入口，主屏逻辑不变。Nagi 反过来，把 Agent 放在前台，把 Android 应用降级为可调用但不再占据入口位置的底层能力。

开发者强调想要的是真实反馈而非点赞，这说明项目本身仍处于早期验证阶段，UI 和交互都还带有明显的原型痕迹。

技术拆解：本地模型、模型无关与 MCP 优先

Nagi 在技术实现上有几个值得关注的取舍。

本地 LLM 承担意图、记忆与上下文。 开发者的说法是，除非你主动接入云端模型，否则上下文数据不会离开手机。这在隐私敏感场景下是个卖点，但也意味着设备端要承担推理负载，对硬件有一定要求。

模型无关设计。 用户可以接入 OpenAI、Anthropic，也可以跑本地模型，或者直接用默认配置。这种开放姿态降低了用户被单一供应商锁定的顾虑，但也带来体验一致性的挑战——不同模型的指令遵循能力差异会直接反映在 Agent 的表现上。

执行路径：MCP / API 优先，驱动原生应用是兜底。 开发者坦承，直接操控常规 Android 应用这条路径"比较粗糙"。这其实点出了整个品类共同的难题：当目标服务没有提供 API 或 MCP 接口时，Agent 只能靠模拟点击去操作界面，稳定性和效率都会明显下降。

MCP（Model Context Protocol）是 Anthropic 于 2024 年底开源的一项协议，目标是给大语言模型与外部工具、数据源之间建立一套标准化的通信接口。在没有 MCP 之前，每个 AI 应用要接入一个外部服务（比如日历、地图或邮件），通常需要为该服务单独写一套适配代码；服务一多，适配成本就呈线性增长。MCP 的思路类似 USB-C：模型侧只需实现一次客户端，工具侧只需暴露一个标准服务器，双方即可互操作。对 Nagi 这类 Agent 手机而言，MCP 优先意味着当目标服务提供 MCP 接口时，Agent 可以走一条语义清晰、结构化程度高的调用通道，成功率和可控性都远高于模拟点击。

不过 MCP 目前的生态覆盖仍然有限，大量主流消费级应用尚未提供官方 MCP 服务器，这也是 Nagi 不得不保留“驱动原生应用”这条兜底路径的根本原因。协议标准化解决的是“怎么调”的问题，而“有没有得调”仍取决于服务方的接入意愿。

模型无关（Model-agnostic）指的是系统架构不绑定任何特定的大模型供应商，用户可以自由切换 OpenAI、Anthropic、本地开源模型或其他后端。这种做法在当前 AI 产品中越来越常见，主要动机有三：一是规避供应商锁定，避免某家涨价、限流或变更 API 时产品被迫跟着调整；二是让用户按隐私和成本偏好选择，敏感数据可以只走本地推理；三是便于持续跟进模型迭代，新模型发布后可以快速接入而不必重构。

代价则在于体验一致性。不同模型在指令遵循、工具调用格式、上下文窗口和多步推理能力上差异明显，同一个 Agent 流程在强模型上可能一次跑通，在弱模型上则反复失败。因此模型无关的产品通常需要额外做一层能力探测与降级策略，这也解释了为什么 Nagi 把“默认配置”作为选项之一——它为不愿意折腾的用户提供一个经过调优的基线。

交互设计：一个物理按键和可复用的"Experiences"

Nagi 在硬件上只保留了一个实体按键：按住说话，轻点记一条笔记。这个设计把输入方式压缩到极简，和"主屏即 Agent"的理念一致。

更有意思的是 Experiences 这个概念——它是可复用的多步骤流程，比如"叫车回家""规划一次旅行""清理收件箱并起草回复"。用户不需要构建器、不需要写代码，只要用自然语言描述一遍，就能生成一个新的流程。

这相当于把"自动化脚本"的门槛降到零，同时对普通用户屏蔽了工作流编排的复杂度。不过从描述看，Experiences 的质量很大程度上取决于底层模型的理解能力和 MCP 接口的覆盖范围。

设备端运行本地 LLM 并非把云端模型原样搬进手机，而是通常采用 1B 到 8B 参数级别的小模型，并经过量化压缩（如 4-bit 量化）以降低内存占用和功耗。当前主流旗舰手机的运行内存普遍在 12GB 以上，勉强可以承载中小尺寸模型的推理，但会挤占其他应用的内存空间，且持续推理带来的发热和耗电仍是明显瓶颈。

另一条常见路径是手机厂商与芯片方合作，利用 NPU 加速推理，把模型常驻在专用硬件上。无论哪种方案，本地模型能力都明显弱于云端大模型，因此实际产品往往采取混合策略：意图识别、记忆检索等轻量任务放在本地，复杂推理再按需调用云端。Nagi 声称“除非主动接入云端，上下文不离开手机”，在工程上意味着它把整套 Agent 循环都压在设备端完成，这对硬件的要求比一般“本地唤醒词识别”要高出一个量级。

现实约束：应用生态与用户习惯的双重阻力

Nagi 保留了对常规 Android 应用的兼容——它们仍可安装、仍能正常使用，只是不再占据首页。这个妥协很务实，但问题也随之而来：当用户需要主动打开某个应用时，他该怎么找？原帖没有展开说明导航细节。

另一个现实问题是习惯。过去十几年的智能手机训练用户形成了"找图标—打开应用"的条件反射，改变这一路径需要的不仅是技术能力，还有足够强的说服力。开发者把问题抛给社区，本质上也承认这一点尚未解决。

值得关注的方向

Nagi 未必会成为一个量产产品，但它提出的问题很扎实：如果 Agent 真的足够可靠，应用网格是否还有必要占据主屏？这一轮从系统层到交互层的重构尝试，正在被越来越多的团队认真对待。

对开发者而言，Model-agnostic 加 MCP 优先的架构值得参考；对普通用户来说，是否愿意把手机主屏交出去，可能取决于 Agent 到底能把事情办到什么程度。