> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 用 myKG 构建 LLM Wiki
- URL: https://www.hubwiz.com/blog/build-an-llm-wiki-with-mykg/
- Published: 2026-06-06T04:19:00.000Z
- Updated: 2026-06-06T04:19:00.000Z
- Description: 如何将一个混合格式文档文件夹转化为一个有类型的、互联的知识图谱，让你的智能体可以实际阅读——使用myKG和Obsidian。
- Author: admin
- Tags: AGENT, LLM WIKI, #Import 2026-10-14 14:41

每个AI会话都从失忆开始。你给它提供上下文，它帮助你，对话结束——一切都蒸发了。下一次，你上传同一个PDF，重新解释同一个项目，重新介绍同样的人。模型永远不会*积累*。它回答然后遗忘。

Andrej Karpathy对这个问题的框架是一个**LLM wiki**：不是每次会话都注入一次性上下文，而是给模型一个持久的、精心策划的知识库，它可以阅读、增长并随着时间的推移建立——一个每天变得更聪明的**第二大脑**，而不是每次都重置为零。你的会议笔记、你的项目文档、你半成品的wiki页面，被提炼成AI可以实际驻留的东西。

但是一堆笔记不等于第二大脑，就像一盒收据不等于会计。要成为持久记忆，知识必须被**结构化**：谁与什么相关，以及如何。DB Migration依赖Secrets Service，Secrets Service由Platform团队拥有，三个工程师为迁移做出贡献——其中一人还在另外两个项目上工作。这不是相似的文本——它是一个*事实网络*。第二大脑的好坏取决于其页面之间的链接。

![LLM Wiki](https://www.hubwiz.com/blog/content/images/2026/06/1-YOCH0v6NuJ-Yd_j4gLfXsg.png)

本文构建那个结构。我们拿四个关于虚构公司的普通Markdown笔记，通过**myKG**（一个Markdown到知识图谱提取器）运行它们，得到一个**Obsidian vault**：每个实体一个Markdown笔记，每个都有类型化属性、类型化关系作为`[[wikilinks]]`、置信度分数和来源。那个vault*就是*LLM wiki——智能体就绪的记忆，人类仍然可以打开、阅读和编辑。

以下所有内容都是使用myKG和Obsidian的真实运行，基于Anthropic的`claude-sonnet-4-5`。

![](https://www.hubwiz.com/blog/content/images/2026/06/1-K3bVHhrzcCwVlyElR2bHNg.png)

## 1、什么是"LLM wiki"？

对于人类来说，wiki是一组页面，每个页面是一个主题，链接连接相关主题。你通过跟随链接导航，而不是全文搜索。链接携带含义。

**LLM wiki**是为机器消费构建的相同理念：

- **每个实体一个笔记。** 一个人、一个项目、一个产品——每个都有自己的页面。
- **类型化属性。** 不是散文；键/值事实（`title: Senior Software Engineer`）。
- **类型化关系。** 不只是"与...相关"；它们*如何*关联（`contributes_to`、`depends_on`、`uses_technology`），作为指向其他笔记的链接。
- **来源和置信度。** 每个事实记录它来自哪个来源以及提取器的置信度。

数字、模式和笔记直接从输出中复制——正如你将看到的，一个有能力的模型从四个短文件中推导出了一个令人惊讶地丰富的结构。

![](https://www.hubwiz.com/blog/content/images/2026/06/1-K7lGoQtd_iS-O-0jHJLw0A.png)

最后一个属性使它成为*智能体*记忆而不仅仅是一个图谱。智能体可以落在一个笔记上，读取一组紧凑的事实，并通过跟随类型化链接**遍历**到邻居——精确组装一个问题需要的邻域，并带有引用。知识在会话之间持久存在，链接使其可导航：模型像阅读wiki一样阅读它，而不是像浏览新上传的PDF那样略读。

## 2、为什么Obsidian是正确的基底

你可以将知识图谱输出为RDF、属性图或一堆JSON。myKG也会输出所有这些格式。但**Obsidian vault**是同时适合人类和智能体的格式：

- 一个`[[wikilink]]`*就是*一条图边。Obsidian的图视图免费渲染整个东西。
- 前置元数据（`type`、`id`、`sources`、`confidence`）是智能体可以解析的结构化元数据。
- 它是**纯Markdown** — 可diff、可git版本控制、可编辑。当模型弄错一个事实时，你修改一行文本，而不是数据库。
- 它是**可审计的**。人类可以打开vault查看智能体将看到的确切内容。

Vault是混乱的源笔记和消费它们的智能体之间的契约。

## 3、原材料

我们的输入是一些普通笔记——人类不假思索地写的那种。以下是每个的摘录（Demo文件在[这里](https://github.com/SenolIsci/mykg/tree/main/docs/examples/blog%5Fdemo%5Frun?ref=hubwiz.com)）。

**项目路线图：**

```
## DB Migration Project
数据库迁移项目旨在将Acme Corp的生产PostgreSQL集群
从本地硬件迁移到AWS Aurora。该项目由基础设施团队拥有，
由Bob Martinez在2026年1月的一次可靠性事件后发起。
Alice Chen和Carol Okafor是核心工程贡献者。
目标完成日期：2026年第三季度末。
该项目对Platform团队的新密钥管理服务有依赖。
当前状态：进行中。风险：中等。预算：$120,000。

```

**团队简介：**

```
Alice Chen是Acme Corp的高级软件工程师。她于2021年3月加入，
拥有MIT的计算机科学学士学位。Alice领导后端公会。
Bob Martinez是工程总监。Bob同时管理基础设施团队
和产品团队。他直接向CEO Sandra Kim汇报。

```

**合作伙伴和供应商笔记：**

```
DataSystems Inc是一家总部位于旧金山的数据基础设施公司。
Acme Corp于2025年9月与DataSystems签署战略合作伙伴关系，
共同开发文档索引基础设施。
HashiCorp提供Acme Corp的Platform团队在Secrets Service项目中
使用的Vault产品。Acme Corp持有于2026年第一季度签署的企业许可证。

```

**技术栈：**

```
Acme Corp目前在生产工作负载中使用本地PostgreSQL 15。
DB Migration项目正在将这些集群迁移到AWS Aurora（兼容PostgreSQL）。
CI/CD管道使用GitHub Actions。容器编排由Kubernetes（EKS）处理。
基础设施团队由Bob Martinez管理，拥有所有这些基础设施。

```

在这些笔记中，实体和关系是*隐含的*——"owned by"、"initiated by"、"leads"、"manages"、"reports to"、"signed a partnership with"、"moving to"——但没有任何东西被类型化、链接或可查询。注意同样的人跨文件重复出现：Bob Martinez出现在路线图、团队介绍*和*技术栈中。将这些提及拼接成一个连贯的图景正是我们要交给myKG完成的工作。

![](https://www.hubwiz.com/blog/content/images/2026/06/1-vKnsX0EbilCBSCmFKGSQkA.png)

## 4、myKG如何构建图谱

myKG运行一个多步管道。两步调用LLM；其余是确定性的。

**Pass 1 — 模式归纳。** 与其强制将笔记放入固定本体，myKG读取它们并*提出*一个。在我们的运行中，它归纳了**9个概念**和16种关系类型，然后在提取任何内容之前对模式进行了协调通过和质量审查通过。

有趣的部分是它*无提示地*构建的*层次结构*。它不只是列出扁平类型——它发现了一个**is-a分类体系**：`Company`是`Organization`的子类型；`Employee`是`Person`的子类型；`Product`是`Technology`的子类型。每个子类型获得父类型没有的属性——`Company`有`annual_spend`，`Employee`有`title`和`join_date`，而临时提到的普通`Person`两者都没有。没有人指定过这些。模型看到了散文中的区别并对它们进行了建模。

**Pass 2 — 实例提取。** 模式固定后，myKG回到每个文件并提取*实例*：实际的人、项目和边，每个都根据模式验证并标记置信度分数。

**规范化、组装、去重。** 在多个文件中提到的同一实体折叠为一个节点；同一条边折叠为一条边；分配稳定ID。在我们的运行中，规范化器映射了**8个别名**，并将18个节点和17条边合并为一个干净的集合。

**孤儿连接。** 有时Pass 2会产生一个*孤儿*：模型提取但无法自信地连接到任何东西的节点。myKG运行一个专用pass，尝试通过让模型确认候选边来重新连接孤儿——关键是，它**拒绝捏造**它无法证明的连接。无法根基的边被省略而不是幻觉，所以即使模型不确定，图谱也保持可信。

**输出。** 最后myKG以你可能需要的每种格式写入图谱——RDF/Turtle、八种NetworkX导出（GraphML、GEXF、GML…）、JSONL节点和边，以及**Obsidian vault**。整个运行花了**2分7秒**，跨越10次LLM调用。此工作示例的Demo文件在[这里](https://github.com/SenolIsci/mykg/tree/main/docs/examples/blog%5Fdemo%5Frun?ref=hubwiz.com)。

它确定的模式片段：

```
Person   —[ works_at ]→         Organization
Person   —[ contributes_to ]→   Project
Person   —[ manages ]→          Team
Person   —[ reports_to ]→       Person
Person   —[ co_founded ]→       Organization
Project  —[ uses_technology ]→  Technology
Project  —[ depends_on ]→       Project
Organization —[ has_partnership ]→ Organization
Organization —[ vendor_for ]→   Organization
Organization —[ provides ]→     Product

```

## 5、自己运行

三条命令，从头到尾——安装它，创建配置，运行它：

```
pip install mykg                          # 1. 安装
mykg init --profile anthropic-claude      # 2. 写入 mykg_config.yaml（+提示输入你的key）
mykg extract-graph ./notes --obsidian-vault   # 3. 从笔记文件夹构建wiki

```

这就是整个循环。其余部分拆解步骤2——选择后端和放入key——以及步骤3的输出。

myKG持有自包含的**配置文件**——每个LLM后端一个。通过更改一行切换后端：

```
profile: anthropic-claude   # 或: openai | openrouter-free | ollama-local | claude-cli

```

每个配置固定一个提供商、一个模型和完整的token预算。几个值得注意的：

- `anthropic-claude` — 本次运行使用的（`claude-sonnet-4-5`）。快速，归纳的模式出来干净且类型丰富——上面的工作示例就是它的输出。
- `openai` — 另一个前沿API，质量相当。
- `openrouter-free` — 路由到免费层模型。更慢，较弱的模型产生较粗糙的图谱，但证明了该方法端到端零花费是可行的。
- `ollama-local` — 通过Ollama完全本地运行。没有数据离开你的机器。
- `claude-cli` — 通过你的本地`claude` CLI运行提取（`claude -p`）。

这里Claude本身是提取引擎。

在`.env.mykg`中放入你的key：

```
ANTHROPIC_API_KEY=sk-ant-...

```

然后是从快速入门的第3步：将`extract-graph`指向一个Markdown文件夹，请求vault，然后等待。你会得到图谱、Obsidian vault和一个纯英文报告，描述运行做了什么——它归纳了什么模式、合并了什么、什么无法连接。

## 6、第二大脑必须是活的

一次性提取是一个快照。第二大脑是你持续维护的东西——它随着你的成长而增长，你喂给它越多它就越敏锐。这就是myKG获得"活知识图谱"标签的地方，几个特性将单次运行变成一个不断演进的wiki。

**新文件直接融入。** 你的笔记不会停止到达。使用`--append`运行，myKG**完全跳过模式归纳，只重新提取新的或修改的文件**，将它们的实体和边折叠到现有图谱中，而不是从头重建。把下周的会议笔记放到文件夹中，重新运行，wiki吸收它们——新人链接到现有项目，新项目附着到现有团队。Vault保持最新而无需重新开始。

**一旦有了词汇表就锁定它。** 归纳的模式对发现很棒，但一旦你了解了你的领域，你会希望每次运行都保持一致性。传递`--base-schema`一个固定的本体（作为TTL文件），它就变成权威的：**LLM可以*扩展*它但不能重命名或与之矛盾。** 你的`Person`、`Project`和`Team`类型——以及它们之间的边——在运行#1和运行#50中含义相同。这种稳定性让图谱能够积累而不是漂移。

**教它你的同义词。** 单靠字符串匹配不会知道"K8s"、"Kubernetes"和"EKS"是同一个东西，或者"Acme Corp"和"Acme Corporation"是同一家公司。myKG的**名称规范化**已经将明显的别名折叠到一个规范节点，对于真正的领域词汇，你可以传递一个`--thesaurus`——一个标准的[SKOS](https://www.w3.org/2004/02/skos/?ref=hubwiz.com)文件——用于**超越字符串匹配的同义词意识**。结果是更干净、更连接的图谱：更少的重复节点，更少的孤儿，一个每次你完善同义词表都会变得更好的更紧凑的受控词汇表。

**将两个大脑合并为一个。** 从工程文档构建了一个图谱，又从销售笔记构建了另一个？`mykg merge-graphs`**将两个独立构建的会话组合成一个统一的图谱，具有完整的来源**——这样你可以并行增长专门的wiki，然后稍后将它们缝合在一起。

## 7、输出是什么：LLM wiki

Vault是每个概念类型一个文件夹，每个实体一个笔记，加上一个`index.md`。以下是myKG为**DB Migration Project**生成的笔记——逐字的，就是我们开头看到的松散文形式的项目：

```
---
confidence: 0.975
id: project-db-migration-project
sources:
- projects.md
- partners.md
- technologies.md
type: Project
---
# DB Migration Project

## 属性
- **status**: in progress (1.0)
- **target_completion_date**: end of Q3 2026 (1.0)
- **budget**: $120,000 (1.0)

## 关系
### 出站
- [[Platform Secrets Service]] - depends_on (1.0)
- [[PostgreSQL]] - uses_technology (0.95)
- [[AWS Aurora]] - uses_technology (0.98)
- [[AWS]] - uses_technology (0.85)
- [[Kubernetes]] - uses_technology (0.65)
### 入站
- [[Infrastructure Team]] - owns (1.0)
- [[Bob Martinez]] - leads (0.9)
- [[Alice Chen]] - contributes_to (1.0)
- [[Carol Okafor]] - contributes_to (1.0)

```

那一整段文字现在变成了一个节点。"由基础设施团队拥有"、"由Bob Martinez发起"、"核心工程贡献者"、"对密钥管理服务的依赖"、"将这些集群迁移到AWS Aurora"——每一个都变成了类型化的、有分数的边。属性是干净的键/值；每个关系都是一个你可以跟随的真实`[[wikilink]]`。注意置信度在做实际工作：到`Kubernetes`的`uses_technology`边只有`0.65`——模型*不太确定*那个细节属于这里，它这样说，而不是断言。

跟随任何链接，图谱继续延伸。`[[Alice Chen]]`是她自己的笔记——属性（title、email、`BSc in Computer Science from MIT`、2021年3月加入）加上她自己的出站边：`works_at → Acme Corp`、`contributes_to → DB Migration Project`*和*`RAG Pipeline Project`、`manages → Backend Engineering Guild`。`[[Platform Secrets Service]]`列出*它的*所有者和依赖。你落地的笔记永远不是死胡同；它是其邻域的索引。

![](https://www.hubwiz.com/blog/content/images/2026/06/1-ObnLoRJy4AORZvsBxhPfFw.png)

## 8、为什么这是好的智能体记忆

站在智能体的角度，回答"谁在做DB迁移，它依赖什么，谁在做那个依赖？"

使用LLM wiki，检索是一个**图遍历**：

1. 解析种子实体 → `DB Migration Project`。
2. 读取它的笔记：`contributes_to ← Alice Chen, Carol Okafor`和`leads ← Bob Martinez`（入站），`depends_on → Platform Secrets Service`（出站）。
3. 跟着`[[Platform Secrets Service]]`跳一步——它的笔记列出`James Whitfield`为贡献者和它自己的上游依赖。
4. 将该邻域作为有根据的上下文交给模型。

智能体得到一个**精确的、有引用的子图**。关系是显式的，所以模型基于事实推理而不是重新推导。而且因为同样的`nodes.jsonl` / `edges.jsonl`支持vault，这个遍历只需要几行代码，可以在JSONL或`[[wikilinks]]`上进行。（向量搜索仍然有助于*第一跳*——模糊匹配问题到种子节点——但一旦你在图上，你就遍历。）

置信度和来源贯穿整个过程。可以告诉智能体信任0.9以上的边，将较低分数的视为需要验证的线索，人类审计员可以将任何声明追溯到源文件。

## 9、结束语

我们从人类随手写的四个笔记开始，最终得到了一个50节点、79边的知识图谱，呈现为Obsidian vault——类型化、链接、有分数、有来源。

那个vault是交给你的智能体的东西——一个**它们可以像你一样阅读的wiki**。你现在就可以在Obsidian中打开它，点击你的智能体将遍历的同一个图谱。

将`mykg extract-graph`指向你自己的笔记，看看你的知识归纳出什么本体——然后锁定模式，教它你的同义词，并在新笔记到达时使用`--append`来增长它成为一个活的第二大脑。

---

原文链接：[Build an LLM Wiki for Your AI Agents](https://medium.com/@senol.isci/build-an-llm-wiki-for-your-ai-agents-b993af38d7c4?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处