这是苍何的第 576 篇原创。RAG 和 NotebookLM 听上去很智能,问题也很明显:每次提问模型都从碎片里重新拼答案,答完就散,同样的问题问一百遍,它就重新拼一百遍。知识本身没有任何积累。

这是什么

作者基于 Karpathy 公开的 LLM Wiki 架构,用 Obsidian(本地 Markdown 笔记工具)做存储,Codex 或 WorkBuddy 做执行 Agent,搭出一套三层结构的个人知识库:Raw 层保存剪藏文章和聊天记录等原始材料,Wiki 层沉淀 AI 整理出的概念和主题,Schema 层规定 AI 如何归档、更新和处理冲突。

关键变化是 AI 从一次性问答变成长期维护者:新资料进入后,Agent 会先看现有页面,补充已有内容,创建新概念页面,遇到分歧则保留来源、时间和适用范围。知识库会留下变化,而不是每次清零重来。

行业怎么看

支持者认为这是个人知识管理的范式转变。Obsidian 的本地 Markdown 格式天然适合 Agent 工作——可直接读写文件、用 Git 留变更记录、双链和图谱帮用户发现核心节点和孤立页面。DeepSeek V4 Flash 性价比高但不支持多模态,Kimi K3 和 Doubao-Seed-Evolving 是国内多模态的备选。

反对意见同样值得听。原文作者自己强烈不建议用 Codex 里的 GPT 5.6 Sol,理由是用量太凶。这意味着这套系统对模型上下文容量和工具调用稳定性要求很高,实际跑起来的时间和成本未必友好。更根本的疑问是:把 AGENTS.md 的规则交给 AI 自己执行,长期维护中积累的错误如何审计?如果 Agent 在 Wiki 层悄悄写入了偏差理解,人能否及时发现?知识管理的负担从「手动整理」转移到「审查 AI 整理结果」,对不少人来说未必更轻松。

对普通人的影响

对企业 IT:这套思路的迁移方向是部门级知识库——把会议纪要、产品文档和客户沟通沉淀成可演进的结构,而不是每次让 RAG 重新检索拼凑。

对个人职场:愿意折腾 Obsidian 和 Git 的技术岗可以先试;非技术背景的人,如果只是想管理读书笔记,NotebookLM 仍是最省力的入口。

对消费市场:Obsidian 类工具会继续吃到「数据自主」这波情绪,但能完整跑通 Agent 工作流的人仍是少数,真正的门槛在 Schema 规则设计而不是工具安装。