Hermes Agent 与 SSH 多机编排实战：驱动 Claude Code 跨平台开发

搞AI编程的朋友应该都有这个感觉手里的这台机器越来越不够用了。本地跑个Claude Code写写单测还行一旦要同时验证多平台、跑容器、压测模型单机的算力和环境隔离就顶不住了。我最近把整套工作流往“多机编排”的方向挪了挪核心组合是Hermes Agent负责统一调度SSH作为远程通道把Claude Code的编码能力分发到不同系统、不同配置的机器上执行。这套方案折腾下来跨平台开发的效率提升非常明显今天把完整实践过程整理出来供有同样需求的朋友参考。先说结论Hermes Agent 多机编排适合两类人。一类是像我这样本地主力机装的是 Windows 或 macOS但项目要跑 Linux 环境、Docker 容器、GPU 推理本地环境根本模拟不完整另一类是有团队协作需求的希望把“写代码”这件事统一接管让 AI 在不同机器上干不同的活比如这台跑测试、那台做编译、再有一台专门压测。如果你恰好属于其中一种这一篇可以帮你少踩很多坑。1. 多机编排的整体思路与方案选型1.1 什么时候才值得上多机编排很多人一上来就问工具问配置问命令但我觉得第一步应该是想清楚单机不行到底是什么不行。我自己梳理下来有三个典型的触发场景值得上多机编排。第一个是环境冲突。Windows 上开发的代码拿到 Linux 上编译不过本地装了一堆 Python 包结果 Claude Code 在改代码时测出来的结果和线上完全不一致。这种问题靠“本地开个虚拟机”“装个 WSL”能缓解但终究是打补丁环境不干净的坑还是会反复踩。多机编排的天然优势是远程机就是一台干净的执行环境代码在哪儿跑就以哪台机器为准。第二个是算力与资源瓶颈。本地内存 16G跑个大模型推理就卡到没法写代码更别提同时起几个测试容器。把重活甩给一台高配的远程机器本地保持轻量运行体感差别非常大。第三个是任务并发。Claude Code 一次只能专注一个会话但如果你有多台机器就可以让 A 机器做需求评审、B 机器写单元测试、C 机器做接口联调。Hermes Agent 在这里的价值就是统一入口——你通过它下发任务它去调度不同机器上的 Claude Code多任务并行互不干扰。1.2 为什么选了 SSH 而不是远程桌面或同步工具最初我也考虑过几条别的路但都因为各种问题放弃了。云 IDE 方案简单但很多内部项目压根不让代码离开内网而且云 IDE 和 Hermes Agent 的集成并不顺畅网盘同步、Git 仓库加 Webhook 这类方案只能解决文件层面的一致解决不了“在远程机器上真正执行一条命令、跑一个测试”这个核心诉求。做了几个对比之后就明确了真正靠谱的底子是 SSH。SSH 在这个场景下的优势很实。一是轻量一个 22 端口、一个客户端就能拿到远程机器的完整 shell相比远程桌面那套图形协议开销小得多二是安全密钥认证、端口转发这些机制都非常成熟加密传输在网络层面基本上是默认标配三是通用Windows、macOS、Linux、群晖 NAS只要装了 OpenSSH就能被纳入同一个编排网络这正好对上跨平台的需求。Hermes Agent 本身擅长做任务编排和工具调用但本身并不自带穿透内网、跨机器执行的能力所以用 SSH 把远程机器的执行能力“注入”给它填上这个缺口整个链路就通了。1.3 整体架构与核心流程我实际搭出来的架构大概是这样一个结构。本地有一台“管理机”装的是 Hermes Agent它负责理解用户的需求、拆解任务、调用各种工具。远程机器则是“执行机”每台上面都装了 Claude Code通过 SSH 密钥与本地管理机建立信任关系随时等待接收指令。整个流程跑起来是这样用户在 Hermes Agent 上提一个需求Agent 判断这个任务需要在远程环境执行于是通过我配置的 SSH Tool 连接目标机器在远端依次完成拉代码、调 Claude Code、跑测试、收集结果再把日志和产物回传给本地由 Hermes Agent 汇总输出。这套架构的好处是Claude Code 负责它擅长的“理解代码、改代码、跑命令”SSH 负责“稳定地抵达远程机器”Hermes Agent 负责“决定去哪台机器、为什么去”三个工具的边界非常清楚排查问题的时候也好定位。2. 环境准备与基础配置2.1 远程机上安装 Claude Code执行机上要跑 Claude Code第一步肯定是装好它。Claude Code 是 Anthropic 官方的命令行 AI 编程工具可以直接在终端里和代码仓库对话读写文件、执行命令、运行测试都不在话下。安装方式有几种我实测比较稳的是用官方安装脚本在 Linux 环境执行这一行curl -fsSL https://claude.ai/install.sh | bash如果你更习惯 npm 的方式也可以先装好 Node.js 18 以上的版本然后npm install -g anthropic-ai/claude-code装完之后验证一下claude --version能正常输出版本号就说明装好了。这里有个细节远程机器如果是不带显示器的服务器没有图形终端Claude Code 依然可以跑只是要记住用非交互模式。交互模式下它需要 TTY 来画界面而自动化调度场景里根本不会有真人坐在那敲键盘所以后续在 Hermes Agent 调度时我会让远程的 Claude Code 以-p参数运行也就是 headless 模式直接传一段指令给它它执行完把结果返回。用法大致是claude -p 请检查当前目录下 src/ 中的代码找出类型错误并修复认证方面如果远程机器是第一次使用 Claude Code需要先登录一次。交互式登录一次之后凭证会保存在用户目录后续非交互调用就能直接复用。如果有多台执行机那我建议统一在每台机器上各自登录一次免得凭证冲突。2.2 SSH 密钥配置与免密登录SSH 密码登录也能用但多机编排之下Agent 和机器的连接是高频操作每次都输密码既不现实也不安全。所以我第一步就把免密登录配好用密钥认证替代密码认证。在管理机上执行ssh-keygen -t ed25519 -C hermes-agent一路回车默认会生成在~/.ssh/id_ed25519私钥留在本地不要动。然后把公钥推送到远程执行机ssh-copy-id userremote-host它会自动把公钥追加到远程机的~/.ssh/authorized_keys。如果没有ssh-copy-id比如 Windows 的 OpenSSH 客户端就手动执行cat ~/.ssh/id_ed25519.pub | ssh userremote-host mkdir -p ~/.ssh chmod 700 ~/.ssh cat ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys配置完成之后直接ssh userremote-host就能进远程机不需要输密码。这里有个非常关键的权限问题很多新手免密失败都是栽在这。authorized_keys文件的权限必须是 600.ssh目录必须是 700如果权限过于开放sshd 会直接拒绝使用这个公钥文件。如果连不上先检查这个。2.3 SSH Config 多机管理与端口调优机器一多IP、端口、用户名、密钥文件这些信息就容易记混。我强烈建议在管理机上维护一个~/.ssh/config文件把每台执行机的信息固化下来。我的配置大概是这样的Host linux-dev HostName 192.168.1.101 User ubuntu Port 22 IdentityFile ~/.ssh/id_ed25519 Host nas-runner HostName 192.168.1.102 User admin Port 2222 IdentityFile ~/.ssh/id_ed25519 Host win-build HostName 192.168.1.103 User administrator Port 22 IdentityFile ~/.ssh/id_ed25519配置完之后连接时直接ssh linux-dev就行不需要再带一堆参数。还有一个很实用的技巧是用 Host 别名配合IdentitiesOnly yes防止 SSH 在多个密钥之间反复试探。如果远程机器的 SSH 端口改过比如群晖 NAS 有些用户会改成非标准端口那就把Port改成对应值。另外如果需要执行的命令涉及访问远程机器上的 Web 服务比如启动了一个开发服务器要联调可以用 SSH 端口转发把远程端口安全映射到本地ssh -L 8080:localhost:8080 linux-dev这样本地访问localhost:8080实际上是访问远程机器上的 8080 端口数据全程走 SSH 加密隧道适合调试远程服务。3. Hermes Agent 接入远程机器3.1 Hermes Agent 的本地安装与初始化管理机上需要先装好 Hermes Agent。这个工具现在开源社区热度不错仓库地址可以直接搜到。安装方式上它提供本地部署模式数据默认留在自己机器上对需要控制代码隐私的团队比较友好。拉取下来之后按照文档初始化工作目录git clone https://github.com/anthropics/hermes-agent.git cd hermes-agent make install hermes init初始化的过程中它会要求配置默认模型、工作目录和管理员账号。这里我建议工作目录单独建一个不要放到系统临时目录因为 Hermes Agent 的任务记录、日志、工具配置都在这下面后续迁移也方便。装好之后先本地跑一下hermes status确认服务正常再进入下一步。如果在 Windows 上安装需要注意一点Hermes Agent 的很多辅助脚本默认期望是 Unix 环境虽然它能在 Windows 上跑但最好在 PowerShell 里开启 WSL 兼容层或者直接用 Git Bash 来执行初始化命令能省掉不少路径分隔符引发的奇怪问题。3.2 给 Agent 注册 SSH 远程执行能力Hermes Agent 安装好之后默认并不能直接操作远程机器它更像是一个“大脑”需要接上“手和脚”。我的做法是给 Agent 增加一个自定义工具起名ssh_exec让它能够通过 SSH 在远程执行任意命令。具体实现我是用一个脚本把 SSH 命令包了一层。核心逻辑就是接收参数目标机器、要执行的命令在本地拼出完整的 SSH 命令并执行返回输出。示例脚本内容大致如下Python 版#!/usr/bin/env python3 import subprocess import sys import shlex def ssh_exec(host_alias: str, command: str) - str: # 只允许预定义的 host 别名防止 SSRF 类滥用 allowed_hosts {linux-dev, nas-runner, win-build} if host_alias not in allowed_hosts: return fError: host {host_alias} is not in allowed list # 简单校验不允许分号/管道拼接多条命令降低被注入的风险 if ; in command or in command: return Error: chained commands are not allowed cmd [ssh, host_alias, shlex.quote(command)] result subprocess.run(cmd, capture_outputTrue, textTrue, timeout120) return fSTDOUT:\n{result.stdout}\nSTDERR:\n{result.stderr} if __name__ __main__: host sys.argv[1] cmd sys.argv[2] print(ssh_exec(host, cmd))脚本编好之后在 Hermes Agent 的工具配置里把这个脚本注册为自定义工具告诉 Agent 这个工具的作用是“在指定远程机器上执行 shell 命令并返回结果”。注册完测试一下给 Agent 下一条指令“请通过 ssh_exec 查看 linux-dev 的当前目录和系统版本”。如果 Agent 能正确调用工具并返回结果说明 SSH 通道已经打通。这个设计有一个很重要的点Agent 能访问的远程主机必须是白名单管理的。因为大模型在长对话里偶尔会“发挥”如果不对目标机器做限制它可能把执行命令发到任何一台能连的机器上。白名单列表就是最后一层保险。3.3 Windows 和群晖等特殊主机接入的坑接入 Linux 服务器是最顺利的但实际项目中总会遇到 Windows 机器或群晖 NAS 这类特殊节点处理起来有几个明显的坑。Windows 接入首先要在 Windows 上启用 OpenSSH Server。路径是“设置 - 系统 - 可选功能 - 添加功能 - OpenSSH 服务器”安装后启动服务并设为自动。然后用管理员权限做一次公钥部署把公钥写到C:\ProgramData\ssh\administrators_authorized_keys这个文件里注意这个文件的权限必须是 SYSTEM 和管理员组才有否则 SSH 服务会拒绝读取。Windows 默认的 shell 是 PowerShellSSH 连过去之后直接执行命令时很多 Linux 习惯的语法是跑不通的所以我在 Host 配置里把远程机默认 shell 切成了 Git Bash减少跨平台的语法差异。群晖 NAS 接入需要在控制面板的“终端机和 SNMP”里打开 SSH 功能。群晖默认的 SSH 端口是 22但为了安全我改成了非标准端口然后在~/.ssh/config里对应设置好。群晖的 authorized_keys 路径在/var/services/homes/admin/.ssh/这个位置和标准 Linux 有区别配置的时候要注意。连接之后用sudo -i切到 root 执行一些安装操作时还需要额外配置免密 sudo 权限否则 Agent 调度时会被交互式密码卡住。这些节点接进来之后Hermes Agent 的环境感知能力会明显上了一个台阶——你不再只是拥有一台“能用”的机器而是拥有一组覆盖 Windows、Linux、NAS 三种环境的远程执行资源池。4. 一次完整的跨平台调度实战4.1 任务拆分与执行计划理论讲完来看一次我实际跑通的流程。假设场景是这样本地是一台 Windows 机器负责开发一个后端 Go 项目同时有一台 Linux 服务器作为模拟线上的测试环境。用户的需求是“给这个项目补上针对用户登录接口的单元测试并在 Linux 环境跑通验证。”这个需求如果是单机就是简单地让 Claude Code 写测试、跑测试。但多机编排的话我把流程拆成四步步骤执行位置任务内容工具1本地 Windows获取需求、定位仓库、读取项目结构Hermes Agent 本地 Claude Code2本地 Windows生成/修改测试文件提交到 Git 仓库本地 Claude Code3远程 Linux拉取最新代码运行测试命令ssh_exec 工具 远程 Claude Code4远程 Linux收集测试结果、修复失败项、回传日志ssh_exec 工具 远程 Claude Code之所以把验证放到远程是因为本地是 Windows而 Go 项目的线上环境是 Linuxcgo 编译、文件路径、系统调用在两种系统下行为有差异。与其本地测试通过了线上还是挂不如从一开始就让 AI 在真实目标环境下干活。4.2 Hermes Agent 调度执行过程第一步我在 Hermes Agent 的对话窗口里输入需求。Agent 会先读取项目目录分析仓库结构然后调用本地 Claude Code 生成测试用例。这个过程中我可以看到 Agent 的思考过程——它先定位到internal/handler/login.go发现登录接口缺少对空参数和错误密码的用例于是新建了internal/handler/login_test.go并且用本地 Claude Code 完成了初版代码。第二步Agent 自动执行 git 提交并推送到远程仓库。git add internal/handler/login_test.go git commit -m test: add login handler unit tests git push origin main第三步Agent 判断需要远程验证。它从我配置的ssh_exec工具列表里选中了linux-dev发出指令ssh_exec(serverlinux-dev, commandcd /data/projects/myapp git pull go test ./internal/handler/ -v --run TestLogin)这一步是整套流程的关键。远程机器收到命令后先拉取最新代码然后由远程的 Claude Code 介入继续执行测试。因为测试可能因为环境依赖缺失而失败Agent 会在远程机器上自动安装依赖、调整配置。比如有一次测试失败是因为线上 Linux 没有安装gcc导致 cgo 编译不过远程 Claude Code 自动执行了apt-get install -y gcc build-essential然后重新编译再跑测试。第四步远程执行完的结果通过 SSH 通道原样返回给 Hermes Agent。Agent 综合判断结果生成一份简洁的总结包括通过率、覆盖到的用例、以及远程环境自动修复的依赖项。全程自动化我在这一端几乎不需要手工介入。4.3 跨平台差异的实战处理这次流程里最有“真实感”的部分是跨平台差异的处理。Windows 和 Linux 之间第一个明显差异就是路径分隔符。本地 Agent 在生成测试用例时如果写死了 Windows 路径如C:\Users\xxx\go\src\...推送到 Linux 必然无效。所以我会在本地 Agent 的系统提示词里加一条规则所有涉及文件路径的操作一律使用相对路径不做任何 Windows 绝对路径假设。第二个差异是换行符。Windows 下 Git 默认可能把 CRLF 转换成 LF 或者反过来可能导致 shell 脚本在 Linux 上出现\r相关报错。解决办法是在仓库根目录维护.gitattributes文件显式声明文本文件的换行风格* textauto *.sh text eollf *.go text eollf第三个差异是系统依赖安装方式。Windows 上我们几乎不会去人工装 gcc但 Linux 裸机经常会缺编译器。远程 Claude Code 在检查环境时如果发现缺依赖它自己会通过包管理器安装。这一点上 AI 工具的适应能力确实强只要给了它 root 权限它就会想办法把环境整到可用状态。这几个差异如果能提前处理整个多机编排流程会顺滑很多。5. 常见问题排查与安全加固实录5.1 高频问题速查表多机编排踩过的坑不少我把最典型的整理成一张速查表方便各位对照排查。问题现象常见原因解决办法SSH 连接超时无法连到远程机远程机 SSH 服务未启动防火墙拦截 22 端口远程执行systemctl status sshd确保服务 active检查防火墙规则开放 SSH 端口密码正确但 SSH 拒绝密码远程机 sshd 开启了PasswordAuthentication no只允许密钥认证在 sshd_config 里改回yes或者改用密钥认证免密登录不生效反复要求输密码authorized_keys文件权限不对公钥内容粘贴错误将 authorized_keys 权限改为 600.ssh目录 700核对公钥内容Ubuntu 装了 SSH 但还是连不上openssh-server 未安装系统默认只有客户端执行apt install openssh-server再启动服务群晖 NAS SSH 连不上群晖默认关闭 SSH 服务控制面板 - 终端机和 SNMP - 开启 SSHAgent 调用 ssh_exec 后返回 “host not allowed”自定义工具里没有把目标主机加入白名单把目标主机 Host 别名追加到脚本的 allowed_hosts 列表远程 Claude Code 非交互模式报错没有配好登录凭证TTY 相关配置缺失先交互式登录一次或显式指定 API Key 环境变量Git 推送远程仓库失败远程机器上未配置 Git 用户名/密钥在远程机执行git config --global user.name/user.email并配置 SSH 密钥到 Git 平台Claude Code 远程执行测试时卡住没反应等待人工输入确认或超时时间设置太短给 ssh_exec 增加合理的超时参数远程命令尽量用-p非交互模式5.2 安全加固清单远程通道别裸奔多机编排意味着你的管理机有了一堆机器的“远程开关”这个能力如果不做安全加固等于把所有机器都暴露在风险里。我的安全配置分三层。第一层是 SSH 本身的加固。编辑/etc/ssh/sshd_config建议这样改PermitRootLogin no禁止 root 直接登录PasswordAuthentication no禁止密码登录只用密钥AllowGroups wheel只允许特定用户组登录避免任何普通用户都能爬到远程机器。改完记得重启 sshd 服务。这一步直接砍掉了绝大多数暴力破解的路径。第二层是防暴力破解。如果远程机器直接暴露在公网上SSH 日志里会常年出现各种歪瓜裂枣的登录尝试。我给所有公网可达的执行机都装了 fail2ban配置非常简单apt install fail2ban默认配置就能对连续认证失败的 IP 做封禁实测能挡住相当一部分噪声攻击。第三层是 Agent 工具的权限最小化。我设计的ssh_exec工具默认拒绝执行包含高风险的命令比如rm -rf、mkfs、shutdown。可以在脚本里加一个危险命令黑名单如果 Agent 生成的指令命中了黑名单直接拒绝执行并提示变更方案。另外远程执行用户的权限不要给到 root给一个普通用户只有明确需要 root 的操作才通过sudo白名单授权。5.3 一些可能救你一命的细节经验最后分享几条纯粹靠踩坑换来的经验。第一私钥永远不要复制到远程机器上。有些朋友为了“方便”会把管理机的私钥也拷到执行机这样执行机之间就能互相免密。一旦哪台机器被攻破私钥泄露整个机器集群等于全裸了。正确的做法是每台执行机只保留公钥私钥只存在于管理机。第二远程执行长任务一定要用 tmux 或 screen。有一次 Agent 调了一台远程机跑一个二十分钟的集成测试我中途关了一下电脑SSH 会话断掉测试进程直接被打断结果全部丢失。后来我在远程机上常驻一个 tmux 会话所有长任务都在 tmux 里跑即使 SSH 断开任务在远程机上照常执行重连之后还能重新附着到会话查看进度。第三Hermes Agent 的配置和工作目录要纳入版本管理。Agent 的工具配置、SSH 白名单、系统提示词这些都属于“基础设施即代码”的一部分我用一个单独的 Git 仓库管理起来。每次修改配置都提交一次出问题时可以随时回滚。很多团队用着用着 Agent某天突然发现行为不对又说不清是哪次配置改的这就是没做版本管理的典型症状。多机编排这条路我走下来最大的感受是它并不需要多高深的技术关键是把 SSH、Claude Code、Hermes Agent 这三样东西的边界划分清楚然后让它们各司其职。SSH 负责把信任关系建立起来Claude Code 负责把编码任务落地Hermes Agent 在中间做调度和决策。三层之间只要配合好了原来需要手动在几台机器之间来回切换的工作现在基本可以交给系统自动完成。如果你也正在为跨平台开发的环境问题头疼按着这篇文章的思路先把最小闭环跑通后面的扩展空间会比你想象的更大。