收藏级

把 Grok Bot 装进手机

开源移动端个人 Agent 全景与架构拆解：原生 node · IM 网关 · PWA · 手机操控

Darren2026-1140 分钟

这篇只收真能上手机的开源方案：原生伴随 App、把 IM 当主入口、可加到主屏幕的 PWA，以及直接操控手机的执行层。纯桌面、纯 CLI、没有移动入口的项目一律不进主文。

方法声明：GitHub 星标来自 REST API 快照 2026-11-04 约 13:20–13:40（北京时间），只代表关注度。架构描述以各项目官方文档与 README 为准；文中凡标「官方未写清」或「本轮未在文档中看到」的，都不做武断断言。主推项目只选有明显流行度背书的；几十 star 的放附录或不作默认推荐。

一、个人 Agent 上手机，到底要什么

对标一条常驻个人助手（例如 Grok Bot 这类系统）在移动场景里真正用得上的能力，可以压成四块：

1. 端侧能力：日历、提醒、通讯录、相机、定位、麦克风，最好还能转发系统通知。没有这些，手机只是一块远程屏幕。
2. 推送：Agent 在家里或云上跑完任务后，要把「请批准」或结果送到锁屏。IM 自带推送、原生 App 走 APNs/FCM、PWA 走 Web Push——三条路成本与能力完全不同。
3. 常驻：控制面不能跟笔记本电源绑死。Gateway 要跑在家里的小主机、VPS，或直接跑在手机本机（Termux / 原生后台服务）。
4. 人审：对外可见的动作——发消息、改日历、跑危险命令——必须有审批落点。手机锁屏上的可操作通知，是天然的审批界面。

缺任何一块，体验都会在路上崩掉：没有端侧能力，你说「下午三点有空吗」它只能瞎猜；没有推送，草稿堆在服务器上等你主动打开 App；没有常驻，合上电脑就断线；没有人审，Agent 要么缩手缩脚，要么在公开渠道闯祸。

也可以用「用户旅程」反过来检验。假设你是独立开发者，中午在外卖队里，忽然想到要发一条产品更新推文：

1. 你用语音对手机说：根据今天的 changelog 起草一条短推，语气克制一点。
2. Agent 在家里的 Gateway 上拉仓库记录、生成草稿，不直接发。
3. 锁屏弹出可操作通知：批准 / 编辑 / 拒绝。
4. 你点批准；若渠道是公开平台，最好还要第二道自动策略闸（敏感词、链接白名单）。
5. 发送结果写回审计；你继续取餐。

这条链路里，IM-only 方案能做 1、2、3（用聊天回复当批准），但做不到「读你手机日历避免和牙医冲突」；PWA 方案连 3 的锁屏可达性都不稳；只有原生 node 或成熟 Companion，才把 3 做成系统级通知。旅程不需要很复杂——复杂的是每一跳的信任边界。

再补一个常被忽略的非功能需求：身份与多设备。人通常有手机 + 电脑 + 有时还有平板。Gateway 必须回答：同一会话是否跨端同步？审批在手机点了，电脑上的卡片会不会还亮着？OpenClaw 文档对「多表面抢答、先提交生效」有明确描述；自建时若没设计，会出现重复执行。

二、四种移动端形态：先选路，再选项目

开源世界里，把个人 Agent 送上手机，大致只有四条路。形态决定你拿得到什么权限，也决定你要付什么运维成本。

选型时还有一个隐藏轴：控制面放哪。

• 放家里 NAS / 小主机：延迟低、数据不出宅，但依赖公网穿透或 Tailscale，停电即停。
• 放 VPS：常驻强，要处理密钥与合规，端侧 node 仍在你手机上。
• 放手机本机（Termux / PicoClaw APK）：出差友好，后台与电量是天敌。
• 混合：Gateway 在 VPS，手机只做 node + IM——这是最接近「笔记本合上也不死」的默认答案。

四种形态乘以四种控制面放置，矩阵很大；下文主推项目会告诉你它们各自的默认答案，避免你在空矩阵上空想。

接下来按形态分类，把真正有声量的项目拆透。

三、OpenClaw 深拆：把手机变成可调用的设备节点

OpenClaw（openclaw/openclaw，393,868★，TypeScript，MIT，调研日仍在 push）是目前开源里**最接近「手机 App 读写日历、提醒、联系人」**的实现。它的移动端不是一个独立聊天壳，而是挂在 Gateway 上的 node。

控制面：Gateway

本地（或家里的小主机 / VPS）常驻一个 Gateway，管 session、工具、事件与渠道。Control UI、CLI、macOS/Windows 桌面端，以及 iPhone / Android 伴随 App，都连到同一套控制面。官方文档写明：同一 Gateway 既能当个人 claw，也能当多人 claw，差别主要在配置。

渠道超过 20 个（WhatsApp、Telegram、Slack、Discord、Signal、iMessage、Teams 等）。陌生人 DM 默认要走 pairing：你在 Gateway 上批准后，对方才能继续聊。这是 inbound 信任边界的第一道闸。

iOS node：权限与能力

官方 iPhone App 已上 App Store（文档要求 iOS / iPadOS 26.2+）。它通过 WebSocket 连 Gateway（同局域网或 Tailscale），并暴露一组可被 node.invoke 调用的能力：屏幕快照、相机拍摄、定位、Talk mode、语音唤醒，以及可选的 Health 摘要。

权限页列出通知、相机、麦克风、语音识别、定位、通讯录、日历、提醒事项、相册——全部走 iOS 原生授权弹窗。聊天支持相册、相机、文件、粘贴和系统分享面板；助手生成的图片通过 Gateway 的短期 artifact URL 内联展示。

配对流程是刻意做成「人审」的：

官方还支持可选的 CIDR 自动批准全新 role: node 配对，但默认关闭；任何角色、scope、公钥变更仍需人工批准。

推送：App Store 版走托管中继，不是把 APNs token 交给你的 Gateway

这一点以前常被说糊。官方文档「Relay-backed push for official builds」写得很清楚：

• 正式 App Store 构建不把原始 APNs token 交给 Gateway。
• App 用 App Attest + StoreKit 交易证明向托管中继 https://ios-push-relay.openclaw.ai 注册，拿到不透明的 relay handle 与 scoped send grant。
• App 再把这份 relay 注册通过 push.apns.register 交给已配对的 Gateway。
• Gateway 发起 push.test、后台唤醒、wake nudge 时，签名请求发给中继；中继持有生产环境 APNs 凭证与原始 token，再打到 APNs。
• 设计目标：生产 APNs 证书不落用户 Gateway、原始 token 不存 Gateway、只有正版 App Store 构建能用托管中继、一个 Gateway 不能给别家配对的设备发唤醒。

本地 / 手动签名构建仍可走直连 APNs，需要你在 Gateway 主机配置 OPENCLAW_APNS_TEAM_ID 等凭证。App 后台被 silent push、Background Refresh 或显著位置变化唤醒后，会短暂重连并上报 node.presence.alive。相关 PR 也写明：对已断开的 iOS node，Gateway 可在 node.invoke 前先发 APNs 静默唤醒，等几秒再重试。

Android node：能力并不「弱于」iOS，路径却不同

Android 官方 App 在 Google Play，也可从部分 GitHub Release 侧载签名 APK。它同样是 companion node，不在手机上托管 Gateway。

与 iOS 的关键差异：

• Android 用前台服务（常驻通知）尽量维持 Gateway 连接；文档强调的是连接保活，而不是像 iOS 那样以 APNs 中继唤醒为主路径。
• 设备命令面更「手机味」：除相机、定位外，文档列出 contacts.search / contacts.add、calendar.events / calendar.add、callLog.search、sms.search、通知列表与动作、步数与活动等——以设备权限与用户设置为前提。
• 通知转发是 Android→Gateway：把系统通知作为 node.event 送进控制面（默认关；需 Notification Listener）。WhatsApp / Telegram / Discord / Signal 等已被 OpenClaw 原生渠道接管的包会排除，避免同一条消息走错会话。
• Wear OS 伴随通过已配对手机中继，手表本身不存 Gateway 凭证。

结论：OpenClaw 的移动端价值不在「又一个聊天 App」，而在 Gateway + node.invoke + pairing +（iOS）中继推送 这条完整设备协议。它是后文参考架构里「端侧工具层」的现成实现。

node.invoke 与人审如何咬合

一次典型的「请帮我明天上午加一个牙医提醒」在 OpenClaw 移动链路上，大致是：

1. 你在 iPhone 聊天里发话，或从另一个 IM 渠道进来，事件进入 Gateway session。
2. Agent harness（可插拔，官方支持对接多种模型与 coding harness）决定调用设备工具，而不是瞎编日程。
3. Gateway 对已配对 node 发 node.invoke。若 iOS 节点在后台断开，官方路径会尝试 APNs 静默唤醒，等待短暂重连后再调。
4. 手机弹出系统级日历/提醒权限（若尚未授予），或在 App 内走审批卡片（exec / 问题类请求）。
5. 写操作成功或失败的结果作为观察返回模型，再生成对你可见的回复。
6. 整个过程的敏感点在：工具跑在谁的信任域。OpenClaw README 原话倾向是：主 session 的工具默认在宿主机执行，除非你配置 sandboxing。移动 node 上的日历写入是「设备本地能力」，与「Gateway 主机上的 shell」是两件不同的风险。

审批界面也不止一种。文档描述了：

• Exec / plugin 审批：操作员连接带 operator.admin 或被显式指定的 operator.approvals 时，可在手机上审查待执行命令；Apple Watch 经 iPhone 中继可给精简的允许一次/拒绝。
• Agent 提问卡片：单选、多选、Other 自由文本、过期倒计时；多端抢答时「先提交的生效」。
• 会话侧栏注意力标记：待回答与待批准会在列表上打标，避免埋在历史里。

这对「发推前先出草稿给人审」一类工作流是直接可复用的交互范式：草稿是一种待批准对象，推送是唤起，卡片是决策，审计是事后。

发现与组网：手机如何找到家里的 Gateway

移动节点不在 localhost。官方推荐三条发现路径：

• Bonjour / mDNS：同局域网浏览 _openclaw-gw._tcp。
• Tailnet + 单播 DNS-SD：跨网络时用 Wide-Area Bonjour（示例域 openclaw.internal.）配合 Tailscale split DNS。
• 手动 host/port：发现被墙或企业网络封锁时的退路；默认端口文档示例为 18789。

远程场景优先 Tailscale Serve 提供 wss:// / https://。Android 文档写明：tailnet/public 的首次配对不接受裸 ws:// 尾网 IP，需要安全端点。明文 ws:// 在非回环上会自动降为 limited operator access，以避免 bearer token 裸奔。多 Gateway 注册表按网关隔离凭证、聊天缓存与离线发件箱；只有当前 focus 的 Gateway 持有带能力的 node session，避免两台控制面同时抢相机。

离线体验也做了产品级细节：只读缓存最近会话；断线时文本进 durable outbox（上限与 48 小时过期在文档中有写）；重连按序刷新且用稳定请求键防重复发送。这些看起来像聊天 App 功能，对常驻助手却是「地铁进出隧道也不丢指令」的基础设施。

四、Hermes Agent 深拆：一个网关接所有聊天软件，必要时跑在手机本机

Hermes Agent（NousResearch/hermes-agent，260,300★，Python，MIT）走的是另一条极端：没有官方原生手机 App，却把「人在路上」这件事解决得相当实用——所有入口都是你已经在用的 IM，推送也免费借 IM；真要在手机上跑 agent 本体，就装 Termux APT 包。

单进程多渠道 Gateway

一个 gateway 进程同时接 Telegram、Discord、Slack、WhatsApp、Signal、Email、Home Assistant，并带语音备忘转写；对话可以跨平台延续。对海外用户，这意味着手机锁屏上的 Telegram / Signal 通知就是 Agent 的触达面。社区还有 HermesClaw 一类微信桥，但那是社区扩展，正式程度因仓库而异，选型时要单独评估维护状态。

人审有两层：命令审批（危险 shell 先问你）与 DM pairing（陌生私信先配对）。这和 OpenClaw 的 inbound pairing 是同一类思想：默认不信任陌生入口。

六种执行后端：控制面与执行面拆开

Hermes 内置六种 terminal backend：local、Docker、SSH、Modal、Daytona、Vercel Sandbox（还可用插件接 Singularity/Apptainer）。Modal / Daytona 一类 serverless 后端的卖点是闲时成本接近零，同时仍能保持可恢复的工作区。

这对移动端场景的意义是：你在地铁上用 Telegram 丢一句「去跑昨晚那份批处理」，真正干活的是云端沙箱，而不是手机 CPU。手机只负责触发、审批与收结果。

Termux：把 Agent 装进安卓口袋

官方为 Android 提供签名的 Termux APT 仓库（aarch64，stable / canary）。Agent 本体可以直接跑在手机上——这在断电的出差旅馆、只有手机热点的临时工位，是「家里 Gateway 不可达」时的备份形态。代价也很清楚：电池、后台杀进程、散热，以及手机上跑 shell 的安全面。

自我改进闭环

Hermes 的差异化不在移动端 UI，而在学习闭环：复杂任务做完后沉淀 skill，skill 在使用中继续改进；记忆靠 SQLite FTS5 + LLM 摘要，用户建模可接 Honcho。技能格式兼容 agentskills.io。对「常驻个人助手」来说，这意味着手机上聊着聊着，家里的 skill 库会变厚——前提是你把同一套状态同步好，而不是 Termux 一份、VPS 一份各玩各的。

和 OpenClaw 的分工怎么理解

可以把两者想成同一张能力表上的不同峰值：

实务上常见叠法是：Hermes（或别的内核）负责重活，OpenClaw node 只当设备工具提供者——前提是你愿意维护两套或做一层工具桥。硬要二选一：先问自己「本周最痛的是读不到日历，还是跑不了隔离 shell」。

轻量 claw 系：nanobot、NanoClaw、PicoClaw

2026 年名字里带 claw 的项目，大多是 OpenClaw 生态的瘦身版或哲学反对票。移动端上，它们几乎都选了 IM 主入口，把推送外包给聊天软件。

nanobot（HKUDS/nanobot，49,807★）

定位「超轻量自托管个人 agent」。入口有 WebUI、终端和聊天 App；渠道覆盖 Telegram、Discord、Slack、微信、飞书、Teams、Email、Mattermost、Linear。能力包括 shell、web search/fetch、MCP、cron、生图、multi-agent delegation、长程目标与 Office 文档阅读。记忆叫 Dream。可对外暴露 Python SDK 与 OpenAI 兼容 API，部署成常驻 gateway。

对移动端：微信 / 飞书 / Telegram 任一在线，你就有推送；端侧日历通讯录仍拿不到。

NanoClaw（nanocoai/nanoclaw，31,077★）

自称 OpenClaw 的「可读懂替代品」：一个进程加少量文件，直接跑在 Anthropic Agents SDK（Claude Code）之上。每个 agent 一个 Linux 容器，只能看见显式挂载目录；凭据走独立 credential gateway，不进容器。聊天里可 spawn 队友，各自 bot 身份、容器与记忆，共享 rooms / canvases——这是开源里最接近「多 agent 团队 + 群聊」的形态之一。

渠道通过 /add-<channel> skill 按需安装（WhatsApp、Telegram、iMessage、微信等），哲学是 skills over features：主干只留注册表。定时任务支持 script gate：先跑脚本判断有没有活，没活就不唤醒模型，省 token。

移动端同样是 IM；价值在隔离模型与团队协作，不在手机权限。

PicoClaw（sipeed/picoclaw，30,091★，Go，MIT）

硬件厂商 Sipeed 出品，Go 单二进制，主打低资源（项目自称可在极低内存与廉价硬件上跑）。支持 MCP（文档称 v0.2.1 起可在 WebUI 管理）、sub-agent、带安全闸的 cron、JSONL memory。

Android 已核实可跑：官方提供 APK（picoclaw.io），也可用 Termux + picoclaw_Linux_arm64.tar.gz + termux-chroot 跑 gateway。文档提醒关闭电池优化、保持前台会话，否则锁屏后进程可能被杀。旧手机「二次就业」当私人 Agent 节点，是这条路线的独特卖点。

（若只要旧安卓机常驻、资源吃紧：看 PicoClaw 的 APK / Termux 路径。）

轻量系共同的移动端诚实边界

三个项目再怎么拆，移动端上仍共享几条边界——写进长文是为了少踩坑：

1. 推送 = IM 推送。IM 挂了、被限流、或你把机器人静音，助手就「消失」。
2. 没有系统通讯录 RPC。要生日提醒，请接日历 SaaS 或另上 OpenClaw node。
3. 安全模型差在执行面，不在手机 UI。NanoClaw 的容器 + 凭据网关、PicoClaw 的 cron gating、nanobot 的 gateway 部署方式，决定的是「家里那台机器被 prompt injection 之后炸多大」，不是聊天气泡好看不好看。
4. stars 不能当架构认证。nanobot 近 5 万星不自动等于微信协议长期稳定；国内 IM 协议变更是运维事件，不是星标事件。

若你的目标是「可读源码的小型个人助手 + 手机 Telegram」，轻量 claw 往往比直接上 OpenClaw 全家桶更幸福——前提是你接受端侧能力为零。

五、国内 IM 路线：微信就是移动端

在国内讨论「移动端个人 Agent」，不先谈 App Store，先谈微信、飞书、钉钉、企微。CowAgent、AstrBot、LangBot 是这条路上的三强。

CowAgent（zhayujie/CowAgent，47,775★）

原 chatgpt-on-wechat。渠道覆盖 Web、微信、飞书、钉钉、企微、QQ、公众号、Telegram、Slack；v2.1.0（2026-06-01）又补了 Telegram、Discord、Slack 与微信客服等。MCP 已支持：官方文档写明可在 ~/cow/mcp.json 或控制台配置 stdio / SSE / streamable HTTP，工具对 LLM 的暴露方式与内置工具一致。

AstrBot（AstrBotDevs/AstrBot，45,880★，AGPL-3.0）

多平台机器人框架，插件与知识库成熟，可接 Dify 等编排。MCP 已支持：WebUI「扩展 → MCP Servers」可配 Streamable HTTP、SSE、stdio；需使用支持 tool calling 的模型与内置 AI 执行模式。

LangBot（langbot-app/LangBot，18,716★，Apache-2.0）

同样定位多平台机器人；MCP 可走 Remote（自动探测 Streamable HTTP / SSE）或 Local stdio（需 Box Runtime）。可从 LangBot Space 一键装预配置 MCP。流水线需启用内置 Agent 且模型打开 tool use；外挂 Dify / n8n / Coze 等 runner 用各自的工具机制。

三者都可把 Dify / n8n / Hermes 当内核、自己当渠道皮。许可要注意：AstrBot 是 AGPL，对要闭源二次分发的团队不友好。

「微信就是移动端」的架构含义

把微信当成手机前端时，系统分层会被迫改写：

1. 身份：微信用户 ≠ 你的 Gateway 用户。要自己做绑定表（openId / 企微 userId ↔ agent subject），否则群里一说话就串会话。
2. 推送：你不再申请 APNs，但要遵守平台消息配额、模板消息 / 客服消息窗口等规则；个人号方案的稳定性与合规风险更高。
3. 富媒体：图片、语音、文件的上传下载链路在 IM SDK 里，Agent 侧要统一成内部 attachment 模型，否则跨 Telegram+微信复用同一记忆时会碎。
4. 人审：IM 里最自然的审批是「回复 批准 / 拒绝」或点按钮（企微卡片、Telegram inline keyboard）。不要假设用户会打开另一个 App。
5. 端侧空洞：下次有人说「让机器人看看我明天有没有空」，在纯 IM 架构里你只能接日历 SaaS API（Google Calendar、飞书日历），读不到手机系统日历——除非另接 node。

这不是贬低国内路线。对大量中国独立开发者，日活本来就在微信里；先把对话与推送跑通，再按需补 OpenClaw / HA，是更现实的里程碑切分。

六、Home Assistant + n8n：事件触发与推送基础设施

个人 Agent 的 routines，不必全自己写。两个开源巨头已经把「事件 → 推送 → 人点一下」做成了成熟产品。

Home Assistant Companion：推送怎么走

home-assistant/core 91,945★；配套 home-assistant/android 4,021★、home-assistant/iOS 2,398★。Companion 把手机传感器（电量、定位、活动、Wi-Fi 等）变成 HA 实体，并支持可操作通知。

开发者文档与 Companion 文档描述的推送模型是：

1. App 注册时提交 push_token + push_url。
2. HA 核心把通知 POST 到你的 push_url（云推送路径）；也可在 App 在线时走 WebSocket 本地推送。
3. 官方 App 的云推送由项目维护的推送服务转发；Android full flavor 经 FCM；Companion 文档说明通知内容会经过该基础设施，并有每设备每日约 500 条的速率限制（以官方说明为准）。
4. 自建 companion 时，你可以自备中继：HA 不绑定某种推送厂商，只负责 POST 到你的 URL。

对 Agent 架构的启示：私有部署的原生 App 几乎总需要一个推送中继——证书在开发者手里，用户 Gateway 不应也不该人人申请一套 APNs。OpenClaw 的 ios-push-relay 与 HA 的 push_url，是同一问题的两种答案。

Hermes 能把 HA 当渠道或工具；于是「门磁打开 → HA 自动化 → 通知手机 → 可选触发 Agent」变成现成管道。

n8n：SaaS 事件与 IM 触发器

n8n-io/n8n 209,502★。它不是个人助手，但是极强的 routines / 连接器层：cron、webhook、Telegram / WhatsApp 等触发器，加上 AI Agent 节点。许可是 Sustainable Use，商用前要读条款。

典型拼法：n8n 监听 GitHub / 日历 / 表格事件 → 调你的 Agent webhook → 结果经 Telegram 回你 → 需要人工时停在 Wait 节点。手机端你只需开着 Telegram。

为什么值得单独成章

很多人把 HA、n8n 排除在「Agent 项目」之外，结果在自建时重复发明：

• 可操作通知（锁屏上点 Allow / Deny）——HA Companion 已经做了多年；
• 地理围栏、Wi-Fi 到家、电量低——事件源现成；
• GitHub issue 创建、表格更新、邮件到达——n8n 节点现成。

Agent 内核擅长的是非结构化意图与工具编排；HA/n8n 擅长的是确定性管道与设备/SaaS 连接。移动端个人助手若只有 LLM loop、没有事件层，routines 要么贵（全靠模型轮询），要么脆（全靠 crontab 盲跑）。

一个可落地的分工：

sequenceDiagram
  participant Phone as 手机 Companion/IM
  participant HA as Home Assistant / n8n
  participant GW as Agent Gateway
  participant Human as 你
  HA->>GW: webhook：事件发生
  GW->>GW: 生成草稿或计划
  GW->>Phone: 推送待批准
  Phone->>Human: 可操作通知
  Human->>Phone: 批准
  Phone->>GW: 审批结果
  GW->>HA: 执行动作 / 写回实体

注意：HA 官方推送有速率限制与隐私说明（通知正文会经推送基础设施；若完全不想经 Google，需评估最小构建与 WebSocket 本地推送）。把这些限制写进你的 SLA，比上线后被 429 打脸便宜。

七、操控手机与聊天前台：执行层和皮

前几章解决的是「人怎么在手机上跟 Agent 说话」。这一章反过来：Agent 怎么替你点手机上的 App。它对应桌面世界的 computer use，只是屏幕更小、厂商限制更严。

Mobile-Agent + GUI-Owl（X-PLUG/MobileAgent，9,357★）

阿里通义开源的移动 GUI Agent。当前公开材料强调 v3.5 搭配 GUI-Owl-1.5 模型族（文档称覆盖 2B 到 235B 量级），并已上架阿里云无影云手机（材料记 2026-03-31），提供百炼 API；另有 OSWorld-MCP 一类基准发布。定位是：看截图 / UI 状态 → 规划多步 → 点击滑动输入。

生产建议是放进云手机隔离，而不是直接授权个人日常机——否则 Agent 点错支付按钮的代价由你本人承担。

Mobilerun（droidrun/mobilerun，9,925★，原 DroidRun）

在真实 Android / iOS 设备上读取 UI 状态、截图理解、点击、滑动、输入、多步规划；通过 CLI 或 Python API 返回结果。另有 Mobilerun Cloud 与 mobile-harness。适合「真机农场」或 CI 里的移动端自动化，也适合接到 Hermes / OpenClaw 工具层，作为 mobile.tap 一类工具。

AppAgent 与附录项

TencentQQGYLab/AppAgent（6,916★）基于 ADB 操控 Android，但 2025-03 之后基本停更，只作历史对照，不作默认推荐。

和「原生 node」别混为一谈

GUI Agent 的评测与演示很性感，但接到个人助手生产路径时，至少加三道闸：只在隔离设备跑、高风险动作二次确认、全程录像或 UI dump 审计。否则「帮我退掉那张机票」会在错误的 App 状态上点下去。

聊天前台对照：PWA、TWA 与端侧推理

若你已经有 Agent 内核，只缺一层「手机上好看的对话框」，下面这些是常见皮。它们大多不是常驻个人 Agent。

Open WebUI / LobeHub / LibreChat

它们强在模型路由、工具 / MCP、知识库与多用户；弱在端侧权限与常驻调度。适合当 Grok Bot 类系统的 Web/PWA 皮，推送仍建议走 IM 或原生中继。

PWA 在 iOS 上还有一条产品陷阱：Web Push 自 iOS 16.4 起才对「已加到主屏幕」的 web app 开放，且权限、送达率、用户教育成本都高于原生。即便某前台某天合并了 Web Push，也不要把「能聊」自动升级成「能当审批通道」。独立开发者更稳的做法是：PWA 负责富文本与工具调试；真正要找你签字的消息，走 Telegram / 微信 / 原生推送三选一。

Khoj（khoj-ai/khoj，37,971★，AGPL）

第二大脑式 RAG + automations（可邮件推送结果）。手机路径核实为：

• 浏览器 PWA（加到主屏幕）；
• Android Trusted Web Activity 包装 app.khoj.dev（bubblewrap 生成，包名 dev.khoj.app，可开通知委托）；
• WhatsApp 经独立项目 Flint（Twilio）接入。

仓库最近 push 在快照里偏早（约 2026-08），活跃度放缓，选型时要看你能否接受维护节奏。

AnythingLLM Mobile（独立仓 183★；主仓 67,907★）

Android 端侧优先：设备上跑 GGUF（llama.cpp）、本地 RAG、语音、部分 agent 工具（含读/写日历等，以官方功能列表为准），并可与 Desktop / 自托管 / Cloud 同步工作区、线程与文档。配对方式：Desktop 打开网络发现后扫 QR；自托管则填服务 URL。自定义 MCP / 工具目前官方建议通过同步到 Desktop/Cloud 使用，而不是在手机单机里完整配置。仅 Android；iOS 官方称计划中、无日期。独立仓 star 很低，但背靠主项目与正式文档，可作「端侧推理 + 伴侣」对照，不作唯一底座。

它特别值得对照的一点是：混合推理拓扑——小模型在手机，大模型在 Desktop/Ollama/云，工具与文档尽量留在端上。这和 OpenClaw「手机当 node、脑子在 Gateway」同构，只是 AnythingLLM Mobile 把「端上也有一个可离线的小脑子」做进了产品。若你的威胁模型是「通勤地铁无信号也要能改稿」，端侧 SLM 有意义；若威胁模型是「对外发帖必须过家里的审批队列」，端侧模型仍只是编辑器，不是放行者。

Eliza（elizaOS/eliza，19,766★）

官网与仓库材料显示：面向 web / desktop / mobile 的用户端 agent，Android 可侧载 APK；iOS App Store / TestFlight 标注 Coming soon。另有更重的 elizaOS / AOSP 路线图，但多为即将发布状态。角色化 agent + Telegram/Discord 等插件是其强项；把「已上架的成熟 iOS 伴侣」当成现状会高估——写进决策时请按侧载 / 即将上架处理。

Eliza 更广的叙事是「agent 操作系统」：桌面安装包已可下，Android APK 可侧载，还有 AOSP / Live ISO 等路线图条目在官网以 Coming soon 列出。对本文范围，我们只取一个保守结论——移动分发尚未与 OpenClaw 的双上架状态同级；若你的硬需求是「同事用 TestFlight/正式商店即装即用」，现阶段仍应把 OpenClaw 或 IM 方案放在默认推荐，把 Eliza 放在观察名单。

八、能力矩阵与通用参考架构

下面矩阵只强调移动端三列；其余能力沿用同日调研的粗粒度判断。符号：✅ 有｜◐ 部分/插件｜✗ 无｜? 文档未写清。

flowchart TB
  subgraph Device["端：手机"]
    UI["聊天 / 语音 / 分享入口"]
    Tools["设备工具：日历·通讯录·相机·定位"]
    Approve["人审弹窗 / 可操作通知"]
  end

  subgraph Control["云或家里的 Gateway"]
    Sess["Session · Agent loop"]
    Mem["记忆 · Skills"]
    Sched["Cron · 事件总线"]
    MCP["MCP / 连接器"]
    Queue["审批队列 · 审计"]
  end

  subgraph Exec["执行环境"]
    Box["Docker / microVM / E2B"]
    CloudPhone["云手机 / Mobilerun"]
  end

  subgraph Push["推送"]
    Relay["APNs/FCM 中继"]
    IM["Telegram / 微信 / Signal"]
  end

  UI <-->|WebSocket / IM| Sess
  Sess -->|node.invoke| Tools
  Sess --> Box
  Sess --> CloudPhone
  Queue --> Relay
  Queue --> IM
  Relay --> Approve
  IM --> UI
  Sched --> Sess
  MCP --> Sess
  Mem --> Sess

分层原则可以背下来：

1. 端：瘦客户端 + 设备节点。敏感写操作在端上确认。
2. Gateway：常驻控制面。手机离线时任务继续跑。
3. 执行环境：与控制面隔离；操作第三方 App 时用云手机。
4. 推送：原生走中继；不做 App 就借 IM；PWA Web Push 当退路且先核实。
5. 人审链路：草稿 → 审批队列 → 推到手机 → 批准/修改 → 执行 → 审计。

参考实现映射（避免架构图悬空）

你不需要一次铺满。最小可运行往往是：一个 Gateway + 一个 IM 渠道 + 人工回复当审批。端侧与中继是第二阶段的增强项。

九、自建怎么选：三套组合与坑点

组合 A：要原生端侧（最接近完整移动个人助手）

OpenClaw Gateway + 官方 iOS/Android node，执行面打开 sandboxing（默认宿主机执行，官方也提醒要自己配隔离），需要操作 App 时外挂 Mobilerun / 云手机；记忆不够再接 Mem0 / Letta。

适合：已经接受「家里有一台常驻机」，并要日历 / 通讯录级能力的人。

组合 B：重执行、海外 IM

Hermes Gateway + Telegram/Signal +（可选）Termux 备份节点，backend 选 Docker / Modal；事件层用 n8n 或 HA。

适合：不需要系统日历 RPC，但需要强沙箱与跨渠道连续对话。

组合 C：主要在国内微信里活着

CowAgent 或 AstrBot 或 LangBot 做渠道皮，内核用 Dify / Hermes / 自研 Agent；推送完全交给微信。若还要端侧，额外配对一台 OpenClaw Android node 或 HA Companion，不要幻想微信插件能读到系统通讯录。

坑点清单（写进 runbook）

1. 推送证书与中继：自建 iOS App 就要 APNs 密钥与中继；直接把生产 token 散落在用户 Gateway 上是安全与合规双重灾难。优先评估「官方中继 / HA 式 push_url / 只借 IM」三条路。
2. IM 风控：个人微信号做机器人、批量 WhatsApp 自动化，都有封号风险。企业微信 / 正式 Bot API 更稳，也更笨。
3. 权限最小化：通讯录与日历是高敏数据。OpenClaw 的 pairing scopes、Android 通知转发白名单、HA 的传感器开关，都要默认关、按需开。
4. 成本：Modal/云手机按秒计费看起来便宜，忘关农场会烧钱；本地 Gateway 则是电费与磁盘。为 cron 加 script gate（NanoClaw 那类）能显著省 token。
5. 后台保活：Android 厂商杀后台；Termux / 前台服务 / 关闭电池优化是运维常识，不是可选优化。
6. 许可：AstrBot AGPL、n8n Sustainable Use、部分聊天前台许可证需法务过目——star 再高也过不了采购。

三套组合的「第一周」清单

组合 A 第一周：家里或 VPS 装好 Gateway → Tailscale Serve → 手机装官方 App 完成 pairing → 只打开日历与通知权限做一次 push.test → 配置 sandboxing → 用一条「创建提醒」闭环验证 node.invoke。先不要接 20 个 IM。

组合 B 第一周：Hermes 起 gateway → 只接 Telegram → backend 用 Docker → 写一条自然语言 cron 投递到 Telegram → 打开命令审批 → 可选再装 Termux 包当旅行备份（与主 Gateway 的状态同步策略先写下来）。

组合 C 第一周：选 Cow 或 AstrBot 或 LangBot 之一 → 先跑通一个企业级渠道（优先企微/飞书机器人，而不是个人微信）→ 配一个 MCP（例如 fetch）验证工具链 → 人审用「回复关键字批准」→ 若需要日历，接飞书日历 API，而不是幻想系统日历。

三周以后再谈 Mobile-Agent 云手机。过早引入 GUI 操控，会把调试面放大十倍。

从「能聊」到「能办事」的验收清单

交付给自己或交付给团队时，不要用「手机打开了对话框」当验收。用下面清单打勾，缺哪条补哪条：

1. 合上笔记本 / 关掉电脑桌面客户端后，定时任务是否仍会跑？
2. 任务完成后，是否能在锁屏或 IM 里收到通知，而无需你主动打开网页？
3. 一条对外发送是否必须经过明确批准，且批准有审计记录？
4. Agent 能否在授权下读取或写入至少一个真实端侧数据源（系统日历、企微日历或 Google Calendar）？
5. 危险 shell / 支付相关 GUI 动作是否默认拒绝或二次确认？
6. 凭证是否不出现在聊天日志与沙箱文件系统里？
7. 通知转发或 IM inbound 是否按不可信输入处理？
8. 出差只带手机时，是否有 Termux / 云 Gateway / IM 三选一的降级路径？

八条里若只满足 1–2，你拥有的是聊天前端；满足 1–3，开始像助手；满足 1–6，才接近本文标题说的「装进手机」；7–8 是上线后还能睡安稳觉的运维成熟度。

对照主推项目：OpenClaw 在 2、3、4 上最完整；Hermes 在 1、3、5、8 上很强；国内 IM 三强天然满足 2（在微信里），但 4 要靠外接日历 API；HA 把 2 做到极致却不是通用 LLM Agent。组合拳存在的理由，正是没有任何单项目在八条上同时满分。把清单存进你的仓库 README，比存一份星标截图有用：星标会过期，验收项会逼你诚实。若八条暂时做不到，也请写明「已知缺口」——例如「推送仅 Telegram、无系统日历」——避免三个月后的自己被 Demo 记忆骗到。公开分享架构时同样如此：先讲清缺口，再讲星标，读者才信得过你的推荐。这篇也按同一标准写：能核实的写死，核实不了的降级或删除，不拿估计数充场面。

一条「人在路上批准」的端到端故事

把前面散落的零件串成一条故事，方便你对照自己的系统缺哪一跳。

场景：你在地铁上。家里的 Agent 监控到竞品发了一篇长文，按你的 skill 起草了一条评论型短推，等待发送。

1. 事件层：n8n 或自建爬虫 webhook 打到 Gateway：「竞品 URL + 摘要」。
2. Agent loop：Gateway 拉 skill「评论语气」、检索你过去的表述偏好（记忆层），生成草稿；发送工具被策略标记为需批准。
3. 审批入队：队列写下草稿全文、目标渠道、过期时间、风险标签。
4. 推送：
   • 若走 OpenClaw iOS：Gateway → ios-push-relay → APNs → 锁屏通知，点开是批准卡片；
   • 若走 Hermes+Telegram：Bot 发来带 inline button 的消息；
   • 若走 HA：notify.mobile_app_* 带 action；
   • 若只有 PWA：此刻你大概率收不到——这就是前文反复泼冷水的原因。
5. 人审：你在颠簸车厢里扫一眼，点「批准」或「改语气更短」。修改应写回队列，而不是只存在手机本地。
6. 执行：Gateway 调用发送工具；失败则回推原因；成功则写审计（谁批准、何时、哪个设备）。
7. 端侧可选增强：若 skill 要求「避开我日历上的深工时段再发」，OpenClaw node 读日历；纯 IM 方案则读 Google Calendar MCP。

这条故事里，没有一步依赖「手机很聪明」。手机要聪明的是权限与触达；聪明的推理在 Gateway。把这个顺序反了——试图在手机上塞满大模型、却没有审批队列——是 2025–2026 很多「手机 Agent」Demo 好看、上线即崩的原因。

AnythingLLM Mobile 证明端侧推理有价值（离线、隐私、低延迟），但它解决的是「口袋里的对话与 RAG」，与「常驻 Gateway + 人审发送」是互补关系，不是替代关系。能同步 Desktop 工作区很好；若你的对外动作仍在云端 Agent 上，手机端侧模型不必也不该拥有生产渠道的裸凭证。

安全基线（移动场景特别易漏）

1. Inbound 一律不可信：所有 IM 文本、通知转发内容、分享进来的文件，都当 prompt injection 入口。OpenClaw / Hermes 的 pairing 是起跑线，不是终点。
2. 凭证不进沙箱、不进聊天记录：NanoClaw 的 credential gateway、各项目的密钥文件权限，比「用了 GPT-4o」更决定你会不会明天刷屏泄露。
3. 通知转发白名单：Android 把通知送进 Agent 很爽，也会把验证码、银行卡短信送进模型上下文。默认关，精确开。
4. 云手机与日常手机物理隔离：GUI Agent 的登录态、支付方式、二次验证，不要与你的主力机混用。
5. 审计可导出：出了事你要能回答「哪一次批准导致了发送」。只有聊天泡泡没有审计表，等于没有人审。

满足这五条，不保证不被黑；不满足这五条，星标再高也只是把攻击面装进了口袋。

附录：本轮刻意降权或未主推的项目

• AppAgent（6.9k★）：停更，仅作 GUI Agent 史。
• anythingllm-mobile 独立仓（183★）：功能看主项目文档；流行度背书弱，作伴侣对照。
• Jan（45.4k★）：本轮 README 未确认移动端，不进主文。
• Leon、Agent Zero：移动端形态未在本轮核到可主推证据。
• 星标口径：全文数字锁定 2026-11-04 API 快照；你阅读时请以当时 GitHub 为准。

写前核实过、仍保持谨慎表述的点

• LobeHub / LibreChat 的 Web Push：未在本轮读到与 Open WebUI 同级的「已实现」证据，故不宣称。
• Eliza 端侧具体权限清单与生产推送：官方以侧载与 Coming soon 为主，细节不展开成承诺。
• HA 推送是否「iOS 也经 FCM」：Companion 文档描述官方服务经 Firebase 体系；实现细节以你部署的 App flavor 为准。
• 矩阵中非移动端列（记忆实现深浅、MCP 边角）仍是粗粒度，上线前请对目标版本复测。

你真正要收藏的，不是某一个星标数字，而是那张四层图：端、Gateway、执行环境、推送。星标会涨会跌；分层想清楚了，换项目也不至于把手机又变回一块只能聊天的砖。

最后留一句给正在用 Grok Bot 或同类系统的人：你已经有的草稿审批、Auto-review、routines，迁到移动端时，优先复用协议与队列，而不是复用 UI。UI 可以是 OpenClaw 卡片、Telegram 按钮或 HA 通知；队列与审计才是你真正的产品资产。把资产留在 Gateway，把触角伸到手机——这才是「装进手机」，而不是「在手机里重写一遍」。

手机不会自动变成个人 Agent 的躯干。你要先决定：它是设备节点、聊天入口、浏览器书签，还是被操控的执行器。四种形态可以叠，但每一层都有自己的权限与故障域。把这篇当对照表：下次有人扔给你一个「也能手机用」的开源链接，先问它到底站在哪一层——再决定值不值得收藏进你的自建清单。