# The State of Agent Wikis
**作者**: mem0
**日期**: 2026-07-21T15:11:23.000Z
**来源**: [https://x.com/mem0ai/status/2079585032587694582](https://x.com/mem0ai/status/2079585032587694582)
---
In April 2026, Andrej Karpathy wrote a GitHub Gist. He describes a method in it. He calls the method the LLM Wiki.
Four teams built the same thing after that. Cognition built DeepWiki. Factory built AutoWiki. LangChain released OpenWiki. Garry Tan released GBrain.
The method is the same in all four systems. An LLM reads your source documents one time. It writes the information into markdown pages. It keeps the pages correct when the sources change. The agent reads these pages. The agent does not read the source documents again for each question.
People call these systems agent wikis. This article tells you what they are. It tells you what each team built. It tells you the limits of the method. It also tells you one important difference that many people miss.
## The idea: compile at ingest, not at query
The usual method to give a model a large set of documents is retrieval. You put the documents in a database. You divide the documents into parts. You make embeddings for the parts. For each question, the system finds the related parts.
This method works. It also has a problem. The system does not keep the results. It builds each answer from the raw parts again. The tenth answer is not better than the first answer. You pay the cost of the work ten times.
An agent wiki moves this cost. The model does the work one time, when it reads the source. It writes the results into pages. The pages stay.
The model does these steps when a new source comes in. It reads the source. It changes the related pages. It corrects the summaries. It marks the information that disagrees with the pages.
Both methods are correct. They are different in two ways. The first difference is when you pay the cost. The second difference is what stays after the question.
Each system has the same three layers.
Layer 1 is the source documents. These are your articles, papers and repositories. The model reads them. The model does not change them.
Layer 2 is the wiki. The wiki is markdown. The model writes all of the wiki. The wiki contains summaries, pages for each subject, and links between the pages.
Layer 3 is the schema file. This file tells the model the structure of the wiki. It also tells the model which tasks to do. The usual file is CLAUDE.md or AGENTS.md. This file makes the model a correct maintainer of the wiki.
The system does three operations.
Ingest: the model reads a new source. Then the model writes the data to each related page.
Query: you ask the wiki a question. You can write a good answer back into the wiki as a new page.
Lint: the model examines the wiki. It finds information that disagrees. It finds information that is too old. It finds pages with no links.
## Why it works:
Human wikis become incorrect with time. The cause is specific. The difficult part is not to read the sources. The difficult part is not to have the ideas. The difficult part is the maintenance.
The maintenance has these tasks. You must correct the links between the pages. You must keep the summaries correct. You must compare each new document with the pages that exist.
This work does not stop. The work gives no reward. A busy team stops this work first. Then the wiki becomes incorrect. Then the people do not use it.
A model does this work without a problem. The model does not become bored. The model does not forget a link. The model can change fifteen files in one operation.
The idea is old. Vannevar Bush described the Memex in 1945. The Memex is a personal store of documents with links between them. Bush had no answer for the maintenance. The model is the answer.
## Where the name comes from
Read the Karpathy gist directly. It is more accurate than the summaries of it.
He writes this about the usual method: "the LLM is rediscovering knowledge from scratch on every question. There's no accumulation."
His method is to compile the information, and not to retrieve it. Then "the knowledge is compiled once and then kept current, not re-derived on every query." The result is "a persistent, compounding artifact."
You do not write the wiki. He writes: "You never (or rarely) write the wiki yourself, the LLM writes and maintains all of it." He uses the agent and Obsidian together. He writes: "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."
The gist gives a limit for the size. Many summaries do not include this limit. The method without embeddings "works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure."
For more sources, the gist tells you to add search. It gives qmd as the example. The gist describes qmd as "a local search engine for markdown files with hybrid BM25/vector search and LLM re-ranking."
Thus the rule is about size. The rule is not about replacement. Do not use retrieval infrastructure when the source set is small. Add retrieval when the source set becomes large.
## What the labs actually built
This is where the pattern stops being an idea and becomes engineering, and the differences between the implementations are the useful part.
Cognition: DeepWiki, the wiki as a public utility
Cognition applied the method to the public repositories on GitHub. Replace github.com with deepwiki.com in the URL of a public repository. You then get a wiki for that codebase. The wiki has an architecture summary, a file index, a dependency graph, and search. The wiki has links to the source (Cognition).
More than 50,000 of the largest public repositories have a wiki. The list includes MCP and LangChain.
The second point is more important. The wiki is not the product. The wiki is retrieval infrastructure for the agent. Devin uses the wiki to find the related code in a codebase. DeepWiki is thus the compiled layer below the code search in Devin (Devin Docs).
Factory: AutoWiki, documentation as a build artifact
Factory applied the method to continuous integration. Factory writes that documentation must be a build artifact, and not a separate project. The documentation comes from the source. It has the structure of the codebase. It changes when the repository changes (Factory).
The method to make the wiki has two passes. Pass 1 is a structural scan. It reads the README file, the package manifests, the CI configuration and the entry points. Pass 2 is a semantic scan. It reads the routes, the API endpoints, the service classes, the database schemas and the feature flags.
Factory divides the work between specialized agents. Each agent gets one part of the repository. Each agent gets sufficient context to write one good page. This method prevents a known problem: one agent alone writes poor documentation for a large repository.
Factory keeps the wiki correct with infrastructure, and not with discipline. The /wiki command makes the wiki again. The /install-wiki command writes a CI workflow. This workflow makes the wiki again at each push to the default branch. For GitHub, the wiki goes into the wiki tab of the repository (Factory Docs).
LangChain: OpenWiki, and the leap from code to everything
LangChain released OpenWiki as open-source software. OpenWiki is a CLI tool. It writes and maintains agent documentation for a codebase. LangChain then released OpenWiki Brains, which has two modes. Code Brain is the first mode, for a repository. Personal Brain is the second mode, for your own sources (LangChain).
Personal Brain is the important change. It reads data from Gmail, Notion, git repositories, X, Hacker News and web search. It writes all of this data into one local markdown wiki. The agent reads this wiki. The method changed from documentation of a repository to documentation of your work.
Each team made the same decision about the output. The output is not text for a person to read. The output is structured markdown for LLM context. It has headings, links between pages, and summaries. The structure lets an agent find the related information quickly. The reader of the wiki is a model.
GBrain: the personal-scale open-source version
GBrain applies the method to a personal knowledge store, and not to a codebase. GBrain uses markdown in a git repository. It has a schema file. It makes a graph of links between subjects automatically.
GBrain shows that the method needs very little infrastructure. It has no vector database. It has no service. It has files. A model maintains the files. A person can read the files.
## The technique matrix
The four systems have the same structure. They use markdown in git. They use a schema file. They compile at ingest. They make the wiki again when the sources change. They write the pages for an agent to read. Four teams solved four different problems and made the same structure. This agreement is good evidence that the structure is correct.
The systems are different in maintenance. Factory does the maintenance in CI. The other three systems do the maintenance when a person runs a command. Their wikis are thus only as correct as the last command.
## Where it stops
Limit 1 is size. Karpathy gives this limit. The method without embeddings is correct for approximately 100 sources. For more pages, you must add a search engine. The gist tells you to use BM25 search and vector search together.
Limit 2 is accuracy. The model compiles the information at ingest. An early summary can remove a detail from the source. Each later answer has this error. Retrieval from the raw parts does not have this problem. You exchange the cost of repeated work for the risk of lost data.
Limit 3 is old information. A page is only as correct as the last update. This is the reason that the Factory method is important. An incorrect wiki is worse than no wiki. The incorrect information has the format of correct information.
Limit 4 is cost. You pay tokens to make pages. You can make pages that nobody reads. You also pay tokens to lint pages that did not change.
## A wiki is not memory
There is one difference that you must know. The words in this field are not yet precise.
Many people call these systems memory. LangChain calls OpenWiki a wiki memory layer for AI agents. Other people say that a wiki gives memory to an agent. The word memory has two different meanings here.
The first meaning is knowledge of a document set. A wiki does this. It compiles the data in your documents, your repository or your Gmail. It tells you what the documents contain.
The second meaning is memory of a user. This is different data. It includes the preferences of a person. It includes the decisions of a person. It includes the methods that a team rejected. It includes the result when an agent tried a method in a different application.
Memory of a user has a different structure. It is related to a person, and not to a document set. It comes from interaction, and not from ingest. It must also do these tasks for each user: correct information that disagrees, remove information that is too old, keep the source of each item, and delete data on request.
A wiki does the first task correctly. A wiki does not do the second task. Your Gmail wiki tells the agent what is in your Gmail. It does not tell the agent that you changed a decision in a conversation on Tuesday. It does not tell the agent that a method already failed for you.
A memory layer does the second task. Mem0 is an example. It keeps each memory with a user_id. The memory thus moves with the person between sessions, applications and agents. It changes a fact in position when the fact changes. It does not add a new record each time.
The two systems are not alternatives. Use both. The error is not to use a wiki. The error is to think that a wiki gives you memory of a user.
## Summary
The idea in agent wikis is correct. Compile the knowledge one time. Then keep it correct. Do not build it again for each question. The maintenance stopped human wikis, and a model does the maintenance at no cost. Four teams built the same structure in a few months. This is strong evidence.
Do these three things. Compile your documents into pages when the document set is stable and you read it frequently. Add retrieval when the document set becomes large, as the gist tells you. Keep the difference between knowledge of a document set and memory of a user. A wiki gives you the first. A wiki does not give you the second.
In Context #17
This blog is part of In Context, a @mem0ai blog series covering AI Agent memory and context engineering.
Mem0 is an intelligent, open-source memory layer designed for LLMs and AI agents to provide long-term, personalized, and context-aware interactions across sessions.
- Get your free API Key here: app.mem0.ai
- or self-host mem0 from our open source github repository
## References
- Andrej Karpathy, LLM Wiki (GitHub Gist, April 2026)
- qmd: local hybrid BM25/vector search for markdown
- Cognition, DeepWiki: AI docs for any repo
- Devin Docs, DeepWiki
- Factory, Introducing AutoWiki
- Factory Documentation, AutoWiki overview
- langchain-ai/openwiki (GitHub)
- LangChain, Wiki Memory
- garrytan/gbrain (GitHub)
- Vannevar Bush, As We May Think (The Atlantic, 1945)
- Mem0
## 相关链接
- [mem0](https://x.com/mem0ai)
- [@mem0ai](https://x.com/mem0ai)
- [183K](https://x.com/mem0ai/status/2079585032587694582/analytics)
- [github.com](https://github.com/)
- [deepwiki.com](https://deepwiki.com/)
- [@mem0ai](https://x.com/@mem0ai)
- [app.mem0.ai](https://app.mem0.ai/?utm_source=x_article_mem0&utm_medium=x_article&utm_campaign=agent_wiki&utm_content=agent_wiki)
- [open source github repository](https://github.com/mem0ai/mem0)
- [Andrej Karpathy, LLM Wiki (GitHub Gist, April 2026)](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)
- [qmd: local hybrid BM25/vector search for markdown](https://github.com/tobi/qmd)
- [Cognition, DeepWiki: AI docs for any repo](https://cognition.com/blog/deepwiki)
- [Devin Docs, DeepWiki](https://docs.devin.ai/work-with-devin/deepwiki)
- [Factory, Introducing AutoWiki](https://factory.ai/news/wiki)
- [Factory Documentation, AutoWiki overview](https://docs.factory.ai/cli/features/wiki/overview)
- [langchain-ai/openwiki (GitHub)](https://github.com/langchain-ai/openwiki)
- [LangChain, Wiki Memory](https://www.langchain.com/blog/wiki-memory)
- [garrytan/gbrain (GitHub)](https://github.com/garrytan/gbrain)
- [Vannevar Bush, As We May Think (The Atlantic, 1945)](https://www.theatlantic.com/magazine/archive/1945/07/as-we-may-think/303881/)
- [Mem0](https://mem0.ai/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:11 PM · Jul 21, 2026](https://x.com/mem0ai/status/2079585032587694582)
- [183.5K Views](https://x.com/mem0ai/status/2079585032587694582/analytics)
- [View quotes](https://x.com/mem0ai/status/2079585032587694582/quotes)
---
*导出时间: 2026/7/23 15:33:25*
---
## 中文翻译
# Agent Wiki 的现状
**作者**: mem0
**日期**: 2026-07-21T15:11:23.000Z
**来源**: [https://x.com/mem0ai/status/2079585032587694582](https://x.com/mem0ai/status/2079585032587694582)
---
2026 年 4 月，Andrej Karpathy 写了一个 GitHub Gist。他在其中描述了一种方法。他称这种方法为 LLM Wiki。
在那之后，有四个团队构建了同样的东西。Cognition 构建了 DeepWiki。Factory 构建了 AutoWiki。LangChain 发布了 OpenWiki。Garry Tan 发布了 GBrain。
这四个系统中的方法是相同的。LLM 会读取你的源文档一次。它将信息写入 markdown 页面。当源文件发生变化时，它会保持页面的正确性。Agent 会读取这些页面。Agent 不会为了每个问题再次读取源文档。
人们将这些系统称为 agent wikis。本文将告诉你它们是什么。它将告诉你每个团队构建了什么。它将告诉你这种方法的局限性。它还将告诉你许多人忽略的一个重要区别。
## 核心理念：在摄取时编译，而不是在查询时
给模型提供大量文档的常规方法是检索。你将文档放入数据库。你将文档分成若干部分。你为这些部分制作嵌入。对于每个问题，系统会找到相关的部分。
这种方法是可行的。但它也有一个问题。系统不保存结果。它每次都从原始部分重新构建答案。第十个答案并不比第一个答案好。你付出了十次工作的代价。
Agent wiki 转移了这种代价。模型在读取源文件时做一次工作。它将结果写入页面。页面被保留下来。
当新源文件进入时，模型会执行这些步骤。它读取源文件。它更改相关的页面。它更正摘要。它标记与页面不一致的信息。
两种方法都是正确的。它们在两个方面有所不同。第一个区别在于你何时付出代价。第二个区别在于问题之后留下了什么。
每个系统都有相同的三个层级。
第一层是源文档。这些是你的文章、论文和代码库。模型读取它们。模型不更改它们。
第二层是 wiki。Wiki 是 markdown 格式的。模型编写所有的 wiki 内容。Wiki 包含摘要、每个主题的页面以及页面之间的链接。
第三层是 schema 文件。该文件告诉模型 wiki 的结构。它还告诉模型要执行哪些任务。常见的文件是 CLAUDE.md 或 AGENTS.md。该文件使模型成为 wiki 的正确维护者。
该系统执行三种操作。
摄取：模型读取一个新的源文件。然后模型将数据写入每个相关的页面。
查询：你向 wiki 提问。你可以将一个好的答案作为新页面写回 wiki。
检查：模型检查 wiki。它发现不一致的信息。它发现过时的信息。它发现没有链接的页面。
## 为什么它有效：
人类 wiki 会随着时间的推移变得不准确。原因是特定的。困难的部分不在于读取源文件。困难的部分不在于拥有想法。困难的部分在于维护。
维护包括这些任务。你必须更正页面之间的链接。你必须保持摘要的正确性。你必须将每个新文档与现有页面进行比较。
这项工作不会停止。这项工作没有回报。忙碌的团队首先停止这项工作。然后 wiki 变得不准确。然后人们不再使用它。
模型做这项工作没有任何问题。模型不会感到厌倦。模型不会忘记一个链接。模型可以在一次操作中更改十五个文件。
这个想法并不新鲜。Vannevar Bush 在 1945 年描述了 Memex。Memex 是一个带有链接的个人文档存储库。Bush 对维护问题没有给出答案。模型就是答案。
## 名称的由来
直接阅读 Karpathy 的 gist。它比关于它的摘要更准确。
他这样写常规方法：“LLM 在每个问题上都在从头重新发现知识。没有积累。”
他的方法是编译信息，而不是检索信息。然后“知识被编译一次并保持最新，而不是在每次查询时重新推导。”结果是“一个持久的、复利的产物。”
你不编写 wiki。他写道：“你从不（或很少）自己编写 wiki，LLM 编写并维护所有内容。”他一起使用 agent 和 Obsidian。他写道：“Obsidian 是 IDE；LLM 是程序员；wiki 是代码库。”
该 gist 对大小给出了一个限制。许多摘要不包括这个限制。没有嵌入的方法“在中等规模（约 100 个来源，约数百页）下出奇地有效，并且避免了对基于嵌入的 RAG 基础设施的需求。”
对于更多的来源，gist 告诉你添加搜索。它以 qmd 为例。该 gist 将 qmd 描述为“一个具有混合 BM25/向量搜索和 LLM 重排序的本地 markdown 文件搜索引擎。”
因此规则是关于大小的。规则不是关于替换的。当源集较小时，不要使用检索基础设施。当源集变大时，添加检索。
## 各实验室实际构建了什么
这就是模式停止成为想法并变为工程的地方，实现之间的差异是有用的部分。
Cognition：DeepWiki，作为公共设施的 wiki
Cognition 将该方法应用于 GitHub 上的公共存储库。在公共存储库的 URL 中将 github.com 替换为 deepwiki.com。你就会获得该代码库的 wiki。该 wiki 包含架构摘要、文件索引、依赖关系图和搜索。该 wiki 包含指向源的链接（Cognition）。
超过 50,000 个最大的公共存储库都有 wiki。列表包括 MCP 和 LangChain。
第二点更重要。Wiki 不是产品。Wiki 是 agent 的检索基础设施。Devin 使用 wiki 在代码库中查找相关代码。因此，DeepWiki 是 Devin 中代码搜索下方的编译层（Devin Docs）。
Factory：AutoWiki，文档作为构建产物
Factory 将该方法应用于持续集成。Factory 写道，文档必须是一个构建产物，而不是一个独立的项目。文档来自源。它具有代码库的结构。它在存储库更改时更改（Factory）。
生成 wiki 的方法有两个阶段。第一阶段是结构扫描。它读取 README 文件、包清单、CI 配置和入口点。第二阶段是语义扫描。它读取路由、API 端点、服务类、数据库模式和功能标志。
Factory 将工作分配给专门的 agents。每个 agent 获取存储库的一部分。每个 agent 获得足够的上下文来编写一个好的页面。这种方法防止了一个已知的问题：一个 agent 单独为大型存储库编写糟糕的文档。
Factory 通过基础设施而不是通过纪律来保持 wiki 的正确性。/wiki 命令再次生成 wiki。/install-wiki 命令编写一个 CI 工作流。该工作流在每次推送到默认分支时再次生成 wiki。对于 GitHub，wiki 进入存储库的 wiki 选项卡（Factory Docs）。
LangChain：OpenWiki，以及从代码到一切的飞跃
LangChain 发布了 OpenWiki 作为开源软件。OpenWiki 是一个 CLI 工具。它为代码库编写和维护 agent 文档。然后 LangChain 发布了 OpenWiki Brains，它有两种模式。Code Brain 是第一种模式，用于存储库。Personal Brain 是第二种模式，用于你自己的源（LangChain）。
Personal Brain 是重要的变化。它从 Gmail、Notion、git 存储库、X、Hacker News 和网络搜索读取数据。它将所有这些数据写入一个本地 markdown wiki。Agent 读取这个 wiki。方法从存储库的文档变成了你工作的文档。
每个团队对输出做出了相同的决定。输出不是供人阅读的文本。输出是供 LLM 上下文使用的结构化 markdown。它具有标题、页面之间的链接和摘要。该结构允许 agent 快速找到相关信息。Wiki 的读者是一个模型。
GBrain：个人级的开源版本
GBrain 将该方法应用于个人知识存储，而不是代码库。GBrain 在 git 存储库中使用 markdown。它有一个 schema 文件。它自动制作主题之间链接的图。
GBrain 表明该方法需要很少的基础设施。它没有向量数据库。它没有服务。它只有文件。模型维护文件。一个人可以读取文件。
## 技术矩阵
这四个系统具有相同的结构。它们在 git 中使用 markdown。它们使用一个 schema 文件。它们在摄取时编译。它们在源更改时再次生成 wiki。它们编写页面供 agent 阅读。四个团队解决了四个不同的问题并制作了相同的结构。这种一致性好地证明了该结构是正确的。
系统在维护方面有所不同。Factory 在 CI 中进行维护。其他三个系统在人员运行命令时进行维护。因此，它们的 wiki 仅与最后一次命令一样正确。
## 局限性在哪里
限制 1 是大小。Karpathy 给出了这个限制。没有嵌入的方法对于大约 100 个源是正确的。对于更多页面，你必须添加搜索引擎。该 gist 告诉你一起使用 BM25 搜索和向量搜索。
限制 2 是准确性。模型在摄取时编译信息。早期的摘要可能会删除源中的细节。每个后续答案都有这个错误。从原始部分的检索没有这个问题。你用重复工作的成本交换了数据丢失的风险。
限制 3 是过时的信息。页面仅与最后一次更新一样正确。这就是 Factory 方法很重要的原因。不正确的 wiki 比没有 wiki 更糟糕。不正确的信息具有正确信息的格式。
限制 4 是成本。你支付令牌来制作页面。你可以制作没人阅读的页面。你也支付令牌来检查没有更改的页面。
## Wiki 不是记忆
有一个你必须知道的区别。该领域的词汇还不精确。
许多人将这些系统称为记忆。LangChain 称 OpenWiki 为 AI agents 的 wiki 记忆层。其他人说 wiki 给 agent 提供记忆。记忆这个词在这里有两个不同的含义。
第一个含义是对文档集的知识。Wiki 做到了这一点。它编译你的文档、你的存储库或你的 Gmail 中的数据。它告诉你文档包含什么。
第二个含义是对用户的记忆。这是不同的数据。它包括一个人的偏好。它包括一个人的决定。它包括团队拒绝的方法。它包括 agent 在不同的应用程序中尝试方法时的结果。
用户记忆具有不同的结构。它与一个人相关，而不是与文档集相关。它来自交互，而不是来自摄取。它还必须为每个用户执行这些任务：更正不一致的信息，删除过时的信息，保留每个项目的来源，并根据要求删除数据。
Wiki 正确地执行第一项任务。Wiki 不执行第二项任务。你的 Gmail wiki 告诉 agent 你的 Gmail 里有什么。它不告诉 agent 你在星期二的对话中改变了一个决定。它不告诉 agent 一个方法对你来说已经失败了。
记忆层执行第二项任务。Mem0 是一个例子。它用 user_id 保留每条记忆。因此，记忆随人在会话、应用程序和 agents 之间移动。当事实发生变化时，它更改位置中的事实，而不是每次都添加一条新记录。
这两个系统不是替代品。两者都使用。错误不在于不使用 wiki。错误在于认为 wiki 给你用户提供记忆。
## 总结
Agent wiki 中的想法是正确的。一次编译知识。然后保持正确。不要为每个问题重新构建它。维护阻止了人类 wiki，而模型以零成本进行维护。四个团队在几个月内构建了相同的结构。这是有力的证据。
做这三件事。当文档集稳定且你经常阅读它时，将你的文档编译成页面。当文档集变大时，添加检索，正如 gist 所告诉你的。保持对文档集的知识和用户的记忆之间的区别。Wiki 给你前者。Wiki 不给你后者。
In Context #17
本博客是 In Context 的一部分，这是一个 @mem0ai 博客系列，涵盖 AI Agent 记忆和上下文工程。
Mem0 是一个智能、开源的记忆层，专为 LLM 和 AI agents 设计，以在会话之间提供长期的、个性化的和上下文感知的交互。
- 在此处获取你的免费 API Key：app.mem0.ai
- 或从我们的开源 github 存储库自托管 mem0
## 参考文献
- Andrej Karpathy, LLM Wiki (GitHub Gist, April 2026)
- qmd: markdown 的本地混合 BM25/向量搜索
- Cognition, DeepWiki: 任何存储库的 AI 文档
- Devin Docs, DeepWiki
- Factory, Introducing AutoWiki
- Factory Documentation, AutoWiki overview
- langchain-ai/openwiki (GitHub)
- LangChain, Wiki Memory
- garrytan/gbrain (GitHub)
- Vannevar Bush, As We May Think (The Atlantic, 1945)
- Mem0
## 相关链接
- [mem0](https://x.com/mem0ai)
- [@mem0ai](https://x.com/mem0ai)
- [183K](https://x.com/mem0ai/status/2079585032587694582/analytics)
- [github.com](https://github.com/)
- [deepwiki.com](https://deepwiki.com/)
- [@mem0ai](https://x.com/@mem0ai)
- [app.mem0.ai](https://app.mem0.ai/?utm_source=x_article_mem0&utm_medium=x_article&utm_campaign=agent_wiki&utm_content=agent_wiki)
- [open source github repository](https://github.com/mem0ai/mem0)
- [Andrej Karpathy, LLM Wiki (GitHub Gist, April 2026)](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)
- [qmd: local hybrid BM25/vector search for markdown](https://github.com/tobi/qmd)
- [Cognition, DeepWiki: AI docs for any repo](https://cognition.com/blog/deepwiki)
- [Devin Docs, DeepWiki](https://docs.devin.ai/work-with-devin/deepwiki)
- [Factory, Introducing AutoWiki](https://factory.ai/news/wiki)
- [Factory Documentation, AutoWiki overview](https://docs.factory.ai/cli/features/wiki/overview)
- [langchain-ai/openwiki (GitHub)](https://github.com/langchain-ai/openwiki)
- [LangChain, Wiki Memory](https://www.langchain.com/blog/wiki-memory)
- [garrytan/gbrain (GitHub)](https://github.com/garrytan/gbrain)
- [Vannevar Bush, As We May Think (The Atlantic, 1945)](https://www.theatlantic.com/magazine/archive/1945/07/as-we-may-think/303881/)
- [Mem0](https://mem0.ai/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:11 PM · Jul 21, 2026](https://x.com/mem0ai/status/2079585032587694582)
- [183.5K Views](https://x.com/mem0ai/status/2079585032587694582/analytics)
- [View quotes](https://x.com/mem0ai/status/2079585032587694582/quotes)
---
*导出时间: 2026/7/23 15:33:25*