Hermex：把 hermes-webui 伺服器裝進 iPhone 的原生客戶端
Native iPhone app for your Hermes agent
秒懂
- 它是什麼？
- Hermex 是一個 MIT 授權的 SwiftUI iPhone App，用來操作你自己架設的 hermes-webui 代理伺服器。它不提供後端、不代管資料，手機只是控制面板。本文說明它的資料流、啟動步驟、版本相容風險，以及什麼情況下你不該用它。
- 適合誰用？
- 如果你已經有一台跑著 hermes-webui 的機器，而且願意自己處理 TLS、隧道或 Tailscale 路由，Hermex 值得裝來試，因為它把手機端該有的操作面（串流對話、Session 搜尋、cron 任務、技能瀏覽）都做成了原生介面。若你還沒架伺服器、或希望有人幫你把後端一起搞定，這個專案幫不上忙，它的 README 明講自己不附帶、不託管、也不代為佈建後端。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Swift（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是「人在外面，代理在機房」這個距離問題
自架 LLM 代理的人常遇到同一個處境：運算跑在桌機、家用伺服器或租來的 VPS 上，但你人不在那台機器前面。要查看一輪對話跑到哪、要中止一個正在燒 token 的執行、要改一條 cron 排程，就得開筆電、連 VPN、進瀏覽器。Hermex 針對的就是這個斷點。它的 README 開頭寫得很直白：「Your server. Your iPhone. No middleman.」手機是控制平面，不是運算平面，代理、工具與資料都留在你自己的硬體上。
目標使用者輪廓清楚：已經自行架設 hermes-webui 的人。README 的 Getting started 第一句就是「Hermex is a client only」，它不自帶、不託管、也不代你佈建後端。你得先有一台跑著 hermes-webui 的機器（macOS、Linux 或 Windows/WSL2，Python 3.11+），設好 HERMES_WEBUI_PASSWORD，然後才輪到這個 App 上場。反過來說，如果你還沒架伺服器，Hermex 對你而言只是一個連不上的空殼。
它主打的三個屬性彼此有因果關係：免費（無訂閱、無內購）、隱私（README 聲明沒有分析、沒有追蹤、沒有第三方中繼，App 只跟你的伺服器通話）、原生（真正的 SwiftUI，iOS 18+，不是網頁包裝）。第三點是體驗差異的來源，前兩點則是架構選擇的結果：因為不經別人的伺服器，所以沒有可收費的中介層，也因為沒有中介層，才需要你自己解決網路可達性。
資料流只有一條：App 直接對你的 hermes-webui 講話
從 README 能確認的架構很單純，沒有中間服務。你在 App 裡填兩個東西：伺服器 URL（例如 https://hermes.yourdomain.com）與密碼，之後所有請求都指向那個位址。伺服器端負責代理、模型供應商設定、技能與記憶，App 端負責呈現與操作。
功能清單反映的正是這條線的兩端。對話可以帶上 model、reasoning-effort、workspace、profile 等選項，附加檔案與圖片，回應以串流方式進來，並顯示 thinking 與 tool-call 細節；執行中可以中途轉向或停止。Sessions 可瀏覽、搜尋、續接伺服器上的每一段對話，而且已快取的 session 離線仍可讀。模型切換是讀伺服器已設定的清單，附最近使用與我的最愛。Tasks 面板對應的是代理的排程 cron job，Skills 是可搜尋的已安裝技能，Workspace browser 直接瀏覽伺服器檔案系統，Memory 與 Insights 則是唯讀的記憶與用量面板。
有兩個細節值得注意。第一，Memory 與 Insights 是唯讀的，README 用「read-only panels」描述，所以別預期能在手機上編輯代理的記憶內容。第二，離線可讀僅限已快取的 session，這是快取行為，不是離線優先的同步架構。整體來看，這個 App 的設計哲學是把伺服器當唯一真相來源，手機端盡量薄。這讓狀態不會分叉，代價是任何網路中斷都會讓功能停擺，只剩快取的那部分能看。
讓手機連到伺服器：三條路，代價各不相同
README 把可達性方案分成三種，並明確標示偏好。第一種是走隧道或反向代理提供 HTTPS，建議使用 Cloudflare Tunnel 或任何能在你擁有的網域上終結真實 TLS 的反向代理。理由是 iOS 的 App Transport Security：真實 HTTPS 不需要開任何例外。但 README 也點出了這個方案的性質，在公開可達的主機名稱上，密碼是唯一的應用層防線，所以必須設得夠強。
第二種是 Tailscale Serve，把伺服器綁在 127.0.0.1:8787 並維持密碼保護，先檢查既有的 Serve/Funnel 路由，確認 HTTPS 443 埠的根路徑空著，才下 tailscale serve --bg 8787。iPhone 端也要裝 Tailscale，並用 tailscale serve status 回報的那個確切 https://…ts.net 網址連線。這條路把暴露面壓到最小，代價是多一層需要維護的網路設定。
第三種是直接在 0.0.0.0 上用純 HTTP 綁定，README 稱之為手動備援方案，不是預設做法。另外，模擬器在本機測試時可以用 http://localhost:8787，前提是伺服器就跑在同一台 Mac 上。
連不上時的排查順序 README 也給了：主機是否醒著、hermes-webui 是否在跑且 /health 有回應（curl https://<your-server>/health）、隧道或反向代理或 Tailscale 路由是否連上、URL 與密碼是否正確。這四步的排序合理，因為它從最底層往上查。我的看法是，這份文件在可達性上寫得比多數同類專案誠實，它沒有假裝「填個網址就能用」，而是把安全責任明確交回使用者手上。
從原始碼建置：Xcode 26 與 HermesMobile target
README 建議一般使用者直接用 App Store 版本，除非你在開發。要自己編譯，需要 Xcode 26 或更新版本（iOS 18 SDK），以及一台 iOS 18+ 的 iPhone 或模擬器。
流程是 clone 專案、開啟 HermesMobile.xcodeproj、在 iPhone 模擬器上跑 HermesMobile scheme。這裡有個容易搞混的地方：Xcode target 叫 HermesMobile，但 App 的顯示名稱是 Hermex，兩者不同名。相依套件由 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'
若那個模擬器沒安裝，用 xcrun simctl list devices available 列出可用裝置再挑一個鄰近的 iPhone 模擬器。使用 XcodeBuildMCP 的人，本機驗證的預設值放在 .xcodebuildmcp/config.yaml，標準的改動後流程寫在 DEVELOPMENT.md。
我沒有實際執行過這些指令，以上全部照 README 陳述。可以確定的是，專案把建置路徑與模擬器名稱寫死在範例裡，這對照著做的人方便，但如果你的 Xcode 版本或模擬器清單不同，就得自己替換。
伺服器版本相容是這個專案最實際的風險
README 的 Server compatibility 段落是整份文件裡最該被反覆讀的一段。App 是針對 UPSTREAM_TESTED_SHA 這個檔案裡釘住的 hermes-webui commit 開發與測試的。上游尚未保證 API 穩定，其 README 也聲明在完成 stable-API 工作之前不支援版本偏移，因此更新或較舊的伺服器版本都可能弄壞個別功能。
這句話的份量比它看起來重。它意味著 Hermex 的可用性上限由上游決定，而不是由 Hermex 自己的發版節奏決定。從 release 記錄看，v1.4.0 在 7 月中、v1.5.0 在 8 月初、v1.6.0 在 9 月初，大約月更的頻率，但上游若在兩次發版之間改了 API，中間這段空窗就得由使用者自己承擔。
具體的失敗模式可以推想，但我要標明這是推論而非文件所述：既然 Tasks 對應 cron job、Skills 對應已安裝技能、Memory 與 Insights 對應伺服器端面板，那麼上游只要更動其中任一項的回應結構，對應畫面就可能顯示異常或無法操作，而對話功能未必同時受影響。這種局部失效比整體崩潰更難察覺。
因此，把 Hermex 接上一個你隨便更新的伺服器，是有風險的組合。若你打算長期使用，值得在升級 hermes-webui 前先確認 UPSTREAM_TESTED_SHA 是否跟著動了。README 沒有描述任何版本協商或降級相容機制，這點在文件裡是空白。
什麼情況下該改用別的方案
Hermex 的定位很窄，窄到它有明確的替代品。如果你的代理跑在遠端，而你要的是跨平台、免安裝的存取方式，hermes-webui 本身的網頁介面就是最直接的對照組：同一個伺服器、同一份資料，用瀏覽器開就行。兩者的差別在於形態而非能力。網頁版不需要 App Store、不受 iOS 版本限制、在 Android 與桌機上都能用；Hermex 換到的是原生 SwiftUI 的互動品質，串流輸出、工具呼叫細節、執行中轉向與停止這些操作在原生介面上更順手，而且已快取的 session 在離線時仍可讀，這是瀏覽器分頁做不到的。
反過來，如果你要的是「不用自己維運」的體驗，那 Hermex 與 hermes-webui 這整條路線都不適合，因為 README 已把自架、防護與維持可達性的責任全部劃給使用者。托管式服務在這一點上是完全不同的取捨。
還有一個常被忽略的維度：平台鎖定。這個 App 需要 iOS 18+，團隊裡若有人用 Android 或較舊的 iPhone，就無法共用同一套操作方式，只能回到網頁介面。這不是缺陷，是原生客戶端的本質，但採納前應該先確認使用者的裝置分布。
授權、維護成本與採用判斷
Hermex 採 MIT 授權，README 的授權徽章與 LICENSE 檔案一致。這表示你可以讀原始碼、自行建置、修改並再散布，義務主要是保留著作權與授權聲明。這裡不構成法律意見，實際條文仍應以 LICENSE 檔案為準。需要留意的是，App Store 上的版本與你自己編譯的版本是兩條路：前者方便，後者讓你掌握建置環境，但你要自己跟上 Xcode 與 iOS SDK 的變動。
維護成本落在三個地方。第一是伺服器端，hermes-webui 的安裝、HERMES_WEBUI_PASSWORD 的設定、TLS 憑證或 Tailscale 路由的維持，這些都不在 Hermex 的範疇內。第二是版本對齊，如前一節所述，上游 API 未穩定，UPSTREAM_TESTED_SHA 是你唯一能對照的錨點。第三是建置環境，Xcode 26 與 iOS 18 SDK 是 README 明列的下限。
至於 App 本身的發版節奏，從 7 月到 9 月三個 minor 版本看來是穩定的，但這是發版時間的觀察，不代表功能品質。README 沒有提供任何效能數據、使用者規模或相容性矩陣，這些欄位在文件裡就是空的，我不會替它補上。
採用與否，取決於你是否已經在那條路上。已經有 hermes-webui 在跑、也願意自己處理網路可達性的人，Hermex 是一個合理的原生前端，安裝前先確認伺服器版本對得上、/health 有回應、並想清楚密碼之外還有沒有其他防線。還沒架伺服器的人，這個專案不是起點，它假設你已經站在終點那一側。
編輯結論
如果你已經有一台跑著 hermes-webui 的機器，而且願意自己處理 TLS、隧道或 Tailscale 路由，Hermex 值得裝來試，因為它把手機端該有的操作面（串流對話、Session 搜尋、cron 任務、技能瀏覽）都做成了原生介面。若你還沒架伺服器、或希望有人幫你把後端一起搞定，這個專案幫不上忙，它的 README 明講自己不附帶、不託管、也不代為佈建後端。安裝前先確認三件事：你的伺服器版本是否等於 UPSTREAM_TESTED_SHA 所指的 commit、curl https://<你的伺服器>/health 是否回應、以及你打算用哪種方式讓手機連到伺服器。最後一項會決定你的密碼是不是唯一一道防線。
社群筆記