uzairansaruzi/hermex

Hermex 是一个 iPhone 原生应用，它的作用很简单：让你在手机上就能远程操控运行在自己服务器上的 Hermes AI Agent。它不运行模型，只负责发送指令和接收结果，是自托管 AI 工作流的移动遥控器。

今天，一个开发者如果想在移动场景下使用自己部署的 Hermes Agent，通常只有几种选择。要么在手机上打开浏览器，输入复杂的服务器地址，忍受移动端网页交互的种种不便；要么通过 SSH 连接到服务器，在命令行里与 Agent 交互，这对于非技术背景的日常使用来说门槛过高。更常见的做法是，开发者可能被迫将工作流拆解：在电脑前用本地 Web UI 或 CLI 与 Agent 协作，离开电脑后，任务就不得不中断，或者依赖其他云端服务接力，这破坏了工作流的连续性和数据主权。

真正的卡点在于，自托管 AI 的“控制权”被锁在了部署它的那台机器上。用户无法在碎片化时间里，像使用 ChatGPT 手机 App 那样，自然地发起、查看或干预一个正在后台运行的长任务。Hermes 的 Web UI 本身功能完整，但它是一个“地点绑定”的界面。这个项目精准切入的，正是 **Agent 执行层** 的“远程控制与状态可视化”环节。它不替代 Hermes 的核心推理与工具调用能力，而是为这套执行体系增加了一个轻便、即时的操作终端。

旧方案为什么不够好？对于自托管场景，浏览器访问是主流，但它缺乏原生应用的通知推送、后台刷新、离线缓存等能力，交互也非为触屏优化。而像 Cursor、Claude Code 这类桌面端 IDE 集成 Agent，则完全无法迁移到移动场景。自己写一个简单的 API 客户端脚本或许可行，但很快会卡在实时流式响应解析、会话状态同步、文件附件上传、以及为不同屏幕尺寸设计直观 UI 这些具体实现上，远非一个周末项目能解决。

为什么现在成立？核心驱动力是 **AI 从聊天转向执行任务**，以及 **开源生态出现可拼装方案**。Hermes 这类开源 Agent 框架的成熟，让“拥有一个私有、可编程的 AI 助手”成为可能，但它的使用场景还局限在开发机前。同时，MCP（Model Context Protocol）等协议的普及，让 Agent 的工具集变得标准化且可远程调用，为移动端安全、可控地发送指令奠定了基础。开发者不再需要从零构建整个 Agent 栈，只需为现成的、标准化的后端做一个漂亮的前端。

这透露出一个变化：当 AI Agent 的能力足够稳定和标准化后，其价值开始向“接入点”和“交互界面”迁移。早期大家比拼的是 Agent 本身有多“智能”，现在，如何让这个智能体以更自然、更无处不在的方式融入用户现有设备和流程，开始成为新的机会点。控制界面与计算本体的分离，让专用设备（如手机）可以成为通用智能的专用操作台。

对于 Builder 而言，今天可以直接用 Hermex 连接自己的 Hermes 服务器，在通勤路上查看任务进度或发送新指令。它最值得学习的，是其 **“控制平面与计算平面分离”的架构思想**。项目没有尝试在手机端塞入一个迷你模型，而是清醒地将手机定位为输入输出和状态监控终端，所有重计算留在服务器。这种清晰的职责划分，既保证了体验的轻快，又维护了数据与算力的私有性。这个设计模式可以迁移到任何需要将重型后台服务（如本地大模型、自动化脚本、数据爬虫）与轻量级、高频的移动交互前台解耦的场景中，例如用平板控制家庭实验室的模型训练，或用智能手表监控云端数据流水线。