# 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。
改造成功标志：
- Agent 从"几乎不查 wiki"变成"默认先查"
- 人类在 Obsidian 中打开 wiki 时，看到的是有价值的知识网络
- RalphLoop 从"研究报告工厂"变成"知识编译+维护流水线"
- 知识库规模稳定，遵循"淘汰旧知识 = 补充新知识"
五、风险与缓解
| 风险 | 可能性 | 影响 | 缓解 |
|---|---|---|---|
| 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 个真正可复用的知识包"。
