早上八点五十，你把一个资料整理任务丢给桌上的 Hermes，抓起手机出门。电梯下到十楼，你突然想起来：范围写得太大，只要论文，别把博客文章也算进去。

以前遇到这种情况，你要么一直惦记到中午回办公室，要么掏出手机打开 Telegram，敲一长串话解释上下文。现在 Nous Research 给了一个官方入口——手机 App。这篇文章不重复“终于有 App 了”这句话，只说清三件事：它到底发布了什么、你今天能不能装上、装上以后哪些能用哪些还不能用。

一、先给结论：手机是遥控器，Agent 没有搬家

这是理解 Hermes Mobile 最重要的一点，也是最容易被误解的一点。

官方公告和 TestFlight 页面描述里写得明白：这个 App 连接的是你自己的 Hermes gateway，模型、工具、记忆、项目文件全都还在原来那台机器上。手机负责三件事——说话、看进度、点同意；真正干活的部分一步都没挪。

  手机 App（聊天 / 语音 / 审批 / 状态页）
        │  认证过的网络连接（直连地址、SSH 隧道或 Tailscale）
        ▼
  你的 gateway（hermes dashboard 或 hermes serve，默认 9119）
        │
        ▼
  模型 · 工具 · Skills · 项目文件 · cron

分工清楚之后，很多现象就顺了。10 月 31 日一位 Android 测试者的报告很能说明问题：App 用了大约 55 分钟后先卡死再崩溃，而几乎同时，服务器上那一轮任务照常跑完，后端日志里唯一的痕迹是 WebSocket 以 1006 断开（issue #147323）。界面挂了，工作没挂。

反过来说也成立：手机上看到的“连不上”，八成不是 App 坏了，而是手机到 gateway 这条链路、或者 gateway 自己的认证没过。

二、这次发布的到底是什么

2026 年 10 月 30 日，Nous Research 在纽约的 NousCon 2026 上放出官方手机版公测，并把报名入口挂到了 hermes-agent.nousresearch.com/mobile。这个页面只做一件事：让你选平台，然后跳到对应的分发渠道。

项目	实际情况
iOS	Apple TestFlight 公开邀请
Android	Firebase App Distribution（不是 Google Play）
应用包名	ai.nousresearch.hermes.mobile
版本	1.0.0；Android 侧测试报告里出现的构建是 versionCode 21
上架状态	两边都没有上应用商店，也没有公布正式版日期

按官方公告的说法，App 的三个卖点是：流式对话、在手机上审批工具调用、管理 Bots 和 routines。

有一件事值得单独提。10 月 25 日，也就是公测前五天，Nous 官方还专门提醒过：应用商店里没有官方 Hermes App，打着 Hermes 旗号、界面做得像模像样的第三方 App 多为仿冒。所以别在商店里搜名字，只从官方页面进。

顺便说一个容易踩的混淆：本站生态页里收录的 Hermes Mobile 是社区开发者做的第三方 Android 客户端，跟这次 Nous 官方发布完全是两回事，只是名字撞了。

三、今天想装？两个入口的状态得先看清楚

公测已经开放，不等于你现在点进去就能装。这是我今天（11 月 2 日）亲自核查的结果，也是发这篇文章时最需要提醒的部分。

iOS 这边，公开邀请链接现在是死的。 官方页面发给你的地址是 testflight.apple.com/join/U8e1zmbc，今天返回 404——Apple 那个只有 896 字节的裸 “Not Found” 页面，不是“名额已满”的提示页。这两种状态差别很大：名额满了，页面还会显示 App 信息并告诉你满了；404 说明这个公开链接本身失效了（被撤销、过期或者换掉了）。而 /mobile 页面本身还是 200，仍在对外发这个旧链接。GitHub 上有人用桌面 UA、iPhone UA、TestFlight UA 和加了防缓存参数的地址各测了一遍，结果一致（issue #147556、issue #147269 的评论）。

Android 这边是名额满了。 打开 Firebase 分发链接，用 Google 账号登录之后会看到一句很直白的提示：This app is at the tester limit，下面小字让你去找开发者清名额。这条报告下面有好几个不同机器、不同账号的用户独立确认过，症状一样（issue #147269）。

所以现在真实的状态是：一批人已经装上了、在报 bug；另一批人卡在门口，等名额或等链接修好。这不是你的网络问题，也不是梯子问题。

四、后台要准备什么

就算拿到安装包，App 也只是个空壳，得先有后端。按测试者报告里反复出现的配置，可以整理成这样一份清单：

1. 把 gateway 跑起来。 常见两种：hermes dashboard（默认 9119，带 dashboard 认证）或用 hermes serve 对外提供 Web 服务。命令细节可以看 hermes dashboard 命令参考。
2. 让手机能路由到它。 同 Wi-Fi 最省事；不在一个网络就用 Tailscale（这也是测试者用得最多的方案），或者干脆用 App 里的 SSH 隧道模式。
3. 别把 9119 裸暴露到公网。 这个端口背后是你的 Agent，能执行命令、能读写文件。用 Tailscale 的网段访问，或者用 Tailscale Serve 出 HTTPS 再把 webapp.public_url 指向那个地址。
4. 准备好认证方式。 App 支持两条路：一是用 Nous 账号走浏览器登录（回调到 /auth/callback），二是 Direct 模式填地址加密码（dashboard 的 basic_auth）。
5. 想要推送，还得装插件。 服务端需要 hermes-mobile-push 这个插件，但它目前不在插件目录里——hermes plugins search hermes-mobile-push 返回 No catalog entries matched，只能手工放到用户插件目录（issue #147651）。缺了它，“回复完成”的推送就别指望。
6. 后端版本别太旧。 报告里出现的后端基本都是 v0.22.5（2026.9.24）。

另外提醒一句：App 里的连接方式不止一种——Direct（地址 + 浏览器登录或密码）、SSH & Mosh 隧道、以及对着 dashboard 地址的直连。不同模式踩的坑不一样，第 6 节会看到具体例子。

五、1.0.0 里已经能用的东西

官方没给功能清单，文档站也还没有手机版设置指南。下面这张表是从首批测试者的真实报告里拼出来的，每条都带 issue 编号，可自行核对。

能力	状态	细节
流式对话	可用	长回复、Markdown 都正常；会话列表和 Projects/Artifacts 有入口
模型选择	可用，但有显示缺陷	客户端读的是网关的 /api/model/options；一位测试者的后端返回 nous 分组 69 个 id、custom:openrouter 分组 407 个
实时语音（Live Voice）	可用，能打断	默认设置下新会话找不到入口，见下方小技巧
审批工具调用	官方公告列出	手机点同意这件事，意义和风险都很大
Bots / routines	官方公告列出	cron 的投递会进 Bot Chat，但在 App 里样式会出错，见第 6 节
System 页	可用	显示 Host 地址、Hermes 版本、发布日期、健康状态、认证方式
推送通知	不完整	思考时有通知、回复完成没有；需先确认 push 插件装好
内联 HTML 报告	暂无	生成的可视化看板只能当文件下载，不能内嵌渲染

实时语音有个实用小技巧，来自 issue #147322：默认设置下，新建的空白会话没有启动实时语音的入口，必须先发一条文字。把 Settings → Chat → Collapsed Voice Button 从“语音消息”改成“实时语音”之后，新会话和快捷开关都能一键进语音，普通语音消息改从输入框发。测试者原话是“开车时这个一键启动很重要”，语音本身（含打断）跑得挺好。

六、六个真坑，装之前先知道

公测版就是公测版。下面这些都是已经进了 issue 的具体问题，不是“听说”。

1. 长会话会吃内存。 那位 Android 测试者的记录很完整：大约 55 分钟，中途反复切换实时语音和长流式回复，先 ANR（主线程卡在等 GC），13 秒后 java.lang.OutOfMemoryError，256 MB 堆打满，设备是 Galaxy S25 / Android 17（#147323）。目前只出现一次，但这说明长会话是接下来最该盯的场景。

2. 长回复滚不动。 同一位测试者还报了滚动卡顿、长流式回复滚不进视野（#147321）。

3. 气泡文字被裁。 首次绘制时气泡底部被切掉半行，用户和 Agent 两边都中招；往上滚再滚回来就完整了——说明内容没丢，是渲染高度算错（#147723）。

4. 模型名截断到分不清。 deepseek/deepseek-v4.1-flash 和 deepseek/deepseek-v4.1-flash-1017 在手机上显示成同一个 deepseek/deepseek-v4.1-fl…，区别正好在被切掉的尾巴上（#147319）。

5. 登录回调会开两次。 Android 上偶发：浏览器里留下一个 invalid_grant 错误页，但 App 其实已经登录成功。日志显示两次 /auth/callback 相隔 697 毫秒，第二次用的还是已经消费掉的 code，是那个“输掉的分页”被渲染出来了（#147738）。这类“其实成功了却报错”的坑最容易让人反复重试。

6. 远程 gateway 的聊天连接会被 403。 认证过了、WebSocket 却一直被拒，App 上显示 “Hermes signed you in, but turned down the chat connection.”。根因是带 ticket、但不带 Origin 头、又来自非本机地址的升级请求，在 ticket 校验之前就被当成原生本地连接挡掉了（#147361）。同一台机器上改用 SSH & Mosh 也未必好使：iOS 上出现过 SSH 和 dashboard 服务端都成功、App 却报“凭据错误”的情况（#147726）。

还有两个偏运维的坑值得记一笔。 一是 hermes-session-reset-policy 插件对 source=gui 的会话从不生效，也就是 dashboard / Desktop / 手机这条线上的会话不会按空闲重置；有位用户 6 小时内看到 47 次上下文压缩，随后手机端就收不到回答了（#147660）。二是 cron 以 deliver: bot-chat 投递的消息，在 App 里会被画成“用户自己说的话”，而 Telegram 上同样的内容是对的外发消息样式（#147573）。

至于“回复完成没提醒”那条（#147345），报告者后来自己关掉了——他怀疑少装了一个组件。结合上面提到的 push 插件不在目录里这件事，基本能对上：不是通知系统坏了，是你可能压根没把推送那一环装上。想彻底搞明白通知该怎么调，可以先看站内这篇 Hermes 通知与提醒配置。

七、拿到名额后的十分钟验收清单

与其一上来就装一堆插件，不如先用一个低风险任务把链路走通。下面这套顺序，是我建议的验收流程，基本覆盖了上面所有坑的触发条件：

1. 新建会话，问一个一句话能答完的问题，确认能收到流式回复。
2. 让它写一段长回复（一千字以上），边收边观察滚动是否跟得上。
3. 切到别的 App 再切回来，看会话是否还在、内容是否完整。
4. 用实时语音交代一件事，中途打断一次，看它是否接得住。
5. 触发一次需要审批的工具调用，在手机上点同意或拒绝。
6. 打开 System 页，核对后端版本和健康状态。
7. 记下三样东西：App 构建号、手机系统版本、后端 hermes --version。以后报 bug 时，这三样比“用不了”有用一百倍。

如果你还在解决后端那一步，先看 安装指南，再看 Web 版与桌面版的分工——手机 App 走的其实就是同一套 webapp 接口，登录握手也是同一套（Nous 登录与 App 交接讲得更细）。

八、这次变化真正的意义

把上面所有粗糙的部分放在一起，Hermes Mobile 的定位其实很清楚：它不是“把 Agent 塞进手机”，而是“把你从办公室里放出来”。

以前你判断一个 Agent 好不好用，会数它有多少工具、支持多少模型。现在多了一个问题：我不坐在电脑前的时候，能不能顺手找到它、补一句话、点个同意，让事情继续往前走？ 这个问题比功能清单重要得多，因为它决定了你会不会真的把一个跑在服务器上的长任务交给它。

而现在的答案是：能，但别全押在手机上。短任务发起、查看进度、补一句要求、审批一次命令、用语音交代想法——这些已经是可用状态。指望手机独自撑完一个几小时的长任务、还指望每条提醒都准时到，那就高估它了。

等官方把 iOS 邀请链接换掉、Firebase 名额放开，再回同一个页面看一眼就行。别从陌生帖子里的安装包入手，你自己机器上的 Agent 值得更稳妥一点。