爆火的洞察 —— 以及为什么它重要

Andrej Karpathy 的 LLM Wiki gist 本周刷屏了，理由很充分。他的核心洞察是：LLM 应该编译和维护一个结构化知识库，而不是每次对话都从零开始重新发现知识 —— 这是对当前大多数人使用 AI 方式的根本性转变。

我们一直在做的，就是这件事。KnowMine 是一个 AI 原生的个人知识库，已经上线数月，拥有 11 个 MCP 工具、pgvector 语义搜索和 SOUL 个性化层。当我们读到 Karpathy 的 gist 时，我们的第一反应不是"好主意"，而是"我们已经上线了，而且解决了他的方案无法解决的三个问题。"

这篇文章不是对 Karpathy 愿景的批评。它是一封致敬信 —— 外加我们构建云原生、MCP 优先实现的工程经验，让任何 AI Agent 都能开箱即用。

Karpathy 方案的天花板在哪里

规模瓶颈。 Karpathy 指出，在约 100 个信息源和几百页内容的规模下，一个索引文件就足够了 —— 不需要向量数据库。没错。但知识库会增长。当达到 500+ 条目且跨领域概念交叉时，关键词匹配和索引扫描就会失效。你需要语义相似度搜索。KnowMine 从第一天就使用 pgvector + text-embedding-3-small —— 每条知识保存时自动向量化，相关知识自动浮现。

本地锁定陷阱。 Karpathy 的方案需要本地 Agent（Claude Code、Codex）+ 本地 Obsidian。这意味着你的知识库被锁定在一台机器、一个会话中。KnowMine 将整个知识库暴露为远程 MCP 端点。任何兼容 MCP 的 Agent —— Claude Code、OpenCode、自定义 Agent —— 都可以从任何地方读写你的知识库。

人工驱动瓶颈。 在 Karpathy 的工作流中，你必须显式地"导入"信息源并"查询" Wiki。LLM 只在被提示时才行动。KnowMine 的 MCP 工具允许 AI Agent 在对话中主动保存知识 —— 我们称之为"对话式知识捕获"。你和 Claude 讨论某个话题，它会在不打断对话流的情况下为你存储洞察。

让这一切运转的架构

三层架构，同一哲学 —— 不同实现

层级	Karpathy 方案	KnowMine
原始信息源	本地 `raw/` 目录中的文件	通过 MCP `add_knowledge` 工具接入任何内容 —— 文本、URL、语音转写
知识库	LLM 编写的 Markdown 文件	pgvector 索引的条目，自动标签、自动归类、语义嵌入
规则/模式	`CLAUDE.md` / `AGENTS.md`	SOUL 画像（AI 生成的用户模型）+ 文件夹预设

MCP 的差异化

当 AI Agent 在对话中将知识存入 KnowMine 时，是这样的：

Tool: add_knowledge
Input: {
  "content": "Karpathy 的 LLM Wiki 模式验证了...",
  "type": "insight",
  "tags": ["competitive-analysis", "knowledge-management"]
}

不需要文件系统。不需要本地 Agent。不需要配置。知识即时向量化、标签化、可发现。

11 个 MCP 工具 —— 不止 CRUD

add_knowledge / update_knowledge / delete_knowledge —— 完整 CRUD
search_my_knowledge —— 跨所有条目的语义向量搜索
get_related_knowledge —— 发现知识之间的隐藏关联
save_memory / recall_memory —— 跨会话的持久化 AI 记忆
get_soul —— 获取 AI 生成的用户画像
get_insight —— AI 驱动的知识模式分析
list_folders —— 浏览知识组织结构

我们正在"偷"的 Karpathy 最佳创意

好创意就该大方承认。gist 中有几个概念确实精彩，我们正在融合它们：

Lint 操作。 定期对知识库进行 AI 健康检查 —— 发现矛盾、孤立条目、过期信息、缺失关联。KnowMine 的 get_insight 工具有这个雏形，但完整的"知识 Lint"功能已加入我们的 Roadmap。

"好答案变成新页面。" 这个反馈循环 —— 你的探索复利式地转化为持久知识 —— 正是 KnowMine 的 save_memory 和 add_knowledge 工具在对话中实现的模式。Karpathy 将它命名为"知识复利"，这个定义堪称完美。

用户可控的 Schema 层。 让用户定义知识的组织方式是一个强大的设计。这与我们计划中的文件夹预设功能高度吻合。

谁该用哪个方案

适合 Karpathy 方案的场景：

你是开发者，熟悉 Claude Code 或 Codex
你希望完全控制数据在本地
你喜欢 Obsidian 的图谱视图和插件生态
你的知识库是特定主题且规模适中（约 100 个信息源）

适合 KnowMine 的场景：

你希望 AI Agent 能远程读写你的知识库
你需要跨越增长中的知识库进行语义搜索
你想要零配置 —— 不需要本地 Agent，不需要文件管理
你跨多个 AI 工具工作，需要一个共享的知识层
你希望 AI 在对话中主动捕获知识

两者都用： 没有什么阻止你用 KnowMine 作为"编译后的知识层"，同时在本地 Obsidian 中保留原始信息源。MCP 是一个互操作标准 —— 这就是它的意义所在。

5 分钟上手

在 knowmine.ai 获取你的 MCP 密钥
将 MCP 端点添加到你的 Agent 配置：
```
knowmine.ai/api/mcp?key=YOUR_KEY
```
告诉你的 Agent："把这个洞察保存到我的知识库" —— 直接就能用。
语义搜索："我关于知识管理知道些什么？" —— 相关条目按语义而非关键词浮现。

Memex 的承诺，终于兑现

Karpathy 引用了 Vannevar Bush 1945 年的 Memex 愿景 —— 一个个人知识存储，其中文档之间的连接与文档本身同等重要。Bush 解决不了谁来维护它的问题。Karpathy 说 LLM 解决了这个问题。我们同意 —— 而且我们认为下一步是让这个被维护的知识库可以被你使用的每一个 AI Agent 从任何地方通过标准协议访问。

这就是 MCP 优先的含义。你的知识不应该被锁定在一个工具或一台机器里。它应该是一个任何 AI 都能调用的服务。

Karpathy 的 LLM Wiki 说对了 —— 当你把它做成云原生 + MCP 优先会怎样？