‍# RalphLoop × Karpathy LLM Wiki 全方位改造方案

本作者用5亿token踩的坑，你可别再踩了。

总是在社媒平台看到有些博主，又发了个对通用智能体框架很有帮助的项目，几乎是隔天隔周就发一个好厉害的项目。

关于karpathy的llm wiki，我引入了，真心论证过后引入了，让kimi和minimax检查了一遍又一遍，以为万事大吉了，直到今天，你看看吧。

直接说结论：不要看到一个很厉害的开源项目就想直接拿过来用，冲突、风险、冗余、架构方方面面，少一点考量都会导致你越跑越偏。

看吧，karpathy的llm wiki虽好，你看看真的适合你吗？反正我已经移除了，再找找更合适的新路子。

核心结论：不要盲目移植开源项目。Karpathy 的 LLM Wiki 虽好，但与 Hermes 现有架构、工作流和知识生产模式存在根本性错配，已移除。

---

一、现状诊断（改造前基线）

1.1 双轨知识库割裂

维度	RalphLoop 知识产出	Wiki 系统现状
位置	knowledge_base/（4.2MB）	harness-knowledge/（577MB）
内容	高质量研究报告（3000字深度档案）	8,800+ 空壳页面（平均430字符）
关系	零链接、零同步、零交叉引用	独立运行，未消费研究报告

1.2 RalphLoop 任务流本质

当前是研究报告工厂：topics-queue → Researcher-KB Agent → 写报告 → 标记完成。没有编译、交叉引用、入库审核、生命周期管理。

1.3 与 Karpathy 构想的差距

Karpathy 要求	Hermes 现状	差距
人类策展决定来源	Agent 自主决定研究对象	❌ 无人类把关
LLM 编译（1来源→10-15页面）	1份报告→1个文件	❌ 无编译深度
交叉引用网络	91.5% 孤儿页面	❌ 无知识网络
定期 Lint	wiki-maintainer 几乎不运行	❌ 无维护机制
约 100 篇 / 400K 词	8,800 篇 / 577MB 空壳	❌ 规模失控

---

二、改造核心原则

不破坏现有核心流程：ralph-loop、task-queue、spawn-hermes 及 topics-queue 保持不动，仅改造任务模板、新增脚本、调整目录结构。

引入 Karpathy 三层架构：

harness-knowledge/
├── raw/              ← 原始来源（研究报告、会话记录、外部文章）
├── wiki/
│   ├── draft/        ← 待审核新页面
│   ├── packets/      ← Knowledge Packet（核心知识单元）
│   ├── procedures/   ← 可复用操作流程
│   ├── decisions/    ← 架构决策记录
│   └── archive/      ← 归档
├── schema.md         ← 知识库规范（人类维护）
└── scripts/          ← 自动化脚本（编译器、巡检、生命周期、质量评分）

人机分工重新定义：

角色	做什么	不做什么
人类	定义核心域、核心问题、审核 draft、定义 schema	不写 wiki、不维护链接
Compile Agent	读取 raw/，编译成 packets/，建立交叉引用	不决定研究什么
Lint Agent	每周巡检，发现矛盾、孤儿、过时内容	不写入新内容
Curation Agent	评估 draft 质量，决定转正/退回/合并	不生成原始内容

---

三、五阶段改造路线图

Week 1：止血与架构重组

• 新建三层目录，将现有空壳批量归档，迁移研究报告至 raw/
• 重写 schema.md，定义页面格式、质量标准（最小1,500字符、至少2个出链、60分及格）
• 修改 Researcher-KB Prompt：不再直接写 wiki，改为产出 raw/ 研究报告 + 编译指令

Week 2-3：建立编译流水线

• 部署 wiki-compiler：读取 raw/ 来源，深度综合编译为 wiki/draft/ 中的 Knowledge Packet（1来源可更新3-10个Packet）
• 部署 wiki-quality：自动评分（长度、出链、结构完整性）
• 在任务队列中新增 compile 类型任务

Week 3-4：生命周期与策展

• 部署 wiki-lifecycle：每周自动统计入链数、质量分、最近访问时间，自动归档低质量/过期/孤儿页面
• 部署 Curation Agent：审核 draft/，≥60分转正，<60分退回，重复度>80%合并
• 人类仅审核 borderline 案例和架构决策（ADR）

Week 4-5：消费约束

• 在核心状态机中增加 强制召回机制：Agent 执行涉及特定域的任务前，必须先查询对应 wiki Packet
• 所有 Agent Prompt 增加"先查 wiki"规则
• 引入语义索引（sqlite-vec + bge-m3）优化召回质量

Week 5-6：聚焦核心域

• 严格限定仅 3-5 个核心域进入 wiki/packets/（如 hermes-architecture、hermes-operations、agent-patterns、mcp-ecosystem）
• 非核心域内容（如"全球思想家研究"）留在 knowledge_base/，不进入 wiki
• 人类每周 15-30 分钟策展：浏览 draft、决定转正/退回、提出新 Compile 任务

---

四、预期效果

指标	改造前	改造后（6周目标）
wiki 页面总数	8,800+	150-250
空壳率	99.9%	< 5%
孤儿率	91.5%	< 20%
平均内容长度	430 字符	2,000+ 字符
wiki-recall 调用	1次/历史	10-20次/天
Agent 复用 wiki 结论	~0%	60%+

Token 节省：按每天20个任务、60%复用率、每次复用节省3,000 Token估算，每月节省约100万 Token。

改造成功标志：

1. Agent 从"几乎不查 wiki"变成"默认先查"
2. 人类在 Obsidian 中打开 wiki 时，看到的是有价值的知识网络
3. RalphLoop 从"研究报告工厂"变成"知识编译+维护流水线"
4. 知识库规模稳定，遵循"淘汰旧知识 = 补充新知识"

---

五、风险与缓解

风险	可能性	影响	缓解
Compile Agent 产出仍然太浅	中	高	硬性字数门槛（1,500+），人类审核前10个样本
人类策展时间不足	中	高	Curation Agent 自动过滤（<60分直接退回），人类只审 borderline
语义索引引入复杂度	低	中	保留原有 FTS5 作为 fallback
任务积压	中	中	Compile/Lint 设为 P2 优先级，不阻塞核心任务
语义漂移	低	高	每个 Packet 强制标注 sources，矛盾时回溯 raw/

---

六、一句话总结

改造的本质不是"让 RalphLoop 写更多 wiki"，而是"把 RalphLoop 从研究报告工厂改造成知识编译器"——人类策展决定什么值得学，RalphLoop 负责编译和维持，Agent 执行时先查已编译的知识。这样知识库才会从"8,000 个空壳"变成"200 个真正可复用的知识包"。