上一篇我们在 Hermes 中配置了多 Profile，每个 Profile 绑定了各自的飞书应用。但光有应用还不够——要让这些机器人真正”干活”，还需要给它们分配对应的 Skill，明确职责边界。这篇文章围绕三个核心主题展开：多飞书机器人如何分工、Skill 集中管理方案、本地与服务器的 Git 同步机制。一、多飞书机器人如何分工多 Profile 配合多飞书机器人，核心目的是让不同的 Agent 只做自己该做的事。比如我们只让内容选题处理选题相关的工作；内容创作则只负责与写作相关的事情。不用把所有功能都在一个机器人里面完成，容易造成混乱不可控。我目前的几个机器人分工是这样的：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
每个 Profile 绑定一个独立的飞书应用，职责清晰，互不干扰。这种分工方式带来的好处不只是整洁——更重要的是，每个 Agent 的上下文更聚焦，输出质量也会更稳定。二、Skill 集中管理为什么要集中管理因为我在本地是使用Obsidian + claudian的，所以 Skill 都放在.claude/skill目录了，如果我需要同步到服务器，则需要继续保持这种结构，这样的好处是即便后续不用 Hermes了，并不影响本地的使用。再者，我主要还是在本地使用的，所以 Skill 就不能到处放，不然就不好管理和维护。如果每个 Profile 都复制一份 Skill， Skill 更新的时候要到处同步，太麻烦。所以，可以将 Skill 集中存放，各 Profile 通过external_dirs引用， Hermes 是支持 Skill 存放在任意目录的， 正好利用这个特性。数据目录规划我把知识库的根目录放在/data/obsidian/目录下， 这个不用和本地完全一致，只需要确保目录结构内的文件通过 Git 与本地保持同步即可， 后续版本库的文件是同步到这个目录下的。这样本地和服务器路径完全一致，维护起来几乎零成本。配置 external_dirs在每个 Profile 的config.yaml里加上external_dirs配置：
# ~/.hermes/profiles/content_curation/config.yaml
profile:
name: content_curation
skills:
external_dirs:
- /data/obsidian/.claude/skill
所有 Profile 都指向同一个目录， Skill 只要有更新，所有 Profile 都能生效。注意：如果每个profile 都要用到这些共享的 Skill ,则需要每个 Profile 的配置文件 都要加上相应的配置。
这种配置不需要自己手动去加，直接告诉 Hermes 去改就行。 用 AI 一定要养成一个习惯—能交给 AI 做的事，就不要自己手工去做。Skill 自动修改的问题配置完成之后，需要重启下网关，应该就能在飞书中调用了，但是不一定能完全可用，比如我们的 Skill 里面有一些路径定义的和本地不一样，可以明确指定现在的知识库路径是什么，让Hermes记住。还有一点需要格外注意：Hermes 是一个自进化的 Agent , 在使用 Skill 的时候，它会根据你的想法和习惯去慢慢修改和调整我们的 Skill ，如果我们不想让它去随意修改我们的 Skill 的话，目前好像还不太好管理， 单靠 SOUL.md 里写规则并不能完全限制它。我现在的策略是： 把所有 Skill 里面的有输出的从内部剥离出来，都放到外面来管理， 如果 Hermes 在使用的时候擅自改动了，我会在同步的时候，先回滚掉这个改动，再同步。我需要所有的 Skill 都是本地我自己改的，不然它什么时候删除东西了，而我并不知道，这个时候一同步，就会污染我本地的内容。三、各 Profile 输出到统一路径为了让 Agent 的产出能顺畅流转到本地，我将所有 Profile 的输出目录统都指向知识库路径下。这样，无论哪个 Agent 写了内容，经过 Git 同步后，在本地 Obsidian 里就能直接看到和编辑。四、本地与服务器 Git 同步解决了 Agent 的使用问题，还有一个绕不开的工程问题：本地改了 Skill 或配置，服务器怎么同步？服务器产生了新内容，本地又如何获取？同步的工具或软件、方案有很多，我选择用 Git 来解决这个问题。为什么选 Git
- 配置或Skill 更新了、 Agent 写了新的内容，都有完整版本记录
- 如果出现问题了，可以回退， 不会造成数据丢失。
- 配置也简单，配置好 SSH ，建立仓库即可。
- 可双向同步，本地推和服务器拉，反之变然。
服务器配置 SSH要让服务器能拉取私有 Git 仓库，需要先配置 SSH Key。这一步同样不需要手动操作，直接把需求发给 Hermes，让它生成密钥、配置好环境。我们只需要把生成的公钥复制到 Git 仓库的 SSH 管理页面里即可。
代码拉取、目录初始化等操作也是同样的思路——直接让 Hermes 操作，不用自己一步步敲命令。服务器自动同步脚本解决了代码的正常拉取和提交，还需要一个定时任务，这样可以定时拉取或推送数据到版本库，实现和本地的数据同步依然是把同步需求发给 Hermes ，让它写脚本实现整个的同步逻辑。
本地同步：Obsidian Git 插件上面说的是服务器这块的自动同步，接下来说下本地的同步， 我用的是 Obsidian 的 Git 插件，在设置中-第三方社区搜索 「git」, 找到作者为 ：「Vinzent」这个
安装完成后，启用插件，根据需要，配置拉取和推送的时间，就能在指定的时间内将服务器的数据拉取到本地，同时本地的更改也能同步到服务器上面。
五、完整链路梳理把上面所有环节串起来，整个系统的运转流程如下：1. 本地配置好共享 Skill 和知识库，上传到 Gitee 仓库2. 服务器通过 SSH 克隆到/data/obsidian/3. 所有 Profile 的external_dirs指向/data/obsidian/.claude4. 各飞书机器人独立工作5. 各 Profile 的输出通过 Git 同步到本地6. 本地在 Obsidian 里处理（编辑、排版、发布），改动再同步回服务器7. 本地改动（含 Skill 更新）再通过 Git 同步回服务器目录结构本地与服务器保持一致的好处是：本地怎么配，服务器就怎么配，不用改任何路径。写在最后这篇文章把 Skill 配置和 Git 同步两个核心模块都梳理了一遍。Skill 配置的核心是职责隔离——每个 Agent 只知道跟自己业务相关的技能，不会串台。这个比堆更多 Skill 重要。Git 同步的核心是版本控制——知识库的内容在本地和服务器之间流动，每一次变更都有版本记录，出了问题随时可回退，不用担心数据丢失。这两块搞完之后，Agent 系统的协作链路才算真正打通：选题 Agent 分析热点 ，创作 Agent 生成初稿 ，再将结果存到知识库，我们在本地直接打开 Obsidian 看到内容继续创作。以上就是今天的分享，后续我还会继续分享实际使用中遇到的问题和优化思路。配置过程中有什么问题，欢迎留言交流。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
