一句话总结
Karpathy的LLM Wiki不是又一个笔记工具，而是一个给Agent用的长期工作底座：
- 传统RAG：查询时临时检索，问完即走，知识不沉淀
- LLM Wiki：先编译成结构化知识层，持续回写，复利增长
- 核心差异：多了一层被Agent消费、持续维护的wiki中间层
一、从"临时检索"到"先编译再查询"
传统RAG的困境
大多数人用LLM和文档打交道的方式：
上传文件 → 提问 → 检索片段 → 生成答案 → 结束
问题：
- 今天问"这5篇文章共同说明了什么"，模型找5次片段、拼1次答案
- 过两天换个问法，大概率还要再做一遍
- 知识不会留下来，不会随着使用慢慢长出来
LLM Wiki的范式
原始资料 → 编译成wiki（摘要、实体、概念、索引）
↓
查询时读index → 钻具体页面 → 生成答案
↓
有价值的结果 → 回写成新页面
核心洞察:
“传统知识库更像’临时检索’，LLM Wiki更像’先编译，再查询’。”
二、三层架构：原始资料、Wiki、Schema
┌─────────────────────────────────────────┐
│ Schema（规则层） │
│ AGENTS.md / CLAUDE.md │
│ 定义：怎么组织、怎么ingest、怎么query │
├─────────────────────────────────────────┤
│ The Wiki（知识层） │
│ LLM生成和维护的Markdown │
│ 摘要、实体页、概念页、索引 │
├─────────────────────────────────────────┤
│ Raw Sources（事实源） │
│ 文章、论文、图片、代码 │
│ 只读，不改 │
└─────────────────────────────────────────┘
Schema：被忽略的关键层
作用：告诉LLM这个wiki应该怎么组织
- 目录怎么分
- 页面该长成什么样
- ingest/query/lint各自走什么流程
- 什么时候自动写，什么时候人工复核
没有Schema的问题：
- 命名会漂
- 页面结构会漂
- 引用习惯会漂
有了Schema：wiki才像能长期维护的系统，不只是聊天记录堆出来的文件夹
三、两个导航器：index.md vs log.md
| 文件 | 作用 | 回答的问题 |
|---|---|---|
| index.md | 内容地图 | “这里都有什么”（空间导航） |
| log.md | 变更记录 | “最近发生了什么”（时间导航） |
index.md: 按类别列出页面、链接和摘要，LLM先读目录再钻具体页面
log.md: 按时间追加，记录ingest、query、lint操作
Karpathy的观察：在约100篇资料、40万词规模下，靠index+摘要已经能撑起不少查询
四、Farzapedia：为Agent而建
核心洞察
“这个wiki不是为我建的，而是为我的agent建的。”
Farza的实践：
- 2500条个人材料（日记、笔记、iMessage）
- 生成400篇相互链接的个人百科
- Agent从index.md开始，一层层钻到需要的页面
典型场景
需求：给新产品做landing page
Agent行为：
- 去wiki找最近喜欢过的图片、电影
- 找竞品页面和审美线索
- 综合出文案和视觉方向
结果：wiki不只是"记忆容器"，而是Agent的长期工作底稿
Karpathy总结的四个特点
- 显式（Explicit）：能看到AI知道什么、不知道什么
- 你的（Yours）：数据留在本地，不锁在厂商那里
- 文件优于应用（File over App）：底层就是通用文件
- 自带AI（BYOAI）：可以换Claude、Codex或其他模型
五、复利的关键：回写（file back）
传统问题
很多不错的分析、比较、总结，最后都停在聊天记录里。过几天要再用，又得重新做一遍。
LLM Wiki的闭环
ingest新资料 → query已有wiki → 有价值输出 → file back到wiki
效果：
- 问答不只是消耗上下文，也开始生产上下文
- 知识会慢慢长出来，而不是回答过就结束
关键：
“开始复利的，往往是回写这一步。”
六、idea file：新的分发方式
核心思想
在LLM Agent时代，可以先分享一个相对抽象的idea file，再交给对方的Agent结合自己的场景落地。
特点：
- 分享的不是成品
- 分享的是结构化思路
- 接力完成落地的是接收方自己的Agent
类比：
“Obsidian是IDE，LLM是程序员，wiki是代码库。idea file相当于设计文档。”
七、架构师视角的三个感受
1. Agent的"记忆"从黑盒往显式工件拉了一步
- 能看到目录、页面、索引、日志、反向链接
- 看到哪些结论是后来补的，哪些地方还没整理好
- 对团队场景：过程有机会变成能被后续协作利用的工件
2. 最有价值的未必是回答更准，而是知识不会轻易蒸发
- 在意的是"不错的分析最后都停在聊天记录里"
file back改变知识怎么积累- 问答开始变成生产上下文
3. 真正麻烦的地方最后还是治理
难点：
- 页面怎么命名
- 引用怎么保留
- 什么能自动写，什么要人工看
- 哪些结论已过期
- 哪些页面只是写得顺但不可靠
提醒：
“知识系统一旦想长期运行，最后绕不开结构、回写和校验。”
八、历史呼应：从Memex到LLM Wiki
1945年：Vannevar Bush的Memex
- 私人的、持续整理的知识存储系统
- 文档之间通过关联路径相互连接
- 更私人、更注重主动整理、更看重文档之间的联系
2026年：Karpathy的LLM Wiki
- Bush没解决的问题"谁来做维护"
- 现在LLM可以接过去了
关键：
“人类放弃维护的速度，通常比知识增长的速度更快。LLM不会觉得烦，不会忘了更新一条交叉引用。维护成本接近零，wiki才有可能真的活下来。”
九、最小闭环：如何开始
建议起点：范围很窄、最近反复在看的主题
最小闭环步骤：
- 准备小的
raw/目录，放同一主题的几份资料 - 写短的
AGENTS.md，说清目录、格式、引用要求 - 让Agent ingest一份来源，看会不会更新摘要、索引
- 问一个需要跨资料综合的问题
- 有价值就file back回wiki
- 回头看：链接通不通，来源在不在，判断是否写过头
走完一圈能感觉到的：
- 这套方式有没有帮你留下东西
- 你愿不愿意继续维护这层中间层
十、一句话总结
“它比传统知识库多出来的，是一层会被持续维护、持续回写、也持续被Agent消费的wiki中间层。”
参考链接
- Karpathy gist: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- Karpathy长帖: https://x.com/karpathy/status/2039805659525644595
- Farzapedia: https://x.com/FarzaTV/status/2040563939797504467
- 原文分析: 架构师视角：LLM Wiki不是知识库，是Agent的长期工作底座
标签: #LLMWiki #Karpathy #知识管理 #Agent #架构 #Farzapedia #第二大脑