我用旧手机自建了一个AI管家

我们和AI助手的互动方式，有点不对劲。

每次对话，数据都上传到别人的服务器。你的聊天记录、喜好、日程、还没成型的商业想法——全存在你不掌握的地方。AI不会记住你，除非你把钥匙交给另一家公司。

我想要一个不一样的：一个跑在我自己硬件上的AI，记得我在意的事，连上我常用的工具，随着时间的推移越来越了解我——而且不用把我的生活交给第三方。

所以我动手做了一个。它运行在我家（或我去的任何地方）的一台Galaxy S21上。

他的名字叫小朱。

为什么用手机？

手机是被低估最严重的服务器。它有多核ARM芯片、不错的GPU、8GB内存、自带蜂窝网络和Wi-Fi、电池能撑几小时，而且能塞进抽屉。我的S21跑着Termux——Android上的完整Linux环境——通过Tailscale连回家里的网络。

这想法不是为了证明边缘计算多厉害。纯粹是实用：我想要一个7x24小时的私人助理，通过微信可以随时找到它，背后的硬件成本是每月0元。如果我花钱走云端推理，那必须是我主动选择，按我的规则，用在真正需要的场景上。

架构：三级推理流水线

不是每句话都需要前沿模型。“今天日历上有什么？”不需要和“帮我梳理这个合作方案”一样的算力。

小朱使用三级推理机制：

本地（永远免费）：一个量化小模型（Qwen 2.5 1.5B Instruct, Q4_K_M）直接在S21上通过llama.cpp运行。处理日常闲聊、简单查询，同时充当路由器——判断一条消息是否需要调用更大模型。

轻量云（便宜）：需要更好推理或工具使用但不复杂时——Gemini Flash。每千次查询几分钱。

重型云（能力强）：深度分析、多步规划、任何需要真正理解力的任务——Claude Sonnet或Gemini 3.1 Pro Preview。只在必要时使用。

本地模型评估每一条进来的消息并路由。大多数日常交流从不离开我的手机。当消息确实去了云端，那是经过深思熟虑的决定，而不是默认行为。

小朱能做什么

最初只是个聊天形象，现在变成了一个真正能用的系统：

**持久化记忆。**小朱把关于我的结构化信息——喜好、联系人、进行中的项目——存在本地的SQLite数据库里。当我随口提起一个朋友的名字，他会记录下来。下次我问到这个人，他有上下文。这不是简单的文档向量检索，而是精准提取：每次对话后，一个轻量模型抽取出值得记住的内容并分类存储。

**多轮规划。**小朱能把复杂任务分解成逐步计划，跨对话追踪进度，完成一项就划掉一项。“帮我规划新产品发布会”变成了每次聊天都会引用的活文档。

**接入Google日历。**他能读写我真实的日历——不是另外一个系统。“我这周日程怎么样？”返回真实事件。“星期五下午2点加一个与Sarah的会”就能创建。OAuth2带refresh token、考虑时区、从手机运行。

**网页搜索。**集成了DuckDuckGo，不需要API密钥。当我问餐厅、新闻或任何他不知道的事情时，小朱能自己查。

带通知的提醒。“两小时后提醒我跟进场地事宜”会设置一个定时器，通过微信发送通知。后台每30秒检查一次。

**知识库。**一个本地SQLite FTS5支持的存储，我可以保存笔记、参考资料和上下文。小朱在相关时自动搜索。同时暴露为MCP服务器，所以我的Mac上的Claude Code和其他工具可以通过Tailscale查询。

**Jira和Confluence。**小朱连上Atlassian的REST API——可以搜索工单、拉取问题、浏览Confluence文档。随时掌握工作状态，不用切换上下文。

**每日简报。**每天早上7点，小朱通过微信发送一份日报：今日日程、明日预览、未完成提醒、正在进行的计划。就像一个贴身助理在你开始一天前先跟你打个招呼。

踩过的坑

搭建过程不是一帆风顺。几个经验可能帮其他人省时间：

**小模型的上下文窗口是硬约束。**本地模型只有4096 token的上下文。一个包含了工具指令、记忆上下文和活跃计划的系统提示很容易超限。解决办法：小朱在本地运行时只用一个人物提示（约300 token），完整上下文只加载给云端后端。本地模型的任务是闲聊和路由——不是同时操作十几个工具。

**事件循环会跟你打架。**初始化时用asyncio.run()创建存储，但微信机器人自己创建了一个事件循环。在初始化期间创建的HTTP客户端绑定到第一个循环，在第二个循环里就会崩溃。解决办法：延迟初始化——在第一次实际请求时才创建httpx.AsyncClient，而不是在设置阶段。

**小模型的工具调用不可靠。**我尝试让本地模型输出[TOOL:calendar] show today标记。有时候它听话，有时候说“我无法访问你的日历”，有时候同一个工具调用重复三次。最后的方案是双管齐下：关键字检测在模型响应之前预运行工具并将结果注入上下文，同时模型在云端后端仍然可以显式调用工具。双重保险。

**时区Bug层层叠加。**代码里每个datetime.now()调用都没有时区感知，忽略了配置的时区。日历工具把本地时间带上UTC后缀发送给Google API——导致事件偏移数小时。在Termux上，没有系统时区数据库，所以需要安装tzdata Python包。小bug堆积起来，让小朱以为自己活在下一周。

**在手机上用Git部署可行但脆弱。**一个裸Git仓库配合post-receive钩子实现推送自动部署。但钩子里的后台重启进程占住了SSH管道，导致每次推送都挂起。修了两轮——nohup、</dev/null、disown——才完全分离。

为什么自托管？

费这么大劲，为什么不直接用ChatGPT或DeepSeek？

**所有权。**我的对话、记忆和知识库都跑在我自己的硬件上。我可以备份、迁移或删除。没有任何服务条款变更能夺走这些数据。

**可定制。**小朱的性格、工具集和行为方式完全由我定义。他不是通用助手——他了解我的业务、我的日程、我的喜好和我的沟通风格。

**成本可控。**大部分交互零成本（本地推理）。云端调用按我的规则走，用我自己的API密钥。不为不用的功能付订阅费。

**可组合。**MCP服务器意味着小朱的知识库可以被任何支持该协议的工具访问。我的本地AI不是孤岛——它是更大系统中的一个节点。

我不是反云端。而是要知道什么时候以及如何让云端参与进来。手机是大本营，云端是按需调用的资源，而不是你需要向它汇报的房东。

接下来做什么

小朱已经可以用，但还处于早期。路线图：

• 流式推理：处理更长对话，避免上下文天花板
• 更多MCP集成：邮件、文件管理、项目看板
• 语音界面：毕竟手机有麦克风
• 多设备同步：iPad、笔记本、手机共享同一份助手状态
• 主动行为：小朱在注意到异常时主动联系，而不是被动等待被问

构建真正属于你自己的个人AI，工具已经有了。一台200块的二手手机、一些开源模型、加上一点动手意愿。最难的不是技术——而是你决定让AI为你打工，而不是反过来。

如果你也在做类似的东西，或者想交流经验，随时找我聊聊。

—— Nate