Hermes-agent

2026-06-14 14:30:48 -04:00
commit dac4b88b94
5058 changed files with 1884848 additions and 0 deletions
@@ -0,0 +1,332 @@
+---
+title: "Windows (WSL2) 指南"
+description: "通过 WSL2 在 Windows 上运行 Hermes Agent —— 安装配置、Windows 与 Linux 之间的文件系统访问、网络设置及常见问题"
+sidebar_label: "Windows (WSL2)"
+sidebar_position: 2
+---
+
+# Windows (WSL2) 指南
+
+Hermes Agent 现已同时支持原生 Windows 和 WSL2。本页介绍 WSL2 路径；如需原生 PowerShell 安装方式，请参阅专属的 **[Windows（原生）指南](./windows-native.md)**。
+
+**何时选择 WSL2 而非原生：**
+- 你想使用 dashboard 内嵌终端（`/chat` 标签页）—— 该面板需要 POSIX PTY（伪终端），仅 WSL2 支持。
+- 你在进行大量 POSIX 相关的开发工作，希望 Hermes 会话与开发工具共享同一文件系统和路径。
+- 你已有 WSL2 环境，不想维护第二套安装。
+
+**何时原生更合适（甚至更好）：**
+- 交互式聊天、gateway（Telegram/Discord 等）、cron 调度器、浏览器工具、MCP 服务器以及大多数 Hermes 功能均可在 Windows 上原生运行。
+- 你不想在每次引用文件或打开 URL 时都考虑跨越 WSL↔Windows 边界的问题。
+
+在 WSL2 中，实际上有两台"计算机"同时运行：你的 Windows 宿主机，以及由 WSL 管理的 Linux 虚拟机。大多数困惑都源于不清楚自己当前处于哪一侧。
+
+本指南涵盖这种分离中专门影响 Hermes 的部分：安装 WSL2、在 Windows 与 Linux 之间传输文件、双向网络配置，以及实际遇到的常见问题。
+
+:::info 简体中文
+最小安装路径的中文说明维护在本页 —— 通过右上角的**语言**菜单切换，选择**简体中文**即可查看。
+:::
+
+## 为什么选择 WSL2（而非原生 Windows）
+
+原生 Windows 安装直接运行在 Windows 上：使用 Windows 终端（PowerShell、Windows Terminal 等）、Windows 文件系统路径（`C:\Users\…`）和 Windows 进程。Hermes 使用 Git Bash 执行 shell 命令，这也是 Claude Code 等 agent 目前处理 Windows 的方式 —— 无需完整重写即可绕过 POSIX 与 Windows 的差异。
+
+WSL2 在轻量级虚拟机中运行真实的 Linux 内核，因此其中的 Hermes 与在 Ubuntu 上运行几乎完全相同。当你需要真正的 POSIX 环境时，这非常有价值：`fork`、`/tmp`、UNIX socket、信号语义、PTY 支持的终端、`bash`/`zsh` 等 shell，以及 `rg`、`git`、`ffmpeg` 等在 Linux 上行为一致的工具。
+
+WSL2 的实际影响：
+
+- Hermes CLI、gateway、会话、内存、技能和工具运行时均位于 Linux 虚拟机内部。
+- Windows 程序（浏览器、原生应用、带登录 profile 的 Chrome）位于虚拟机外部。
+- 每次需要两者通信时 —— 共享文件、打开 URL、控制 Chrome、访问本地模型服务器、将 Hermes gateway 暴露给手机 —— 都需要跨越一道边界。这些边界正是本指南要讲的内容。
+
+## 安装 WSL2
+
+在**管理员 PowerShell** 或 Windows Terminal 中执行：
+
+```powershell
+wsl --install
+```
+
+在全新的 Windows 10 22H2+ 或 Windows 11 上，此命令会安装 WSL2 内核、虚拟机平台功能以及默认的 Ubuntu 发行版。按提示重启。重启后 Ubuntu 会打开并要求设置 Linux 用户名和密码 —— 这是一个**全新的 Linux 用户**，与你的 Windows 账户无关。
+
+验证你确实在使用 WSL2（而非旧版 WSL1）：
+
+```powershell
+wsl --list --verbose
+```
+
+应显示 `VERSION  2`。如果某个发行版显示 `VERSION  1`，请转换：
+
+```powershell
+wsl --set-version Ubuntu 2
+wsl --set-default-version 2
+```
+
+Hermes 在 WSL1 上无法可靠运行 —— WSL1 会动态转译 Linux 系统调用，某些行为（procfs、信号、网络）与真实 Linux 存在偏差。
+
+### 发行版选择
+
+我们以 Ubuntu（LTS）为测试基准。Debian 同样可用。Arch 和 NixOS 也有人在用，但一键安装脚本假设使用基于 Debian 的 `apt` 系统 —— 如需其他路径，请参阅 [Nix 安装指南](/getting-started/nix-setup)。
+
+### 启用 systemd（推荐）
+
+Hermes gateway（以及任何你希望持续运行的服务）在 systemd 下更易管理。在现代 WSL 上，在发行版内执行一次即可启用：
+
+```bash
+sudo tee /etc/wsl.conf >/dev/null <<'EOF'
+[boot]
+systemd=true
+
+[interop]
+enabled=true
+appendWindowsPath=true
+
+[automount]
+options = "metadata,umask=22,fmask=11"
+EOF
+```
+
+然后在 PowerShell 中执行：
+
+```powershell
+wsl --shutdown
+```
+
+重新打开 WSL 终端。`ps -p 1 -o comm=` 应输出 `systemd`。
+
+上面的 `metadata` 挂载选项很重要 —— 没有它，`/mnt/c/...` 上的文件无法存储真实的 Linux 权限位，这会导致在 Windows 路径下对脚本执行 `chmod +x` 等操作失效。
+
+### 在 WSL 内安装 Hermes
+
+打开 WSL2 shell 后执行：
+
+```bash
+curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
+source ~/.bashrc
+hermes
+```
+
+安装程序将 WSL2 视为普通 Linux —— 无需任何 WSL 专属配置。完整目录结构请参阅[安装说明](/getting-started/installation)。
+
+## 文件系统：跨越 Windows ↔ WSL2 边界
+
+这是最容易让人踩坑的部分。存在**两套文件系统**，文件放在哪里至关重要 —— 影响性能、正确性以及哪些工具能访问到它。
+
+### 两个方向
+
+| 方向 | 内部路径 | 使用的路径 |
+|---|---|---|
+| Windows 磁盘，从 WSL 访问 | `C:\Users\you\Documents` | `/mnt/c/Users/you/Documents` |
+| WSL 磁盘，从 Windows 访问 | `/home/you/code` | `\\wsl$\Ubuntu\home\you\code`（较新版本为 `\\wsl.localhost\Ubuntu\...`） |
+
+两者都是真实存在的，都可以使用，但它们**不是同一个文件系统** —— 底层通过 9P 网络协议桥接。这带来了真实的性能和语义差异。
+
+### Hermes 和项目应放在哪里
+
+**经验法则：将所有 Linux 相关内容保留在 Linux 文件系统内。**
+
+- 你的 Hermes 安装目录（`~/.hermes/`）—— Linux 侧。安装程序已自动处理。
+- 你在 WSL 中开发的 git 仓库 —— Linux 侧（`~/code/...`、`~/projects/...`）。
+- 你的模型、数据集、venv —— Linux 侧。
+
+遵循此规则的好处：
+
+- **I/O 速度快。** 对 `/mnt/c/...` 的操作需经过 9P，比原生 ext4 慢 10–100 倍。在 `~/code` 下感觉瞬间完成的 `git status`（10k 文件仓库），在 `/mnt/c` 下可能需要 15 秒以上。
+- **权限正确。** Linux 权限位在 `/mnt/c` 上只是尽力模拟。`ssh` 因"权限不当"拒绝密钥，或 `chmod +x` 静默失败，都是常见问题。
+- **文件监听可靠。** 跨 9P 的 inotify 不稳定 —— 文件监听器（开发服务器、测试运行器）在 `/mnt/c` 上经常漏报变更。
+- **无大小写敏感问题。** Windows 路径默认不区分大小写；Linux 区分大小写。同时包含 `Readme.md` 和 `README.md` 的项目在两侧行为不同。
+
+只有当你**确实需要**文件存在于 Windows 侧时，才将其放在 `/mnt/c` 下 —— 例如需要从 Windows GUI 应用打开，或 Windows Chrome 的 DevTools MCP 需要当前目录是 Windows 可访问的路径。
+
+### 在两侧之间传输文件
+
+**从 Windows → 传入 WSL：** 最简单的方式是打开资源管理器，在地址栏输入 `\\wsl.localhost\Ubuntu`，然后拖放到 `\home\<you>\...`。或者在 PowerShell 中：
+
+```powershell
+wsl cp /mnt/c/Users/you/Downloads/file.pdf ~/incoming/
+```
+
+**从 WSL → 传入 Windows：** 复制到 `/mnt/c/Users/<you>/...`，Windows 资源管理器会立即看到：
+
+```bash
+cp ~/reports/output.pdf /mnt/c/Users/you/Desktop/
+```
+
+**在 Windows 应用中打开 WSL 文件**（GUI 编辑器、浏览器等）：使用 `explorer.exe` 或 `wslview`：
+
+```bash
+sudo apt install wslu     # 安装一次 —— 提供 wslview、wslpath、wslopen 等工具
+wslview ~/reports/output.pdf    # 用 Windows 默认程序打开
+explorer.exe .                  # 在 Windows 资源管理器中打开当前 WSL 目录
+```
+
+**在两个世界之间转换路径：**
+
+```bash
+wslpath -w ~/code/project        # → \\wsl.localhost\Ubuntu\home\you\code\project
+wslpath -u 'C:\Users\you'        # → /mnt/c/Users/you
+```
+
+### 行尾符、BOM 与 git
+
+如果你在 Windows 侧用 Windows 编辑器编辑文件，可能会产生 `CRLF` 行尾符。当 Linux 侧的 `bash` 或 Python 读取这些文件时，shell 脚本会报错 `bad interpreter: /bin/bash^M`，带 BOM 的 `.env` 文件也可能导致 Python 失败。
+
+解决方法是在 WSL 内（而非 Windows 上）配置合理的 git 设置：
+
+```bash
+git config --global core.autocrlf input
+git config --global core.eol lf
+```
+
+对于已有 CRLF 的文件：
+
+```bash
+sudo apt install dos2unix
+dos2unix path/to/script.sh
+```
+
+### "在 WSL 内 clone 还是在 `/mnt/c` 上 clone？"
+
+在 WSL 内 clone。始终如此，除非有特殊原因。典型的 Hermes 工作流（`hermes chat`、调用 `rg`/`ripgrep` 搜索仓库的工具、文件监听器、后台 gateway）在 `~/code/myrepo` 下会比在 `/mnt/c/Users/you/myrepo` 下快得多，也更可靠。
+
+一个例外：**启动 Windows 二进制文件的 MCP bridge。** 如果你通过 `cmd.exe` 使用 `chrome-devtools-mcp`（参见 [MCP 指南：WSL → Windows Chrome](/guides/use-mcp-with-hermes#wsl2-bridge-hermes-in-wsl-to-windows-chrome)），当 Hermes 的当前工作目录是 `~` 时，Windows 可能会报 `UNC` 警告。此时请从 `/mnt/c/` 下的某个目录启动 Hermes，以便 Windows 进程拥有一个带盘符的工作目录。
+
+## 网络：WSL ↔ Windows
+
+WSL2 在轻量级虚拟机中运行，拥有独立的网络栈。这意味着 WSL 内的 `localhost` 与 Windows 上的 `localhost` **并不相同** —— 从网络角度看，它们是两台独立的主机。对于每个服务，你需要确定流量方向，并选择正确的桥接方式。
+
+以下两种情况最为常见。
+
+### 情况一 —— WSL 中的 Hermes 访问 Windows 上的服务
+
+最常见的场景：你在 **Windows 上运行 Ollama、LM Studio 或 llama-server**，而 WSL 内的 Hermes 需要访问它。
+
+此场景的权威说明在 providers 指南中：**[WSL2 本地模型网络配置 →](/integrations/providers#wsl2-networking-windows-users)**
+
+简要说明：
+
+- **Windows 11 22H2+：** 启用镜像网络模式（在 `%USERPROFILE%\.wslconfig` 中设置 `networkingMode=mirrored`，然后执行 `wsl --shutdown`）。之后 `localhost` 在两侧均可互通。
+- **Windows 10 或旧版本：** 使用 Windows 宿主机 IP（WSL 虚拟网络的默认网关），并确保 Windows 上的服务绑定到 `0.0.0.0` 而非仅 `127.0.0.1`。通常还需要在 Windows 防火墙中为该端口添加规则。
+
+完整表格（Ollama / LM Studio / vLLM / SGLang 绑定地址、防火墙规则一行命令、动态 IP 辅助工具、Hyper-V 防火墙解决方案）请点击上方链接 —— 此处不再重复。
+
+### 情况二 —— Windows（或局域网）上的设备访问 WSL 中的 Hermes
+
+这是反向情况，其他地方较少记录，但以下场景需要用到：
+
+- 从 Windows 浏览器使用 Hermes **Web Dashboard**。
+- 从 Windows 侧工具使用 **OpenAI 兼容 API 服务器**（当 `API_SERVER_ENABLED=true` 时由 `hermes gateway` 暴露）。参见 [API Server 功能页](/user-guide/features/api-server)。
+- 测试**消息 gateway**（Telegram、Discord 等），平台会向本地 webhook URL 发送请求 —— 通常建议使用 `cloudflared`/`ngrok` 而非原始端口转发。
+
+#### 子情况 2a：从 Windows 宿主机本身访问
+
+在**启用了镜像模式的 Windows 11 22H2+** 上，无需任何额外操作。WSL 中绑定到 `0.0.0.0:8080`（甚至 `127.0.0.1:8080`）的进程，可直接从 Windows 浏览器通过 `http://localhost:8080` 访问。WSL 会自动将绑定发布回宿主机。
+
+在 **NAT 模式**（Windows 10 / 旧版 Windows 11）下，WSL2 默认的"localhost 转发"通常会将 Linux 侧的 `127.0.0.1` 绑定转发到 Windows 的 `localhost`，因此以 `--host 127.0.0.1` 启动的 Hermes 服务通常可从 Windows 通过 `http://localhost:PORT` 访问。如果无法访问：
+
+- 在 WSL 内显式绑定到 `0.0.0.0`。
+- 用 `ip -4 addr show eth0 | grep inet` 获取 WSL 虚拟机的 IP，然后从 Windows 直接访问该 IP。
+
+#### 子情况 2b：从局域网中的其他设备访问（手机、平板、另一台 PC）
+
+这才是真正麻烦的地方。流量路径为 **局域网设备 → Windows 宿主机 → WSL 虚拟机**，你需要分别配置两段：
+
+1. **在 WSL 内绑定所有网络接口。** 监听 `127.0.0.1` 的进程永远无法从虚拟机外部访问。请使用 `0.0.0.0`。
+
+2. **配置 Windows → WSL 虚拟机的端口转发。** 镜像模式下自动完成。NAT 模式下需要在管理员 PowerShell 中手动配置，每个端口单独设置：
+
+   ```powershell
+   # 获取 WSL 虚拟机当前 IP（NAT 模式下每次重启 WSL 都会变化）
+   $wslIp = (wsl hostname -I).Trim().Split(' ')[0]
+
+   # 将 Windows 端口 8080 转发到 WSL:8080
+   netsh interface portproxy add v4tov4 `
+     listenaddress=0.0.0.0 listenport=8080 `
+     connectaddress=$wslIp connectport=8080
+
+   # 在 Windows 防火墙中放行该端口
+   New-NetFirewallRule -DisplayName "Hermes WSL 8080" `
+     -Direction Inbound -Protocol TCP -LocalPort 8080 -Action Allow
+   ```
+
+   之后可用以下命令删除：`netsh interface portproxy delete v4tov4 listenaddress=0.0.0.0 listenport=8080`。
+
+3. **让局域网设备访问 `http://<windows-lan-ip>:8080`。**
+
+由于 NAT 模式下 WSL 虚拟机 IP 在每次重启后都会变化，一次性配置的规则在下次 `wsl --shutdown` 后即失效。如需持久化，要么启用镜像模式，要么将端口代理步骤写入 Windows 登录时自动运行的脚本。
+
+对于来自云端消息服务商的 webhook（Telegram `setWebhook`、Slack 事件等），不建议折腾端口转发 —— 请使用 `cloudflared` 隧道。参见 [webhook 指南](/user-guide/messaging/webhooks)。
+
+## 在 Windows 上长期运行 Hermes 服务
+
+Hermes 的 [Tool Gateway](/user-guide/features/tool-gateway) 和 API 服务器都是长期运行的进程。在 WSL2 中，有以下几种方式保持它们持续运行。
+
+### 在 WSL 内使用 systemd（推荐）
+
+如果你按照上面的安装步骤启用了 systemd，`hermes gateway` 和 API 服务器的使用方式与任何 Linux 机器上完全相同。使用 gateway 设置向导：
+
+```bash
+hermes gateway setup
+```
+
+它会提示是否安装 systemd 用户单元，以便在 WSL 启动时自动拉起 gateway。
+
+### 让 WSL 在 Windows 登录时自动启动
+
+WSL 虚拟机只在有进程使用时保持运行。若要在没有终端窗口的情况下保持 gateway 可访问，可通过任务计划程序在 Windows 登录时启动一个 WSL 进程：
+
+- **触发器：** 用户登录时（你的账户）。
+- **操作：** 启动程序
+  - 程序：`C:\Windows\System32\wsl.exe`
+  - 参数：`-d Ubuntu --exec /bin/sh -c "sleep infinity"`
+
+这样可以保持虚拟机存活，使 systemd 管理的 gateway 持续运行。在 Windows 11 上，较新的 `wsl --install --no-launch` + 自动启动流程也可以实现；`sleep infinity` 方案是兼容性最好的版本。
+
+## GPU 直通（本地模型）
+
+WSL2 自 WSL 内核 5.10.43+ 起原生支持 **NVIDIA** GPU —— 在 Windows 上安装标准 NVIDIA 驱动（**不要**在 WSL 内安装 Linux NVIDIA 驱动），WSL 内的 `nvidia-smi` 即可识别 GPU。之后，CUDA 工具链、`torch`、`vllm`、`sglang` 和 `llama-server` 均可正常使用真实 GPU。
+
+AMD ROCm 和 Intel Arc 在 WSL2 内的支持仍在发展中，不在 Hermes 的测试范围内 —— 使用当前驱动可能可以工作，但我们暂无推荐方案。
+
+如果你运行的是**原生 Windows** 本地模型服务器（Windows 版 Ollama、LM Studio），它已通过 Windows 驱动使用 GPU，则完全不需要 WSL GPU 直通 —— 只需按照上面的情况一，从 WSL 通过网络访问即可。
+
+## 常见问题
+
+**连接 Windows 上的 Ollama / LM Studio 时报"Connection refused"。**
+参见 [WSL2 网络配置](/integrations/providers#wsl2-networking-windows-users)。九成情况是服务绑定在 `127.0.0.1` 上，需要改为 `0.0.0.0`（Ollama：`OLLAMA_HOST=0.0.0.0`），或者缺少防火墙规则。
+
+**`git status` / `hermes chat` 在仓库中极慢。**
+你很可能在 `/mnt/c/...` 下工作。将仓库移到 `~/code/...`（Linux 侧），速度会有数量级的提升。
+
+**脚本报错 `bad interpreter: /bin/bash^M`。**
+Windows 编辑器产生的 CRLF 行尾符。执行 `dos2unix script.sh`，并在 WSL git 配置中设置 `core.autocrlf input`。
+
+**通过 MCP 启动 Windows 二进制文件时出现"UNC paths are not supported"警告。**
+Hermes 的工作目录在 Linux 文件系统内，Windows `cmd.exe` 无法识别。在该会话中从 `/mnt/c/...` 下启动 Hermes，或使用一个在调用 Windows 可执行文件前先 `cd` 到 Windows 可访问路径的包装脚本。
+
+**休眠/睡眠后时钟漂移。**
+宿主机从睡眠恢复后，WSL2 的时钟可能滞后数分钟，导致所有基于证书的操作失败（OAuth、HTTPS API）。按需修复：
+
+```bash
+sudo hwclock -s
+```
+
+或安装 `ntpdate` 并在登录时运行。
+
+**启用镜像模式后或连接 VPN 时 DNS 停止工作。**
+镜像模式会将宿主机网络设置代理到 WSL —— 如果 Windows DNS 有问题（VPN 分流隧道、企业解析器），WSL 会继承这些问题。解决方法：手动覆盖 `resolv.conf`（在 `/etc/wsl.conf` 中设置 `generateResolvConf=false`，然后手动编写 `/etc/resolv.conf`，填入 `1.1.1.1` 或你的 VPN DNS）。
+
+**运行安装程序后找不到 `hermes` 命令。**
+安装程序通过 `~/.bashrc` 将 `~/.local/bin` 添加到 shell 的 PATH 中。需要执行 `source ~/.bashrc`（或打开新终端）才能在当前会话中生效。
+
+**Windows Defender 对 WSL 文件扫描很慢。**
+Defender 通过 9P 桥接扫描从 Windows 访问的文件，这会放大 `/mnt/c` 风格跨边界访问的延迟。如果你只在 WSL 内部访问 WSL 文件，则不受影响。如果你频繁使用 Windows 工具访问 `\\wsl$\...`，可考虑将 WSL 发行版路径排除在实时扫描之外。
+
+**磁盘空间不足。**
+WSL2 将虚拟机磁盘存储为 `%LOCALAPPDATA%\Packages\...` 下的稀疏 VHDX 文件。它会自动增长，但删除文件后不会自动收缩。回收空间的方法：执行 `wsl --shutdown`，然后在管理员 PowerShell 中运行 `Optimize-VHD -Path <path-to-ext4.vhdx> -Mode Full`（需要 Hyper-V 工具），或使用 WSL 文档中记录的更简单的 `diskpart` 方式。
+
+## 下一步
+
+- **[安装说明](/getting-started/installation)** —— 实际安装步骤（Linux/WSL2/Termux 均使用同一安装程序）。
+- **[集成 → Providers → WSL2 网络配置](/integrations/providers#wsl2-networking-windows-users)** —— 本地模型服务器网络配置的权威深度说明。
+- **[MCP 指南 → WSL → Windows Chrome](/guides/use-mcp-with-hermes#wsl2-bridge-hermes-in-wsl-to-windows-chrome)** —— 从 WSL 中的 Hermes 控制你已登录的 Windows Chrome。
+- **[Tool Gateway](/user-guide/features/tool-gateway)** 和 **[Web Dashboard](/user-guide/features/web-dashboard)** —— 你最常需要从 WSL 暴露到网络其他部分的长期运行服务。