最晃眼的Agent。
这是打开 Hermes Agent 官网时的第一感受。
Hermes Agent 官网首屏，截图于 2026 年 8 月。
这里的“晃眼”只说视觉，不是能力排名。
高饱和蓝色铺满屏幕，上面压着白色巨型标题和赫尔墨斯线稿。
赫尔墨斯（Hermes）是古希腊神话中商业、旅行、道路与信使的守护神，也是众神的信使。Nous Research 用他的名字来命名这款可以在不同入口之间传递消息、调用工具并执行任务的 Agent，倒也贴切。
这个设计确实让人过目不忘。
更亮眼的是它的热度，截止 2026 年 8 月 12 日，GitHub API 显示 Hermes Agent 约有 22.9 万 Star。
现在已经有 Codex、WorkBuddy 等完成度很高的 Agent 产品。它们有桌面端、云端和移动入口，已经把大部分配置收进产品里。
Hermes 为什么还有这么多开发者关注它？
看完它的产品和代码，我更看重一个差异：Hermes 把整套 Runtime 的控制权交给了使用者。
这也是判断它适不适合自己的关键。
Hermes 早已不只是一个命令行工具
图：Hermes 图标，真是文艺啊
Hermes 有原生桌面端、CLI/TUI 和 Web Dashboard，也能从 Telegram、Discord、Slack、WhatsApp、Signal 等消息平台接收任务。
Agent 可以在本机或 Docker 中运行，也可以通过 SSH 连接 VPS 和其他远程执行环境。
Hermes Agent 官方桌面应用展示图
桌面应用也不是给命令行套一层壳。
左侧可以管理多个 Agent 任务，主界面保留对话、工具调用和执行结果。它已经具备成熟 Agent 产品的基本形态。
不过，多入口已经不是 Hermes 独有的优势。
WorkBuddy 可以从微信发起任务、回答追问和批准文件修改，再回到桌面端查看过程。小程序还可以在云端沙箱和远程电脑之间选择。
Codex 则把 App、CLI、IDE 和 Cloud 连在一起。任务运行后，用户还能从 ChatGPT 手机端查看线程、终端输出、测试和 Diff，并完成审批。移动端能力仍有预览状态、平台和地区限制。
所以，如果需求只是“电脑执行、手机发消息”，现在已经有不少更省事的选择。
多模型和本地运行，不是 Hermes 的独有优势
Hermes 支持 Nous Portal、OpenRouter、OpenAI、自定义 Endpoint 和兼容 OpenAI 协议的本地服务。配置完成后，可以在同一套运行环境里切换模型服务商和模型。
主 Agent 和部分辅助任务还可以分开选模型。比如 Curator、视觉、Embedding 和 Session Search，不必都使用同一个 Provider。
这确实比普通聊天工具更深入，但这还不足以说明“多模型”就是 Hermes 的独有优势。
WorkBuddy 已经把多模型和自定义 API 集成到设置界面，也能接入本机 Ollama。普通用户不必修改配置文件，就可以在多个模型之间切换。
Codex CLI 的单个会话不能像 Hermes 那样直接切换模型服务商；要切换 Provider，需要使用目标配置重新启动。
Hermes 的入口和基础能力已经覆盖成熟 Agent 产品常见的范围；它虽然能更细致地配置模型，但还不足以单独成为首选理由。
Hermes 真正让用户掌控的是整套 Runtime
把 Agent 想成一个长期工作的员工。
模型只是它的大脑。它还需要接收任务的入口、保存会话、沉淀经验的记忆系统、调用工具的权限、定时启动的机制，以及真正执行命令的电脑或服务器。
Hermes 把这些部分集中在同一个采用 MIT 协议的开源项目里：
- 桌面端、CLI 和消息 Gateway，负责接收任务；
- Agent Loop 和模型路由，负责思考与调度；
- Session、Memory 和 Skill，负责保存会话与经验；
- Cron、Webhook 和子 Agent，负责定时运行与分工；
- Plugin、MCP 和 Toolset，负责扩展能力；
- 本机、Docker，以及通过 SSH 连接的远程后端，负责真正执行任务。
根据 Hermes Agent 官方架构文档与源码整理。箭头只表示任务流入，以及 Agent 核心的读写、调用关系。
-
WorkBuddy 把大部分复杂度封装在产品界面里。
-
Codex 把开发工作流整合进 OpenAI 的产品体系。
-
Hermes 选择把这层复杂度开放出来。
部署者可以查看和修改模型路由、长期状态、扩展机制、消息入口与执行后端，也可以逐层替换它们。
模型不合适，可以换 Provider；任务不该在本机执行，可以换 Docker 或远程服务器；消息入口、Memory Provider 和工具也能按需要调整。
这才是 Hermes 更明确的差异：它提供的不是一个“本地运行”开关，而是对整套 Runtime 的控制权。
当然，控制权有成本。
依赖、密钥、权限、升级、日志、服务器和故障排查，都需要自己负责。外接云模型、搜索、MCP 或消息平台时，也仍然受相应服务的边界约束。
如果只想把工作做完，这些“自由”很可能只是额外负担。
22.9 万 Star，不等于每个人都该安装
选型可以简单一点。
1. 日常办公，先看成品工具
如果主要处理文档、表格、PPT 和本地文件，又需要微信、小程序或国内 IM，可以先看 WorkBuddy 这类成熟产品。
它已经把模型设置、文件预览、云端沙箱、远程电脑和交付物整合进图形界面。
2. 软件开发，先看 Codex
如果主要工作是写代码、做代码审查、跑测试和处理长期工程任务，可以先看 Codex。
App、CLI、IDE 和 Cloud 可以接力，也能从手机查看和审批任务。
3. 想掌握整套 Runtime，再看 Hermes
Hermes 更适合下面几类需求：
- 部署一个长期运行的个人或团队 Agent；
- 不希望整套 Runtime 依赖单一厂商账号；
- 需要同时调整模型、Memory、Skill、Cron、Gateway 和执行环境；
- 需要连接自己的服务器、内部工具或特殊消息渠道；
- 愿意承担配置、安全和维护成本。
4. Agent 开发者和 AI 从业者
正在做 Agent 的开发者和 AI 从业者，不必把工作迁到 Hermes，却值得读它的代码。
Hermes 展示了几件很具体的事：经验怎样沉淀成可治理的 Skill；工具越来越多时，怎样控制上下文成本；Cron、Gateway、子 Agent 和执行后端，怎样组成一套长期运行的系统。
如果想试，先做一个小实验
不必一开始就把主力工作迁到 Hermes。
可以先选一个边界清楚、失败成本很低的任务。
比如做一个只读的常驻选题雷达：定时检查指定的 AI 项目和论文，只在出现实质变化时，通过消息通道向你发来原始链接、变化摘要和一个值得继续研究的问题。
这个任务也可以交给 WorkBuddy、Codex Automations 或其他工具。测试重点不该是比较谁的功能更多，而是看谁能在模型选择、信息来源、消息入口和维护成本之间取得更合适的平衡。
如果 Hermes 没有减少人工检索，反而增加服务器、模型调用和维护成本，就停止使用。
值得学习，不等于必须成为主力工具。
所以，Hermes 适合谁？
想直接完成工作，可以先选成熟的 Agent 产品。想掌握、改造或研究一套长期运行的 Agent Runtime，再认真看 Hermes。
当 Agent 越来越像一套长期基础设施，除了使用厂商做好的工作台，我们能不能拥有一套可以自行拆解、替换组件并运行的 Agent 系统？
Hermes 至少给了这个问题一个足够完整的样本。
参考资料：
