Windows下Hermes Agent安装指南：为什么必须用WSL2

1. 项目概述：为什么Windows用户需要Hermes Agent，又为何安装过程让人反复重启？

Hermes Agent不是另一个“AI聊天框”，它是一套可编程、可扩展、能真正调用本地工具和模型的智能体运行时——类似一个轻量级的AI操作系统内核。你在Windows上装它，不是为了多开一个网页对话窗口，而是为了实现：用自然语言启动本地Python脚本、让AI自动读取你桌面上的Excel并生成分析报告、把Chat界面变成你私有知识库的指挥中心、甚至让AI接管你的开发工作流——比如自动写单元测试、查Git提交历史、调用Ollama跑本地大模型推理。这些能力背后，是Hermes对CLI、HTTP API、MCP（Model Context Protocol）和Tool Gateway的深度整合。

但问题来了：Windows原生环境和Hermes底层依赖的POSIX生态存在天然鸿沟。它需要真正的fork进程、可靠的信号处理、标准的UNIX socket、完整的PTY终端支持（用于内嵌Web Terminal）、以及像rg（ripgrep）、fd、bat这类Linux原生工具链。PowerShell再强大，也模拟不出/proc文件系统里进程状态的实时映射；Windows Terminal再漂亮，也无法让hermes chat里的/chat标签页获得一个能被Web前端完整挂载的伪终端实例。这就是为什么官方文档明确分出两条路径：原生Windows安装（适合轻量交互、Telegram/Discord网关、浏览器插件）和WSL2安装（适合深度开发、Dashboard内嵌终端、本地模型服务集成、长期后台服务管理）。而绝大多数搜索“Hermes Agent安装”的用户，点进来的第一眼看到的是curl | bash，却没意识到自己正站在一个双系统边界的悬崖上——稍不注意，就会掉进/mnt/c/路径性能黑洞、CRLF行尾符报错、localhost网络不通、systemd无法启动、GPU不可见等连环坑里。

我试过三种安装路径：纯PowerShell（失败于bad interpreter: /bin/bash^M）、WSL2 Ubuntu但没启用systemd（gateway一关终端就死）、以及镜像网络模式下没配防火墙（Ollama连接拒绝）。最终稳定落地的方案，是以WSL2为基石，用systemd为心脏，以镜像网络为血管，所有操作严格限定在Linux文件系统内。这不是过度设计，而是Hermes在Windows上发挥全部潜力的唯一可靠路径。这篇教程不讲“能不能装”，只讲“怎么装得稳、跑得久、扩得开”。接下来每一节，都是我在三台不同配置Win11机器（i5-1135G7轻薄本、Ryzen 7 5800H游戏本、i9-13900K工作站）上，踩了至少7次坑、重装12次WSL发行版后总结出的硬核实操逻辑。

2. 安装路径深度拆解：为什么必须选WSL2？原生PowerShell方案到底差在哪？

2.1 核心矛盾：Hermes不是“Windows软件”，而是“Linux智能体运行时”

Hermes Agent的源码仓库、CI/CD流程、核心依赖（如tokio异步运行时、clap命令行解析器、reqwestHTTP客户端）全部构建在Linux CI环境中。它的设计哲学是“Everything is a POSIX process”。这意味着：

• 会话管理：每个hermes chat会话都派生为独立子进程，依赖fork()系统调用创建隔离环境。Windows Subsystem for Linux 1（WSL1）通过动态翻译系统调用模拟fork，但实际行为与Linux内核差异极大——当Hermes尝试并发启动5个模型推理任务时，WSL1会出现进程句柄泄漏，内存占用飙升至8GB后无响应；而WSL2中同一负载下CPU利用率稳定在40%，内存恒定在1.2GB。

• 终端交互：Dashboard的/chat页面需要一个真实的PTY（Pseudo-Terminal）来渲染命令行输出流。PowerShell的System.Console类无法提供符合ioctl(TIOCGWINSZ)标准的窗口尺寸查询接口，导致Web Terminal初始化失败，页面卡在“Connecting…”；WSL2中的/dev/pts/0则完全兼容，hermes chat输入命令后，光标闪烁、颜色高亮、Ctrl+C中断全部原生生效。

• 文件系统语义：Hermes的技能（Skills）模块会频繁调用inotify监听代码仓库变更。在/mnt/c/Users/you/project路径下，WSL2通过9P协议桥接Windows NTFS，inotify事件丢失率高达63%（实测100次git commit仅触发37次监听回调）；而在~/code/project原生ext4分区下，100次全部精准触发，延迟<5ms。

提示：别被“PowerShell是Windows原生Shell”误导。PowerShell本质是.NET Core应用，它调用Windows API，而非Linux syscall。Hermes的hermes gateway进程若在PowerShell中后台运行（Start-Process -NoNewWindow），一旦PowerShell窗口关闭，进程会被Windows Session Manager强制终止——这是Windows会话隔离机制决定的，无法绕过。

2.2 WSL2 vs 原生PowerShell：一张表看透适用场景

能力维度	WSL2安装方案	原生PowerShell安装方案	实测影响
Dashboard内嵌终端	✅ 完全支持/chat标签页的PTY终端	❌hermes dashboard启动后，/chat页面空白或报错	原生方案下，Web界面失去最核心的交互能力，沦为静态文档查看器
本地模型服务集成	✅ 可直接调用WSL2内CUDA加速的vLLM、llama.cpp	⚠️ 仅支持Windows版Ollama/LM Studio，需额外网络配置	WSL2方案GPU利用率实测达92%（nvidia-smi），原生方案因Windows驱动层转换，同等负载下GPU利用率仅68%
长期后台服务	✅systemd管理hermes gateway，开机自启，崩溃自愈	❌ 依赖Start-Process或Task Scheduler，无进程守护机制	WSL2方案中hermes gateway连续运行14天零中断；原生方案平均2.3天因PowerShell会话超时崩溃一次
文件操作性能	✅git status10k文件仓库耗时<0.8s（~/code/）	✅git status同等仓库耗时<1.2s（C:\project\）	表面差距不大，但hermes chat中调用rg --type-add md=*.md搜索Markdown时，WSL2快3.7倍（1.4s vs 5.2s）
跨平台开发一致性	✅ 与Ubuntu服务器部署完全一致，hermes deploy无缝迁移	❌ Windows路径分隔符\与Linux/混用，CI脚本需大量条件判断	团队协作中，WSL2开发者推送的.hermes/skills/脚本，原生Windows用户需手动替换23处路径分隔符才能运行

2.3 关键决策点：什么情况下你该放弃WSL2，退回原生PowerShell？

只有当同时满足以下全部三个条件时，才建议选择原生PowerShell安装：

1. 你的核心需求仅限于“聊天+简单工具调用”：例如用/web指令打开网页、用/file上传PDF让AI总结，且从不涉及本地代码仓库分析、模型微调、或需要Dashboard内嵌终端；
2. 你已安装并习惯使用Git Bash或MSYS2：因为Hermes原生Windows版依赖Git Bash提供POSIX兼容层，若你电脑上没有预装Git for Windows（含Git Bash），安装过程会额外增加Git安装、PATH配置、Bash初始化等步骤，复杂度不亚于WSL2；
3. 你使用的是Windows 10 LTSC或企业锁定环境：某些企业域策略禁用Windows功能启用（wsl --install需管理员权限且可能被组策略阻止），此时原生PowerShell是唯一可行路径。

注意：网上流传的“PowerShell 2.0兼容安装包”是严重误导。Hermes最低要求PowerShell 5.1（Windows 10 1607起内置），PowerShell 2.0（Windows 7默认）因缺少Invoke-RestMethod、ConvertFrom-Json等关键Cmdlet，根本无法执行安装脚本。若你看到此类教程，请立即关闭页面——它大概率是2018年前的过期资料。

3. WSL2环境准备：从零开始的精准配置，避开90%的常见故障

3.1 系统前提验证：三行命令确认你的Win11是否“达标”

在管理员权限的PowerShell中执行以下命令，逐条验证。任何一条失败，都需先解决再继续：

# 检查Windows版本（必须为Win11 22H2+ 或 Win10 22H2+） Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsHardwareAbstractionLayer # 检查虚拟机平台是否启用（WSL2依赖Hyper-V轻量级虚拟化） Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform | Select-Object FeatureName, State # 检查Windows Subsystem for Linux功能状态 Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux | Select-Object FeatureName, State

预期输出：

• WindowsVersion显示22H2或更高（如23H2）
• VirtualMachinePlatform和Microsoft-Windows-Subsystem-Linux的State均为Enabled

若未启用：执行以下命令并重启电脑：

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart # 重启后，再执行： wsl --update

实操心得：很多用户卡在“wsl --install 无响应”，根源是Windows Update服务被禁用。请确保Windows Update服务（wuauserv）处于Running状态。我曾遇到一台公司电脑因组策略禁用更新服务，wsl --install卡在“正在下载内核”长达47分钟，手动启动wuauserv后12秒完成下载。

3.2 WSL2发行版安装：为什么必须选Ubuntu 22.04 LTS，而非最新版？

执行wsl --install默认安装Ubuntu 24.04，但Hermes官方测试矩阵明确标注“Ubuntu 22.04 LTS (Jammy) 是唯一经过全功能验证的发行版”。原因在于：

• 内核兼容性：Ubuntu 22.04搭载Linux 5.15内核，与WSL2内核5.10.102.1完全匹配。Ubuntu 24.04的6.8内核在WSL2中存在cgroup v2挂载异常，导致hermes gateway启动时systemd单元加载失败（日志报错Failed to mount cgroup2）；
• 包管理稳定性：apt源中python3.10（Hermes依赖）在22.04中为3.10.12-1~22.04.1，在24.04中升级为3.12.3-1ubuntu1，后者因asyncio事件循环变更，导致hermes api-server在高并发请求下出现RuntimeError: Event loop is closed；
• 安全更新节奏：22.04 LTS获得5年安全更新（至2027年），24.04仅3年（至2027年），对于需要长期稳定运行的AI服务，LTS版本是生产环境铁律。

正确安装命令（跳过默认Ubuntu，直装22.04）：

# 卸载可能存在的旧版（如有） wsl --unregister Ubuntu # 手动下载并安装Ubuntu 22.04 Invoke-WebRequest -Uri https://cloud-images.ubuntu.com/releases/22.04/release/ubuntu-22.04-server-cloudimg-amd64-wsl.rootfs.tar.gz -OutFile $env:USERPROFILE\Downloads\ubuntu-22.04-wsl.tar.gz wsl --import Ubuntu-22.04 $env:USERPROFILE\WSL\Ubuntu-22.04 $env:USERPROFILE\Downloads\ubuntu-22.04-wsl.tar.gz --version 2 # 设为默认发行版 wsl --set-default Ubuntu-22.04

安装完成后，首次启动会要求设置Linux用户名和密码。切记：此处的用户名与Windows账户无关，且必须为小写字母开头（如hermesuser），不能包含空格或特殊字符。我曾用MyUser导致后续systemd单元文件生成失败，错误日志显示Invalid username 'MyUser' in unit file。

3.3 systemd启用：让Hermes服务真正“活”起来的关键一步

WSL2默认禁用systemd，因其传统上依赖完整的Linux init系统。但Hermes的gateway和api-server需要进程守护、日志轮转、依赖注入等systemd核心能力。启用步骤如下：

1. 在WSL2终端中创建/etc/wsl.conf：

sudo tee /etc/wsl.conf >/dev/null <<'EOF' [boot] systemd=true [interop] enabled=true appendWindowsPath=true [automount] options = "metadata,umask=22,fmask=11" EOF

2. 关键参数解释：

   • metadata：启用NTFS元数据映射，使chmod +x script.sh在/mnt/c/路径下真正生效（否则权限修改静默失败）；
   • umask=22：设置新建文件默认权限为644（rw-r--r--），fmask=11设置文件掩码为666，避免Windows编辑器创建的文件因权限过高被Linux程序拒绝读取；
   • appendWindowsPath=true：将Windows的PATH追加到WSL的PATH末尾，确保hermes能调用Windows侧的chrome.exe等GUI程序。

3. 强制重启WSL2（此步不可省略）：

# 在PowerShell中执行 wsl --shutdown # 然后重新打开Ubuntu-22.04终端

4. 验证systemd是否生效：

ps -p 1 -o comm= # 正确输出应为 "systemd"，而非 "init" systemctl --version # 应显示 "systemd 249 (249.11-0ubuntu3.12)"

提示：若ps -p 1 -o comm=仍输出init，说明wsl --shutdown未成功。请检查Windows任务管理器中是否有wslservice.exe进程残留，手动结束它后再执行wsl --shutdown。这是WSL2在快速启动模式下的经典bug。

4. Hermes Agent核心安装与配置：从curl到可用的完整链路

4.1 安装脚本执行：为什么必须用curl而非手动下载？

Hermes官方安装脚本（https://hermes-agent.nousresearch.com/install.sh）是动态生成的，其内容根据你的WSL发行版、架构（x86_64/arm64）、以及当前最新稳定版本实时编译。手动下载二进制包会面临：

• 版本错配：hermes-v0.12.3-x86_64-unknown-linux-musl.tar.gz在Ubuntu 22.04上因musllibc与glibc不兼容，解压后./hermes报错No such file or directory（实为动态链接器缺失）；
• 依赖缺失：脚本会自动检测并安装curl、jq、unzip等前置依赖，手动安装需逐个确认版本（如jq必须≥1.6，旧版不支持--argjson参数）；
• 路径污染：脚本将二进制文件安装到~/.local/bin，并自动添加到$PATH，手动操作易遗漏source ~/.bashrc步骤。

安全执行命令（带进度与校验）：

# 下载并校验安装脚本（官方提供SHA256哈希） curl -fsSL https://hermes-agent.nousresearch.com/install.sh.sha256 -o install.sh.sha256 curl -fsSL https://hermes-agent.nousresearch.com/install.sh -o install.sh sha256sum -c install.sh.sha256 # 应输出 "install.sh: OK" # 执行安装（-s 参数静默模式，-v 参数显示详细日志） bash install.sh -s

安装过程约90秒，输出关键日志：

[INFO] Detected WSL2 environment: Ubuntu-22.04 [INFO] Installing hermes v0.12.3 for x86_64-unknown-linux-gnu [INFO] Downloading binary from https://github.com/nousresearch/hermes-agent/releases/download/v0.12.3/hermes-v0.12.3-x86_64-unknown-linux-gnu.tar.gz [INFO] Extracting to /home/hermesuser/.local/bin [INFO] Adding ~/.local/bin to PATH in ~/.bashrc [INFO] Installation complete! Run 'source ~/.bashrc' to use hermes immediately.

4.2 PATH生效与基础验证：三步确认安装成功

安装脚本末尾提示source ~/.bashrc，但很多用户忽略此步，导致hermes命令找不到。完整验证流程：

1. 立即生效PATH：

source ~/.bashrc # 或新开一个WSL终端（更彻底）

2. 验证命令可用性：

hermes --version # 应输出 "hermes 0.12.3" which hermes # 应输出 "/home/hermesuser/.local/bin/hermes"

3. 初始化Hermes环境（创建默认配置）：

hermes init # 此命令会生成 ~/.hermes/config.yaml，默认启用本地模型发现、禁用Telemetry

注意：hermes init会询问“是否启用匿名使用统计”，强烈建议选择N。Hermes的Telemetry模块会向telemetry.nousresearch.com发送设备ID、会话时长、技能调用频次等数据。虽然官方声明“不收集个人身份信息”，但作为本地AI代理，最小化外部通信是安全基线。

4.3 Dashboard启动与网络穿透：让Windows浏览器能访问WSL2服务

Hermes Dashboard默认绑定127.0.0.1:8080，这在WSL2中意味着“仅本虚拟机内可访问”。要让Windows浏览器通过http://localhost:8080访问，需配置网络穿透：

方案A：Windows 11 22H2+ 镜像网络模式（推荐）

1. 在PowerShell中创建%USERPROFILE%\.wslconfig：

@' [network] mirroring=true '@ | Out-File -FilePath "$env:USERPROFILE\.wslconfig" -Encoding utf8

2. 重启WSL2：

wsl --shutdown # 重新打开Ubuntu终端

3. 启动Dashboard：

hermes dashboard --host 0.0.0.0:8080 # 或更简洁的 hermes dashboard # 因为镜像模式下，0.0.0.0绑定会自动发布到Windows localhost

4. 在Windows浏览器中访问http://localhost:8080，应看到Hermes Dashboard登录页。

方案B：Windows 10/NAT模式端口转发（兼容性方案）

若你使用Windows 10或旧版Win11，需手动配置端口转发：

# 在管理员PowerShell中执行 $wslIp = (wsl hostname -I).Trim() netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=8080 connectaddress=$wslIp connectport=8080 New-NetFirewallRule -DisplayName "Hermes Dashboard 8080" -Direction Inbound -Protocol TCP -LocalPort 8080 -Action Allow

然后在WSL中启动：

hermes dashboard --host 0.0.0.0:8080

实操心得：NAT模式下$wslIp每次wsl --shutdown后都会变化，上述命令需每次重启后重跑。我将其封装为wsl-port-forward.ps1脚本，并通过Windows任务计划程序设置为“用户登录时”触发，彻底解放双手。

5. 生产级配置：让Hermes在WSL2中真正稳定、高效、可扩展

5.1 systemd服务配置：告别终端关闭即服务死亡

Hermes Gateway是核心服务，需7x24小时运行。systemd是唯一可靠方案：

1. 创建用户级service文件：

mkdir -p ~/.config/systemd/user cat > ~/.config/systemd/user/hermes-gateway.service <<'EOF' [Unit] Description=Hermes Agent Gateway After=network.target [Service] Type=simple Environment="HOME=/home/hermesuser" Environment="PATH=/home/hermesuser/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" ExecStart=/home/hermesuser/.local/bin/hermes gateway --host 0.0.0.0:8080 --api-server-enabled true Restart=always RestartSec=10 StandardOutput=journal StandardError=journal SyslogIdentifier=hermes-gateway [Install] WantedBy=default.target EOF

2. 启用并启动服务：

systemctl --user daemon-reload systemctl --user enable hermes-gateway.service systemctl --user start hermes-gateway.service

3. 验证服务状态：

systemctl --user status hermes-gateway.service # 应显示 "active (running)"，且"Loaded:"行显示 "enabled" journalctl --user-unit hermes-gateway.service -f # 实时查看日志

提示：--user参数至关重要。WSL2中systemd以用户会话运行，非系统级。若漏掉--user，systemctl会报错Failed to connect to bus: No such file or directory。

5.2 GPU直通配置：让本地大模型真正“飞”起来

Hermes调用vLLM或llama.cpp时，GPU加速是性能分水岭。WSL2 GPU直通无需额外驱动：

1. Windows端：安装最新NVIDIA Game Ready Driver（≥535.98），无需在WSL2内安装nvidia-driver；
2. WSL2端：验证GPU识别：

nvidia-smi # 应显示GPU型号、温度、显存使用率 # 若报错"command not found"，安装nvidia-utils： sudo apt update && sudo apt install -y nvidia-cuda-toolkit

3. Hermes配置：在~/.hermes/config.yaml中启用CUDA：

providers: vllm: host: "http://localhost:8000" model: "meta-llama/Meta-Llama-3-8B-Instruct" # 添加GPU参数 extra_args: - "--tensor-parallel-size=1" - "--gpu-memory-utilization=0.9"

4. 启动vLLM服务（在WSL2中）：

# 安装vLLM（需CUDA 12.1+） pip3 install vllm # 启动（自动使用GPU） python3 -m vllm.entrypoints.api_server \ --model meta-llama/Meta-Llama-3-8B-Instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --host 0.0.0.0 \ --port 8000

实测对比：在RTX 4090上，llama-3-8b单次推理（512 tokens）：

• CPU模式：12.4秒
• GPU模式（WSL2直通）：1.8秒（提速6.9倍）
• GPU模式（Windows原生Ollama）：2.1秒（因Windows驱动层转换损耗）

5.3 文件系统最佳实践：把90%的性能问题扼杀在摇篮里

所有Hermes相关操作必须严格限定在WSL2原生文件系统（/home/hermesuser/）：

• Hermes安装目录：~/.hermes/（自动创建，无需干预）
• 代码仓库：~/code/my-project/（而非/mnt/c/Users/you/code/）
• 模型缓存：~/.cache/huggingface/（pip3 install huggingface-hub后自动配置）
• 临时文件：/tmp/（而非/mnt/c/Temp/）

强制路径检查脚本（加入~/.bashrc）：

# 检查当前目录是否在/mnt/c/下，若是则警告 check_wsl_path() { if [[ "$PWD" == "/mnt/"* ]]; then echo "⚠️ WARNING: You are in /mnt/c/ path! Performance will be severely degraded." echo " Switch to ~/code/ for development work." fi } PROMPT_COMMAND="check_wsl_path; $PROMPT_COMMAND"

经验教训：我曾将一个12万行的Python项目放在/mnt/c/Users/you/project，hermes chat中执行rg "def test_"耗时47秒；移至~/code/project后，同一命令仅需3.2秒。这不是玄学，是9P协议与ext4文件系统的本质差异。

6. 常见问题与避坑指南：那些官方文档不会写的血泪经验

6.1 “Connection refused”错误：Ollama/LM Studio连接失败的终极排查表

现象	根本原因	解决方案	验证命令
hermes gateway日志报Failed to connect to http://localhost:11434	Ollama绑定127.0.0.1，WSL2中localhost指向自身，非Windows宿主机	Windows中启动Ollama时加参数： ollama serve --host 0.0.0.0:11434	curl -v http://HOST-IP:11434/api/tags（HOST-IP为Windows局域网IP）
连接超时（timeout）	Windows防火墙阻止入站连接	在PowerShell中执行： New-NetFirewallRule -DisplayName "Ollama WSL" -Direction Inbound -Protocol TCP -LocalPort 11434 -Action Allow	Test-NetConnection -ComputerName HOST-IP -Port 11434
返回404或空响应	Ollama服务未启动，或WSL2中curl未指定--noproxy '*'	在WSL2中执行： curl --noproxy '*' http://HOST-IP:11434/api/tags	ollama list在Windows中应显示已拉取模型
Permission denied访问/mnt/c/Users/...	/mnt/c/挂载时未启用metadata选项	重新配置/etc/wsl.conf，确保options = "metadata,..."，然后wsl --shutdown	ls -l /mnt/c/Users/you/应显示正确权限（如drwxrwxrwx）

6.2 “bad interpreter: /bin/bash^M”：行尾符灾难的根治方案

此错误99%源于在Windows编辑器（VS Code、Notepad++）中修改了WSL2内的shell脚本。解决方案分三步：

1. 全局Git配置（一劳永逸）：

git config --global core.autocrlf input git config --global core.eol lf

2. 修复现有文件：

# 安装dos2unix sudo apt install -y dos2unix # 批量转换（假设脚本在~/scripts/） find ~/scripts -name "*.sh" -exec dos2unix {} \;

3. VS Code终极设置（防患未然）：

• 打开VS Code设置（Ctrl+,）
• 搜索files.eol，设为LF
• 搜索files.autoSave，设为onFocusChange
• 搜索editor.formatOnSave，设为true

提示：core.autocrlf input的含义是“检出时转LF，提交时保持LF”，完美适配WSL2开发。若设为true（Windows模式），则检出时会转CRLF，再次引发问题。

6.3 Dashboard打不开/白屏：网络与证书的隐形杀手

现象	排查步骤	解决方案
浏览器显示ERR_CONNECTION_REFUSED	1.systemctl --user status hermes-gateway.service确认服务运行 2.ss -tuln | grep :8080确认端口监听	若服务未运行，systemctl --user start hermes-gateway；若端口未监听，检查hermes-gateway.service中ExecStart路径是否正确
页面加载后白屏，控制台报Failed to load resource: net::ERR_CERT_AUTHORITY_INVALID	1. 访问http://localhost:8080（HTTP）而非https://localhost:8080 2. 检查Hermes是否启用了HTTPS重定向	在~/.hermes/config.yaml中确保https_redirect: false，或直接用HTTP访问
hermes dashboard命令无响应，卡住	1.hermes --version确认命令正常 2.free -h检查内存是否耗尽（Dashboard需≥2GB空闲内存）	关闭其他内存密集型应用，或在hermes dashboard后加--memory-limit 1g参数限制内存使用

6.4 WSL2磁盘空间爆炸：VHDX文件不自动收缩的真相

WSL2将Linux文件系统存储为%LOCALAPPDATA%\Packages\...\LocalState\ext4.vhdx，删除文件后VHDX大小不变。清理步骤：

1. 在PowerShell中执行（需管理员权限）：

# 关闭WSL wsl --shutdown # 获取VHDX路径（替换为你的实际路径） $vhdPath = "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\ext4.vhdx" # 使用diskpart收缩（比Optimize-VHD更可靠） $diskpartScript = @" select vdisk file="$vhdPath" attach vdisk readonly compact vdisk detach vdisk "@ $diskpartScript | diskpart

2. 验证效果：

Get-Item $vhdPath | Select-Object Name, Length | Format-Table -AutoSize # 对比收缩前后的Length值

实测：一个膨胀至120GB的VHDX，执行compact vdisk后降至32GB，释放88GB空间。此操作安全，无需备份。

7. 进阶扩展：从单机Agent到团队AI工作流

7.1 多Profile协同：为不同项目配置专属Agent环境

Hermes的Profiles功能允许你为不同任务创建隔离环境。例如：

• ># 初始化新Profile hermes profile init># 创建启动快捷方式，目标栏填写： "C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222 --user-data-dir="C:\chrome-profile"
  2. WSL2端：配置MCP Bridge：

  # 安装bridge pip3 install chrome-devtools-mcp #