从DeepWiki到OpenWiki：Agent Wiki如何解决RAG的致命缺陷

做过RAG（检索增强生成）系统的工程师，大概率都遇到过这样一个尴尬的场景：同一批文档，系统回答第10个问题时，并不比回答第1个问题时更聪明。每次查询都是从原始分块重新推导，前9次积累的理解完全没有沉淀下来。这种结构性缺陷，根源在于传统RAG「不保留结果」的设计理念——每个答案都是现场重建的，同样的理解工作要重复支付10次成本。

核心思路：把成本从查询阶段挪到导入阶段

近一年来，多个技术团队从不同场景出发，不约而同地收敛到了同一个解决方案：不要在查询时重新推导，而要在资料导入时完成编译。这套模式被命名为Agent Wiki。

三层架构与核心操作

传统RAG的工作流程是：文档入库→切分→生成Embedding→写入向量索引，查询时召回相关分块并生成答案。这套方案能用，但存在根本性问题：它不保留结果。每个答案都是从原始分块现场重建的，第10个答案不会比第1个更好。Agent Wiki的核心转变在于：模型在读取源文档时就把工作做完一次，把结果写成页面，页面持久保留。当新的源文档进入系统时，模型执行的是增量操作——读取新资料、更新相关页面、修正受影响的摘要，并标记与既有页面的矛盾信息。两种方案的核心差异不在于效果，而在于成本发生的时间点，以及一次查询结束后留下了什么。

四大项目的工程实践对比

四个代表性系统——Cognition的DeepWiki、Karpathy的Gist llm-wiki、Factory的AutoWiki、LangChain的OpenWiki——其架构可以抽象为同一个三层模型。 第一层是源文档，包括文章、论文、代码仓库，模型只读不修改。第二层是Wiki，内容采用Markdown格式，全部由模型写入，包含摘要、按主题组织的页面，以及页面之间的链接。第三层是维护指令或配置，用于告诉模型Wiki如何组织、生成和更新，具体形式可能是项目专用配置文件或工作流。 围绕这个架构，三个核心操作支撑起整个系统的运转： Ingest（导入）：模型读取新的源文档，把信息分发到所有相关页面。 Query（查询）：向Wiki提问，一个好的回答可以作为新页面反写回Wiki。 Lint（检查）：模型检查整个Wiki，找出互相矛盾的信息、已经过时的内容，以及没有任何链接指向的孤立页面。Lint这一步容易被忽略，但它恰恰是这套方案能长期成立的关键。

边界与思考

在具体实现上，四个团队展现出有趣的分化。 DeepWiki最早于2025年5月公开发布，将这套方法应用到GitHub公开仓库，上线时已覆盖5万多个主流项目。但更值得关注的是其产品定位：Wiki本身不是产品，而是给Agent使用的检索基础设施，Devin正是依靠它在代码库中定位相关代码。 AutoWiki的切入点是持续集成。其核心主张是「文档应该是一个构建产物，而不是一个独立项目」——文档从源码生成，结构与代码库对齐，代码变了它就跟着变。生成过程分两遍：结构扫描和语义扫描。工作被分配给多个专职Agent，每个Agent负责代码库的一部分，这个设计有效规避了单个Agent面对大型代码库时文档质量下降的问题。 OpenWiki则在代码库基础上进一步扩展，推出了Personal Brain模式——从Gmail、Notion、Git仓库、X等平台拉取数据，全部写入本地Markdown Wiki。这标志着这套方法从「为代码库写文档」演进到了「为你的工作写文档」。 四个系统在维护方式上出现了真正的分歧：AutoWiki将更新直接接入CI，OpenWiki支持GitHub Ac

如有侵权，请联系删除。