# 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 published a GitHub Gist describing a pattern he called the LLM Wiki.
In the months since, four different teams have shipped the same idea without coordinating: @cognition built DeepWiki, @FactoryAI built AutoWiki, @Langchain open-sourced OpenWiki, and Garry Tan open-sourced GBrain. Different companies, different users, one architecture.
An LLM reads a body of sources, compiles them into a maintained set of markdown pages, and keeps those pages current as the sources change. Agents then read the pages instead of re-deriving everything from raw material on every question.
The pattern has become a category, and the systems built on it are increasingly just called agent wikis. This is what it actually is, what each team built, where it breaks, and the one thing it is repeatedly mistaken for.
## The idea: compile at ingest, not at query
Start with the problem, because the pattern is a direct answer to it.
The default way to give a model a body of knowledge is retrieval. You upload documents, chunk and embed them, and at query time you fetch the relevant chunks and answer. It works, and it has a structural flaw: nothing accumulates. Every question starts from raw chunks, so the model re-derives the same understanding again and again, and the tenth question about a codebase is no cheaper or better informed than the first.
The LLM Wiki inverts when the synthesis happens. Instead of assembling knowledge at query time from raw pieces, an LLM assembles it once at ingest time into durable pages, then maintains them. When a new source arrives, the model reads it, updates the entity pages it touches, revises summaries, and flags contradictions with what was already written.
RAG re-derives knowledge on every question. A wiki derives it once and then keeps it current. Both are legitimate; they differ in when you pay the synthesis cost and whether the result survives.
The architecture is consistently three layers. Raw sources are immutable: articles, papers, repositories, data. The model reads them and never edits them. The wiki is LLM-generated markdown the model owns entirely: summaries, entity pages, concept pages, cross-references. The schema is a configuration file (CLAUDE.md, AGENTS.md, or similar) that tells the model how the wiki is organized and what workflows to run, which is what makes it a disciplined maintainer rather than a chatbot with file access.
Three operations run on top: ingest a source and file it across the pages it affects, query the wiki (and optionally file good answers back as new pages, so exploration compounds too), and lint, a periodic pass hunting contradictions, stale claims, and orphaned pages.
## Why it works: the bottleneck was never the writing
Human wikis rot, and the reason is specific. The hard part was never reading the sources or having the insight. It was the bookkeeping: updating cross-references, keeping summaries current, reconciling a new document against forty existing pages. That work is unbounded, unglamorous, and the first thing a busy team drops. So the wiki decays, people stop trusting it, and it dies.
That is precisely the work a language model does not mind. It does not get bored, it does not forget to update a cross-reference, and it can touch fifteen files in one pass. The LLM Wiki works because it removes the maintenance cost that killed every wiki before it.
The idea is older than the tooling. Vannevar Bush described the Memex in 1945: a curated personal store of documents with associative trails between them. Bush's unsolved problem was who maintains the trails. The answer, eighty years later, is the model.
## Where the pattern got its name
Karpathy's gist is worth reading directly, because it is more precise than most summaries of it. His complaint about ordinary document workflows: "the LLM is rediscovering knowledge from scratch on every question. There's no accumulation." His alternative was to compile instead of retrieve, so that "the knowledge is compiled once and then kept current, not re-derived on every query," producing what he called "a persistent, compounding artifact."
Crucially, you do not write it. "You never (or rarely) write the wiki yourself, the LLM writes and maintains all of it." His own setup was the agent on one side and Obsidian on the other, watching pages update live: "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."
The gist is also specific about scale, which is the detail most worth carrying forward. The index-first approach with no embeddings "works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure." Past that, it recommends adding search, specifically qmd, described as "a local search engine for markdown files with hybrid BM25/vector search and LLM re-ranking."
That reads as a scoping rule rather than a replacement for retrieval. Skip the retrieval infrastructure while the corpus is small, and add it back as it grows. Compile-time and query-time synthesis sit on a spectrum, and where you land on it depends mostly on how much material you have.
The engineering question is what the pattern looks like past personal scale, which is what the last few months have answered.
## 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_labs took the pattern and pointed it at every public repository on GitHub. Swap github.com for deepwiki.com in any public repo URL and you get a generated, navigable wiki of that codebase: architecture overview, file index, dependency graph, and search, with links back to source (Source: Cognition).
Two things stand out. The scale is real: over 50,000 of the top public repositories are already indexed, from MCP to LangChain. And the wiki is not the product's endpoint, it is retrieval infrastructure for the agent. Devin uses the wiki to locate relevant context in a codebase, so DeepWiki is the compiled layer that makes Devin's code search better grounded (Source: Devin Docs).
Factory: AutoWiki, documentation as a build artifact
@FactoryAI framed the same pattern in CI terms, and their framing is the sharpest line in the category: documentation should be a build artifact, not a side project. It is built from source, organized around how the codebase actually works, and refreshed when the repo changes (Source: Factory).
The generation method is the most explicitly engineered of the four. AutoWiki runs a two-pass analysis: a structural scan of README, package manifests, CI config, and entry points, then a deeper semantic scan of routes, API endpoints, service classes, database schemas, and feature flags. The work is split across specialized agents, each scoped to one facet of the repository with just enough context to produce a good page, which is a direct answer to the context problem that makes single-agent documentation generation mediocre at scale.
Currency is handled as infrastructure rather than discipline: /wiki regenerates on demand, and /install-wiki writes a CI workflow that refreshes the wiki on every push to the default branch. For GitHub repos it syncs into the repository's own wiki tab (Source: Factory Docs).
LangChain: OpenWiki, and the leap from code to everything
@LangChainAI open-sourced OpenWiki as a CLI that writes and maintains agent documentation for a codebase, then expanded it into OpenWiki Brains with two modes: Code Brain, the original repository use case, and Personal Brain, which builds a wiki from your own connected sources (Source: LangChain).
That second mode is the significant move. Personal Brain ingests from Gmail, Notion, git repositories, X, Hacker News, and web search, and synthesizes them into a local markdown wiki the agent consults. The category jumped from "document my repo" to "compile my working life."
One design detail deserves attention because every team converged on it: the output is not prose for humans. It is structured markdown optimized for LLM context, with headings, cross-references, and summaries designed so an agent can find relevant context fast. The wiki is written for the reader that will actually read it, and that reader is a model.
GBrain: the personal-scale open-source version
Garry Tan's GBrain applies the same shape to a personal knowledge base rather than a codebase: markdown in a git repository, a schema file, and an automatically maintained graph of entity cross-links. It is the clearest demonstration that the pattern is substrate-simple. No vector database, no service, just files a model maintains and a human can read.
## The technique matrix
Read down the columns and the convergence is the signal. Four teams, four corpora, and one architecture: markdown in git, a schema file the model obeys, synthesis at ingest, refresh on change, and pages written for an agent to read. When independent teams solving different problems land on the same shape, the shape is usually right.
The divergence is about currency, and it is the tell for maturity. Factory treats staleness as a build problem and solves it in CI. Everyone else refreshes on demand, which means their wikis are exactly as current as the last time someone remembered to run the command.
## Where it stops
The pattern is genuinely good, which is why it needs honest limits.
Scale. Karpathy names it himself: index-first with no embeddings is a moderate-scale technique, roughly a hundred sources. Past a few hundred pages you are back to a search engine, which is why his own gist recommends hybrid BM25 and vector search.
Fidelity. Compiling at ingest means an early summary can quietly lose a detail from the source, and every later answer inherits that loss. Retrieval against raw chunks does not have this failure mode. You are trading re-derivation cost for compression risk.
Staleness. A compiled page is only as true as the last refresh. This is the whole reason Factory's CI framing matters more than it first appears: a wiki that is stale is worse than no wiki, because it is confidently wrong in a format that looks authoritative.
Compile cost. You pay real tokens up front to build pages you may never query, and to re-lint pages nothing changed about.
## A wiki is not memory
There is one distinction worth drawing carefully here, because the vocabulary in this space is still loose.
These systems are increasingly described as memory. LangChain calls OpenWiki a wiki memory layer for AI agents, and the general framing around the pattern is that this is how you give an agent memory. The word is carrying a lot of weight there, and it covers two quite different things.
Two axes are sitting under one term.
Corpus knowledge is what a wiki does: compile what a set of documents, or a repository, or your Gmail archive says. It answers "what does this body of material contain."
User and experience memory is the other axis: what a specific person prefers, what they decided last week, which approach their team already rejected, what an agent tried in a different app yesterday and how it turned out. It is scoped to an identity rather than a corpus, it accumulates from interaction rather than ingestion, and it has to handle contradiction, staleness, provenance, and deletion per user.
A wiki is excellent at the first and does not attempt the second. Compiling your Gmail into pages tells an agent what is in your Gmail. It does not tell the agent that you changed your mind about the vendor decision in a conversation last Tuesday, or that a suggested approach already failed for you once.
That second axis is what a dedicated memory layer like Mem0 is for: memory tagged to a user_id so it follows a person across sessions, apps, and agents, updated in place when facts change rather than appended forever. The two are complementary, and the mistake is not choosing a wiki. The mistake is believing you have solved memory because you compiled a corpus.
## The takeaway
The LLM Wiki is a real pattern with a real insight behind it: knowledge should be compiled once and maintained, not re-derived on every question, and the maintenance that killed human wikis is exactly the labor a model performs for free. Four teams shipping the same architecture in months is the strongest evidence it is correct.
Take three things from it. Compile your documents into maintained pages when the corpus is stable and re-read often. Add real retrieval as it grows past personal scale, which the original formulation recommends as well. And keep the distinction between compiling a corpus and remembering a user, because a wiki gives you the first and not the second. That is worth a lot, and it is not the same thing.
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)
- [29K](https://x.com/mem0ai/status/2079585032587694582/analytics)
- [@cognition](https://x.com/@cognition)
- [@FactoryAI](https://x.com/@FactoryAI)
- [@Langchain](https://x.com/@Langchain)
- [qmd](https://github.com/tobi/qmd)
- [@cognition_labs](https://x.com/@cognition_labs)
- [github.com](https://github.com/)
- [deepwiki.com](https://deepwiki.com/)
- [Cognition](https://cognition.com/blog/deepwiki)
- [Devin Docs](https://docs.devin.ai/work-with-devin/deepwiki)
- [@FactoryAI](https://x.com/@FactoryAI)
- [Factory](https://factory.ai/news/wiki)
- [Factory Docs](https://docs.factory.ai/cli/features/wiki/overview)
- [@LangChainAI](https://x.com/@LangChainAI)
- [LangChain](https://github.com/langchain-ai/openwiki)
- [Mem0](https://mem0.ai/)
- [@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)
- [29K Views](https://x.com/mem0ai/status/2079585032587694582/analytics)
- [View quotes](https://x.com/mem0ai/status/2079585032587694582/quotes)
---
*导出时间: 2026/7/22 08:38:52*
---
## 中文翻译
# 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，@FactoryAI 构建了 AutoWiki，@Langchain 开源了 OpenWiki，Garry Tan 开源了 GBrain。不同的公司，不同的用户，同一种架构。
一个 LLM 读取一组来源，将其编译成一组维护好的 markdown 页面，并随着来源的变化保持这些页面的最新状态。然后，Agent 读取这些页面，而不是在每个问题上都从原始材料重新推导一切。
这种模式已经演变成一个类别，基于此构建的系统越来越多地被简单地称为 agent wiki。这就是它的本质，每个团队构建了什么，它在哪里失效，以及它反复被误解的一点。
## 核心理念：在摄入时编译，而不是在查询时
从问题开始，因为这种模式是对问题的直接回答。
给模型提供知识主体的默认方式是检索。你上传文档，将其分块并嵌入，在查询时获取相关块并回答。这行得通，但存在一个结构性缺陷：没有任何积累。每个问题都从原始块开始，因此模型一次又一次地重新推导相同的理解，关于代码库的第十个问题并不比第一个更便宜或更有依据。
LLM Wiki 颠覆了综合发生的时间。不是在查询时从原始片段组装知识，LLM 在摄入时一次性将其组装成持久的页面，然后对其进行维护。当新来源到达时，模型读取它，更新其触及的实体页面，修订摘要，并标记与已编写内容的矛盾。
RAG 在每个问题上重新推导知识。Wiki 只推导一次，然后保持其最新。两者都是合理的；它们区别在于你何时支付综合成本，以及结果是否得以保留。
架构始终分为三层。原始来源是不可变的：文章、论文、存储库、数据。模型读取它们但从不编辑它们。Wiki 是 LLM 生成的 markdown，模型完全拥有它：摘要、实体页面、概念页面、交叉引用。Schema 是一个配置文件（CLAUDE.md、AGENTS.md 或类似文件），它告诉模型 Wiki 是如何组织的以及运行什么工作流，这正是使其成为有纪律的维护者而不是具有文件访问权限的聊天机器人的原因。
在顶层运行三个操作：摄入来源并将其归档到受影响的页面中，查询 Wiki（并可选择将好的答案作为新页面归档回去，以便探索也能复合增长），以及 Lint，这是一个定期运行的过程，用于查找矛盾、过时的声明和孤立的页面。
## 为什么有效：瓶颈从来都不是写作
人类 Wiki 会腐朽，原因很具体。困难的部分从来都不是阅读来源或拥有洞察力。而是文书工作：更新交叉引用，保持摘要最新，将新文档与四十个现有页面进行协调。这项工作是无限的、不起眼的，也是忙碌的团队首先放弃的事情。因此 Wiki 衰退，人们停止信任它，然后它就消亡了。
这正是语言模型不介意的工作。它不会感到无聊，它不会忘记更新交叉引用，并且它可以在一次操作中处理十五个文件。LLM Wiki 之所以有效，是因为它消除了扼杀之前每个 Wiki 的维护成本。
这个想法比工具更古老。Vannevar Bush 在 1945 年描述了 Memex：一个精选的个人文档存储，其间有联想轨迹。Bush 未解决的问题是谁维护这些轨迹。八十年后，答案是模型。
## 这个模式的名称来源
Karpathy 的 Gist 值得直接阅读，因为它比大多数摘要更精确。他对普通文档工作流的抱怨：“LLM 在每个问题上都从头开始重新发现知识。没有积累。”他的替代方案是编译而不是检索，以便“知识只编译一次然后保持最新，而不是在每次查询时重新推导”，从而产生他所谓的“一个持久的、复合的制品”。
至关重要的是，你不是编写它。“你从不（或很少）自己编写 Wiki，LLM 编写并维护所有内容。”他自己的设置是一边是 agent，另一边是 Obsidian，观察页面实时更新：“Obsidian 是 IDE；LLM 是程序员；Wiki 是代码库。”
该 Gist 也具体说明了规模，这是最值得继承的细节。无嵌入的索引优先方法“在中等规模（约 100 个来源，约数百页）下出奇地有效，并且避免了基于嵌入的 RAG 基础设施的需求。”除此之外，它建议添加搜索，特别是 qmd，被描述为“一个具有混合 BM25/向量搜索和 LLM 重排序的 markdown 文件本地搜索引擎”。
这读起来更像是一个范围规则，而不是检索的替代方案。当语料库很小时，跳过检索基础设施，随着其增长再添加回来。编译时和查询时的综合处于一个频谱上，你落在何处主要取决于你有多少材料。
工程问题在于这种模式在个人规模之外是什么样子的，这是过去几个月已经回答的问题。
## 实验室实际上构建了什么
这是模式停止成为一个想法并变成工程的地方，实现之间的差异是有用的部分。
Cognition：DeepWiki，作为公共设施的 Wiki
@cognition_labs 采用了这种模式并将其指向 GitHub 上的每个公共存储库。在任何公共存储库 URL 中将 github.com 换成 deepwiki.com，你就会获得该代码库生成的、可导航的 Wiki：架构概述、文件索引、依赖关系图和搜索，以及回源链接（来源：Cognition）。
有两点很突出。规模是真实的：超过 50,000 个顶级公共存储库已经被索引，从 MCP 到 LangChain。而且 Wiki 不是产品的终点，它是 agent 的检索基础设施。Devin 使用 Wiki 在代码库中定位相关上下文，因此 DeepWiki 是使 Devin 的代码搜索更有根据的编译层（来源：Devin Docs）。
Factory：AutoWiki，作为构建产物的文档
@FactoryAI 用 CI 术语构建了相同的模式，他们的框架是类别中最清晰的线条：文档应该是构建产物，而不是副业项目。它从源构建，围绕代码库的实际工作方式组织，并在存储库更改时刷新（来源：Factory）。
生成方法是四个中最明确工程化的。AutoWiki 运行两遍分析：对 README、包清单、CI 配置和入口点的结构扫描，然后是对路由、API 端点、服务类、数据库模式和功能标志的更深层次的语义扫描。工作被分配给专门的 agent，每个 agent 的范围仅限于存储库的一个方面，具有足够的上下文来生成一个好的页面，这是对使单 agent 文档生成在规模上平庸的上下文问题的直接回答。
新鲜度作为基础设施而不是纪律来处理：/wiki 按需重新生成，/install-wiki 编写一个 CI 工作流，在每次推送到默认分支时刷新 Wiki。对于 GitHub 存储库，它同步到存储库自己的 Wiki 选项卡（来源：Factory Docs）。
LangChain：OpenWiki，以及从代码到一切的飞跃
@LangChainAI 开源了 OpenWiki 作为一个 CLI，用于编写和维护代码库的 agent 文档，然后将其扩展到具有两种模式的 OpenWiki Brains：Code Brain，原始的存储库用例，以及 Personal Brain，它从你自己的连接来源构建 Wiki（来源：LangChain）。
第二种模式是重要的一步。Personal Brain 从 Gmail、Notion、git 存储库、X、Hacker News 和网络搜索中摄取，并将它们综合成 agent 咨询的本地 markdown Wiki。该类别从“记录我的存储库”跳到了“编译我的工作生活”。
一个设计细节值得注意，因为每个团队都达成了共识：输出不是给人类的散文。它是为 LLM 上下文优化的结构化 markdown，具有标题、交叉引用和摘要，旨在让 agent 能够快速找到相关上下文。Wiki 是为真正会阅读它的读者编写的，而那个读者是模型。
GBrain：个人规模的开源版本
Garry Tan 的 GBrain 将相同的形状应用于个人知识库而不是代码库：git 存储库中的 markdown，一个 schema 文件，以及一个自动维护的实体交叉链接图。这是该模式在底层上最清晰的演示。没有向量数据库，没有服务，只有模型维护的文件和人类可以阅读的文件。
## 技术矩阵
向下阅读列，趋同性就是信号。四个团队，四个语料库，一种架构：git 中的 markdown，模型遵守的 schema 文件，摄入时综合，更改时刷新，以及为 agent 阅读而编写的页面。当解决不同问题的独立团队落在相同的形状上时，该形状通常是正确的。
分歧在于新鲜度，它是成熟的标志。Factory 将过时视为构建问题并在 CI 中解决。其他人按需刷新，这意味着他们的 Wiki 的新鲜程度完全取决于某人上次记得运行命令的时间。
## 它在哪里停止
这种模式确实很好，这就是为什么它需要诚实的限制。
规模。Karpathy 自己点名：无嵌入的索引优先是一种中等规模的技术，大约一百个来源。超过几百页，你又回到了搜索引擎，这就是为什么他自己的 Gist 建议使用混合 BM25 和向量搜索。
保真度。在摄入时编译意味着早期的摘要可能会悄悄丢失源中的细节，随后的每个答案都会继承这种丢失。针对原始块的检索没有这种失败模式。你是在用重新推导的成本换取压缩风险。
过时。编译的页面只有在最后一次刷新时才是真实的。这就是为什么 Factory 的 CI 框架比最初看起来更重要的全部原因：过时的 Wiki 比 Wiki 更糟糕，因为它以一种看起来权威的格式自信地出错。
编译成本。你预先支付真实的 token 来构建你可能永远不会查询的页面，以及重新 lint 没有任何变化的页面。
## Wiki 不是记忆
这里有一个值得仔细区分的区别，因为这个领域的词汇仍然很松散。
这些系统越来越多地被描述为记忆。LangChain 称 OpenWiki 为 AI agent 的 Wiki 记忆层，并且围绕该模式的一般框架是这是你如何给 agent 记忆。这个词在那里承载了很大的重量，它涵盖了两个截然不同的事物。
两个轴位于一个术语之下。
语料库知识是 Wiki 所做的：编译一组文档、存储库或你的 Gmail 档案所说的内容。它回答“这个材料主体包含什么”。
用户和体验记忆是另一个轴：特定的人喜欢什么，他们上周决定什么，他们的团队已经拒绝了哪种方法，agent 昨天在不同的应用程序中尝试了什么以及结果如何。它的范围是身份而不是语料库，它从交互而不是摄入中积累，并且它必须按用户处理矛盾、过时、来源和删除。
Wiki 擅长第一种，不尝试第二种。将你的 Gmail 编译成页面告诉 agent 你的 Gmail 里有什么。它不告诉 agent 你在周二的对话中改变了关于供应商决定的想法，或者建议的方法对你来说已经失败过一次。
第二个轴是像 Mem0 这样的专用记忆层的用途：标记给 user_id 的记忆，以便它跟随一个人跨会话、应用程序和 agent，当事实发生变化时原地更新而不是永远追加。两者是互补的，错误不在于选择 Wiki。错误在于认为你因为编译了语料库就解决了记忆。
## 总结
LLM Wiki 是一个真正的模式，背后有真正的洞察：知识应该编译一次并维护，而不是在每个问题上重新推导，而扼杀人类 Wiki 的维护正是模型免费执行的劳动。四个团队在几个月内发布相同的架构是它正确的最有力的证据。
从中获得三件事。当语料库稳定且经常重读时，将文档编译成维护的页面。当它超过个人规模时添加真正的检索，原始公式也建议这样做。并保持编译语料库和记住用户之间的区别，因为 Wiki 给你前者而不是后者。这很有价值，并且不是同一件事。
In Context #17
这个博客是 In Context 的一部分，这是一个 @mem0ai 博客系列，涵盖 AI Agent 记忆和上下文工程。
Mem0 是一个智能的、开源的记忆层，专为 LLM 和 AI agent 设计，以提供跨会话的长期、个性化和上下文感知的交互。
- 在这里获取你的免费 API Key：app.mem0.ai
- 或从我们的开源 github 存储库自托管 mem0
## 参考文献
- 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)
- [29K](https://x.com/mem0ai/status/2079585032587694582/analytics)
- [@cognition](https://x.com/@cognition)
- [@FactoryAI](https://x.com/@FactoryAI)
- [@Langchain](https://x.com/@Langchain)
- [qmd](https://github.com/tobi/qmd)
- [@cognition_labs](https://x.com/@cognition_labs)
- [github.com](https://github.com/)
- [deepwiki.com](https://deepwiki.com/)
- [Cognition](https://cognition.com/blog/deepwiki)
- [Devin Docs](https://docs.devin.ai/work-with-devin/deepwiki)
- [@FactoryAI](https://x.com/@FactoryAI)
- [Factory](https://factory.ai/news/wiki)
- [Factory Docs](https://docs.factory.ai/cli/features/wiki/overview)
- [@LangChainAI](https://x.com/@LangChainAI)
- [LangChain](https://github.com/langchain-ai/openwiki)
- [Mem0](https://mem0.ai/)
- [@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](