最近我折腾了一套远程开发的组合拳桌面上跑 Hermes Agent 当中枢通过 SSH 把任务派给另一台 Linux 服务器上的 Claude Code让它自己在那边写代码、跑测试再把结果同步回来。整套流程跑通之后最直观的感受是笔记本风扇终于不吵了好几个项目可以并行走也不用再人肉切终端。很多朋友看到 Hermes Agent、Claude Code、SSH 这几个词堆在一起就觉得是重活其实拆开看没那么玄乎。这套方案本质上解决的是两件事一是把 Claude Code 从本地挪到远程节点让执行环境更干净、资源更充足二是通过 SSH 把多个节点串起来由 Hermes Agent 统一调度实现跨平台的多机编排开发。适合正在用 Claude Code 写正经项目、嫌本地机器吃力、或者手上正好有闲置服务器或 NAS 的朋友参考。1. 为什么要把 Claude Code 放到远程节点上跑1.1 本地开发容易踩的三个坑先说我自己的经历。刚用 Claude Code 的时候我直接在笔记本上跑遇到的第一关就是资源不够。上下文窗口、会话缓存、编辑器、构建工具全挤在同一台机器上16G 内存的机器经常眼看着就满了。任务一大Claude Code 响应速度明显下滑甚至直接卡死整个终端只能强杀。这等于把 AI 编码的体验毁掉了一半。第二个坑是环境不一致。我本地是 Windows公司测试机是 Linux两边装的依赖版本、路径规则、沙箱行为都不一样。Claude Code 在本地生成的东西推到远端经常跑不起来最后还得手动改配置。很多人在本地跑得欢一到 CI 就翻车根子就在这里。第三个坑是多任务并行时的手忙脚乱。手头同时有两个项目就需要开两个 Claude Code 实例分别盯着不同目录。项目一多终端标签页开十几个哪个任务是哪个项目都分不清。多机编排把这些痛点全部按住了执行放到远程节点环境在服务器上统一任务分发交给 Hermes Agent本地只保留一个控制台看输出结果。1.2 Hermes Agent 在编排里到底干啥Hermes Agent 是一个面向 AI 代理的编排调度框架。你可以把它理解成代理的中控台你在它里面定义节点和任务它负责把任务派给不同节点上的真实执行体比如 Claude Code、Codex或者普通的 Shell 命令然后收集执行结果按你制定的规则做后续处理。它的核心价值不是替代 Claude Code而是把人肉在多个终端之间来回切换变成一条指令拆成 N 个子任务自动分发到对应机器。本地部署也比较轻量装好之后一个配置目录、一个 CLI 就能跑起来。网上常说的 Hermes Agent 的 Pantheon 组件生态其实就是一堆可插拔的功能模块名字听起来唬人本质跟应用商店差不多按需装就行。1.3 多机编排的核心逻辑和适用场景这套体系的控制流可以简化成图你面前的电脑是控制端上面跑 Hermes Agent远程的服务器、NAS、云主机是执行节点节点上安装并登录好 Claude Code中间用 SSH 隧道做连接任务形态是指令 工作目录 期望产物。用生活里的例子类比就是Hermes Agent 是快递分拣中心Claude Code 是各片区的快递员SSH 是连接它们的路。你只需要把包裹丢进分拣中心它自己决定派哪个快递员、走哪条路去送。所以多机编排并不是让每台机器都装一套完整开发环境远程节点只要有运行时、Claude Code CLI 和登录凭据就够了。适用场景其实很明确本地性能不足、需要统一 Linux 构建环境、多个项目并行需要隔离执行、或者团队里有一台闲置的高配服务器想物尽其用。如果你只有一台电脑也不是不能用但多机编排的收益会打不少折扣。2. 部署准备先装 Hermes Agent再装 Claude Code2.1 Hermes Agent 本地部署要点Hermes Agent 的部署本身不复杂但有几个细节值得注意。以常见安装方式为例先确保本机有 Node.js 18 或 Python 3.10 环境然后执行安装命令npm install -g hermes-agent hermes-agent --version或者 Python 版本pip install hermes-agent hermes-agent init初始化之后会生成一个配置目录里面主要是节点列表、认证方式、任务定义这些内容。不同版本的配置字段名可能会有差异所以装完先跑一遍hermes-agent --help和hermes node --help把当前版本支持的子命令摸清楚再动手能省掉不少折腾时间。Windows 上部署有一个让我印象很深的坑如果用户目录带中文名或者项目路径有空格部分版本的 Hermes Agent 在拼接远程命令时会出问题。建议安装路径和后续工作目录都用纯英文路径。另外 Windows 防火墙很可能会拦截 Agent 监听的本地端口第一次启动如果发现控制台一直连不上先去防火墙放行对应端口。2.2 Claude Code 安装登录与配额常识Claude Code 的安装就直白很多执行npm install -g anthropic-ai/claude-code claude --version首次运行claude会走登录流程通常是浏览器授权或 API Key 两种方式。登录成功后凭据会存在用户目录下的.claude文件夹里。这一步很关键只有完成登录的节点才有资格被远程遥控执行编码任务。多机编排场景下配额管理是个容易被忽略的大问题。Claude Code 账号通常有每周限额和并发会话限制多节点同时跑任务非常容易触发限流终端里会出现类似 weekly claude code limit is 50% 的提示。比较稳妥的做法是给不同节点规划不同的额度来源主节点用订阅额度子节点用独立的 API Key 按量计费。否则你会发现机器是闲下来了账号额度却一天就烧光了。2.3 跨平台环境的差异对照跨平台部署的时候不同系统踩的坑完全不一样。我自己实际跑下来列了一张对照表给刚开始搞的人当参考环境优势常见坑Windows 控制端日常开发工具链全路径分隔符、PowerShell 版本、中文用户名macOS 控制端自带 OpenSSH终端体验最好远程任务里的启动器要用 zsh tmux 才稳Linux 执行节点环境干净最适合跑服务部分发行版默认没装 openssh-serverNAS / 云主机24 小时在线适合长任务端口映射、家目录权限、SSH 服务版本偏老补充一个具体的例子我的远程节点是一台跑 Ubuntu 的旧服务器按理说是最省心的环境结果装完系统之后发现 SSH 根本连不上一查是 Ubuntu Desktop 默认不带 openssh-server执行sudo apt install openssh-server才解决。另外如果你用的是麒麟这类国产 Linux 发行版安装 SSH 服务的方式也类似只是软件包管理器不同用系统对应的rpm升级或者直接装openssh-server包即可核心流程没有差别。3. SSH 远程通道搭建与安全加固3.1 一步到位的 SSH 密钥生成和分发SSH 是整个编排体系的管道管道不通上层配置再漂亮都没用。我强烈建议直接用密钥登录而不是密码登录。一是因为编排场景需要无人值守密码方式没法批量处理二是因为密码登录在公网上就是活靶子日志里全是扫描尝试。生成密钥的命令ssh-keygen -t ed25519 -C hermes-agent-$(hostname) -f ~/.ssh/hermes_agent用 ed25519 而不是 rsa是因为它更短更快安全性也不差。生成后分发到远程节点推荐用ssh-copy-idssh-copy-id -i ~/.ssh/hermes_agent.pub userremote-host如果节点不支持ssh-copy-id手动把公钥追加到远程~/.ssh/authorized_keys也一样别忘了检查目录权限.ssh目录要是 700authorized_keys要是 600权限过宽会让 SSH 直接忽略这个文件。管理多个节点时强烈建议在本地维护~/.ssh/config给每个节点起一个短别名Host dev-node HostName 192.168.1.20 User ubuntu Port 22 IdentityFile ~/.ssh/hermes_agent Host nas-node HostName 192.168.1.30 User admin Port 2222 IdentityFile ~/.ssh/hermes_agent_nas配置好之后ssh dev-node就能直连完全不用记 IP、用户名、端口和密钥路径。Hermes Agent 里引用远端节点时很多场景也是依赖这套 SSH config 的安全连接能力。3.2 SSH 服务端连接不上的排查清单SSH 连不上是新手最容易卡住的位置。我把自己常走的排查路径整理成一个顺序清单照着做基本能定位问题。先看服务端是不是活着。执行systemctl status sshd或service ssh statusUbuntu 桌面版没装 openssh-server 的坑前面提过这是第一步就能发现的。接着看端口监听状态ss -tlnp | grep 22如果没有任何输出多半是 sshd 没起来或者换了端口。然后检查防火墙。sudo ufw status如果开着就要放行 22 端口或者你自定义的 SSH 端口。腾讯云、阿里云这类云主机还得检查控制台的安全组规则很多连不上的案例都是安全组没放行。再看认证配置。/etc/ssh/sshd_config里的PermitRootLogin、PasswordAuthentication、PubkeyAuthentication三个参数是重点。如果你明明用的是密钥服务端却一直要密码十有八九是PubkeyAuthentication被设成了 no或者是从 Windows 生成的公钥格式不对。最后看日志。Ubuntu 是journalctl -u sshd --no-pager -n 50也有发行版写在/var/log/auth.log。日志会直接告诉你失败原因是 Permission denied还是 Connection refused还是 no matching key exchange method对症下药才有意义。3.3 免密登录与批量节点的实测方法密钥分发完成以后一定要先手动验证一次免密登录ssh dev-node echo ok hostname如果秒回ok和主机名说明通道是通的。接着把 Hermes Agent 里的节点配置指到这个别名上再进行一次从 Agent 发起的远程命令测试。如果节点数量多逐个手动验证太累。我写过一个简单的批量验证循环把节点别名按行写进nodes.txt然后用BatchMode跳过交互式密码提示快速筛出有问题的节点for host in $(cat nodes.txt); do if ssh -o BatchModeyes -o ConnectTimeout5 $host hostname /dev/null 21; then echo $host OK else echo $host FAIL fi doneBatchModeyes这个参数以前经常被我忽略后来发现它特别适合在脚本里使用因为一旦密钥失效不会卡在交互式密码输入上而是直接失败返回脚本逻辑立刻就能发现问题。3.4 防扫描SSH 服务的安全基线既然把 SSH 暴露出来作为编排通道安全基线必须做。我最常接到的问题是我的 auth.log 里全是 Failed password是不是被攻击了这基本是常态只要用密码认证互联网上扫描器无时无刻不在试。处理思路有三个层次。第一层彻底改成密钥登录在/etc/ssh/sshd_config里把PasswordAuthentication设为no这是釜底抽薪。第二层如果条件允许把 SSH 端口从默认的 22 改成高位端口配合防火墙限制来源 IP能过滤掉绝大多数自动化扫描。第三层部署 fail2ban 这类工具对多次认证失败的 IP 自动封禁日志再也不会被刷屏。我给远程节点做完这三步之后auth 日志基本就清净了。顺手再提醒一句不要把堡垒节点用 root 直接登录新建一个普通用户给它sudo权限就够用了不要图省事。4. 实操用 Hermes Agent 编排两台机器干活4.1 编写节点与任务配置理论铺垫完了下面看一下真实的任务编排长什么样。我用一个实际跑通的场景做演示本地 Windows 机器是控制端远程 Ubuntu 服务器是执行节点任务目标是让远程的 Claude Code 生成一个 FastAPI 项目骨架然后跑测试最后把产物拉回本地。Hermes Agent 的配置这里按通用格式写不同版本的字段名可能略有差异核心思路一致nodes: - name: win-local type: local enabled: true - name: ubuntu-node type: ssh ssh_alias: dev-node workdir: /home/ubuntu/projects tasks: gen_fastapi: node: ubuntu-node command: claude -p create a FastAPI project with GET / and GET /health, write files into /home/ubuntu/projects/demo如果你装了 Hermes Agent 之后不知道从哪下手先跑一下hermes node list看节点是否在线再去hermes task run --help看任务命令的写法。我个人的习惯是先把节点配置好、用hermes node exec手动跑一条简单命令验证连通性再开始定义任务不要一步到位写复杂任务。4.2 远程跑 Claude Code 生成代码节点在线之后就可以把真正的工作派下去了。用 Claude Code 的无头模式claude -p指定一次性提示词非常适合自动化调度因为不需要交互式终端stdout 会把结果完整返回退出码也遵循 Unix 惯例。从 Hermes Agent 发起远程执行逻辑上类似这样hermes node exec ubuntu-node -- claude -p create a FastAPI project with GET / and GET /health, write files into /home/ubuntu/projects/demo任务执行过程中Hermes Agent 会实时收集远程节点的输出。这一步的体验比较像在看一条正在跑 CI 的流水线日志你不需要切到远端机器就能确认进度。任务跑完先别急着高兴验证产物是否合格才是关键。在远端把测试也一并跑掉hermes node exec ubuntu-node -- cd /home/ubuntu/projects/demo python -m pytest -q如果测试输出里有passed说明这次调度从提示词、代码生成到验证跑通了闭环。我第一次跑通这个流程的时候还挺感慨的因为整个过程中我除了写一行任务命令什么都没碰过远程机器。4.3 前后端分节点并行再回收结果单节点跑通只是第一步多机编排真正的甜头在并行。我的另一个项目需要同时生成前端组件和后端接口正好拆成两个任务派给不同节点。win-local : claude -p generate React Button component ... ubuntu-node : claude -p generate FastAPI route for login ...Hermes Agent 有一种批量派发的执行模式把多条命令一次性提交到不同节点并行跑全部结束后统一回收输出和退出码。如果这两个任务串行跑可能要花掉两倍的等待时间并行之后整体耗时只取决于最慢的那个任务。并行带来的一个额外好处是认领责任的边界更清晰前端项目在本地节点生成后端接口在 Linux 节点生成两边环境互不污染。出问题的时候直接看对应节点的日志不用再猜是哪个环境导致的。4.4 任务结果自动同步回本地远程节点生成了代码最终还是要同步回本地开发机看看效果。最朴素的做法是手动执行 rsyncrsync -avz ubuntu-node:/home/ubuntu/projects/demo ./result不过既然是编排场景我更推荐把同步这一步也挂到任务链路上。在 Hermes Agent 的任务配置里加一个on_complete钩子任务成功退出后自动执行 rsync把远端产物拉回本地指定目录。这样整个流程就变成本地发起任务 → 远端执行代码生成 → 自动跑测试 → 自动同步产物全程不需要人工介入。这个自动同步的步骤是我在实际使用中认为价值最高的设计。它让跨平台开发真正有了体感本地写提示词远端干活最终产物出现在你面前时就像在本地写代码一样无缝。5. 常见问题与排查技巧实录5.1 SSH 与 VS Code Remote 连接问题速查多机编排用得多了以后SSH 层的问题基本踩了个遍。这里给一个速查表是我自己排查时的行动指南症状可能原因优先排查动作Connection timed out安全组/防火墙拦截检查云安全组、ufw、sshd 监听端口Connection refusedsshd 没起或端口不对systemctl status sshdss -tlnpPermission denied (publickey)密钥没配对或权限错检查 authorized_keys、密钥文件权限Host key verification failedknown_hosts 记录过期或变更用ssh-keygen -R 主机IP清除旧记录VS Code Remote 卡在 SSH 初始化服务端缺依赖或版本太老更新系统自带 tar、curl检查 openssh 版本VS Code 远程开发是实现这套组合的一个好帮手。使用 Remote-SSH 连上服务器后常用的claude命令就能直接在远程终端里跑编辑体验与本地完全一致。之前有朋友问vscode 配好 claude code 之后远程连不上怎么办我第一反应就是先确认服务器上有没有装好openssh-server因为云上的镜像经常默认不装。再确认客户端密钥和服务端 authorized_keys 是否一致这两个问题覆盖了九成以上的情况。5.2 密钥权限和 Host key 校验报错免密登录明明配好了却一直提示要输密码或者直接拒绝我踩过太多次先说权限问题。OpenSSH 对密钥文件权限非常苛刻私钥不能对其他用户可读通常是 600~/.ssh目录要是 700。在 Windows 上用 vscode 或scp传过公钥之后尤其容易在权限上出问题因为 Windows 的文件权限模型和 Linux 不一样传到服务器上有时会带着过于宽松的 ACL。解决方法是登录服务器执行chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chmod 600 ~/.ssh/id_ed25519另外一个高频报错是Host key verification failed。这种情况通常发生在主机系统重装、IP 被重新分配之后本地~/.ssh/known_hosts里还保留着旧的主机指纹和新的对不上。解决方案就是手动清除旧记录ssh-keygen -R 192.168.1.20清完再连一次输入 yes 确认新指纹就能正常使用。自动化脚本如果遇到变更频繁的节点也可以在连接参数里加StrictHostKeyCheckingaccept-new仅接受新主机不会覆盖已验证的旧记录。5.3 Claude Code 限额与频率限制怎么避开多节点同时跑 Claude Code最容易踩的坑就是账号配额。我自己第一次批量跑任务的时候根本没意识到多个节点共用同一个账号结果跑不到半天就收到提示说可用额度已经用掉一半后面直接触发限流所有任务排队等待整个编排系统就像被按了暂停键。避开这个问题有几种策略。第一同一时间尽量只让一个节点跑重量级任务其他节点做轻量级辅助工作错峰调度。第二不同节点用不同的额度来源避免共享账号互相消耗。第三优先使用claude -p无头模式减少交互式会话的资源占用和时间跨度让单位额度完成更多任务。另外注意如果节点上保留了多个历史会话它会占用上下文窗口也会影响额度的使用效率。定时清理~/.claude下的历史会话缓存能让额度花得更值。5.4 Hermes Agent 任务不执行时的排查套路任务定义了节点也在线但hermes task run之后什么反应都没有这种情况我遇到过几次积累下来一套排查套路。第一先确认任务配置里的节点名和hermes node list里的一致配置里的 typo 是最常见原因。第二把任务命令拆出来直接在节点上手动跑一遍如果能跑通但 Agent 层不执行问题多半在 Agent 与节点的认证连接上。第三打开 verbose 日志看 Agent 执行到哪一步卡住是 SSH 连接失败、远程命令报错还是结果解析异常。我这里还有一个笨但好用的技巧先让 Agent 执行一个最简单、一定成功的命令比如echo test确认核心链路是通的再逐步往任务里加复杂度。很多人一上来就写完整任务失败后面对一堆输出根本分不清是哪一层出了问题这个习惯真的能省很多时间。写在最后的一点经验把这些折腾完以后我最想分享的其实是两条心法。第一先把 SSH 通道本身的稳定性做扎实再去碰编排功能两者依赖关系强顺序反了会到处碰壁。第二从小任务开始小到只是让远端跑一句hostname再慢慢让 Claude Code 生成文件、跑测试、做多机并行。很多人一上来就追求一句命令调度整个集群结果日志一长就懵了反而觉得这套工具不好用。先把一条链路走通后面所有的扩展都只是往配置里加内容和节点的事。如果你已经跑通了这套架构还可以往两个方向继续折腾一是接入本地模型做降级和补充比如 ollama 负责一些轻量任务Claude Code 专心处理复杂编码二是把 Hermes Agent 的编排能力和可视化工具做联动让任务状态、日志、产出物集中展示真正把一个个人 AI 开发集群管起来。这套玩法后续还有不少可以挖的空间等我把新方案跑通了再来分享。