Hermes × Obsidian 知识运营架构：从收件箱到审查队列，再到记忆与技能

Hermes 接入 Obsidian 后，真正需要设计的不是“让 Agent 看到更多笔记”，而是一套可持续的知识运营架构。Obsidian 的价值在于本地 Markdown、开放文件格式和用户自己拥有的数据；Hermes 的价值在于能在会话中使用工具、加载 Skills、维护持久 Memory，并通过 cron 在新会话里定时执行任务。把两者放在一起，最稳的做法不是把整个 vault 当作模型的长期记忆，而是把 vault 当成一个可读、可写、可审查、可回滚的知识作业系统。

这套系统的关键判断很简单：笔记不是记忆，摘要不是技能，自动化不是授权。Obsidian vault 可以保存原文、链接、会议纪要、调试记录、项目日志和反思；Hermes Memory 只适合保存短小、稳定、需要跨会话默认出现的事实；Hermes Skills 更适合保存经过验证的流程、命令、坑点和检查清单。三者职责不同，混在一起就会制造噪声：模型每次启动都背负过多无关信息，技能目录塞满一次性技巧，vault 里又看不出哪些内容已经被提炼、哪些仍然只是材料。

vault 分类要先服务运营，而不是先服务美观

Obsidian 的目录结构不必复杂，但必须让 Agent 能安全理解边界。一个适合 Hermes 协作的 vault，可以从七个顶层区域开始：00-Inbox 放未经处理的输入；10-Sources 放原始资料和外部链接；20-Projects 放项目上下文；30-Decisions 放已经确认的决策；40-Procedures 放候选流程；50-Review-Queue 放等待人审的晋升候选；90-Archive 放过期、冻结或仅需留档的材料。编号不是必须，但它能让文件浏览和自动扫描有稳定顺序。

目录命名的目的不是让笔记看起来像知识库，而是明确每个文件的运营状态。00-Inbox 里的内容默认不可信、不稳定、不应被写入 Memory；10-Sources 里的内容保留出处和原文，不承担结论职责；30-Decisions 里的内容必须能解释“谁确认、何时确认、适用范围是什么”；40-Procedures 里的内容只是技能候选，不等同于已经安装的 Hermes Skill。这样划分后，Agent 在处理笔记时不会把一个临时想法误当成长期偏好，也不会把一次故障排查误当成通用操作手册。

如果需要给 Hermes 一个默认入口，环境变量 OBSIDIAN_VAULT_PATH 是最清晰的边界；没有设置时，工作流可以回退到 ~/Documents/Obsidian Vault。这个约定应该写进每个相关提示词或 cron 任务里，因为 cron 会在新会话里运行，不能依赖上一次聊天里的口头上下文。路径、允许扫描的目录、禁止触碰的目录、输出位置和是否允许写入，都应该在任务说明中明确。

收件箱处理：先归档事实，再产生判断

收件箱的第一轮处理只做三件事：识别类型、补齐元数据、移动到下一站。比如一条网页摘录可能进入 10-Sources/Web，一段项目讨论可能进入 20-Projects/项目名/Logs，一条操作经验可能进入 40-Procedures/Candidates。这一步不急着总结成“最佳实践”，因为未经重复验证的材料很容易带有环境偶然性。

每条材料都应带最小来源信息：来源链接或文件路径、采集日期、采集人或触发方式、原始上下文、是否允许外传、是否包含敏感信息。对于 Hermes 参与生成或改写的内容，还应记录执行提示词摘要、涉及的文件、验证结果和失败边界。来源字段不是形式主义，它决定了后续能否追溯一条记忆为什么存在，也决定了技能失效时能不能回到原始证据重新判断。

一个安全的 inbox 任务可以要求 Hermes 只读扫描最近新增的 Markdown 文件，输出一份移动建议，而不是直接批量移动。建议格式可以包括目标目录、理由、是否敏感、是否需要人工确认、是否可能成为 Memory 或 Skill 候选。只有低风险、规则明确的内容才允许自动移动；涉及个人身份、客户数据、凭证、合同、医疗、财务或未经确认结论的材料，应该进入人工队列。

来源与可追溯性：每个结论都要能回到证据

知识运营系统最怕“结论脱离来源”。一条简短记忆如果只写“某项目使用某框架”，几周后很难判断它来自配置文件、会议讨论、历史部署，还是 Agent 自己的推断。更稳的写法是在 vault 中保留完整来源，在 Memory 中只保存必要事实，并在候选记录里保留指向来源文件的路径。Memory 负责短句，vault 负责证据链。

技能候选也一样。Hermes Skills 是按需加载的过程性记忆，适合保存可复用工作流，例如触发条件、步骤、命令、验证方式和常见坑点。它不应该从一条笔记直接生成。一个流程至少要经过一次真实执行，最好经过重复使用或人工确认，才值得进入技能目录。否则技能会变成未经验证的建议集合，下一次加载时反而增加风险。

来源记录还要区分三类事实：官方事实、用户环境事实和经验判断。官方事实可以来自 Hermes 文档或 Obsidian 官方页面，例如 Hermes 的 Skills、Memory、cron 机制，Obsidian 的本地 Markdown 与数据归属；用户环境事实来自本机路径、仓库结构、部署方式、团队约定；经验判断则来自多次执行后的归纳。三类事实写在一起时，必须标清来源层级，避免把本地经验包装成官方能力。

审查队列：让 Agent 提议，人来批准晋升

50-Review-Queue 是整套架构的控制阀。它接收三种候选：记忆候选、技能候选、归档候选。记忆候选回答“这个事实是否应该在未来会话默认出现”；技能候选回答“这个流程是否足够稳定，值得保存成 SKILL.md”；归档候选回答“这份材料是否已经完成运营生命周期，只需留档或删除”。

每个候选文件可以采用统一字段：候选类型、来源文件、提出原因、适用范围、风险等级、最后验证日期、验证证据、建议动作和人工决定。人工决定最好只允许几个状态：approved、rejected、needs-more-runs、archive-only。这样 cron 扫描时只需要处理状态，不需要重新理解整篇文章。

Hermes 本身已经支持对 Memory 写入和 Skill 写入设置审批门槛。对于重视治理的团队，vault 里的 Review Queue 和 Hermes 的写入审批可以互相配合：vault 负责沉淀候选和证据，Hermes 的审批机制负责阻止未审查内容直接进入长期上下文或技能库。两层门槛都不是为了降低效率，而是为了防止“模型觉得有用”直接变成“系统长期相信”。

保留策略：不是所有笔记都值得永久在线

Obsidian 很适合长期保存，但知识运营不能把“能保存”理解成“永远活跃”。收件箱内容如果 30 天仍无人处理，可以进入冷队列；项目日志在项目结束后可以冻结到 90-Archive；来源材料如果已有稳定结论和外部链接，可以只保留索引与关键摘录；含敏感信息的临时材料应有更短保留周期。具体天数取决于团队规则，关键是每类内容都要有默认去向。

保留策略也应影响 Agent 权限。活跃目录可以允许 Hermes 做摘要、整理和链接建议；归档目录默认只读；敏感目录默认不可访问；审查队列允许写入候选但不允许直接修改人工决定。文件系统权限、提示词约束和工具范围应该互相印证，而不是只靠一句“请小心”。

过期并不等于删除。很多调试记录、项目复盘和来源摘录不需要进入 Memory，也不需要变成 Skill，但仍然值得留在 vault 中等待检索。它们的价值是可追溯，而不是默认注入。把这类材料留在 Obsidian，用搜索或明确路径让 Agent 在需要时读取，比把它们塞进长期记忆更节省上下文，也更容易纠错。

cron 的角色：定期提出队列，而不是定期替人做决定

Hermes cron 可以按自然语言或 cron 表达式运行任务，并在新会话中执行。这个特性适合做知识运营巡检：每天扫描 inbox，列出未处理材料；每周检查 Review Queue，找出等待超过阈值的候选；每月列出可能过期的项目日志和候选技能。cron prompt 必须自包含，说明 vault 路径、扫描范围、输出文件、禁止动作和判断标准，因为定时任务没有上一轮聊天的上下文。

一个好的日常 cron 不应写成“整理我的整个 Obsidian 并更新你的记忆”。更安全的写法是：只读扫描 00-Inbox，为每个新增文件生成分类建议，把结果写入 50-Review-Queue/inbox-triage-日期.md，不要移动原文件，不要写 Memory，不要创建或修改 Skills。周任务可以进一步检查候选状态，但仍然只生成报告，等待人工批准。

当某条候选被多次验证并人工批准后，Hermes 才可以执行晋升动作。记忆晋升应该压缩成短句，避免来源全文进入系统提示；技能晋升应该生成结构化 SKILL.md，包括触发条件、步骤、验证、坑点和边界。晋升后，Review Queue 文件应记录目标 Memory 或 Skill 名称、日期和验证证据，避免未来重复晋升。

从笔记到 Memory：只保存默认需要的稳定事实

Memory 的位置很高，因为它会在会话开始时进入系统提示。适合放进去的内容通常很短：用户偏好、常用项目路径、稳定环境约定、反复确认的工作方式。它不适合保存长代码块、一次性日志、大段资料、未经确认的推论或会过期的待办。Memory 越满，越需要合并和删减；否则长期上下文会变成噪声仓库。

从 Obsidian 晋升到 Memory 时，可以用四个问题过滤：未来三个月是否仍然成立；是否会影响多数相关会话；是否已经有人确认或多次验证；是否能用一句话表达。如果答案不清楚，就留在 vault 或 Review Queue。很多内容只需要“可检索”，不需要“默认记住”。

从笔记到 Skill：只保存可重复执行的流程

Skill 的门槛应该比 Memory 更高。一个技能不是一段经验摘抄，而是一套未来可执行的程序性知识。它应该说明何时加载、适用系统、必要命令、输入输出、失败处理和验证方式。一次成功不等于技能成立；一次失败后的修正也不一定值得沉淀。只有当某个流程跨会话重复出现，或者一次任务复杂到足以复用，才值得从 Obsidian 候选变成 Hermes Skill。

这也是 Obsidian 的优势所在。候选流程可以先在 40-Procedures 里自然生长，保留草稿、运行记录、错误案例和人工批注。等它稳定后，再把精炼版本写入技能目录。vault 保存演化过程，Skill 保存可执行版本。两者同时存在，但不要互相替代。

一套可落地的最小制度

最小可行制度不需要复杂平台：一个明确的 vault 路径，一组运营目录，一个 inbox 扫描提示词，一个 review queue 模板，一个只读巡检 cron，一个人工批准规则。第一周只让 Hermes 做建议，不做晋升；第二周开始允许它根据批准状态生成 Memory 或 Skill 草稿；第三周再考虑开放小范围自动移动。每一步都要有文件证据和回滚路径。

这样使用 Hermes 与 Obsidian，知识不会被神秘地“吸进 AI”，也不会散落在无人整理的 Markdown 里。Obsidian 负责保存可追溯的材料和人的判断，Hermes 负责扫描、归类、提炼候选、执行经过批准的晋升。长期价值来自这条审查队列：它让知识从输入到保留、从保留到记忆、从经验到技能，每一步都有边界、有来源、有责任人。