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

Karpathy LLM Wiki 实战落地用 OpenClaw 多 Agent 做了三个关键升级10年工业视觉老兵一人创业中。用OpenClaw搭了一套AI公司的操作系统——多Agent协作开发、自动化工作流、智能获客。技术踩坑创业都写。前言一个困扰了所有工程师的问题做技术的人知识焦虑是常态。论文要看、方案要写、算法要调、客户要跟、政策要学。每件事都重要但串起来就是一团乱麻。我试过很多办法文件夹分类——建了一套客户/技术/政策/产品的目录每次新笔记都面临灵魂拷问这算技术还是产品最后堆在杂项里吃灰。RAG——向量数据库 Embedding API LangChain花了两周搭好每次回答都是碎片拼凑没有上下文没有逻辑关联。更致命的是RAG不积累知识今天问完明天还是从零开始。直到2026年4月初KarpathyOpenAI联合创始人发布了他用LLM管理个人知识库的方法叫LLM Wiki。全网讨论量爆炸三天内GitHub相关项目star飙升。我花了三个月落地这套方案踩了三个坑。这篇文章说说我的真实体验。一、LLM Wiki 的核心把知识当代码一样编译Karpathy的方案核心很简单三层分离。raw/ → 原始资料PDF、论文、截图、聊天记录只读 ↓ wiki/ → AI编译产物结构化Markdown带交叉引用活的 ↓ CLAUDE.md → Schema规则页面格式、更新逻辑给AI的方向和RAG的根本区别在于RAGLLM 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推理会混乱过期的结论自动标红孤立页面归类到待整理。七、这套东西对我意味着什么一人公司最稀缺的不是技术能力是上下文切换的代价。白天跟客户聊完技术方案晚上打开记录已经忘了当时聊了啥。方案讨论到哪一步了下一步做什么全靠脑子记。现在AI每次处理完沟通记录自动更新客户wiki页面——跟进状态、讨论的技术方案、达成的共识、下一步行动。下次见客户之前让AI读一遍wiki30秒内恢复完整上下文。知识不再是散落在各处的碎片而是真正可检索、可推理、可累积的资产。相关阅读Karpathy LLM Wiki 原版Gisthttps://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f我用OpenClaw搭了一套多Agent对抗式开发流水线一个需求2.5小时出可运行代码一人公司的AI开发实践持续更新。如果对你有启发点赞收藏是对我最大的支持。