我给所有AI工具装了一个共用大脑

我最近干了一件事，把我电脑上所有AI工具的「技能」和「知识」全部打通了。

不是那种云端同步的打通，是在我本地、在我自己电脑上，给 Claude Code、Cursor、WorkBuddy、Hermes、OpenClaw 这帮家伙装了一个共用的大脑。

为什么要搞这个？因为我实在受不了了。

先说说问题出在哪

我现在同时在用五个AI工具。不是那种「试试看」的在用，是每天都在用、每个都有自己擅长的场景的那种在用。Claude Code 写代码，Cursor 做阅读器，Hermes 跑自动化、秘书，WorkBuddy 处理一些日常简单事物（便宜）。

用得多了一个问题就出来了，就是每个工具各自积累的「技能」和「知识」是散的。

比如我在hermes里面做了一个写作风格的技能，叫 shine-writer。这个技能是我花了不少时间调的，它知道我怎么说话、什么词不能用、文章应该怎么组织。结果呢，WorkBuddy 用不上。我得手动复制一份过去。

然后我又在claude里面装了figma的技能，hermes也用不上。

最开始我用的方案是 rsync，就是写个脚本，把一个目录里的技能定期同步到各个平台的技能目录。听起来能跑对吧？但跑着跑着三个问题就出来了。

第一个是冗余。我有两个地方在存技能，一个 /.agents/skills/，一个 /.shared-agent/skills/。同样一份规范，存了两份。有时候我都分不清哪个是最新的。

第二个是单向。rsync 只能从一个方向往另一个方向推。如果我在 Claude Code 里面新建或者改了一个技能，它不会自动回流到规范源。我得自己记着去跑脚本。

第三个是不实时。必须手动跑同步脚本。忘了就不同步。我这个人就是忘性大。

所以我就想，能不能像 symlink 那样，改一处就处处更新？

其实我的需求很简单，就一句话，改一处，处处更新。

具体来说就是，不管我在哪个平台修改了一个共享技能，所有其他平台应该立刻就能用到最新版。不需要手动同步，不需要记着跑脚本。

另外我还想解决一个问题，就是当我在某个平台里做了一个新技能想共享出去的时候，流程不能太麻烦。最好是跑一个命令就搞定。

怎么做的

我今天的思路是这样的，把所有AI工具的「事实」部分抽离出来，做成一个共享目录。

你想想看，每个AI工具需要的知识其实分两类。一类是「你是谁、你为谁服务」这种事实，比如我的身份信息、项目列表、偏好设置。这些内容所有平台应该是一样的。另一类是每个平台自己的运行配置、密钥这些，这些确实不该共享。

所以我就做了一个分层。用一个目录当「规范源」，存所有需要共享的东西，然后让各平台通过不同的方式去读取这个规范源。

规范源

我在 ~/.agents/ 下面放所有共享的东西。

~/.agents/├── skills/          ← 所有共享技能的唯一规范源├── facts/           ← 共享事实（身份、项目、偏好）├── keys/            ← 密钥注册表（不存实际值，只记录哪个技能需要什么key去哪里取）├── registry.md      ← 技能注册表（每个技能分发到了哪些平台）└── 几个管理脚本

关键点就是 skills/ 这个目录，它是唯一的规范源。所有技能在这里只有一份，其他任何地方都不该有独立的副本。

三层分发

但是不同的AI工具支持的方式不一样，所以我又设计了一个三层分发策略。我觉得这个分层其实是最关键的，因为不同的平台能力不同，你硬要统一反而会出问题。

第一层，整目录 symlink。

像 Claude Code、Cursor、OpenClaw 这些平台，它们的技能目录就是直接读文件系统的，那我就直接把整个技能目录做一个软链接过去。比如 Claude Code 的技能目录下有一个 shine-taste，它其实是一个 symlink，指向 ~/.agents/skills/shine-taste。这样我在 Claude Code 里面编辑这个技能，改的就是规范源本身，所有其他 symlink 平台瞬间生效。

这就好比是你在一个共享文档里改了内容，所有打开了这篇文档的人立刻就能看到最新版。不需要任何同步操作。

这个是我觉得最理想的方式，零延迟，零维护。

第二层，文件级 symlink。

WorkBuddy 比较特殊，它的每个技能目录下有一个 _skillhub_meta.json 文件，是平台自己管理的元数据，不能被共享覆盖。所以对于 WorkBuddy，我就只对 SKILL.md 和 references 这些文件做 symlink，_skillhub_meta.json 保留为真实文件。

这种做法就是「该共享的共享，该保留的保留」。每个平台自己的平台专属文件不动，只把技能内容本身链接过去。也是今天试了一下才发现 WorkBuddy 有这个 meta 文件的问题，之前没想到。

第三层，rsync 复制。

Hermes 和 Nanobot 有自己的技能管理系统，比如 Hermes 会做完整性校验，你给它一个 symlink 它反而不认。对于这些平台，就还是用 rsync 把技能文件复制过去。只不过现在只需要一个方向了，从规范源推出去。

所以说我觉得这种分层的思路挺重要的。不要试图用一套方案解决所有问题，而是根据每个平台的特性选择最合适的方式。能 symlink 的就 symlink，不能的就 rsync，关键是规范源只有一个。

新技能怎么流转

光有分发还不够，还得解决「新技能怎么进来」的问题。

我今天专门想了一下，大概有四种场景。

场景一，在某个平台里创建了新技能，想共享给其他平台。

比如我在 Claude Code 里用 skill-creator 生成了一个新技能，想让 WorkBuddy 和 Hermes 也能用。我就跑一个 skill-promote 命令，它会自动把这个技能从 Claude Code 的目录搬到规范源，然后在 Claude Code 那边创建一个 symlink 指回去，再根据我选择的平台做分发。

整个过程就是「搬走 → 链接回去 → 分发出去」。原来的平台不会感觉到任何变化，但技能实际上已经在规范源里了。我觉得这个设计挺巧妙的，搬运对原平台完全透明。

场景二，从 GitHub 或者市场安装了技能，想纳入共享。

流程和场景一差不多。唯一的区别是，如果这个技能是从 GitHub 装的，它的来源信息会被保留下来，这样以后要更新的时候知道去哪里拉。这个我觉得是一个比较重要的细节，不然装了一堆技能后来都忘了从哪来的。

场景三，直接在规范源里创建新技能。

有时候我会在 ~/.agents/skills/ 下面直接写一个新技能，然后跑 skill-link 命令，它会提示我要分发到哪些平台，然后自动创建 symlink 或者 rsync。这个场景其实是最简单的，因为技能一开始就在规范源里，不需要搬运。

场景四，某个平台更新了共享技能的内容。

这个是最常见的场景。对于第一层和第二层的平台，因为是 symlink，改的就是规范源本身，所以所有平台自动生效，不需要任何操作。对于第三层的平台，需要跑一次 skill-link 来触发 rsync 更新。

我觉得这个设计里面最让我满意的地方就是，大多数情况下你都不需要做任何同步操作。你在一个地方改了，所有其他地方自动就有了。只有 Hermes 和 Nanobot 这种需要手动触发一下，后面我还要优化成自动的。

Key 的管理

还有一个问题要解决，就是密钥。

每个技能可能需要不同的 API Key。但这些 key 到底存在哪里？怎么让所有平台都能用到？

我之前的做法比较混乱，有的放在环境变量里，有的放在平台配置里，有的放在技能目录的 .env 里。说实话我自己都记不太清哪个 key 在哪。

所以这次我做了一个「密钥注册表」。不在规范源里存实际的密钥值，只是做一个表格，记录每个技能需要什么 key，以及这个 key 应该去哪里取。

技能通过 symlink 共享之后，密钥的处理方式就自然分成了三种。

环境变量型的 key，比如 WECHAT_APP_ID，我在 ~/.zshrc 里统一 export，所有平台启动的时候都会继承。

平台配置型的 key，比如 Hermes 的模型凭证存在它自己的 auth.json 里，这个不共享，各管各的。

技能目录里如果有 .env 文件，因为技能目录本身是 symlink，所以 .env 也是共享的，所有平台读到的都是同一份。

这样做的好处是，既保证了共享的便利性，又不会把密钥集中存在一个地方造成安全风险。每个 key 还是在它该在的地方，只是我们多了一层「这个技能需要什么 key」的记录，方便排查问题。当然我还没有把所有 key 的映射都整理完，这个后面慢慢补。

踩了什么坑

讲一下实际落地过程中踩到的坑。

最大的坑就是 symlink 的路径问题。 你得确保 symlink 的目标路径是正确的相对路径或者绝对路径。

另外一个坑是，不是所有平台都认 symlink。 我前面说过 Hermes 有完整性校验，它不吃 symlink 这套。所以第三层平台还是得用 rsync。这个没办法，只能接受。你不能强迫一个不支持 symlink 的平台去支持它，那就用它能接受的方式。

还有一个我之前没想到的问题， 就是当你 promote 一个技能的时候，必须先检查它是不是已经是一个 symlink。如果已经是 symlink 了，说明它已经在规范源里了，不能重复 promote。这个不检查的话会出问题，因为你会把一个 symlink 当成真实目录去搬，结果就乱了。我也是跑了一遍才发现这个逻辑要加。

最后一个就是心理建设。 把技能目录从一个地方搬到另一个地方，这个过程其实会有点紧张。虽然搬完之后会创建 symlink 指回去，原始平台不会有感知，但操作的时候还是会想「万一搞坏了怎么办」。我建议先在不太重要的技能上试，确认流程没问题了再搞全部的。

说实话搞完这个之后，最大的感受就是一种「消除了精神负担」的轻松感。

之前每次在一个平台里改了技能，脑子里都会冒出来一个念头，「其他平台同步了吗？」然后要么手动跑脚本，要么就安慰自己「下次一起同步」。现在不需要了，因为改的就是规范源本身，所有 symlink 平台自动就有最新版。

而且 promote 一个新技能的流程也简单了很多，一条命令就搞定，不需要我手动去各个平台目录下创建链接或者复制文件。

当然也有限制，第三层平台还是需要手动触发同步，这点没法完全自动化。但至少相比之前所有平台都要手动同步，已经好了太多了。我也不确定后面有没有更好的办法来解决 Hermes 和 Nanobot 的这个问题，如果有试过的同学可以在评论区说一说。

如果你也同时在用好几个AI工具，而且也遇到技能和知识散落各处的问题，可以试试这个思路。核心就是三件事，一个规范源、按平台能力分层分发、把技能流转的流程自动化。

不一定非得用我这套目录结构，但思路是通用的，把共享的部分抽出来，让各平台以最合适的方式去读取。

那么今天的分享就到这里了，如果你也在折腾多工具共用的方案，欢迎在评论区聊聊你是怎么做的，我也很好奇大家都是怎么解决这个问题的。