oh-my-hermes记忆系统如何与Hermes原生记忆共存一文读懂绝不读改的边界设计【免费下载链接】oh-my-hermesAll in one plugin for Hermes Agent ⚚ the coding intelligence, a long-term memory system and model optimized workflow packages项目地址: https://gitcode.com/GitHub_Trending/ohm/oh-my-hermesoh-my-hermesOMH是一个为 Hermes Agent 打造的一体化插件核心能力包括工作流编排、长期记忆系统和模型优化包。它最特别的设计之一是自带一套本地项目记忆库与 Hermes 原生的MEMORY.md、USER.md记忆文件并行共存同时守住一条铁律OMH绝不读取、绝不修改 Hermes 的内部记忆。这种只围观、不动手的边界设计既让两套记忆各司其职又避免了插件悄悄改写用户数据的隐患。本文用大白话讲清楚两套记忆系统怎么分工、边界是怎么设计的、以及降级审核这些机制对新手意味着什么。两套记忆系统各管一摊 先搞懂一个前提装了 OMH 之后你其实拥有两套独立的记忆Hermes 原生记忆OMH 项目记忆存在位置MEMORY.md、USER.md等文件本地.omh记录存储谁可以写入只有 Hermes 自己的记忆工具用户审核后的 OMH 记录是否每轮对话都占用上下文是L1 层有字符上限否L2 层按需预取审核机制无随写随用候选 → 审核 → 批准全程留痕生命周期无过期 / 复审 / 归档时钟可配官方文档 docs/MEMORY.md 开篇就写明OMH 不读取、不修补、不修改 Hermes 的不透明内部记忆。也就是说OMH 对自己的记忆负责对 Hermes 的记忆敬而远之。绝不读改边界到底是怎么设计的️这是整个记忆系统最值得新手理解的地方可以总结成三个动作1️⃣ 写入权永远归 Hermes。OMH 可以建议改什么但真正的写文件动作只能由 Hermes 自己的记忆工具执行。OMH 全程旁观且只把结果报告为观察到的一次原生写入绝不允许它算作 OMH 自己的变更证据。2️⃣ 审核只产出建议不直接落地。当 Hermes 的记忆文件积累太多需要整理时可以用memory-sync工作流技能定义见 skills/omh-memory-sync/SKILL.md。它做的是逐条审查MEMORY.md、USER.md里的陈述 → 准备一份原生写入的差异diff→等你明确批准后才由 Hermes 亲手应用。文档 docs/MEMORY_CONTEXT.md 对此的表述非常干脆没有任何 OMH 界面会调用、应用或观察这次原生写入。3️⃣ 读也分边界。OMH 读取 Hermes 记忆文件仅限于整理计划这类明确场景读到的内容不会被当作 OMH 的已审核上下文。Hermes 原生记忆和外部记忆提供商的上下文在 OMH 体系里统一标记为not_omh_reviewed——没有经过 OMH 审核流程的东西自动获得不了任何准入资格也不能反过来继承 OMH 的批准。新事实进门要过三道关Remember / Refuse / Defer OMH 记忆不是来者不拒的笔记本。每条新事实进来时系统会先问清它的来源类别、目标存储、作用范围和保留类别然后给你一个明确决策Remember记住只创建一个有边界的持久候选必须等 OMH 本地审核批准、且目标写入被单独观察到之后才算真正生效。Refuse拒绝密钥、原始日志、对话转录、疑似提示注入的指令、临时任务进度——这些一律不入库。Defer推迟来源、作用范围或目标不确定的内容先送去审核而不是直接留存。Retrieve instead去检索过去对话里的历史留在 Hermes 自己的会话存储里按需通过原生会话搜索召回不必挤占记忆额度。配合保留期分级volatile 易失 1–7 天 / standard 标准 / durable 持久无过期每条记录都有自己的复审到期日和过期日到期自动失去影响力。相关实现分布在 src/workflows/memory.py、src/plugin_bundle/omh/memory_provider.py 等模块中。L1 与 L2记忆分层与降级机制 这是共存设计里最精巧的部分官方称之为记忆分层Memory TieringL1 层 Hermes 原生记忆文件小而精有字符上限每一轮对话都要为它付出上下文成本。L2 层 OMH 记录存储经过审核、有治理、不受 L1 字符上限约束。L1 装满时常规操作是删条目——事实就丢了。OMH 提供了另一个选择降级Demotion——把内容完整搬进 L2L1 里只留一行短引用[omh#sha12] 前60字符…。整个降级流程依然严格遵守边界OMH 负责计划挑出最值得下移的条目、生成引用行、把内容做成待审核候选和校验内容不完整、会被截断的条目直接拒绝降级绝不悄悄损坏数据而把 L1 原文替换成引用行这一步留给 Hermes 自己的记忆工具完成。L1 的半边永远归 HermesOMH 只读不能改。两套记忆如何各审各的memory-sync 工作流 当 Hermes 的MEMORY.md、USER.md或技能记忆积累到需要大扫除时memory-sync工作流就是那个工具。对新手来说记住它的三条铁律就够了它是提示词引导不是自动脚本——不跑命令、不自动触发一切以你批准为准。它只准备不执行——审查产出的是建议的差异不是写入动作。批准的差异由 Hermes 应用后报告口径是观察到的原生写入——Hermes 自己的行为永远不冒领成 OMH 的变更证据。新事实则不走这条路新东西一律走上一节说的 Remember / Refuse / Defer 候选流程技能定义见 skills/omh-memory-new/SKILL.md两套入口泾渭分明绝不混用。外部记忆提供商同样只围观 如果你还接了第三方记忆 provider向量库、托管记忆服务等OMH 的态度和对待 Hermes 原生记忆完全一致不导入不会把 provider 的记录搬进 OMH 审核流。不授权不授予任何MEMORY.md/USER.md的写入权限authorizes_native_memory_mutation恒为false。只记录观察OMH 会如实记录 provider 的同步状态完整 / 截断 / 跳过 / 失败让你能分清provider 收到了完整对话和只收到截断子集详见 docs/MEMORY-SYNC-FIDELITY.md。不夸大结论文档明确声明它不认证回执真伪、不证明无出网、不回答provider 能不能删除数据——这些保持unknown而不是编一个答案。这种能力边界内说满话边界外说不知道的诚实正是这套边界设计最打动人的地方。小结记住这四条就够 ✅两套记忆并存Hermes 原生记忆管每轮都要用的精华L1OMH 项目记忆管经审核、可追溯的上下文L2。写权唯一MEMORY.md/USER.md只能由 Hermes 自己的记忆工具写入OMH 只建议、不代笔。审核留痕OMH 记忆从候选到生效必须过审核外部上下文永远not_omh_reviewed。降级不丢数据L1 满了走降级流程内容完整下沉到 L2L1 只留引用行。想深入了解完整机制推荐阅读 docs/MEMORY.md项目记忆总览、docs/MEMORY_CONTEXT.md记忆上下文审核与 docs/MEMORY-PREFETCH.md记忆预取角色职责可参考 roles/memory-keeper.md。【免费下载链接】oh-my-hermesAll in one plugin for Hermes Agent ⚚ the coding intelligence, a long-term memory system and model optimized workflow packages项目地址: https://gitcode.com/GitHub_Trending/ohm/oh-my-hermes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考