hermes-lcm 评测：把上下文压缩从有损摘要改成可钻取的 DAG

它解决什么问题

Hermes Agent 内置的压缩器在提示词超过阈值时，会修剪旧的工具结果，让辅助模型总结中段对话，然后用摘要加最近尾部重建活动提示。原始会话行可能留在 state.db 里，也能通过 session_search 搜索，但模型的活动上下文不再包含被压缩回合的原文，也没有结构化的下钻路径。hermes-lcm 针对这个痛点：它把原始消息持久化到插件自己的 SQLite 存储，把旧上下文压成深度感知的摘要节点，再把摘要聚合成有层次的有向无环图（DAG）。活动上下文由系统提示、最高价值摘要和受保护的新鲜尾部组装而成。关键是，智能体可以通过工具搜索、检查和展开压缩材料，而不必把全部内容塞回提示词。这个插件面向的是那些需要长会话、且不能接受上下文丢失的 Hermes 用户，比如复杂的多步骤任务或持续对话场景。

核心机制：从一次性摘要到可召回 DAG

hermes-lcm 的工作流程分五步。第一步，把消息持久化到插件本地的 SQLite 存储，并附带 FTS 元数据。第二步，把旧上下文压缩成深度感知的摘要节点。第三步，随着摘要积累，把它们进一步聚合成 DAG。第四步，从系统提示、最高价值摘要和受保护的新鲜尾部组装活动上下文。第五步，提供召回工具，让智能体搜索、检查和展开压缩材料，而不淹没主提示。关键设计是源血统（source lineage）：原始行和摘要节点都保留来源信息，检索时可以按后代过滤。这跟内置压缩的本质区别在于，内置压缩是一次性的，压缩后活动上下文里没有原文，也没有结构化的恢复路径；而 hermes-lcm 的召回是活动上下文引擎的一部分，当前会话的检索直接通过 LCM 工具完成，不是辅助的跨会话搜索步骤。

安装与激活：两条路径和两个名字

安装 hermes-lcm 需要先有 Hermes Agent 和 Python 3.11+。官方推荐的方式是把仓库克隆为通用用户插件：git clone https://github.com/stephenschoettler/hermes-lcm ~/.hermes/plugins/hermes-lcm。如果只想在某个 profile 下使用，就克隆到 ~/.hermes/profiles/myprofile/plugins/hermes-lcm。从已有检出目录里，可以运行 ./scripts/install.sh 来创建符号链接，profile 感知的安装则用 HERMES_PROFILE=myprofile ./scripts/install.sh。注意，即使检出目录已经在规范插件路径上，也要运行 install.sh，因为它会在匹配的全局或 profile 的 skills 目录里暴露内置的 hermes-lcm 技能。安装器会预先检查两条路径，遇到冲突会拒绝创建链接。激活时，插件有两个名字：插件清单名是 hermes-lcm，运行时上下文引擎名是 lcm。配置里要同时设置 plugins.enabled 包含 hermes-lcm，以及 context.engine 为 lcm。改完配置必须重启 Hermes。

召回工具与策略：不是搜索，是下钻

hermes-lcm 提供了一组工具，包括 lcm_grep、lcm_recall、lcm_query_state、lcm_compute、lcm_compile_evidence、lcm_evidence_pack、lcm_retrieve、lcm_recent、lcm_load_session、lcm_describe、lcm_expand、lcm_expand_query、lcm_status、lcm_inspect 和 lcm_doctor。这些工具的核心是分页恢复：原始消息按有界页面返回，子摘要和外部化载荷也分页，而不是一次性倒进提示词。文档里提到一个召回技能和策略（Recall skill and policy），但没有给出具体策略内容。从工具清单看，lcm_recall 用于按需召回，lcm_expand 用于展开某个节点，lcm_grep 用于搜索，lcm_recent 用于按自然时间召回。这套设计把召回从被动的搜索变成主动的下钻：智能体可以先看摘要，再决定展开哪一层。

可选功能家族：从压缩层到记忆系统

除了核心压缩循环，hermes-lcm 还有三个默认关闭的功能家族。第一个是大输出外部化和上下文预算控制，巨大的工具结果会移到可恢复的引用里，而不是挤占提示词。第二个是时间记忆，提供日、周、月汇总，以及通过 lcm_recent 进行自然时间召回。第三个是语义检索，lcm_grep 支持语义或混合模式，可以用免费层云服务或完全本地的嵌入提供商。这三个家族默认关闭，意味着需要用户显式开启才能获得完整记忆能力。文档提到有特性概览和按智能体类型的配置 profile，但没给出具体配置键。这个设计的好处是核心插件保持轻量，坏处是用户需要额外阅读文档才能解锁高级功能。

依赖与降级：tiktoken 和 regex 的可选性

hermes-lcm 没有必需的第三方运行时依赖。如果安装了 tiktoken，就用它做 token 估计；否则回退到基于字符的估计。如果安装了 regex，就用来对消息忽略模式应用超时；否则消息级正则过滤会被禁用，并给出警告，而不是运行无界的 stdlib re 匹配。这个降级策略值得注意：没有 regex 时，消息忽略功能会静默失效，只留下警告。对于依赖消息过滤的用户，这可能是一个坑。安装时应该明确检查这两个可选依赖是否满足。文档没有说明 tiktoken 缺失时 token 估计的准确度差异，但字符估计显然不如 token 精确，可能影响上下文预算的判断。

局限与替代方案

hermes-lcm 的局限在文档里部分可见。它是插件，依赖 Hermes Agent 的插件机制，不是独立工具。它引入了额外的 SQLite 存储，意味着磁盘占用和可能的性能开销。召回工具虽然强大，但智能体必须主动调用，如果智能体不调用，压缩后的内容仍然不会自动出现在活动上下文里。文档明确说，不要声称 Hermes 核心没有持久化压缩前历史，因为内置压缩也可能在 state.db 里保留原始会话。替代方案是 Hermes Agent 的内置压缩器，它更简单，没有额外存储，但压缩后活动上下文里没有原文和结构化恢复路径。另一个灵感来源是 lossless-claw，那是给 OpenClaw 的类似插件，但本文材料没有提供细节。选择的关键在于：你是否需要当前会话内的主动召回能力，还是可以接受跨会话搜索。

维护与许可

hermes-lcm 的许可证是 MIT，这意味着可以自由使用、修改和分发，只要保留版权声明。仓库最近的发布节奏是 v0.19.0 在 2026 年 7 月，v0.20.0 在 7 月底，v0.21.0-rc2 在 8 月初，看起来维护活跃。项目没有被归档，默认分支是 main。升级成本方面，插件有诊断工具，包括运行时健康检查、数据库检查、可选的 /lcm 斜杠命令，以及备份优先的修复和轮转路径。这些工具暗示了升级或故障时需要处理数据库完整性。文档没有给出具体的迁移指南，但备份优先的修复路径至少提供了一个安全的降级手段。采用者应该把插件版本和 Hermes Agent 版本一起锁定，因为插件接口可能随 Hermes 变化。

编辑结论

hermes-lcm 适合需要长时间会话、且对上下文丢失敏感的开发者和智能体应用。它不适合只需要简单摘要压缩、或不想引入额外存储和工具依赖的场景。采用前先验证三点：确认 Hermes Agent 版本兼容性，检查插件安装路径是否与现有插件冲突，并在真实会话中测试召回工具的延迟和准确性。该插件的核心价值在于把压缩从不可逆的摘要变成可钻取的 DAG，但代价是额外的 SQLite 存储和工具调用开销。

官方来源

1. Official README
2. Project repository
3. Release notes