Hermes 支持的渠道越来越丰富，偏偏 iPhone 最最基础的 iMessage 不支持，最近 Hermes 终于补齐了这块短板。
Hermes Agent v0.17.0 里加入 Photon iMessage 支持后，变简单的是「把 iMessage 作为一个消息入口接进 Hermes」。你不需要自己折腾一套 iMessage 桥接脚本，也不需要把手机端消息手工转发给 Agent。Photon 分配一个可收发 iMessage 的号码，Hermes 把这个号码接到 Gateway。配置完成后，你直接用 iPhone 的「信息」App 给这个号码发消息，Hermes Agent 就能在另一端回复。
这篇主要记录三件事：iMessage 作为渠道时消息怎么走，怎么把它接到 Hermes，以及哪些边界需要提前想清楚。
先说适用场景
这个方案适合一个很具体的需求：你已经有一个正在运行的 Hermes Agent，希望多一个手机上很顺手的入口。比如随手用 iMessage 发一句话，让它查状态、记一条信息、触发一个已有流程，或者继续一段轻量对话。
它不太适合做严肃的高可靠消息总线。Photon 的共享线路、免费额度和号码分配方式，都决定了它更像一个方便入口，控制权不完全在自己手里。
我会把它当成「个人 Agent 的手机入口」来看，而不是生产系统依赖；也不会把它理解成一个可以替代 Hermes 后台驻留的运行方案。
原理：消息怎么走
从使用者视角看，你只是在 iPhone 上给一个 iMessage 号码发消息。真正的链路仍然会回到 Hermes 后台，可以拆成几段。
第一段是 iMessage 到 Photon。Photon 给项目分配一个可收发 iMessage 的号码，你的手机把消息发给这个号码。
第二段是 Photon 到本地 sidecar。Hermes 配置过程中会保存设备 token、项目密钥和号码信息，sidecar 负责把 Photon 侧的消息接进来。
第三段是 sidecar 到 Hermes Gateway。Gateway 才是 Hermes 的消息入口层，负责路由、会话管理和权限判断。允许名单和配对审批也在这条链路上发挥作用，避免陌生号码直接触发 Agent。
最后一段是 Hermes Gateway 到 Hermes Agent。Agent 生成回复后，消息沿原路返回，最终回到 iPhone 的「信息」App。
所以排查问题时不要只盯着一个点。iMessage 能发出去、Photon 有号码、sidecar 依赖已安装、Gateway 正在运行、Agent 进程可用、手机号被允许，这几件事都要同时成立。iMessage 只是入口，后面的 Hermes 服务没有跑起来，消息不会自己变成回复。
安装和接入流程
1. 准备环境
开始前先确认几件事：
- Hermes Agent 已经升级到支持 Photon iMessage 的版本。
- 本机或服务器上有 Node.js 18.17 或更高版本。
- 你有一个可以接收 iMessage 的手机号。
- 你有 Photon 账号；没有也可以在配置过程中注册。
- Hermes Gateway 和 Agent 有一个可以持续运行的环境。
Node.js 版本可以先查一下：
node --version如果这一步都不满足，后面排错会很绕。尤其是 Node.js 版本，不要等 sidecar 依赖安装失败了再回头查。
2. 配置 Photon
Hermes 提供了统一向导。第一次配置时，我更建议走向导，因为它能少记几个参数：
hermes gateway setup在向导里选择 Photon iMessage。
如果你已经知道自己要配置什么，也可以直接运行：
hermes photon setup --phone +你的手机号手机号要用国际格式。中国大陆手机号大概是这样：
hermes photon setup --phone +8613800000000命令运行后，终端会给出设备授权地址和验证码。按提示打开 Photon Dashboard，登录后批准这台设备。
页面显示设备已连接后，回到终端等配置继续完成。Hermes 会继续处理 Photon 项目、手机号注册、依赖安装和授权配置。
成功时终端会出现类似下面的输出：
✓ phone registered
✓ allowlisted your number (PHOTON_ALLOWED_USERS)
┌─ Your agent's iMessage number ───────────────────────────────
│ 📱 +16xxxxxxxxx
│ Text this number from your phone to talk to your agent.
└──────────────────────────────────────────────────────────────
✓ Photon setup complete.这里最重要的是 Photon 分配给你的 iMessage 号码。把它存到通讯录里，后面就靠它和 Agent 对话。
还有一个小坑：安装依赖时可能会看到 npm audit 的漏洞提示。只要最后显示 Photon setup complete，就先不要动它。尤其不要顺手跑：
npm audit fix --force--force 可能把 sidecar 需要的依赖版本一起升级掉。这个动作看起来是在「修安全问题」，实际可能是在制造一个更难排查的兼容性问题。
3. 启动 Gateway
首次启动 Gateway 可以指定 Photon 平台：
hermes gateway start --platform photon如果 Gateway 本来就在跑，重启即可：
hermes gateway restart这里要把「渠道配置完成」「Gateway 启动成功」和「Agent 真能回复」分开看。Photon 只是把 iMessage 消息送到 Hermes 这边；Gateway 和 Agent 是否在后台稳定运行，仍然要单独确认。
4. 检查状态
先看 Photon 状态：
hermes photon status重点看这几项：
device token : ✓ stored
project secret : ✓ stored
assigned number : +1...
sidecar deps : ✓ installed如果这几项里有缺失，不要急着去 iPhone 上反复发消息。先把状态补齐。
再看 Gateway：
hermes gateway status看到类似下面的提示，才说明 Gateway 服务本身正在运行：
✓ System gateway service is running我一般会把这两条命令放在一起看：Photon 负责「iMessage 入口有没有准备好」，Gateway 负责「Hermes 有没有在接消息」。还要再确认 Agent 本身可用。少看任何一边，都容易误判。
5. 发送第一条 iMessage
打开 iPhone 的「信息」App，新建一条 iMessage，把收件人填成 Photon 分配的号码，然后发一句简单的话：
你好，介绍一下你自己如果 Hermes Agent 正常回复，说明整条链路已经通了。
hermes photon setup 会自动把配置时填写的手机号加入允许名单。其他手机号第一次发消息时，可能不会直接进入对话，而是需要配对审批。
查看待批准的配对请求：
hermes pairing list批准配对：
hermes pairing approve photon <配对码>这个设计挺必要。iMessage 入口一旦打开，如果完全不做允许名单和配对，任何拿到号码的人都可能给你的 Agent 发消息。对个人工具来说，这种边界比「配置方便」更重要。
6. 看 Photon 后台和额度
在 Photon Dashboard 里，进入 Spectrum -> Users，可以看到当前用户、绑定手机号，以及分配到的 iMessage 号码。
免费版每个项目最多添加 10 个用户。如果要让其他人也用这个入口，可以点击 Add user，填入对方手机号。
需要注意的是，Photon 使用共享 iMessage 线路池，所以不同用户在 Texts on 里看到的收件号码可能不一样。这属于线路分配方式，通常不是配置错误。
免费版目前还有两个比较实际的限制：
- 每个 server 每天最多处理 5000 条消息。
- 每条共享线路每天最多发起 50 次新对话。
日常个人使用大概率够了。但如果你想把它当成多人团队入口，或者希望号码长期稳定、额度可控，就需要认真看 Photon 的付费方案和服务条款。
我的判断
这套接入有用，是因为它把 iMessage 变成了 Hermes 的一个标准消息渠道。它省掉的是自建 iMessage 桥接这部分麻烦：不用自己维护一套消息转发脚本，也不用围绕 iMessage 单独设计一条收信链路。配置过程也更容易复查：先连 Photon，再看 Gateway，最后用一条 iMessage 验证整条链路。
但它不会省掉 Hermes 后台。Gateway 仍然要跑，Agent 仍然要跑，权限、会话和工具调用也仍然发生在 Hermes 这一侧。把它和 Telegram 类比更容易理解：Telegram Bot 不等于 Agent 本身，iMessage 号码也不等于 Agent 本身，它们都只是用户发消息进来的门。
对个人 Agent 来说，这仍然很实用。配置成功后，iMessage 就是一个手机上天然存在的输入框。你可以少维护一个自制入口，但不能少维护承接消息的 Hermes 服务。
但它也有边界。共享线路、免费额度、配对安全、第三方服务依赖，都决定了它更适合个人和轻量场景。真正要做团队级、生产级消息系统，还是应该把权限、审计、稳定性和服务条款先想清楚。
我会先把它作为 Hermes Agent 的一个便捷入口使用：适合随手问一句、触发一个轻量任务、或者让 Agent 接收手机端的临时输入。至于更严肃的自动化流程，还是放在更可控、更容易审计的消息渠道里。