llm-wiki-agent: ein Wiki, das der Coding-Agent selbst schreibt

Das Problem: Quellen sammeln ist einfach, sie erschließen ist Arbeit

Die meisten Wissenswerkzeuge setzen voraus, dass man bereits weiß, was in den eigenen Notizen steht, und sie dann durchsucht. llm-wiki-agent dreht die Richtung um: Man legt Quelldokumente in raw/ ab und beauftragt den Agenten mit der Auswertung. Das README formuliert den Unterschied selbst so, dass andere Werkzeuge einen die eigenen Notizen durchsuchen lassen, während dieses alles Gelesene liest und ein strukturiertes Wiki schreibt, das über die Zeit wächst. Die Zielgruppe ist eng umrissen: Forschende, die über Wochen Papers und Berichte lesen, Menschen, die ein Buch kapitelweise erfassen, Teams, die Meeting-Transkripte und Kundengespräche auswerten, sowie alle, die ein Unternehmen oder eine Technologie über längere Zeit beobachten. Es ist ausdrücklich kein Werkzeug für einmalige Zusammenfassungen. Der Nutzen entsteht erst durch die zweite, dritte und vierte Quelle, weil dann Entitäts- und Konzeptseiten zusammenlaufen und Widersprüche sichtbar werden.

Ordnernamen als Architektur: raw, wiki und graph

Die Repository-Struktur ist die eigentliche Spezifikation. Eingang ist raw/, Ausgang ist wiki/ mit index.md als Katalog aller Seiten, log.md als append-only-Protokoll jeder Operation und overview.md als fortlaufend überarbeitete Synthese über alle Quellen. Darunter liegen vier Seitenklassen: sources/ mit einer Zusammenfassung pro Dokument, entities/ für Personen, Firmen und Projekte, concepts/ für Ideen, Frameworks und Methoden sowie syntheses/ für Antworten auf Anfragen, die als Wiki-Seiten abgelegt werden. Ein zweiter Baum graph/ enthält graph.json als persistente Knoten- und Kantendaten und graph.html als vis.js-Visualisierung, die sich laut README in jedem Browser öffnen lässt. Die Kanten stammen aus [[wikilinks]]; zusätzlich zeichnet der Agent erschlossene Beziehungen als gepunktete Linien, und eine Community-Erkennung gruppiert verwandte Themen. Verlinkung ist damit kein Nachgedanke, sondern das Datenmodell.

Der Ablauf: Konvertierung, Extraktion, Widerspruchsprüfung

Der Datenfluss beginnt beim Format. Markdown wird direkt gelesen, alles andere laut README zur Ingest-Zeit über markitdown umgewandelt, ohne separaten Schritt. Unterstützt werden unter anderem PDF, DOCX, PPTX, XLSX, HTML, TXT, CSV, JSON, XML, RST und EPUB. Danach extrahiert der Agent Wissen und verteilt es auf die Seitenklassen. Zwei Mechanismen sind hervorzuheben. Erstens werden Entitäts- und Konzeptseiten automatisch angelegt und bei jedem neuen Dokument, das dieselbe Entität erwähnt, aktualisiert. Zweitens prüft der Ingest-Vorgang auf Widersprüche: Trifft eine neue Quelle auf eine bestehende Aussage, wird das zum Ingest-Zeitpunkt markiert und nicht bis zur Abfrage aufbewahrt. Das ist der interessanteste Entwurf im Projekt, weil es die Prüfung an den Moment bindet, in dem beide Texte im Kontext liegen. Ob die Prüfung greift, hängt allerdings vom Urteilsvermögen des Agenten ab; das README beschreibt das Verhalten, nennt aber keine Genauigkeit oder Fehlerquote.

Installation ohne API-Schlüssel, aber nicht ohne Agent

Die Einrichtung besteht aus zwei Befehlen: git clone https://github.com/SamurAIGPT/llm-wiki-agent.git, dann cd llm-wiki-agent. Danach öffnet man das Verzeichnis im Agenten. Claude Code liest CLAUDE.md und .claude/commands/, Codex und OpenCode lesen AGENTS.md, Gemini CLI liest GEMINI.md. Ein API-Schlüssel oder eine Python-Installation ist laut README nicht nötig, was daran liegt, dass die Modellaufrufe über den jeweiligen Agenten laufen und nicht über eigenen Code. Die Bedienung erfolgt über Kurzauslöser oder natürliche Sprache. Typische Eingaben sind ingest raw/papers/my-paper.md, ingest report.pdf für die automatische Konvertierung, ingest slides.pptx notes.docx für gemischte Stapel, query: what are the main themes?, lint sowie build graph. Claude Code bietet zusätzlich die Slash-Befehle /wiki-ingest, /wiki-query, /wiki-lint und /wiki-graph; die natürlichen Auslöser funktionieren laut README in allen Agenten identisch.

lint und die Grenze der automatischen Pflege

Der lint-Befehl ist der ehrlichste Teil des Konzepts, weil er die Schwächen des eigenen Bestands offenlegt: verwaiste Seiten, defekte Links, fehlende Entitätsseiten und Lücken samt Quellenvorschlägen. Die README-Beispiele zeigen Ausgaben wie den Hinweis, dass keine Quellen zu mixture-of-experts vorliegen und man das Mixtral-Paper erwägen sollte, oder dass ein Projekt auf fünf Seiten erwähnt wird, aber keine eigene Seite hat. Genau hier liegt auch die Grenze. Die Qualität des Wikis steht und fällt mit der Fähigkeit des Agenten, Entitäten konsistent zu benennen und nicht bei jeder Quelle eine Variante anzulegen. Wer mehrere hundert Dokumente einliest, sollte mit verwaisten oder doppelten Seiten rechnen, weil das README keine Normalisierung, kein Schema und keine Validierung der Seitennamen beschreibt. Auch die Widerspruchserkennung ist ein Hinweis, keine Wahrheitsfindung: Sie markiert, sie entscheidet nicht. Und für einen einzelnen kurzen Artikel ist der Apparat aus index.md, log.md, overview.md und drei Seitenklassen schlicht überdimensioniert.

Was llm-wiki-agent von einem RAG-Stack unterscheidet

Der naheliegende Vergleich ist ein Retrieval-Augmented-Generation-Aufbau, also Chunking der Dokumente, Einbettung in einen Vektorindex und Abfrage zur Laufzeit. Der Unterschied liegt nicht in der Antwortqualität, sondern im Artefakt. Ein RAG-Stack erzeugt bei jeder Frage eine neue Antwort und vergisst sie danach; llm-wiki-agent schreibt die Antwort als Seite unter wiki/syntheses/ zurück, sodass sie beim nächsten Mal verlinkt und zitierbar ist. Auch die Prüfung verschiebt sich: Statt zur Abfragezeit Ähnlichkeiten zu berechnen, werden Beziehungen und Widersprüche beim Einlesen festgehalten. Dafür fehlen Eigenschaften, die ein Vektorindex mitbringt, etwa eine Ähnlichkeitssuche über Tausende Dokumente in Millisekunden. Das Wiki skaliert über Struktur, nicht über Indexgröße. Wer schnelle semantische Suche über einen sehr großen Bestand braucht, fährt mit einem RAG-Stack besser; wer ein lesbares, versionierbares Nachschlagewerk will, mit diesem Projekt.

Wartung, Lizenz und der Faktor Agent

Das Repository steht unter MIT, was Weitergabe und kommerzielle Nutzung erlaubt, solange Copyright-Hinweis und Lizenztext erhalten bleiben. Rechtliche Einordnung ersetzt das nicht. Wartungsaufwand entsteht an zwei Stellen. Erstens wächst wiki/ mit jeder Quelle, und ohne gelegentlichen lint-Lauf sammeln sich verwaiste Seiten und tote Links an. Zweitens ist der Agent die Abhängigkeit: Ändert sich das Verhalten von Claude Code, Codex, OpenCode oder Gemini CLI, ändert sich das Verhalten des Wikis, ohne dass sich am Repository etwas geändert hätte. Das README nennt keine Versionsbindung und keine Tests, die das abfangen. Es gibt keine Releases, der letzte Push liegt laut Repository-Metadaten bei September 2026. Wer das Projekt produktiv einsetzt, sollte den Stand von CLAUDE.md, AGENTS.md und GEMINI.md selbst im Blick behalten, weil dort die Anweisungen an den Agenten stehen und nicht im Python-Code.

Redaktionelles Fazit

Wer ohnehin mit Claude Code, Codex, OpenCode oder Gemini CLI arbeitet und einen wachsenden Bestand an Papers, Transkripten oder Interviewnotizen hat, bekommt hier ohne API-Schlüssel und ohne Python-Setup ein versionierbares Markdown-Wiki. Wer einen Abfrage-Layer über bestehende Notizen sucht oder mit einem Agenten außerhalb der vier genannten arbeitet, ist hier falsch. Vor dem ersten echten Lauf sollte man eine kleine Probe in raw/ ablegen, ingest ausführen und danach wiki/log.md sowie die neu erzeugten Seiten unter wiki/entities/ gegen die Quelle prüfen, denn nur dort zeigt sich, ob die Extraktion trägt.

Offizielle Quellen

1. Issues
2. License: MIT
3. README
4. SamurAIGPT/llm-wiki-agent on GitHub