给 Agent 搭操作系统：Hermes vs OpenClaw

这是 @servasyy_ai "Harness Engineering" 系列的第二篇（第一篇讲理论框架）。评论区问得最多的是"道理都懂，具体怎么做"——所以这篇不讲一种方案，而是对比两种路径：

• Hermes-Agent：Nous Research 发布的自进化 Agent 框架；
• 自建 Harness：作者基于 OpenClaw 搭的 MemOS 系统（凤凰架构）。

评判框架是 Harness Engineering 的三根支柱：

1. 记忆治理——治 Agent 的失忆症；
2. 架构约束——明确职责边界；
3. 评估闭环——保证质量、防质量漂移。

以下来自 @servasyy_ai。Hermes 的核心理念：Agent 应该像人脑——工作记忆有限必须精炼，但能通过多层记忆架构随时回溯深层信息。

三层记忆架构

复制~/.hermes/memory/
  MEMORY.md    # L1 热记忆：2200 字符上限，工作记忆
  USER.md      # L1：1375 字符上限，用户画像和偏好
  external/    # L2：外部 Provider（Honcho 语义搜索等 8+ 个）
  sessions/    # L3：历史对话，SQLite FTS5 全文检索

L1 热记忆由 Agent 通过 memory 工具主动管理：memory add（加）、memory replace（改）、memory remove（删）。满了必须做选择：删旧的，或合并相关记忆。L2 提供语义搜索的长期存储，L3 用 FTS5（<50ms）全文检索历史对话——想找总能找到。

其他关键特性

• 主 Agent + 并行子 Agent：子 Agent 是 isolated 的（独立 session/对话线程/终端），启动时继承主 Agent 的记忆快照（MEMORY.md + USER.md），用完即毁；
• Personality + Context Files：~/.hermes/context/ 下 project.md / style.md / conventions.md 注入项目知识；
• Progressive disclosure：启动只注入 Skill 描述索引，需要时再加载全文，省 token；
• 成本控制：Frozen Snapshot 保护 prefix cache，Auxiliary 副驾模型路由降级；
• CLI 优先：终端 + Telegram/Discord/Slack，轻量快速。

以下来自 @servasyy_ai。自建 MemOS 的核心理念：记忆不该有上限，用混合搜索保检索质量，用自动去重防膨胀。

技术底座与 Hook：100% 捕获的秘密

复制PostgreSQL 17 + pgvector
  memories 表      # 35,000+ 条记忆
  skills 表        # 几百个 Skill
  task_skills 表   # 任务与 Skill 的关联
  memory_graph 表  # 65,524 条关系边

传统方案捕获率只有约 60%，因为依赖 Agent"记得"去存——忙忘了、觉得不重要、session 崩了没来得及。MemOS 用 OpenClaw 的事件驱动 Hook 实现系统强制：

• before_agent_start（启动前）：自动检索相关记忆，强制注入 System Prompt——Agent 想不看都不行；
• agent_end（结束后）：自动捕获完整对话，走智能去重。

智能去重三层：①内容哈希精确去重；②Top-5 相似度检测（阈值 0.75）；③LLM 最终裁决（DUPLICATE 跳过 / UPDATE 合并 / NEW 新建）。反复聊同一话题，记忆自动合并进化而不是堆成重复条目。

混合搜索：BM25（精确匹配）+ 向量余弦（text2vec-base-chinese，语义理解）+ RRF 融合。"Python 错误处理"和"异常捕获"是同一个意思——FTS5 只能匹配关键词，混合搜索能理解语义。

两级共享架构：有策略的知识流动

传统共享三困境：单一共享库→隐私泄露；各自独立→知识孤岛；定期同步→冲突复杂。MemOS 的两级设计：

• 同实例内共享（Local Scope）：物理同库、逻辑隔离，每条记忆有 owner 字段，scope=private/shared/public 控制可见范围，零拷贝；
• 跨实例 Hub-Client：Hub 是 HTTP Server（监听 gatewayPort+11），自签 HMAC Token；主动推送非自动同步——私有数据永不离本地，Hub 只返摘要、详情二次请求。

以下来自 @servasyy_ai。这是两种方案差异最大的地方。

Hermes 的 Skill：主动生成，但质量控制薄弱

Agent 自主调 skill_manage 创建，Skills 存 ~/.hermes/skills/，有 Skills Hub 社区生态。已知问题：Skill 重复制造是社区高频反馈——后台 review 的去重/合并不够强，且无法追溯"这个 Skill 从哪来的"。

MemOS 的 Skill：四步自动生成 + Auto-recall

从早期 VKitty"临终反哺"（靠 Agent 自觉，捕获率 60%）进化到 MemOS：把"Agent 的职责"变成"系统的能力"。

1. 规则过滤：chunks 数量达阈值 + 内容非平凡，过滤噪音；
2. 混合检索：FTS + Vector + RRF 找已有相关 Skill，决定升级还是新建；
3. LLM 决策：confidence ≥ 0.7 升级已有、< 0.3 建新、中间跳过——阈值是跑两周数据调出来的；
4. 质量评分：0–10 分，≥ 6 分才入库，同时建 task_skills 关联记进化轨迹。

全程异步，不阻塞 Agent 主流程。

Auto-recall 是关键：生成了 Skill 还不够，要让它在正确时机出现在正确 Agent 面前。before_agent_start Hook 在 Agent 启动时自动检索注入相关 Skill——Agent 想不看都不行，它是系统级拦截器不是可选 API。

架构约束：职责边界

Hermes 是主 Agent + 临时子 Agent 并行；自建是 4 常驻 Agent（智库/黄家 1 号/技术顾问/创意伙伴）+ 按需工蜂（写作/配图/爬虫工蜂）。所有 Agent 共享 shared-knowledge/：AGENTS.md 自动注入 System Prompt 即"DNA"——工具规范、输出语言、写作风格、禁忌词、反哺规范，工蜂出生自带团队全部基因。工蜂完成任务后 Hook 自动捕获轨迹（临终反哺）。

以下来自 @servasyy_ai。第三根支柱：Agent 做完了你不知道对不对，时间长了质量漂移还发现不了。

Hermes：Cron 调度 + 消息推送

定时任务自动检查系统健康，异常时推送到 Telegram/Discord/Slack。简单直接、手机能收，但没有明确的质量审核与失败反思机制，评估标准不可配置。

自建：心跳 + 智库审核 + 延迟反思

• 心跳检查：定期自检，正常不说话、异常才告警；
• TODO 一致性检查：TODO.md 里标 ⏳ 但记忆里已完成→直接修正 + 通知。做完不改 TODO = 制造假信息，铁律；
• 智库审核：工蜂产出先交智库审（带证据吗？合配方吗？质量达标吗？），不合格打回重做——Agent 不能给自己打分；
• 反思系统（延迟分析）：Hook 记失败 → JSONL 按日期分片 → 凌晨 Cron 批量分析根因 → 能修自动修。为什么延迟？成本低 10 倍、不阻塞主流程、能发现跨 session 的系统性模式（连续三天同一工具同一时段失败，就是系统性问题）。

真实运营数据

以下来自 @servasyy_ai 的实测数据：

成本对比

• Hermes：安装 10 分钟、配置 30 分钟、上手 1 小时；个人每月 $10–50；维护主要是更新版本和偶尔清 MEMORY.md；
• 自建：搭基础设施 1–2 周、调试 1–2 周、上手 2–4 周；4 个 Agent 每月约 $200–300（含对话、Skill 生成、反思分析、向量生成）。

四个场景选型

分阶段实施建议（选自建的话）：先搭 MemOS 跑起来（PostgreSQL+pgvector 或 SQLite+FTS5，两个 Hook，哈希去重）→ 定义角色与配方库 → 加评估机制（心跳/互评/TODO 检查）→ 一个月后看到轨迹复利，再上 Skill 自动生成、可视化、反思系统。先跑起来，再优化。