Posts

Agent 系列日记 5：为什么 Skill 路由比 ReAct 控制器更适合个人助理

从 luck-agent 到 Hermes-lite，我花了两年时间才想清楚这个问题：80% 的请求不需要"思考"，只需要"路由"。

回顾：ReAct 控制器模式的困境

2024 年做 luck-agent 的时候，我采用的是经典的 ReAct 模式（Reasoning + Acting）：

用户输入 → 大模型推理（意图识别 → 规划 → 工具选择 → 执行）→ 输出

所有请求，不管简单还是复杂，都走同一个推理链。一个"查 QPC 里有没有 VPS 相关的记录"的请求，也要经过：

  1. 理解自然语言
  2. 判断意图类别
  3. 选择工具（search_qpc）
  4. 构造查询参数
  5. 执行并解释结果

问题很明显：

  • Token 消耗大：每次推理要带上完整的 system prompt + 工具定义，光上下文就吃掉 3000-5000 token
  • 延迟高：一个简单查询要等模型完成完整推理链，响应时间 3-8 秒
  • 上下文窗口压力：随着工具数量增加（现在 Hermes-lite 有 20+ 个工具），system prompt 越来越大

我当时就在知识库里记了一条：

“对于个人助理场景，相比最初的 ReAct 控制器模式，Skill 技能路由更适合当前 luckagent：80% 请求是固定模式，不需要复杂推理，技能比 Agent 更稳定，成本更低，响应更快。”

Skill 路由的核心思想

一句话：预定义技能映射，轻量分类先路由，只加载需要的工具和 prompt。

用户输入 → 轻量路由（关键词/意图 → 技能）→ 加载专用 prompt + 工具 → 执行

路由表设计

# 简化版路由逻辑
ROUTING_RULES = {
    "qpc": {
        "keywords": ["QPC", "知识库", "记一下", "记录"],
        "skill": "qpc",
        "tools": ["feishu_bitable_read", "feishu_bitable_write"],
        "prompt": "qpc_skill_prompt"  # 只加载 QPC 相关的 prompt
    },
    "vps": {
        "keywords": ["VPS", "服务器", "防火墙", "Docker"],
        "skill": "gcp-vps-ops",
        "tools": ["terminal", "read_file"],
        "prompt": "vps_skill_prompt"
    },
    "blog": {
        "keywords": ["博客", "文章", "Hugo", "发布"],
        "skill": "hugo-blog",
        "tools": ["terminal", "read_file", "write_file"],
        "prompt": "blog_skill_prompt"
    }
}

对比：同样"查 QPC"操作

指标ReAct 模式Skill 路由
上下文 token~4000（全量工具定义）~800（仅 QPC 相关）
首次响应延迟3-8s0.5-1.5s
工具调用次数2-3 次（推理+执行）1 次（直接执行）
准确率92%（模型可能选错工具）98%（路由确定性高）

Hermes-lite 的 Skill 实现

Hermes-lite 的 skill 系统是这样工作的：

read more
Posts

Hermes-lite 裁剪实战：7 类典型坑与解法

上一篇文章介绍了 Hermes-lite 的整体裁剪思路。这篇深入每一类实际踩过的坑， 把"为什么会遇到"和"怎么解"都说清楚。

一、路径迁移坑

从 .hermes/ 迁到 .hermes-lite/ 后，不是只改 HERMES_HOME 就完事。

踩到的点

  • .skills_prompt_snapshot.json 里残留旧 .hermes/ 路径
  • web_search/SKILL.md 硬编码了旧路径
  • 技能、工具、memory、config、sessions、workspace 各自缓存旧路径
  • systemd 环境变量、进程环境、配置文件、技能正文需要一起排查

经验

  1. 迁移后 grep 全目录旧路径：
grep -r "\.hermes/" /home/user/.hermes-lite/ --include="*.json" --include="*.md" --include="*.yaml" -l
  1. 技能快照要清理重建，不能复用旧缓存
  2. systemd 重启不是可选项 — 长进程内缓存会保留旧状态
systemctl restart hermes-lite
systemctl status hermes-lite  # 确认新 PID

二、技能裁剪坑

一开始容易只看磁盘上有多少 SKILL.md，但真正可用数量要看运行时过滤后的结果。

踩到的点

  • 磁盘上 67 个 SKILL.md，实际 gateway/slash 可见 65 个
  • kanban-orchestrator/worker 因为 environments: [kanban] 被过滤，这是预期不是坏了
  • _find_all_skills(skip_disabled=True) 这个参数名容易误读，实际是返回全部技能，默认才过滤 disabled
  • web_search 技能存在，但 Tavily key 缺失，会变成"看得到但用不了"

经验

判断技能可用性要看三层：

read more
Posts

Hermes-lite 裁剪指南：在 1GB VPS 上跑轻量 AI Agent

为什么要裁剪

完整版 Hermes Agent（Nous Research）功能丰富：多平台网关、浏览器自动化、语音 TTS/STT、多 Agent 协作、Kanban 看板等。但这些功能对资源要求不低——在我的测试里，完整配置更适合至少 2GB 内存的机器。

我有一台 GCP e2-micro（2 vCPU / 954MB RAM），想用它跑一个 24/7 在线的 AI Agent 接入飞书。完整版装不下，于是有了这个裁剪实践。

三阶段渐进式裁剪

裁剪不是一步完成的，而是三阶段递进：

第一阶段：本地 Codex 完成初期核心裁剪

在本地电脑上，利用 Codex（OpenAI） 作为辅助分析工具，对完整版 Hermes 进行全面"解剖"：

  • 逐一扫描 ~/.hermes/ 目录结构，识别每个模块的职责
  • 分析 67 个技能的依赖关系，标记哪些是核心链路的、哪些是边缘功能
  • 梳理 config.yaml 中每个配置项的实际作用，搞清楚"关掉会怎样"
  • 输出一份裁剪清单：哪些 toolset 可以禁、哪些 skill 可以删、哪些配置可以收紧

这一阶段的核心价值：把"能不能关"这个判断做对。Codex 帮助理解了代码间的依赖关系，避免直接关某个功能导致连锁崩溃。

第二阶段：大 VPS 上跑完整版 + 压测验证

在一台大内存 VPS 上安装完整版 Hermes，作为"对照基准"：

  • 记录完整版的实际内存占用（idle / 高负载两种状态）
  • 逐个关闭非核心功能，观察内存变化和稳定性
  • 跑压测：模拟长时间运行、多轮对话、工具调用密集场景
  • 确认裁剪后系统在资源充足环境下依然稳定

这一阶段的目的：建立性能基线 + 验证裁剪组合的安全性。在大 VPS 上翻车无所谓，在小 VPS 上翻车就是服务宕机。

read more