Obsidian 里的笔记越积越多以后，最需要帮助的往往是一些具体小事：把今天的零散记录整理成待办，给项目笔记补上来源链接，或找出上周尚未解决的问题。让 Hermes 处理这些工作，先要确认它读写的是哪个文件夹，以及你能否看清每次修改。
本文按 2026 年 9 月 23 日 Hermes 官方 Obsidian 工作流与调度文档说明做法。实际连接时间取决于安装、模型和文件权限，不承诺几分钟完成。下面使用测试库设计流程，没有读取私人笔记，也没有创建真实定时任务。官方 Obsidian 工作流
准备一个只有几份样本的库
先建独立测试库，放入一份项目进展、一份带链接的参考笔记和一份待办。内容可以虚构，但结构尽量接近日常使用，例如标题、列表、附件路径和双向链接。
再建立输入与输出两个目录。第一轮只让 Hermes 读取输入，在输出目录新增整理结果，不移动原笔记、不批量改名。这样出现问题时，容易判断它究竟改了什么。
单独测试库还有一个好处：你可以故意放入同名笔记、失效链接和不完整日期，观察助手会不会询问或保留未知，而不是替你补成确定事实。
提示词里的目录约定能表达意图，但不是操作系统权限控制。若需要真正限制访问范围，应在运行账号、容器挂载或文件权限层落实。不要把 private 标签当作程序无法读取该文件的证明。
路径先解析成完整地址
官方工作流采用文件系统方式处理笔记，约定使用 OBSIDIAN_VAULT_PATH，未设置时有默认候选路径。首次连接时应确认实际路径，不要让助手在找不到指定目录后随意搜索其他笔记库。
尤其要注意，文件工具未必像 shell 一样展开环境变量。把 $OBSIDIAN_VAULT_PATH/笔记.md 原样传给文件读取工具，可能找不到文件。应先取得变量值，再使用具体绝对路径。
可以向 Hermes 提出这样的只读检查请求，把示例路径替换成自己的测试库：
请使用 /Users/example/Notes/Hermes-Test 这个测试库。
先确认该目录存在，只列出 Input 中的 Markdown 文件名。
不要读取其他目录，不要写文件；路径不存在就报告问题。
请在结果中给出实际使用的绝对路径。
检查结果应与文件管理器中看到的一致。若不同，先排查运行位置、路径拼写和权限。远程服务器上的 Hermes 不会因为你电脑里安装了 Obsidian，就自动访问电脑上的库。
第一次写入只创建一个新文件
只读检查成功后，让 Hermes 在输出目录创建一份连接记录，写明本次输入目录与处理范围。打开 Obsidian，确认文件出现在预期位置，中文和链接显示正常。
然后让它读取一份虚构项目笔记，生成摘要与待办。要求保留来源文件链接，区分笔记已经明确的事项和仍需确认的问题。不要同时要求重命名、重新分类和创建长期记忆，否则很难定位失败原因。
检查时可以故意保留一句“下周再讨论上线时间”。合格的整理应把它作为待确认事项，不能变成一个具体上线日期。待办也应保留负责人是否已知，不能因为表格需要填满就编出人名。
如果原笔记在处理中被人工修改，输出应说明采用了哪个版本。之后再考虑覆盖或合并现有笔记，至少需要先读取当前内容，避免用旧摘要覆盖刚写的新信息。
一份日常整理结果应该长什么样
可以让结果包含三个自然部分：今天新增了什么、有哪些待办、哪些问题需要人确认。每条尽量链接回原笔记，必要时附上短摘录或标题位置。
例如项目笔记写“供应商还没确认交付日”，整理结果就应保留这个状态，并提出下一步跟进。若另一份笔记写“预计周五交付”，应指出两处信息不一致，而不是选择看起来更新的一句。
不要一开始就为所有笔记设计复杂分类。先观察一周中最常重复的整理动作，再决定是否增加属性。一个没有人维护的十几个字段模板，很快就会变成模型猜测的来源。
需要使用 frontmatter 时，字段值写成实际值，不要把 active | archived 这样的说明原样保存进去。它表示可选项，不能同时作为一份笔记的真实状态。写入后在 Obsidian 中检查属性类型与显示结果。
笔记、长期记忆与技能分别保存什么
笔记库可以容纳项目材料、来源摘录和历史记录；Hermes 的持久记忆用于跨会话延续少量信息；技能用于复用操作流程。把每份新笔记都复制进后两者，会增加过时信息与重复内容。持久记忆说明
一条经常使用的报告格式，可以作为记忆候选；本周某项目的临时排期，更适合留在项目笔记里。一个已经多次验证的发布流程，可以整理为技能；一次还在试错的操作记录，先保留为普通笔记。
自动整理可以提出候选，并写出来源与理由。是否进入跨会话记忆，应结合稳定性、使用频率与敏感程度确认。对即将过期的结论，记录复查时间，避免后来每次对话都沿用旧状态。
云端模型读取笔记时，相关文本可能发送给模型服务。本地保存 Markdown 并不自动意味着整个处理过程都离线。对于不能外发的材料，应先选择符合要求的运行方式与模型，再决定哪些目录参与处理。
手动流程稳定后再加入定时任务
先重复几次手动整理，确认输出可用、没有遗漏来源，也没有改动输入文件，再考虑自动运行。定时任务需要携带完整路径、允许范围和输出要求，不能依赖上次聊天中没有保存的约定。
Hermes 当前调度文档提供聊天与 CLI 等入口，也支持在新会话中执行任务。创建时要同时定义计划和任务内容，并核对工作目录、模型配置及结果保存位置。定时任务说明
与其直接照抄一条缺少任务正文的命令，可以先让 Hermes生成待创建的任务说明，自己核对时区和下一次运行时间。确认以后再建立任务，手动触发一次，查看真实输出与执行记录。
调度进程的环境可能与交互终端不同。终端里临时导出的变量，后台服务未必能读到。若手动成功而定时失败，应检查运行账号、配置位置和实际目录，不要通过扩大为全盘搜索来掩盖路径问题。
扫描范围与重复运行要事先安排
只按“过去二十四小时修改”筛选，可能漏掉停机期间的笔记，也可能反复处理同步工具触碰过的文件。更稳妥的方式是记录上次成功位置，并结合文件内容变化判断是否需要重新整理。
同一天的任务可能因重试执行两次。输出文件名和写入方式应能区分更新与追加，避免每次运行都复制一遍相同待办。若采用固定日报文件，修改前先读取已有内容，保留人工补充部分。
输入中出现无法读取的文件时，在结果里列出具体缺项。不要把失败当成“今天没有新内容”，更不要在缺少来源的情况下照常生成一篇看似完整的日报。
机器休眠、模型额度或同步延迟都可能影响执行。开始阶段查看几次运行记录，确认失败能被发现、恢复后能继续，再逐步降低人工检查频率。
如果你同时在手机和电脑编辑，最好先等同步完成再让任务读取，处理结束后再检查是否产生冲突文件。不要让整理任务自动选一个冲突版本覆盖另一个。先保留两份，比较实际改动，确认哪些是人工新内容，哪些是自动生成内容，再合并到目标笔记。
恢复能力要在出错之前试一次
同步和备份用途不同：同步可能把误删也传播到其他设备。Obsidian 官方建议保留备份；采用任何自动修改前，先确认自己能从历史版本或独立备份恢复一份笔记。Obsidian 备份说明
可以在测试库里修改一个样本，再恢复它，检查正文、附件和链接是否一起回来。用 Git 的话，确认实际跟踪了哪些文件；.gitignore 只影响 Git，不会阻止 Agent 读取对应目录，也不会自动清除已经提交的内容。
发生误写时，先暂停相关定时任务，保留当前差异，再按受影响文件恢复。不要直接用旧的整个库覆盖回来，否则可能丢掉期间人工新写的笔记。
等测试库里的读取、整理、定时执行和恢复都走通，再把一小部分真实资料纳入。每天能少做几项重复整理，同时仍知道内容从哪里来、文件改了什么，这样的连接才有持续使用的价值。