前阵子我整理开发环境的时候，意识到一个有点尴尬的现实：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 通常自带 OpenSSH，Linux 端需要确保 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 'Automatic'Bitvise 的安装则更直白，一路 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-id：
ssh-copy-id -i ~/.ssh/id_ed25519.pub username@192.168.1.100Windows 受控端手动一点，把公钥内容追加到C:\Users\你的用户名\.ssh\authorized_keys，注意这个文件要用 UTF-8 无 BOM 格式保存，不要用记事本默认的带 BOM 编码，否则密钥匹配会失败。这一步我当初卡了很久，后来用 VS Code 重新保存才解决。
一个容易忽略的点是权限。Linux 上~/.ssh目录应该是 700，authorized_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_KEY=xxxx。
4. Claude Code 在受控端的落地：安装、VSCode 集成与多配置管理
4.1 在远端机器上安装 Claude Code 并确认可用
Claude Code 是 Anthropic 出品的编程 Agent，可以在终端里直接交互，也可以用-p参数走非交互模式，这个特性特别适合被外部编排系统调用。
在每台受控端机器上安装，用到的是 npm：
npm 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 --tb=short"这里我用了cd /d是因为 Windows 默认 shell 是 cmd，和 Linux 的cd行为不同。如果后续测试 failures 很多，建议把输出重定向到文件里，别让终端刷屏：
ssh win-dev "cd /d D:\projects\pyapp && python -m pytest --tb=short > test_output.txt 2>&1 && 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 user@192.168.1.101Windows 主机尤其注意防火墙，默认情况下 22 端口出站入站可能都没放行。可以在“高级安全 Windows Defender 防火墙”里新增入站规则放行 TCP 22。Bitvise SSH Server 装好之后它一般会提示你是否自动创建防火墙规则，如果当时手滑没选，后面就连不上。
host key 变化是另一个经典问题。重装系统或者虚拟机重置后，管理机~/.ssh/known_hosts里还存着旧的 host key，SSH 会因为 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 足够。
修改配置后要重启 sshd：
sudo 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 git@github.com成功的话会返回类似Hi username! You've 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 的多机编排方案，我用下来的总体感受是：初期搭建确实要花点时间，但链路一旦稳定，日常“跨平台改代码跑测试”这件事的精力消耗会降一个量级。如果你也正被多台机器来回切换折磨，不妨照这个思路先把最小链路搭起来，跑通第一个任务之后，你会回来感谢自己当初这几小时投入的。
