uzairansaruzi/hermex 是什么？

Hermex 是 hermes-webui 的 iOS 原生控制端，手机只做控制面，推理和工具留在你自己的服务器上。它把适配风险明确写进了仓库：上游 API 尚未稳定，客户端与服务器版本必须对齐。

uzairansaruzi/hermex 可以商用吗？

可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。

uzairansaruzi/hermex 还在维护吗？

在维护。仓库最近一次提交在 1 天前。

uzairansaruzi/hermex 是用什么编程语言写的？

主要是 Swift（依据 GitHub 的语言统计）。

Hermex 评测：自托管 Hermes agent 的 iPhone 原生客户端

Q: uzairansaruzi/hermex 还在维护吗？

在维护。仓库最近一次提交在 1 天前。

秒懂

它是什么？: Hermex 是 hermes-webui 的 iOS 原生控制端，手机只做控制面，推理和工具留在你自己的服务器上。它把适配风险明确写进了仓库：上游 API 尚未稳定，客户端与服务器版本必须对齐。
适合谁用？: 适合已经在自托管 hermes-webui、又不想每次开浏览器的人：手机端看会话、改 cron 任务、翻工作区文件，确实比移动浏览器顺手。不适合把 Hermes 当纯云端服务用的人，因为 Hermex 不附带、不托管、也不代你部署后端，服务器可达性和密码强度全由你负责。
能商用吗？: 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
还在维护吗？: 在维护。仓库最近一次提交在 1 天前。
用什么语言写的？: 主要是 Swift（依据 GitHub 的语言统计）。

以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。

开源项目深度解析

Hysen Labs 编辑部 · 2026年9月10日 · uzairansaruzi/hermex

它解决的问题：agent 跑在服务器，人却在手机上

自托管 agent 的常见形态是：推理、工具调用、记忆和文件都留在一台你控制的机器上，浏览器是唯一的入口。这套形态在桌面上没问题，一旦离开工位就变得别扭。Hermex 针对的正是这个缺口，README 把它定位为自托管 hermes-webui 服务器的 mobile cockpit，并强调 phone is the control plane, not the compute plane。

目标用户写得相当窄：已经跑着 hermes-webui、并且愿意自己处理网络可达性的人。仓库说明里 Hermex 是 client only，不附带、不托管、不代你 provision 后端，需要你自备一台 macOS、Linux 或 Windows/WSL2 上运行 hermes-webui 的机器，Python 3.11 起，并设置 HERMES_WEBUI_PASSWORD。

如果 Hermes 对你来说是一个托管服务，这个项目基本与你无关。它假设你有一台自己运维的服务器，也假设你接受为此负责。

控制面与计算面的切分方式

从 README 的功能清单可以还原出数据流：iPhone 通过 HTTPS 直连你的 hermes-webui 服务器，聊天请求带着 model、reasoning-effort、workspace 和 profile 这些选项发出去，响应以流式返回，thinking 和 tool-call 的细节也在同一条流里。运行中还能 steer 或 stop，也就是在服务端已经在跑的那次执行上做干预，而不是重新发一条消息。

其余面板是同一套 API 的不同视图：Sessions 用来浏览、搜索、恢复服务器上的会话，缓存过的会话离线也能读；Tasks 对应 agent 的定时 cron 任务，可以查看和编辑；Skills 是已安装技能的浏览与搜索；Workspace browser 直接翻服务器的文件系统；Memory 与 Insights 是只读面板，分别对应 agent 记忆和使用统计。

值得单独指出的是模型选择这一项：客户端不维护自己的模型清单，而是切换到服务器已经配置好的任意模型或 provider，并记录 recents 和 favorites。这把配置权留在了服务器侧，客户端只做选择。代价是手机上看不到任何服务器没有暴露的模型，好处是不会出现两端配置漂移。

README 明确写着 no analytics, no tracking, no third-party relay，应用只和你的服务器通信。这是架构声明，不是可以独立验证的结论，但至少与它不托管后端的定位一致。

部署路径：15 分钟里真正花时间的是网络

README 给的步骤只有三步：在服务器上装好并启动 hermes-webui，设置 HERMES_WEBUI_PASSWORD；让手机能访问到它；在 App Store 版本里填服务器 URL 和密码。它自己估计大约 15 分钟。

第二步才是全部工作量所在，README 给了三条路线。推荐路线是用 Cloudflare Tunnel 或任意反向代理，在你自己拥有的主机名上终止真正的 TLS。理由是 iOS 的 App Transport Security 对真实 HTTPS 没有额外要求，不需要开例外。这里有一句必须原样读进去的提醒：在公网可达的主机名上，密码是唯一的应用层防线。

第二条是 Tailscale Serve，把服务器绑在 127.0.0.1:8787 并保持密码保护，先检查已有的 Serve/Funnel 路由，只有当 HTTPS 443 端口根路径空闲时才执行 tailscale serve --bg 8787，然后在 iPhone 上装 Tailscale，用 tailscale serve status 报出的那个 https://…ts.net 地址连接。第三条只适用于模拟器本地测试，服务器跑在同一台 Mac 上时用 http://localhost:8787。直接绑 0.0.0.0 走明文 HTTP 被列为手动兜底方案，不是默认值。

连接失败时 README 让先查四件事：跑 hermes-webui 的机器是否醒着；服务是否在跑并能响应 /health，可以用 curl https://<your-server>/health 验证；隧道、反向代理或 Tailscale 路由是否连通；URL 和密码是否正确。这个顺序是合理的，因为它按故障概率从高到低排列。

从源码构建要面对的真实门槛

README 的态度很直接：除非你在做开发，否则用 App Store 版本。自己构建需要 Xcode 26 或更新版本（iOS 18 SDK），以及一台 iOS 18+ 的 iPhone 或模拟器。

仓库结构上有一个容易踩的坑：Xcode 工程文件叫 HermesMobile.xcodeproj，scheme 和 target 都是 HermesMobile，而应用显示名是 Hermex。按名字找 Hermex.xcodeproj 会找不到。依赖通过 Swift Package Manager 自动解析。

命令行构建与测试的命令是：

xcodebuild -project HermesMobile.xcodeproj -scheme HermesMobile -destination 'platform=iOS Simulator,name=iPhone 17' build

xcodebuild test -project HermesMobile.xcodeproj -scheme HermesMobile -destination 'platform=iOS Simulator,name=iPhone 17'

如果本机没有 iPhone 17 模拟器，README 建议用 xcrun simctl list devices available 列出可用设备再挑一个相近的。使用 XcodeBuildMCP 的话，本地校验默认值在 .xcodebuildmcp/config.yaml，标准改动后流程在 DEVELOPMENT.md。

这里没有给出最低 macOS 版本、构建耗时或包体积，材料里也没有 CI 配置的描述，所以这些只能自己在本地确认。

上游 API 未稳定，这是项目自己承认的硬约束

Hermex 有一节 Server compatibility，内容比多数客户端项目的兼容性说明都更坦白：应用是围绕 UPSTREAM_TESTED_SHA 里钉住的那个 hermes-webui commit 开发和测试的。而上游不保证 API 稳定，其 README 声明在稳定 API 工作完成前不支持版本偏移，因此更新或更旧的服务器版本都可能破坏单个功能。

这直接决定了升级成本。服务器端一次 git pull 就可能让手机端某个面板失灵，而失效范围取决于上游改了什么。缓解手段只有一条：把服务器的 commit 钉在 UPSTREAM_TESTED_SHA 附近，或者在升级服务器后重新验证你实际用到的功能。仓库没有提供版本协商、能力探测或降级路径的描述，所以客户端大概率是直接调用，失败就是失败。

这也是判断是否采用的第一个分水岭。如果你的服务器会频繁跟随上游更新，Hermex 会持续给你制造需要手动排查的故障。如果你的服务器版本相对固定，这个风险就小得多。

另外，README 在 Server compatibility 一节末尾是被截断的，后面是否还有补充说明无法从现有材料确认。

什么时候它不如直接用浏览器

hermes-webui 本身就是一个 Web UI，任何能开浏览器的手机都能访问它。Hermex 的增量是原生 SwiftUI 带来的交互质量：流式输出、thinking 和 tool-call 的展开、运行中的 steer 与 stop、离线可读的会话缓存。这些在移动浏览器里不是做不到，是做起来不顺手。

但它换不来任何服务端能力。手机不是算力所在，所有推理仍在你的服务器上跑，Hermex 只是把请求和响应搬了一趟。如果你的使用场景是偶尔查一眼会话，或者你已经在用一套顺手的移动端 Web 方案，引入一个需要单独维护版本对齐的客户端并不划算。

还有一类情况它明确不覆盖：需要在手机上完成服务器部署或修复网络的人。Hermex 不 provision 后端，连接失败时它只能告诉你测试没过，剩下的排查要靠 curl 和隧道工具。

与直接使用 hermes-webui 的 Web 界面相比，两者的差别不在功能集，而在交互层和离线能力：Web 界面零安装、永远与服务器同版本，Hermex 则要求你把客户端版本和服务器 commit 当成一对来管理。选哪个取决于你更怕多装一个客户端，还是更怕在手机上点不准。

许可、维护与升级的实际账

Hermex 以 MIT 许可发布，仓库 LICENSE 文件即为其全文。README 同时说明应用本身免费，无订阅、无内购。需要注意的是，你依赖的 hermes-webui 是第三方、同样 MIT 许可的独立项目，两者的维护节奏互不绑定，许可证也各自独立。MIT 允许修改和再分发，但具体到商标、App Store 分发以及你对自己部署的合规义务，材料里没有涉及，也不构成法律意见。

维护成本主要不在代码，而在版本对齐。仓库提供了 UPSTREAM_TESTED_SHA 这个锚点，等于把兼容性责任交给了使用者：上游不保证 API 稳定，客户端只在钉住的 commit 附近被验证过。每次升级服务器，你都要重新确认自己实际使用的面板是否还工作。

发布节奏可以参考：v1.4.0 在 2026 年 7 月 13 日，v1.5.0 在 8 月 4 日，v1.6.0 在 9 月 6 日，大约每月一版。这说明客户端侧在持续跟进，但不代表上游接口因此变稳。

安全侧的成本同样落在你身上。README 反复强调，在公网可达的主机名上密码是唯一的应用层防线，因此强密码不是建议而是前提；Tailscale Serve 路线则要求服务器绑在 127.0.0.1:8787 并保持密码保护。这两条都属于部署配置，客户端无法替你兜底。

编辑结论

适合已经在自托管 hermes-webui、又不想每次开浏览器的人：手机端看会话、改 cron 任务、翻工作区文件，确实比移动浏览器顺手。不适合把 Hermes 当纯云端服务用的人，因为 Hermex 不附带、不托管、也不代你部署后端，服务器可达性和密码强度全由你负责。上手前先做三件事：curl 一下 https://<your-server>/health 确认服务在跑；核对仓库里的 UPSTREAM_TESTED_SHA 与你服务器的 commit；确认隧道或 Tailscale Serve 给出的 https://…ts.net 地址与 tailscale serve status 输出完全一致。

官方来源

社区笔记