Multi-Agenten verbrauchen nur jede Menge Tokens und verlieren oft den Kontext? Deshalb habe ich ein LLM-Wiki mit der Struktur einer „Zeitungsredaktion“ gebaut.

• Autonome Multi-Agenten-Systeme tauchen derzeit überall auf, aber wenn man sie tatsächlich laufen lässt, verbrauchen sie 5- bis 10-mal so viele Tokens und verlieren häufig den Kontext. Deshalb habe ich die Struktur der Multi-Agenten an einer Zeitungsredaktion ausgerichtet.
• Es gibt fünf Agentenrollen, aber der einzige Agent, bei dem das LLM selbst beurteilt, ist der Desk (Prüfung). Der Rest sind Schreibaufgaben, regelbasierte Python-Prüfungen (Lint) statt LLMs sowie Arbeitskoordination (Orchestrierung).
• Wie beim Konzept eines LLM-Wikis werden Originaldokumente gelesen, daraus Source Pages erstellt, daraus Entwürfe zu Personen und Konzepten extrahiert und diese dann zu thematischen Übersichten, Widerspruchsnotizen und Synthese-Seiten aufgebaut. Gespeichert wird einfach als Markdown-Dateien in git, und alle Python-Tools laufen lokal. Nach dem Klonen kann man den Beispielgraphen sofort ohne API-Key ausführen.
• Das derzeit auf GitHub enthaltene Beispiel behandelt die Debatte „Was bedeutet Open Source bei KI?“, aber das Framework selbst ist themenunabhängig.

---

Warum ich nicht einfach mehrere Agenten frei losgelassen habe

• Die Erfahrungsberichte von Leuten, die das tatsächlich mit Kosten von Tausenden Dollar ausprobiert haben, kamen im Großen und Ganzen zum selben Ergebnis: Es verbraucht massenhaft Tokens, Agenten verlieren beim Hin und Her den Kontext, und unfertige Arbeit wird als erledigt markiert.
• Deshalb habe ich den Schwerpunkt nicht darauf gelegt, die Agenten selbst entscheiden zu lassen, sondern auf feste Regeln und Kontextisolation. Auch wenn ich die Metapher einer Redaktion verwende: Das einzige LLM, das wirklich frei urteilt, ist der Desk; die übrigen erledigen nur fest definierte Aufgaben.

Vorweggenommene Antworten auf naheliegende Einwände

• Die Dokumente wachsen immer weiter, bis sie am Ende unbrauchbar werden: Das halte ich für die realistischste Sorge. Deshalb habe ich die schreibende Rolle und den Desk, der über Freigabe entscheidet, komplett getrennt. Dem Desk werden nur das Ergebnis und die Bewertungskriterien gezeigt, nicht die Absicht des Autors. Zusätzlich filtert ein regelbasierter Lint mechanisch heraus, wenn Dokumente aufblähen, sich wiederholen oder ziellos ausufern. Trotzdem würde ich nicht behaupten, dass Aufblähung damit vollständig „verhindert“ ist.
• Wenn man immer wieder editiert, häufen sich Fehler an; und wenn man sich anhand des eigenen Feedbacks selbst korrigiert, wiederholt man am Ende nur vorhandene Muster: Dieser Zweifel begleitet jede Behauptung von Selbstverbesserung, und ich halte ihn ebenfalls für berechtigt. Wenn wiederholt vom Desk gefundene Mängel zurück in die Guidelines einfließen, tausche ich deshalb die Validierungs-Failure-Cases jedes Mal gegen neue aus, um zu verhindern, dass das System nur auf dieselben Prüfungsaufgaben trainiert wird (Overfitting). Es wird also jeweils an zuvor unbekannten Fällen geprüft. Für die Synthese-Seiten habe ich außerdem eine Prüfung eingebaut, die abgleicht, ob Inhalte aus unterschiedlichen Quellen unzulässig zusammengeworfen wurden.
• Ist das am Ende nicht nur RAG mit manuell ausgetauschten Embeddings?: Wenn das Ziel Suche ist, stimmt das. Der Unterschied ist, dass das Ergebnis kein Vektorindex ist, sondern miteinander verbundene Dokumente, die Menschen einfach lesen können; außerdem werden Widersprüche zwischen Quellen nicht überdeckt, sondern auf separaten Widerspruchsseiten sichtbar gemacht. Ziel ist nicht, bei jeder Frage die Originaltexte erneut zusammenzukratzen, sondern dass die aufgebauten Einschätzungen erhalten bleiben.

Ein altes Konzept: Memex

• Ich habe es mit Blick auf Strömungen wie Vannevar Bushs Memex (eine 1945 konzipierte vernetzte Informationsmaschine) und Lickliders „Man-Computer Symbiosis“ gebaut.
• Deshalb gibt es Trails (assoziative Pfade), die Seiten miteinander verbinden, sowie eine Discover-Funktion, die unerwartete Verbindungen findet. Es geht nicht darum, automatisch einen Index zu erzeugen, sondern Wege zu hinterlassen, denen Menschen selbst folgen können.

Hinweise zur Nutzung

• „Kein API-Key nötig“ stimmt nur zur Hälfte: Die Python-Tools in tools laufen lokal, dafür braucht man keinen externen Key. Die Agenten selbst laufen allerdings über Claude Code; dafür muss jeder seinen eigenen Key verwenden (BYOK).
• Das öffentliche Repo ist eher eine Idee mit kleinem Beispiel: Es enthält ein englisches Beispiel mit 15 Nodes, sodass jeder nach dem Klonen denselben Graphen reproduzieren kann. Die reale Instanz mit etwa 2.300 Nodes, die ich täglich genutzt habe, halte ich separat privat; bitte trennt sie daher vom öffentlichen Repo.
• Koreanischer Modus (WIKI_LANG=ko): Nur der Haupttext und die Metadaten am Dokumentanfang (Frontmatter) werden auf Koreanisch umgestellt; Markierungen, die die Dokumentstruktur beschreiben (wie ## Summary oder [fact]), bleiben bewusst auf Englisch. Das heißt: Es ist kein „vollständig koreanischer“ Modus.

Entstehung und aktueller Stand

• Ausgangspunkt war, dass ich eine Implementierung an das von Karpathy geteilte LLM-Wiki-Gist angehängt habe. Das Konzept selbst wurde früher auch schon auf GeekNews vorgestellt: https://de.news.hada.io/topic?id=28208
• Ob die Trennung von Schreiben und Prüfung wirklich dazu führt, dass weniger halbgar durchgewinkt wird, und ob eine Selbstverbesserungsschleife tatsächlich hilft, ist noch kein sauber gemessenes Ergebnis, sondern eine Hypothese, mit der ich experimentiere.