企业官网建设流程全解析

开头

你有几台机器，却在每台机器上重复装 Agent、重复登录、重复维护提示词？更难受的是，手头的 Windows 机器性能一般，真正有 GPU 的 Linux 服务器却闲着，macOS 上写的工程又只能在本地验证。今天我聊的这套方案，就是用 Hermes Agent 做调度中枢，通过 SSH 把不同的 Claude Code 实例串起来，实现跨平台、跨机器的统一调度。简单说，你坐在一台笔记本前，一条指令下去，Linux 服务器帮你跑后端任务，Windows 工作站帮你查 .NET 工程，macOS 上负责 Swift 编译验证，全部自动完成。

这篇文章适合谁？已经装过 Claude Code、想把它从单机玩具变成实际生产力的人；手头有多台开发机、想把算力和系统环境盘活的人；以及正在研究 Hermes Agent 多机编排但被文档绕晕的人。我会把从密钥配置、sshd 加固、Agent 连接、到一次真实跨平台调度的完整过程都写出来，踩过的坑也会一并列出，照着走基本能跑通。

1. 整体设计与思路拆解

1.1 为什么要搞多机编排，而不是每台机器各自为战

单机使用 Claude Code 时，最常见的痛点是“上下文和任务都被绑死在当前会话里”。你在 Windows 上跑一个任务，想再切到 Linux 服务器上跑，得重新登录终端、重新配环境、重新把相关代码传过去。如果任务一多，整个人就变成了人肉交换机，效率极低。

多机编排的核心价值，是把“任务分发”这件事从人脑里抽出来，交给一个统一的调度层去管理。比如我自己的习惯是这样的：本地只留编辑器和轻量检查，复杂的静态分析交给 Linux 服务器，涉及 Windows 平台 API 的生成任务交给 Windows 工作站，涉及 Apple 生态的代码验证交给 macOS。每台机器上的 Claude Code 就是一个随时待命的“代码工人”，Hermes Agent 则是派活的人。

这个设计还有一个容易被忽略的好处：隔离。某些大型任务会反复读写目录、安装依赖，如果在本地跑，很可能把你正在用的开发环境搞得一团糟。把它调度到远程机器上，哪怕任务把远程环境搞坏了，也无所谓，换一台机器或重建实例就行。这种容错性，单机方案给不了。

1.2 Hermes Agent 与 Claude Code 各自扮演什么角色

用一句话概括它们的关系：Hermes Agent 负责人和机器，Claude Code 负责代码。

Claude Code 本质上是 Anthropic 推出的命令行编程助手，能读代码、改代码、执行命令、搜索文件，它天然适合当“执行单元”。但它没有多机概念，你在哪台机器上启动它，它就只能操作那台机器的文件系统。Hermes Agent 则是编排者，它维护着一个远程主机清单，知道每台机器的操作系统、可用资源、SSH 连接方式，并负责把任务发给指定机器上对应的 Claude Code 实例。

注意，这和简单地在远程终端里敲claude不一样。Hermes Agent 做的事情更像是一个消息队列加调度器：你可以提前定义任务模板，比如“帮我 review 某个目录的代码”“生成某个模块的测试用例”，然后把任务批量分发到不同机器上，结果统一回收。用生活类比就是：Claude Code 是各个城市的分公司员工，Hermes Agent 是总部的调度台，它只负责说“上海同事处理华东客户，北京同事处理华北客户”，具体怎么干活全由分公司决定。

1.3 为什么传输层选 SSH，而不是自研 HTTP 接口

远程调度的方案有好几种，最常见的思路是写一个 Web 服务挂在每台机器上，用 HTTP 接口来收任务。这个思路可以实现，但我个人的建议是：如果条件允许，优先走 SSH。原因有三点。

第一，SSH 是自带加密和认证的成熟协议，你不需要自己实现鉴权、加密、防重放，省掉一大截安全设计的成本。第二，SSH 生态里有大量现成工具，密钥管理、端口转发、SFTP 文件传输都能直接用，排查问题时用ssh -v就能看到详细握手过程。第三，SSH 在很多内网环境下天然可达，尤其是开发机之间往往已经开通了 22 端口，不需要额外开放其他服务端口，攻击面更小。

有人会担心 SSH 并发不够用，其实对于个人开发和中小团队场景，几十路并发 SSH 连接完全不是问题。真到大规模集群调度，那就不是这个方案的适用场景了，应该去用 Kubernetes 之类的专业编排工具。

2. 环境准备与安装部署

2.1 角色划分与机器规划建议

动手之前，先把机器角色理清楚。我建议至少规划三类机器：

• 控制端：部署 Hermes Agent，用来下发任务、回收结果。通常就是你的主力开发机。
• 执行端：部署 Claude Code，并开启 SSH Server。承担实际代码生成和验证任务，可以有多台。
• 文件服务端（可选）：如果涉及大量代码仓库同步，可以用一台机器做 Git 仓库或共享目录，调度任务前先同步代码。

实际操作中，控制端和执行端可以复用，比如你本地既跑 Hermes Agent，也作为一台执行端给其他机器提供服务，这是没问题的。但为了演示清晰，我建议至少准备两台机器，一台 Linux、一台 Windows，这样最能暴露跨平台问题。

2.2 Hermes Agent 与 Claude Code 的安装细节

Hermes Agent 的安装方式以官方文档为准，常见的做法是通过 npm 全局安装。安装后第一次启动通常会有一个身份绑定的环节，很多人在这一步卡住——安装完运行hermes命令，提示要打开某个网页登录，这是正常的，它需要在官网完成身份绑定后才能拉取配置和密钥，并不是安装出错。如果你在离线环境或内网环境，需要确认控制端能访问到官网的认证服务。

Claude Code 的安装相对简单，大多数平台直接执行：

npm install -g @anthropic-ai/claude-code

然后在终端运行claude进入交互模式，按提示完成登录。这里有一个需要注意的点：如果公司网络或组织策略限制了 Anthropic 订阅服务，登录时可能报“your organization has disabled claude subscription access for claude code”之类的错误，这个我在后面常见问题部分会专门讲怎么处理。

如果你的执行端并不直接使用 Anthropic 官方账号，而是走第三方模型网关（例如阿里云百炼平台）或者本地模型服务，那需要在启动 Claude Code 之前设置对应的环境变量，指向自定义 API 地址和密钥。别一上来就纠结哪家模型强，先把通道打通再说。

2.3 三平台开启 SSH Server 的完整步骤

执行端机器要想被 Hermes Agent 远程控制，前提是开启 SSH 服务。这里把 Linux、Windows、macOS 三平台的开启方式列一下。

Linux（以欧拉、麒麟、Ubuntu 等为例）

# 安装 SSH 服务端（Debian/Ubuntu 系） sudo apt install openssh-server # 启动并设置开机自启 sudo systemctl enable --now sshd # 确认端口在监听 sudo ss -tlnp | grep 22

如果你用的是欧拉（openEuler）或银河麒麟这类系统，而且机器无法联网，需要提前准备好 openssh 的 rpm 升级包进行离线安装。离线安装时要注意架构匹配，ARM 架构和 x86_64 的包不能混用，别下错了。

Windows

Windows 10/11 自带 OpenSSH Server，可以通过 PowerShell 开启：

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0 Start-Service sshd Set-Service -Name sshd -StartupType 'Automatic'

如果自带功能开启后有问题，另一个选择是安装 Bitvise SSH Server，它提供图形化配置界面，在 Windows 上管理起来更直观，还内置了虚拟账户和 SFTP 服务。我个人在 Windows 执行端上用 Bitvise 的情况更多，尤其是需要精细控制端口转发和用户权限时。

macOS

macOS 开启 SSH 最简单：系统设置 → 通用 → 共享 → 打开“远程登录”。也可以在终端里执行：

sudo systemsetup -setremotelogin on

macOS 的 SSH 配置路径是/etc/ssh/sshd_config，和 Linux 基本一致，后续的加固操作同样适用。

3. 配置 SSH 远程调度的关键细节

3.1 密钥对生成与免密登录配置

Hermes Agent 控制端与执行端之间，我强烈建议用密钥认证而不是密码认证。密码认证最大的问题是不方便自动化，而且反复输密码的体验会让你很快放弃这套方案。生成密钥的过程如下：

ssh-keygen -t ed25519 -C "hermes-agent-control"

一路回车会在~/.ssh/id_ed25519和~/.ssh/id_ed25519.pub生成密钥对。然后把公钥拷贝到执行端：

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-host

Windows 执行端没有ssh-copy-id，需要手动把公钥内容追加到目标机器对应用户的authorized_keys文件中。这里的路径要格外小心：OpenSSH for Windows 读取的授权文件一般位于C:\Users\用户名\.ssh\authorized_keys，而不是某些教程里说的ProgramData目录，放错了会导致密钥认证失效。

另外，.ssh 目录的权限要收紧。Linux 上执行端的~/.ssh必须是 700，authorized_keys必须是 600，权限过宽时 SSH 会直接拒绝密钥认证，只允许密码登录，这个问题很隐蔽，我当时排查了挺久才发现是权限问题。

3.2 安全加固：如何限制只有指定用户组能登录

如果你不想让所有系统用户都能通过 SSH 访问执行端，最好在sshd_config里做限制。以 Linux 为例，编辑/etc/ssh/sshd_config：

# 只允许 wheel 组的用户登录，注意与 AllowUsers 二选一，不要同时使用 AllowGroups wheel # 禁止 root 直接登录，使用普通用户登录后再提权 PermitRootLogin no # 只允许密钥认证，关闭密码登录 PasswordAuthentication no PubkeyAuthentication yes

保存后重启 sshd 服务：

sudo systemctl restart sshd

这里有个容易踩的坑：如果你把当前登录用户从 wheel 组里挪出去了，或者 PermitRootLogin 设成了 no 但你本来只靠 root 登录，重启服务后你就把自己关在门外了。所以每次改 sshd 配置后，先不要关掉当前会话，另开一个终端连接测试一下，确认没问题再退出。

如果你希望 Hermes Agent 用 root 身份来执行某些高级任务，可以通过“先普通用户登录，再 sudo 提权”的方式，而不是直接打开 root 的 SSH 登录。除非是在隔离的测试环境，否则我不建议放开PermitRootLogin yes。网上有不少“如何取消限制、让 root 也可以 SSH”的帖子，那种操作在生产环境要非常谨慎。

3.3 Hermes Agent 多机连接配置的落地写法

Hermes Agent 具体怎么声明远程机器，不同版本的配置格式会有些差异，但核心思路是一致的：给每台执行端定义一个别名，指定主机地址、SSH 用户、密钥路径和标签。

以我自己用的一个简化配置为例：

remote_hosts: - name: linux-gpu host: 192.168.1.101 user: dev identity_file: ~/.ssh/id_ed25519 tags: [linux, gpu, backend] - name: win-dev host: 192.168.1.102 user: dev identity_file: ~/.ssh/id_ed25519_win tags: [windows, dotnet, frontend] - name: mac-build host: 192.168.1.103 user: dev identity_file: ~/.ssh/id_ed25519 tags: [macos, swift, ios]

配置好之后，先手动测试每一台机器能否免密连通：

ssh -i ~/.ssh/id_ed25519 dev@192.168.1.101 "echo hello"

如果这一步能直接输出 hello，就说明 SSH 层完全打通。此时再启动 Hermes Agent，它就能通过这个配置自动连接各台执行端，把任务按标签路由到正确的机器上。

顺便说一句，如果你有多台机器要管理，建议在~/.ssh/config里给每台机器写一个 Host 别名，比如：

Host linux-gpu HostName 192.168.1.101 User dev IdentityFile ~/.ssh/id_ed25519

这样后面无论用ssh linux-gpu还是 Hermes Agent 加载配置，都会方便很多，还不用记 IP。

4. 实操全流程：从控制端调度一次跨平台任务

4.1 准备一个能体现跨平台优势的任务

理论讲得再多，不如现场跑一个任务。我实际测试时用了这样一个场景：一个全栈小项目，需要同时在三个平台上生成代码。

• Linux 执行端：生成 Python 后端接口文件。
• Windows 执行端：生成 .NET 平台的配置类和依赖注入代码。
• macOS 执行端：生成 Swift 的数据模型，并做一次编译验证。

在控制端进入项目目录，用 Hermes Agent 的交互模式或命令行指令分别下发任务。以命令行形式为例：

hermes run "为订单模块生成 Python FastAPI 接口文件，包含 CRUD 和校验逻辑" --host linux-gpu

hermes run "为订单模块生成 .NET 服务注册代码，使用依赖注入风格" --host win-dev

hermes run "为订单模块生成 Swift 数据模型，编译验证无误后输出结果" --host mac-build

下发后，控制端的输出会显示每台执行端的连接进度和任务状态，比如“开始连接 win-dev”“任务已在 win-dev 上启动”“等待执行结果”等。Claude Code 在远程机器上的实际表现，和你本地使用完全一样，它会创建会话、读取代码、执行命令，只是这些操作发生在那台远程机器上。

4.2 结果回收与文件同步的常用方法

任务执行完后，一个很现实的问题浮出水面：远程机器生成的文件怎么回到控制端？

最简单的办法是 Git。如果项目代码已经放在一个 Git 仓库，执行端完成任务后自动 commit 并 push，控制端 pull 即可。但很多场景下项目还没纳入版本管理，或者出于安全考虑不想让执行端持有仓库写权限。

这种情况下，我一般让 Claude Code 把输出文件写到远程机器上的某个固定目录，然后用scp或rsync一次性拉回：

rsync -avz -e "ssh -i ~/.ssh/id_ed25519" dev@192.168.1.102:/output ./local-output

这里有个实操经验：如果你把生成目录也作为 Hermes Agent 执行端的“工作目录”，那长期跑下来远程机器会积累大量临时文件。建议在任务模板里加一条“完成后自动清理中间文件”的指令，只保留最终交付物，不然磁盘撑爆只是时间问题。

4.3 用 VSCode 连接远程主机辅助调试

如果你在配置或执行阶段遇到问题，光靠 Hermes Agent 的日志排查不够直观，我建议直接用 VSCode 的 Remote-SSH 插件连到执行端去看现场。

操作很简单：VSCode 安装 Remote-SSH 扩展后，按 F1 输入 “Remote-SSH: Connect to Host”，选择你之前在 ssh config 里配好的主机。连上之后，VSCode 会像本地一样打开远程目录，你可以直接打开终端运行claude手动测试，也可以检查远程机器上的文件是否生成正确。这个手段对排查三类问题特别管用：一是确认远程 Claude Code 是否正常登录；二是确认执行端的目录权限是否正确；三是手动复现 Hermes Agent 下发的那条任务，看是否真的能跑通。

再补充一点，Remote-SSH 本身也是一种验证 SSH 配置的好工具。如果 VSCode 能连上，说明密钥、sshd 服务、网络这些基础链路都没有问题，问题只可能出在 Hermes Agent 这一层。

5. 常见问题与排障实录

5.1 SSH 连接类的典型报错与处理

报错：Permission denied (publickey)

这个报错 90% 是密钥认证没通过。按顺序检查四件事：执行端~/.ssh/authorized_keys里有没有你的公钥；公钥文件权限是否太大，要求~/.ssh是 700、authorized_keys是 600；控制端指定的私钥路径是否正确；sshd_config里PubkeyAuthentication是否被设成了 no。排查时不要干猜，直接执行ssh -v -i ~/.ssh/id_ed25519 dev@host，看输出里有没有 “Offering public key” 和 “Server accepts key” 这两行。

报错：Connection timed out

先确认目标机器 IP 是否可达：ping 目标IP。再确认 22 端口是否开放：telnet 目标IP 22或nc -vz 目标IP 22。如果是 Windows 执行端，特别容易忘记启动 sshd 服务——很多人以为装了功能就自动运行了，其实需要手动 Start-Service。如果目标机器上有防火墙，记得放行 22 端口。

报错：Host key verification failed

这是因为控制端的known_hosts里记录的指纹和执行端实际指纹不一致，常见于执行端系统重装或容器重建。解决方法是手动清理对应主机的旧指纹：

ssh-keygen -R 192.168.1.101

然后重新连接即可。我建议在多机调度场景里，每台执行端尽量使用固定 IP 或固定主机名，能减少这类问题的发生频率。

5.2 Claude Code 远程执行时报错的处理

报错：your organization has disabled claude subscription access for claude code

这个报错看起来吓人，其实只是当前机器上的 Claude Code 登录身份没有访问权限。如果你用的是组织账号，而组织策略禁止了 Claude Code 使用，那就需要联系管理员调整策略，或者改用自己的个人订阅账号登录。如果公司统一走第三方模型网关，那就检查环境变量是否在 Hermes Agent 执行远程命令时被正确传递了。很多情况下，Hermes Agent 通过 SSH 执行命令是一个非交互式的 shell，环境变量和本地交互终端不一样，容易漏掉ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN之类的配置。解决办法是把环境变量写进执行端用户自己的~/.bashrc或~/.zshrc，而不是只在控制端设置。

远程 Claude Code 提示未登录

这种场景一般发生在执行端是全新机器、还没有执行过claude登录时。Hermes Agent 能通过 SSH 连上机器，但机器上的 Claude Code 还没有身份凭证。解决办法是先用 VSCode Remote-SSH 或普通终端登录到执行端，手动执行claude完成一次登录；如果执行端走的是第三方网关，把网关的 Key 写入对应环境变量后，启动一次 Claude Code 验证可用，再回过来让 Hermes Agent 调度。

5.3 Hermes Agent 部署类问题小结

“安装要登录网站”是不是装的有问题？

不是。这是 Hermes Agent 首次启动时的身份绑定流程，需要在官网完成登录授权，然后把凭证同步到本地。如果公司网络连不上官网认证服务，后面的调度功能就用不了，这属于环境网络访问限制问题，不是安装包本身的问题。

Windows 桌面版安装报错

优先检查两个东西：Node.js 版本是否过低，以及系统是否缺少 VC++ 运行库。如果报错信息指向某个原生模块，先升级 Node 到 LTS 版本，再重新安装。实在不行就退回命令行版，实际使用中命令行版和桌面版的核心调度能力基本一致。

欧拉或麒麟这类国产系统离线环境怎么装 openssh

提前准备好对应系统版本和架构的 rpm 包，使用rpm -Uvh进行升级安装。注意 ARM 架构（aarch64）和 x86_64 的包要区分，装错之后会直接起不来 sshd。离线环境还常见一个问题：执行ssh-copy-id依赖ssh客户端，有些精简系统连 ssh 客户端都没有，需要一并安装。

5.4 多机调度场景的优化技巧

机器多了之后，每次全量测试所有执行端是否在线会很烦。我的做法是写一个简单的批量探测脚本：

for host in linux-gpu win-dev mac-build; do if ssh -o ConnectTimeout=3 -o BatchMode=yes "$host" "echo ok" 2>/dev/null; then echo "$host: online" else echo "$host: offline" fi done

BatchMode=yes的作用是禁用密码交互，如果密钥认证失败会直接返回错误，不会卡在那里等人输密码。这个脚本可以作为 Hermes Agent 任务下发前的预检工具，避免任务发到一台离线机器上然后干等超时。

6. 进阶方向：把远程机器变成模型能力扩展池

多机编排跑通后，可以进一步做的方向是：把其中某些执行端变成“模型能力扩展池”。比如有一台 Linux 机器本地跑着 Ollama，可以通过配置第三方供应商的方式，让远程的 Claude Code 使用本地模型进行推理，而不是依赖云端 API。这样做的好处是数据不出内网，适合处理敏感代码。

工具链上比较顺手的组合是 cc-switch 加 Ollama。cc-switch 负责快速切换 Claude Code 的模型供应商，Ollama 负责提供本地推理服务。你可以在执行端把供应商切到 Ollama 的本地端点，然后照常通过 Hermes Agent 调度。实测下来，本地模型的代码生成质量确实和云端大模型有差距，但胜在稳定和私密，适合做代码补全和格式整理这类低风险任务。

还有人问过我：draw.io 这类架构图工具能不能和 Hermes Agent 对接？严格来说 draw.io 有自己的命令行导出工具，你可以让远程执行端的 Claude Code 生成.drawio格式的 XML 文件，再调 draw.io 的命令行导出 PNG 或 SVG。这不是原生集成，但通过任务模板完全可以实现，算是一个挺实用的小扩展。

7. 写在最后的几条实操心得

这套方案我用了大概两个月，整体跑下来最深的体会是：多机编排能大幅省时间，但前提是 SSH 这个底座必须稳。我前两周几乎天天在调密钥、调 sshd 配置，一旦底座稳了，后面调度任务就非常顺。

有几个细节特别想强调一下。第一，执行端尽量固定 IP，或者至少保证主机名可解析，否则你会在 known_hosts 指纹冲突上反复踩坑。第二，给 Hermes Agent 创建专用的低权限账号，能避免它远程执行时拥有过高的系统权限，也方便审计它到底在哪些机器上做了什么。第三，每次改完 sshd_config 之后，千万先保留当前连接，另开终端验证没问题再退出，别把自己锁在门外，这个错误我真的犯过。

最后一件事，如果你打算让远程任务自动把代码 commit 到 Git 仓库，记得单独配置执行端的 Git 身份（user.name 和 user.email），别让它用系统默认的 root 身份去提交。这些小细节看着不起眼，但往往就是它们决定了一套多机方案是从此稳定运行，还是三天两头需要你来救火。