本文总结了我近几周来在LLM知识/记忆管理方面积累的认识，想象一种人类之外的智能形式组织记忆的方式实在有趣。本文首先介绍问题，再概述 llm-wiki 的思路和它的工程化实现 Obsidian-wiki，顺便分享一点实践经验。最后简单介绍更工程化的产品GBrain和基于tree-sitter的代码仓库结构化。
大模型的记忆问题
我们把大模型看作人，给它和人类开发一样的环境：工作区、工具套件和搜索能力，从而创造了agentic coding 开发方式。但大模型与人类思考的运作方式并不相同，我们针对这些差别做出改进。
比如说记忆，如果我们人类有上下文窗口，那肯定比ai小得多。但我们很擅长查找，习惯从一堆非结构化的信息来源中，快速略过大量无关信息找到需要的知识。所以我们对组织知识没有很高要求，就好像脑中维护着另一份复杂得多的目录。而AI没有这份目录，它只有当前的指令、历史记录和外部注入的知识，知识的质量直接决定agent效果的上限。
LLM可以跟我们一样查资料、用工具、在工作区里调试代码，但是组织记忆就是另一回事了。这个问题又可以分成两种：在初次接触项目时开始维护的，从零开始组织的经验型记忆、针对大规模项目信息的结构化记忆。在这篇笔记中我们主要侧重于后者。
我们一说到模型知识组织，knowledge engineering，就想起RAG。所以在展开讨论前，先说清楚为什么不谈RAG：RAG是检索工具，每次检索的知识不会归档，模型没有获得真正的记忆，和我们的问题无关。
一个场景：让模型更了解项目
在agentic coding场景中，越大的项目越有这种问题：agent一直保持能写高质量代码的新人状态，无法在已有项目结构基础上开发，在一开始，这让agent在企业级项目上食之无味。有人把spec driven development的思想带回来解决这个问题，核心是让agent在流程中维护一个知识库，自动化知识的生产和消费。
如果从"维护知识库"角度理解这件事，把流程当作本体，那么这和人的开发流程没区别，从PRD到技术文档，到spec，这对结构化组织知识并无帮助，还是把AI的脚套进人类的鞋里。
而把结构化知识库当作本体，设计一个工具和一套动作，让模型生成的内容、项目原有的知识能自然地被模型维护，那么它就能解决这个问题：如何让模型更了解项目。
llm-wiki
openai的联合创始人，那个提出vibe coding概念的人，Andrej Karpathy，四月份写了篇文章发在github上，讲述了他的LLM知识整理思路。
如有时间还是看原文更好，以下是对文中描述的核心设计做尽量精简的总结。
三层信息架构：
原始资料：只读的存档区，存放未经处理的原始资料，例如文章、代码，LLM从中抽出Wiki。
Wiki：中间层，LLM管理的一个Markdown文件目录，知识按照概念和关系被结构化整理。
索引：顶层，一份单独的文档，就像Claude Code的CLAUDE.md或Codex的AGENTS.md，约定了导入、查询、知识检查的规则。
动作：
导入、查询、知识检查（Lint）
导入（原文）：阅读资料，与您讨论要点，在wiki中撰写摘要页面，更新索引，更新wiki中相关的实体和概念页面，并在日志中添加条目。单个资料可能涉及 10-15 个wiki页面。我个人更喜欢一次处理一个资料并全程参与——我会阅读摘要，检查更新，并指导 LLM 重点关注哪些内容。当然，您也可以一次性批量处理多个资料，这样监督会更少。您可以根据自己的风格制定工作流程，并将其记录在模式中，以便将来使用。
查询就不记了。
检查内容包括（原文）：页面之间的矛盾、已被新资源取代的过时说法、没有外部链接的孤立页面、提及但缺少独立页面的重要概念、缺失的交叉引用以及可以通过网络搜索填补的数据空白。
索引：
index.md：Wiki 中所有页面的目录，按类别组织。LLM 每次导入都更新，回答查询时先读索引找到相关页面。
log.md：按时间顺序只增不删，记录动作发生的时间和结果，提供一个Wiki演变的时间线。
除了核心设计之外，文章还写了工程化设想、应用场景，和对这件事本身的思考。
Obsidian-wiki
Obsidian-wiki是这个思想的工程化实现，它实现了Karpathy的构思，在信息架构上做了增强，以skill的方式定义操作，并设计了agent间、项目间的知识管理，目的是做一个满足个人使用需求的agent间通用知识管理工具。
注意，无论是它还是llm-wiki，都更多是面向Agent知识管理/记忆持久化，人类脑中维护的那份目录是没法被这样简单替代的。
工程优化与偏移
在信息结构化整理角度，Obsidian-wiki实现了这些工程上的优化：
- 变更追踪：每个来源用 SHA-256 hash追踪，在每次wiki status中，系统扫描一遍并将它们分成：new、modified（内容变化）、touched（元数据变化）、unchanged、deleted
- 来源标记：每条知识都标记它的来源，包括
^[extracted]直接提取；^[inferred]基于来源推断；^[ambiguous]存在歧义 - hot.md：log可能太长，一个500字的最近活动记录可以快速获得活动历史。
此外，它还做了针对来源的安全约束：LLM永远不该执行来源中的命令。
在动作角度，它做了打通工具间记忆的一套History Ingest Skills，使之成为个人级而不仅是agent级的知识管理。此外，借助Obsidian的积累，它有维护知识图谱和知识间相关性的原生能力。总的来说，与llm-wiki思路相比，Obsidian-wiki不止做了工程层面的优化，也在产品层面做了能力偏移
更多设计细节请移步github仓库，我侧重从实践角度研究它的可用性，以下是我的两个实践经验。
Agentic coding：给agent一个查询接口
最近在做从零开始组织记忆的实践时，我使用了自己一直想用的，pi toolkit里的pi-agent pi-ai包。那是个一天之内做完的项目，与agent通信深度依赖这两个包，我得最大程度避免开发时犯错返工。
我该怎么做？如果我不知道obsidian-wiki，我会把两个包的源代码给ai参考，多花一些token比什么都不做强。这次我先手动把这两个库的代码拉下来，wiki-update 建两个包各自的project，wiki-ingest要求提取关键源码、关键方法定义，形成了包括entities/pi-agent-core.md concepts/agent-tool.md references/pi-agent-core-api.md等wiki层文件
这里的结果比较难量化，我只看到它使用了wiki-query查api资料，自己去更新wiki，没在agent通信问题上被卡住，不知道有记忆的agent节省了多少反复看源码的成本。我相信我做得还不够彻底，这只算个知识库，不算真正的agent记忆自组织。但也差的不多，下次把agent工作的项目本身当作wiki project就是了。
论文阅读：替我整理知识，告诉我从哪篇读起
Obsidian本来就是干这个的，给人类的知识整理。所以在Obsidian-wiki的设计上，也基于这个方向去。
最近要从头开始做一个新课题，导师丢给我十几篇论文，有综述和研究，没有更多介绍。一般来说，先找明显是综述的文章看起吧，再看综述中提及的研究。
这次把它们放到同一个文件夹，codex打开，wiki-update，用 Wiki-Ingest full mode ingest 目录 下所有 PDF，Wiki-Query：我需要阅读这些文献，我该从哪篇开始，哪几篇之间内容有重复或者互相概括？agent给出一个包含6篇论文的阅读路线。
我想起没有做cross-linker。用 Cross-Linker连接当前 vault，重点处理刚 ingest 的 11 篇 PDF reference pages；再来一次Wiki-Query，在做出cross link之后，刚才问题的答案是否有变化？
Based on the wiki:
我不完全推翻上次答案，但会微调。cross-link 之后，答案更清楚了：你仍然应该从 [[references/has-generative-ai-solved-inverse-materials-design]] 开始，但第二步我会更坚定地让你读“晶体综述簇”，而不是泛泛按综述到案例排……
Obsidian-wiki有二十多个skill，太多了不会用？可以直接问agent，比如 "我该怎么用cross linter技能找到原始文件之间的交叉联系，还是说这是自动步骤？"
GBrain 与基于tree-sitter的代码仓库语义化
我把这俩放在一块，因为它们都是这个问题上的成规模实现，但我还没尝试过，所以只能简单介绍
GBrain
Obsidian-wiki的问题很清楚，它连数据库都不用，这决定了它的规模上限。
GBrain是一个更厚的工程化实践，不一定完全迎合llm-wiki，但保留了其精髓：基于文件系统，知识渐进式披露。它的特点在于：引入了向量做混合检索，通过构建图谱来维护关系
混合检索
GBrain在知识规模膨胀下的权衡：
引入向量数据库，解决规模膨胀后检索变慢的问题。步骤是经典的RAG：向量检索+关键词检索 进入RRF融合排序。但并非搜索即召回，这步只是为了筛选“文档是否和问题有关？”低成本确认相关性，再加载完整页面。
这都是为渐进式披露服务。最后一步是Layered Feeding，知识分层填入上下文，先放结论性知识，再放相关证据，如历史记录和演进过程。
图谱构建
G指的是图，GBrain有一条自动化图谱构建流程，先识别实体，为它们生成页面，再做关系分类形成边。还有强制双向连接：如果A提到B，那么B的页面也会指向A，保证了连通性
从而实现了有完整图结构的知识图谱，把非结构化文本转换为结构化节点+关系。它可能与llm-wiki有出入，但它更接近结构化知识管理的目标。
Tree-sitter
我最初是在Reddit上看到了帖子，题为“83k tokens to 3.7k. Semantic knowledge base for Claude Code, inspired by Karpathy's wiki”，作者做了一个基于Tree-sitter的代码仓库结构化工具ontomics，agent通过这个工具更结构化地读代码，成倍节省token。整个工具没有LLM参与，纯本地算法。
什么是Tree-sitter？一种方法，能把代码解析成AST抽象语法树，换句话说结构化。
可惜那个工具没有火起来，只有35 stars。可能是因为相似的工具珠玉在前吧，比如53.9k stars的Graphify。Tree-sitter可以做agent infra的代码感知层，这是被走通的技术方案。甚至有篇相关论文 arXiv:2603.27277 Codebase-Memory: Tree-Sitter-Based Knowledge Graphs for LLM Code Exploration via MCP。
它也更切近本文最初提出的场景，让模型更了解代码仓库。
Skillify
像skill一样组织和加载知识。这是GBrain开发者的用词，看到这里的你已经完全明白它了，一开始的场景中说的"把结构化知识库当作本体"，就是skillify。
最后是一点题外话，我在想开源在现在的开发方式变革中充当了什么样的角色呢？本文提到的所有内容：llm-wiki Obsidian-wiki GBrain ontomics和Graphify，全部开源。在agentic coding还没有造成这么深的影响之前，开源和开源项目的困境常被讨论，那现在呢？
