https://caozuohua.github.io/tags/%E8%BD%BB%E9%87%8F%E5%8C%96/Recent content in 轻量化 on CAO ZUOHUAHugozh-cnThu, 25 Jun 2026 00:00:00 +0000https://caozuohua.github.io/posts/2026-06-25-hermes-lite-pitfalls-deep-dive/Thu, 25 Jun 2026 00:00:00 +0000https://caozuohua.github.io/posts/2026-06-25-hermes-lite-pitfalls-deep-dive/<p>上一篇文章介绍了 Hermes-lite 的整体裁剪思路。这篇深入每一类实际踩过的坑， 把&quot;为什么会遇到&quot;和&quot;怎么解&quot;都说清楚。</p> <hr> <h2 id="一路径迁移坑">一、路径迁移坑</h2> <p>从 <code>.hermes/</code> 迁到 <code>.hermes-lite/</code> 后，不是只改 <code>HERMES_HOME</code> 就完事。</p> <h3 id="踩到的点">踩到的点</h3> <ul> <li><code>.skills_prompt_snapshot.json</code> 里残留旧 <code>.hermes/</code> 路径</li> <li><code>web_search/SKILL.md</code> 硬编码了旧路径</li> <li>技能、工具、memory、config、sessions、workspace 各自缓存旧路径</li> <li>systemd 环境变量、进程环境、配置文件、技能正文需要一起排查</li> </ul> <h3 id="经验">经验</h3> <ol> <li>迁移后 <code>grep</code> 全目录旧路径：</li> </ol> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>grep -r <span style="color:#e6db74">&#34;\.hermes/&#34;</span> /home/user/.hermes-lite/ --include<span style="color:#f92672">=</span><span style="color:#e6db74">&#34;*.json&#34;</span> --include<span style="color:#f92672">=</span><span style="color:#e6db74">&#34;*.md&#34;</span> --include<span style="color:#f92672">=</span><span style="color:#e6db74">&#34;*.yaml&#34;</span> -l </span></span></code></pre></div><ol start="2"> <li>技能快照要清理重建，不能复用旧缓存</li> <li>systemd 重启不是可选项 — 长进程内缓存会保留旧状态</li> </ol> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>systemctl restart hermes-lite </span></span><span style="display:flex;"><span>systemctl status hermes-lite <span style="color:#75715e"># 确认新 PID</span> </span></span></code></pre></div><hr> <h2 id="二技能裁剪坑">二、技能裁剪坑</h2> <p>一开始容易只看磁盘上有多少 <code>SKILL.md</code>，但真正可用数量要看运行时过滤后的结果。</p> <h3 id="踩到的点-1">踩到的点</h3> <ul> <li>磁盘上 67 个 <code>SKILL.md</code>，实际 gateway/slash 可见 65 个</li> <li><code>kanban-orchestrator/worker</code> 因为 <code>environments: [kanban]</code> 被过滤，这是预期不是坏了</li> <li><code>_find_all_skills(skip_disabled=True)</code> 这个参数名容易误读，实际是返回全部技能，默认才过滤 disabled</li> <li><code>web_search</code> 技能存在，但 Tavily key 缺失，会变成&quot;看得到但用不了&quot;</li> </ul> <h3 id="经验-1">经验</h3> <p>判断技能可用性要看三层：</p>https://caozuohua.github.io/posts/2026-06-24-hermes-lite-trimming-guide/Wed, 24 Jun 2026 23:58:52 +0000https://caozuohua.github.io/posts/2026-06-24-hermes-lite-trimming-guide/<h2 id="为什么要裁剪">为什么要裁剪</h2> <p>完整版 Hermes Agent（Nous Research）功能丰富：多平台网关、浏览器自动化、语音 TTS/STT、多 Agent 协作、Kanban 看板等。但这些功能对资源要求不低——在我的测试里，完整配置更适合至少 2GB 内存的机器。</p> <p>我有一台 GCP e2-micro（2 vCPU / 954MB RAM），想用它跑一个 24/7 在线的 AI Agent 接入飞书。完整版装不下，于是有了这个裁剪实践。</p> <h2 id="三阶段渐进式裁剪">三阶段渐进式裁剪</h2> <p>裁剪不是一步完成的，而是三阶段递进：</p> <h3 id="第一阶段本地-codex-完成初期核心裁剪">第一阶段：本地 Codex 完成初期核心裁剪</h3> <p>在本地电脑上，利用 <strong>Codex（OpenAI）</strong> 作为辅助分析工具，对完整版 Hermes 进行全面&quot;解剖&quot;：</p> <ul> <li>逐一扫描 <code>~/.hermes/</code> 目录结构，识别每个模块的职责</li> <li>分析 67 个技能的依赖关系，标记哪些是核心链路的、哪些是边缘功能</li> <li>梳理 config.yaml 中每个配置项的实际作用，搞清楚&quot;关掉会怎样&quot;</li> <li>输出一份裁剪清单：哪些 toolset 可以禁、哪些 skill 可以删、哪些配置可以收紧</li> </ul> <p>这一阶段的核心价值：<strong>把&quot;能不能关&quot;这个判断做对</strong>。Codex 帮助理解了代码间的依赖关系，避免直接关某个功能导致连锁崩溃。</p> <h3 id="第二阶段大-vps-上跑完整版--压测验证">第二阶段：大 VPS 上跑完整版 + 压测验证</h3> <p>在<strong>一台大内存 VPS</strong> 上安装完整版 Hermes，作为&quot;对照基准&quot;：</p> <ul> <li>记录完整版的实际内存占用（idle / 高负载两种状态）</li> <li>逐个关闭非核心功能，观察内存变化和稳定性</li> <li>跑压测：模拟长时间运行、多轮对话、工具调用密集场景</li> <li>确认裁剪后系统在资源充足环境下依然稳定</li> </ul> <p>这一阶段的目的：<strong>建立性能基线 + 验证裁剪组合的安全性</strong>。在大 VPS 上翻车无所谓，在小 VPS 上翻车就是服务宕机。</p>