从单机到多机：Hermes Agent 到底解决了什么问题
用上 Claude Code 一段时间后，你会发现一个很尴尬的处境：单机开发时它确实很香，但一旦涉及多台机器、多个项目、不同操作系统，就变得异常别扭。你在这台 Windows 工作站上写前端逻辑，那台 Linux 服务器上跑后端服务，还有一台 macOS 笔记本专门处理 iOS 构建，每台机器都装一套 Claude Code，每次都要手动 SSH 过去开个终端、切目录、敲命令。项目稍微一变复杂，调度就成了灾难。
Hermes Agent 就是冲着这个痛点来的。它是一个基于 Claude Code 构建的多智能体编排框架，核心思路是让一台主机通过 SSH 协议远程调度其他机器上的 Claude Code 实例，实现跨平台、跨机器的统一开发编排。说白了，就是把你的多台开发机变成一个逻辑上的分布式开发集群，由 Hermes Agent 统一分配任务、收集结果，你只需要在主机上维护一套配置。
我当时花了一整个周末把这件事完整跑通，期间踩了不少坑，包括 SSH 密钥权限、Windows 端服务配置、Claude Code 环境变量传递这类细节。这篇文章把这套方案从零到一的完整过程全部写清楚，给同样想搞多机协作开发的读者一条能直接照着走的路。
这套方案适合谁？如果你手上有两台及以上的开发机器，且日常使用 Claude Code 写代码、做重构、跑测试，同时对自动化调度有一定需求，那么这篇文章就是为你准备的。如果你只是单机单项目使用，也可以先了解整体架构，后面扩展时能少走很多弯路。
我把整套方案分成环境准备、SSH 配置、Hermes Agent 部署、Claude Code 远程调度验证、常见问题排查五个部分，每一部分都有可直接复制的操作命令和参数说明。
1. 整体架构与核心思路拆解
1.1 为什么要用 SSH 做远程调度的基石
先说结论：SSH 是这个方案里最稳定、最通用、最不容易出问题的远程通道，没有之一。Hermes Agent 的多机编排最终依赖的就是 SSH 协议，而不是什么自定义的长连接或专有协议。
原因是多方面的。SSH 天然跨平台，Windows、Linux、macOS 都有成熟的 SSH 客户端和服务端实现；SSH 的密钥认证机制非常成熟，可以做到免密登录，这对自动化调度来说是刚需；SSH 本身是加密通道，所有传输的命令、输出、文件内容都是加密的，在开发环境里安全性足够；还有一个很实际的原因——几乎每台开发机都已经预装或可以轻松安装 SSH，不需要额外引入重依赖。
你可以把 SSH 理解为多机编排的高速公路，Hermes Agent 是跑在这条高速路上的调度卡车，Claude Code 则是每辆卡车上装载的货物。没有路，卡车和货物都动不了。
我最初也考虑过直接用 Redis 或 MQTT 做消息队列来协调多机任务，但后来发现两个问题：一是需要在每台机器上维护消息队列客户端，部署复杂度高；二是消息队列本身不解决“如何远程执行命令”的问题，最终还是得回到 SSH 上来。绕了一圈，SSH 才是最务实的底座。
1.2 Hermes Agent 在编排链路中的定位
搞清楚了 SSH 的角色，再看 Hermes Agent 的位置。Hermes Agent 在这套架构里有点像开发团队的“技术主管”，统一接收你的任务指令，拆解成子任务后分发给各个工作节点，也就是各台机器上的 Claude Code 实例，最后汇总结果给你。
具体到我的落地方式，Hermes Agent 跑在主机上，它通过 SSH 协议连接多台工作机。每一台工作机上，我需要保证 Claude Code CLI 可以被非交互式调用，也就是说不需要人工在终端里输入指令，而是由 Hermes Agent 把指令通过 SSH 通道送过去，Claude Code 执行完再把输出回传。
这里有一个关键点：Hermes Agent 和 Claude Code 不是替代关系，而是配合关系。Hermes Agent 负责调度和编排，Claude Code 负责具体的编码理解和代码生成。Hermes Agent 本身需要调用 Claude Code 的能力，所以在主机上也要安装 Claude Code，它承担的是“主控智能体”的职能，而工作机上的 Claude Code 是“执行智能体”。
1.3 相比传统多机开发方式的优势对比
这里用一张表格把多机编排方案和传统方案的差异说清楚，方便你判断是否值得投入时间：
| 对比维度 | 传统多机开发（手动 SSH 逐个操作） | Hermes Agent 多机编排 |
|---|---|---|
| 任务分发 | 人工登录每台机器，手动执行命令 | 主机统一下发，自动分配到各节点 |
| 结果收集 | 分别在各个终端查看输出，人工汇总 | 自动回传，统一展示 |
| 跨平台适配 | 每台机器的命令、路径、环境都要人工适配 | 通过 Hermes Agent 配置统一处理差异 |
| 可复用性 | 操作步骤依赖记忆，无法标准化 | 配置化，可版本管理、可复用 |
| 依赖管理 | 每台机器手动安装依赖，版本易漂移 | 可编排统一安装和校验 |
| 最适合场景 | 机器少、任务简单、偶尔远程操作 | 机器多、任务复杂、需要频繁跨机协作 |
这套方案最核心的价值不是“远程执行命令”，而是“把多机协作变成一种可配置、可复用、可扩展的工程能力”。刚开始配置时确实要花一些时间，但一次配置好，后续所有跨机任务都能走同一套通道。
2. 环境准备：主机与工作机的选型和配置
2.1 主机选型：为什么我推荐 Linux 或 macOS 做控制端
先说主机。Hermes Agent 的控制端，也就是你日常操作的那台机器，我建议优先选 Linux 或 macOS，而不是 Windows。这不是说 Windows 完全不行，而是从稳定性和配置成本角度考虑，类 Unix 系统自带完整的 SSH 工具链，环境变量管理也更直接，排错时能省不少事。
我实际用的是 Ubuntu 22.04 LTS 做主机，原因很简单：包管理方便、SSH 工具链完整、Python 环境干净。Hermes Agent 官方对 Linux 的支持也最好，文档中的示例基本都是基于 Linux 的。
如果你只能用 Windows 做主机，也不是完全没戏。Windows 10/11 自带 OpenSSH 客户端，可以用命令行工具完成大部分操作。但我个人建议，如果你打算长期做多机编排，可以考虑在 Windows 上装一个 WSL2，在 WSL2 里跑 Hermes Agent，网络和进程管理与 Linux 一致，踩坑概率直线下降。我在文章后面的常见问题部分会专门说 Windows 主机的坑。
2.2 工作机准备：列出所有需要接入编排的机器清单
工作机就是实际执行开发任务的机器。你需要先列一个清单，包括每台机器的 IP、SSH 端口、用户名、操作系统类型、已安装的工具链。我用一台 Windows 11 台式机和一台 Ubuntu 20.04 服务器作为工作机，分别模拟前端开发和后端服务的场景。
这里有一个非常关键的建议：给你的工作机设置静态 IP，或者在路由器上做 DHCP 固定 IP 绑定。原因很直白，Hermes Agent 的配置里要写死 IP 地址，如果机器每次重启后 IP 都变，配置就失效了，编排链路就断了。这一点我实际踩过坑，一开始用的是 DHCP 动态分配，结果路由器重启之后工作机 IP 变了，Hermes Agent 连不上，排查了半天才发现的。
清单可以做成这样一份表：
| 机器角色 | 主机名 | 操作系统 | IP 地址 | SSH 端口 | 登录用户 | 核心用途 | | --- | --- | --- | --- | --- | --- | --- | --- | | 控制端 | hermes-main | Ubuntu 22.04 | 192.168.1.100 | 22 | devuser | Hermes Agent + Claude Code 主控 | | 工作节点A | dev-win11 | Windows 11 | 192.168.1.101 | 22 | admin | 前端开发 / 跨平台构建 | | 工作节点B | dev-linux | Ubuntu 20.04 | 192.168.1.102 | 22 | dev | 后端服务开发 / 测试 |
2.3 Claude Code 安装的两种常用方式
工作机上的 Claude Code 是执行任务的“手”，装不好后面全部白搭。这里说两种最常用的安装方式，分别适用于不同场景。
第一种是 npm 全局安装，适用于已经装了 Node.js 环境的机器。版本要求 Node.js 18 及以上，命令是npm install -g @anthropic-ai/claude-code。装完之后验证一下版本：claude --version。
第二种是原生安装脚本，适用于不想装 Node.js、希望用独立二进制文件的场景。官方提供了一个安装脚本，在目标机器上执行后会自动适配系统架构并安装到用户目录。我在 Windows 工作机上用的就是这种方式，因为那台机器是给前端同事用的，我不想为装 Claude Code 再去动它的 Node.js 全局环境。
不管用哪种方式，装完之后都要在每台工作机上手动执行一次claude登录流程，也就是用浏览器授权账号。这个动作是为了让 Claude Code CLI 拿到有效的认证凭证，后续由 Hermes Agent 发起的非交互式调用才能正常工作。当时我有一个误区，以为主控端授权了，工作机就可以直接免授权用，实际上工作机的 Claude Code 是独立的进程，必须要自己的认证凭证。
3. SSH 免密登录配置：多机编排的第一道关卡
3.1 生成密钥并分发到所有工作机
SSH 免密登录是整个编排链路里最容易踩坑、也最需要细心的一步。先说生成密钥。
主机上执行：
ssh-keygen -t ed25519 -C "hermes-agent-main" -f ~/.ssh/hermes_agent_key这里我用的参数说明一下：-t ed25519指定密钥类型为 Ed25519，它比传统的 RSA 更安全、更短、性能也更好，目前所有主流 SSH 实现都支持；-C是注释信息，你可以理解成给这把钥匙贴了个标签，方便以后识别是哪台机器的；-f指定密钥文件的保存路径和名称，我不喜欢用默认的id_ed25519这个名字，因为同一台机上可能有多套密钥，区分开更清晰。
执行完会在~/.ssh/目录下生成两个文件：
hermes_agent_key：私钥，留在主机上，权限默认 600，不要动它hermes_agent_key.pub：公钥，需要分发到所有工作机上
提示：私钥文件绝对不要外传，也不要放进 Git 仓库。如果有人拿到你的私钥，就等于拿到了所有工作机的登录权限。
3.2 使用 ssh-copy-id 批量分发公钥
分发公钥最省事的方式是用ssh-copy-id工具。在主机上，对每一台工作机执行一次：
ssh-copy-id -i ~/.ssh/hermes_agent_key.pub admin@192.168.1.101 ssh-copy-id -i ~/.ssh/hermes_agent_key.pub dev@192.168.1.102执行过程中会让你输入一次工作机的登录密码，这是唯一一次需要密码的操作。之后私钥认证就生效了，后续所有连接都不需要再输密码。
如果你在 Windows 上用的是 OpenSSH for Windows，需要确认下 ssh-copy-id 是否可用。有些发行版默认没有这个工具，那就手动把公钥内容加到工作机的~/.ssh/authorized_keys文件里，一行一个，保存退出即可。注意目录权限，~/.ssh必须是 700，authorized_keys必须是 600，权限不对会导致 SSH 拒绝使用这个密钥认证。
3.3 验证免密登录的关键命令
分发完成后，在主机上逐个测试免密连接是否成功：
ssh -i ~/.ssh/hermes_agent_key admin@192.168.1.101 "echo win11-ok" ssh -i ~/.ssh/hermes_agent_key dev@192.168.1.102 "echo linux-ok"如果看到两边分别输出win11-ok和linux-ok，说明免密通道已经通了。这一步是整个方案的里程碑节点，因为后续 Hermes Agent 的所有远程调用都是基于这个通道跑的，通道不通，后面的一切无从谈起。
我建议把验证结果在清单里标注一下，方便后面排查时对照。我当时在 Windows 工作机上卡了很久，因为 Windows 默认没开 OpenSSH Server，要先通过“设置 → 系统 → 可选功能 → 添加功能 → OpenSSH 服务器”安装，再启动ssh-agent和ssh-server两个 Windows 服务，否则主机连过去直接被拒。
还有一个细节，Windows 工作机的防火墙要放行 22 端口。如果你用的是 Windows Defender 防火墙，在安装 OpenSSH Server 时通常会自动创建入站规则，但某些精简版系统或第三方安全软件会拦截，需要手动放行。这个我在排查章节会展开。
4. Hermes Agent 部署与配置实战
4.1 主机端安装 Hermes Agent 的完整步骤
SSH 通道通了，接着在主机上安装 Hermes Agent。Hermes Agent 的安装方式取决于你的系统环境，官方推荐的方式是通过 Python 的 pip 安装，所以先确保主机上有 Python 3.10 以上的版本。
python3 --version pip3 --version然后安装：
pip3 install hermes-agent安装完成后，执行hermes --version确认安装成功。我第一次装的时候遇到一个坑：pip 安装包名和 GitHub 仓库名不一致，网上的教程混着来，容易装错包。正确的包名是hermes-agent全小写带连字符，不是hermes_agent下划线版本。如果你用的是pip install hermes_agent，装出来可能是另一个无关的包，命令根本调不起来。
装完之后需要初始化配置目录：
hermes init这个命令会在用户目录下创建一个.hermes配置文件夹，里面包含主配置文件和示例节点配置。初始化过程还会提示你设置默认的模型参数和工作目录，我建议都先保持默认，等整个链路通了之后再按需调优。
注意：Hermes Agent 在安装完成后首次运行时需要登录官方网站进行身份验证。这个验证是为了关联你的账号体系和 API 密钥，不是可有可无的流程。安装完如果没有弹出网页登录提示，检查一下你的终端是不是在受限环境，比如某些公司的代理模式会阻止自动打开浏览器，手动访问初始化日志里提示的 URL 即可。
4.2 配置多机节点：把 SSH 连接信息写进配置
接下来是核心配置。打开.hermes/config.yaml，你会看到类似这样的结构：
nodes: primary: host: "127.0.0.1" port: 22 username: "devuser" ssh_key: "~/.ssh/hermes_agent_key" claude_path: "/usr/local/bin/claude" platform: "linux" win11-node: host: "192.168.1.101" port: 22 username: "admin" ssh_key: "~/.ssh/hermes_agent_key" claude_path: "C:\\Users\\admin\\AppData\\Roaming\\npm\\claude.cmd" platform: "windows" linux-node: host: "192.168.1.102" port: 22 username: "dev" ssh_key: "~/.ssh/hermes_agent_key" claude_path: "/home/dev/.local/bin/claude" platform: "linux"每个节点对应一台工作机，字段含义如下：
host：目标机器的 IP 地址或域名port：SSH 端口，默认 22username：登录用户ssh_key：使用哪把私钥连接这台机器claude_path：目标机器上 Claude Code CLI 的绝对路径platform：目标机器的操作系统类型
这里最难搞的就是claude_path，不同系统、不同安装方式，路径完全不一样。建议你提前在每台工作机上执行which claude（Linux/macOS）或where claude（Windows）拿到真实路径，再填进配置。我一开始图省事，直接写了claude不带路径，结果 Hermes Agent 通过非交互式 SSH 执行时找不到命令，因为非交互式 shell 的 PATH 环境和交互式终端里是不一样的。
如果你自己装了多个版本的 Node.js，npm 全局包的路径可能不是你预期的那个。排查方法是在终端里先把which claude的结果打印出来，然后通过ls -la看一下真实路径是否指向了正确的位置。
4.3 配置验证与初始连接测试
配置写完之后，通过 Hermes Agent 自带的诊断命令验证节点是否可用：
hermes doctor这个命令会依次检查每个节点的 SSH 连接、Claude Code 可用性和平台兼容性，输出结果类似：
[OK] primary - SSH connected, Claude Code v2.0.1 [OK] win11-node - SSH connected, Claude Code v2.0.0 [OK] linux-node - SSH connected, Claude Code v2.0.1看到三个节点都显示OK，说明 Hermes Agent 已经能通过 SSH 远程调用工作机上的 Claude Code 了。如果某个节点显示FAIL，先回到 3.3 的免密验证步骤，单独用 SSH 命令连一下，看看是密钥问题还是客户端问题。
hermes doctor是我强烈推荐每次都跑的命令，它能在几秒内暴露大部分配置错误，比逐个排查快太多。
5. 核心实操：用 Hermes Agent 远程调度 Claude Code
5.1 从单机指令到多机编排的切换
安装和配置都做好之后，就可以进入正题了。Hermes Agent 的指令格式延续了 Claude Code 的交互习惯，你可以在终端里直接输入任务描述：
hermes run "检查 win11-node 上的前端项目，找到所有的 TODO 注释并按优先级整理"这条命令的执行链路是：Hermes Agent 读取任务，识别目标节点是win11-node，通过 SSH 连接该机器，在预设的工作目录中以非交互模式调用 Claude Code，传入任务文本，等待执行完成后把结果回传到主机终端。
让我具体说下我在实际中是如何用的。我在主机上执行：
hermes run --node win11-node --task "浏览当前目录下的 src 目录，找到所有 API 调用代码，检查是否有未处理的错误捕获，把问题列出来并给出修复建议"Hermes Agent 会先通过 SSH 在 windows 工作机上找到 Claude Code CLI，然后把任务作为参数传给它执行。执行过程中，输出会流式地回流到主机终端，你能实时看到 Claude Code 在思考什么、执行了什么命令、产生了什么输出。这一点体验很好，如果你直接手动 SSH 过去跑 Claude Code，输出只会留在远程，还得自己切换窗口查。
5.2 多节点并行调度与结果汇聚
单机调度通了之后，多机并行调度就很自然了。比如你有一个需求，既要改前端又要改后端，可以用一次指令同时调度两个节点：
hermes run --nodes win11-node,linux-node --task "分别分析当前项目的代码结构，输出模块清单和依赖关系说明"Hermes Agent 会把这条任务广播到两个节点，每个节点上的 Claude Code 在自己的环境里执行分析，最后把结果分别展示在当前终端里。方便之处是不用来回切换 SSH 窗口，所有节点的输出都在一个终端里按节点名分组显示。
如果你需要做更复杂的编排，比如把一个大型重构任务拆成多个子任务、分发给不同节点执行，Hermes Agent 的任务脚本模式可以做到。大致思路是在配置文件中定义任务流，每个步骤指定节点和指令，类似 CI 流水线。我目前用到这个层级的频率不高，但如果你管理超过三台机器，值得研究一下。
5.3 跨平台开发场景的注意事项
跨平台是这个方案最典型的应用场景，也是最容易出问题的地方。我在实践时发现几个高频坑，在这里集中说明。
第一，路径分隔符的问题。同一段代码里如果写了硬编码的路径，在 Windows 和 Linux 上行为会不一样。比如C:\Users\admin\project在 Linux 上就不存在。建议所有多机协作的任务描述里都不要写死绝对路径，而是用相对路径，或者让 Hermes Agent 在每个节点上先执行pwd确认当前目录。
第二，换行符的问题。Windows 上的 CRLF 换行符传到 Linux 上可能导致脚本执行报错。如果涉及跨平台文件操作，建议在任务里明确指定处理方式，或者在 Git 配置中启用core.autocrlf input来自动转换。
第三，Shell 环境差异。Windows 的 SSH Server 默认 shell 是 cmd.exe 或 PowerShell，而 Linux 是 bash。同一个命令在不同 shell 里的语法不一样。当你用hermes run传指令时，一定要考虑目标节点的默认 shell。比如遍历目录在 bash 里是ls -la，在 PowerShell 里是Get-ChildItem或ls -Force，直接照搬命令会报错。
我的一个实操习惯是：在每个节点的配置里，通过platform字段区分系统类型，然后在写任务指令的时候，根据目标节点单独传参，不搞一刀切的通用任务文本。这样看起来麻烦一点，但实际执行成功率远超通用指令。
6. 常见问题与排查技巧实录
6.1 SSH 连接失败：密钥权限和防火墙的典型坑
多机编排里 SSH 连接失败是最高频的问题，我遇到的案例主要集中在三个方面。
第一个是私钥权限过宽。Linux 下如果私钥文件是 644 或者 777 权限，SSH 会直接拒绝使用。检查命令：
ls -la ~/.ssh/hermes_agent_key正确的权限应该是-rw-------，如果不是，执行：
chmod 600 ~/.ssh/hermes_agent_key第二个是防火墙拦截 22 端口。Windows 工作机上最容易出现这个问题，安装 OpenSSH Server 之后直接测试连接可能被拒。排查方法是在 Windows 上执行netstat -an | findstr :22确认 22 端口在监听，然后在防火墙设置中检查是否存在 OpenSSH Server 的入站规则。我遇到的情况是第三方安全软件把这条规则拦截了，手动添加放行规则后恢复正常。
第三个是 SSH 服务没起来。Linux 上执行systemctl status sshd确认 sshd 服务是 active 状态；Windows 上在“服务”界面确认OpenSSH SSH Server服务已启动并设置成自动启动。
如果用的是非默认端口，比如把 SSH 改到了 22022，那么 Hermes Agent 配置里的port字段必须同步修改，否则一定连不上。
6.2 Claude Code 远程调用报错：PATH 和环境变量问题
在节点上配置好了 Claude Code，但 Hermes Agent 调度时总是提示claude: command not found，这是 PATH 环境变量在非交互式 SSH 会话中加载不完整导致的。
解决方案有两个。第一个，也是最推荐的做法：在 Hermes Agent 的节点配置里，把claude_path写成 Claude Code 的绝对路径。为什么要写绝对路径？因为非交互式 SSH 执行命令时，.bash_profile或.bashrc的加载规则和交互式登录不一样，PATH 不完整是常态。直接把绝对路径填死，绕开 PATH 解析问题，省心。
第二个方法是在节点配置里增加环境变量设置：
win11-node: host: "192.168.1.101" port: 22 username: "admin" ssh_key: "~/.ssh/hermes_agent_key" claude_path: "C:\\Users\\admin\\AppData\\Roaming\\npm\\claude.cmd" env: PATH: "C:\\Users\\admin\\AppData\\Roaming\\npm;%PATH%"Windows 节点的 PATH 分隔符用分号，Linux 用冒号，别搞混。我一开始把 Linux 的写法套到 Windows 上，结果环境变量整个乱了。
6.3 Windows 节点连不上：OpenSSH Server 配置要点
Windows 做工作节点比 Linux 要费心一些。OpenSSH Server 在 Windows 上的配置有几个要点，缺一个都不行。
第一步是安装功能。打开 PowerShell（管理员），执行：
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0安装完成后，设置服务自启动并启动：
Set-Service -Name sshd -StartupType 'Automatic' Start-Service sshd第二步是确认默认 shell。Windows OpenSSH 默认用 cmd.exe。如果你希望 SSH 连接后直接进入 PowerShell，需要执行：
New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -PropertyType String -Force这个设置直接影响 Hermes Agent 传过去的命令是否能被正确解释。如果你的任务指令是按 PowerShell 语法写的，但连接进去是 cmd.exe，命令就会异常。
第三步是权限。Windows 上 OpenSSH 的公钥认证文件路径是C:\Users\用户名\.ssh\authorized_keys，这个目录和文件的 ACL 权限必须只允许当前用户和管理员访问，否则 sshd 会拒绝公钥认证。很多教程不强调这块，但实际踩坑率极高。
6.4 阿里百炼等国内模型的对接思路
部分读者可能用的是阿里百炼等国内模型平台，而不是 Anthropic 官方 API，需要通过环境变量或配置文件对 Claude Code 指向兼容的端点。Hermes Agent 在节点配置中支持设置环境变量，可以在节点层级加入：
linux-node: host: "192.168.1.102" port: 22 username: "dev" ssh_key: "~/.ssh/hermes_agent_key" claude_path: "/home/dev/.local/bin/claude" env: ANTHROPIC_BASE_URL: "https://你的兼容端点" ANTHROPIC_AUTH_TOKEN: "你的API密钥"这样工作机上的 Claude Code 在调用模型时就会走你配置的兼容端点，而不是官方默认的 API。不同平台的变量名可能有差异，接入前先确认 Claude Code 支持的环境变量标准名称。注意，这里不需要在每台工作机的系统级环境变量里修改，只改 Hermes Agent 的节点配置即可，这样更干净、更可复用。如果你用 CC Switch 切换不同模型商，思路类似，CC Switch 负责管理本地 CLI 的多套配置模板，Hermes Agent 负责跨机器的调度，两者可以共存。
6.5 连接 Windows 认证失败：用户名与域名的坑
SSH 连接 Windows 认证失败，最常见的错误提示是Permission denied或ssh: connect to host ... port 22: Connection refused。表面看是认证问题，但实际原因可能五花八门。
我遇到过的典型案例是用户名的格式问题。Windows 的 OpenSSH 在解析用户名时，如果你使用 Microsoft 账户而非本地账户，用户名不是你的邮箱前缀，而是你本机用户目录的文件夹名。比如你 Microsoft 账户是alice@outlook.com，但本机用户目录是C:\Users\Alice_Zhang，SSH 连接时的用户名可能是Alice_Zhang，而不是alice。这个从 Windows 登录界面上看不出来，但会让 SSH 认证一直失败。
排查方法是在 Windows 工作机上执行：
whoami输出结果形如desktop-abc123\alice_zhang，其中反斜杠后面的部分才是 SSH 连接时可用的用户名。把这个填到 Hermes Agent 的节点配置里，问题就解决了。
6.6 Hermes Agent 安装要登录网站怎么处理
这个情况我在前面的安装环节提到过，这里展开说。Hermes Agent 首次运行时，初始化流程会输出一个登录 URL，要求你在浏览器中打开并授权。如果在无桌面环境或被网络策略管控的服务器上，浏览器没法自动打开，需要手动处理。
正确做法是：在能访问外网的本地浏览器里打开终端输出的完整 URL，完成账号授权和 API 关联，然后终端会自动继续。如果连 URL 都访问不了，检查网络策略或代理配置，确保域名可以被正常解析和连接。
如果你用的是阿里百炼等兼容平台，确认 Hermes Agent 支持设置环境变量来指定模型平台的 Base URL 和密钥，否则默认会请求官方平台，导致初始化验证不过。我的建议是：先明确 Hermes Agent 版本支持的模型提供方，再决定是不是要额外配置环境变量，不要盲目照搬网上的命令。
7. 落地经验：这套方案现在怎么用最顺手
文章到这里，该讲的配置和步骤都讲得差不多了。最后分享几个我实际用下来觉得特别值得注意的经验，也算是给想快速落地的读者几条捷径。
第一，先用两台 Linux 机器练手，再引入 Windows 节点。Hermes Agent 多机编排的核心链路在纯 Linux 环境下最干净，SSH 配置、路径、环境变量都直来直去。等你把任务分发、结果回传这些基本流程跑顺了，再加入 Windows 节点，有前面的经验打底，排错时会快很多。
第二，把 Hermes Agent 的配置文件纳入版本管理。config.yaml和 SSH 公钥是整套编排的核心资产，放进 Git 仓库，后续新增机器、调整参数都有了操作记录。但私钥文件绝对不要进仓库，用.gitignore排除掉。我给每个节点都打了标签，比如win11-node、linux-node，后续写任务指令时直接引用标签名，不用记 IP。
第三，善用hermes doctor做每次环境变更后的自检。凡是改过 SSH 密钥、Claude Code 版本、节点 IP 里的任何一项，都跑一次hermes doctor，它能在 10 秒内告诉你当前所有节点是否可用，不用猜。
第四，Claude Code 的版本尽量保持所有节点一致。我有一次在 Windows 节点上升级了 Claude Code 到新版本，Linux 节点还是旧版本，结果同一个任务在不同节点上给出的结果风格不一致，排查了半天才发现是版本差异导致的。多机编排的前提是各节点能力对齐，版本是其中最重要的一环。建议把 Claude Code 版本写进 README，作为多机环境的基线配置。
最后再补充一点，这套方案本身是灵活的，不一定非要三个节点起步。哪怕你只有一台 Linux 服务器和一台 Windows 笔记本，用 Hermes Agent 统一调度也比手动来回切换 SSH 窗口舒服得多。跨平台开发本身考验的不是单一机器的性能，而是多机协作是否顺畅。把 SSH 通道打通、Hermes Agent 配置好之后，你会发现“多机开发”这件事终于不需要靠人肉切换来完成，所有任务在一个终端里就能搞定。
