搜索 “Hermes Agent install” 的用户，通常不是只想复制一行命令。他真正想知道的是：该在哪个系统安装、先选哪个模型、安装后怎么证明它真的可用，以及什么时候才适合继续接 Telegram、Discord、Slack、cron 或 skills。
官方 Quickstart 的核心原则很明确：先让 Hermes 完成一次普通 chat，再逐层加入 gateway、cron、skills、voice 或 routing。也就是说，安装只是第一个检查点，不是整套长期运行环境已经完成。
先抓住 4 个关键点
- macOS 和 Windows 用户可以优先考虑官方 Desktop installer；命令行用户再按系统选择 CLI 安装路径。
- 第一次启动优先跑
hermes setup或hermes model，不要先配置消息网关。 - 如果普通 chat 不能稳定响应，先修模型、API Key、PATH 或终端环境，再谈 gateway、cron 和 skills。
- 长期运行前必须能解释 Hermes 会读取哪些目录、写入哪些配置、使用哪些模型凭据。
官方最小安装路径
如果你希望同时安装命令行和桌面应用，官方 Quickstart 建议 macOS 或 Windows 用户优先使用 Hermes Desktop installer。
如果你只需要命令行，Linux、macOS、WSL2 和 Termux 的官方一行安装命令是：
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bashWindows 原生命令行路径使用 PowerShell：
iex (irm https://hermes-agent.nousresearch.com/install.ps1)安装完成后，重新加载 shell：
source ~/.bashrc如果你使用 zsh，可以改成：
source ~/.zshrc然后先启动 Hermes：
hermes如果你是在服务器、CI 用户或新建 service account 下安装，重点检查 ~/.local/bin 是否在 PATH 里。官方安装文档也提示，服务用户的 shell 环境往往更小，可能需要把 Hermes launcher 加进 PATH，或确认实际调用的是 venv 里的 hermes。
不同目标的启动顺序
| 你的目标 | 先做什么 | 通过标准 |
|---|---|---|
| 只想本机可用 | hermes setup | 能完成一次普通 chat |
| 已经知道模型提供方 | hermes model | 配置保存后能稳定响应 |
| 想用本地或自托管模型 | hermes model 加 custom endpoint | endpoint、model name、context length 都能验证 |
| 想接 Telegram / Discord / Slack | CLI 正常后再 hermes gateway setup | gateway status 正常，允许名单和 bot token 已核验 |
| 想做长期自动化 | 普通 chat 稳定后再加 cron、skills、memory | 每个能力都有独立回滚和审查清单 |
这张表的重点不是命令，而是顺序。很多安装失败看起来像 Hermes 问题，实际是用户还没证明模型链路可用，就开始叠加 gateway、cron 或 browser 工具。
首次模型配置
安装后建议按这个顺序操作：
- 运行
hermes setup，让向导处理基础配置。 - 如果你已经知道要用哪个提供方，运行
hermes model直接选择模型。 - 准备对应 API Key、OAuth 登录或 OpenAI-compatible endpoint。
- 保存配置后，先做一次短问答。
- 如果失败，只排查模型链路，不要同时改 gateway、skills 和 memory。
官方 Quickstart 列出的常见模型路径很多，包括 Nous Portal、GitHub Copilot ACP、MiniMax、Alibaba Cloud、Hugging Face、AWS Bedrock、DeepSeek、NVIDIA NIM 等。新用户不需要一次性比较全部提供方，第一轮只要选一个你能稳定访问、能控制费用、能看懂报错的路径。
Windows、Termux 和服务器安装边界
Windows 用户最容易误判。官方 Quickstart 现在同时给出 Desktop installer 和 PowerShell 命令行路径；如果你只是本机使用，先按官方路径跑通即可。如果你的场景依赖 Linux shell、systemd、容器、后台服务或大量终端工具，仍应把 WSL2 作为单独候选路径验收。
Termux 用户可以走同一安装脚本。官方安装文档说明脚本会检测 Termux，并使用 Termux 的依赖安装路径；但手机环境仍应把长期运行、权限、电池管理和后台保活单独验收。
服务器用户要额外检查三件事：
hermes是否在非交互 shell 的 PATH 中。- 是否需要跳过 browser bootstrap，例如 headless 环境可考虑官方安装参数
--skip-browser。 - secrets 是否放在环境变量、配置文件或 profile 中，并且不会被日志、memory 或 shell history 泄露。
第一次启动后的验收清单
| 检查项 | 成功标准 | 失败时先看哪里 |
|---|---|---|
| PATH | hermes 可以从新 shell 调用 | ~/.local/bin、venv launcher、shell profile |
| 基础诊断 | hermes doctor 没有关键错误 | Python、Node、Git、ripgrep、ffmpeg、dotenv |
| 模型配置 | 能完成一次普通 chat | API Key、OAuth、endpoint、model name、网络 |
| 工具列表 | 你知道哪些工具启用 | hermes tools、profile 配置 |
| gateway | 尚未配置，或只配置一个低风险入口 | bot token、allowlist、platform setup |
| memory | 不把 secrets 写入长期记忆 | MEMORY.md / USER.md 策略 |
| skills | 不把临时脚本直接沉淀 | skill 审查、输入输出、权限边界 |
如果 hermes doctor 报依赖缺失，不要直接复制网络上的零散安装命令覆盖环境。先确认你调用的是安装器创建的 launcher，而不是仓库源码里的某个同名文件。
常见安装失败场景
| 现象 | 更可能的原因 | 处理顺序 |
|---|---|---|
hermes 命令不存在 | shell 没重新加载，PATH 未包含 launcher | 重新加载 shell，检查 ~/.local/bin |
| 安装成功但 chat 没响应 | 模型配置或 API Key 未完成 | 重新跑 hermes model，用最小问题测试 |
| gateway 启动但没人能发消息 | bot token、allowlist 或平台配置不完整 | 重新跑 hermes gateway setup，检查 status |
| Windows 上终端/工具异常 | Desktop、PowerShell、WSL2 路径混用 | 先确认实际安装路径，再决定是否复现到 WSL2 |
| 服务器后台不可用 | service user 环境与交互 shell 不一致 | 检查 PATH、工作目录、环境变量和日志 |
不建议一开始就做的事
- 不要还没完成普通 chat，就接多个消息平台。
- 不要为了“长期记忆”把 API Key、token、cookie 写进 memory。
- 不要把第一次成功运行的临时命令直接做成 skill。
- 不要在没有 allowlist 的情况下把 gateway 暴露给团队或群聊。
- 不要把 OpenClaw 迁移当成普通升级；迁移前先做 dry-run、secrets 备份和回滚计划。
推荐第一天完成的最小闭环
第一天只做一个可回滚闭环：
- 安装 Hermes。
- 配置一个模型提供方。
- 完成一次普通 chat。
- 跑
hermes doctor，记录关键输出。 - 确认 profile、配置文件和 secrets 放在哪里。
- 只选择一个下一步方向：迁移、memory、skills 或 gateway。
如果你来自 OpenClaw，下一步先看迁移页，因为迁移涉及配置、secrets、消息入口和回滚。如果你是全新用户，先看 Memory 教程，理解 Hermes 为什么不是一次性聊天工具。如果你已经有重复流程，再看 Skills 教程，不要急着接 cron。
完成检查
- 你已经能从新 shell 运行
hermes。 - 你完成了至少一次普通 chat。
- 你知道当前模型提供方、API Key 和 endpoint 在哪里配置。
- 你没有把 gateway、cron、skills 和 memory 一次性全部打开。
- 你已经决定下一步是迁移、memory、skills 还是消息网关。