借助 Amazon Quick 构建 LLM Wiki 范式的云上知识库

📌 编者按与转载导读（dongVPS / 大七）：
– 原文出处：本文转载自 AWS 官方博客《借助 Amazon Quick 构建 LLM Wiki 范式的云上知识库》（作者：awschina）。特此鸣谢原作者与 Andrej Karpathy 提出的先驱性思考。
– 改进与修改说明：原文详尽拆解了 Karpathy 的 LLM Wiki 理论（先编译后查询、三层架构）在 Amazon Quick 商业客户端中的落地步骤。但在真实的极客自建与企业生产环境中，原文方案存在“写入放大导致 Token 成本暴增”、“商业桌面客户端强绑定”、“幻觉自循环回音壁”、“Lint 体检只查不改带来治理疲劳”、以及“缺失面向最终对外交付物闭环”等 5 项工程硬伤。
– 对比查阅建议：为了方便读者对比查阅，本文完整保留了 AWS 官方原文的技术实操与 12 张原版架构截图，并在文末独家附上了 【第十章：dongVPS深度评析与 5 大工程改良方案】。建议读者对照阅读，取其精华，规避其落地盲区。

---

摘要：本文介绍如何在 Amazon Quick 桌面端落地 Karpathy 提出的 LLM Wiki 范式，借助内置索引、知识图谱和 MCP，实践 LLM wiki 的摄入，查询和检查三个操作。

目录：
– 01 一、概述
– 1.1 三层架构
– 1.2 三个操作
– 02 二、解决方案
– 03 三、方案需求
– 04 四、方案搭建过程
– 4.1 Step 1：搭建 LLM Wiki 骨架
– 4.2 Step 2：注册文件夹并开索引
– 4.3 Step 3：安装 wiki-inspect MCP
– 4.4 Step 4：创建 Quick Agent
– 05 五、在 Quick 中实测 LLM Wiki 的三个操作
– 5.1 操作 1：Ingest 素材摄取
– 5.2 操作 2：Query 检索内容
– 5.3 操作 3：Lint 体检
– 5.4 交给定时任务
– 5.5 可视化你的 Wiki
– 06 六、清理
– 07 七、讨论
– 08 八、附：完整代码
– 09 九、参考
– 10 十、dongVPS深度评析：LLM Wiki 范式的 5 大工程盲区与进阶生产力改良方案（独家重磅）

---

一、概述

你是否遇到过这样的情况：把一堆 PDF、网页剪藏、会议纪要丢给 AI，它答得头头是道；可过了一周换个问法再问，它又从头把那堆文档翻一遍，给出的结论还和上次不太一样。上次让它花半小时理清的几份资料之间的关系，对话一关就没了。资料越攒越多，AI 却一点没「变懂」。

问题不在模型不够聪明，而在用法：大多数「让 AI 读文档」的方案都是 RAG —— 每次提问时临时检索几段原文、现场拼出答案。知识从不沉淀，每个问题都在从零推导；遇到需要综合五份资料的问题，它每次都得重新去找、重新去拼。

2026 年 4 月，Andrej Karpathy 在 GitHub Gist llm-wiki 里提出了另一种做法 —— LLM Wiki，核心是先编译，后查询：素材导入后 LLM 提前完成提取、整合、关联，产出一套互相链接的 markdown 维基，查询直接读它。新增资料时自动更新已有词条、标记冲突 —— 知识持续变厚，而不是每次从零推导。

1.1 三层架构

层	内容	所有权
原始资料	论文、网页、笔记等源文件	人写，LLM 只读、绝不改动 —— 保障溯源真实性
Wiki	实体页、概念页、综述页，靠 [[双链]] 织成知识网；配 index.md 目录和 log.md 变更日志	LLM 完全拥有
Schema	LLM 的工作手册：页面格式、引用规范、矛盾处理逻辑	人机共同演进

第三层是关键 —— 它把通用聊天机器人约束成专业的知识库维护者。

1.2 三个操作

• 
  

  Ingest —— 灌素材。读内容、产出摘要、同步更新全部关联词条。一份文档往往触发十余个页面的修改

  
  
• 
  

  Query —— 检索 Wiki 页面生成回答。优质结论可以直接写回知识库，把对话产出固化为知识

  
  
• 
  

  Lint —— 定期体检。排查内容矛盾、过时论断、孤立页面，挖掘信息缺口

  
  

模式很清晰，但落地要凑齐语义检索、图遍历、写入、定时维护 —— 社区实现大多是一套本地栈：编辑器 + 插件 + embedding 运行时 + 两份索引 + 一个服务层。

LLM Wiki 组件	自建	Amazon Quick
编辑与看图	Obsidian + 若干插件（Templater、Dataview…）	不需要（在对话里读写）
全文检索 + 语义检索	自建 FTS 索引 + Ollama 常驻 + embedding 模型 + 向量索引	注册文件夹时打开 Indexing 开关
实体与关系抽取	自己解析、自己维护一张图	wiki/ 的 Always remember 开关自动抽取实体 + agent 用 kg_* 工具补精确双链
写入	一个 MCP server 把 vault 暴露给 agent	file_write
调度	cron / launchd	定时任务（只跑 Lint）

本篇文章介绍如何在 Amazon Quick 桌面端搭建 LLM Wiki 的架构，并演示 Ingest、Query 和 Lint 三个操作。

二、解决方案

整体方案需要三个组件：你的 Wiki 文件夹，Amazon Quick 桌面端以及 MCP 用于 LLM wiki 系统的相关管理.

📷 图 1：整体架构

五条主流程：① Quick 扫描两个索引单元 → ② 建全文和向量索引 → ③ 供内置工具检索 → ④ agent 调用工具 → ⑤ file_write 写回 wiki/（写页 → 灌边 → 触发索引）。

检索和图谱能力全是 Quick 自带的，注册文件夹时打开 Indexing 下的开关就有了 —— 本地不用部署向量数据库，也没有 embedding 服务要常驻。

三、方案需求

• 
  

  Amazon Quick 桌面端 Professional 或 Enterprise 版本

  
  
• 
  

  本文用到的骨架、MCP 和提示词都在 aws-samples/sample-llm-wiki-on-quick，先取下来：

  
  

git clone https://github.com/aws-samples/sample-llm-wiki-on-quick.git
cd sample-llm-wiki-on-quick

四、方案搭建过程

4.1 Step 1：搭建 LLM Wiki 骨架

Karpathy 的原文把 wiki 分成三层，每层所有权不同：

• 
  

  Raw sources（raw/） —— 你收集的原始素材。不可变 —— LLM 只读，永不修改。这是 source of truth。

  
  
• 
  

  The wiki（wiki/） —— LLM 生成的 markdown 目录。它完全拥有这一层：创建页面、素材到来时更新、维护交叉引用、保持一致。你读它，LLM 写它。

  
  
• 
  

  The schema —— 一份文件（原文用的是 CLAUDE.md / AGENTS.md）告诉 LLM wiki 怎么组织、有哪些约定、每个操作该走什么流程。这是关键的配置文件 —— 它让 LLM 成为一个有纪律的 wiki 维护者，而不是通用聊天机器人。

  
  

wiki/ 里有两个特殊文件：

• 
  

  index.md —— 面向内容。整个 wiki 的目录，每页一行含链接和一句摘要，按类别分组。每次 ingest 都更新；回答问题时先读它定位相关页。

  
  
• 
  

  log.md —— 面向时间。只追加，每条以固定前缀开头（## [2026-04-02] ingest | Article Title），于是 grep “^## [” log.md | tail -5 就能看最近五条。

  
  

先在本地建好存放 Wiki 的目录（例如 ~/Wiki-Vault/），然后把仓库里的骨架复制过去 —— scaffold/ 就是按上面这份规格建好的，AGENTS.md、index.md、log.md 都已经写好内容：

cp -R scaffold/ ~/Wiki-Vault/

具体文件结构如下：

Wiki-Vault/
├── AGENTS.md              ← schema 层：约定 + 三个操作的流程
├── raw/                   ← 不可变素材
│   ├── articles/          ← 网页剪藏
│   ├── papers/            ← 论文长文
│   └── assets/            ← 素材里的图片
└── wiki/                  ← LLM 拥有
    ├── index.md           ← 内容目录（空表格骨架，按类别分组）
    ├── log.md             ← 操作日志（含 grep 用法说明）
    ├── concepts/          ← 抽象：模式、协议、方法、术语
    ├── entities/          ← 具体：产品、服务、人、工具
    ├── sources/           ← 素材摘要页
    └── synthesis/         ← 解读、对比、问答归档

这就是 Karpathy 原文的布局 —— index.md / log.md 摆在 wiki/ 根下，四类页面平铺。不需要为 Quick 做任何目录层面的妥协。

4.2 Step 2：注册文件夹并开索引

在 Quick 的 My Computer → Local folders 下把 vault 加进来。分开注册三个文件夹（每行一次 Add folder）：

#	注册的目录	Agent access	Allow full file context	Always remember
1	~/Wiki-Vault	✓	✗	✗
2	~/Wiki-Vault/raw	✓	✓	✗
3	~/Wiki-Vault/wiki	✓	✓	✓

Indexing 的两个开关，各管一件事：

开关	管什么	本方案
Allow full file context for enhanced searching	文件上传 + 建关键词索引和语义索引	开
Always remember file information	从正文自动抽取实体和关系进知识图谱	只在 wiki/ 开

注册顺序：先加根（不开索引）→ 再加 raw 和 wiki。反过来会被拒，可以在文件夹设置有 File extensions 和 Exclude patterns 可以限制范围。

最终添加后的效果如下:

📷 图 2：文件夹注册完成后的状态

4.3 Step 3：安装 wiki-inspect MCP

给 agent 补三个只读的校验工具，Lint 时用。它们只解析 ~/Wiki-Vault 下的 .md 文件，不读 Quick 的任何数据库。

工具	作用
wiki_lint()	一次扫完 8 项：死链、孤儿页、frontmatter 缺失、index.md 是否和实际文件对得上、type 有没有放错目录、索引时效、缺页候选、枢纽分布
wiki_edges(page=None, for_kg=False)	准确的双链关系。for_kg=True（不带 page）直接给可灌边的结构
wiki_hubs()	哪些页是枢纽、哪些页没人引用，整体是网状还是星形

① 拷贝 MCP 目录

mkdir -p ~/.quickwork/mcp-servers
cp -R mcp/wiki-inspect ~/.quickwork/mcp-servers/

② 注册到 Quick

导入 ~/.quickwork/mcp-servers/wiki-inspect/import-wiki-inspect.json，或直接编辑 ~/.quickwork/profiles/<你的-profile>/mcp_config.json，在 mcpServers 里加一段：

"wiki-inspect": {
  "command": "uv",
  "args": ["run", "--with", "fastmcp", "python", "-c",
           "import os,runpy; runpy.run_path(os.path.expanduser(\"~/.quickwork/mcp-servers/wiki-inspect/server.py\"), run_name=\"__main__\")"],
  "env": { "UV_HTTP_TIMEOUT": "120" }
}

📷 图 3：添加 wiki-inspect MCP

③ 重启 Quick

重启后在 Settings → MCP 里应该能看到 wiki-inspect、状态正常 —— 工具本身留到下一步建完 agent 再跑。工具说明和安全边界见仓库里的 mcp/wiki-inspect/README.md。

4.4 Step 4：创建 Quick Agent

在 Quick 的对话界面用自然语言建一个专门维护 LLM Wiki 的 agent：

建一个 agent，名字叫「LLM Wiki Agent」。

描述：维护 ~/Wiki-Vault 这个 LLM Wiki —— 消化素材、回答问题、做体检。

instructions 用 ~/Wiki-Vault/AGENTS.md 的全文，原样放进去，不要改写、不要精简。

welcome_message：
我维护 ~/Wiki-Vault。把素材放进 raw/ 让我 ingest，或者直接问我 wiki 里有什么。

starter_prompts：
自动 ingest raw/ 里的新素材
wiki 里都有什么
做一次体检（lint）

它能直接读到 AGENTS.md 创建完成后 Quick 会直接问你是否 Publish 并用这个 agent 开始对话。

📷 图 4：创建 LLM Wiki Agent

MCP 在上一步已装好，所以建完可以立刻验证整条链路：

跑一次 wiki_lint

环境到此就绪。 下面在 Quick 里跑三个操作。

五、在 Quick 中实测 LLM Wiki 的三个操作

5.1 操作 1：Ingest 素材摄取

灌入四份素材，都是官方原文下载：

素材	大小	来源
Karpathy 的 llm-wiki gist	12 KB	gist 原文
AWS Agent Registry GA 公告	35 KB	AWS 官方博客
MCP 规范 2026-07-28	50 KB	github.com/modelcontextprotocol/modelcontextprotocol
A2A 规范（节选）	42 KB	github.com/a2aproject/A2A

放进 raw/articles/，然后：

ingest raw/articles/llm-wiki-karpathy.md

它会先停下来讨论要点和建页计划（唯一保留的「必须问」环节），确认后一口气做完：写摘要页 → 建 concept/entity 页 → 解读进 synthesis/ → 更新 index.md → 追加 log.md → 灌边 → 触发索引。

📷 图 5：Ingest 前的要点与建页计划

📷 图 6：Ingest 执行结果

第二份起可以用自动模式跳过讨论：

自动 ingest raw/articles/aws-agent-registry.md

📷 图 7：自动模式 Ingest

5.2 操作 2：Query 检索内容

5.2.1 关键词检索

精确术语、关键字、[[链接]] 这类直接命中的文本走关键词索引：

MCP 的主要功能是什么?

📷 图 8：Query 回答与引用

可以看到它直接检索已有知识库找出对应内容，并给出引用的文件位置。

5.2.2 语义检索

口语提问、和页面用词不重叠的走这类查询：

一个 agent 想让另一个 agent 帮它干活，怎么找到对方？

📷 图 9：语义检索定位

它定位到 Agent Card 页，给出三种发现机制（Well-Known URI / Registries / Direct Configuration）、supportedInterfaces 传输协商、JWS 签名验真。

引文可追溯到官方原文 —— 用 grep -F 核对过：

细节	wiki 页	A2A 官方规范
.well-known/agent-card.json	✅	✅
supportedInterfaces	✅	✅
JWS / RFC 7515	✅	✅

MUST / SHOULD / MAY 的用法也可以使用。

5.2.3 归档判断

问「MCP 和 A2A 分别解决什么问题」Agent 会回答：

因为这一问正好是那页已覆盖的内容，我没有新建归档页。

而第四轮 ingest 时它主动写了 synthesis。同一条规则（复述不归档、跨页综合才归档）两种相反结论，都对。

📷 图 10：归档判断

5.3 操作 3：Lint 体检

在 agent 里直接让它跑一次 Lint：

📷 图 11：Lint 体检报告

报告分两部分：wiki_lint 扫出来的 8 项（文件层，确定性的），加上 agent 自己读页面判断的 4 项 —— 矛盾、过期声明、缺交叉引用、数据缺口。图谱层（实体在图谱里齐不齐、边有没有灌进去）它会用 kg_search 抽查，那部分在云端，本机的校验工具看不到。

⚠️ 如果 Lint 提示索引时效或过期，重启 Quick，或者直接跟 agent 说「触发 ~/Wiki-Vault/wiki 的重新索引」。

5.4 交给定时任务

三个操作里，定期要做的只有 Lint。另外几件维护的事，Quick 已经自动做了：

事情	谁来做	要不要定时任务
重新索引	Quick 按 Scan interval（默认 30 分钟）自己扫描，写完页最迟半小时进索引	❌ 不需要。想马上生效就在对话里说一句
图谱抽取	wiki/ 开了 Always remember，抽取器随扫描自动跑	❌ 不需要
灌 [[双链]] 边	Ingest 写完页立刻灌，schema 要求两步连做	❌ 不需要。偶尔漏灌由 Lint 查出来
体检（Lint）	定时任务	✅ 唯一的定时任务

定时 Lint 只查不改：查文件层、漏灌的边、抽取偏差、索引时效，最后按发现列出可选操作（补边、更新索引、修抽取偏差等），你回复编号，agent 在对话里执行。

在 Quick 里新建一个定时任务：每天跑一次，agent 选 LLM Wiki Agent，挂载 wiki-inspect，prompt 如下：

每天对 ~/Wiki-Vault 做一次体检。只查不改，跳过语义判断。
任一工具不可用，在报告里写该项「未检查」，继续下一步，不要自己写代码代替。

1. 跑 wiki_lint(brief=True)。
2. 用 wiki_edges(for_kg=True) 取边集，对 pages 逐个 kg_search 拿 node_id，数出文件里有、图谱里没有的边。只数不灌。
3. 随机抽 3~5 个页名 kg_search，核对名字、category、summary 与文件名和 frontmatter 是否一致，查四类之外的碎片节点。
4. 用 wiki_lint #10 的 raw/、wiki/ 最新 mtime（epoch）对比 file_rag_status 的 rag_index_time。

用 update_feed 发报告，每项写具体页面名。全绿只写「无问题」。
有问题时，末尾只列有发现的项：
[1] 补边 [2] 更新索引 [3] 修抽取偏差 [4] 完整体检 [5] 处理缺页候选

偶尔想做一次含语义判断（矛盾、过期声明、缺交叉引用、数据缺口）的完整体检，在对话里说一句「对 ~/Wiki-Vault 做一次完整体检」就行。

5.5 可视化你的 Wiki

Quick 的 My Context 功能可以直观地以知识图谱形式查看当前 wiki 里的对象。

📷 图 12：My Context 知识图谱

右边的功能按钮里有 Summarize、Ask 等，可以针对某个概念或实体进一步分析提问。

这个面板要给 wiki/ 打开 Always remember file information 才会出图。图里有两类内容：抽取器从 wiki 页正文里自动挖出的实体、术语和关系，以及 agent 用 kg_add 显式灌进去的 [[双链]] 边 —— 前者覆盖面广但不保证遵守 schema，后者和文件一一对应。

六、清理

清理方案只需要, Connectors → 移除文件夹；停掉定时任务 → Mission Control → 关掉 schedule。你的 markdown 不受影响 ——Amazon Quick 全程只读写文件内容本身，索引和图谱都存在别处。

云端那份副本：删本地文件会同步删云端的对应文件；移除整个文件夹注册后，可以点设置里那条 companion space 的链接进去确认 Space 状态。

七、讨论

回到开头的问题：资料越攒越多，AI 却不见长进。换成 LLM Wiki 之后，每读一份素材，它都把要点写进 wiki、和已有内容连起来；下次再问，读的是整理好的知识，而不是从头翻原文。知识会沉淀，越用越懂。

在 Amazon Quick 上搭这套方案，比自己拼一套本地工具简单得多：

• 检索和图谱不用自建：注册文件夹、打开两个开关，全文检索、语义检索、知识图谱就都有了。

• 规则写清楚，agent 就靠谱：AGENTS.md 里写明摘要和解读分开、每次更新目录和日志，它就照做。

• 语义检索很关键：日常提问的用词和页面里的写法常常对不上，靠关键词找不到，靠语义能找到。

• 精确的事交给代码：双链关系由 agent 显式写进图谱，死链、孤儿页这类检查交给 MCP 工具，不指望模型自觉。

• 维护基本自动：索引和抽取 Quick 自己跑，每天一个定时体检，发现问题你回个编号就能修。

  
  

八、附：完整代码

本文用到的代码和提示词都在 aws-samples/sample-llm-wiki-on-quick：

目录	内容
scaffold/	目录骨架 + AGENTS.md（schema 层），cp -R 到 ~/Wiki-Vault/ 就能用
mcp/wiki-inspect/	只读校验 MCP：3 个工具、安装说明
prompts.md	本文用到的全部提示词：建 agent、Ingest、Query、Lint、定时任务
SECURITY.md	动手前必读：风险链路 + 四条控制建议

---

十、dongVPS深度评析：LLM Wiki 范式的 5 大工程盲区与进阶生产力改良方案

💡 dongVPS 技术观察室导读：
AWS 这篇文章将 Andrej Karpathy 提出的 LLM Wiki（先编译后查询、知识持续沉淀） 落地拆解得非常清晰，但在工程实战、成本控制与知识纯度治理层面，若直接照搬官方思路，在严肃的团队生产或个人高频写作环境中极易踩坑。结合我们在多智能体编排与内容工业化流水线中的实战经验，我们对该方案提出以下 5 大核心盲区剖析与改良方案：

1. 致命的“写入放大（Write Amplification）”与 Token 成本雪崩

• 原文字面逻辑：“一份文档往往触发十余个页面的修改”。在官方演示的小玩具 Demo 里（只丢入 3~4 份十几 KB 的短文），这种全量漫游修改显得十分智能。
• 实战工程痛点：在真实的生产场景中，如果你连续导入几十篇技术研报、代码规约或系列文献：
• 每摄入 1 篇文档，LLM 就被要求去遍历并重写 10~15 个已有的维基实体页；
• 这种 写入放大率高达 10x ~ 20x，会导致 API 调用次数和 Token 消耗呈二次方指数级膨胀，摄入耗时从几秒拉长到几十分钟，调用账单迅速失控。
• 东VPS 改良方案：
• 引入 “增量聚合缓冲区（Batching & Staging）”。新素材先进入暂存队列，积攒到一定批次后，由 Agent 进行一次性聚类合并与批量更新，而不是“每扔一篇碎片小文章就漫山遍野地全库翻修一遍”。

2. 商业公关倾向与工具强绑定（Vendor Lock-in）

• 原文字面逻辑：作为 AWS 官方推广文章，作者的核心潜台词是：“Obsidian 插件生态太重，自建 FTS 和向量太复杂，用我们付费的 Amazon Quick 桌面端开箱即用”。
• 实战工程痛点：深度依赖特定的闭源商业桌面客户端，意味着你的知识库被锁定在单一供应商的环境中，丧失了跨平台协同、CI/CD 自动化流水线集成以及无头（Headless）服务器端自主运行的灵活性。
• 东VPS 改良方案：
• 范式与工具彻底解耦：底层坚持采用 纯 Git 版本控制 + 本地标准 Markdown 文件树 + 开放 MCP 协议。无需依赖 Amazon Quick，无论是 Antigravity、Claude Code、Cursor 还是终端命令行脚本，都能通过标准工具调用这套 Wiki 结构，零成本、零锁定、永久可控。

3. 缺乏防御机制的“幻觉自循环回音壁（Hallucination Cascade）”

• 原文字面逻辑：原文默认“LLM 拥有 Wiki 目录的完全写权限，且每次提取都是客观准确的”。
• 实战工程痛点：大模型在多跳推理和关系抽取中存在固有的“幻觉漂移”。一旦 LLM 在 concepts/A.md 中提炼出一个细微的伪事实：
• 下一次 Ingest 新文档 B.md 检索关联到 A 时，LLM 会将 A 中的错误作为无可争辩的真理进行二次演绎；
• 这种 “幻觉自循环级联” 会像病毒一样在 [[双链]] 网络中蔓延，最终导致知识图谱的底层可信度全盘崩塌。
• 东VPS 改良方案：
• 强制反向溯源锚点：在 Schema 中加入强约束，Wiki 词条的每个关键论断必须附带对 raw/ 源文件的绝对行号或段落索引（如 <!-- src: raw/papers/xxx.pdf#L45 -->）；
• 高危实体变更的人工确认：核心实体与主时间线的大改，必须生成 Git Diff 让人类做轻量确认后才可并入主分支。

4. “只查不改”导致的治理疲劳（Linting Fatigue）

• 原文字面逻辑：文章指出定时任务“只查不改”，只列出死链和孤儿页，让人类在对话中回复编号让 Agent 处理。
• 实战工程痛点：当 Wiki 规模膨胀到数百甚至上千页时，每天定时任务抛出的数十条琐碎报错会迅速演变成“告警疲劳（Alert Fatigue）”，用户很快就会麻木并不再查看。
• 东VPS 改良方案：
• 问题分级治理架构：
  • 语法与机械性错误（如死链检测、孤立文件未进 index.md、缺失 frontmatter 标签）：由确定性的 Python 规则脚本秒级自动修复（Auto-healing），无需调用昂贵的 LLM；
  • 深层语义性矛盾（如跨文档事实冲突、年代对不上）：才过滤提炼为高优先级的“语义决策建议”，在交互会话中提示人类决策。

5. 缺乏面向“对外最终交付物”的生产流水线

• 原文字面逻辑：Karpathy 原文与 AWS 方案均偏向“个人被动第二大脑”，把维护一套结构工整的维基当成了系统运行的终点。
• 实战工程痛点：维基不应该是终点，维基只是高密度认知的“中间态资产”。如果只沉迷于整理维基而缺乏业务价值产出，系统就会沦为认知自嗨的“数字囤积狂”。
• 东VPS 改良方案：