如果你手上有两三台电脑一台主力开发机、一台常开的 Linux 服务器偶尔还有一台 Windows 工作站或 MacBook 需要参与构建那你大概率遇到过这种尴尬代码在自己机器上跑得好好的一放到对面机器就环境崩、路径错、还要手动开个终端敲命令。更要命的是想让 Claude Code 在每台机器上都跑一遍代码审查、测试生成、文档整理这类事情手动挨个登录再粘贴提示词一套流程下来半小时没了。我最近把这三件事串在了一起用 Hermes Agent 做主控通过 SSH 远程调度各台机器上的 Claude Code实现跨平台开发任务的批量下发和结果回收。整体的思路不复杂就是“一台主控多台执行机”但真正落地的时候涉及环境安装、免密链路、安全加固、非交互执行、结果汇总这一整套流程踩坑不少。这篇文章就围绕这套“Hermes Agent SSH Claude Code 多机编排”方案把从架构设计到日常排障的完整过程写出来给想搞多机 AI 编码流水线的朋友一个可复用的参考。1. 多机编排的整体设计一次把三样东西串起来1.1 为什么要做多机编排先说清楚这个方案解决的到底是什么问题。Claude Code 本身是一个跑在终端里的 AI 编程代理你给它一个任务描述它能在本地读取代码、修改文件、执行命令、跑测试最后交付结果。单机使用已经很强了但一旦你的开发环境分散在多台机器上就会出现几个很现实的需求平台差异化验证前端工程需要在 macOS 上打包后端服务要在 Ubuntu 上跑测试Windows 环境要验证兼容性这些任务天然分布在不同的物理机器上。资源隔离与额度控制Claude Code 的会话额度和执行环境是相互独立的把任务拆到不同机器上既能避免单机排队也能让每台机器各司其职。环境一致性保障有些依赖在特定系统上才装得起来比如某些 Windows 下的原生库你在 macOS 上再怎么折腾也复现不了不如直接调度到目标机器上去执行。但问题也随之而来每次都手动 SSH 登录、粘贴提示词、等结果再复制回来这件事一旦变频繁就没法忍。于是就有了编排层——也就是 Hermes Agent 这类工具存在的意义。1.2 架构角色主控端、执行端、协调器整套架构里其实只有三类角色画出来非常简单角色部署位置承担工作主控端日常使用的开发机或内网服务器运行 Hermes Agent负责任务拆分、SSH 调度、结果汇总执行端各台目标机器Linux / Windows / macOS运行 sshd执行远程收到的命令调用已安装的 Claude Code链路主控到各执行机的 SSH 通道负责加密通信、免密认证、命令传输为什么选择 SSH 而不是自己写一套通信协议核心原因是它到处都是现成的。Linux 和 macOS 自带 sshdWindows 10 以后也内置了 OpenSSH Server打开一个功能开关就能用。只要能通 SSH你就能以系统用户的身份做任何事包括启动 Claude Code、读写文件、执行构建脚本。相比起维护一套 agent 间自有的消息通道SSH 的学习成本最低、排障手段最丰富、也最不需要额外引入中间件。Hermes Agent 在这里的角色是“协调器”它不替代 ssh 命令而是把你手动操作终端的过程固化下来定义好“在哪些机器上执行什么命令”编排层负责分发和收集。这就像你不再亲自跑腿去每个工位找人干活而是设了一个调度台按任务单把工作分下去再把结果收回来登记。2. 环境准备把 Claude Code 装到每一台机器上2.1 Claude Code 的跨平台支持情况Claude Code 底层是 Node.js 应用所以凡是你装得了 Node 的地方基本都能跑。官方安装命令很稳定就是通过 npm 全局安装npm install -g anthropic-ai/claude-code我实际部署过的平台大概有这么几类Ubuntu / Debian 系最顺利Node 装好后直接安装即可唯一要注意的是系统默认源里的 Node 版本可能偏老建议用 nvm 装一个 18 或 20 以上的 LTS 版本。Windows直接装 npm 包会拿到 .cmd 包装脚本在 PowerShell 里输入claude就能启动。需要注意 OpenSSH 的默认 Shell 是 cmd 还是 PowerShell这直接影响远程命令的语法风格。macOSApple Silicon 机器上偶尔会遇到 Node 在 x64 和 arm64 之间切换的问题如果有其它工具把架构带偏了用node -p process.arch检查一下即可。国产化环境例如龙芯 MIPS 架构搭配麒麟系统这类环境下 OpenSSH 客户端与服务端都是现成的SSH 协议没有区别只是安装 Node 和 npm 包可能会遇到编译兼容问题需要先确认系统里有对应架构的预编译二进制或者在系统本地源中安装版本较新的 Node。跨平台部署的要点不是我写了什么而是要先把自己的硬件清单列出来。每台机器什么系统、什么 IP、有没有 Node、装没装 claude全部登记在案后面配置起来才不会乱。2.2 安装与登录那些容易踩的坑我在 Windows 上踩过的第一个坑是安装成功后提示claude: 无法加载文件 ... 因为在此系统上禁止运行脚本。这是 PowerShell 执行策略的问题Claude Code 装好之后通过 claude 启动时用管理员 PowerShell 调整一下策略即可Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser另一个常见问题就是登录。新机器上第一次运行claude会进入浏览器授权流程服务端生成的认证信息会写到用户目录下的~/.claude目录里。如果发现登录后桌面端或终端端反复卡在账号界面多数情况下是认证目录的读写权限出了问题或者当前用户环境变量没有正确指向家目录。还有一个小技巧如果你所在网络的出口需要走特殊的合规网关Anthropic 官方允许通过环境变量来指定 API 端点和密钥。对团队来说把密钥放进环境变量而不是敲进终端里后面做远程调度会安全得多因为 SSH 命令在进程列表里是可见的直接拼在命令行里容易被同机用户看到。2.3 Hermes Agent 部署主控端放什么Hermes Agent 的部署我放在了主控机器上。它本身是一个可以本地运行的服务既能以普通命令行方式启动也能做成守护进程常驻。我自己的习惯是放到 Docker 容器里跑把配置目录和日志目录挂载出来好处是不污染宿主机环境、升级方便、重装系统也不影响配置。主控端配置里最关键的是“机器清单”和“任务模板”这两块。机器清单里登记了各执行端的主机名、IP、SSH 端口、用户和认证方式任务模板则定义了某类任务要在哪台机器上跑什么命令。举个例子我要在所有机器上运行同一个代码审查任务模板会展开成若干个 SSH 命令分别推送到目标机器。这一层配置写好后日常就只需要写“任务描述”不需要再关心机器差异。3. SSH 免密链路搭建与安全加固3.1 从密钥生成开始多机编排最重要的基础设施是免密登录。没有免密的话Hermes Agent 每次执行远程命令都要输入密码根本没法自动化。密钥认证的配置方式很成熟分三步走生成密钥对ssh-keygen -t ed25519 -C hermes-operator -f ~/.ssh/hermes_ed25519之所以选择 ed25519是因为它比 RSA 密钥更短、生成更快、安全性也足够。对老设备兼容性有要求的场景可以再保留一把 RSA 密钥ssh-keygen -t rsa -b 4096 -C hermes-operator-rsa -f ~/.ssh/hermes_rsa分发公钥到各执行机Linux 和 macOS 上有现成的ssh-copy-idWindows 上用 Git Bash 也能调用ssh-copy-id -i ~/.ssh/hermes_ed25519.pub userexec-host如果执行机是群晖这类 NAS或者其它没有ssh-copy-id的系统手动追加到~/.ssh/authorized_keys也是一样的效果。测试免密登录ssh -i ~/.ssh/hermes_ed25519 userexec-host echo ok这一条通了后面的编排链路就成功了一大半。3.2 用 config 文件管理多台机器机器多了以后我不建议每次写完整命令推荐在~/.ssh/config里把每台机器都命名好。下面是我的配置片段Host build-linux HostName 192.168.1.21 User ubuntu Port 22 IdentityFile ~/.ssh/hermes_ed25519 Host build-win HostName 192.168.1.22 User admin Port 22 IdentityFile ~/.ssh/hermes_ed25519 Host build-mac HostName 192.168.1.23 User dev Port 22 IdentityFile ~/.ssh/hermes_ed25519这样配置完之后主控端调度时可以直接用ssh build-linux ...这样的短主机名。它的好处不只是少打几个字而是让 Hermes Agent 的配置里不需要出现 IP、用户名、密码这些细节统一由 SSH 客户端去解析。以后某台机器换了 IP只需要改一处配置编排层完全不用动。另外如果机器分布在不同的内网或跨地域可以考虑用 Tailscale 这类组网工具把各台机器放到同一个虚拟内网中让它生成的内网 IP 走 SSH 链路。这样做的好处是无需在公网暴露 22 端口很多安全风险在源头就规避掉了。3.3 顺手把 Git 仓库认证也解决多机开发的常见场景是远程机器需要拉取私有 Git 仓库然后才能执行构建或测试。这里我通常会复用刚才生成的那把公钥把它添加到 GitLab 或 GitHub 的 SSH Keys 里。这样一来执行端机器拉取仓库的时候就不再需要单独配账号密码相当于一次密钥分发同时解决了 SSH 登录和 Git 认证两件事。我见过不少人把 Git 仓库的私钥单独复制到每台机器上这种做法没有必要反而扩大了私钥泄露面。更合理的做法是让各执行机共用主控生成的这把专用身份密钥或者每台机器单独生成密钥然后把各自的公钥加到 Git 平台的同一账号下。前一种适合临时搭建的环境后一种适合人员固定的团队。3.4 安全加固别让编排链路变成后门SSH 免密虽然方便但风险也随之升高。一旦有机器被入侵攻击者可能通过私钥横向移动。所以我强烈建议在做编排前先把 sshd 的安全基线打一遍在/etc/ssh/sshd_config中关闭密码登录PasswordAuthentication no关闭 root 直接登录PermitRootLogin no限定允许登录的用户AllowUsers hermes ubuntu admin必要时在防火墙层面限制来源 IP只允许主控机的 IP 访问 22 端口改完配置记得重启服务sudo systemctl restart sshd如果机器直接暴露在公网日志里出现大量连接尝试几乎是必然的。遇到这种情况不要慌先看日志journalctl -u ssh --since 1 hour ago | grep Failed password | wc -l或者grep Failed password /var/log/auth.log | wc -l数量很大的话建议装一个 fail2ban 做自动封禁。配置其实很简单把 maxretry 设为 5、bantime 设为 1 小时即可。再加上我们前面已经关闭了密码登录基本上就能把这类暴力破解挡在门外。4. 实战编排用主控机远程调度 Claude Code 干活4.1 先定义一组真实的任务集理论说多了没用我拿一个典型的跨平台开发日出来举例。假设你在做一个桌面端应用前端的核心代码在 GitLab 仓库里目标是要提交一个稳定的测试版本需要完成下面这些事主控机开发机让 Claude Code 对整个项目做静态代码审查找出潜在的逻辑问题和安全隐患Ubuntu 执行机构建后端模块跑完整的单元测试和集成测试输出测试报告Windows 执行机在当前代码上打一个 Windows 安装包macOS 执行机在 macOS 上验证 UI 的兼容性收集控制台日志如果没有编排这一套流程需要人工逐个登录、手动敲命令、等结果、把报告拷回来。有了 Hermes Agent主控端只需要定义一个任务清单然后逐项调度。下面的伪代码把调度逻辑表达得很清楚# hermes_flow.py tasks [ {host: local, command: claude -p \审查整个项目的代码质量输出问题列表\ --output-format json}, {host: build-linux, command: cd /data/app claude -p \运行 make test 并汇总测试报告\ --output-format json}, {host: build-win, command: cd C:\\app claude -p \执行 build.ps1 生成安装包\ --output-format json}, {host: build-mac, command: cd ~/app claude -p \运行 UI 兼容性检查并输出日志\ --output-format json}, ] for t in tasks: if t[host] local: run_local(t[command]) else: run_ssh(t[host], t[command])实际项目里我会把这些命令封装到 Hermes Agent 的配置模板里不直接在代码里写死。模板的好处是任务参数可以随时随地改不需要重新部署编排服务。4.2 远程驱动 Claude Code 以非交互方式执行Claude Code 在交互式终端里的体验很好但在远程调度场景下我们必须让它以“非交互、一次性”的方式执行任务。这就像平常写代码是一行一行敲 REPL但脚本化的场景需要让程序跑完返回结果。Claude Code 提供了类似-p也就是 print 模式的参数配合--output-format json可以得到结构化输出方便后续解析。一个典型的命令长这样claude -p 分析当前目录下的 API 接口设计列出需要改进的地方 --output-format json执行完成后当前终端就能拿到一段 JSON 格式的结果。在远程机器上这个结果会通过 SSH 的 stdout 传回主控端主控端负责保存到日志文件或者做进一步处理。需要注意的一点是非交互模式下 Claude Code 不会像交互模式那样自动加载你在终端里配置的上下文所以提示词要写得足够完整。我一般的做法是在提示词里明确“你现在要读哪个目录、关注哪类文件、输出什么格式”这样远程任务的成功率要高很多。4.3 日志回收与结果汇总命令执行完结果在远端机器的 stdout 里怎么收回来最简单的办法是把远端命令的输出重定向到文件然后用scp或rsync拉回主控端。例如ssh build-linux cd /data/app claude -p ... /tmp/report.json 21 scp build-linux:/tmp/report.json ./results/linux-report.json如果执行机的数量和任务频率都上来了我更推荐每家机器上挂一个共享目录例如用 NFS或者直接用rsync把结果同步到主控机。归档目录里按“日期/机器名/任务名”来组织过了一两周还能回溯某天某台机器上某个任务跑出来的结果。你的执行机上如果接入了像 MinIO 这类的对象存储也可以让 Claude Code 命令执行完以后直接把结果推到对象存储这样主控端就只关心任务下发不需要维护一堆本地文件。这两种方案各有优劣内网场景用 rsync 最省事跨网场景还是对象存储更靠谱。5. 实际问题排查与避坑记录5.1 SSH 连不上、卡慢、密钥无效远程调度遇到的第一类问题基本都是 SSH 层面的。我按出现频率排一下第一Ubuntu 上 SSH 连不上。先确认 sshd 装没装、跑没跑systemctl status sshd如果没装先安装并在防火墙里放行 22 端口sudo apt install openssh-server sudo ufw allow 22/tcp第二密钥无效、一直提示输入密码。多数情况不是公钥没放对而是权限不对。~/.ssh目录要是 700authorized_keys文件要是 600否则 sshd 出于安全考虑会忽略这个文件chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys第三Windows 上免密失效。Windows OpenSSH 对管理员用户的authorized_keys路径有特殊处理它默认放在C:\ProgramData\ssh\administrators_authorized_keys而不是用户目录下的那个。如果普通用户没问题、管理员连不上八成就是这个原因。第四老设备提示密钥算法不支持。尤其是一些老交换机、老 NAS它们只支持 ssh-rsa 算法而新版 OpenSSH 默认启用了更严格的算法选择ssh -o HostKeyAlgorithmsssh-rsa -o PubkeyAcceptedAlgorithmsssh-rsa userold-device这种兼容性问题不需要写入全局配置在~/.ssh/config里单独为那台设备加参数即可。5.2 Claude Code 登录、安装、桌面端卡登录远程执行claude之前一定要先在目标机器的交互终端里完成至少一次登录授权。这个授权动作通常是一次性的认证信息会保存在用户目录下后续 SSH 免密进来直接复用不需要重复登录。但我在实践里遇到过两类麻烦。一类是 Windows 上装完 claude 后找不到命令这通常是 npm 全局目录没有加入系统的 PATH。解决方法是把npm config get prefix里显示的目录加进用户环境变量然后重开终端。另一类是登录流程卡住。如果你是在远程机器上跑claude弹出的浏览器授权链接属于本机流程你用 SSH 进去以后没有默认浏览器登录就可能卡在某个空白页面。解决办法是在本机执行一次授权再把认证目录里的关键文件同步到远程机器的对应路径下或者直接在 SSH 会话里显式设置 API 密钥相关的环境变量绕过浏览器登录。这个方法对 VSCode Remote SSH 场景同样适用——先确保远程环境里能正常读到认证信息和环境变量内置的 codex 或 claude 登录才能顺顺利利。5.3 远程执行时的环境变量与路径坑SSH 非交互登录和交互登录最大的区别在于它不加载.bashrc里和环境变量相关的一部分内容。这就导致明明你在交互终端里能跑起来的命令通过 SSH 执行时提示command not found。解决方式有两种。一种是在远端命令里手动加载环境ssh build-linux source ~/.bashrc claude -p ...另一种是把环境变量写入/etc/environment或用户的~/.profile这样即使非交互登录也能读取到。需要注意的是Windows 上的 SSH 默认 Shell 如果是 cmd则环境变量用%VAR%而不是$VAR而在 PowerShell 里是$env:VAR。这些差异只有在真正踩到的时候才会意识到有多痛。路径分隔符也是跨平台调用中的高频坑。我在 Windows 执行机上推送命令时目录分隔符用的是C:\app但同一段命令如果直接拿到 Linux 上跑就完全无效。解决方案是把任务模板做成“平台相关”的或者干脆在每台机器上放一个独立的本地脚本Hermes Agent 只负责触发远端脚本不关心脚本内部写的什么路径。这个思路我用了很久非常省心。5.4 网络攻击与大量 SSH 连接的处理如果你把执行机的 22 端口暴露到公网日志里出现大量连接尝试是常态我最高纪录是一天看到两万多次 Failed password。这种情况下免密认证本身已经挡住了绝大多数攻击但你仍然应该做这几件事修改 sshd 监听端口到非默认端口比如 2222能挡掉一大片扫描流量启用 fail2ban配置好忽略名单和自己的主控 IP在云安全组或防火墙里限制源 IP只允许主控机器的 IP 访问 SSH 端口千万不要图省事开放/0的 22 端口访问。多机编排链路的安全性很大程度上取决于最弱的一环管好 SSH 入口整条链路就稳了一大半。5.5 我所使用的最终任务模板示例最后放一个当前正在用的 Hermes Agent 任务模板片段仅供参考。这个模板把“目标机器”和“要执行的提示词”拆开日常新增任务只需要改提示词task: name: daily_code_review steps: - host: local prompt: 对当前目录下的代码做一次架构审查重点关注异常处理和并发问题 - host: build-linux prompt: 进入 /data/app运行测试套件把失败用例列表输出成 JSON - host: build-win prompt: 运行项目根目录的 build.ps1检查是否能够生成安装包输出构建日志的尾部执行时Hermes Agent 会逐台机器发起 SSH 连接每台机器上调用 Claude Code 完成本地工作然后把输出结果统一聚合并写回主控端的日志目录。这套流程稳定跑下来以后我个人的体会是多机编排真正的复杂度不在机器数量而在于“链路不可见”。只要 SSH 能通、命令能跑、日志能回来剩下的事情其实都是时间问题。如果你也想动手试建议不要一上来就搞五台机器先拿“本机 一台 Linux 执行机”练手跑通“远程让 Claude Code 审查代码并把 JSON 结果收回来”这一条完整链路再逐步加机器。这条路我替你踩过值得走。