nesquena/hermes-webui 是什么？

Hermes WebUI 是一个用 Python 和原生 JavaScript 写成的三栏式网页界面，目标是让 Hermes Agent 在浏览器和手机上获得与终端几乎一致的操作体验。它没有构建步骤，没有框架，也没有打包器，但这份简单也带来了启动方式和进程管理上的混乱。

nesquena/hermes-webui 可以商用吗？

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

nesquena/hermes-webui 还在维护吗？

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

nesquena/hermes-webui 是用什么编程语言写的？

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

Hermes WebUI 评测：浏览器里跑 Hermes Agent，功能对齐终端，但启动方式有点乱

Q: nesquena/hermes-webui 还在维护吗？

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

秒懂

它是什么？: Hermes WebUI 是一个用 Python 和原生 JavaScript 写成的三栏式网页界面，目标是让 Hermes Agent 在浏览器和手机上获得与终端几乎一致的操作体验。它没有构建步骤，没有框架，也没有打包器，但这份简单也带来了启动方式和进程管理上的混乱。
适合谁用？: 适合已经运行 Hermes Agent、并且希望从浏览器或手机访问同一套记忆和技能的用户。它不引入新模型，不增加配置，只是把终端操作搬到网页上。
能商用吗？: 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
还在维护吗？: 在维护。仓库最近一次提交在 2 天前。
用什么语言写的？: 主要是 Python（依据 GitHub 的语言统计）。

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

开源项目深度解析

Hysen Labs 编辑部 · 2026年8月8日 · nesquena/hermes-webui

它解决的是重复解释自己的问题

大多数 AI 工具每次会话都从零开始，不记得你是谁，不记得你项目的约定，你每次都要重新说明一遍。Hermes Agent 本身用持久记忆、用户档案和技能系统来解决这个问题，但它的正常入口是终端或消息应用。Hermes WebUI 把同一个 Agent 搬进浏览器，让你用网页界面操作，而不用离开 Hermes 已有的记忆和模型。README 说得很直接：它用你现有的 Hermes agent 和现有模型，不需要额外设置。这个项目不是给你一个新的 AI 引擎，而是给 Hermes 一个更友好的操作面板。适合那些已经在终端里用 Hermes、但想要更直观的界面，或者想用手机访问的人。

三栏布局和 Composer Footer 的交互逻辑

界面分三栏：左侧是会话和导航，中间是聊天，右侧是工作区文件浏览。模型、档案和工作区控制都放在 Composer Footer 里，也就是你写消息时始终可见的底部区域。这个设计避免了传统聊天界面里设置项藏在菜单深处的问题。还有一个圆形 context ring 显示 token 用量，让你在输入时就能看到上下文窗口还剩多少。所有设置和会话工具集中在 Hermes Control Center，入口在侧边栏底部。这个布局把常用操作放在手边，把不常用的收进控制中心，逻辑清晰。但右侧文件浏览只支持内联预览，没有提到编辑功能，如果你期待在网页里直接改文件，这里可能不够用。

启动方式有三种，停止方式各不相同

快速开始给了一条简单路径：克隆仓库后运行 python3 bootstrap.py。但 README 同时提供了 ./start.sh 和 ./ctl.sh 两个脚本，三者各有不同的停止方式。bootstrap.py 在前台运行，Ctrl-C 就能停。ctl.sh start 会在后台启动守护进程，把 PID 写到 ~/.hermes/webui.pid，用 ./ctl.sh stop 才能停。而用 start.sh 或脱离前台运行的 bootstrap.py 启动的进程，没有 PID 文件，你得用 lsof -i :8787 或 ss -tlnp 找到端口对应的进程再手动 kill。README 明确警告：ctl.sh stop 只能管它自己启动的进程，管不了 bootstrap.py 或 start.sh 启动的服务。这种三分叉的启动方式对新手不友好，你很可能记不住自己是用哪个命令启动的。

配置靠环境变量，安全和远程访问靠隧道

配置通过 .env 文件和环境变量覆盖来实现，比如 HERMES_WEBUI_HOST=0.0.0.0 可以让服务监听所有网卡。默认端口是 8787，从 lsof 那条命令可以推断。README 强调安全访问方式是 SSH 隧道，从你的 Hermes 设置里建立一个隧道，然后在电脑上访问。它也提到 Tailscale 和手机访问，说明远程访问是设计目标之一。但 README 没有给出具体的隧道命令示例，只说“单条命令”。如果你想在公网直接暴露这个 WebUI，需要自己配置密码，README 提到可以设置密码，但没有详细说明密码字段名。这部分文档比较薄，实际部署时你可能要翻源码才能确认。

Nix 和 Docker 是给严肃部署准备的

除了脚本启动，项目还提供 Nix flake 和 NixOS module，以及 Docker 部署，分单容器和多容器两种。Nix 模块意味着你可以声明式地安装并作为系统服务运行，这对 homelab 用户很有吸引力。Docker 多容器部署暗示 WebUI 和 Hermes Agent 可能被拆成不同服务，但 README 没有给出具体的 compose 文件内容。对于只想快速试用的用户，bootstrap.py 就够了；对于想长期跑在服务器上的用户，Nix 或 Docker 是更稳的选择。但这也意味着你需要额外学习 Nix 或 Docker 的配置语法，项目本身没有帮你规避这些运维成本。

功能对齐 CLI，但语音和移动端细节存疑

README 声称与 CLI 体验有近乎 1:1 的 parity，列出的功能包括聊天、会话、工作区、语音、档案、安全、主题、面板和移动端。语音功能存在，但没有说明是语音输入还是语音输出，也没有提到具体用哪家语音识别服务。移动端访问是明确的卖点，但 README 没有给出响应式布局的细节，只提到可以通过 SSH 隧道从手机访问。如果你依赖语音交互，建议先查 docs 目录下的具体文档，确认语音功能是否满足你的使用场景。这个项目更新频繁，最近三个 release 都是 exp 前缀的实验版本，说明功能还在快速变动，稳定性需要自己观察。

与 OpenClaw 的定位差异，以及它不适合的场景

README 自己把 OpenClaw 列为最接近的竞争对手，两者都是常驻、自托管、开源的 agent，都有记忆、cron 和消息平台接入。关键差异在技能系统：Hermes 会自动从经验中写和保存自己的技能，OpenClaw 则围绕社区市场。Hermes 用 Python 生态，OpenClaw 用 Node.js。如果你已经在用 Python 写工具，Hermes 的集成成本更低。但 WebUI 本身不是独立产品，它依赖 Hermes Agent 的全部能力，所以不适合只想找个网页聊天界面、不想引入完整 agent 系统的人。如果你只需要简单的 Web 对话，直接用 OpenCode 这类自带 Web UI 的工具可能更轻量，但 OpenCode 没有 Hermes 的持久记忆和定时任务。

维护成本和许可证：MIT 下的实验性更新

项目采用 MIT 许可证，可以自由使用和修改，没有 copyleft 限制。最近三个 release 都是 exp-v0.52.x 系列，间隔两到三天，说明开发节奏很快，但实验版本意味着 API 和行为可能随时变化。升级时你需要关注 release notes，因为启动方式、配置键或界面布局都可能调整。README 提到运行测试，但没有给出测试命令的具体内容，你需要在仓库里找测试目录。对于生产环境，建议固定版本号，不要追最新 exp 版本。整体维护成本中等：项目是纯 Python 加原生 JS，没有构建步骤，依赖少，但频繁更新会带来持续的跟进成本。

编辑结论

适合已经运行 Hermes Agent、并且希望从浏览器或手机访问同一套记忆和技能的用户。它不引入新模型，不增加配置，只是把终端操作搬到网页上。不适合那些想要一个独立于 Hermes 生态的通用 AI 聊天界面的人，也不适合对进程管理要求极简的人，因为三种启动方式各有各的停止路径，容易搞混。采用前先确认你的 Hermes 版本与 WebUI 的兼容性，查看 docs/why-hermes.md 了解与 OpenClaw 的差异，并测试 SSH 隧道或 Tailscale 访问是否满足你的安全要求。它的价值绑定在 Hermes Agent 的持续演进上，如果 Hermes 本身停止维护，这个界面也会失去意义。

官方来源

社区笔记