Hermes Agent+SSH远程调度Claude Code：多机AI编码编排实战

先说结论：这套组合打完，我十几台开发机终于不用再逐台登录、重复配置，也不用靠聊天窗口传任务了。Hermes Agent 承担编排中枢，SSH 负责打通控制节点和各台工作机之间的安全通道，Claude Code 则作为真正干活的 AI 编码代理被远程唤起。三个角色各管一摊，配合起来能覆盖多机并行编码、远程审查、跨平台构建这类真实场景。如果你手里同时有 Windows、Linux、macOS 几套环境，或者团队里有人想统一调度 Claude Code，这篇文章就是按我踩过的坑写下来的。

1. 整体设计思路：为什么是 Hermes Agent + SSH，而不是其他方案

1.1 真实痛点：AI 编码助手被“锁”在了单机上

Claude Code 本身是一个跑在终端里的交互式编程代理，装在哪台机器上，它就只能访问哪台机器的文件系统、执行哪台机器的命令。这带来一个很实际的问题：我在本地 Mac 上调试好的一套提示词、配置、项目上下文，换到 Windows 工作机上就全不认了。项目还没跨机器，脑子先得跨一次。

更麻烦的是多机并行。一个仓库拆成几个模块，我想同时让两台机器分别处理订单模块和库存模块，就得开两个终端窗口，分别登录两台服务器，手动把任务粘贴进去。任务跑完没有统一收口，结果散落在各个屏幕里。时间一长，哪个任务成功、哪个失败、失败原因是什么，根本没法追溯。

还有一个隐蔽痛点：Claude Code 的会话和配置默认存在用户目录下。团队里不同人用同一台构建机时，一旦 A 的配置覆盖了 B 的目录，要么登录态失效，要么模型参数被改掉，排查起来相当费劲。这些问题的根源都一样：缺少一个能统一管理“在哪台机器上、以什么身份、执行什么 AI 任务”的调度层。

1.2 三层架构拆解：编排层、通道层、执行层

我最终采用的方案是很朴素的三层结构。

第一层是编排层，也就是 Hermes Agent。它负责维护任务队列、记录每台工作机的状态、把任务拆成可执行命令并下发，最后回收执行结果。你可以把它理解成一个“任务管家”：真正写代码的人不是它，但它知道把活派给谁、什么时候派、怎么汇总。

第二层是通道层，SSH。控制节点和工作节点之间所有通信都走 SSH 协议。选 SSH 不是因为多高深，而是因为它足够通用：Linux 和 macOS 自带服务端，Windows 也可以装 OpenSSH Server 或 Bitvise SSH Server，客户端更是全平台覆盖。密钥认证配好之后，控制节点可以免密登录任意工作机，批量执行命令就像在本地一样。

第三层是执行层，Claude Code。它必须安装到每台工作机上，作为实际执行 AI 编码任务的进程被唤醒。Hermes Agent 并不会替 Claude Code 做决策，它只负责通过 SSH 把任务文本传过去，然后启动一个claude -p的非交互进程来干活。这样做的优势是：Claude Code 的所有能力都被保留，远程调度只是换了一个启动方式。

1.3 方案选型对比：为什么不直接用 MCP 或 tmux

有人会问，Claude Code 不是支持各种 Agent 连接方式吗，为什么还要套一层 SSH？我的观点是：MCP 适合在单机进程内扩展能力，解决的是“Claude Code 能不能访问某个工具”的问题；而我面对的是“多台物理机器上的多个 Claude Code 实例如何被统一控制”的问题，这属于进程编排和资源调度，不是 MCP 协议擅长的事。

还有人会用 tmux + SSH 手动管理：先登录每台机器，开几个 tmux 窗口跑 claude，再用 SSH 粘过去看输出。这套方案在只有两三台机器时能用，但一旦任务多了，会话列表管理、超时清理、结果结构化返回都会变成体力活。Hermes Agent 的价值就是把这一层自动化：任务失败自动重试，结果按任务 ID 归档，worker 状态集中可见。它不会替你写出更好的代码，但能让你从“人肉运维多台终端”里解放出来。

1.4 执行层为什么选 Claude Code 而不是 Codex

执行层这个小节值得单独说。我也试过直接用 Codex 来做远程编码代理，它的模型能力没话说，但在我这个场景里有两个问题：一是它的 CLI 在无头环境下的批量、非交互调用方式不如 Claude Code 顺手；二是我需要跨平台统一调度的工具链，Claude Code 通过 npm 安装，Windows、Linux、macOS 三套系统命令一致，而 Codex 在某些发行版上的依赖配置要额外处理。

另外 Claude Code 支持-p（print）非交互模式，可以传入单条任务指令，配合--output-format json拿到结构化输出。这个能力对编排系统极其重要：Hermes Agent 不需要解析人类可读的终端文本，直接吃 JSON 就够了。所以我的取舍很简单：Herman Agent 做大脑，SSH 做神经网络，Claude Code 做手和脚。

2. 环境准备：控制节点与工作节点的部署

2.1 Hermes Agent 本地部署的正确姿势

Hermes Agent 的部署方式我这里以自己用的版本为例。它支持 Docker 和本机直接运行两种方式，我更推荐在控制节点上用本机运行，因为调度任务时经常要读取本地的密钥文件和配置目录，容器方式还得额外挂载，稍微麻烦一点。

部署时先确认控制节点的系统环境。我用的是 Ubuntu 22.04 作为控制节点，执行安装脚本或者拉取可执行文件后，第一件事不是急着配置，而是先初始化配置目录。启动之后，一般会在用户目录下生成一个配置文件夹，里面至少包含一个主配置文件、一个存放 worker 信息的目录、一个存放任务运行日志的目录。我习惯把日志单独放到/var/log/hermes并做按天轮转，因为编排系统跑起来之后，日志量会比想象中大很多。

Windows 上也有便携版，解压即用，适合临时把某台 Windows 机器当控制节点。但我个人还是倾向让 Linux 机器当控制节点，因为后续要写批量脚本、处理定时任务，Linux 下的工具链更成熟。Windows 节点更适合作为被调度的 worker，而不是调度方。

2.2 各工作机上安装 Claude Code

Claude Code 的安装相对简单，前提是每台工作机上都有 Node.js 18 以上版本。安装命令是 npm 全局安装：

npm install -g @anthropic-ai/claude-code

装完先手动执行一次claude，完成登录认证。这一步必须在工作机本机上做，因为认证信息会写进当前用户的配置目录。如果你想隔离不同项目的配置，可以通过环境变量指定独立的配置目录，比如：

export CLAUDE_CONFIG_DIR=/data/claude-config/project-a claude

这一点在多机编排时非常关键。如果所有任务共用同一个配置目录，不同项目的模型参数、MCP 插件配置会互相污染；我的做法是一个项目一个配置目录，Hermes Agent 下发任务时把对应的CLAUDE_CONFIG_DIR一起带过去。

Windows 上的安装有几点需要注意。首先确认 npm 全局 bin 目录在 PATH 里，否则远程执行claude会提示命令找不到。其次 Windows 默认 PowerShell 的执行策略可能会拦截 npm 生成的脚本，需要调整执行策略或者在 Hermes Agent 里给 Windows worker 指定 shell 为powershell.exe -ExecutionPolicy Bypass -Command。

2.3 SSH 服务端选型：Windows、Linux、macOS 三平台对照

SSH 服务端的选择直接决定你后面省不省心。我用下来的对照关系是这样的：

Windows 上如果只是临时用，我建议直接启用 Windows 自带的 OpenSSH Server，在“可选功能”里添加，然后把服务设为自动启动。追求管理便捷、要多用户虚拟账户映射的话，再考虑 Bitvise SSH Server。不过要注意，Bitvise 默认的权限模型和 OpenSSH 的 authorized_keys 有差异，如果用 Hermes Agent 统一走 OpenSSH 风格的密钥认证，还是推荐 Windows 自带方案，少一层适配。

所有工作机的 SSH 服务端配好后，先在本机用密码登录一次，确认能通，再进入下一步密钥配置。这一步别跳，很多后面看似诡异的问题，根源就是服务端连密码登录都没开。

3. 多机编排的命门：SSH 密钥体系与通道打通

3.1 专用密钥比默认密钥更省心

很多教程上来就让你用~/.ssh/id_rsa作为编排密钥，我强烈不建议。原因很简单：权限粒度。控制节点可能同时连生产服务器、测试机、同事的电脑，如果把个人默认密钥当作调度凭证，一旦泄露，所有机器都暴露了。正确做法是单独生成一把只用于 Hermes Agent 调度的密钥，权限收窄，出现风险时可以单独吊销重换。

我生成密钥用的是 ed25519 算法，性能好、长度短、安全性足够：

ssh-keygen -t ed25519 -C "hermes-agent-overseer" -f ~/.ssh/hermes_ed25519

生成后不要设置 passphrase。不是说安全不重要，而是在编排场景下，Herman Agent 需要免交互地加载私钥，如果加了 passphrase，每次 SSH 连接都会卡在密码输入上。真要加固私钥，应该靠控制节点本身的文件系统权限和系统账户安全，而不是给私钥加口令。

3.2 公钥分发与权限检查（最常见翻车点）

密钥生成的下一步是把公钥写入每台工作机的authorized_keys。最简单的命令是ssh-copy-id，Linux 和 macOS 上都有：

ssh-copy-id -i ~/.ssh/hermes_ed25519.pub dev@192.168.1.21

Windows 工作机没有ssh-copy-id命令，可以手动追加：

cat ~/.ssh/hermes_ed25519.pub | ssh dev@192.168.1.22 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

后面这个命令在 Windows 的默认 shell 下可能不生效，因为cat >>在 PowerShell 里不是这个语义。我在 Windows 工作机上更推荐用 PowerShell 执行：

$key = Get-Content $env:USERPROFILE\.ssh\hermes_ed25519.pub Add-Content $env:USERPROFILE\.ssh\authorized_keys $key

公钥传上去之后，权限检查是绕不开的坑。Linux 和 macOS 上，~/.ssh目录权限必须是 700，authorized_keys必须是 600，多一个组可写权限 SSH 都会拒绝加载公钥。我遇到过太多次Permission denied (publickey)，最后发现是authorized_keys是 664。执行下面这条命令修复：

chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys

3.3 连接复用与批量连通性验证

所有工作机的公钥分发完成后，先在控制节点上写一个批量验证脚本，确认每台机器都能免密登录。脚本内容不复杂，核心就一句话：

for host in dev-linux dev-win dev-mac; do ssh -i ~/.ssh/hermes_ed25519 -o ConnectTimeout=5 -o BatchMode=yes hermes@$host "hostname && claude --version" done

这个-o BatchMode=yes参数很关键，它会让 SSH 在需要交互输入密码时直接失败，而不是卡住等待。批量任务一旦有一个节点卡在密码输入上，整个编排任务都被拖死。

连接量比较大的时候，一定要开启 SSH 连接复用。默认情况下，SSH 每次连接都会重新做一次密钥交换和握手，对于短命令批量调度，握手时间甚至比命令执行时间还长。我在控制节点的~/.ssh/config里加了这段：

Host dev-* IdentityFile ~/.ssh/hermes_ed25519 ControlMaster auto ControlPath ~/.ssh/control-%r@%h:%p ControlPersist 10m

这样第一个连接建立后，后续连接直接复用同一个 TCP 通道，批量调度几十台机器时速度提升非常明显。

3.4 在 Hermes Agent 中登记 worker 节点

通道打通之后，下一步就是把各工作机登记进 Hermes Agent。我用的是配置文件方式，在配置文件的 workers 段里逐台声明。每台 worker 至少包括三部分信息：连接地址、SSH 身份、远程 shell 类型。shell 类型必须明确，因为后面下发命令时要决定用 bash、sh 还是 powershell 来包一层。

我常用的简化配置长这样：

workers: - name: linux-build host: 192.168.1.23 user: hermes identity: ~/.ssh/hermes_ed25519 shell: bash - name: win-dev host: 192.168.1.24 user: hermes identity: ~/.ssh/hermes_ed25519 shell: powershell - name: mac-mini host: 192.168.1.25 user: hermes identity: ~/.ssh/hermes_ed25519 shell: zsh

登记完先跑一个 worker 自检，确认 Hermes Agent 能通过 SSH 连上所有节点并拿到基础信息。这一步跑不通就继续排查 SSH，跑通了再开始下发任务，省得后面任务失败时还得判断是通道问题还是任务本身问题。

4. 实操：SSH 远程调度 Claude Code 跑跨平台任务

4.1 第一步：单台机器上跑通第一个远程 AI 任务

不要一上来就玩多机并行，先在单台机器上把链路完整跑通。我在 Hermes Agent 里定义了一个最简单的任务：让远程 Linux 构建机扫描指定目录里的 TODO 注释，生成一份文档。任务定义大致如下：

tasks: - name: scan-todo-linux worker: linux-build command: | cd /data/repos/order-service && CLAUDE_CONFIG_DIR=/data/claude-config/order-service \ claude -p "请扫描 src/ 目录下的所有 TODO、FIXME 注释，汇总输出到 docs/todo.md" \ --output-format json

然后通过 Hermes Agent 触发执行。关键点在于：目标机器上必须已经安装并且认证过 Claude Code，否则远程执行时claude命令不存在，或者需要交互登录，任务直接就卡住了。所以我一直强调，工作机上的 Claude Code 要在配置阶段手动跑一次，把登录态准备好。

第一次跑通时，注意看返回结果里是否带了--output-format json的结构化内容。如果能看到 JSON，说明远程执行链路已经没问题了，后续可以放心做批量和并发。

4.2 多机并行：任务分发、并发控制与超时

单机跑通后，我开始把同一个仓库的不同模块任务分到不同机器上。比如订单模块在 Linux 构建机上改，前端仓库在 Windows 机器上动，模型评估脚本在 Mac mini 上跑。Hermes Agent 的任务定义里，每个 task 指定一个 worker，再整体设置并发数，避免同时把所有 worker 打满。

并发控制这块吃过一次亏。最开始我把并发数设得很大，结果 5 台工作机同时拉起 claude 进程，每台机器还有多个任务在跑，内存直接被打到 swap，任务全部超时。后来我把并发策略调整为每个 worker 同时最多只能跑一个任务，整体并行度通过跨 worker 控制。任务队列里再多的任务也只能排队进入，这样每台机器上的 Claude Code 都能稳定工作，不会因为资源争抢导致整机卡死。

超时设置也值得讲。AI 编码任务的执行时间波动非常大，短的可能几十秒，长的可能要跑十几分钟。我按任务类型区分超时：代码生成类给 10 分钟，大规模重构或测试补全给 30 分钟。Herman Agent 里对每个任务单独设置 timeout，超时后自动标记失败并记录日志，方便后续重跑或人工介入。

4.3 跨平台坑：shell 差异、路径差异、换行符

跨平台调度最难受的不是 AI 本身，而是三套系统之间的差异。第一个坑是 shell。Linux 用 bash，macOS 默认 zsh，Windows 的默认 shell 在不同 SSH 服务端下可能是 cmd 也可能是 PowerShell。我在 worker 配置里强制声明 shell，命令下发时用对应的 shell 执行。比如 Windows 节点上，所有命令都包一层powershell -Command，确保语法一致。

第二个坑是路径。Linux 的/data/repos/order-service，在 Windows 上就是D:\repos\order-service。我通常把仓库路径和 Claude Code 的配置目录设计成“按机器设置独立变量”。具体做法是，在 Hermes Agent 里给每个 worker 挂一组环境变量，而不是在任务命令里写死路径。这样同一份任务模板，分发到不同机器时自动替换成对应路径，任务定义里不出现任何硬编码的绝对路径。

第三个坑是换行符。我在 Windows 工作机上执行 bash 风格的多行命令时，遇到过\r导致命令解析失败的问题。解决方法是：跨平台任务的命令尽量写成单行，或者写成独立脚本文件，先通过 scp 推送到目标机，再远程执行这个脚本。这比在命令行里拼一堆引号和转义要稳得多。

4.4 结果回传与日志聚合

任务执行完，结果不能留在工作机上，否则又要手动登录去看。我让 Hermes Agent 在每个任务完成后，自动回收两个东西：命令的标准输出，以及生成的产物文件列表。

标准输出的回收很简单，执行完后把返回内容写进按任务 ID 命名的文件里，统一存到控制节点的日志目录。产物文件的处理稍微复杂些。比如远程让 Claude Code 生成了一份review.md，脚本需要在任务命令最后显式执行一次回传：

scp -i ~/.ssh/hermes_ed25519 /data/repos/order-service/review.md hermes@overseer:/var/lib/hermes/artifacts/20250115-review.md

早期我偷懒只回收标准输出，结果 Claude Code 明明在远程生成了文件，我却看不到内容，还得手动登录确认，多机编排的体验直接打对折。现在我的原则是：凡是任务中可能产生文件的地方，都在命令里显式回传。

日志聚合我放在最后一步。Hermes Agent 自带的任务日志只记录了调度的生命周期，比如开始时间、结束状态、退出码。Claude Code 进程本身的详细输出，我要求通过--output-format json落到标准输出，再被 Hermes Agent 回收。这样每个任务的完整轨迹都能在控制节点上查询，出问题时不用逐台机器翻日志。

4.5 连接 VSCode Remote-SSH：人工兜底与图形化

全自动调度再香，也总有需要人工介入的时候。比如 Claude Code 在某个 PR 上产生了歧义，需要打开具体文件看上下文。这时候我会用 VSCode 的 Remote-SSH 插件直接连到对应工作机，图形化界面里查看文件树、diff、终端状态。

Hermes Agent 跑完一个任务后，会生成一个结果链接，里面包含机器名、项目路径、产物文件路径。我在 VSCode 里新建 Remote-SSH 窗口，用同一把密钥连上去，直接打开那个路径，就能在编辑器里继续人工 review。这一步不算优雅，但胜在可靠，是全自动流程和人工审查之间的缓冲带。

另外一些特别复杂的任务，比如涉及大量交互式确认的代码重构，我干脆不自动化。直接在 VSCode 里连上远程机器，打开对应目录，在集成终端里手动跑claude，需要确认时人工回答。我的经验是：能用-p全自动跑的，交给 Hermes Agent；需要反复确认的，保留人工交互入口。两者结合，既不牺牲自动化率，也不至于让 AI 卡在某个问题上空转。

5. 常见问题与排查实录

5.1 高频报错速查表

这一节把这些年遇到的高频问题整理成表，方便你排查时直接对照。

5.2 远程执行时命令被转义和引号地狱

远程调度 AI 任务和本地执行最大的区别在于：命令要经过本地 shell、SSH、远程 shell 三层解析。只要命令里出现引号、管道、特殊字符，就有被某一层错误拆分的风险。我在早期被这个问题折磨了很久，一个命令在本地明明能跑，通过 SSH 调过去就报错。

我的解决方案是三步走。第一，所有复杂命令不要写在任务定义的 command 字段里，而是单独写成一个 shell 脚本，比如scripts/remote-task.sh，提交到项目仓库。第二，Herman Agent 下发任务时，先通过 scp 把脚本推送到工作机，再远程执行bash /tmp/remote-task.sh。第三，脚本内部再调用 claude，这样格式问题只在脚本内部检查。

如果确实需要在命令行里拼多行命令，也要注意 SSH 命令参数本身是一个字符串。我习惯先在本机把命令用bash -n做语法检查，再通过 SSH 执行。这里有一个细节：配合set -euxo pipefail让远程脚本在任何一步失败时及时退出，避免一个命令失败后继续往下跑，最后拿到一个不完整的结果。

5.3 安全加固：别让编排入口变成攻击入口

Hermes Agent 控制节点一旦配置完成，相当于拿到了所有工作机的钥匙。这把钥匙如果丢了，所有机器都会沦陷。所以安全加固在我这里不是可选优化，而是必须做的。

首先，禁用工作机上的 SSH 密码登录，只保留密钥认证。编辑 sshd_config，设置PasswordAuthentication no，然后重启 sshd。这一步能挡住大部分暴力破解。其次，不要让 Hermes Agent 使用 root 或管理员账户登录，而是为每台工作机创建专用系统用户，权限只开放给它需要操作的项目目录和命令。比如 Linux 上我用hermes用户，配合 sudoers 里白名单放行少数命令，而不是直接给全部 root 权限。

第三个措施是限制来源。工作机上的 sshd 可以加AllowUsers hermes，只允许这个用户登录，再配合防火墙只在控制节点 IP 上放行 SSH 端口。我还见过有人直接在 sshd_config 里限制公钥来源：AuthorizedKeysCommand从统一平台拉取公钥，这样密钥轮换时不用逐台机器手动更新。这个方案适合团队规模较大的场景，我目前的状态是机器数量不多，用传统 authorized_keys 也能管理得过来。

最后，定期轮换编排密钥。我给自己定的周期是每三个月换一次，换的时候生成新密钥，分发到各工作机，然后从控制节点删除旧密钥。步骤繁琐，但考虑到这套系统掌握了多台机器的执行权限，这点麻烦值得。

5.4 我踩过的最大的几个坑

第一个坑是公私钥路径混淆。最初在 Hermes Agent 配置里把公钥路径写成了私钥路径，结果 SSH 直接报错。这类问题排查起来不复杂，但很消耗时间，后来我把密钥文件名起得非常明确，比如私钥id_ed25519和公钥id_ed25519.pub，配置时一眼就能看出问题。

第二个坑是没有对齐 Claude Code 的配置目录。有一次我在 Linux 构建机上跑任务，远程 claude 用的模型和我预期的不一样，折腾了很久才发现工作机的CLAUDE_CONFIG_DIR指向了另一个项目的历史配置。从那以后，我在每个任务命令开头都显式声明CLAUDE_CONFIG_DIR，不让 claude 用默认路径，从源头避免配置串号。

第三个坑是 Windows 工作机的 PATH 问题。npm 全局安装的 claude 放在%APPDATA%\npm下，这个目录不一定在系统 PATH 中。远程通过 PowerShell 执行时，如果 PATH 没加载，就会提示找不到 claude。我在 Windows worker 的任务命令里固定写全路径，或者先把 npm prefix 加到 worker 的环境变量里。这个坑很隐蔽，因为你在 Windows 机器上手动打开 PowerShell 时 PATH 是正常的，但通过 SSH 非交互登录时加载的环境变量可能不完整。

最后是控制节点磁盘回收问题。日志和产物默认全部堆积在控制节点，跑一段时间磁盘就满了。我现在给日志目录写了按天轮转，产物目录只保留最近 7 天，再用 cron 定期清理任务结束后留下的临时文件。编排系统本身就容易产生大量中间文件，尽早把清理机制做好，后面能省很多事。

这套“Hermes Agent 多机编排 + SSH 远程调度 Claude Code”的方案，说到底不是某个单个工具的魔法，而是把三个环节串起来之后产生的规模效应。我在实际使用中最大的体会是：先把 SSH 通道和使用方式练熟，再上编排调度，会顺手很多。编排系统确实方便，可一旦通道不稳定或者权限混乱，它带来的麻烦也成倍放大。如果你手头已经有多台开发机，建议先从两台机器开始把心跳、密钥、单任务跑通，再去扩展规模。调度层带来的收益，是在机器数量和处理规模上来之后才能真正体现出来的。