oh-my-hermes 配置文件地图：10分钟速通 ~/.omh 目录核心文件完全指南

oh-my-hermes 配置文件地图：10分钟速通 ~/.omh 目录核心文件完全指南

【免费下载链接】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

如果你正在使用oh-my-hermes（Hermes Agent 的 All in one 插件），大概率会好奇：它到底把哪些配置文件、模型路由、长期记忆数据写到了哪里？答案是——几乎全部集中在家目录下的~/.omh文件夹里。本文作为oh-my-hermes 配置文件地图，带你 10 分钟速通~/.omh目录下的核心文件：每个文件管什么、什么时候被写入、出问题时去哪里排查。无需修改任何一行代码，读懂这份地图即可。

一、~/.omh 是什么：oh-my-hermes 的"总控台"

omh setup执行时会在用户主目录下创建~/.omh（Windows 上为C:\Users\<你>\.omh），它是 oh-my-hermes 的本地状态库，与 Hermes 自身的~/.hermes是两个相互独立的存储。

简单理解它的定位：

• 📁配置类文件：你手动或交互式回答写入的偏好（模型链、供应商、价格）
• 🧠记忆类文件：oh-my-hermes 的长期记忆系统存储
• 📊运行时文件：每次工作流执行的运行记录与日志
• 🛠️技能文件：由安装器生成并注册给 Hermes 的技能包

💡 定位规则详见 docs/INSTALLATION.md，默认用户级作用域写入~/.omh；若运行omh setup --scope project，则写入项目根目录的.omh/，实现按仓库隔离。

二、~/.omh 目录结构速览

三、routing/：模型路由配置全集

~/.omh/routing/是绝大多数用户最常打交道的目录，它决定了 oh-my-hermes给哪类任务挑哪个模型。这里有 7 个"兄弟文件"，各司其职：

1️⃣ model-chains.json：按工作类别配置模型链

安装后自动播种categories为空对象，表示沿用内置默认模型链。你一旦写入某类别（如deep、architect），就会整链替换该类别的模型，直到你手动删除。

{"schema_version": "mixture_chain_overrides/v1", "categories": {}}

推荐用命令而非手改文件：omh model-chains show查看现状、omh model-chains interview交互式问答、omh model-chains set <category> "model[:effort], ..."脚本化写入。文件无效时会被整体忽略并回退默认值，由omh doctor提示修复。

2️⃣ providers.json 与 model-providers.json：让模型"走通"供应商

• providers.json（provider_entitlements/v1）：记录你的机器上拥有哪些供应商和订阅。OMH 只存 provider ID，从不存密钥或 token。它会让模型链重排——你已绑定的供应商能提供的模型排到最前。
• model-providers.json（model_provider_routes/v1）：当 alias 需要供应商专用的 wire ID（如vendor/model-name）时，做一次映射即可：

{"models": {"glm-5.2": {"provider": "my-gateway", "model": "z-ai/glm-5.2"}}}

3️⃣ 其他高频配角文件

完整 schema 与优先级顺序见 docs/FANOUT.md 与 docs/WORKFLOWS.md，路由逻辑源码位于 src/coding/model_routing.py。

四、memory/：长期记忆系统的"家"

oh-my-hermes 的 long-term memory system 全部落在~/.omh/memory/下（项目级则落在仓库内.omh/memory/），核心子结构：

• records/—— 已审核的记忆记录，召回时才会进入编码交接
• archive/—— 过期记录归档区（omh memory retire --apply会移到这里）
• pins.json/attention.jsonl—— 固定记忆与注意力观察
• usage.json—— 记忆召回使用统计
• domain-intelligence/—— 领域智能存储

⚠️ 记忆写入默认遵循review-first安全策略：只能捕获候选，必须审核通过后才参与召回，且 oh-my-hermes 不会读写 Hermes 的全局记忆。策略在~/.omh/setup-profile.json中记录，详见 docs/MEMORY.md。

五、runtime/：运行日志与状态文件

~/.omh/runtime/只记录运行时元数据，是排查问题的第一现场：

• state.json—— setup/install/apply/doctor 的摘要
• runs/<run-id>/run.json+events.jsonl—— 每次工作流执行的运行信封与事件流
• journal/events.jsonl—— 只追加的生命周期观察日志
• wrapper_sessions/<session-id>/—— 包装器聊天会话
• update-check.json—— 更新检查结果

需要给支持团队发日志时，用omh runtime export --redacted导出脱敏包（自动抹去 prompt、密钥等敏感字段）。

六、skills/ 与其余工作流目录

• 📦~/.omh/skills/：安装器生成的托管技能目录，通过skills.external_dirs注册进 Hermes。omh apply会确保该目录在技能发现列表里；卸载时会连同~/.omh一并移除。
• 🎯~/.omh/goals/：目标台账（metadata-only 的goal_ledger/v1），断线续作时先查这里恢复检查点。
• 💻~/.omh/coding/fanout/<id>/：fanout 并行委派的dispatch_summary.json、run_journal.json、recovery/等运行证据，schema 见 docs/FANOUT.md。
• 📄~/.omh/plans/与~/.omh/learning/skill-drafts/：文档计划、技能草稿——草稿只是待审核材料，不会被自动安装成技能。
• 📐~/.omh/codegraph/codegraph.json：代码图谱索引，仅在观察到omh codegraph build --write成功写入后才应被引用。

七、快速定位与体检你的 ~/.omh

几个新手常踩的坑：

1. 找错位置：WSL 与原生 Windows 是两个独立文件系统，HOME环境变量在原生 Windows 上不生效，需用OMH_HOME显式覆盖。
2. 项目级与用户级混用：项目作用域写的是仓库内.omh/，不是~/.omh，两者互不迁移。
3. 手改 JSON 后没生效：routing 下所有文档都是"严格且原子"校验的——一个文件无效会被整体忽略，用omh doctor看具体报错。

八、总结

~/.omh就是 oh-my-hermes 的"黑匣子 + 控制台"：routing/管模型怎么挑，memory/管记忆怎么存，runtime/管过程怎么查，skills/管能力怎么装。记住这份配置文件地图，配合omh doctor一条命令，你的排查效率会直接起飞 🚀。更多细节可查阅 docs/INSTALLATION.md 的 "What Gets Recorded" 章节。

【免费下载链接】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