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

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

01一、概述

02二、解决方案

03三、方案需求

04四、方案搭建过程

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

06六、清理

07七、讨论

08八、附：完整代码

09九、参考

一、概述

你是否遇到过这样的情况：把一堆 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	动手前必读：风险链路 + 四条控制建议

九、参考

aws-samples/sample-llm-wiki-on-quick —— 本文的完整代码：目录骨架、wiki-inspect MCP、提示词
Andrej Karpathy, llm-wiki.md（2026-04-04）—— LLM Wiki 模式的原始定义
What is Amazon Quick?
Amazon Quick on desktop —— 桌面端官方文档
Connectors（桌面端） —— 本地文件夹注册与索引开关
Skills and agents（桌面端） —— agent 与定时任务

➡️ 下一步行动：

相关产品：

Amazon Quick — 人工智能助手，用于研究、业务洞察、自动化和无代码应用程序构建
Amazon Connect — AI 客户体验解决方案

相关文章：

立即咨询 → 从 AI 规划到落地实施，我们的专家团队为你全程护航。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用

亚马逊AWS官方博客