‍# 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.2MBharness-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% 孤儿页面❌ 无知识网络定期 Lintwiki-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 Packet1来源可更新3-10个Packet部署wiki-quality自动评分长度、出链、结构完整性在任务队列中新增compile类型任务Week 3-4生命周期与策展部署wiki-lifecycle每周自动统计入链数、质量分、最近访问时间自动归档低质量/过期/孤儿页面部署Curation Agent审核draft/≥60分转正60分退回重复度80%合并人类仅审核 borderline 案例和架构决策ADRWeek 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,800150-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 个真正可复用的知识包。