llm-wiki

1. 核心想法

大部分人理解的LLM和文档之间的交互更像是RAG的操作：上传一堆文件，LLM在每次请求时检索数据块（chunk）然后生成回答。

这种方法是可行的，但在最基础的 RAG 模式下，系统保存的通常只是可检索的原始数据块，而不是持续演化的综合知识。因此，模型在回答每个问题时，仍需要重新检索、理解并组织相关材料。

Karpathy就提出了一种新的想法：LLM不再只是在查询时从原始文档或者数据块中检索信息，而是预先构建并持续维护一个持久化的 Wiki——它由一组结构化、相互连接的Markdown文件组成，位于你和原始数据源之间。

每次新增一个信息源时，LLM不只是给它建立索引，留待之后检索。它会阅读内容、提取关键信息，并将其整合进现有的Wiki中——更新实体页面、修订主题摘要、标记新数据与旧数据之间的矛盾，并进一步强化或挑战不断演化的综合结论。

Wiki不需要自己来写，而是交给LLM来写和维护。人只需要负责筛选原始信息、确定探索方向，并提出正确的问题。

2. 整体架构与工作流程

整个系统位于原始信息源和用户或 Agent 之间。新增信息首先由 LLM 读取和分析，再被整理进已有 Wiki；在回答问题时，Agent 不必直接扫描全部原始材料，而是先读取索引和相关 Wiki 页面，只有在需要验证细节时才回到原始来源。

原始信息源
   ↓
读取、提取与综合
   ↓
持续维护的 Wiki
   ↓
索引与渐进式加载
   ↓
用户或其他 Agent

3. 索引与日志

随着Wiki内容越来越多，有两个特殊文件可以帮助LLM和你快速找到所需内容。

`index.md`

index.md面向内容。它是Wiki 中所有内容的目录：每个页面都会列出链接、一句话摘要，还可以附带日期、来源数量等元数据。它会按照类别进行组织，例如entities、concepts、sources等。每次摄取了新的数据，LLM都会更新这个文件。在回答问题的时候，LLM会先读取索引，找到相关页面，然后再深入查看这些页面。对于规模有限、页面结构清晰的 Wiki，这种方式可能已经足够有效。例如在大约 100 个来源、数百个页面的规模下，Agent 可以先读取索引，再渐进式访问相关页面，不一定需要立即搭建基于 Embedding 的 RAG 基础设施。

`log.md`

log.md面向时间顺序。它是一份只追加、不修改的记录，用来保存发生了什么以及何时发生，例如数据摄取、查询、Lint检查等。 log.md展示了Wiki的演进时间线，也能帮助LLM理解最近完成了哪些操作。

4. 为什么可行？

维护一个知识库最繁琐的部分，并不是阅读或思考，而是那些琐碎的维护工作：更新交叉引用、让摘要保持最新、记录新数据何时与旧有说法相冲突，以及在几十个页面之间维持一致性。

人们之所以会放弃维护Wiki，是因为维护负担的增长速度往往快于它所带来的价值。LLM不会感到厌烦，也不会忘记更新某个交叉引用，还可以一次同时修改15个文件。Wiki之所以能够持续得到维护，是因为维护成本能够显著降低。

人的工作，是筛选和整理信息来源、引导分析方向、提出好问题，并思考这些内容究竟意味着什么。剩下的工作都交给LLM。

5. 具体的实现

5.1 DeepWiki

DeepWiki是Cognition（Devin开发团队）推出的一款专门针对Github代码仓库的自动文档生成与交互式阅读平台。

核心目的是帮助开发者在面对庞大且不熟悉的仓库时，能够快速理解项目的整体架构和关键实现逻辑。对于公开的Github仓库，DeepWiki免费开放使用。

核心功能亮点

简单接入与自动生成不需要配置或者部署。直接访问官网输入仓库地址，或者直接在浏览器地址栏中将目标Github的github.com替换为deepwiki.com，系统后端就会自动拉取代码，生成一个包含项目概览、功能模块、API说明的结构化“百科”页面
自动化生成可视化图表系统会递归扫描项目的根目录和子目录，识别模块关系与依赖。它能自动绘制出系统架构图和依赖关系图谱，能直观地看到各个模块、类和函数之间是如何相互调用的。
内置代码问答能力（Ask Devin）单纯看文档依然可能遇到盲区，因此生成的Wiki页面内置了基于Devin模型的聊天助手。可以直接向它提问，它会结合代码上下文给出精准回答，并附带直接指向源码的引用链接。
与Devin深度整合 DeepWiki的代码库智能理解能力直接集成在了Devin中。在使用Devin编写或修改代码时，Devin会自动检测何时需要扫描代码库，可以手动触发它来获取DeepWiki级别的上下文分析。

DeepWiki 对公共 GitHub 仓库是完全免费且免登录开放的，但针对私有代码仓库，它采取了企业级的隔离方案。私有仓库的解析属于付费服务，主要面向企业团队和专业开发者，私有仓库需要通过 Devin 账户或企业服务接入，生成内容仅对获得授权的账户或团队开放。具体的数据存储、保留和模型训练政策，应以 Cognition 最新的服务条款和企业协议为准。

5.2 AutoWiki

AutoWiki是Factory公司在2026年推出的一套“代码库自动文档系统”，它的核心理念是：

Documentation should be a build artifact, not a side project. 文档应该像APK、二进制文件、测试报告一样，由构建流程自动产出，而不是开发者额外维护的副业。

传统的模式通常是：

开发功能
  ↓
合并代码
  ↓
有空再更新文档

AutoWiki把流程改成：

代码 push 到 main
  ↓
CI 触发
  ↓
分析代码差异
  ↓
自动重新生成相关文档
  ↓
提交、保存并发布 Wiki

也就是说，文档不再依赖某个人“记得更新”，而是由代码仓库的当前状态自动生成。

AutoWiki 可以在默认分支更新后触发文档刷新，并根据代码库的当前状态更新相关页面。生成的内容通常包括：

系统整体架构
技术栈
项目目录结构
主要入口
模块和系统划分
API与数据流
开发约定
如何贡献代码
模块之间的关系和交叉链接

5.3 OpenWiki

OpenWiki 是 LangChain 开源的 Agent 知识编译器。

它将代码仓库、邮件、Notion、书签和网页搜索等原始信息，持续整理为本地 Markdown Wiki，供 LLM 作为长期、结构化、可更新的上下文使用。

OpenWiki的最初目标是：

先让一个Agent阅读代码库，把重要知识整理成Wiki；以后其他Agent先读Wiki，需要细节时再回到源码。

它是一个TypeScript CLI，可以在仓库中生成并维护openwiki/目录里的Markdown文档。在运行前需要自己配置模型。

生成Wiki之后，OpenWiki会修改仓库中的Agent指令文件，例如：

AGENTS.md
CLAUDE.md

它不会把整个Wiki塞进指令文件，而只是加入一个引用，大意是：

需要理解代码库结构时，请读取openwiki/ 中的文档

渐进式上下文加载：

AGENTS.md
   ↓
告诉 Agent Wiki 在哪里
   ↓
Agent 先读 index
   ↓
根据任务读取相关页面
   ↓
必要时再读取源码

可以手动执行更新，也提供Github Actions、GitLab CI示例，可以定期运行并创建包含文档更新的PR或MR。

代码仓库模式被称为 Code Brain。

后续又扩展了 Personal Brain，即面向通用个人知识的模式。

信息源从代码扩展到了Gmail、Notion、X/Twitter、Hacker News、Web Search等。

LangChain明确将两种模式分开，因为它们使用的prompt、连接器和更新工作流不同，但底层思想相同：给Agent提供自动生成、持续维护的上下文。

5.4 GBrain

GBrain 是 Garry Tan 开源的一套 Agent 长期知识系统。与 DeepWiki、AutoWiki 和 OpenWiki 相比，它的重点不只是自动生成 Wiki，而是为长期运行的 AI Agent 提供一个可持续读写的“外部大脑”。

在普通聊天中，模型只能使用当前上下文窗口里的信息；在许多 Agent 系统中，Memory 更常用于保存用户偏好、操作规则和工具配置；GBrain 则更强调保存关于外部世界的长期知识。GBrain 则主要保存关于外部世界的长期知识，例如人物、公司、项目、会议、想法和事件。

GBrain 将信息划分为三个层次：

Session Context
当前对话和当前任务中的临时信息
 
Agent Memory
用户偏好、操作规则、工具配置和任务连续性
 
GBrain
人物、公司、项目、会议、概念等长期世界知识

例如：

“用户喜欢简洁的回答”
→ Agent Memory

“Alice 是 Acme 的产品负责人”
→ GBrain

“我们刚刚正在讨论发布计划”
→ Session Context

这种划分避免了把所有信息都堆进同一种记忆中，也降低了Agent重启或切换会话后丢失重要知识的风险。

核心能力

持久化的Agent知识层 GBrain保存实体页面、事实、时间线和来源。Agent在新的会话中可以重新查询这些内容，而不需要依赖之前的聊天记录。
面向Agent的读写接口 GBrain提供CLI和MCP接口。Claude Code、Codex、Cursor、OpenClaw或Hermes等Agent可以直接调用它，完成搜索、读取、写入和更新知识等操作。
从检索走向综合普通搜索系统主要返回相关页面或数据块；GBrain 更强调由 Agent 读取多个相关来源，综合出带有背景、时间和来源的答案。
主动维护与后台整理在完整配置中，Agent 可以按照预设工作流摄取新信息、更新旧页面，并通过周期性任务整理和补充已有知识。
本地与自托管 GBrain 可以使用本地 PGlite，也可以连接 PostgreSQL 或远程服务。这使它更适合作为个人 Agent 或企业内部 Agent 的长期记忆基础设施。

与OpenWiki的区别

OpenWiki 更接近一个“知识编译器”：它从代码仓库、邮件、Notion 和网页等信息源中提取内容，并持续生成结构化的 Markdown Wiki。

GBrain 更接近一个“Agent 运行时大脑”：它关注 Agent 应该在什么时候查询长期知识、什么时候写入新事实，以及如何区分世界知识、操作记忆和当前上下文。

因此，两者并不完全是同类产品：

OpenWiki：
原始信息 → 编译和维护 Wiki → Agent 阅读 Wiki

GBrain：
Agent 工作过程 → 主动读写长期知识 → 跨会话持续使用

OpenWiki 更适合自动构建和维护可阅读的知识库；GBrain 更适合为持续运行的个人 Agent 提供可查询、可写入、可演化的长期记忆。

5.5 Swimm

Swimm是一套面向研发团队的持续文档平台，核心目标是让文档和代码保持同步。

它会将文档中的内容与具体代码建立关联。当代码在 PR 或 MR 中发生变化时，Swimm 会检查哪些文档可能已经过期，并自动同步简单修改，或者提醒开发者更新文档。

它也支持根据 PR、分支或代码片段生成文档初稿，但与 DeepWiki、AutoWiki 不同，Swimm 更关注已有文档的持续维护，而不是重新生成整个代码库 Wiki。

对于我们的场景，Swimm 最有价值的地方是：

代码发生修改
→ 自动识别可能受影响的 Feature Wiki
→ 提醒或协助开发者更新
→ 文档与代码一起审核和合并

它比较适合“AI 生成初稿、开发者补充业务信息、系统持续检查文档是否过期”的团队工作流。

局限是它主要理解代码和 Git 变更，PRD 中的业务背景、产品规则和验收标准仍需要额外接入或人工补充。

6. 总结

这类系统的共同方向，是将 Agent 获取知识的方式从“每次查询时重新检索和理解”，转变为“提前整理、持续维护，并在需要时渐进式加载”。

它们解决的并不只是文档生成问题，而是 Agent 的上下文工程问题：如何让 Agent 在有限的上下文窗口中，稳定获得已经整理过的项目知识、历史决策和长期背景。

四种实现分别代表了不同方向：

DeepWiki 强调开箱即用的代码库理解；
AutoWiki 强调文档随构建流程自动更新；
OpenWiki 强调开源、可配置的知识编译；
GBrain 强调 Agent 可主动读写的长期记忆。

LLM Wiki 也并不会完全替代 RAG。更可能的架构是：Wiki 保存已经综合过的稳定知识，RAG 负责查询原始材料和长尾细节，Agent 则根据任务在两者之间进行选择。

最终的关键问题不再只是“如何找到相关文档”，而是：

如何让知识在被使用之后沉淀下来，并在新信息到来时得到持续修正。

Rooftop

主题