对比、优缺点及路线图
Engram 与自动内存引擎处于不同的内存生态空间。它重点针对人类所有权、可评审性和可移植性进行了优化。
Engram 的优势
- 纯文本 Markdown 格式的事实唯一来源（source of truth）。
- 持久写入前必须经过人类批准。
- Git 原生的审计历史与同步。
- 工作区优先（workspace-first）和全局后备（global-fallback）的内存分级。
- 独立于智能体：任何智能体都可以直接读取 Markdown。
- 安全保障层：Schema 校验、秘密扫描、注入扫描、哈希完整性校验和忽略规则。
- 不需要运行常驻进程（daemon）、数据库或云端账户。
- 导入、观察、归档、图谱、基准测试和修复流程为长期维护提供支持。
Engram 的权衡点 (Tradeoffs)
- 自动化程度低于基于常驻守护进程（daemon）的内存系统。
- 默认搜索是确定性的词汇搜索；
search --semantic增加了确定性的局部相似度匹配，而不是基于第三方向量模型服务的语义搜索。 - 图谱向量是局部哈希的词向量，而不是高维语义嵌入。
- 矛盾检测是启发式且仅具建议性的。
deduplicate --semantic使用确定性的局部相似度，不调用外部向量服务。- 模式挖掘、加密配置和 PR 工作流设计资产虽已存在，但在运行时的完整工作流尚未完全打通。
- 内存图谱完全依赖于自动生成的标签和摘要。
与 Agentmemory 的对比
rohitg00/agentmemory 是一个适用于编码智能体的强大的自动内存引擎。其 README 介绍了基于服务器的内存、MCP/hooks/REST 集成、许多智能体适配器、基准测试声明、查看器、回放功能、混合检索以及 Hermes 集成。
当您需要自动捕获、实时查看器/回放、向量检索、多个 MCP 工具和服务器端共享内存时，请使用 agentmemory。
当您希望内存成为仓库可读的协议时，请使用 Engram：Markdown 优先、人类批准、Git 评审，即使没有运行中的服务器也能跨智能体移植。
| 对比维度 | Engram | agentmemory |
|---|---|---|
| 唯一事实来源 | 批准的 Markdown 文件 | 内存服务器 / 数据库 |
| 信任边界 | 人类 A/B/C 批准 | 自动捕获加工具治理 |
| 默认模式 | 文件协议，不需要常驻进程 | 推荐运行后台服务 |
| 评审机制 | Git diff 和 Markdown 评审 | 查看器/API 和存储的会话 |
| 最合适场景 | 需要所有权和可审计性的团队 | 需要自动召回和回放的个人用户 |
| 风险点 | 需要更多的手动纪律规范 | 除非严密治理，否则会产生更多隐性状态 |
与 Hermes Agent 的对比
总结 (TL;DR)
| Engram | Hermes Agent | |
|---|---|---|
| 设计哲学 | 人类所有、文件优先的协议 (可选自动执行) | 自主、始终激活的内存 |
| 存储方式 | .agents/.engram/ 中的分类 Markdown 文件 | MEMORY.md + USER.md (硬性字符限制) |
| 写入模型 | 默认由人类批准 (A/B/C 闸门；可通过规则自动执行) | 智能体自主写入 |
| 召回机制 | 按需：engram load "<任务>" 注入相关文件 | 始终开启：每个会话的核心文件冻结到系统提示词中 |
| 向量搜索 | 可选本地 sqlite-vec (确定性，非嵌入支持) | 通过外部提供商 (例如 agentmemory — BM25 + 向量) |
| 跨智能体 | 任何可读取文件的智能体都可使用 Engram 内存 | Hermes 核心是单智能体；通过 agentmemory 插件实现跨智能体 |
| 可移植性 | Git 原生、离线优先、纯 Markdown | 本地文件；外部提供商可能会引入云端锁定 |
| 运行开销 | 无需后台守护进程，需要保存纪律 (除非配置了自动化) | 服务器进程 + 查看器 UI、REST API、MCP 服务器 |
存储格式
Engram 将每个内存存储为带有 YAML 前言（frontmatter）、哈希完整性校验和可选依赖图（depends_on）的分类 Markdown 文件。JSON 索引、图谱和 sqlite-vec 侧车（sidecar）作为加速层——Markdown 是唯一事实来源。
Hermes 将所有持久内存压缩为两个受限文件：
~/.hermes/memories/MEMORY.md—— 智能体笔记，上限为 2,200 个字符~/.hermes/memories/USER.md—— 用户画像，上限为 1,375 个字符
硬性字符限制促使智能体去精选而不是累积。会话历史记录可通过 SQLite FTS5 进行搜索。
写入模型
Engram —— 默认采用明确的人类闸门。智能体提出候选内存；人类必须在写入磁盘前进行批准。机密信息和提示词注入扫描在保存时进行。 (注：用户可以通过保存一条规则来选择自动执行此过程，例如在回复完成时自动保存智能体新提议的内存，从而建立自动保存流程)。
Hermes —— 自主。智能体决定写什么以及何时写，仅受字符上限约束。核心循环中无需人类批准。
召回模型
Engram —— 按需路由。engram load "<任务>" 根据标签、类型、时效性、图谱和可选向量信号对候选进行重新排序，然后将紧凑包（默认 8 个文件）注入到上下文。
Hermes —— 始终激活的注入。会话开始时核心文件会被冻结到系统提示词中。可选的外部提供商（例如 agentmemory）在每次 LLM 轮次之前运行预取，并在之后进行同步。
何时使用哪个
当您需要可审计、经人类审查的内存、通过 Git 共享团队内容、隐私保证或跨工具的智能体无关可移植性时，使用 Engram (并可选择通过自定义规则自动保存)。
当您希望内存无需保存纪律自动累积、始终开启的上下文注入，或具有查看器、REST API 和可插拔向量后端的更丰富运行时环境时，使用 Hermes。
与智能体内置内存的对比
内置的智能体内存很方便，但通常与单个主机绑定。它可能难以进行对比（diff）、导出、评审或与其他智能体共享。
Engram 将内置内存视为便利层，而不是权威来源。权威仍然是人类拥有的文件。
路线图想法
- 用于图谱向量和搜索的可选局部嵌入（embedding）提供程序。
- 更好的图谱诊断，用以解释特定内存被路由的原因。
- 签入仓库的基准测试基准数据（fixtures），以便跟踪召回率是否下降。
- 结合图谱、质量检查和归档的更强大的矛盾冲突评审工作流。
- 针对
agentmemory各种导出变体的更多导入测试。 - 用于语义重复项检测的可选外部嵌入提供程序。
- 能够在报告无效内存文件后提议修复方案的修复（repair）工作流。
下一步：返回到首页。