--- title: '自进化的Claude Code记忆系统' video_id: 7huCP6RkcY4 url: https://youtu.be/7huCP6RkcY4 title_en: "I Built Self-Evolving Claude Code Memory w/ Karpathy's LLM Knowledge Bases" channel: Cole Medin published: 2026-04-06 duration: "19:24" topics: [RAG 与知识系统, Claude Code 定制扩展, Agent 工程] noted: 2026-07-05 value: A views: '14.7万' --- [![封面](https://i.ytimg.com/vi/7huCP6RkcY4/maxresdefault.jpg)](https://youtu.be/7huCP6RkcY4) > Cole Medin · 19:24 · 发布 2026-04-06 · 14.7万次观看(截至抓取) · [观看原视频](https://youtu.be/7huCP6RkcY4) > 🔥 观众最高回放 [10:40](https://youtu.be/7huCP6RkcY4?t=640) — 演示用 InsForge 一键搭建带登录数据库的托管应用 ## 主旨 把 Karpathy 的 LLM 知识库范式整套照搬,只把数据源从"外部资料"换成"你和编码 agent 的会话日志",用 Claude Code hooks + Claude Agent SDK 搭出一份随 codebase 演进、越用越聪明的记忆系统。 ## 核心论点 1. **Karpathy 的 LLM 知识库范式可整套复用,只换数据源**——外部资料换成内部会话,给 Claude Code 一份随 codebase 演进的记忆。(→ 详解1、5) 2. **用编译器类比理解整个系统**:raw 源码 → LLM 编译 → wiki 可执行 → linting 测试 → 查询 runtime,每一环都对应知识管理的一步。([[#2-编译器类比知识就是被编译的源码-0236|→ 详解2]]) 3. **不用花哨 RAG**:靠一份 index 文件 + 渐进式披露,agent 自己在 vault 里逐层导航,无向量库、无语义检索。([[#3-不用花哨-ragindex--渐进式披露-0534|→ 详解3]]) 4. **整个系统只靠 Claude Code hooks 驱动**:session start 注入规则与索引,pre-compact/session-end 把会话摘要写进 daily log,flush 每天晋升进 wiki。(→ 详解4、5) 5. **复利循环是核心价值**:每次问答都把综合结论回填知识库,用得越多答得越好,几乎零维护。([[#6-复利循环越用越聪明-1654|→ 详解6]]) ## 知识点详解 ### 1. 起点:Karpathy 的 LLM 个人知识库 [00:35](https://youtu.be/7huCP6RkcY4?t=35) Karpathy 一条推文带火了"用 LLM 建个人知识库"的做法:把外部资料(文章、论文)引进自己的系统,组织成便于 agent 查询的形态,即所谓 AI 第二大脑。他用 Obsidian 当载体,给出了一整套 playbook——数据摄入、查看、查询、格式化,还带健康检查。 本片的底座就是这套 LLM wiki 范式;与同源的 [[2026-07-02-给LLM Wiki定的开放标准OKF来了|OKF 那篇]] 相比,OKF 关心"怎么定标准让各家知识库互通",本片关心"怎么把这套范式落地成一个能自我演进的实现"。 ### 2. 编译器类比:知识就是被编译的源码 [02:36](https://youtu.be/7huCP6RkcY4?t=156) Cole 用编译器类比串起 Karpathy 的整个系统。源码 = raw 文件夹里未加工的 markdown(文章、论文、转写),是系统的唯一入口。编译器 = 一个 LLM,读全部 raw 信息,做摘要、建立文档间链接、决定知识结构;这一步有脚本代码承接。 编译产物 = wiki(他称 executable),里面是 LLM 产出的文章加反向链接 [03:54](https://youtu.be/7huCP6RkcY4?t=234)。Obsidian 的 graph view 把知识连成图,agent 能顺着链接遍历、把分散的知识点串成更完整的答案。 进 runtime 之前还有一层 linting(测试套件)[04:40](https://youtu.be/7huCP6RkcY4?t=280):找研究缺口、陈旧数据、raw 里有但 wiki 没收的差异、断链——保证知识库的完整性。最后才是 runtime,即用 agent 跑查询取用 wiki [05:34](https://youtu.be/7huCP6RkcY4?t=334)。 ### 3. 不用花哨 RAG:index + 渐进式披露 [05:34](https://youtu.be/7huCP6RkcY4?t=334) Karpathy 有句关键判断:本以为要上花哨 RAG,结果 LLM 很擅长自动维护 index 文件。于是整个 wiki 里最重要的一个文件就是 index——它向 agent 描述有哪些文件夹和资源,当作检索的起点。 因此不需要向量数据库、不需要语义检索,agent 直接在 vault 里按 index 导航到对应文件即可。这正是 [[渐进式披露]]:先读索引摘要判断方向,再按需打开具体 Entity document。简单是这套策略最大的吸引力。 数据流上,外部信息经 Obsidian Web Clipper 落进 raw 文件夹 [06:21](https://youtu.be/7huCP6RkcY4?t=381),喂给 LLM 产出 wiki——里面有 concepts(抽取的概念)、connections(概念间关系)、index,以及 agents.md [07:18](https://youtu.be/7huCP6RkcY4?t=438)。agents.md 是给 agent 的全局规则,把整个系统讲清楚:信息从哪来、编译版在哪查、index 和 log 是什么,让 agent 一进新会话就有元认知,知道自己被丢进了什么系统。 ### 4. 一键起系统:把 PRD prompt 丢给 agent [07:55](https://youtu.be/7huCP6RkcY4?t=475) 最省事的部分:想给自己搭这套 LLM 知识库,只需把一段 prompt 发给你的 coding agent。这段 prompt 来自 Karpathy 的一条后续推文,本质是一份 [[PRD]]——把要建的东西全写清楚,不给别的上下文,agent 就能一次性(one-shot)把整套系统搭出来。 Cole 自己的版本也内建了这个:照 README 的 quick start,不用手动 clone,把 prompt 发进 Claude Code,它会自己 clone repo、配好所有 hooks。 ### 5. Cole 的改造:内部数据 + hooks 驱动的自进化记忆系统 [08:47](https://youtu.be/7huCP6RkcY4?t=527) Cole 的关键改动:数据源从外部换成内部。不再从网上抓资料,而是给 Claude Code 一份随 codebase 演进的记忆——把知识库建在"你和编码 agent 的对话"上。会话日志(daily/session logs)就相当于 raw 文件夹,再用 Claude Agent SDK 在后台把它们抽取成结构化、交叉引用的知识文章。按 codebase 逐个建,项目越用记忆越丰富。 整套系统只靠 Claude Code hooks 驱动,不装任何额外集成。session start hook 在每次新会话加载 agents.md 和 index [12:44](https://youtu.be/7huCP6RkcY4?t=764),让 agent 一上来就带着系统说明和文件清单,能直接基于知识库回答、无需深扒代码。 pre-compact 和 session-end 两个 hook 做同一件事:在即将丢失上下文(关会话或压缩记忆)前,把最新消息送进另一个 LLM 处理,生成一段带"决策/教训/待办"的标准格式摘要,写进 daily log [14:53](https://youtu.be/7huCP6RkcY4?t=893)。这两个 hook 都在底层调 Claude Agent SDK,单独跑一个 Claude 进程做摘要,复用你的 Anthropic 订阅、无需配 API key [15:31](https://youtu.be/7huCP6RkcY4?t=931)。 再往上是 flush:每天一次,把 daily logs 里的 concepts 和 connections 抽出来,晋升进 wiki [15:52](https://youtu.be/7huCP6RkcY4?t=952)。想改行为可直接改 flush/compile 脚本里发给 SDK 的 prompt——系统自带 agents.md,Claude Code 能读懂自己的结构、带你做定制,是个能自我改进的自包含系统 [16:29](https://youtu.be/7huCP6RkcY4?t=989)。 ### 6. 复利循环:越用越聪明 [16:54](https://youtu.be/7huCP6RkcY4?t=1014) 最后是 复利循环。每次提问,agent 横跨多篇 wiki 文章综合出一个答案,然后把这个答案再归档回知识库——不断在会话之间连接信息并保存。于是 wiki 随时间增长,加上未来所有 Claude Code 会话进来的新信息,知识库持续变大。 问得越多,agent 检索得越好、答得越好,而你几乎不用做任何维护。示例中他把对话延伸去做网络调研,只要结束会话或触发压缩,后台的 SDK 就自动抽取要点写进 daily log,择日晋升进 wiki。 ## 可执行步骤 - [ ] 把 Karpathy 那段 PRD prompt(或 Cole repo 的 quick start prompt)发进你的 coding agent,一次性搭出 LLM 知识库骨架 - [ ] 用 Obsidian 打开你的 codebase 目录作为 vault,当作查看记忆与 wiki 的画布 - [ ] 在 settings.json 里配三个 hook:session start(注入 agents.md + index)、pre-compact 与 session-end(把会话摘要写进 daily log) - [ ] 让 agents.md 描述整个系统结构,使 agent 一进会话就有元认知、能自我定制 - [ ] 设一个每日 flush,把 daily logs 里的概念与关系晋升进 wiki - [ ] 想改摘要/晋升行为,直接改 flush/compile 脚本里发给 Claude Agent SDK 的 prompt ## 关联 - 印证:[[2026-07-02-给LLM Wiki定的开放标准OKF来了|OKF 那篇]] 同源自 Karpathy 的 LLM wiki;两片都强调 index 文件 + [[渐进式披露]] 让 agent 少花 token 逐层收窄。本片是"实现侧"(hooks + Claude Agent SDK 的自进化记忆),OKF 是"标准侧"(让各家知识库互通)。 - 深化:本片把 LLM wiki 的数据源从外部资料换成内部会话日志,并给出 编译器类比 这条 OKF 篇没有的落地心智模型。 ## 术语 - Compiler analogy(编译器类比)——把知识流水线映射成 源码→编译器→可执行→测试→runtime - Wiki——LLM 编译产出、带反向链接的知识文章集合,即"可执行/可查询"层 - Linting——对知识库做的完整性检查:找缺口、陈旧数据、断链、raw 与 wiki 的差异 - Daily logs / session logs——捕获每次会话摘要的原始层,相当于 raw 文件夹 - Flush——每天把 daily logs 里的概念与关系晋升进 wiki 的过程 - Claude Agent SDK——在 hook 里后台单跑一个 Claude 进程做摘要/抽取,复用 Anthropic 订阅 - Compounding loop(复利循环)——每次问答把综合结论回填知识库,越用越聪明 ## 金句 > "giving claude code a memory that evolves with your codebase." [08:47](https://youtu.be/7huCP6RkcY4?t=527) → 一句话点出与外部知识库的分野:记忆的对象不是网上的资料,而是你和 agent 一起把项目改成什么样。 > "we really don't have to do anything to maintain this... it just gets better and better and better." [16:54](https://youtu.be/7huCP6RkcY4?t=1014) → 复利循环的卖点是"零维护自增长",但这依赖 hook/SDK 稳定跑通,实际维护成本片中未量化。 ## 立场与利益 - InsForge 是本片付费赞助(全栈 app 平台,带 promo code),那段与记忆系统内容无关,可整体忽略。 - Cole 反复引流自己的 repo 与 Dynamous 社群(4 小时付费 workshop),存在自我推广成分;但核心范式来自 Karpathy 的公开推文,记忆系统 repo 本身开源。 - 与工具强绑定的部分:整套实现依赖 Claude Code hooks + Claude Agent SDK + Anthropic 订阅,换别的 agent 需重写;通用共识部分是"编译器类比 + index 导航 + 复利循环"的心智模型。 ## 价值定位 - 适合谁:已经在用 Claude Code、想给它建一份持久/自进化记忆(尤其按 codebase 沉淀决策与教训)的人;没碰过 hooks 的人可拿本片当 hooks 实战入门。 - 解决什么:想让 agent 记住"这个项目踩过的坑、做过的决策",不必每次翻 git log 或起 subagent 慢扒代码——本片给了一套 hooks + SDK 的落地骨架。 - 认知 vs 实操:偏实操(具体到三个 hook、flush、agents.md),但 repo 细节没逐行讲,真正上手仍需照 README。 - 与 [[2026-07-02-给LLM Wiki定的开放标准OKF来了|OKF 那篇]] 重叠(同源 Karpathy),但本片独有的是:把数据源换成内部会话日志的自进化记忆系统、hooks + Claude Agent SDK 的具体驱动链路,以及编译器类比这条落地心智模型。 ## 自检问题 1. Cole 的记忆系统和 Karpathy 原版 LLM 知识库最本质的区别是什么? **答案**:数据源——Karpathy 处理外部资料(文章/论文),Cole 处理内部会话日志,给 Claude Code 一份随 codebase 演进的记忆,但整套组织方式照搬 Karpathy。见"Cole 的改造"一节 [08:47](https://youtu.be/7huCP6RkcY4?t=527)。 2. 编译器类比里,raw、compiler、executable、linting、runtime 分别对应知识管理的什么? **答案**:raw=未加工 markdown 入口,compiler=读全部 raw 做摘要与链接的 LLM,executable/wiki=带反链的知识文章(供查询),linting=完整性检查(缺口/陈旧/断链),runtime=用 agent 跑查询。见"编译器类比"一节 [02:36](https://youtu.be/7huCP6RkcY4?t=156)。 3. 这套系统为什么不需要向量数据库或语义检索? **答案**:靠一份 index 文件描述有哪些资源当检索起点,agent 按 [[渐进式披露]] 在 vault 里逐层导航到对应文件即可;Karpathy 发现 LLM 很擅长自动维护 index,不必上花哨 RAG。见"不用花哨 RAG"一节 [05:34](https://youtu.be/7huCP6RkcY4?t=334)。 4. 三个 hook 各自在什么时机、做什么? **答案**:session start 在每次新会话注入 agents.md + index [12:44](https://youtu.be/7huCP6RkcY4?t=764);pre-compact 与 session-end 在即将丢上下文时把最新消息交给 Claude Agent SDK 摘要、写进 daily log [14:53](https://youtu.be/7huCP6RkcY4?t=893);再由每日 flush 把 daily logs 的概念/关系晋升进 wiki [15:52](https://youtu.be/7huCP6RkcY4?t=952)。见"Cole 的改造"一节。 5. "复利循环"指的是什么,它的零维护承诺有什么前提? **答案**:每次问答都把综合出的答案回填知识库,wiki 随会话累积增长、agent 越答越好,几乎零维护 [16:54](https://youtu.be/7huCP6RkcY4?t=1014);但前提是 hook/SDK 要稳定跑通,片中未量化实际维护成本。见"复利循环"一节与"金句"。 > [!quote] 💬 热门评论 top-10 主 + 10 回(抓取 2026-07-07) > > [2] **@MadHolms**:让我思考的部分是“无需RAG”这一点。当你的知识库只有20个文件且索引能轻松放入上下文时，这很有效。但当你在一个有数百次会话的真实代码库上运行6个月后，索引文件会变得巨大，你基本上每次启动会话都要为完整的上下文加载付费。希望能看到后续展示它在规模下的表现，因为我试过的每个“只用平面文件”的方法最终都会崩溃 👍 50 >   ↪ **@tonyclif1**:我记得Karpathy的建议是“最多100个文件” 👍 2 >   ↪ **@matt.lehodey**:你需要像Claude code那样的内容，看看它在泄露的代码中如何组织文件 👍 1 >   ↪ **@arubalcaba**:能不能引入像graphify这样的东西？ >   ↪ **@OhDearBabajan**:你每次会话只使用你需要的上下文。关键是将文件组织成足够小的块，以便在前1-2次会话内获得有意义的结果 >   ↪ **@ColeMedin(UP)**:是的，说得好！整个索引和linting方法保持了可扩展性，但我认为在某个时候你会想升级到更传统的RAG，使用向量数据库和语义搜索 👍 4 > [4] **@Chef_PC**:这正是我一直在构建的东西，只是我之前不知道。我的版本使用停止钩子，每次轮次传递给一个脚本，脚本解析元数据并注入到psql数据库。然后一个脚本将会话处理成可读的转录和可操作的工作流，工具调用也被抓取，所以另一个效率代理会回顾第一个代理如何运行脚本，并向监督者提出工作流更新的建议 👍 6 >   ↪ **@ColeMedin(UP)**:喜欢！！ > [5] **@annonymbruger**:看看运行这个有多贵会很好，既然你在子任务中使用SDK，应该很容易 👍 4 > [8] **@GamingOnInsulin**:这是我第一个关于这个的视频，我有一个问题：如果知识不在Obsidian笔记中，它会从网络获取并保存到Obsidian笔记中吗？还是我理解错了？ > [10] **@dpspokojdpspokoj2320**:我认为最好从头开始展示整个设置，使用一些抽象的原始数据，比如一堆关于FIFA世界杯预选赛的新闻或最近关于减肥的研究。这对普通观众会更有用 👍 3 >   ↪ **@ColeMedin(UP)**:说得对，谢谢你的建议，朋友！ 👍 2 > ——其他 4 条:感谢/夸赞([3]@jarad4621、[6]@JurOz1980、[7]@DigitalSpaceport、[9]@OberDesiah);1 条 spam 已略 >
英文原文[1] @ColeMedin(UP):If you're interested in building your own AI second brain to save yourself hours every week, check out the Dynamous community and the new 4 hour second brain bootcamp: https://dynamous.ai/second-brain-bootcamp 👍 11
  ↪ @SecurityFirm:Karpathy method not optimize and high latency. not useful. note: karpathy not innovate this method
[2] @MadHolms:The part that got me thinking is the "no RAG needed" bit. That works great when your vault has 20 files and the index fits comfortably in context. But once you've been running this for 6 months on a real codebase with hundreds of sessions, that index file is going to be massive and you're basically paying for a full context load on every session start. Would love to see a follow-up showing how this holds up at scale, because that's where every "just use flat files" approach I've tried eventually breaks down. 👍 50
  ↪ @tonyclif1:The recommendation by Karpathy is for "UP to 100 files" if I remember correctly. 👍 2
  ↪ @matt.lehodey:You need contents like Claude code look at how it organises files in the leaked code 👍 1
  ↪ @arubalcaba:Could it be possible to bring in something like graphify?
  ↪ @OhDearBabajan:You use context specifically for what you need per session. It’s about organizing your files into small enough chunks so that you can get meaningful results within the first 1-2 sessions
  ↪ @ColeMedin(UP):Yeah fair point! The whole index and linting approach keeps things scalable but I would say that at some point you would want to graduate to more traditional RAG with a vector database and semantic search. 👍 4
[3] @jarad4621:Thanks I was waiting for your version which I knew is going to be explained better because the other ones weren't explained very well even though it's simple it's not simple but at least not simple to understand why it works the way it does and most critically how to modify for other use cases like business research etc 👍 3
[4] @Chef_PC:This is exactly what I've been building without knowing it. Mine uses stop hooks passing each turn to a script that it parses with metadata and injects into a psql db. Then a script processes down the sessions into readable transcripts and actionable workflows, and the tool calls are grabbed too, so another efficiency agent goes back through and looks at how the first agent ran it's script and makes suggestions to the overseer for a workflow update. 👍 6
  ↪ @ColeMedin(UP):Love it!!
[5] @annonymbruger:It would be nice to see how expensive this is to run, and since you are using the sdk in sub task it should be easy. 👍 4
[6] @JurOz1980:Agree, it much more valuable for your private knowledge 👍 1
[7] @DigitalSpaceport:This is exactly the cutting edge use case that will really hit hard for every user, not just devs. 🎉 👍 7
  ↪ @ColeMedin(UP):I appreciate it a lot!
[8] @GamingOnInsulin:This is my first video on this i have a question what if the knowlage is not in the obsidian notes yet does it then get it from the web and saves it in obsidian notes? Or am i worng about this ?
[9] @OberDesiah:It's funny. I thought of doing my own things like this for a couple of months, but then there are doers and procrastinators. 👍 8
  ↪ @yellow-surfboard:Same. I literally proposed it in a kaizen meeting at work, but never found the time to look at the implementation. I was very quick to copy someone else's work though haha.
[10] @dpspokojdpspokoj2320:I think it would be a good idea to show the whole setup from scratch using some abstract raw data, like a bunch of news about FIFA World Cup qualifications or recent research on weight loss. It would be more useful for your casual viewers 👍 3
  ↪ @ColeMedin(UP):That's fair, I appreciate the suggestion my friend! 👍 2