现象：
💻 ls -la /mnt/d/1.pdf 2>/dev/null || echo "File not found" (20.9s)
调研结论：
Hermes Agent 的 checkpoints: enabled: true 会在每次 tool call 前后对整个工作区做文件系统快照。目录文件一旦多起来，这个纯本地的 I/O 操作轻松就能拖出 30-40 秒，而 LM Studio 完全 idle（因为它根本没收到请求）。
详解：
针对这个问题，我查阅了 Hermes Agent 官方文档、GitHub Issue 记录以及社区在 WSL2 下的踩坑经验。社区揭示了一个比"仅因为输出重定向"更底层的真相 ，导致 20 秒卡顿的"真凶"其实是 Checkpoint Manager 的工作区定界缺陷 + WSL2 的跨系统 I/O 瓶颈。
真正的罪魁祸首：工作区定界 (Project Root Resolution)
当你的命令中带有 > 触发 Checkpoint 时，Hermes 会执行以下操作：
- 寻找当前文件或终端所在的"项目根目录"。
- 如果它找不到
.git文件夹，它就会直接把你当前的目录（甚至向上回溯）当成整个项目根目录。 - 官方文档提到 Hermes 有一个防呆机制：
"Hermes skips overly broad directories (root /, home $HOME)"。但这个机制在 WSL 里失效了！- WSL 里的
$HOME是/home/vasts。 - 但你启动对话或操作的路径通常在 Windows 侧，比如
/mnt/c/Users/vasts或/mnt/d/。 - Hermes 不知道
/mnt/c/Users/vasts是你的 Windows 主目录，它以为这只是一个普通项目，于是试图通过极其缓慢的 WSL 9p 挂载协议，对你整个 Windows C 盘用户目录（或整个 D 盘根目录）执行全量git status和git add扫描！
- WSL 里的
我在你的系统里检查了 ~/.hermes/checkpoints/ 影子仓库的记录，证实了这一点。其中一个 Checkpoint 绑定的 HERMES_WORKDIR 居然是指向 /mnt/c/Users/vasts 的，这就是它卡死 20 秒的原因（它在扫你的整个 C 盘用户空间）。
社区主流的 3 种解决姿势
既然用提示词（Prompt）去压制 LLM 的肌肉记忆（2>/dev/null）不可靠，社区开发者通常在工程环境层面解决这个问题：
1. 划定物理边界（最推荐的"Git 锚点"法）
Checkpoint Manager 的搜索逻辑是"寻找最近的 .git 目录"。
如果你要在 /mnt/d/1.pdf 附近或者 ~/tmp/ 目录下让 Agent 干活：
- 做法 ：在这个具体的小文件夹里执行一次
git init（比如cd ~/tmp && git init）。 - 效果 ：当触发 Checkpoint 时，Hermes 看到这里有
.git，就会把~/tmp/作为根目录，快照瞬间就能完成（<0.1 秒），彻底消除 20 秒的卡顿。
本人的具体操作：
- 修改.bashrc: 让进入命令行时，默认位置是wsl_workspace文件夹
- ~/wsl_workspace中，执行一下"git init"
2. "套娃"规避正则检测
如果不得不在没有 Git 保护的大目录下用重定向，社区发现 Hermes 的拦截正则很薄弱：
- 直接发
ls 2>/dev/null会被抓。 - 把它包装在字符串里执行：
sh -c "ls -la /mnt/d/1.pdf 2>/dev/null"，Checkpoint Manager 的正则通常只会扫描顶层命令，看到sh就放行了，不会触发快照。
3. 关闭全局快照，回归手动
如果你的日常使用场景是系统级运维 （在各个大目录、磁盘之间到处查文件），而不是单项目代码开发，社区普遍建议：
- 做法 ：在
~/.hermes/config.yaml中彻底设置checkpoints: enabled: false。 - 理由 ：Checkpoint 机制本身就是为"限定在单一代码仓库内开发"设计的。如果你在全局乱飞，影子 Git 仓库只会无限膨胀并卡死 I/O。防呆功能可以改用
approvals.mode: smart（在执行高危命令前弹窗问你是否同意）来替代。