如果你和我一样日常要在本地、服务器、NAS 甚至机房老旧的几台机器之间来回切环境还要折腾 AI 编程助手那你大概率会遇到这个问题本地机器算力不足、不同项目散落在不同主机上、远程机器上根本没有图形界面连跑个 Claude Code 都要先想办法连上去再配环境。我前阵子折腾了一套基于 Hermes Agent 的多机编排方案通过 SSH 把远程机器全部纳管起来再用 Claude Code 做跨平台开发调度实测下来整个工作流顺了不少。这篇文章就把我踩过的坑、整理出来的完整操作流程和关键配置一起放出来。1. 多机编排的架构设计思路1.1 为什么需要 Hermes Agent 来做多机调度先明确一个前提这里说的多机编排不是 DevOps 里那种 Kubernetes 容器调度而是偏个人的开发与自动化场景我自己手上有一台 Windows 办公机、一台跑着 Linux 的服务器、一台群晖 NAS还有几台吃灰的旧笔记本偶尔要帮朋友处理点代码。每台机器配置不同、系统不同、环境也不同如果在每台机器上都手动装一遍依赖、配一遍 SSH、再登录某个 AI 代码工具那基本可以预见会有多痛苦。Hermes Agent 在这里的角色更像一个遥控器或调度中枢。它本身是一个开源的自动化智能体框架支持加载不同的模型服务也能对接本地的代码生成工具。真正让我决定用它做多机编排的原因有三个一是它的 agent 声明式配置相当直观把每台远程主机的访问方式、工作目录、常用命令写成一个配置文件即可二是它原生支持通过子进程调用外部的 CLI 工具比如 Claude Code这就等于让 Hermes 能够远程把任务派发给 Claude Code 去执行三是它支持任务队列和简单的异步调度在有多个远程节点时我可以把一个多文件的重构任务拆成几份同时丢给不同机器处理。如果你只是在一台机器上用 Claude Code 写代码那完全不需要 Hermes Agent但一旦你把写代码这件事扩展到多台机器比如服务器上跑测试、NAS 上做备份、旧笔记本当编译节点手动 SSH 加复制命令就会成为最大的时间黑洞。Hermes Agent 就是用来把这个过程固化成可复用代码的。1.2 整体拓扑控制端、执行端、远程代码环境我把整个架构分成三个角色来看第一层是控制端也就是你日常办公用的机器。在控制端上安装 Hermes Agent 和 Claude Code 的客户端用 Hermes 的配置文件定义好所有远程节点的元信息包括主机名、IP、SSH 端口、用户名、密钥路径、远程默认目录、使用哪个解释器执行 Python 等。第二层是执行端也就是所有参与任务的远程主机。执行端只需要具备两个条件能接受 SSH 连接并且装有运行时环境Python、Node.js 或 Docker 均可。执行端不需要安装 Hermes Agent因为调度指令完全由控制端通过 SSH 下发执行端只需要按指令干活然后返回结果。第三层是远程代码环境通常是被 git 管理的一个或多个项目仓库。我建议把仓库统一放在远程主机的某个固定路径下比如~/workspace/并且在 Hermes 配置中为每个节点指定workdir这样所有机器上的相对路径才能保持一致Claude Code 在分析代码时也不容易迷失方向。我实际使用的网络环境很普通不需要专线只要各台机器能互相通过 SSH 访问即可。这里需要格外注意SSH 连接只走标准的 22 端口或自定义端口整个数据链路没有用到任何额外通道这也是我推荐这个方案的核心原因简单、安全、不依赖任何第三方中转服务。1.3 为什么用 SSH 作为底层通道SSH 几乎可以说是运维和开发者的基础设施几乎每一台 Linux 服务器默认就开启了 sshdWindows 10 以后的系统也把 OpenSSH Server 做成了可选功能群晖的 DSM 系统也能在控制面板里一键开启 SSH。用 SSH 做底层通道有三个直接好处第一是认证足够简单。通过密钥对实现免密登录之后Hermes Agent 在调度时就不需要反复交互输入密码批量任务可以无人值守地跑完这在多机调度中非常关键毕竟你不会想在半夜爬起来给某台机器输入密码。第二是天然的加密安全。所有远程执行命令的内容都是加密传输的即使在某台机器上执行了敏感操作也不会以明文形式暴露在网络中。第三是兼容性极好。SSH 不仅支持 Linux 和 Windows也能连网络交换机、NAS、路由器等设备。这样一来我不仅可以用它调度开发任务还能顺便用它读取设备状态一举多得。2. 环境准备从零搭建 SSH 免密通道2.1 控制端与执行端的 SSH 环境检查在动手安装任何工具之前我先检查所有机器的 SSH 环境。这一步很简单但要细心。对于控制端 Windows 机器我建议到设置 - 应用 - 可选功能里确认是否有 OpenSSH Client如果没有就添加如果是 Windows 10 之前的旧系统可以考虑用 Git Bash 自带的 SSH或者直接安装 Bitvise SSH Client 这样的独立客户端。不过我还是推荐系统自带 OpenSSH因为 Hermes Agent 调用ssh命令时走标准 PATH 不容易出幺蛾子。如果是 macOS 或 Linux 控制端一般系统自带 SSH 客户端直接用即可。对于执行端 Linux 服务器先确认 openssh-server 是否安装并运行systemctl status sshd # 如果没有安装则安装 sudo apt install openssh-server # Debian/Ubuntu sudo yum install openssh-server # CentOS/openEuler对于群晖 NAS我通常是在 DSM 的控制面板 - 终端机和 SNMP里勾选启用 SSH 功能端口保持默认 22。群晖系统底层虽然是 Linux但合规起见我不建议直接改 root 登录创建一个专用账号并加入 ssh 组即可。对于 Windows 执行端如果你也想让其他机器反向连过来同样需要启动 OpenSSH Server 服务并在防火墙里放行 22 端口。我实际测试下来Windows 上的 OpenSSH Server 对密钥权限要求比较严格但基本功能没有问题。2.2 生成密钥对与批量分发公钥免密登录需要密钥对我在控制端先生成一对然后通过ssh-copy-id批量分发到所有执行端。生成密钥时我推荐三条建议用ed25519算法、设置必要的注释、不要偷懒不设 passphrase如果你是在自己的私有环境里也可以不设方便全自动调度。生成密钥的命令如下ssh-keygen -t ed25519 -C hermes-agent-multi-host -f ~/.ssh/hermes_agent_key这个命令会生成一对文件名带hermes_agent_key的密钥我可以这样刻意区分于日常使用的默认密钥避免搞混哪个 key 是给 Hermes 调度用的。之后手动将公钥添加到各执行端的authorized_keys中ssh-copy-id -i ~/.ssh/hermes_agent_key.pub userremote_host如果执行端没有ssh-copy-id就采用手动方式把公钥追加到远程主机的~/.ssh/authorized_keys然后注意权限chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys这里有一个我踩过坑的细节群晖默认的authorized_keys路径与普通 Linux 略有差别。我需要在群晖用管理员账号登录后把公钥放到用户的~/.ssh/authorized_keys同时保证.ssh目录权限不可被组用户写。如果权限过松sshd 会直接忽略这个文件导致登录失败。2.3 验证免密登录与服务端安全配置分发完公钥后不要急着写 Hermes 配置先在命令行里逐台验证ssh -i ~/.ssh/hermes_agent_key userremote_host echo ok hostname如果所有机器都能快速打印出ok和主机名说明免密已生效。接下来为了安全我通常会做三件事。第一禁用空密码用户登录确保每个 SSH 账号都有密码或密钥保护第二根据实际需求限制只有特定组如wheel组的用户可以 SSH 登录避免任何普通用户都能直接访问这可以在/etc/ssh/sshd_config里配上AllowGroups wheel第三如果不想让 root 直接远程登录就把PermitRootLogin设为prohibit-password甚至no这样即使密钥泄露也无法直接用 root 登录。当然安全配置要符合你的实际需求。我在自己实验室环境的机器上为了省事会把密钥权限放宽但线上业务机器绝不这么做这是一条红线。3. Hermes Agent 与 Claude Code 的本地部署3.1 安装 Claude Code 并完成认证在控制端安装 Claude Code 非常简单只要系统有 Node.js 18 以上版本执行npm install -g anthropic-ai/claude-code验证安装是否成功claude --version接着需要进行认证。Claude Code 支持多种登录方式我常用的是网页授权的方式命令行执行claude后按提示打开授权链接然后在浏览器里登录并授权。需要注意的是如果你的团队或组织统一管理了订阅直接用公司账号登录可能会看到类似 your organization has disabled claude subscription access for claude code 的提示遇到这种情况就不能用订阅账号了需要改用个人账号或者让管理员在后台把你的账号加入允许列表。认证完成后Claude Code 会用 token 的形式缓存登录状态同时你可以通过环境变量或全局配置指定你偏好的模型。3.2 安装 Hermes Agent 并初始化Hermes Agent 的安装方式也在逐渐演进因为它是较新的开源项目我建议直接按官方仓库 README 中推荐的安装方式操作。在控制端执行# 以官方发布版本为例 pip install hermes-agent # 或者通过官方脚本安装 curl -fsSL https://hermes-agent.example.com/install.sh | bash上面的域名仅为示意具体请按你拿到的最新版官方网址为准。如果你在安装过程中弹出需要跳转网页登录的情况大概率是因为它在初始化时要从远程拉取一些默认行为配置或插件清单这个环节需要保持网络可达可以试着手动下载对应配置放本地再离线安装。安装完成后执行初始化命令hermes init它会生成一个hermes_config.yaml配置目录里面包含主配置、agent 定义和任务模板。我建议一上来不要急着改复杂参数先把默认的 hello world agent 跑起来hermes run demo如果这个 demo 能正常返回输出说明 Hermes 的控制流已经没问题接下来就可以对接 Claude Code 了。3.3 配置 Hermes Agent 对接模型与 Claude CodeHermes Agent 本身可以对接多种模型服务我这里主要说两件事如何对接 Claude Code以及如何指定模型来源。在hermes_config.yaml中会有一个tools或commands的配置段。我添加了一个名字叫claude的工具定义让它直接调用本机的claudeCLI。例如tools: claude: command: claude args: [-p, --output-format, json]-p参数表示以非交互模式运行 Claude Code这是批量执行的关键。如果不用-pClaude Code 会进入交互式 REPL在自动化场景下没法做。--output-format json能让你拿到结构化的输出结果方便 Hermes 继续做后续处理。如果你本地的 Claude Code 需要指定模型或 API 端点我通常会通过环境变量注入。做法是在控制端的用户环境变量文件或 Hermes 启动脚本里设置export ANTHROPIC_MODELclaude-sonnet-4-20250514 export ANTHROPIC_BASE_URLhttps://your-model-endpoint.example.com这一点很实用。比如有些模型服务商提供兼容 Anthropic 接口的代理服务我把ANTHROPIC_BASE_URL指向它Claude Code 就能正常使用所有 Hermes 配置完全不用改。4. 用 SSH 远程调度 Claude Code 进行跨平台开发4.1 远程执行单条命令与文件同步Hermes Agent 里自定义远程执行器的方式非常多我一般先写一个简单的 shell 执行器供 Hermes 调用。你也可以把 SSH 命令直接写进 Hermes 的工具调用中但我建议封装成函数或脚本更容易做错误处理和日志记录。下面是一个简单的远程执行脚本思路#!/bin/bash # remote_exec.sh REMOTE_HOST$1 REMOTE_USER$2 REMOTE_COMMAND$3 ssh -i ~/.ssh/hermes_agent_key $REMOTE_USER$REMOTE_HOST $REMOTE_COMMAND有了这个脚本我就可以在 Hermes 的任务配置中指定tasks: remote_test: command: bash remote_exec.sh host1 deploy rsync -avz ./project userhost1:/home/user/workspace/project如果只是远程执行直接在 Hermes 里调用ssh子进程也可以。但更常见的场景是需要先把代码同步到远程再远程运行。文件同步我推荐rsync因为它是增量同步能大幅减少传输体积。Windows 上可以在 Git Bash 或 WSL 里使用 rsync执行端 Linux 上一般预装有 rsync。4.2 在多台机器上批量运行 Claude Code 任务最核心的使用场景是把一堆代码分析任务分发给多台机器。这里有一个很典型的例子我在服务器 A 上拉了一个大型前端仓库在 NAS 上保存近半年的日志数据在办公机上有一个算法脚本需要做 code review。以前我要分别登录三个环境手动粘贴同样的提示词给 Claude Code。现在直接用 Hermes 写一个批量任务agents: reviewer: model: claude tools: - remote_exec hosts: - serverA - nas - work tasks: review_all: agent: reviewer description: 对指定目录下的代码做审查并输出建议 steps: - remote_exec: claude -p --output-format json 请审查当前仓库的潜在Bug与性能风险运行时Hermes 会遍历所有 hosts通过 SSH 连接到每台机器并执行claude -p ...命令。因为控制端安装了 Claude Code理论上也可以在控制端直接执行但在多机场景下我建议在每台执行端也安装一份 Claude Code或者至少准备好可用的 Python/Node 解释器。原因很简单Claude Code 在执行时往往需要读取本地仓库的上下文文件如果代码本身就在远程机器上让远程的 Claude Code 直接读文件上下文完整度要高得多。不过这种方式对执行端配置有要求也需要在每台机器上做一次 Claude Code 认证。如果你想省事也可以只在控制端安装 Claude Code然后通过 SSH 把本地代码传给远程分析过程在控制端完成但这样对远程项目的理解会弱很多。我的原则是大型仓库就在执行端装 Claude Code小任务就在控制端统一跑。4.3 跨平台差异与兼容性处理多机编排必然会遇到系统差异问题我踩过的坑集中在三处文件路径、换行符和 shell 环境。文件路径是最直接的差异。Windows 下C:\Users\...、Linux 下/home/...、群晖下/volume1/...三者完全不一样。解决思路是不要在任何代码里写死绝对路径而是在 Hermes 的每个主机配置中单独定义工作目录和日志目录然后通过环境变量注入任务。这样每个节点的操作逻辑相同只是参数不同。换行符也是常见问题。Windows 下的 git 仓库默认把行尾转换成 CRLF而 Linux 下是 LF这有时会导致远程执行 shell 脚本时报错。我的办法是在仓库根目录放一个.gitattributes文件强制把.sh和.py文件统一使用 LF 结尾例如*.sh text eollf *.py text eollfshell 环境方面Windows 控制端要特别注意。包括 Git Bash、PowerShell、WSL 与 CMD 的调用方式各不相同。我建议在 Windows 上统一使用 Git Bash 作为 Hermes Agent 的外部 shell或者干脆启用 WSL然后在 WSL 中运行 Hermes。这样不仅能获得完整的 Unix 工具链SSH 和脚本语法也更统一。还有一类特殊设备比如华为交换机或者一些网络设备它们只支持 SSH 登录到命令行模式不支持标准的 shell 命令。对于这类设备我的做法是只做状态采集不做开发调度。也就是在 Hermes 里单独定义一个network_device主机类型commands 直接写成交换机命令比如display version和display interface brief收集回来做成巡检报告也算是多机编排的价值延伸。5.1 SSH 连接不稳定与密钥权限问题SSH 免密登录失败最典型的原因就是权限问题。报错信息往往是Permissions 0777 for xxx.pem are too open或者Bad owner or permissions这说明私钥文件权限太宽松了。解决办法是在控制端把私钥权限收紧chmod 600 ~/.ssh/hermes_agent_key执行端的authorized_keys权限也必须是 600 或 644不能是 777。目录权限要 700不能给组和其他用户写权限。如果排查完权限仍然失败我建议开启 sshd 的调试日志sudo tail -f /var/log/auth.log # 或者 sudo journalctl -u sshd -f日志中能看到具体被拒绝的原因绝大多数是权限或密钥解析问题。另外还有一个隐蔽问题就是当你有多个 SSH 配置时~/.ssh/config里某个 Host 段会干扰当前连接。例如你写了Host *段并指定了错误的User或IdentityFile所有 SSH 连接都会引用到错误配置。我在~/.ssh/config里专门为 Hermes 调度创建了明确的 Host 条目Host hermes-server-a HostName 192.168.1.10 User ubuntu Port 22 IdentityFile ~/.ssh/hermes_agent_key IdentitiesOnly yesIdentitiesOnly yes很关键它让 SSH 只使用指定的私钥不再尝试其他默认密钥避免密钥过多时反复尝试带来的卡顿和失败。5.2 Windows 环境下的 Bash 与路径转换在 Windows 控制端使用 Hermes Agent 时我遇到过两种常见问题一是 shell 路径二是路径分隔符。shell 路径问题表现为 Hermes 内部调用/bin/bash找不到。解决办法有两种要么在环境变量里加 Git Bash 的 bin 目录要么像前面说的直接在 WSL 里跑 Hermes。我目前选择在 WSL 里跑 Hermes这样内部所有进程都运行在 Linux 语义下完全没有 Windows 路径混淆问题。路径分隔符问题则更多出现在把 Windows 路径传给远程 Linux 机器的过程中。例如把D:\project这类字符串传给远程脚本经常会出现路径不存在。我的处理方案是在任务定义里统一使用相对路径Hermes 在解析时只做拼接不做平台转换。例如把工作目录统一设为workspace/project在 Windows 上实际拼接为D:/workspace/project在远程端拼接为~/workspace/project从根上避开分隔符问题。5.3 群晖、交换机等特殊设备的 SSH 配置群晖的 SSH 服务虽然从 DSM 界面开启很简单但登录后默认的登录 shell 对普通用户限制较多。我第一次配群晖密钥时一直报Permission denied (publickey,password)排查半天发现是群晖默认不允许空密码登录而我创建的测试账号没有设置密码。群晖要求 SSH 登录账号必须设置一个密码你可以拒绝远程密码登录但不能没有密码。另外群晖的用户家目录可能在/var/services/homes/user这与/home/user不一样配置脚本时要格外留意。如果你要写日志到用户目录建议使用~或$HOME变量替代绝对路径。交换机的情况就更特殊了。大部分企业交换机只支持aaa认证和 SSH 命令行不支持普通rcp/scp。针对这类设备我宁可靠 Hermes 里的纯命令采集型任务而不是让 Claude Code 去改造交换机系统。例如hosts: switch_core: hostname: 192.168.10.254 device_type: network tasks: collect_switch_status: host: switch_core commands: - display version - display interface brief5.4 Claude Code 认证失效与订阅限制远程多台执行端都安装 Claude Code 后最常见的问题是认证 token 过期。由于我控制在很干净的沙箱环境里通常只需要每台执行端在维护窗口里重新跑一次claude并完成网页授权。如果你觉得每台都网页登录太麻烦可以尝试将控制端的~/.claude配置目录包含认证缓存打包复制到执行端但注意这可能与账号安全策略冲突我不建议在生产环境这么操作仅仅适用于自己的实验网络。关于订阅限制如果你被组织管理员禁用了 Claude Code 的订阅访问报错会提示your organization has disabled claude subscription access for claude code。解决办法是用个人账号登录或请管理员在组织后台开通 Claude Code 的访问权限。如果你是通过模型服务商的自定义 API 端点接入了兼容接口那这个认证报错与本地模型服务无关重点检查ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY是否配置正确即可。我把一些典型问题整理成速查表方便你对照排查现象可能原因解决思路“Permissions too open”私钥或公钥文件权限过宽设为 600/700“Permission denied (publickey)”公钥未追加或 sshd 配置禁用了公钥认证检查 authorized_keys 与 sshd_config远程 bash 脚本换行错误CRLF 换行用 .gitattributes 强制 LFWindows 下找不到 bash缺少 Git Bash 或 WSL装 Git Bash 或用 WSL 运行 HermesClaude Code 认证过期token 失效重新执行 claude 登录授权群晖无法免密登录账号无密码或目录权限不对设置账号密码并 chmod交换机不识别 shell 命令设备类型不是标准 Linux使用 network 设备命令模板5.5 离线环境的 SSH 与 Hermes 安装还有一个容易被忽视的点是离线安装。很多内网环境完全无法访问外部软件源我之前就在一台装有国产 Linux 发行版比如银河麒麟或 OpenEuler的机器上部署过。最稳妥的办法是在有网络连接的机器上把安装包都下载好然后打包拷贝进去。对于 SSH 服务端在 openEuler 这类系统上可以用dnf install openssh-server但离线情况下需要先获取本机架构对应的 rpm 包。我通常会根据uname -m确定架构x86_64 或 aarch64然后从软件源镜像站下载对应的 rpm拷贝到目标机器上执行sudo rpm -Uvh openssh-server-*.rpm openssh-*.rpm对于 Hermes Agent由于它是 Python 包离线安装相对友好。先在一台联网机器上执行pip download hermes-agent -d ./hermes_packages然后把整个hermes_packages目录拷贝到目标机器执行pip install --no-index --find-links./hermes_packages hermes-agent这个方法同样适用于 Claude Code 的 npm 安装。因为 Claude Code 依赖的依赖项比较多我一般会直接拷贝整个全局 node_modules 目录不过这样做版本容易乱最好还是用离线缓存的方式。离线安装的机器如果没有外部模型服务也不需要外网Hermes Agent 的调度链路全部走内网 SSH所以整体可行。6. 进阶技巧与我的实操心得前面大多是基础配置和排障这里再分享几个我实测下来很有效的小技巧算是让整个调度体系更好用的细节。第一把 SSH Agent 用起来。虽然我已经在~/.ssh/config里指定了单独的密钥但当你有大量机器节点时Hermes 每次调用 ssh 进程都会重新加载私钥。更好的方式是启动ssh-agent并添加私钥eval $(ssh-agent -s) ssh-add ~/.ssh/hermes_agent_key如果当前的 shell 会话能通过ssh-agent提供认证那么后续所有 ssh 连接都会复用这个 agent多个并发任务同时发起时不会有锁等待速度提升明显。第二任务执行尽量做成幂等的。通俗来说就是同一条任务脚本重复执行多次结果应当一致。比如远程机器上拉取代码前先判断目录是否存在再利用 git clone 或 git pull这能避免因为上一次任务失败导致目录不完整。我在 Hermes 的脚本模板里已经内建了这种逻辑实际跑起来省心很多。第三日志集中管理。多机调度的隐患之一是不知道每个节点到底执行了什么。我在控制端设定了一个统一日志目录Hermes 每个任务执行完都会把 stdout 和 stderr 写入以“日期主机名”命名的文件。因为执行端很多是内网 IP出问题时直接按 IP 查日志省掉了一台一台登录翻记录的功夫。第四用好 VSCode 的 Remote-SSH。既然我们已经打通了 SSH 通道日常调试时大可以不必在终端手工敲命令直接用 VSCode 的 Remote-SSH 插件连接到远程主机在图形界面里写代码、开终端、关联 Claude Code 扩展。我通常在 VSCode 里的远程终端启动 Hermes Agent这样可以就近看日志也能直接在开发界面里执行 Claude Code 的交互式对话非常顺手。这一步建议放在免密登录配置验证之后再做体验会非常顺滑。第五养成写 SSH 配置注释的习惯。当机器数超过五台以后没有人能记住每台机器是用来干什么的。我习惯在每个 Host 条目的上方加一行注释记录机器的物理位置、用途、系统版本和注意事项比如“这台是群晖路径要用 /volume1/workspace”。这是小成本大回报的投资。最后聊两句心里的真实感受折腾这套 Hermes Agent 加 SSH 加 Claude Code 的多机编排方案前后花了我大概两天的时间中间踩了不少坑但最终把日常开发从“手动连半天机器”变成“一条命令批量处理”之后那种顺滑感确实很值得。最让我意外的并不是某个工具本身而是当 SSH 通道、Hermes 的 agent 定义和 Claude Code 的非交互模式真正串在一起时几乎可以把本地开发、远程执行、任务校验这整套流程都自动化。像 rsync 同步代码、远程拉起测试、收集多台机器的执行结果这些东西即使不用 AI 工具也能做但有了 Claude Code 的代码理解和生成能力整个流程才真正算得上“跨平台开发”。如果你目前手上的体量很小其实不需要一上来就追求复杂编排先把 SSH 免密跑通再把 Claude Code 的-p模式玩熟最后再加 Hermes 这层调度壳一步一步来。我的建议是一定要花时间把权限和日志做好因为后续所有自动化流程的稳定性都依赖这两点。希望这篇实战记录能帮你少走一些弯路也欢迎你在实际部署后继续摸索出更多适合自己工作流的玩法。