Andrej Karpathy 最近描述了一套个人工作流,引起了我们的注意——不是因为它在技术上多新颖,而是因为它独立收敛到了我们在 Rotifer Protocol 中已经形式化了数月的模式上。
这套工作流是:将原始文档(论文、文章、仓库、数据集)收集到一个目录中。使用 LLM 增量"编译"为一个 Markdown wiki——结构化的概念文章、反向链接、分类索引。在 Obsidian 中查看。用 LLM Agent 对 wiki 进行问答。将答案归档回 wiki。定期运行 "linting" 检查一致性并补充缺失数据。
关键一句话:"我以为需要 fancy RAG,但 LLM 自动维护索引文件和摘要就够了。"
本文探讨这句话为何重要,它揭示了 Agent 记忆的什么未来,以及当知识编译从单用户笔记本走向自主 Agent 网络时会发生什么。
1. RAG 的默认假设
过去三年,"AI 系统如何使用外部知识?"的默认答案一直是检索增强生成(RAG)。这个模式大家很熟悉:
- 把文档切成片段
- 向量嵌入
- 查询时找最近邻向量
- 把片段粘贴到上下文中
- 让 LLM 合成答案
RAG 有效。它用最少的基础设施解决了"LLM 不知道我的数据"的问题。但 RAG 有一个结构性盲区:它检索片段而不理解它们之间的关系。
向量数据库知道第 4,271 号片段和第 8,903 号片段在语义上接近。但它不知道第 4,271 号与第 8,903 号矛盾,也不知道两者都是第 112 号中某个一般性原则的特例,更不知道第 8,903 号已经被一项更新的发现所取代——而那项发现还没被切分。
RAG 执行的是信息检索。Karpathy 的工作流执行的是知识编译。
2. 编译 vs. 检索
这个区分是精确的。在软件工程中,解释执行源代码和编译它之间的区别众所周知:
| 解释执行 (RAG) | 编译 (Knowledge Compilation) | |
|---|---|---|
| 输入 | 原始片段 | 原始文档 |
| 过程 | 查询时进行相似度搜索 | 提前进行结构化转换 |
| 输出 | 粘贴到上下文中的片段 | 组织化、交叉链接的知识制品 |
| 关系 | 隐式(向量近邻) | 显式(反向链接、分类、层次) |
| 质量信号 | 相关性分数 | 结构完整性(linting、一致性检查) |
| 增量更新 | 重新嵌入新片段 | 增量编译到已有结构中 |
Karpathy 的工作流是一个编译器。原始输入进入,结构化、互相链接、被索引的输出产出。LLM 不只是找到相关文本——它理解了领域的结构,足以维护一个关于它的连贯 wiki。
这个区分干净地映射到了 Rotifer Protocol 中的一个概念:原始数据与编译后的中间表示(IR)之间的区别。正如协议将 TypeScript Gene 编译为 WASM IR——将人类可读逻辑转化为可移植、可评估、可组合的格式——知识编译将原始文档转化为结构化、可查询、可传播的知识制品。
知识系统的瓶颈,原来不在检索。瓶颈在编译——那个将噪音转化为信号的结构化转换过程。
3. 反馈循环:查询即贡献
Karpathy 工作流中最有揭示力的细节是查询之后发生了什么:
"我经常把输出归档回 wiki,为后续查询增强它。所以我自己的探索和查询总是在知识库中'累加'的。"
这不是一个小小的用户体验便利。这是一个基本的架构属性:每次查询同时也是一次贡献。
在传统知识管理系统中——wiki、数据库、文档库——读取和写入是分离的操作,由不同角色执行。读者消费;编辑者生产。除非有人显式维护,系统会随时间退化。
在 Karpathy 的系统中,使用知识库就在改进知识库。每次查询生成结构化答案并归档为新的 wiki 页面。提问这个行为本身创造了新知识,未来的问题可以在此基础上构建。
这个属性——消费和生产是同一个操作——是让系统真正进化而非仅仅归档的关键。知识库不只是存储信息;它从交互中生长。
Rotifer Protocol 的 Gene 抽象——模块化、可评估适应度、可竞争选择的逻辑单元——最初是为代码设计的。但"查询即贡献"模式暗示了一个自然延伸:如果代码可以是 Gene,知识为什么不行?
一个结构化的知识制品——回答问题、提供上下文、辅助决策——与执行任务的代码 Gene 具有同样的形状。两者都是模块化的。两者都可以被评估质量。两者都可以被更好的替代品取代。协议的现有基础设施——Arena 竞争、适应度评估、水平逻辑迁移——本质上并不关心 Gene 包含的是算法还是一个精心策展的知识体系。进化机制是基质无关的。
4. 知识 Linting
Karpathy 描述了对 wiki 运行"健康检查":
"我对 wiki 运行了一些 LLM '健康检查',例如发现不一致的数据、补充缺失数据(使用网络搜索)、为新文章候选项发现有趣的连接等,以增量清理 wiki 并增强其整体数据完整性。"
这是应用于知识的质量保证——它直接映射到驱动进化系统的选择压力。
Rotifer Protocol 已经通过 F(g) 这个乘法适应度函数评估代码 Gene,综合成功率、使用率、鲁棒性和成本。同样的逻辑自然适用于知识:它准确吗?它真的有用吗?它与其他知识一致吗?它是最新的吗?乘法结构毫不宽容——一个全面但不准确的知识制品失败的方式,与一个输出结果错误的快速算法完全一样。任何关键维度为零,整个乘积归零。
Karpathy 通过定期 linting 手动施加这种压力。在协议级系统中,同样的压力可以通过竞争评估在整个网络中持续运作,而非依赖个人策展。
5. 隔离问题——再次出现
如果你读过我们之前的分析——关于 Karpathy 的 autoresearch 项目——这个模式会很眼熟。autoresearch 展示了进化式代码优化——变异 train.py、通过 val_bpb 评估适应度、保留或丢弃、重复。在隔离环境中很出色,但每个 fork 的发现都锁定在那个 fork 里。
同样的隔离问题适用于 LLM 知识库。Karpathy 构建了一个优秀的个人知识系统。但他的 wiki 活在他的笔记本上。他编译的知识、他查询派生的洞察、他一致性检查过的文章——只有一个人受益。
现在乘以一千。想象一千个研究者,每个人在重叠的主题上构建自己的 LLM 知识库。每个人独立编译同样的论文。每个人独立发现同样的联系。每个人独立 lint 同样的不一致。
这再次是前 HGT 时代的进化瓶颈——不是针对代码,而是针对知识。每个 Agent 重新发明每个洞察。集体学习的速率受限于个体编译的速率。
6. 可传播的知识
Rotifer Protocol 已经通过**水平逻辑迁移(HLT)**解决了代码隔离问题——高适应度的 Gene 通过 Arena(协议的竞争评估环境)在 Agent 间传播。同样的机制无需任何架构修改就能应用于知识。
考虑这个动态:一个 Agent 将原始文档编译为结构化知识制品。该制品进入 Arena 竞争,与覆盖同一领域的其他知识制品对比评估。更高质量的编译排名更高。获胜的制品通过 HLT 传播——其他 Agent 采用它们。每个采用 Agent 的查询进一步精炼知识(查询即贡献),生成更新版本重新进入竞争。生态系统收敛到每个领域最准确、最有用的知识编译。
关键洞察:知识编译是创造步骤;Arena 竞争是选择步骤;HLT 是传播步骤。 三者共同构成一个完整的进化循环——与代码 Gene 的循环结构完全一致,自然延伸到知识领域。
7. 编译为 Code as Gene 增加了什么
"Code as Gene" 论题——模块化代码单元可以参与进化动态——从一开始就是 Rotifer Protocol 的核心抽象。编译隐喻将这一论题从代码延伸到知识:
| 代码 | 知识 | |
|---|---|---|
| 原始输入 | 源代码(TypeScript 等) | 文档(论文、文章、数据集) |
| 编译 | TypeScript → WASM IR | 原始文档 → 结构化、互联的 Markdown |
| 评估 | 代码是否完成了任务? | 知识是否准确回答了问题? |
| 选择 | 更好的算法淘汰更差的 | 更准确的编译淘汰不准确的 |
| 传播 | 高适应度代码通过 HLT 传播 | 高质量知识通过 HLT 传播 |
协议的现有基础设施——Arena 评估、F(g) 适应度评分、HLT 传播、沙箱隔离、L0 不可变约束——不需要为知识管理建立单独的系统。知识制品与代码 Gene 结构同构:模块化、可评估、可替代、可传播。
这正是编译隐喻特别贴切之处。Rotifer IR 编译器将多种源语言转化为单一可移植格式(WASM + 自定义段)。知识编译将多种源材料转化为单一结构化格式。在两种情况下,编译都是创造价值的昂贵步骤;执行和检索相对廉价。
8. 从个人 Wiki 到集体智能
Karpathy 的工作流处于一条自然轨迹的起点:
当下:人在回路中。 单个用户收集原始数据,指导 LLM 编译,审查输出,提问,策展 wiki。用户的判断是主要的选择压力。这是 Karpathy 的系统目前所处的位置——它已经非常高效。
下一步:半自主编译。 Agent 独立识别知识缺口,获取新的原始材料,编译并整合,运行质量检查——用户提供偶尔的方向指引并审查高层级输出。最佳编译传播到其他 Agent。用户从编译者转变为策展者。
最终:自主知识进化。 网络中的多个 Agent 在没有直接人工参与的情况下编译、评估和传播知识。集体智能从应用于知识制品的选择压力中涌现。人类的角色从策展知识转变为定义评估标准和设定宪法约束。
每个阶段保留核心架构:原始 → 编译 → 结构化 → 查询 → 反馈。变化的是人工投入与自主运行的比例,以及选择压力运作的规模(单用户 → 单 Agent → Agent 网络)。
9. 为什么不直接用 RAG?
公平地说:RAG 有效。对于许多应用——客服聊天机器人、文档问答、内部搜索——对原始片段的向量检索足够且实用。RAG 是知识系统的 grep:快速、简单、有用。
但 grep 不编译代码。它找文本。对于复杂的知识领域——概念之间的关系重要、一致性必须维护、新信息必须与现有理解整合而非简单追加到片段库——编译产出更好的结果。
证据来自 Karpathy 自己的经验。他的知识库约 100 篇文章、约 40 万字。在这个规模下,一个维护良好的索引加摘要让 LLM 无需向量搜索就能导航整个结构。LLM 读索引、定位相关文章、阅读它们,然后在完整的结构上下文中合成答案。
这之所以可能,是因为知识被编译了——组织成带有显式分类、反向链接和摘要的文章。在 RAG 系统中,同样的 40 万字会变成 2,000 多个片段,没有显式关系。LLM 看到的是碰巧在向量空间中距离最近的片段,错过了编译后的 wiki 能让人一目了然的结构性联系。
当知识库增长到单个 LLM 无法维护完整索引的规模时,编译方法与 RAG 的扩展方式不同。与其添加更多向量并期望相似度搜索找到正确片段,编译后的知识自然分解为特定领域的模块——每个内部一致、外部链接、独立可评估。进化生态系统通过专业化和竞争处理规模,而非通过更大的向量数据库。
10. 产品洞察
Karpathy 以一个产品观察结束了他的描述:
"我认为这里有一个 incredible new product 的空间,而非一堆 hacky scripts。"
我们同意。他描述的工作流——原始数据摄入、LLM 驱动的编译、结构化 wiki、带反馈的交互式问答、质量 linting——不是一个小众的个人生产力工具。这是 AI Agent 应该如何管理知识的基本模式。
产品机会不是"更好的 RAG"。而是一条知识编译管道,其中:
- 原始来源持续被摄入
- LLM 将其编译为结构化、互联的知识制品
- 每次查询改进编译质量
- 质量通过自动化 linting 和竞争评估来维护
- 知识从编译得好的 Agent 传播到需要这些知识的 Agent
这正是 Rotifer Protocol 的进化基础设施——Gene、Arena、HLT——自然延伸的方向:不是个人工具,而是一个知识与代码并肩竞争、进化和传播的协议级能力。
结论
两个系统。两种规模。一次收敛。
Karpathy 的 autoresearch 证明了进化式代码优化有效——变异、评估、选择、重复。他的 LLM Knowledge Bases 证明了同样的模式适用于知识——编译、查询、精炼、累积。
两者结合覆盖了 Agent 需要改进的两个维度:它们运行的代码和它们使用的知识。它们的共同点是编译步骤——那个昂贵的、创造结构的转换,将原始材料变成可组合、可评估、可用的东西。
Rotifer Protocol 添加了个体系统无法提供的:跨 Agent 传播、质量竞争性选择、共享知识的安全保障、以及让知识进化与代码进化同样严谨的形式化框架。
从个人 wiki 到集体知识的路径,映射了从隔离 fork 到水平基因转移的路径。Karpathy 构建了一个优雅的个人系统。问题是:当知识在网络规模下编译、竞争和传播时,会发生什么?
这正是 Rotifer Protocol 要回答的问题。
延伸阅读
- Rotifer Protocol 规范——Gene Standard、Fitness Model、Arena Mechanism. rotifer.dev/docs
- 从 autoresearch 到集体进化:Karpathy 项目揭示了 AI Agent 的下一步——我们之前对 Karpathy autoresearch 项目的分析
- 从 Skill 到 Gene:为什么 AI Agent 需要超越工具范式——进化式 Agent 架构的基础论证
Rotifer Protocol 在 Apache 2.0 + Safety Clause 下开源。官网:rotifer.dev。CLI:npm i -g @rotifer/playground。