我用Hermes给自己搭了一个「第二大脑」，132处断链10秒修完

Karpathy十天前发了一个gist（5000+ stars），提了一个很有意思的观点：知识库不应该用来搜索，而应该用来编译。就像写代码一样，新信息进来，编译器自动检查已有模块、更新依赖、确保一致性，而不是每次都从头解析一遍。

但这个思路一直缺一个东西：谁来当那个编译器？

Hermes是GitHub上的一个开源AI Agent框架，大部分人把它当聊天机器人或者编码助手来用。但它有一个被低估的能力：默认就带一套llm-wiki技能，能直接操作本地文件系统。这就让它有资格当那个编译器。

昨天我用Hermes搭了一套三层结构的AI知识库。现在有49个wiki页面，覆盖各大模型、IDE、视频生成工具、MCP协议等方向。最爽的是，每次收录一篇新文章，Hermes会自动提取实体、创建页面、建立交叉引用，把新知识织进已有的网络。而这一切其实都是我在手机上通过微信操作Hermes完成的。

本文拆解一下这套系统的架构设计和实现细节。

RAG解决不了的问题

很多人用Obsidian + AI的做法是：把笔记丢进向量数据库，提问时做RAG检索。这个方案对”找东西”够用了，但有一个根本性的缺陷：知识不会累积。

每次你问一个问题，RAG从几百篇笔记里捞出几段相关的文本片段，LLM现场理解上下文、生成回答。但这次分析的结果呢？消失了。下次你再问一个稍微不同的问题，LLM又要从零开始重新分析一遍同样那几篇笔记。

这就像每次需要某个知识点时，都去图书馆重新读一遍相关章节，而不是在笔记本上写下一份自己的摘要。

更实际的问题：假设你在3月份的一篇笔记里分析过Claude和GPT的定价差异，5月份另一篇笔记里又提到了新的价格变动。RAG检索时，两次分析各自独立存在，LLM不会自动帮你合并成一份更新的对比结论。你必须手动去发现这两篇笔记有关联，然后自己动手整合。

说白了就是”知识租赁”：你每次都在租用AI的理解能力，而不是在积累理解的结果。

工具链：llm-wiki + Hermes

这套系统的两个核心组件：

Hermes是驱动这一切的本地AI Agent框架。它的关键能力是：直接读写本地文件系统（通过read_file/write_file）、调用ripgrep进行内容搜索（通过search_files）、执行Python脚本进行批量操作（通过execute_code）。所有操作都在本地完成，知识库里的内容不会上传到任何第三方服务。

llm-wiki是一个知识库维护skill，把Karpathy的LLM Wiki模式封装成了标准化的操作规程。包括三层目录结构的标准、收录/查询/一致性检查的操作流程、实体页/概念页/对比页的页面模板，还有冲突处理和归档策略。安装到Agent里之后，AI就有了”知识库管理员”的行动框架。

两者的分工很清晰：llm-wiki定义”知识该怎么组织”，Hermes提供”操作本地文件的能力”。这个分层不是偶然的：如果你想换成别的Agent框架（比如Claude Code、Cursor），llm-wiki的操作规程照样可用；如果你想给Agent添加新的能力（比如自动追踪GitHub Trending），装一个新的Skill就行。

编译式知识库的架构

我平时用Obsidian + iCloud手动维护知识库，没有自动组织之前，文件间的链接非常难维护。Hermes先帮我分析了现有的库结构，给出了优化方案：保持现有目录结构的基础上增加一个wiki文件夹。确认方案后它帮我初始化了wiki目录：

262

wiki/
├── SCHEMA.md           # 规则层：定义一切约定
├── index.md            # 导航：所有页面的一句话摘要
├── log.md              # 变更日志：append-only
├── raw/                # 第一层：原始素材，不可变
│   └── articles/       #   原文原封不动存这里
├── entities/           # 第二层：实体页（工具、公司、模型）
├── concepts/           # 第二层：概念页（方法论、趋势、技术）
└── comparisons/        # 第二层：对比分析

接着它扫描了我Obsidian仓库里的所有文件，分成5个任务并行处理。耗时10几分钟，中间遇到iCloud同步锁死文件的问题，重试后解决。

第一层：Raw—— 不可变的原始素材

所有外部来源的文章、论文、教程，原文存入raw/articles/，不做任何修改。

这一层的设计原则很简单：永远不要修改原始素材。作用是提供可追溯的信息源，任何wiki页面在frontmatter里必须标注sources字段，指回对应的raw文件，保证知识的可验证性。 当然，raw不一定是一个文件夹，也可以保持现有目录结构，作为一个结构化的raw。

第二层：Wiki—— AI维护的编译产物

这是整个系统的核心。每个wiki页面不是一篇独立的文章，而是知识网络中的一个节点。

举个具体的例子。我让AI收录一篇讲Claude Code token优化技巧的文章。AI的处理流程是这样的：

步骤1：定向感知。AI先读取SCHEMA.md和index.md，了解知识库当前覆盖了哪些实体和概念。这一步决定了AI是去”已有页面里补充信息”还是”创建新页面”。在我的知识库里，它发现已有claude-code.md（实体页）和llm-token.md（概念页）。

步骤2：内容解析。AI读取原文，提取出关键实体（Claude Code、Anthropic）和核心概念（token管理、API缓存、MCP工具消耗）。

步骤3：决策。原文的核心贡献是”一套系统化的token省钱方法论”。已有的claude-code.md是工具的概览页，不应该塞进这么细的方法论；llm-token.md是token计费的基础概念页。所以AI决定创建一个新的概念页claude-code-token-optimization.md。

步骤4：写入。看一下这个frontmatter：

---
title: Claude Code Token 省钱秘笈
created: 2026-04-14
updated: 2026-04-14
type: concept
author: external
tags: [ide-tool, inference, tutorial, workflow]
sources:
  - wiki/raw/articles/claude-code-save-tokens-2026.md
---

几个要点：type: concept说明这是概念页；author: external标明内容来源于第三方；sources字段指向raw层的原始文件；标签全部来自Schema预定义的taxonomy，没有自由发挥的空间。

步骤5：交叉引用。AI在新页面底部写入了5个[[wikilinks]]——claude-code、llm-token、ai-coding-tools、mcp、cursor-ide。同时，AI回到已有的claude-code.md和llm-token.md页面，补充了反向链接。这就是”编译”的过程：新知识不是孤立的，它被自动织入已有的知识网络中。

步骤6：导航更新。最后AI更新index.md（添加新条目，总数从48变成49）和log.md（追加操作记录）。

整个过程从我发一条指令开始，到全部文件写入完成，不到一分钟。要是手动操作的话（读完原文、提炼要点、检查已有页面、写新页面、逐个去已有页面加反向链接、更新索引和日志），保守估计半小时。

第三层：Schema—— 约束AI行为的规则引擎

很多人忽略这一层，但它才是系统能跑起来的关键。

Schema定义了AI”能做什么、不能做什么、怎么做”。我的Schema里有几条硬规则：

实体创建阈值：一个实体必须在2篇以上的源文章中出现，才值得创建独立页面。只在一篇文章里出现过一次的工具？不值得建页，信息留在原文章对应的raw文件引用里就好。

页面大小限制：超过200行的页面必须拆分。这个阈值是根据Obsidian的阅读体验定的，200行左右的页面能在30秒内读完，再长就变成”参考文档”而不是”知识卡片”了。

交叉引用最低要求：每个页面至少要有2个出站的[[wikilinks]]。如果一篇文章确实找不到足够的关联，说明它可能太窄了，或者知识库还太薄。

更新优先级：新信息与已有内容冲突时，以时间戳为准，新的覆盖旧的。但如果确实存在矛盾（比如两篇文章对同一个功能给出了不同的性能数据），Schema要求同时保留两个版本，在frontmatter里标注contradictions: [page-name]，等人类来审。

标签约束：所有标签必须来自预定义的taxonomy。我的taxonomy有30多个标签，分5个维度（工具类型、技术概念、商业/公司、内容相关、元数据）。AI不能自创标签，这防止了标签膨胀。发现需要新标签的话，得先更新taxonomy，再拿来用。

这套规则的本质是：用显式约束替代隐式判断。没有Schema的话，AI每次收录文章时都在”凭感觉”决定该不该建页、该怎么写、该链接到哪里。有Schema之后，这些决策变得可预测、可审计。

批量维护的实战：132处引用，10秒更新

昨天我让Hermes Agent帮我重构了Obsidian vault的顶层目录结构，具体改动：

• 1.Published/ → 9.Done/（把已发布的内容从第一个位置挪到最后）
• 9.References/ → 10.References/（参考资料腾出编号）
• 新增1.Resources/（活跃资源）、2.Canvas/（画布）、Attachment/（附件）

问题来了：wiki页面在frontmatter sources字段里大量引用了旧路径，比如1.Published/xxx.md。

AI的处理流程：

Step 1: search_files("1.Published", path="wiki/")
        → 命中 41 个文件，129 处匹配

Step 2: search_files("9.References", path="wiki/")
        → 命中 3 个文件，3 处匹配（不含log.md中的变更记录）

Step 3: Python脚本批量替换（排除raw/目录，原始素材不动）
        → 执行 132 处路径替换

Step 4: search_files("1.Published", path="wiki/")
        → 仅 log.md 中有 2 处匹配（变更记录本身，属于历史存证）

为什么用Python脚本而不是逐个patch？41个文件、132处替换，如果用AI逐个调用文件编辑工具，每个文件一次工具调用，至少41次API请求。用Python脚本一次搞定，省95%的API开销。

另外有一个技术细节：search_files底层用的是ripgrep，它能在macOS的iCloud同步锁状态下正常工作。iCloud Drive在同步时会锁文件，普通文件读取返回空，这个问题我被坑过好几次。在iCloud vault里，ripgrep比直接read_file靠谱得多。

最后更新SCHEMA.md里的文件夹约定表（添加新文件夹的行）和log.md（追加变更记录）。从发现问题到全部完成，10秒左右。

几个踩过的坑

交叉引用的雪球效应。收录一篇长文章，理论上可能触发5-15个已有页面的更新。早期我让AI全量更新，结果发现它会把一些关联不强的页面硬拉上关系。后来在Schema里收紧了链接标准：只在”确实存在直接的信息补充关系”时才添加链接，而不是两个页面出现了相同关键词就链接。

工具的”热情”有时会帮倒忙。我让AI帮我生成两张配图，准备插到文章里。结果新文件一进vault，llm-wiki skill自动触发了，开始分析这两张图片要不要收录、要不要建页、要不要加交叉引用。等它折腾完，对话上下文里堆了一堆wiki维护的信息，AI已经”忘了”我原始的意图是插图片，最后两张图放错了位置。这个问题的根源是skill的触发机制太敏感——它分不清”用户在写文章”和”用户在维护知识库”这两个场景。后来我在操作流程里加了一条规则：写文章时先暂停llm-wiki skill，避免它干扰主任务。

AI生成的页面容易泛泛而谈。第一版batch建页时，有些概念页写得像维基百科摘要，什么都有，什么都不深。后来我调整了prompt，要求每个页面必须包含”与vault中已有内容的具体关联”。比如写token优化那个页面时，必须引用已有工具页中的具体功能特性，不能泛泛地说”token对AI工具很重要”。

知识一致性的灰区。两篇文章对同一件事给出不同数据时（比如一篇说某模型支持10万context，另一篇说8万），Schema要求保留两个版本并标注矛盾。但实际操作中，AI有时候会”自作主张”选一个它认为更可信的版本。这个问题目前还没完美解决，只能靠log里的变更记录做审计。

总结

不是所有知识都适合用这个方案来管理。

适合的：一个明确的领域（比如AI工具领域），信息源以文章、教程、论文为主，实体和概念相对稳定，需要长期积累和交叉对比。

不太适合的：高度时效性信息（新闻、股价）、纯个人笔记（日记、情绪记录）、需要实时数据的知识（API文档会频繁变动的场景）。

目前每天收录1-2篇新文章。在这个规模下，AI维护的成本几乎为零，收益很明显。每收录一篇文章，知识网络就稠密一点，查询时能关联到的上下文就多一点。

如果你也在某个垂直领域维护大量笔记，需要跨文章做关联和对比，可以试试这个思路， 有什么问题可以在评论区聊。