安装器结束以后，终端里能输入 hermes，只能说明启动入口已经存在。第一次使用还要确认模型连接正确、工具能读到预期目录，以及退出后能恢复刚才的对话。把这几件事分开验收，遇到报错时才知道该查安装、账号还是权限。
先选安装方式，别同时维护两套环境
本文根据 2026 年 9 月 23 日的官方文档整理。当前安装页提供桌面安装器与仅命令行安装两条路径；macOS 桌面安装器面向 Apple Silicon。其他平台和特性限制应查看平台支持表。旧教程里一句“支持 macOS”不够精确，Intel 机器不能据此推定自己处于当前支持范围内。
如果只是想在自己的电脑里交互使用，可以从官方桌面安装器开始；服务器上长期运行或习惯终端操作的人，更适合阅读命令行安装说明。不要先安装一份桌面版，又在另一个目录手工克隆代码，随后交替调用两个启动器。这样最容易出现“刚更新过，版本却没变”的困惑。
在现有机器上安装之前，先检查是否已经有 hermes 命令，记录它所在路径。如果之前装过，确认旧环境保存的数据在哪里，再决定升级还是新建测试环境。程序代码、配置和会话不一定放在同一个目录，不能以删除某个代码文件夹代替完整卸载判断。
命令行安装应在目标用户下完成
官方 Linux、macOS、WSL2 的命令行入口如下，Windows 原生安装另有 PowerShell 入口。下面是官方公布的安装方式，本文没有在你的生产机器或个人账号上执行安装，也没有完成付费模型授权。
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
这条命令会执行下载的安装脚本，适合在已经确认来源、明确安装范围的环境使用。需要固定部署过程的团队，可以先保存并检查脚本，记录使用的版本，再按自己的软件安装流程运行。下载成功与依赖安装成功也要区分：代理、证书或软件源访问失败时，安装日志通常比最后一句报错更有用。
普通用户的 git 安装通常把代码放在 ~/.hermes/hermes-agent/，启动器放在 ~/.local/bin/hermes。以 root 运行会使用不同布局和数据目录。因此在服务器上先确定日后运行服务的用户，再安装；否则交互测试用的是管理员配置，后台进程却从另一个用户目录寻找模型凭据。
安装后重新打开终端，或仅重新加载自己实际使用的 shell 配置。不要同时执行 bash 和 zsh 的初始化文件。接着检查命令路径和诊断信息：
command -v hermes
hermes --version
hermes doctor
如果第一条没有结果，先检查 PATH 和启动器是否存在。如果能启动但依赖报错，就沿安装日志处理相应依赖。还没到模型请求这一步时，更换 API Key 不会解决解释器或动态库的问题。
配置一个提供方，记录实际选中的模型
通过 hermes model 进入模型向导，或使用 hermes setup 完成初始配置。快速入门文档还提供不同设置模式。初次配置时，选择一种登录方式和一个明确的模型，保留向导最终显示的提供方、模型名和连接方式。
不要把“能在服务商网页聊天”当成“这里的 API 已经可用”。网页套餐、API 账户和第三方工具授权可能采用不同计费与权限规则；是否可用需要按所选提供方的正式说明确认。模型列表里看得到名称，也不保证当前账号有调用资格。
自建模型端点更需要逐项核对：地址能不能从运行 Hermes 的机器访问，协议是否兼容，模型 ID 是否与服务端一致，认证方式是否匹配。本机上的 localhost 只指当前机器。在服务器或容器里填入 localhost，不会自动连接到你的笔记本模型服务。
官方当前要求模型至少具备 64K 上下文。对本地推理来说，模型宣传支持的窗口、服务进程实际配置的窗口和硬件能承受的窗口，是三个需要分别确认的条件。把参数改大可能增加资源消耗，不能用“模型名字一样”代替运行配置检查。先从服务端确认窗口和工具调用能力，再交给 Hermes 使用。
第一次对话只检查连接
启动 Hermes 后，先让它回复一段短文本，不要求联网、不读项目文件，也不让它安装依赖。观察欢迎信息中的提供方和模型是否符合刚才的选择，再看是否能连续回复两轮。这样可以把认证、模型不存在和网络超时等问题，与工具调用错误分开。
收到认证失败时，检查所选账号与凭据；模型不存在时，核对完整模型 ID 和端点；连接超时则先确认目标机器的网络。不要同时更换模型、端点和代理，然后把偶然成功当成原因已经找到。每次只改一项，记录变更前后的报错，会更容易复现。
这次对话不需要复杂提示词。它的验收条件是：你知道请求交给谁，响应能够返回，并且下一轮仍能继续。需要评估模型写代码或分析能力时，另准备业务样本，避免把模型质量测试混进安装诊断。
文件读取测试要放在可丢弃目录
普通对话通过后，创建一个独立练习目录，放一份自己写的短 README，内容可以是项目名、两个功能和一个待办事项。让 Hermes 只读取这份文件并复述待办，再核对返回内容和实际文件。这样你能看出它是否读到了文件，而不只是根据目录名猜测。
“请只读”是一条任务要求，不等于操作系统已经限制了写权限。还应查看实际启用的工具和终端后端，确认它能访问哪些目录。若要验证隔离，使用专门用户、限定挂载或其他真实权限配置，再检查不应访问的路径是否确实受限。不要拿生产密钥目录做第一次测试。
当前配置的最小模式也可能保留文件操作和终端能力，不能把“最小”理解为完全没有工具。运行 hermes tools 查看设置；如果模型只回复“我无法读取”，要分辨是工具未启用、目录不可见，还是模型没有正确发起工具调用。诊断时记录发生在哪一步，避免直接把全部权限打开。
完成读取测试后，检查目录里的文件是否符合预期。以后加入写入操作时，也先在这个练习目录进行：创建一个明确文件、检查内容、再删除它。每增加一种能力，都应能用一个小任务验证结果。
退出以后，确认恢复的是刚才那次会话
给测试会话留一个无敏感信息的标记，例如“这次练习的项目叫蓝色笔记本”。正常退出后，使用 hermes --continue 恢复最近的会话，再让它说明刚才读过什么文件。验证的是持久化与恢复路径，不是让模型记住一段需要保密的口令。
如果恢复出陌生会话，先检查用户、profile 和数据目录是否一致。终端里手工运行与服务进程运行，可能使用不同的环境。不要因为找不到历史就立即覆盖旧目录；先保存配置和日志，确认是不是启动了另一份安装。
普通设置与凭据也需要分开备份。官方文档将常规配置与秘密信息分别存储，但实际认证还可能涉及其他文件。分享诊断材料前逐项去除密钥和令牌，不要直接打包整个用户目录。备份文件本身同样需要限制访问。
需要常驻任务时，再移到服务器
只有你确实需要电脑关机后仍能处理任务，才有必要增加服务器和 Gateway。先在目标用户下跑通相同的对话、读取和恢复测试，再配置消息平台。云服务器适合放常驻进程，但不会自动替你修正模型权限、工具范围或消息账号设置。
选择机器时，先确定模型在云端 API 运行还是在本机推理。两种部署的资源需求差别很大。本文没有对服务器套餐做性能测试，也不把某个规格写成通用最低配置。常驻进程还需要日志空间、备份与服务恢复安排，不能只比较购买页面上的核心数。
配置 Gateway 后，要分别检查平台消息是否到达、Hermes 是否收到任务、模型是否返回，以及回复是否成功送出。能在 CLI 聊天，只证明其中一部分链路正常。再做一次断开 SSH 后的存活检查和重新登录后的状态检查，确认服务生命周期符合预期。
后续升级前，记录当前程序版本、配置位置和一组小验收任务，参考官方仓库的变更说明。升级后重复普通对话、文件读取和会话恢复，再逐步检查扩展工具。即使将来接入更多功能，这几项短测试仍然能帮你找到故障开始的位置。