Karpathy 的 LLM Wiki 思想终于被工程化了：Nous Hermes LLM-Wiki Skill 完整解析（附 11 条 Lint 审计项和 Obsidian 无头同步方案）

Karpathy 的 LLM Wiki 思想终于被工程化了：Nous Hermes LLM-Wiki Skill 完整解析

刚写完 WikiSkill 论文就发现一个工业级实现？这篇可以当作上一篇的工程对照版。

本文提纲

  1. 为什么 WikiSkill 论文和 Karpathy LLM Wiki 缺了一环：没有可执行的工程规范
  2. Hermes Agent research/llm-wiki Skill 总览：三层文件架构 + 三大核心操作
  3. 启动一个新 Wiki：SCHEMA.md 约束体系 + frontmatter 质量信号 + 标签分类法
  4. Ingest 流程：Raw 源不可变 + SHA256 漂移检测 + 页面阈值 + 溯源标记
  5. Query 流程：Index 定位 → 页面阅读 → 综合答案 → 有价值结果反向写回 queries/
  6. Lint 审计流程：11 条健康检查（孤儿页面、断链、过期、矛盾、漂移、标签违规…）
  7. 日常运维：Bulk Ingest 批处理、Archive 归档、Log 轮转、检索命令
  8. Obsidian 集成与无头同步：服务器端 Agent 写、桌面端 Obsidian 读的双向实时同步
  9. 11 条官方 Pitfalls + 与 WikiSkill / llm-wiki-compiler 的横向对比
  10. 落地实操：把 TheAIEra 项目改造成 LLM Wiki 架构需要几步

为什么 WikiSkill 论文和 Karpathy 的 LLM Wiki 缺了一环

前天写 Google Research 的 WikiSkill 论文（arXiv 2608.27454）时有个感觉：架构图画得很漂亮，Raw→Wiki→Skills 三层讲得也对，但它是一个研究框架——核心关注的是"怎么让 Skill 在验证集上分数涨上去"，而不是"真实团队里怎么日复一日维护知识库"。

Andrej Karpathy 年初在推上提出 LLM Wiki 这个思路时更直白："Agent 不应该每次都用 RAG 从零在原始语料里挖知识，知识应该被编译一次、写进持久维基、持续更新、越用越厚。"但他只给了理念，没给可执行的目录规范、页面类型、frontmatter、审计规则。

Nous Research 在它的 Hermes Agent 里，把这个理念以一个内置 Skill 的形式工程化落地了——名字就叫 research/llm-wiki（v2.1.0，MIT 协议，Windows/macOS/Linux 全平台），和论文恰好同一天（2026.8.27）文档可见。更巧的是：它也是三层架构，只是第三层不是 Skills 而是 SCHEMA——这是"面向个人/小团队知识沉淀"和"面向 Agent Skill 进化"的两种设计分叉。

今天就把这个 Skill 完整拆解一下。不是概念，是可以抄的工程细节：目录结构、frontmatter 字段、11 条 Lint 检查项、Obsidian 无头同步 systemd 单元文件，全有。

LLM-Wiki Skill 总览

先看 Skill 元信息，确认这是个稳定的内置能力而非实验品：

字段 值
Source Bundled（Hermes 安装后自带，无需额外装 Skill）
路径 skills/research/llm-wiki
版本 2.1.0
作者 Hermes Agent
协议 MIT
平台 linux, macos, windows
标签 wiki, knowledge-base, research, notes, markdown, rag-alternative
关联 Skill obsidian、arxiv（ArXiv 条目直接 ingest 到 LLM Wiki）

定位宣言（SKILL.md 开头原文）：

Unlike traditional RAG (which rediscovers knowledge from scratch per query), the wiki compiles knowledge once and keeps it current. Cross-references are already there. Contradictions have already been flagged. Synthesis reflects everything ingested.

分工：人类选源、定分析方向。Agent 负责总结、交叉引用、归档、一致性维护。

一句话：LLM Wiki 是"编译过的 RAG"——RAG 每次都对原始资料重新做 embedding + 检索 + 合成；LLM Wiki 在 ingest 时就把知识结构化写入，查询时直接读已经整理好的维基页面。

激活条件（什么时候 Hermes 会自动加载这个 Skill）

  • 用户要求 create/build/start a wiki/knowledge base
  • 用户要求 ingest/add/process a source 进 wiki
  • 用户问的问题，且 $WIKI_PATH/~/wiki 下已经有 wiki
  • 用户要求 lint/audit/health-check wiki
  • 用户在 research 语境下提到 "my wiki"、"knowledge base"、"notes"

不是你手动 use skill，是它自动判断——这是 Bundled Skill 的好处。

目录结构（三层架构，纯 Markdown 文件，零数据库）

wiki/                          ← $WIKI_PATH 或默认 ~/wiki
├── SCHEMA.md                  ← Layer 3：结构规则、标签分类法、领域声明
├── index.md                   ← 内容总目录（分节 + 一行摘要 + 条目总数）
├── log.md                     ← 追加式时间线操作日志（500 条后按年份轮转）
├── raw/                       ← Layer 1：不可变原始资料
│   ├── articles/              ← Web 文章、剪报
│   ├── papers/                ← PDF、ArXiv 论文
│   ├── transcripts/           ← 会议记录、访谈转录
│   └── assets/                ← 图片、图表
├── entities/                  ← Layer 2：实体页（人物、组织、产品、模型）
├── concepts/                  ← Layer 2：概念页（技术、方法、主题）
├── comparisons/               ← Layer 2：对比分析页
├── queries/                   ← Layer 2：归档的高质量查询结果
└── _archive/                  ← （需要时创建）过期被取代内容

对照 WikiSkill 论文架构来看：

MERMAID_BLOCK_0

关键差异：WikiSkill 的 Layer 3 是可执行过程知识（SKILL.md），Hermes LLM-Wiki 的 Layer 3 是规约约束（SCHEMA.md）。前者服务于"Agent 自进化 Skill 让验证集分数上涨"，后者服务于"人类+Agent 协作构建一个长期不腐烂的知识库"。两者 Layer 1/Layer 2 的设计哲学完全一致，Layer 3 因为目标不同而分化。

设计分叉的原因很好理解：研究中需要技能持续变异+验证门控；真实个人/团队用的知识库，最怕的是变异，最需要的是结构稳定。SCHEMA 就是稳定性的源头。

启动新 Wiki：SCHEMA.md 是整部宪法

这是整个 Skill 里最有工程智慧的部分。它不是上来就 ingest 资料，而是先问你：这个 Wiki 的领域是什么？ 然后为该领域写一份 SCHEMA.md——所有后续的文件命名、frontmatter、标签、页面创建门槛、更新策略全部由它规定。

SCHEMA.md 必须包含的 7 大节

# Wiki Schema

## Domain
[AI/ML research | personal health | startup intelligence]

## Conventions
- 文件名：小写 + 连字符（`transformer-architecture.md`）
- 每个 Wiki 页必须有 YAML frontmatter（见下）
- 内链用 [[wikilinks]]，每页至少 2 条出站链
- 更新页面必须 bump updated 日期
- 新页面必须加到 index.md 对应节
- 每个动作必须追加 log.md
- **溯源标记（Provenance markers）**：综合 3+ 源的页面，段落末尾用 ^[raw/articles/xxx.md] 标具体出处

Frontmatter 字段（含可选质量信号）

这是让知识库"不会变成垃圾堆"的关键。不是"写了就完事"，而是每条知识都自带状态标签：

---
title: Page Title
created: YYYY-MM-DD
updated: YYYY-MM-DD
type: entity | concept | comparison | query | summary
tags: [taxonomy tags below]
sources: [raw/articles/source-name.md]
# Optional — but 强烈建议给快变/观点类内容加上
confidence: high | medium | low
contested: true                              # 存在未解决矛盾
contradictions: [other-page-slug]           # 冲突的对端页面
---

为什么 confidence 和 contested 不是多余字段？
因为知识库最危险的不是"有错误"，而是"弱观点默默硬化成了事实"。Lint 流程会专门挑出 contested: true 和 confidence: low 的页面提醒你复核——这些才是最容易传播错误知识的地方。RAG 没有这个能力，它把所有 chunk 一视同仁。

Raw 源也有 frontmatter（SHA256 漂移检测）

---
source_url: https://example.com/article
ingested: 2026-08-30
sha256: <hex digest of body only>   # 只算 frontmatter 之后的正文
---

这个设计特别狠。下次再 ingest 同一个 URL：
1. 重新下载 body
2. 重新算 sha256
3. 和存的比较
- 一样 → 跳过，不做任何处理（省 token）
- 不一样 → 标记 source drift（源站改了），重新处理

这个机制是免费的，成本就是每行 sha256 计算，但它防住了"源站偷偷改了内容我们的 wiki 还在重复老信息"这个长期知识库的第一死因。

Tag Taxonomy（标签分类法 + 反 tag sprawl 规则）

SCHEMA 里必须定义 10-20 个顶级标签。示例 AI/ML 域：

Models:     model, architecture, benchmark, training
People/Orgs: person, company, lab, open-source
Techniques: optimization, fine-tuning, inference, alignment, data
Meta:       comparison, timeline, controversy, prediction

铁律：Wiki 页面上用的每个标签必须先出现在 SCHEMA 的 taxonomy 里。想加新标签？先改 SCHEMA.md，再用。Lint 第 10 条就是抓"自由标签"的。

这阻止了知识库的 tag 从"十几个清晰分类"变成"几十个同义词/近义词垃圾堆"——这是我自己 Notion/Obsidian 多次崩盘的原因。自由标签长得比知识还快。

Page Thresholds（页面创建门槛，防垃圾页）

不设定门槛，Agent 见一个人名就开一页，知识库很快变成目录合集：

情况 动作
实体/概念在 2+ 个源 出现，或 1 个源里的核心主题 创建新页
源中提到了已有页覆盖的东西 追加到现有页
脚注里提了一次的人名/小细节/域外内容 不创建
单页 > 200 行 拆分成子主题 + 交叉链接
内容被完全取代 归档（移到 _archive/，从 index 移除，链入方替换成 (archived)）

4 种 Page Type

  • Entity Pages：一个 notable 实体一页。包含是什么、关键事实日期、和其他实体的 [[wikilink]] 关系、来源。
  • Concept Pages：一个概念/主题一页。含定义、当前共识、开放问题/争议、相关概念链。
  • Comparison Pages：并排对比。含维度表格、综合判断、来源。
  • Query Pages：有价值的查询结果归档（不是所有查询都归档，只有"再推导一遍会很痛"的才存）。

三大核心操作：Ingest → Query → Lint

整个 Skill 的 Agent 行为被严格限定在三个操作上。不会出现"Agent 随便改你的 wiki"这种情况。

操作一：Ingest（把一份新资料整合进 Wiki）

6 步流程，每一步都有防垃圾机制：

MERMAID_BLOCK_1

第 1 步里的漂移检测（之前提过）：如果这是同一 URL 的 re-ingest，重算 sha256 比——未变就跳过，变了才标记 drift 重新处理。

第 3 步的 anti-duplicate：很多 Agent KB 方案的通病是 ingest 第 5 篇文章时重复创建同一实体的第 5 个页面，知识库变成碎片。这里强制 Agent 在写前先查 index + search_files。

第 4 步的交叉链接：硬性规定每页必须至少 2 条出站 [[wikilink]]。孤立的页面在查询时永远找不到，等于没写。

操作二：Query（回答一个领域问题，结果有价值则反向落库）

  1. 读 index.md 定位相关页面 → 大 Wiki（100+ 页）再加 search_files 全站搜关键词
  2. 读相关页面的完整正文
  3. 用已经编译好的知识综合回答。引用格式：Based on [[page-a]] and [[page-b]]...
  4. 反向写回（关键）：如果这个回答是"有分量的比较、深度分析、新的综合结论"，而不是简单查表 → 在 comparisons/ 或 queries/ 下创建新页。简单 lookup 不归档，只归档"下次重新推导会很痛"的结果。
  5. 更新 log.md（记录查询 + 是否落库）。

这一步是"知识复利"的关键——回答用户的问题本身变成了知识库的增量。传统 RAG：你问过一个复杂问题，下次再问还得重新检索合成；LLM Wiki：你问过一次有价值的问题，这个答案已经是一张维基页，下次查直接命中。

操作三：Lint（11 条健康审计，知识库的年度体检）

这是 LLM-Wiki Skill 工程化程度最高的部分。没有 Lint 的知识库，半年后一定会腐烂。

# 审计项 检测方式 严重程度
① Orphan pages（孤儿页） 扫描所有 Layer 2 .md 文件的 [[wikilinks]] 建入链表，入链数 = 0 的是孤儿 高
② Broken wikilinks（断链） [[xxx]] 指向的文件不存在 高
③ Index completeness（目录完整） 对比文件系统上的所有页和 index.md 的条目，未登记的要补 高
④ Frontmatter validation（元数据校验） title/created/updated/type/tags/sources 6 项齐备；标签全在 taxonomy 中 中-高
⑤ Stale content（内容过期） updated 日期 比最近提到同实体的 raw 源还老 90 天以上 中
⑥ Contradictions（矛盾） 同主题页面冲突声明；所有 contested: true / contradictions:[] 页面汇总给用户 中
⑦ Quality signals（质量信号） 列出所有 confidence: low；以及只引用单源却没 set confidence 的页（应降为 medium） 中
⑧ Source drift（源漂移） 对每个 raw/ 文件重算 sha256，和 frontmatter 比对；变化了 = 源站内容改了或 raw 被人工碰过 低-中（不是硬错，但必须报告）
⑨ Page size（页长） > 200 行的 → 该拆分了 低
⑩ Tag audit（标签违规） 列出所有在用标签，挑出不在 SCHEMA taxonomy 中的自由标签 低
⑪ Log rotation（日志轮转） log.md > 500 条 → 重命名为 log-YYYY.md，开新档 低

输出格式：按严重程度分组（broken links > orphans > source drift > contested pages > stale content > style issues），每条带具体文件路径和建议动作。然后追加一条 ## [YYYY-MM-DD] lint | N issues found 到 log.md。

第 ① 条孤儿页面检测的代码片段（Skill 文档里直接给的 Python 框架）：

import os, re
from collections import defaultdict

wiki = "<WIKI_PATH>"

# 扫描 entities/ concepts/ comparisons/ queries/ 所有 .md
# 抽出所有 [[wikilinks]] → 建入链 map
# 入链数 = 0 的页面就是孤儿

这 11 条每一条我都踩过坑：Notion 3 年积累的页面，一半是孤儿；Obsidian 里大量断链没人修；标签分类 2 年后完全混乱；某网页改了内容我一直引用旧版……这份 Lint 清单直接抄。

日常运维 4 项

Searching（4 种检索命令）

# 内容检索
search_files "transformer" path="$WIKI" file_glob="*.md"
# 按文件名
search_files "*.md" target="files" path="$WIKI"
# 按 frontmatter 的 tag（正则）
search_files "tags:.*alignment" path="$WIKI" file_glob="*.md"
# 最近动态
read_file "$WIKI/log.md" offset=<last 20 lines>

Bulk Ingest（批量入料）避免重复索引

一次性 ingest 多个源，不要逐个 ingest（逐个会重复 update index 多次）：
1. 一次性读全部源
2. 一次性识别所有实体/概念 → 一次 search_files 查是否已存在（不是 N 次）
3. 一次性 create/update 所有页面
4. 结尾只写一次 index.md
5. 只写一条 log entry 覆盖整批

Archiving（归档生命周期）

内容被完全取代或领域变了时：
1. 没 _archive/ 就建
2. _archive/entities/old-page.md（保留原目录层级，别全扔在根下）
3. 从 index.md 删除
4. 所有链入它的页面 → 把 [[old-page]] 改成 old-page (archived) 纯文本
5. 记一条 archive log

Log Rotation（日志轮转）

log.md > 500 条 → 改名为 log-YYYY.md 存根，开始新档。Lint 会自动检查。

Obsidian 集成与无头同步：Agent 在服务器写、我在手机读

这是最惊艳的落地细节。知识库的目录本身就是一个合法 Obsidian Vault：

  • [[wikilinks]] 直接就是 Obsidian 的点击链接
  • Graph View 直接画知识网络
  • YAML frontmatter 直接被 Dataview 插件用来做查询
  • raw/assets/ 放图片，![[image.png]] 直接引用

最佳实践设置：Obsidian 里把 attachments 目录设为 raw/assets/，打开 Wikilinks 选项，装 Dataview 写查询：

TABLE tags FROM "entities" WHERE contains(tags, "company")

无头同步（Server / Headless 机器）

你的 Agent 可能在一台 24h 开机的服务器上跑 ingest/lint，你在笔记本或手机 Obsidian 上读。怎么同步？用 obsidian-headless（Node.js 22+），它用 Obsidian Sync 协议但不启动 GUI：

# 装
npm install -g obsidian-headless

# 登录 Obsidian 账号（Sync 订阅）
ob login --email <email> --password '<password>'

# 建远程 vault
ob sync-create-remote --name "LLM Wiki"

# 连本地 wiki 目录和远程 vault
cd ~/wiki
ob sync-setup --vault "<vault-id>"
ob sync            # 手动首次同步
ob sync --continuous   # 前台持续同步（建议 systemd 后台跑）

systemd 单元文件（官方给出，直接抄，支持机器重启后自动跑）：

# ~/.config/systemd/user/obsidian-wiki-sync.service
[Unit]
Description=Obsidian LLM Wiki Sync
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/path/to/ob sync --continuous
WorkingDirectory=%h/wiki
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target

systemctl --user daemon-reload
systemctl --user enable --now obsidian-wiki-sync

# 允许用户登出后服务不停（关键！）
sudo loginctl enable-linger $USER

效果：Agent 在服务器往 ~/wiki 写文件 → 几秒内 Obsidian Sync 传到你的手机/桌面 Obsidian → Graph View 自动出现新节点。反过来也是同步的，你手动改了桌面端的页面，服务器端下次 ingest 时能看到最新内容。

官方 11 条 Pitfalls（每条对应一个真实踩坑）

直接抄文档，不翻译了，每一条在没有 SCHEMA 约束的知识库上都会中：

  1. Never modify files in raw/ — sources are immutable. Corrections go in wiki pages.
  2. Always orient first — read SCHEMA + index + recent log before any operation in a new session. Skipping this causes duplicates and missed cross-references.
  3. Always update index.md and log.md — skipping this makes the wiki degrade. These are the navigational backbone.
  4. Don't create pages for passing mentions — follow the Page Thresholds. A name appearing once in a footnote doesn't warrant an entity page.
  5. Don't create pages without cross-references — isolated pages are invisible. Every page must link to at least 2 other pages.
  6. Frontmatter is required — it enables search, filtering, and staleness detection.
  7. Tags must come from the taxonomy — freeform tags decay into noise. Add new tags to SCHEMA.md first, then use them.
  8. Keep pages scannable — a wiki page should be readable in 30 seconds. Split pages over 200 lines.
  9. Ask before mass-updating — if an ingest would touch 10+ existing pages, confirm the scope first.
  10. Rotate the log — when log.md exceeds 500 entries, rename it log-YYYY.md and start fresh.
  11. Handle contradictions explicitly — don't silently overwrite. Note both claims with dates, mark in frontmatter, flag for user review.

和两个相关方案的横向对比

维度 Hermes LLM-Wiki Skill WikiSkill (Google Research arXiv) llm-wiki-compiler (atomicmemory)
定位 人类+Agent 协作知识库 Agent Skill 自进化研究框架 CLI 批处理流水线编译器
Layer 3（顶层） SCHEMA.md（规约约束） Skills Layer（可执行 SKILL.md） 自动生成的页面（编译产物）
谁写 Layer 2 Agent（有严格的 Page Thresholds 和交叉链要求） Wiki Maintainer（从 traces 抽 patterns） Node.js CLI（规则驱动）
是否有验证门控 无（Lint 是审计不是回滚） Gating 验证集分数下降就回滚 Skill 无
是否可回滚 Layer 2 手动 Archive（不自动） Skill 可回滚；Wiki 不回滚 不可回滚（每次覆盖重编译）
适用规模 个人/团队 wiki（几百页量级） Agent 任务上 Skill 进化（几十到几百个 skill） 小语料（文档原话：tuned for small corpora）
Obsidian 原生 ✅ 目录就是 Vault + 无头同步方案 ❌ ✅ 兼容同一个 vault
可复现性 纯 Markdown，git 可追溯 依赖 Agent rollout 运行环境 CLI 可复现但需 Node.js 22+
当用户要什么选它 Agent-in-the-loop 日常维护 + 人工审校 Agent Skill 在 benchmark 上拿高分 纯批处理编译、无 Agent、定时 cron

落地实操：把 TheAIEra 项目改造成 LLM Wiki 架构要几步

看完想动手？给一份 TheAIEra 现有项目怎么对齐这个架构的实操清单，按重要性排序：

  1. 加 SCHEMA.md。domain: 中文 AI 技术与资讯（TheAIEra）。定义 15 个左右 tags（models/frameworks/tools/practices/companies/blogs/daily-news/open-source/benchmarks 之类），加 Conventions 里规定文件名 + frontmatter 格式。

  2. 建立 raw/ 三层：raw/articles/ 放原始网页抓取（写好 sha256 frontmatter 防漂移）、raw/papers/ 放 PDF、raw/transcripts/ 放 YouTube 或会议文字稿、raw/assets/ 放截图/图表。之前的文章都是跳过 raw 直接写成文的，这一步补一下。

  3. 加 index.md（已有博客列表可以先对应，但必须加"一行摘要 + 条目总数 + 最后更新日期"结构 + 分节字母序 + 至少 2 条 [[wikilink]] 交叉引用规则）。

  4. 写第一条 lint：启动 Hermes 或自己跑 11 条检查——重点先抓 ① 孤儿页（很多文章只被首页索引、从没被其他文章引用过 → 加交叉链）、② 断链、④ frontmatter、⑦ 单源 confidence 未设置、⑩ 标签自由。

  5. 建立 log.md：之前 git commit 已经是时间线，现在再加一个人类可读的追加式日志——## [日期] ingest | 条目名，附创建/更新的文件列表。

  6. 选一个观测端：
    - 方案 A：本地 Obsidian → 把 blogs/ 的根（或整个 theaiera 根）设为 vault，Dataview 做查询；
    - 方案 B：有服务器 → 装 obsidian-headless + systemd 单元，笔记本/手机 Obsidian 直接读同步。

  7. 日常 workflow 改成 ingest→query→lint：比如现在"写一篇 X 的深度解读"这个 workflow，先从 ingest X（把 X 的文档/代码/README/repo 存 raw/）开始，Agent 自动生成 entities/concepts/comparisons 的 Layer 2 页面，你审核和改后再生成完整博客。不要直接从"打开空白 .md 文件开始写"。

参考文档与链接

一个真实问题问你：你 Obsidian/Notion 里有多少"孤儿页"？多少"自由标签"？上次清理是什么时候？评论区晒晒数字，我先来：我的 Notion 之前是 60% 孤儿页、标签有 120 个……

作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

关注公众号，获取更多 AI 技术干货！

posted @ 2026-08-30 11:30  iTech  阅读(66)  评论(0)    收藏  举报