企业官网建设流程全解析

1. 写在前面：为什么需要多机调度

我最近在折腾一套全新的开发工作流，核心需求一句话就能说清楚：让写代码的AI工具在远程主机上跑起来，然后我在本地机器上像指挥中心一样统一调度，按任务分发给不同机器执行。

这套方案的三个关键词——Hermes Agent、SSH、Claude Code——组合到一起，解决的是真实到不能再真实的痛点：AI编程工具越用越顺手，但它被绑死在一台机器上。你不可能要求办公室的Windows工作站和家里的Linux服务器装一套完全一样的环境，更不可能每次都开着远程桌面去点鼠标。更难受的是，当你同时要处理前端、后端、运维脚本、文档生成这些跨类型任务时，单机串行执行效率实在拉胯。

我实测的最终方案是：本地Windows作为控制端，通过SSH密钥连到两台Linux主机，其中一台专门跑Claude Code负责代码生成和修改，另一台用Hermes Agent做任务编排和命令分发，把整个开发过程拆成多个子任务，按机器负载和工具擅长度合理分配。实际跑下来，一次涉及三个模块的跨平台编译任务，从手动切换机器操作大约需要二十分钟，变成了一条命令五点七秒完成分发调度。

如果你是以下几类人，这篇内容对你应该很有用：手里有超过一台开发机的程序员，想把Claude Code用到远程环境里的AI工具使用者，或者对自动化编排感兴趣、想搭一套类似“任务中控台”的爱好者。我会把整套方案的架构思路、密钥配置、工具安装、实际操作步骤、踩坑记录全部摊开来讲，确保你照着做就能跑通。

2. 方案选型思路：为什么要用 Hermes Agent + SSH + Claude Code

2.1 单机开发的天花板在哪里

先说一个基本事实：Claude Code 这类终端导向的AI编程工具，本质上是一个在本地终端里跑起来的Agent，它能读懂你的代码仓库，调用工具执行命令、修改文件、运行测试。它非常强大，但它的工作环境默认就被限制在当前机器上。

这就带来三个很现实的问题。

第一，仓库在远程，代码跑不起来。你的开发机是Windows，但线上是Linux，依赖、路径、编译参数都可能不一样。你让Claude Code改了代码，本地跑不了，也不知道改没改对。

第二，多机器协作时，上下文不连续。你在办公室电脑上让Claude Code修了一个bug，回家想接着改另一个，对不起，两台机器的会话历史不互通。你得手动导来导去。

第三，AI任务之间的编排是空白。Claude Code擅长写代码，但如果同时要把代码推上Git、执行远程测试、收集日志、生成报告，它单兵作战就得靠一堆外部SHELL脚本强凑，维护成本直线上升。

2.2 Hermes Agent 在体系里承担什么角色

Hermes Agent 是一个面向终端环境的智能代理工具，它做的核心事情是理解你的自然语言指令，将其拆解为可执行的命令序列，并在目标机器上执行。它可以被理解为调度大脑——我自己打的比方是，Claude Code像一位码农，Hermes Agent 像他的项目经理。

项目经理不写代码，但它知道谁该干什么、什么时候干、下一步该调用哪个环节的资源。Hermes Agent 负责接收任务描述，分析需要执行的动作，通过SSH通道把任务发给指定机器，再拉回执行结果。

这套组合的实际收益非常明显：

• 任务分发变成本地的一条指令，不用手动开多个终端窗口反复切换。
• 多台机器之间的SSH通道复用同一个密钥对，配置一次，到处执行。
• Claude Code 专注于它最擅长的代码理解与修改，而环境操作、文件传输、命令调度这些杂活全部由Hermes Agent 接管。

2.3 为什么仍然需要SSH而不是更复杂的方案

有人可能会问，既然要协调多台机器，为什么不用Ansible、SaltStack、Kubernetes这些更重型的东西？

我的回答是：杀鸡不需要牛刀。Ansible在设计上是给基础设施配置管理用的，它的Playbook有严格的语法，学习曲线陡峭，而且对AI工具的支持并不友好。Kubernetes用来调度容器，但是我们这里是调度真实的开发环境和AI进程，不是在管一组无状态Pod。SSH的好处在于——它简单、通用、安全，Puppet和Ansible底层实际上也是基于SSH通道来工作的。我们要构建的是一个开发辅助编排层，而不是一套全自动运维系统，SSH加上Hermes Agent 的智能分发能力已经绰绰有余。

2.4 需要提前准备的环境清单

按照我实际的部署经验，你至少需要准备以下环境，清单如下：

Windows控制端是主战场，因为大多数时候你人在Windows前面，调度指令从这台机器发出。执行端建议至少准备一台性能较好的Linux机器，因为Claude Code在生成和修改大型项目时内存和CPU占用都不小。

如果你的执行端只有Windows，也不用担心，Windows 10/11自带的OpenSSH服务端和Bitvise SSH Server都是可用的方案，后文会在密钥配置和问题排查部分专门讲怎么处理Windows执行端的坑。

3. 核心前置工作：SSH密钥配置与多机互信

3.1 一次性生成密钥，打通控制端与执行端

SSH免密登录是整个编排体系的地基。这一步没做通，后续一切自动化都是空谈。我用的是最经典的RSA密钥对方案，如果你对安全性有更高要求，也可以使用ed25519算法，生成方式完全一样。

在控制端（Windows）上打开一个PowerShell窗口，输入：

ssh-keygen -t rsa -b 4096 -C "hermes-multi-machine"

参数说明：-t rsa指定算法，-b 4096指定密钥长度，-C是添加注释，方便你日后识别这是哪台机器的密钥。执行后一路回车，默认会写入C:\Users\你的用户名\.ssh\id_rsa，其中id_rsa是私钥，id_rsa.pub是公钥。

公钥是要分发到各台执行机的，私钥留在控制端绝不能外泄，这个习惯必须刻在脑子里。

3.2 关联任务：把公钥批量部署到执行端

3.2.1 通用方法：ssh-copy-id

在Linux控制端或Windows Git Bash环境下，有一个非常好用的命令ssh-copy-id，可以直接把公钥追加到目标机器的authorized_keys文件中：

ssh-copy-id -i ~/.ssh/id_rsa.pub user@192.168.1.101

这条命令首次执行会提示你输入目标机器的密码，之后就不再需要了。它会自动创建.ssh目录、设置正确的权限、把公钥内容追加进去，省去手动操作出错的可能。

3.2.2 Windows环境下的手动部署

如果你没有Git Bash，也可以手动完成。步骤很简单：先把id_rsa.pub的内容复制一份，然后SSH登录到目标Linux机器，执行：

mkdir -p ~/.ssh chmod 700 ~/.ssh echo "粘贴你的公钥内容" >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys

注意chmod权限那一步非常关键。我见过不少人密钥文件内容完全正确，但就是登录不上，十有八九是authorized_keys或.ssh目录的权限过宽。SSH服务端校验很严格，authorized_keys必须是600，.ssh目录必须是700，去掉了任何组权限和其他用户的读权限，才能通过验证。

3.3 验证多机互信是否打通

配置完成后，别急着往下走，先做一轮连通性验证。

在控制端依次执行：

ssh user@192.168.1.101 "echo connected to node1" ssh user@192.168.1.102 "echo connected to node2"

如果两行都能看到connected to nodeX的输出，说明密钥配置成功。如果提示需要输密码，回去检查密钥内容和权限设置。

3.4 设置SSH专属配置项，简化连接参数

多机环境下，每次敲一长串user@192.168.1.101也很烦。我通常会在控制端的~/.ssh/config文件里维护一组主机别名，格式很简单：

Host node1 HostName 192.168.1.101 User ubuntu IdentityFile ~/.ssh/id_rsa Host node2 HostName 192.168.1.102 User root IdentityFile ~/.ssh/id_rsa

配置好之后，ssh node1就能直接连上对应机器，不用再记IP和用户名。这个配置文件同样适用于scp、sftp，也是后续Hermes Agent 调用SSH执行命令时依赖的底层连接基础。

4. Hermes Agent 安装与基础配置

4.1 安装前要确认的依赖项

Hermes Agent 基于Node.js技术栈开发，所以第一件事是确保控制端安装好Node.js运行时，版本尽量在18以上。推荐直接使用LTS版本，后续兼容性问题少很多。

在Windows控制端（或任一需要安装Hermes Agent的节点）执行：

npm install -g @hermes-agent/core

如果你的网络环境访问npm官方源不稳定，建议顺手切换成国内镜像源再装，实测速度提升明显：

npm config set registry https://registry.npmmirror.com

4.2 初始化与登录验证

安装完成后，在任意目录运行：

hermes init

这一步会生成一个默认的配置文件，通常存放在~/.hermes/config.yaml。首次运行可能提示你登录网站验证身份，这是Hermes Agent的账号激活流程，按提示打开浏览器完成绑定即可。

我实际操作中遇到的一个小坑是：Windows控制台如果有代理设置，可能会导致登录验证的网页打不开。解决办法是把终端里的代理变量临时清掉，等激活成功后再恢复。

4.3 编辑核心配置，让Agent知道去哪台机器干活

打开~/.hermes/config.yaml，你会看到一个类似下面的结构，我贴上我的核心配置并标注每项含义：

# Hermes Agent 核心配置示例 agent: name: "my-dev-orchestrator" model: provider: "anthropic" api_key: "sk-ant-***" # 你的Claude API密钥或第三方兼容接口密钥 model_name: "claude-sonnet-4-20250514" context: max_tokens: 32000 # 单次任务允许的上下文长度 ssh: default_timeout: 30 # SSH连接超时时间，单位秒 connections: - name: "node1" host: "192.168.1.101" username: "ubuntu" key_path: "~/.ssh/id_rsa" - name: "node2" host: "192.168.1.102" username: "root" key_path: "~/.ssh/id_rsa"

ssh.connections这一段是核心，它声明了Hermes Agent 可以调度的所有远程节点。每一项都对应前面配置过SSH密钥的机器，Agent 在执行任务时，会根据任务描述自动选择合适的节点。

4.4 验证Agent是否正常工作

配置完成后，运行一个最简单的中文指令测试：

hermes run "查看node1的系统信息和当前目录"

如果Hermes Agent 正确识别出需要使用node1，并通过SSH执行了uname -a和pwd，最后把结果汇总返回，说明整套调度链路是通的。这一步成功，相当于第一块多米诺骨牌倒了，后面的事情都顺利得多。

5. Claude Code 安装与跨平台适配

5.1 执行端的Claude Code安装

Claude Code官方安装方式同样基于Node.js。在需要执行代码生成任务的Linux机器上执行：

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

安装完成后，初始化登录：

claude

首次运行会要求你完成认证，通常是打开生成的链接登录Anthropic账号，或者填入API Key。认证通过后，Claude Code会在当前用户目录生成独立的会话和配置目录。

5.2 Windows端的快速配置：一个容易忽略的问题

在Windows控制端同样可以安装Claude Code，但注意一个关键差异：Windows终端默认使用的是CMD或PowerShell，Claude Code的某些交互逻辑在PowerShell里工作不太正常。建议在Windows端统一使用Windows Terminal配合PowerShell 7，或者干脆用Git Bash跑，实测稳定性好很多。

另外，Claude Code 会读取仓库目录下的一些配置文件，比如.claude/commands/*.md，这些文件在跨平台复用时要特别注意换行符。Windows的CRLF换行符可能导致Linux端解析命令出错，最简单的办法是在Git配置里统一设置：

git config --global core.autocrlf input

5.3 多节点间共享配置的策略

Claude Code在同一俄平台上的配置可以复制，但最好不要直接复制整个用户目录。我更推荐的做法是：配置好一台基准机器后，把关键配置纳入Git仓库管理，比如.claude/settings.json和.claude/commands目录，然后在其他机器上通过git clone同步。

这样做的好处是，你新增一段常用Prompt模板或调整模型参数时，只需要提交一次，所有节点拉取即可生效。避免了逐台机器手动同步的重复劳动。

5.4 在VSCode中整合Claude Code远程开发

很多读者喜欢在VSCode里使用Claude Code插件，边看代码编辑器和AI交互窗口并行工作。这个习惯不用改，而且可以通过VSCode的Remote-SSH插件天然打通：本地VSCode连接远程节点，然后在该远程环境的终端里启动Claude Code，你获得的是“远程机器上的AI编码助手 + 本地编辑体验”的组合。

实际操作路径：VSCode安装Remote-SSH扩展，按F1输入Remote-SSH: Connect to Host，选择node1，VSCode会打开一个远程窗口，这时按Ctrl+打开终端，输入claude`即可完美运行。

6. 多机编排实操：调度Claude Code完成跨平台任务

6.1 设计一个真实的任务场景

理论说了一堆，下面拿一个我实际跑过的完整任务来演示整个编排过程。

任务目标：在一台Linux服务器（node1）上创建一个Python爬虫项目，抓取某个公开网站的标题列表，把结果写到results.json，然后通过Hermes Agent 把生成的文件回传到控制端（Windows），再由控制端完成一次格式化预览。

这个任务横跨三台机器（控制端、node1执行端、文本处理环节），里面包含代码生成、命令行执行、文件传输、本地处理四种不同类型的工作，非常适合展示Hermes Agent 的编排能力。

6.2 用自然语言下达编排指令

在控制端执行：

hermes run "在node1上创建一个Python爬虫项目，使用requests和BeautifulSoup抓取https://example.com的标题，保存到results.json，然后把结果文件拉回本地"

这条指令包含了三个关键信息：目标节点（node1）、执行动作（创建项目、写爬虫、运行）、结果处理（回传本地）。Hermes Agent 接收到指令后，会做以下事情：

1. 解析出目标节点node1，选择SSH连接通道。
2. 在node1上拼装并执行一组命令：创建项目目录、安装依赖库、生成爬虫代码。
3. 在node1上执行python3 crawler.py，确认results.json生成。
4. 通过scp或sftp命令把results.json传回控制端指定目录。

6.3 有一个关键细节：Claude Code是被Hermes Agent “请”出来的

这里要特别说明Hermes Agent 和Claude Code的协作方式。Hermes Agent 并不会直接调用Claude Code的API去写代码，而是在远程节点上启动Claude Code的终端模式，把写代码的任务交给它。

简单说，Hermes Agent 生成的远程命令类似：

cd /home/ubuntu/crawler-project && claude -p "请创建一个爬虫脚本..." --output-format text

其中-p参数代表非交互式模式（print模式），它让Claude Code直接处理完任务后输出结果并退出，而不是打开交互式对话界面。这是实现自动化的关键开关，我去翻了很多资料，发现不少人卡在这里——以为Claude Code只能手动对话使用，不知道还有这种批处理模式。

6.4 编排粒度与任务拆分的实战体会

初用Hermes Agent 编排多机任务时，最容易犯的错是把复杂任务一把扔给它。比如“帮我部署一个网站”，这听起来很简洁，但实际执行时Agent要拆解出几十个操作步骤，任何一步出现歧义或环境差异，执行就中断了。

我的经验是：手工把任务拆成三个阶段——准备阶段、执行阶段、收尾阶段。准备阶段包括环境检查和依赖安装，执行阶段是核心代码生成和运行，收尾阶段是文件回传和报告生成。每一步用一句明确的自然语言指令，尽量不要跨阶段写进同一条指令里。

切分后的指令条目如下：

hermes run "在node1上检查是否有python3和pip，如果没有就安装" hermes run "在node1上创建目录crawler-project，用Claude Code生成爬虫并运行" hermes run "把node1上的crawler-project/results.json回传到本地D:/results/"

三条指令串行执行，每一条的结果都可验证，出了问题能快速定位在哪一步。全局任务编排可以写成Shell脚本循环调用，或者用Hermes Agent自己的任务链功能串起来。

6.5 查看执行日志，确认各节点负载

编排系统最怕黑盒运行。Hermes Agent 默认会在~/.hermes/logs/下记录每个任务的详细日志，包括SSH连接时长、命令执行耗时、返回结果摘要。我习惯在跑完一批任务后快速扫一眼时间线，确认有没有节点在空转或超时。

7. 常见问题与排查技巧实录

7.1 SSH连接相关高频问题

问题一：ssh: connect to host github.com port 22: Connection refused

这个问题表面上和github相关，实际上根因多半不在github，而是你的网络环境屏蔽了22端口。常见场景包括：公司防火墙限制、部分云服务器的安全组规则、路由器策略。排查方法是先换443端口试试：

ssh -T -p 443 git@ssh.github.com

如果443端口能通，就在~/.ssh/config里为github单独加一段配置：

Host github.com HostName ssh.github.com Port 443 User git

这个方法在我的多台机器间同步配置时救了不少次。

问题二：SSH连接Windows服务器时报authentication failed

Windows执行端配置OpenSSH Server是出了名的容易踩坑。一个非常隐蔽的原因是：Windows的OpenSSH服务默认只允许Administrators组和Users组通过密码登录，但不允许密钥登录。你需要以管理员身份运行PowerShell，并编辑C:\ProgramData\ssh\sshd_config文件，确认以下几行没有被注释：

PubkeyAuthentication yes PasswordAuthentication yes

修改完后重启服务：

Restart-Service sshd

如果还是失败，再去事件查看器 -> Windows日志 -> OpenSSH/Operational里面看详细报错。这是官方日志，信息量很大，比盲猜配置强得多。

问题三：SSH命令行连接超时

部署在欧拉或其他国产Linux发行版上的机器，可能默认没有安装SSH服务端。解决办法是在目标机器上手动安装并启动服务。以OpenSSH为例，标准安装命令是：

sudo yum install -y openssh-server sudo systemctl enable sshd sudo systemctl start sshd

服务启动后检查监听端口：

ss -tlnp | grep 22

如果输出里没有sshd进程监听22端口，多半是SELinux策略或防火墙拦截，可以临时放行测试：

sudo firewall-cmd --permanent --add-service=ssh sudo firewall-cmd --reload

7.2 Hermes Agent 使用中的典型问题

问题四：安装后运行hermes命令提示找不到

这是Node.js全局安装路径没有加入系统PATH导致的。Windows环境下，检查npm prefix -g输出的路径，然后把对应的node_modules/.bin目录加入环境变量。很多情况下，重启一个终端窗口就能解决，因为环境变量是在窗口创建时读取的。

问题五：hermes run执行到一半卡住

Hermes Agent 执行远程命令时，如果目标机器上出现了交互式提示，比如y/n确认、密码输入、或者长时间运行的进程，Agent会一直等待直到超时。建议在配置里把default_timeout设大一些，比如300秒，同时在远程命令末尾加上< /dev/null，避免标准输入阻塞导致Agent挂起。

问题六：Claude Code订阅被组织禁用

执行claude时如果看到类似your organization has disabled claude subscription access for claude code的提示，说明当前登录的Anthropic账号是组织管理员账号，且组织策略禁止了Claude Code的使用。解决办法是换用自己的个人账号登录，或者在组织设置里允许Claude Code访问。

7.3 跨平台开发中的环境差异问题

问题七：路径和换行符混乱

Windows和Linux的路径分隔符和换行符差异，会在远程执行代码时引起各种莫名报错。最典型的是Python脚本在Windows上编写、Linux上运行时出现SyntaxError，原因是CRLF换行符导致的。

统一策略有两个：设置Git的core.autocrlf为input（提交时转为LF，拉取时保持LF），开发编辑器设置files.eol为\n。代码仓库内禁止混用换行符，是跨平台开发的黄金法则。

还有一个路径坑需要注意：如果控制端是Windows，远程任务里写本地路径时，不要在Shell命令里直接用反斜杠\，尽量使用/，否则很容易在SSH传输时被转义解析错误。

7.4 问题速查表

8. 编排能力再扩展：一些进阶玩法

这套体系跑通以后，能力边界完全取决于你的想象力。简单列举几个我在实际工作中扩展的场景，给读者做个参考。

第一，把Hermes Agent作为定时任务调度器。在多台机器上编写不同的Claude Code任务模块，然后通过系统crontab或Windows计划任务定时触发hermes run，实现每天自动刷新某类数据、生成日报、同步仓库等功能。整个链条完全是无人值守的。

第二，在移动设备上远程发起任务。Android平板或手机上装一个支持SSH的终端（比如Termius），就可以SSH到控制端，再通过Hermes Agent下发任务。因为这个编排体系唯一的入口就是一条SSH命令，不需要额外开发App。

第三，任务结果统一收集到消息通知渠道。Hermes Agent 执行完毕后，可以通过添加Webhook或调用系统命令的方式，把任务结果推送到你的微信群机器人、钉钉群或者Telegram Bot，随时随地掌握任务状态。

这些扩展场景需要的不是新工具，而是对SSH链路和Agent指令的熟练运用。

9. 从这套实战中沉淀下来的一点感悟

整套方案跑通后，我有一个很深的体会：所谓“编排”，并不是把所有事情接在一起就会自动变好，更核心的是清晰划分每层工具的职责边界。SSH提供通道，Hermes Agent负责理解意图和分发任务，Claude Code负责具体的代码生成和修改，各司其职，互不越权。

我在这个过程中经历的几次返工，几乎都是因为职责划分不清晰导致的。比如最初我想让Claude Code直接去执行SSH命令，结果它的终端环境和多台机器的连接配置纠缠在一起，搞得一团糟。后来把调度权限交给Hermes Agent，Claude Code只管代码，问题就迎刃而解了。

最后留个建议：如果你是第一次搭建，不要一上来就追求多任务并行或复杂编排，先老老实实跑通一条最简单的“本地指令 -> 远程生成代码 -> 回传文件”闭环。等这条链路稳定了，再往里面加节点、加任务类型、加定时调度。地基扎稳了，上面盖几层楼都不怕。