项目简介
Oh My Hermes 是面向 Hermes Agent 编程助手的一体化增强层，集成长期项目记忆、模型优化的工作流包与原技能。它将请求转化为清晰的能力与可验证的证据边界，并通过 omh 命令完成安装配置、更新、模型选择与诊断，强化而非替代原有工作流。
README 预览
\n \n\n\n# oh-my-hermes\n\n\n English |\n 한국어 |\n 日本語 |\n 中文\n\n\n\n \n \n \n \n\n\n\n \n\n\n\n Install once. Keep Hermes. Add a stronger operating layer.\n \n Planning, research, creation, coding handoffs, operations, and project memory with explicit evidence boundaries.\n\n\n\n \n\n\n\n oh-my-hermes (OMH) turns a normal\n Hermes Agent\n request into a clear capability, a useful next step, and an honest record\n of what actually happened — strengthening the workflow you already use,\n never replacing Hermes or hiding a coding executor behind it.\n \n OMH is the operating layer above Hermes-native skills: it frames the\n problem, picks the workflow and evidence gates, and runs native skills\n as capabilities inside that governed path.\n\n\n[Website](https://rlaope.github.io/oh-my-hermes/) ·\n[Documentation](docs/README.md) ·\n[Installation](docs/INSTALLATION.md) ·\n[Capabilities](docs/CAPABILITIES.md) ·\n[Capability Impact](docs/CAPABILITY_IMPACT.md) ·\n[Agent Install](INSTALL_FOR_AGENTS.md) ·\n[GitHub Pages site](site/index.html)\n\n> [!NOTE]\n> OMH keeps Hermes as the natural-language surface and adds a professional\n> operating layer with explicit evidence boundaries.\n>\n> \n> \n> \n\n> [!TIP]\n> Be with us!\n>\n> \n> \n> \n> Updates for oh-my-hermes are shared on @rlaope on X, alongside release notes and project news.\n> \n> \n> \n> Follow @rlaope on GitHub for more projects, releases, and ongoing work.\n> \n> \n> \n> Join the Oh-My-Hermes Community on Discord to ask questions, share workflows, and talk with other users.\n> \n> \n> \n> Built with AI agents Friren and Killua, collaborators helping ship oh-my-hermes.\n> \n> \n> \n> Thank you to Nous Research for creating Hermes Agent.\n> \n> \n\n\n\n## Quick Start\n\n**macOS / Linux:**\n\n```sh\ncurl -fsSL https://raw.githubusercontent.com/rlaope/oh-my-hermes/main/install.sh | sh\n```\n\n**Windows (PowerShell 5.1+):**\n\n```power
常见问题 (5)
故障排除在 Windows 上运行 omh update 时，如何修复 "Creating a junction requires an absolute path for the target" 错误？
当 PATH 中的 powershell.exe 解析为 PowerShell 7 而不是 Windows PowerShell 5.1 时，就会发生这种情况。OMH 的更新程序将相对路径作为 junction 目标传递，PowerShell 7 会拒绝该相对路径（5.1 可以容忍），因此新的 generation 虽然构建成功，但永远不会激活。
**永久修复：** 升级到包含 PR #2218 的版本（合并提交 d0df9331a8156b611e3a6bee94465a5b18db45f8），该提交使 junction 创建使用绝对目标路径，可同时兼容 PowerShell 7 和 5.1。
**旧版本（例如 4.0.0）的临时解决方法：** 仅在执行更新时，临时将 Windows PowerShell 5.1 放在 PATH 的最前面：
set PATH=C:\Windows\System32\WindowsPowerShell\v1.0;%PATH%
omh update然后使用
omh doctor 进行验证。无需 cmd 回退或绕过策略。故障排除为什么 OMH 记忆记录不会注入到 Slack/Telegram/Discord 的 DM 对话中？
原因：OmhMemoryProvider.initialize() 通过 self._shared_surface = bool(kwargs.get("shared_surface", bool(platform and platform != "cli"))) 将每个非 CLI 平台都视为共享会话面。在没有 principal_context 的共享会话面上，个人记录和遗留记录会被排除（按 #1485 实行 fail-closed），因此即使存储中保存有已批准的记录，1:1 私聊（DM）轮次也永远不会收到已审查的记录。修复/变通方法：修补该 provider，使其在未显式传入 shared_surface 关键字参数时，将 chat_type == "dm" 视为非共享：
self._shared_surface = bool(kwargs.get(
"shared_surface",
bool(platform and platform != "cli" and kwargs.get("chat_type") != "dm"),
))群组频道和未知聊天类型仍保持共享并继续 fail-closed。如果修补的是受管理的 bundle，请在每次 omh update 之前恢复上游原始文本，并在 omh doctor 通过后重新应用补丁。
故障排除为什么在 OMH 中，Hermes delegate_task 子系统提示词缺少模型家族校准块？
这是 OMH 4.0.0 中的一个 bug：PR #2178 为原生子任务添加了 omh.delegation-protocol 部分，但从未包含校准表，而渲染该校准表的模块（coding/unit_prompt_assembly.py）仅被 coding fanout 路径使用，原生 delegate_task 并未使用它。此问题已由 PR #2215（提交 8981d6967cec156b2e675fc663a4580f972b98e6）修复——请将 OMH 升级到包含该合并的构建版本。修复后，每个原生 delegate_task 子任务都会获得一个独立的 omh.child-calibration 系统提示部分，校准将按以下顺序从子任务自身的模型解析：精确覆盖 → 模型系列 → 通用。行为说明：原生子任务在所有 effort 级别下都会收到校准（Hermes 部分元数据无法可靠地暴露 reasoning_effort），而 omh coding fanout 路径通过 calibration_entry_for_route 保留其现有的 high/xhigh/max effort 门槛。omh.delegation-protocol 部分的文本保持不变。
故障排除为什么 Hermes 的 delegate_task 子任务没有收到 OMH 委托协议，以及如何修复这个问题？
这是 OMH 4.0.0 中的一个 bug：插件的 pre_tool_call 钩子（hooks/tool_hooks.py:128）只会为 delegate_task 添加未知角色警告并返回 None——它从不注入 coding-handling 框架要求在每个委托提示中包含的委托协议（goal 回显、带编号的完成标准、验证环节）。OMH 只在其自行组装的单元提示中嵌入该协议（omh/coding/unit_prompt_assembly.py），因此 Hermes 原生的 delegate_task 派生调用只有在父模型手动粘贴该协议时才能获得它。变通方法（已确认有效）：创建一个本地 Hermes 插件，注册一个系统提示段落，其文本由 omh coding composition-guide --json 的输出构建。Hermes 主机会将插件的系统提示段落带入 delegate_task 子会话，因此每个派生的子会话都会自动获得该协议。通过检查子会话存储的系统提示进行验证——其中应包含协议行，并且子会话的第一条用户消息应与派发的 goal 逐字节一致。
故障排除如何在使用共享 ~/.omh 的多路复用 profiles 时，阻止 OMH memory consolidation (dreaming) brief 在每一轮出现？
这是 OMH 3.0.2 中的一个已知 bug：该插件是一个单例，会将所有 profile 绑定到共享的 ~/.omh 存储，因此 memory/dreaming.json 和 memory/consolidation.json 是全局的。当某个 profile 触发 headroom_below_floor 时，会写入一份简报，随后 render_pack() 会将其注入到所有 profile 的每一个回合中，而 turn-interval/compaction 计数器也是按整个主机范围统计的。目前还没有受支持的设置可以禁用 dreaming（DREAMING_MODES 虽已存在，但 consolidation_reasons() 始终使用默认值调用）。临时解决方案：编辑 memory_dreaming.py，设置 DEFAULT_DREAMING_MODE = "off"，并在 read_latest_consolidation() 中强制 due = False。由于这会修改受管理的文件，因此在运行 omh update 之前必须先恢复上游原始文本，再运行 omh doctor 以通过 plugin_manifest/plugin_bundle_current 检查，然后重新应用该补丁。正式的修复方案正在进行中（通过 profile_slot(hermes_home) 哈希按 profile 对 dreaming 状态做命名空间隔离，正如 memory_session_lens.py 和 todo_store.py 已经实现的那样）。