Im April 2026 schrieb Andrej Karpathy einen GitHub Gist. Darin beschreibt er eine Methode. Er nennt sie das LLM Wiki.
Vier Teams bauten danach das Gleiche. Cognition baute DeepWiki. Factory baute AutoWiki. LangChain veröffentlichte OpenWiki. Garry Tan veröffentlichte GBrain.
Die Methode ist in allen vier Systemen gleich. Ein LLM liest deine Quelldokumente einmal. Es schreibt die Informationen in Markdown-Seiten. Es hält die Seiten aktuell, wenn sich die Quellen ändern. Der Agent liest diese Seiten. Der Agent liest die Quelldokumente nicht für jede Frage erneut.
Man nennt diese Systeme Agent-Wikis. Dieser Artikel erklärt, was sie sind. Er erklärt, was jedes Team gebaut hat. Er erklärt die Grenzen der Methode. Er erklärt auch einen wichtigen Unterschied, den viele übersehen.
Die Idee: Kompilieren beim Einlesen, nicht bei der Abfrage
Die übliche Methode, einem Modell eine große Menge an Dokumenten zu geben, ist das Retrieval. Du legst die Dokumente in einer Datenbank ab. Du teilst die Dokumente in Teile auf. Du erstellst Embeddings für die Teile. Für jede Frage findet das System die relevanten Teile.
Diese Methode funktioniert. Sie hat aber auch ein Problem. Das System behält die Ergebnisse nicht. Es baut jede Antwort aus den rohen Teilen von Neuem auf. Die zehnte Antwort ist nicht besser als die erste. Du zahlst die Kosten für die Arbeit zehnmal.
Ein Agent-Wiki verlagert diese Kosten. Das Modell erledigt die Arbeit einmal, wenn es die Quelle liest. Es schreibt die Ergebnisse in Seiten. Die Seiten bleiben bestehen.
Das Modell führt diese Schritte aus, wenn eine neue Quelle eingeht. Es liest die Quelle. Es ändert die zugehörigen Seiten. Es korrigiert die Zusammenfassungen. Es markiert Informationen, die mit den Seiten nicht übereinstimmen.
Beide Methoden sind korrekt. Sie unterscheiden sich in zwei Punkten. Der erste Unterschied ist, wann du die Kosten zahlst. Der zweite Unterschied ist, was nach der Frage bestehen bleibt.
Jedes System hat die gleichen drei Schichten.
Schicht 1 sind die Quelldokumente. Das sind deine Artikel, Papiere und Repositories. Das Modell liest sie. Das Modell verändert sie nicht.
Schicht 2 ist das Wiki. Das Wiki ist Markdown. Das Modell schreibt das gesamte Wiki. Das Wiki enthält Zusammenfassungen, Seiten für jedes Thema und Links zwischen den Seiten.
Schicht 3 ist die Schema-Datei. Diese Datei sagt dem Modell die Struktur des Wikis. Sie sagt dem Modell auch, welche Aufgaben es zu erledigen hat. Die übliche Datei ist CLAUDE.md oder AGENTS.md. Diese Datei macht das Modell zu einem korrekten Verwalter des Wikis.
Das System führt drei Operationen durch.
Einlesen: Das Modell liest eine neue Quelle. Dann schreibt das Modell die Daten auf jede zugehörige Seite.
Abfrage: Du stellst dem Wiki eine Frage. Du kannst eine gute Antwort als neue Seite zurück ins Wiki schreiben.
Lint: Das Modell untersucht das Wiki. Es findet Informationen, die widersprüchlich sind. Es findet Informationen, die zu alt sind. Es findet Seiten ohne Links.
Warum es funktioniert:
Menschliche Wikis werden mit der Zeit falsch. Die Ursache ist spezifisch. Der schwierige Teil ist nicht, die Quellen zu lesen. Der schwierige Teil ist nicht, die Ideen zu haben. Der schwierige Teil ist die Wartung.
Die Wartung hat diese Aufgaben. Du musst die Links zwischen den Seiten korrigieren. Du musst die Zusammenfassungen korrekt halten. Du musst jedes neue Dokument mit den vorhandenen Seiten vergleichen.
Diese Arbeit hört nie auf. Die Arbeit gibt keine Belohnung. Ein vielbeschäftigtes Team stellt diese Arbeit zuerst ein. Dann wird das Wiki falsch. Dann nutzen die Leute es nicht.
Ein Modell erledigt diese Arbeit ohne Probleme. Das Modell wird nicht gelangweilt. Das Modell vergisst keinen Link. Das Modell kann fünfzehn Dateien in einem Durchgang ändern.
Die Idee ist alt. Vannevar Bush beschrieb den Memex im Jahr 1945. Der Memex ist ein persönlicher Speicher von Dokumenten mit Links zwischen ihnen. Bush hatte keine Antwort für die Wartung. Das Modell ist die Antwort.
Woher der Name kommt
Lies den Karpathy-Gist direkt. Er ist genauer als die Zusammenfassungen davon.
Er schreibt dazu über die übliche Methode: „Das LLM entdeckt bei jeder Frage das Wissen von Grund auf neu. Es gibt keine Akkumulation."
Seine Methode ist, die Informationen zu kompilieren und nicht abzurufen. Dann „wird das Wissen einmal kompiliert und dann aktuell gehalten, nicht bei jeder Abfrage neu abgeleitet." Das Ergebnis ist „ein dauerhaftes, sich aufbauendes Artefakt."
Du schreibst das Wiki nicht. Er schreibt: „Du schreibst das Wiki nie (oder selten) selbst, das LLM schreibt und pflegt alles davon." Er verwendet den Agenten und Obsidian zusammen. Er schreibt: „Obsidian ist die IDE; das LLM ist der Programmierer; das Wiki ist die Codebasis."
Der Gist gibt eine Grenze für die Größe an. Viele Zusammenfassungen enthalten diese Grenze nicht. Die Methode ohne Embeddings „funktioniert überraschend gut in mittlerem Maßstab (~100 Quellen, ~hunderte Seiten) und vermeidet die Notwendigkeit einer Embedding-basierten RAG-Infrastruktur."
Für mehr Quellen sagt der Gist, dass du Suche hinzufügen sollst. Er gibt qmd als Beispiel. Der Gist beschreibt qmd als „eine lokale Suchmaschine für Markdown-Dateien mit hybridem BM25/Vector-Search und LLM-Re-Ranking."
Die Regel betrifft also die Größe. Die Regel betrifft nicht den Ersatz. Verwende keine Retrieval-Infrastruktur, wenn die Quellenmenge klein ist. Füge Retrieval hinzu, wenn die Quellenmenge groß wird.
Was die Labs tatsächlich gebaut haben
Hier hört das Muster auf, eine Idee zu sein, und wird zu Engineering, und die Unterschiede zwischen den Implementierungen sind der nützliche Teil.
Cognition: DeepWiki, das Wiki als öffentliches Dienstprogramm
Cognition wandte die Methode auf die öffentlichen Repositories auf GitHub an. Ersetze github.com mit deepwiki.com in der URL eines öffentlichen Repositorys. Du erhältst dann ein Wiki für diese Codebasis. Das Wiki hat eine Architekturzusammenfassung, einen Dateiindex, einen Abhängigkeitsgraphen und eine Suche. Das Wiki hat Links zur Quelle (Cognition).
Mehr als 50.000 der größten öffentlichen Repositories haben ein Wiki. Die Liste umfasst MCP und LangChain.
Der zweite Punkt ist wichtiger. Das Wiki ist nicht das Produkt. Das Wiki ist die Retrieval-Infrastruktur für den Agenten. Devin verwendet das Wiki, um den zugehörigen Code in einer Codebasis zu finden. DeepWiki ist somit die kompilierte Schicht unter der Codesuche in Devin (Devin Docs).
Factory: AutoWiki, Dokumentation als Build-Artefakt
Factory wandte die Methode auf kontinuierliche Integration an. Factory schreibt, dass Dokumentation ein Build-Artefakt sein muss, und kein separates Projekt. Die Dokumentation stammt aus der Quelle. Sie hat die Struktur der Codebasis. Sie ändert sich, wenn sich das Repository ändert (Factory).
Die Methode zur Erstellung des Wikis hat zwei Durchläufe. Durchlauf 1 ist ein struktureller Scan. Er liest die README-Datei, die Paketmanifeste, die CI-Konfiguration und die Einstiegspunkte. Durchlauf 2 ist ein semantischer Scan. Er liest die Routen, die API-Endpunkte, die Service-Klassen, die Datenbankschemata und die Feature-Flags.
Factory teilt die Arbeit zwischen spezialisierten Agenten auf. Jeder Agent bekommt einen Teil des Repositorys. Jeder Agent bekommt ausreichend Kontext, um eine gute Seite zu schreiben. Diese Methode verhindert ein bekanntes Problem: Ein einzelner Agent schreibt schlechte Dokumentation für ein großes Repository.
Factory hält das Wiki mit Infrastruktur korrekt, und nicht mit Disziplin. Der /wiki-Befehl erstellt das Wiki neu. Der /install-wiki-Befehl schreibt einen CI-Workflow. Dieser Workflow erstellt das Wiki bei jedem Push auf den Standard-Branch neu. Für GitHub geht das Wiki in den Wiki-Tab des Repositorys (Factory Docs).
LangChain: OpenWiki und der Sprung von Code zu allem
LangChain veröffentlichte OpenWiki als Open-Source-Software. OpenWiki ist ein CLI-Tool. Es schreibt und pflegt Agent-Dokumentation für eine Codebasis. LangChain veröffentlichte dann OpenWiki Brains, das zwei Modi hat. Code Brain ist der erste Modus, für ein Repository. Personal Brain ist der zweite Modus, für deine eigenen Quellen (LangChain).
Personal Brain ist die wichtige Änderung. Es liest Daten aus Gmail, Notion, Git-Repositories, X, Hacker News und Websuche. Es schreibt all diese Daten in ein lokales Markdown-Wiki. Der Agent liest dieses Wiki. Die Methode änderte sich von der Dokumentation eines Repositorys zur Dokumentation deiner Arbeit.
Jedes Team traf die gleiche Entscheidung bezüglich der Ausgabe. Die Ausgabe ist kein Text zum Lesen für einen Menschen. Die Ausgabe ist strukturiertes Markdown für LLM-Kontext. Es hat Überschriften, Links zwischen Seiten und Zusammenfassungen. Die Struktur ermöglicht es einem Agenten, die relevanten Informationen schnell zu finden. Der Leser des Wikis ist ein Modell.
GBrain: Die persönliche Open-Source-Version
GBrain wendet die Methode auf einen persönlichen Wissensspeicher an, und nicht auf eine Codebasis. GBrain verwendet Markdown in einem Git-Repository. Es hat eine Schema-Datei. Es erstellt automatisch einen Graphen von Links zwischen Themen.
GBrain zeigt, dass die Methode sehr wenig Infrastruktur benötigt. Es hat keine Vektordatenbank. Es hat keinen Dienst. Es hat Dateien. Ein Modell pflegt die Dateien. Ein Mensch kann die Dateien lesen.
Die Technik-Matrix
Die vier Systeme haben die gleiche Struktur. Sie verwenden Markdown in Git. Sie verwenden eine Schema-Datei. Sie kompilieren beim Einlesen. Sie erstellen das Wiki neu, wenn sich die Quellen ändern. Sie schreiben die Seiten für einen Agenten zum Lesen. Vier Teams lösten vier verschiedene Probleme und erstellten die gleiche Struktur. Diese Übereinstimmung ist ein guter Beleg dafür, dass die Struktur korrekt ist.
Die Systeme unterscheiden sich in der Wartung. Factory erledigt die Wartung in CI. Die anderen drei Systeme erledigen die Wartung, wenn eine Person einen Befehl ausführt. Ihre Wikis sind daher nur so korrekt wie der letzte Befehl.
Wo es aufhört
Grenze 1 ist die Größe. Karpathy gibt diese Grenze an. Die Methode ohne Embeddings ist für etwa 100 Quellen korrekt. Für mehr Seiten musst du eine Suchmaschine hinzufügen. Der Gist sagt dir, BM25-Suche und Vektorsuche zusammen zu verwenden.
Grenze 2 ist die Genauigkeit. Das Modell kompiliert die Informationen beim Einlesen. Eine frühe Zusammenfassung kann ein Detail aus der Quelle entfernen. Jede spätere Antwort enthält diesen Fehler. Das Retrieval aus den rohen Teilen hat dieses Problem nicht. Du tauschst die Kosten für wiederholte Arbeit gegen das Risiko von Datenverlust.
Grenze 3 sind veraltete Informationen. Eine Seite ist nur so korrekt wie die letzte Aktualisierung. Das ist der Grund, warum die Factory-Methode wichtig ist. Ein falsches Wiki ist schlimmer als kein Wiki. Die falsche Information hat das Format korrekter Information.
Grenze 4 sind die Kosten. Du zahlst Tokens, um Seiten zu erstellen. Du kannst Seiten erstellen, die niemand liest. Du zahlst auch Tokens, um Seiten zu linten, die sich nicht geändert haben.
Ein Wiki ist kein Gedächtnis
Es gibt einen Unterschied, den du kennen musst. Die Wörter in diesem Bereich sind noch nicht präzise.
Viele Leute nennen diese Systeme Gedächtnis. LangChain nennt OpenWiki eine Wiki-Gedächtnisschicht für KI-Agenten. Andere Leute sagen, dass ein Wiki einem Agenten Gedächtnis gibt. Das Wort Gedächtnis hat hier zwei verschiedene Bedeutungen.
Die erste Bedeutung ist Wissen über eine Dokumentenmenge. Ein Wiki macht das. Es kompiliert die Daten in deinen Dokumenten, deinem Repository oder deinem Gmail. Es sagt dir, was die Dokumente enthalten.
Die zweite Bedeutung ist Gedächtnis eines Benutzers. Das sind andere Daten. Es umfasst die Vorlieben einer Person. Es umfasst die Entscheidungen einer Person. Es umfasst die Methoden, die ein Team abgelehnt hat. Es umfasst das Ergebnis, wenn ein Agent eine Methode in einer anderen Anwendung ausprobiert hat.
Gedächtnis eines Benutzers hat eine andere Struktur. Es bezieht sich auf eine Person, und nicht auf eine Dokumentenmenge. Es kommt aus Interaktion, und nicht aus dem Einlesen. Es muss auch diese Aufgaben für jeden Benutzer erledigen: Widersprüchliche Informationen korrigieren, zu alte Informationen entfernen, die Quelle jedes Eintrags behalten und Daten auf Anfrage löschen.
Ein Wiki erledigt die erste Aufgabe korrekt. Ein Wiki erledigt die zweite Aufgabe nicht. Dein Gmail-Wiki sagt dem Agenten, was in deinem Gmail ist. Es sagt dem Agenten nicht, dass du am Dienstag in einem Gespräch eine Entscheidung geändert hast. Es sagt dem Agenten nicht, dass eine Methode bei dir bereits fehlgeschlagen ist.
Eine Gedächtnisschicht erledigt die zweite Aufgabe. Mem0 ist ein Beispiel. Es behält jede Erinnerung mit einer user_id. Die Erinnerung bewegt sich somit mit der Person zwischen Sitzungen, Anwendungen und Agenten. Es ändert eine Tatsache an Ort und Stelle, wenn sich die Tatsache ändert. Es fügt nicht jedes Mal einen neuen Eintrag hinzu.
Die beiden Systeme sind keine Alternativen. Verwende beide. Der Fehler ist nicht, kein Wiki zu verwenden. Der Fehler ist zu denken, dass ein Wiki dir das Gedächtnis eines Benutzers gibt.
Zusammenfassung
Die Idee bei Agent-Wikis ist richtig. Kompiliere das Wissen einmal. Dann halte es korrekt. Baue es nicht für jede Frage neu auf. Die Wartung stoppte menschliche Wikis, und ein Modell erledigt die Wartung kostenlos. Vier Teams bauten in wenigen Monaten die gleiche Struktur. Das ist ein starkes Indiz.
Mach diese drei Dinge. Kompiliere deine Dokumente in Seiten, wenn die Dokumentenmenge stabil ist und du sie häufig liest. Füge Retrieval hinzu, wenn die Dokumentenmenge groß wird, wie der Gist dir sagt. Behalte den Unterschied zwischen Wissen über eine Dokumentenmenge und Gedächtnis eines Benutzers. Ein Wiki gibt dir das Erste. Ein Wiki gibt dir nicht das Zweite.
In Context #17
Dieser Blog ist Teil von In Context, einer @mem0ai Blogserie über KI-Agenten-Gedächtnis und Kontext-Engineering.
Mem0 ist eine intelligente, quelloffene Gedächtnisschicht, die für LLMs und KI-Agenten entwickelt wurde, um langfristige, personalisierte und kontextbewusste Interaktionen über Sitzungen hinweg zu ermöglichen.
- Hol dir deinen kostenlosen API-Key hier: app.mem0.ai
- oder hoste mem0 selbst von unserem Open-Source-GitHub-Repository
Referenzen
- Andrej Karpathy, LLM Wiki (GitHub Gist, April 2026)
- qmd: lokale hybride BM25/Vektorsuche für Markdown
- Cognition, DeepWiki: KI-Dokumentation für jedes Repo
- Devin Docs, DeepWiki
- Factory, Einführung von AutoWiki
- Factory Dokumentation, AutoWiki Übersicht
- langchain-ai/openwiki (GitHub)
- LangChain, Wiki-Gedächtnis
- garrytan/gbrain (GitHub)
- Vannevar Bush, As We May Think (The Atlantic, 1945)
- Mem0
