Karpathy LLM Wiki 实战落地：用 OpenClaw 多 Agent 做了三个关键升级

做技术的人，知识焦虑是常态。论文要看、方案要写、算法要调、客户要跟、政策要学。每件事都重要，但串起来就是一团乱麻。文件夹分类——建了一套"客户/技术/政策/产品"的目录，每次新笔记都面临灵魂拷问：这算技术还是产品？最后堆在"杂项"里吃灰。RAG——向量数据库 + Embedding API + LangChain，花了两周搭好，每次回答都是碎片拼凑，没有上下文，没有逻辑关联。更致命的是：RAG不积

头帕王子

535人浏览 · 2026-04-08 09:17:21

头帕王子 · 2026-04-08 09:17:21 发布

Karpathy LLM Wiki 实战落地：用 OpenClaw 多 Agent 做了三个关键升级

10年工业视觉老兵，一人创业中。用OpenClaw搭了一套AI公司的操作系统——多Agent协作开发、自动化工作流、智能获客。技术+踩坑+创业，都写。

在这里插入图片描述

前言：一个困扰了所有工程师的问题

做技术的人，知识焦虑是常态。

论文要看、方案要写、算法要调、客户要跟、政策要学。每件事都重要，但串起来就是一团乱麻。

我试过很多办法：

文件夹分类——建了一套"客户/技术/政策/产品"的目录，每次新笔记都面临灵魂拷问：这算技术还是产品？最后堆在"杂项"里吃灰。

RAG——向量数据库 + Embedding API + LangChain，花了两周搭好，每次回答都是碎片拼凑，没有上下文，没有逻辑关联。更致命的是：RAG不积累知识，今天问完明天还是从零开始。

直到2026年4月初，Karpathy（OpenAI联合创始人）发布了他用LLM管理个人知识库的方法，叫LLM Wiki。全网讨论量爆炸，三天内GitHub相关项目star飙升。

我花了三个月落地这套方案，踩了三个坑。这篇文章，说说我的真实体验。

一、LLM Wiki 的核心：把知识当代码一样"编译"

Karpathy的方案核心很简单：三层分离。

raw/       → 原始资料（PDF、论文、截图、聊天记录），只读
    ↓
wiki/      → AI编译产物（结构化Markdown，带交叉引用），活的
    ↓
CLAUDE.md  → Schema规则（页面格式、更新逻辑），给AI的方向

和RAG的根本区别在于：

RAG	LLM Wiki
每次查询从零检索，用完即弃	知识持续累积，越用越厚
回答是"检索片段的拼凑"	回答是"基于已有知识的推理"
AI不知道你已有知识的边界	AI知道你的知识边界在哪里
需要向量数据库+Embedding	纯Markdown，零基础设施

一个例子说明差别：

问RAG：“这个客户最近跟进得怎么样了？”
RAG答：找到三条记录，分别是1月、2月、3月的需求描述。

问LLM Wiki同一问题：
LLM Wiki答：该客户是某行业头部企业技术负责人，1月主动询问过相关需求，3月因在外出差暂缓沟通，当前优先级高，切入点建议以某某竞品失败案例重新提案。

差别不是"快慢"，是"有没有真正理解"。

二、三个核心操作

LLM Wiki只有三个操作，没有复杂界面。

2.1 灌入（Ingest）

把新资料扔进raw/，给AI一个指令：“处理这个文件，更新相关页面，标注矛盾点。”

AI自动执行：

提取关键信息
更新wiki/中相关的实体页（一次资料可能触发10-15个页面更新）
添加交叉引用
标注新旧知识矛盾

2.2 查询（Query）

直接问AI，它基于wiki/回答——不是检索，是推理。

2.3 巡检（Lint）

定期让AI检查知识库健康度：

哪些结论已经过时？
哪些页面孤零零没有引用？
哪些新旧知识有矛盾？

结果写入outputs/目录，这就是知识库的"体检单"。

三、我在工业视觉场景的落地

工具组合很简单：OpenClaw 多 Agent 系统（自动执行 Ingest/Lint）+ 飞书文档（协作）。

3.1 我和 Karpathy 方案的关键区别

先说结论：我参照了 Karpathy 的原版思路，但在实际落地时做了一个关键调整——我没有用 raw/ 层。

原版的三层是 raw/ → wiki/ → CLAUDE.md，我的架构是这样的：

Karpathy 原版：
raw/       → 原始资料（PDF、论文、截图），只读
    ↓
wiki/      → AI编译产物（结构化Markdown），活的
    ↓
CLAUDE.md  → Schema规则

我的落地版：
各 Agent 工作空间（memory/）→ 日常工作自然沉淀的笔记、日志、方案
    ↓
共享 wiki/                    → AI 定期编译整理的结构化知识
    ↓
schema.md                     → 编译规则 + HEARTBEAT.md 巡检指令

区别在哪？

Karpathy 是一个人用 Claude，手动往 raw/ 扔资料，再让 Claude 编译到 wiki。这在个人场景很优雅。

但我的情况不同——我有 6 个 Agent 在同时工作：算法、运营、项目、专利、点子、数据。每个 Agent 有自己的工作空间，每天都在产出笔记、方案、客户记录。

如果还用 raw/ 的模式，意味着要手动收集 6 个 Agent 的产出，丢进 raw/，再编译。这是把多 Agent 的优势废掉了。

我的做法是：让每个 Agent 的工作空间天然就是"知识源"。每个 Agent 每天写 memory 日志、产出方案文档，这些就是未经编译的"原始资料"。然后通过 cron 定时任务，每天凌晨自动扫描所有 Agent 的 memory/，把有价值的信息编译进共享 wiki/。

Karpathy 的 raw/ 是"扔进去"的动作，我的 memory/ 是"自然长出来"的。 一种是主动收集，一种是被动沉淀。对于多 Agent 协作场景，后者更可持续。

3.2 三层架构在工业视觉场景的映射

知识源层（替代 raw/）——6 个 Agent 各自的工作空间：

workspace/
├── algo/memory/       # 算法笔记：模型训练记录、精度对比、技术方案
├── ops/memory/        # 运营笔记：政策简报、行业调研、知识库整理
├── pm/memory/         # 项目笔记：客户跟进、需求分析、优先级判断
├── ideas/memory/      # 点子笔记：技术洞察、产品灵感、竞品分析
├── patent/memory/     # 专利笔记：审查意见、方案迭代
└── data/memory/       # 数据笔记：数据源评估、API调试

每个 Agent 在日常工作中自然产出这些内容，不需要额外操作。这比"手动把资料扔进 raw/"高效得多。

编译产物层（wiki/）——AI 编译后的结构化知识：

wiki/
├── pages/
│   ├── customers/      # 客户实体页：背景、需求、状态、下一步
│   ├── products/       # 产品实体页：技术方案、进度、成本
│   ├── tech/           # 技术实体页：算法、工具、部署经验
│   ├── market/         # 市场实体页：行业趋势、竞品、政策
│   ├── policy/         # 政策实体页：补贴、申报、截止日期
│   └── ops/            # 运营实体页：流程、工具、经验
├── outputs/
│   ├── qa/             # 问答归档：有价值的问答沉淀
│   └── health/         # 健康报告：每周巡检结果
├── index.md            # 全局入口
└── schema.md           # 编译规则

规则层（schema.md + HEARTBEAT.md）——两条核心指令：

schema.md 定义编译规则：
1. 遇到新实体（客户/项目/技术方案）→ 建一个独立页面
2. 页面之间有引用关系 → 在两页都加双向链接
3. 新知识和旧知识矛盾 → 在旧页面加标注

HEARTBEAT.md 定义巡检节奏：
- 每次心跳轮到时，只扫描 pages/ 下的一个分类
- 顺序轮转：customers → products → tech → market → policy → ops
- 发现问题记到 outputs/health/

3.3 一个具体例子

算法 Agent 完成了一个"相位偏折术在反光表面缺陷检测中的应用"的技术调研，写进了 algo/memory/ 的日志里。

凌晨 cron 触发，wiki 编译 Agent 扫描到这条日志，自动执行：

创建"相位偏折术"的独立技术页面
更新"缺陷检测"分类索引
如果有正在做的反光表面客户，标注"相关技术"
更新 index.md 的交叉引用
如果和已有方案矛盾，自动标注

全程自动，从"Agent 日常工作"到"结构化知识资产"，不需要我手动整理一条。

3.4 比原版多做了什么

回过头看，我在 Karpathy 原版基础上多做了三件事：

1. 知识源从"手动收集"变成"自动沉淀"
原版需要人主动往 raw/ 扔资料，我的 Agent 在工作中自然产出。知识收集的成本从"每条手动"降到了"零操作"。

2. 增加了 outputs/ 层做知识回溯
原版只有 raw/ 和 wiki/，我加了 outputs/ 目录：qa/ 存有价值的问答归档，health/ 存每周巡检报告。这让知识库不只是"变厚"，还能"回头看"——哪些问题被反复问？哪些客户页面长期没更新？

3. 巡检从"想起来才跑"变成"定时自动"
Karpathy 提到了 Lint 但没有强调频率。我把巡检写进了 Agent 的 HEARTBEAT.md，每次心跳轮到一个分类，6 个分类轮转一圈正好一周。不需要提醒，不会遗漏。

四、踩过的三个坑

坑一：误以为RAG是答案（浪费两个月）

花了两个月搭RAG：向量数据库、Embedding API、LangChain全套。效果不满意之后，我怀疑是调参不够好、数据量不够大。

后来想明白了：RAG解决的是"检索速度"，不是"知识积累"。我要的不是更快地找到碎片，我要的是知识随使用持续增厚。

坑二：Schema写太复杂（执行卡死）

第一版Schema写了2000字——页面格式、更新规则、矛盾处理流程、标签体系全定义好。AI第一次处理raw/就卡住了，规则太多互相冲突，跑了40分钟还没完。

后来精简到300字，只留三条核心规则。Schema是给AI方向，不是给AI枷锁。

坑三：把"存储"当成"编译"

最开始看到好文章，复制链接扔进raw/，就以为"知识入库了"。

错了。存链接不等于编译。编译的意思是：读完之后，用200字写清楚这是什么领域、解决了什么、我为什么关心、和我的什么工作相关。未经编译的知识只是文本，经过推理的知识才是资产。

五、为什么说"知识管理是写作问题"

踩了三个月坑之后，我最大的领悟是：

这不是一个整理问题，这是一个写作问题。

与其花三周设计完美的分类体系，不如花三周写出20篇扎实的页面。

分类会自然涌现——当你写了10篇缺陷检测页面，会发现"这些可以分三类：表面缺陷、结构缺陷、功能缺陷"。分类从笔记里长出来，不是从大脑里想出来。

**先写，写完再整理。**和写代码一样，粗糙的第一版比完美的设计草稿有价值一百倍。

六、知识库健康检查

每周跑一次Lint：

检查项	异常信号	后果
孤立页面	没有任何页面引用它	内容没有上下文承接
内容过薄	少于100字只有链接	当初没有真正编译
状态过期	标注"跟进中"但超30天未更新	上下文已失效
矛盾未标	新旧知识冲突但没有标注	AI推理会混乱