最近 Grok Bot 很火，我也和 GPT Astra 来回聊了好几次，要不要换过去。它给我的建议一直很明确：按我现在的需求，继续用 Hermes 更合适。

正好借这个机会，把我正在用的这套工作流整理出来，分享给大家。

之前我用 Obsidian 管理自己的知识库，文章、笔记、项目资料和协作规则等都放在里面。

接入 Hermes 后，用的还是这套知识库。原来积累的文件继续保留，电脑上的 Codex、Claude Code，以及服务器上的 Hermes，都会围绕这些资料工作。

Obsidian 的库本来就是一个本地文件夹，笔记主要以 Markdown 保存。Agent 只要能访问文件，就可以读取里面的文章、找到项目上下文，把整理结果写回去。

接下来要解决的是同步：电脑上刚更新的资料，怎样让服务器上的 Hermes 读到？Hermes 做完的结果，怎样回到电脑，让下一次工作接着往下走？

我用 Git 管这套知识库的版本和多端同步，用文件记录任务的背景、进度和结果。这篇就从已有 Obsidian 库出发，接上 Hermes，再走完一次“读取旧资料→完成任务→写回原库→电脑接手”。

原来的 Obsidian 库，怎样接着用

原来的目录结构可以继续使用。文章还在原始资料目录，整理后的知识还在知识页里，项目的进度继续写进对应项目。

Obsidian 负责浏览和编辑这些文件；Agent 可以直接在文件层工作。服务器不必为了读 Markdown 再打开一个 Obsidian 窗口。用户日常也可以直接与 Agent 对话，不需要先打开 Obsidian 才能发起任务。

这套接法先覆盖 Markdown 正文和明确保存的附件。插件数据库、Dataview 动态查询和其他依赖插件运行的内容，要另外确认 Agent 能否读懂，不能把复制文件等同于完整复现 Obsidian 界面里的所有效果。

已有笔记提供背景，项目文件记录进度，Agent 完成任务后继续把结果沉淀回这套库。

先说清楚，究竟同步什么

Git 在这里负责传递文件和记录修改历史。

同步的内容是：你选择纳入 Git 的已有笔记、项目目标、当前进度、已经做出的决定、执行结果，以及 Agent 应当遵守的协作规则。

模型的内部上下文、还没写进文件的聊天内容，不会跟着一次 git push 自动出现在另一端。你在电脑上聊了半小时，最后没有留下记录，服务器上的 Hermes 就缺少这半小时的信息。

这套方案能否接上工作，取决于上一位有没有留下足够的记录，下一位有没有真的读。

我这套库的多端关系可以这样看：

text

1
2
3
4
5
6
7
8
9
电脑上原来的 Obsidian 知识库
  ↕ Codex / Claude Code 读取资料、更新项目状态
Git 私有远端
  ↓ 同一套知识库同步到服务器
Hermes 在知识库的独立任务目录里工作
  ↓ 提交结果，交给人审阅
合并回主线
  ↓ 同步回电脑上的原库
下一位 Agent 接手；Obsidian 也能查看更新后的 Markdown

下面只在现有库里增加一个演示项目。仓库名和任务名使用占位示例；你的原有目录可以保留。我的日常系统把部分操作封装成了脚本，这里展开基础命令，方便看清每一步发生了什么。

1. 找到现有库，确认 Git 同步状态

前提是你已经能使用 Hermes，并且它能读取、修改你指定的目录。电脑和服务器都需要安装 Git，配置好提交身份，以及访问同一个私有仓库的权限。

这篇从已有知识库接入开始。模型接入、Hermes 安装和聊天入口配置，需要先在你的环境里完成。

先找到你在 Obsidian 中使用的库文件夹，也就是包含笔记目录、通常还有 .obsidian 配置目录的那个位置。

以下终端命令使用 Bash；Windows 可以用 Git Bash。尖括号中的路径和仓库占位符都要换成你自己的值，命令逐条执行，上一条失败就停止。

1
2
cd "<你的 Obsidian 库根目录>"
git status

如果这套库已经通过 Git 同步，继续使用已有仓库和远端。 先确认工作区干净、分支和远端无误，再按原来的流程同步。不要重复初始化或覆盖已有远端。下面的命令假设主分支叫 main，远端叫 origin。

如果确认这个文件夹及其父目录都尚未纳入 Git，先备份原库，再在 GitHub 创建一个空的私有仓库，不初始化 README。在本地库根目录执行：

1
2
git init -b main
git remote add origin git@github.com:YOUR_NAME/YOUR_VAULT_REPO.git

完成两端的 SSH 鉴权后，再准备首次提交。已有库中哪些笔记可以上传、哪些允许服务器和模型读取，需要先选清楚。私有仓库控制访问权限，调用模型处理资料仍遵循你自己的隐私边界。

以我原来的知识库分层为例，只加一个演示项目就够了：

text

1
2
3
4
5
6
7
8
9
10
原来的 Obsidian 库/
├── .obsidian/              # 本机配置，按需决定是否同步
├── AGENTS.md
├── .gitignore
├── 10_项目/
│   └── demo/
│       ├── context.md
│       └── ledger.md
├── 50_知识库/              # 已有知识页
└── 60_原始资料/            # 已有文章等原始材料

你的文件夹名字不同，直接沿用原名，把后文的路径对应改掉。

context.md 记录“现在是什么情况”，ledger.md 记录“做过什么”。把当前状态和历史经过分开，接手的人就不用在几十条执行记录里猜哪一条还有效。

2. 写下交接规则

在原来的 AGENTS.md 中补上交接约定。已有规则继续保留；没有这个文件时，再创建下面的最小版本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# 协作规则

开始任务前：
- 确认本次工作目录和 Git 分支。
- 读取 10_项目/demo/context.md 和 ledger.md。
- 用几句话复述目标、已完成事项、下一步。
- 信息冲突时标出冲突，不自行猜测。

完成任务后：
- 把产物保存到指定目录。
- 更新 context.md 中的当前状态和下一步。
- 在 ledger.md 追加本次动作、产物路径、验证结果和遗留问题。
- 区分已经完成、尚未验证和准备去做的事。

修改边界：
- 只修改本次任务明确允许的文件。
- 不把密钥、Cookie、登录态和数据库放进仓库。
- 同一时间只有一端修改本项目，交接后上一端停止写入。
- 遇到 Git 冲突或推送被拒绝时停止，保留现场。
- Git 提交、推送、合并按本次明确授权执行。

不同 Agent 对规则文件的自动发现方式可能不同。第一次接入，直接在任务消息里要求它读取这个文件，并复述要点。这些约定也需要结合实际修改检查，写进提示词本身不能保证每次都执行到位。

接着写演示项目的 context.md。选择库里一篇可以交给 Agent 处理的已有笔记，把它的仓库相对路径填进“资料入口”，例如 50_知识库/某篇公开笔记.md：

markdown

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# 教程笔记整理

## 目标
把资料入口中的已有笔记整理成一份新手清单，保存为 checklist.md。

## 资料入口
<填入现有笔记的仓库相对路径>

## 阅读边界
只读取本次指定的笔记及交接文件，保留原文不改。
如果笔记依赖尚未提供的附件或链接，标出缺失资料。

## 当前状态
任务说明已建立，清单尚未生成。

## 下一步
读取指定笔记，根据原文生成不超过 8 项的清单。

## 验收
每项都有具体动作和对应的原文小节依据，不补造工具功能。

ledger.md 先写一个标题 # 执行记录 即可。

检查原来的 .gitignore，按需追加排除项，保留已有配置。首次接入时可以先排除整个 .obsidian/，让各端保留自己的插件和界面设置：

1
2
3
4
5
6
7
8
9
10
.obsidian/
.env
.env.*
!.env.example
secrets/
runtime/
*.db
*.sqlite*
node_modules/
.venv/

这是基础排除清单，提交前仍要检查具体文件。已有仓库若已跟踪 .obsidian/，新增忽略规则不会停止跟踪；是否调整其同步范围需要另行处理。.gitignore 同样不会清除已经进入 Git 历史的敏感内容。

文件准备好，在电脑上检查并提交。除交接文件外，要确认指定笔记及必要附件也已经提交到远端；首次接入的库只逐项加入本次需要且允许同步的资料：

1
2
3
4
5
6
7
8
git status --short
git add AGENTS.md .gitignore 10_项目/demo/context.md 10_项目/demo/ledger.md
# 首次接入时，逐项加入选定的已有笔记及必要附件：
git add -- "<已选定的笔记相对路径>"
git diff --cached
git diff --cached --check
git commit -m "docs: add demo handoff context"
git push -u origin main

这次提交完成后，先暂停电脑上对这个项目的修改，把工作交给服务器。

3. 给 Hermes 一个独立的任务目录

服务器上克隆同一个仓库：

1
2
3
git clone git@github.com:YOUR_NAME/YOUR_VAULT_REPO.git my-vault
cd my-vault
git status --short

git status --short 应当没有输出。后续再次接手时，也先确认这里干净、当前分支是 main，再执行：

1
2
3
4
5
6
git fetch origin
git merge --ff-only origin/main
git worktree add -b agent/demo-01 ../my-vault-demo-01 origin/main
cd ../my-vault-demo-01
pwd
git branch --show-current

Worktree 会创建另一个工作目录，并检出任务分支。Hermes 在新目录里修改文件，服务器原来的主线目录可以保持干净。

记下 pwd 输出的绝对路径。给 Hermes 发下面这段任务，把路径占位符换成刚才的结果：

text

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
本次工作目录是：<刚才 pwd 输出的绝对路径>
预期分支是：agent/demo-01

请先核对目录和分支，读取该目录下的 AGENTS.md、
10_项目/demo/context.md 和 10_项目/demo/ledger.md，
复述目标、当前状态和下一步，再执行任务。

仅允许修改：
- 10_项目/demo/checklist.md
- 10_项目/demo/context.md
- 10_项目/demo/ledger.md

读取 context.md 指定的已有笔记，根据原文生成清单，
逐项检查验收要求。保留原笔记不改；资料不存在或内容
不足时先报告，不要凭空补全，也不扩大读取范围。
完成后更新当前状态，并追加本次执行记录。
最后报告产物路径、验证结果和尚未完成的事项。
本次先不执行 Git 提交、推送和合并。

第一次做，明确写出目录，比一句“去知识库里处理一下”更容易核对。

如果 Hermes 无法访问这个目录，先处理它的目录权限或运行环境，确认能读取文件后再继续。

4. 把结果带回电脑

Hermes 完成后，回到服务器的任务目录，查看变化：

1
2
3
git status --short
git diff
cat 10_项目/demo/checklist.md

新建但尚未暂存的文件不会出现在普通 git diff 里，所以清单要单独打开看。确认修改范围和内容后，再暂存这三个文件：

1
2
3
4
5
git add 10_项目/demo/checklist.md 10_项目/demo/context.md 10_项目/demo/ledger.md
git diff --cached
git diff --cached --check
git commit -m "docs: complete demo checklist and handoff"
git push -u origin agent/demo-01

然后在 GitHub 为 agent/demo-01 向 main 创建 Pull Request，也就是一次合并申请。

审阅时重点看两件事：清单是否符合要求，交接记录是否如实反映结果。比如，“文件已生成”和“已经人工确认可用”就应该分开写。生成了一份文件，不代表里面每句话都对。

确认后合并 PR；这个演示可以选择 Squash and merge，把本次任务收成一个主线提交。

回到电脑上原来的 Obsidian 库根目录。确认当前为 main、工作区干净，再同步：

1
2
3
4
git branch --show-current
git status --short
git fetch origin
git merge --ff-only origin/main

现在打开一个新的本地 Agent 会话，发给它：

text

1
2
3
4
5
请读取本仓库 AGENTS.md，以及 10_项目/demo/ 下的
context.md、ledger.md 和 checklist.md。

先说明上一个工作端完成了什么、依据在哪里，
还有什么尚未验证，再给出下一步建议。暂时不要修改文件。

它能根据文件正确说清这些事，这次交接才算接上了。

这里没有复制 Hermes 的整段聊天记录。带回来的东西是一份产物、一份更新后的项目状态，以及能追溯的执行记录。

我实际踩过的坑

我曾遇到过自动化任务直接在服务器正式目录里生成文件，留下了未提交的修改，导致后续 Git 拉取被阻塞的情况。

任务本身产生了结果，同步却卡住了。后来我把服务器正式目录和任务写入目录分开，定时写库也放到隔离 Worktree 中，通过统一入口处理提交和同步。

所以教程里保留了独立任务目录：某个任务写到一半时，主线仍可以保持干净；出了问题，也能找到对应的修改现场。

另一个容易误解的地方是锁。我的脚本用了本机 Git 锁，但服务器上的锁管不到你的 Windows。两台机器同时修改同一个文件，仍然会产生冲突。

所以，最小版本采用轮流写入。 电脑交出去之后暂停编辑，服务器提交并交回之后也停止修改旧任务分支。下一次服务器任务从最新主线新建目录和分支，例如 agent/demo-02。

遇到同步失败，先看 git status，确认自己在哪个分支、有哪些未提交文件，再看远端更新。网络失败可以排查网络；分支已经分叉或内容发生冲突，就需要比较双方修改。不要直接强推覆盖，也不要让脚本自动丢弃现场。

从这一小段开始用

我的日常操作还按任务情况做了区分：电脑上单人处理的低风险文档小改，可以检查后直接提交主线；服务器人工任务走独立分支和审阅；稳定的定时任务通过隔离目录、提交范围限制和检查后，再受控回写。

第一次复现，用上面这一种交接方式就够了。等你知道哪些步骤每天都会重复，再考虑把它们封装起来。

这套做法还有一个很实际的限制：记录会过时。目标已经改了，context.md 却没更新，下一位 Agent 可能沿着旧目标继续做。Git 能告诉你谁改过文件，却无法替你判断目标是否还成立。

因此，每次交接时，我更关心这几个问题：当前目标写清楚了吗？哪些结果已经验证？下一位从哪里开始？

直接把这篇文章交给你的 Agent

你可以把本文交给能访问本机文件和终端的 Codex、Claude Code 或其他 Agent，再附上下面这段提示词，让它参考文章，按你的实际环境完成接入。路径和另一端的情况填上，不清楚的地方写“待确认”就行。

text

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
请参考我提供的这篇 Hermes + Git 工作流文章，
帮我在现有 Obsidian 知识库上接入 Hermes 和 Git 同步，
让电脑和另一端的 Agent 能接着处理同一个项目。

我的知识库路径：<填写本地路径>
另一端的设备及 Hermes 安装情况：<填写，或写“待确认”>

先读取库里的协作规则，检查目录、Git 分支、远端、
未提交修改和 Hermes 的可用情况。缺少的关键信息一次问清。
文章中的路径、分支和命令只作参考，按我的环境调整。

保留已有笔记、目录、规则和 Git 仓库。
确认接入方式后，直接完成必要配置、交接文件和验证。
上传哪些资料、是否改变已有同步方式，先与我确认；
密钥和登录态留在仓库外，遇到冲突保留现场，不覆盖修改。

先选一篇我允许使用的普通笔记，跑通一次：
电脑写下任务 → Hermes 读取并生成结果 → 写回项目记录
→ Git 同步回电脑 → 本地新会话读取并接手。

最后告诉我改了什么、实际验证到了哪一步，
以及以后每次开始和结束工作该怎么操作。
某一步无法验证就明确标出，不把模拟结果写成实测完成。

先把这一次交接跑通，再用到下一个真实项目里。原来积累在 Obsidian 里的资料，就能随着每次任务继续被使用和更新。