Posts

Agent 的记忆：Hermes-Lite 如何用 5 层结构解决「鱼的难题」

人类 chatbot 最尴尬的瞬间：第二次见面完全不认识你。Agent 的记忆系统怎么同时做到持久化、低成本、不丢上下文？我深入 Hermes-Lite 源码写了一个月，拆解出 5 层架构。

从「鱼的难题」开始

用过 ChatGPT 的人都知道一个痛：下次打开，它完全不记得你了。

对一次性聊天这没问题。但对个人助理——帮你管理 200 条知识库、追踪几个项目的进度、记住你的偏好——这等于每次都要把整段友情重来。

我做 QPC（个人知识库）时就被这个问题卡过。后来折腾 Hermes-Lite、nanobot，逐步摸到一条可行的路。这篇文章从 Hermes-Lite 的实际源码出发，拆解它的 5 层记忆架构，看看一个 Agent 是怎么解决「鱼的难题」的。

总览：5 层架构

┌─────────────────────────────────────────────┐
│  Layer 1: 持久记忆 (MEMORY.md / USER.md)     │  ← 跨会话，纯文本
├─────────────────────────────────────────────�
│  Layer 2: 会话压缩 (ContextCompressor)       │  ← 长对话不爆
├─────────────────────────────────────────────┤
│  Layer 3: 会话检索 (session_search + FTS5)   │  ← 历史不丢
├─────────────────────────────────────────────�
│  Layer 4: 增量写入门控 (Nudge 机制)           │  ← 该记就记
├─────────────────────────────────────────────�
│  Layer 5: 原子性保障 (fcntl + 临时文件)       │  ← 不丢不坏
└─────────────────────────────────────────────┘

每一层解决一个独立问题，层与层之间不耦合。下面逐层拆解。

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