Hermes Agent + SSH + Claude Code 多机编排：让AI直接操作远端代码

前阵子我整理开发环境的时候意识到一个有点尴尬的现实Claude Code 装在我的笔记本上用起来确实顺手可真正吃性能的活——编译大型项目、跑完整测试套件、处理数据流水线——全都堆在远端那台 Linux 工作站和 Windows 主机上。每次要处理跨平台问题我都是先同步代码、再拉环境、再让 AI 改来来回回折腾的时间足够我自己手动改两遍了。后来我把 Hermes Agent、SSH 和 Claude Code 串成一套多机编排方案让 AI 直接“住”到代码所在的机器上这个问题才算彻底解决。这套组合特别适合几类人主力电脑性能一般但手里还有其他机器的开发者、需要频繁在 Windows/Linux/macOS 三端验证代码的人、以及想把手头几台设备统一纳管成“个人 AI 开发集群”的折腾党。这篇文章不聊太多虚的就讲我怎么一步步把通道打通、把任务发出去、结果怎么收回来外加我在实际部署中踩过的坑和走过的弯路。1. 单机开发的天花板为什么要做多机编排1.1 一个几乎所有开发者都会遇到的日常我自己最典型的场景是这样主力笔记本装的是 macOS日常写业务逻辑、开模型对话很舒服。但一旦接手一个仓库要求必须在 Linux 环境编译或者要在 Windows 上做兼容性回归测试事情就变味了。传统流程是先把代码推送到远端仓库SSH 登录目标机器拉代码配环境再手动执行编译或测试把输出贴回来自己分析。遇到问题再改代码再推送再执行。如果让 Claude Code 介入很多人会直接把它装在本机然后把远端代码拉下来给它读。这在小项目上没毛病但项目一大就暴露问题本机磁盘不够、模型上下文被无关文件占满、拉代码和推送代码的冲突频繁出现。更别说你本机是 Windows目标机器是 Linux很多行为在两端根本不一致AI 在本地看到的东西和远端实际运行环境完全是两回事。1.2 多机编排的本质把 AI 能力调度到代码所在地多机编排和我之前习惯的思路有个根本区别过去我默认“代码要跟着人走”无论在哪台机器干活先把代码弄到自己面前。而编排思路是反过来——代码在哪儿AI 就去哪儿。这套体系里三个角色各司其职Hermes Agent是整个方案的调度中枢负责理解上层任务、拆分指令、决定把任务派到哪台机器。SSH是连接层打通管理机和目标机器之间的安全通道传输指令和结果。Claude Code是执行引擎跑在受控节点上实际读取代码、分析问题、生成补丁。用这张拓扑去理解就很简单你只需要在一台“管理机”上操作 Hermes Agent它会通过 SSH 登录到任意一台配置好 Claude Code 的机器在那边执行claude命令再把输出回传给你。整个过程里代码完全没有离开它原本的环境。1.3 什么情况下这套方案才值回票价我得说句实在话如果你的开发场景就是一台笔记本从头写到尾那多机编排属于过度设计没必要给自己找事。但下面这几类场景我觉得值得投入本地性能和远端环境差异大比如你本地是轻薄本编译、跑测试要到高配工作站。需要多平台验证产品要同时出 Windows、Linux、macOS 版本每次改动都要在三端回归。团队共享开发服务器代码已经集中在一台 Linux 服务器上希望 AI 直接操作服务器上的工作副本而不是每个人各自维护一份。多台机器不同用途一台负责数据处理、一台负责前端构建、一台专门跑深度学习训练想用一个入口统一管理。说白了多机编排解决的不是“能不能跑”的问题而是“折腾不折腾”的问题。我的体会是配置好一次之后后面省下来的时间是非常可观的。2. 网络底座先行SSH 在三大平台的开荒与免密配置2.1 三端 SSH 服务端的准备方法SSH 是整个链条的地基地基不稳后面全白搭。我的管理机是 macOS受控端分别是一台 Ubuntu 工作站和一台 Windows 主机三端的 SSH 配置方法各不相同这里逐个说。Linux 和 macOS 通常自带 OpenSSHLinux 端需要确保 sshd 服务在跑。Ubuntu 上常见的启用命令sudo systemctl enable --now ssh systemctl status sshmacOS 则在“系统设置 → 通用 → 共享”里把“远程登录”打开即可默认监听 22 端口。Windows 是重头戏。微软现在提供了系统自带的 OpenSSH Server但说实话它的初始配置对不熟悉命令行的人不太友好。也有第三方选择比如 Bitvise SSH Server图形化程度高装完点几下就能用。我做了一个简单对比方案优点缺点适合人群Windows 自带 OpenSSH Server系统集成、无需额外费用配置靠 PowerShell、服务管理不够直观愿意折腾命令行的用户Bitvise SSH Server图形界面、虚拟账号、日志完善免费版有限制、商用需购买授权想快速上手的 Windows 用户如果你选系统自带的 OpenSSH Server大概流程是这样在“设置 → 应用 → 可选功能”里添加“OpenSSH 服务器”然后用管理员权限的 PowerShell 启动服务Start-Service sshd Set-Service -Name sshd -StartupType AutomaticBitvise 的安装则更直白一路 Next设置好 Windows 登录账号映射或者虚拟账号服务会自动注册。我个人在 Windows 上用了 Bitvise原因是它在用户权限映射和日志排查上更符合我习惯。2.2 免密登录一次性配置长期受益密码登录能跑通但每次 SSH 进去都要输密码编排脚本根本无法自动化。免密登录是整套方案能成立的前提。密钥对生成建议用 ed25519安全性比 RSA 好性能也更好ssh-keygen -t ed25519 -C hermes-agent-key一路回车之后会生成~/.ssh/id_ed25519私钥和~/.ssh/id_ed25519.pub公钥。接下来要把公钥放到目标机器的~/.ssh/authorized_keys里。Linux 和 macOS 可以用ssh-copy-idssh-copy-id -i ~/.ssh/id_ed25519.pub username192.168.1.100Windows 受控端手动一点把公钥内容追加到C:\Users\你的用户名\.ssh\authorized_keys注意这个文件要用 UTF-8 无 BOM 格式保存不要用记事本默认的带 BOM 编码否则密钥匹配会失败。这一步我当初卡了很久后来用 VS Code 重新保存才解决。一个容易忽略的点是权限。Linux 上~/.ssh目录应该是 700authorized_keys文件应该是 600权限过宽 SSH 会直接忽略这个文件。命令chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys2.3 用 SSH Config 给每台机器起个“外号”机器一多IP 地址和用户名就容易混。我习惯在管理机的~/.ssh/config里给每台机器定义别名后面 Hermes Agent 和手动排查都可以直接引用。Host linux-ws HostName 192.168.1.100 User dev IdentityFile ~/.ssh/id_ed25519 ServerAliveInterval 30 Host win-dev HostName 192.168.1.101 User dev IdentityFile ~/.ssh/id_ed25519 ServerAliveInterval 30配置完测试一下ssh linux-ws hostname whoami ssh win-dev echo %COMPUTERNAME%ServerAliveInterval 30这个参数值得多说一句它每 30 秒发一个心跳包防止长时间不操作时连接被中间设备断开。跑长时间 AI 任务时非常有用不然任务执行到一半SSH 会话被掐断那才是真的欲哭无泪。3. Hermes Agent 调度中枢部署命令行与桌面版怎么选3.1 Hermes Agent 在体系里扮演的角色先说清楚 Hermes Agent 到底是什么定位。它不只是一个能聊天的 AI 前端而是一个可以编排工具、执行任务的 Agent 框架。在我们的多机体系里它的任务拆解思路很接近一个“项目经理”你告诉它“去 Windows 那台机器上把测试跑一遍如果有失败就让 Claude Code 修”它负责把这句话拆成可执行步骤调用 SSH 工具连到目标机器再调用目标机器上的 Claude Code 执行具体的编码任务。我第一次用的时候犯过一个理解错误以为 Hermes Agent 会自己写代码。实际上它更擅长“把活派下去”写代码、改代码这类细粒度工作由 Claude Code 这类编码 Agent 完成。想明白这一点后整个架构就非常清晰了。3.2 安装过程与常见的“首次登录疑问”Hermes Agent 官方提供了桌面版和 CLI 版。我一开始装的是桌面版在 Windows 上遇到报错后来查到是系统缺少某些运行库以及安装包下载不完整导致的。这类问题在安装桌面版时太常见了尤其是网络不稳定的情况下下载中断会让安装包不完整安装过程直接抛错。我的建议是如果只是做多机编排调度优先用 CLI 版。CLI 版更轻量依赖更少在服务器上也能跑出现问题时排查路径短。具体安装方式官方文档写得很清楚这里只说一个高频疑问——“安装时让登录网站怎么回事”。我第一次遇到这个提示也愣了一下以为装错了软件。实际上这是正常的Hermes Agent 首次启动需要在浏览器里完成账号关联和模型服务授权它要拿着这个授权去接模型 API。这不是什么异常流程按提示操作即可。如果你是在无浏览器环境的服务器上装就得检查一下官方是否支持 API Key 直连方式我印象中可以通过配置文件指定密钥来跳过浏览器授权环节具体以你安装版本的文档为准。3.3 模型接入以阿里百炼为例的配置路径Hermes Agent 本身不生产模型能力需要接外部模型。它可以接 Anthropic 官方模型也可以接兼容 OpenAI 协议的国内模型服务。我这边因为访问 Anthropic 官方服务的网络条件不稳定实际生产环境主要接的是阿里百炼平台的通义系列模型。百炼平台的模型接口是 OpenAI 兼容的配置时关注这几个参数base_url填百炼提供的 API 地址形如https://dashscope.aliyuncs.com/compatible-mode/v1。api_key在百炼控制台创建注意不要硬编码进博文里的示例更不要提交到 Git。model 名称选择你要用的模型比如通义千问系列支持 Agent 任务的具体型号。配置完成之后先跑一个简单的交互式任务验证模型链路通不通。如果返回结果很慢或者报 401优先检查 api_key 和 base_url 是否填对。这里报 401 大概率是鉴权问题别急着改 Agent 参数。另外提醒一句不要把真实 api_key 写在配置文件里然后到处同步我见过有人把配置文件推到仓库几分钟后 key 就被别人盗刷的情况。建议用环境变量方式注入比如在启动 Hermes Agent 前export DASHSCOPE_API_KEYxxxx。4. Claude Code 在受控端的落地安装、VSCode 集成与多配置管理4.1 在远端机器上安装 Claude Code 并确认可用Claude Code 是 Anthropic 出品的编程 Agent可以在终端里直接交互也可以用-p参数走非交互模式这个特性特别适合被外部编排系统调用。在每台受控端机器上安装用到的是 npmnpm install -g anthropic-ai/claude-code装完先手动验证一下claude --version需要特别说明的是Claude Code 的使用需要你有可用的 Claude 订阅权限。如果你在团队环境遇到your organization has disabled claude subscription access for claude code这类的报错这是组织的访问控制策略需要联系管理员在 Claude 控制台对你的账号开放 Claude Code 权限而不是自己想办法绕过去。这一步务必确认清楚否则后面任务编排得再好也跑不起来。4.2 VSCode Remote-SSH 配 Claude Code 的典型玩法VSCode 是目前最主流的远程开发载体。流程并不复杂本地 VSCode 装好 Remote-SSH 插件通过 SSH config 定义的别名连接远端然后在远端环境里安装扩展。使用claude命令之前建议先 VSCode 的终端里跑一遍交互确认。如果你更喜欢图形界面也可以在 VSCode 插件市场搜 Claude Code 相关扩展装到远程端。但我的实际体验是在受控端机器上CLI 方式反而更稳定尤其适合长时间运行的任务VSCode 扩展在重负载下偶尔会掉线重连CLI 则不会有这个问题。还有一点值得注意VSCode 连接远端后默认打开的是你 SSH 登录用户的家目录。实际项目代码可能不在家目录下建议通过文件 → 打开文件夹打开代码目录这样 claude 在工作时才能正确读取到项目根目录的上下文。4.3 多端多配置管理cc-switch 的使用思路受控端多了之后会出现一个很实际的问题每台机器可能需要对应不同的模型供应商或者不同的项目配置。我见过有人直接手动改~/.claude/下的配置文件改来改去特别容易出错。cc-switch 这个小工具就是用来解决多配置切换的。它可以在不同供应商、不同模型之间快速切换 Claude Code 的配置。官方对它的定位是“管理 Claude Code 的 provider 配置”。在多机编排场景里我建议每台受控机固定用一套配置不要让同一台机器上的配置频繁切换。原因有两点一是配置切换后当前会话可能失效需要重新授权二是如果你在编排任务时没指定配置远端默认配置可能与任务预期不符导致模型能力差异。更稳妥的方式是在每台机器上把配置固化好编排层只管发指令不参与配置切换。5. 全链路实测Hermes Agent 通过 SSH 把 Claude Code 派到远端干活5.1 第一个任务让远端 Windows 跑测试并修复失败理论讲再多不如跑一个真实任务。我设计了一个很典型的场景我有一个 Python 项目在 macOS 上开发但目标运行环境是 Windows。现在要让 Hermes Agent 调度到 Windows 受控机在那边运行完整测试如果发现失败调 Claude Code 直接修复代码并把改动报告返回。从用户视角看我只需要在 Hermes Agent 里下达一条自然语言指令比如在 win-dev 节点上进入 D:\projects\pyapp运行 pytest如果测试失败让 Claude Code 分析失败原因并修改代码修改完成后再次运行 pytest 确认通过最后输出修改了哪些文件、问题的根因是什么。这条指令背后Hermes Agent 做的事情大致是解析指令识别目标节点是win-dev。通过 SSH 连接win-dev检查目录是否存在、Python 环境和依赖是否就绪。在远端执行pytest捕获输出。如果失败将失败日志作为上下文调用远端claude命令请求修复。回收修复结果再次执行测试验证。5.2 手动复现编排中的每一条核心命令如果你没有 Hermes Agent 或者想先验证链路完全可以用手动命令把整个编排流程复现一遍这也能帮你在接入 Hermes Agent 之前确认各环节都没问题。第一步SSH 到目标机器并执行测试ssh win-dev cd /d D:\projects\pyapp python -m pytest --tbshort这里我用了cd /d是因为 Windows 默认 shell 是 cmd和 Linux 的cd行为不同。如果后续测试 failures 很多建议把输出重定向到文件里别让终端刷屏ssh win-dev cd /d D:\projects\pyapp python -m pytest --tbshort test_output.txt 21 type test_output.txt第二步把失败日志喂给远端 Claude Code。Claude Code 的-p参数是“非交互模式”能在单条命令里直接提需求非常适合被编排系统调用ssh win-dev cd /d D:\projects\pyapp claude -p \读取 test_output.txt 和项目代码定位测试失败根因修改代码然后重新运行 pytest 直到通过最后列出修改的文件和原因\注意在 cmd 和 bash 之间互相嵌套引号时特别容易出错我实际执行时更倾向于把这段指令写成一个.bat脚本放到远端然后通过 SSH 只调动脚本大幅降低转义问题。第三步回传结果。Hermes Agent 的编排系统会自动收集 SSH 会话中的 stdout/stderr作为最终回答的上下文。人工操作的话把test_output.txt和 Claude Code 的--output-format输出放到一起看即可。5.3 为什么说 Claude Code 的 headless 模式是编排的关键Claude Code 本身是个交互式程序双击进入对话界面很爽但它没法直接被另一个系统嵌套调用。编排场景必须用 headless 模式也就是claude -p。这个模式下它能接受单次传入的指令执行完毕后直接退出输出可以通过 stdout 捕获。举个实际例子如果我想让远端 Claude Code 分析一个编译错误命令可以是这样ssh linux-ws cd /home/dev/project claude -p 请阅读 build.log 中的编译错误分析最可能的原因给出修复建议 --output-format stream-json--output-format stream-json会把输出变成结构化 JSON 流对于程序化处理非常友好。Hernes Agent 这类编排框架通常就是读这种结构化输出来判断任务状态和结果的。还有一个我自己调试时常用的参数是--allowedTools它可以限制 Claude Code 能调用的工具范围。在远端受控机上我通常只允许它执行读取文件、编辑文件、运行测试等必要操作禁止它随意执行网络下载或者其他危险命令。这个限制不仅是安全考虑也能避免 AI 跑偏去干一些预期之外的事情。5.4 编排任务失败后如何处理任何自动化系统都会失败SSH 断连、依赖缺失、测试环境不一致都可能导致任务中断。我常用的策略是“两层重试”第一层SSH 连接级别连接超时就重连最多重试 3 次。第二层任务级别Claude Code 修复后如果测试仍然失败把新的测试输出再次喂给它让它迭代修复最多迭代 N 轮超过轮数就把中间日志全部返回给人判断。这个思路很像开发者的自然行为——不是一次就改好而是“看日志、改代码、再跑、再看日志”不断循环。把这种循环自动化之后AI 修 bug 的能力会超出你预期但前提是你必须给它设置上限否则遇到一个无法收敛的问题它会一直空转到资源耗尽。6. 踩坑盘点认证失败、端口限制与平台差异6.1 SSH 连不上一个有序的排查链路我遇到最多的 SSH 问题集中在三类端口不通、认证失败、host key 变化。很多人一上来就怀疑密钥配置其实连端口都还没摸到服务。我自己的排查链路是这样# 第一步确认主机通不通 ping 192.168.1.101 # 第二步确认 22 端口是否有服务在监听 nc -vz 192.168.1.101 22 # 第三步启用 SSH 详细日志看卡在哪一步 ssh -vvv user192.168.1.101Windows 主机尤其注意防火墙默认情况下 22 端口出站入站可能都没放行。可以在“高级安全 Windows Defender 防火墙”里新增入站规则放行 TCP 22。Bitvise SSH Server 装好之后它一般会提示你是否自动创建防火墙规则如果当时手滑没选后面就连不上。host key 变化是另一个经典问题。重装系统或者虚拟机重置后管理机~/.ssh/known_hosts里还存着旧的 host keySSH 会因为 key mismatch 直接拒绝连接。第一次遇到这情况我不明所以后来学会用ssh-keygen -R 192.168.1.101把旧 key 从 known_hosts 里移除再重新连接即可。这在重装频繁的测试环境里几乎每周都要用一次。6.2 权限控制wheel 组与 root 登录的取舍多机编排时权限设计要非常谨慎。无限 root 权限的 AI 代理是灾难哪怕只是误操作也可能把系统配置改坏。我按热搜词里的问题展开说如何设置只有 wheel 组的用户可以 SSH 登录如何禁止或允许 root 登录编辑目标机器的/etc/ssh/sshd_config加入或修改以下配置AllowGroups wheel PermitRootLogin no第一行的含义是只有主组属于 wheel 的用户才能 SSH 登录。如果用户不在 wheel 组里就用 root 身份执行usermod -a -G wheel username第二行是禁止 root 直接 SSH 登录。这属于安全基线建议保持no。如果个人调试环境确实需要 root 登录可以改成prohibit-password表示只允许密钥登录禁止密码登录。但我的建议是不要图省事开 root 直连日常任务用普通用户加 sudo 足够。修改配置后要重启 sshdsudo systemctl restart sshd这一步非常容易把当前会话搞断因为它重启的是 SSH 服务本身。如果你是在远程改的配置建议先用sudo sshd -t检查语法确认无误后再重启否则配置写错了你可能连不上机器只能去机房或者带外管理卡救援。6.3 GitHub 远端仓库连不上port 22 connection refused 的另一种解法做多机编排的时候很多任务需要从 GitHub 拉代码这时经常遇到ssh: connect to host github.com port 22: Connection refused。这个报错我们在热搜词里也看到了非常普遍。原因是当前网络环境下GitHub 的 22 端口访问不稳定甚至被阻断。GitHub 官方提供了一种替代方案通过 443 端口走 SSH 连接。在管理机的~/.ssh/config里加一段Host github.com HostName ssh.github.com Port 443 User git配置好之后测试ssh -T gitgithub.com成功的话会返回类似Hi username! Youve successfully authenticated的输出。这个方案不涉及任何特殊网络工具只是改变了 SSH 连接的端口和目标域名是官方支持的常规做法。如果你在多台受控机上都要拉 GitHub 代码记得每台机器的 SSH config 都要加上这段因为远端机器连 GitHub 时走的是它自己的网络出口。另外注意全局 Git 配置和 SSH config 是两回事。SSH config 解决的是“连接 GitHub 的网络通道问题”如果你遇到的是推送时提示没有权限那是 SSH key 没有在 GitHub 账号里注册需要在 GitHub 的 Settings → SSH and GPG keys 里把公钥加进去。6.4 跨平台执行命令时最容易翻车的两个小细节第一个是路径分隔符。Windows 用反斜杠\Linux/macOS 用正斜杠/。通过 SSH 在远端执行命令时路径写法稍有不对就会报错。我习惯在编排层就约定好Windows 节点统一用 cmd 能识别的路径写法Linux 节点用正斜杠不让同一套命令直接跨两端复用。第二个是换行符。Windows 的文本文件默认是 CRLF 行尾Linux 是 LF。如果你在 Windows 上创建了一个脚本直接拷到 Linux 上执行经常出现$\r: command not found的诡异报错。解决方案是在 Linux 上用sed -i s/\r$// script.sh转换一下或者让 Claude Code 在修复时顺便注意保持 LF。这些事看着小累积起来非常消耗耐心。还有一个容易被忽略的是 Windows 默认编码。Windows 控制台默认代码页可能是 GBK而 Linux 上一般默认 UTF-8。如果 Windows 上的脚本输出中英文混杂SSH 回传的内容在 Linux 管理机上看就可能乱码。我处理的方法是尽量在命令前面加上chcp 65001把代码页切到 UTF-8保证输出对齐。6.5 编排初期的稳定性建议最后给想直接上手的朋友一个建议不要一开始就把所有机器都接入编排系统先找一台不重要的机器最好是虚拟机把 SSH 免密、Claude Code 安装、Hermes Agent 任务调度整个链路完整跑一遍确认所有环节都稳定了再加第二台、第三台。我自己踩过的最大坑是太早信任自动化把一台生产用的 Windows 主机接入后AI 在一次“修复测试失败”的任务中顺手改了系统环境变量导致好几个服务重启后起不来。从那以后我在所有受控机上都给 AI 用的系统账号尽量瘦身权限只给到对应项目目录和必要的构建工具能不给管理员权限就不给。这套 Hermes Agent SSH Claude Code 的多机编排方案我用下来的总体感受是初期搭建确实要花点时间但链路一旦稳定日常“跨平台改代码跑测试”这件事的精力消耗会降一个量级。如果你也正被多台机器来回切换折磨不妨照这个思路先把最小链路搭起来跑通第一个任务之后你会回来感谢自己当初这几小时投入的。