785 Artikel für Agenten, nicht für Menschen. Eine Wissensbasis ohne Vektorsuche

Wenn ein Agent die Arbeit in einem unbekannten Projekt beginnt, verbraucht er die ersten 30 bis 40 % seiner Token dafür, herauszufinden, was um ihn herum vorgeht. Nicht arbeiten, sondern sich orientieren. Dieser Beitrag beschreibt Happyin Knowledge Space, eine Bibliothek von Referenzkarten, die ich für Agenten statt für Menschen schreibe: warum das Kartenformat so aussieht, wie es aussieht, warum sich schnell entwickelnde Bereiche eine Aktualitätsschwelle haben, warum ich Karten von Hand verlinke statt sie in einer Vektordatenbank abzulegen, und wie Recherchen aus Chats auf mehreren Konten dort landen, ohne Kopieren und Einfügen. Als die russische Originalfassung am 22. April 2026 erschien, enthielt die Bibliothek 785 Karten in 26 Bereichen.

Zwei Probleme damit, wie ein Agent ein Projekt lernt

Ein README erklärt die Motivation, ein Tutorial nimmt einen an die Hand, eine API-Referenz listet Parameter auf. Keines davon beantwortet die Frage, mit der der Agent tatsächlich kommt: Hier ist meine Aufgabe, welches Muster kopiere ich, und wo liegen die Fallstricke?

Das zweite Problem ist tiefer und fällt erst später auf. Ein Modell kennt „alles“, aber dieses Alles ist ungleich in seinen Trainingsdaten verteilt. Je länger eine Technologie im Netz ist, desto mehr Beiträge, Stack-Overflow-Antworten und Tutorials gibt es dazu, und desto mehr Gewicht trägt der Ansatz im Modell. Wenn ich Claude bitte, ein LoRA zu trainieren, schlägt es zuerst ein Rezept von vor fünf Jahren vor. Nicht weil es besser wäre, sondern weil es mehr davon gibt. Für stabile Technologien ist das in Ordnung. Für alles, was sich schnell bewegt, etwa Modelltraining, Agenten-Werkzeuge oder Sicherheit, heißt das: Der Agent zieht mich unbemerkt in die Vergangenheit.

Die naheliegende Lösung wäre, jedes Mal Deep Research zu betreiben und aktuellen Kontext mitzubringen. Das mache ich auch. Aber Deep Research ist teuer: mehrere hundert Dollar im Monat an Abos, und die Limits sind trotzdem fast sofort aufgebraucht. Schlimmer noch, jeder Recherchelauf verschwindet mit seiner Sitzung. Morgen führe ich dieselbe Suche zum selben Thema aus und verbrauche dieselben Token für das, was ich schon herausgefunden habe.

Daraus entstanden zwei Ideen. Recherche soll sich ansammeln, statt zu verdampfen. Und das Format soll dem Agenten zeigen, was jetzt aktuell ist, damit er beim Öffnen eines Projekts sofort weiß: So macht man es hier.

Das Format: eine Karte, kein Artikel

Jede Karte hat dasselbe Gerüst. Oben das Thema und eine Definition in einem Satz, damit der Agent sofort erkennt, ob er richtig gelandet ist. Dann Key Facts: kurze Aussagen mit Zahlen, etwa Versionen, Schwellenwerte und Abhängigkeiten. Danach Patterns: kopierbarer Code mit Sprachkennzeichnung. Ganz unten die Gotchas, jeweils als Paar aus dem, was kaputtgeht, und dem, was es behebt.

Keine Einleitungen à la „schauen wir uns einmal an“ und keine Schlüsse à la „in diesem Artikel haben wir untersucht“. Die Karte zur Kafka-Broker-Architektur ist eine Tabelle ZooKeeper gegen KRaft, eine kommentierte Konfiguration, JMX-Metriken mit Alarmschwellen und eine Schritt-für-Schritt-Migration. Es liest sich nicht flüssig. Aber der Agent sucht nach „KRaft migration“ und bekommt in drei Schritten ein funktionierendes Rezept.

Der letzte Block ist der wertvollste. Eine Zeile wie „min.insync.replicas wirkt nur mit acks=all“ spart eine halbe Stunde Fehlersuche. Der Agent hat sie gelesen, den Fehler nicht gemacht und keinen Wiederholungszyklus gebraucht, um ihn zu beheben.

26 Bereiche, aus der Arbeit gewachsen

Im April war der größte Bereich Bildgenerierung mit 58 Karten, knapp dahinter LLM-Agenten mit 57, dann Data Science und Security mit je 56 (Security wuchs über einen eigenen Ordner mit CWE-Klassen). Danach folgten Kafka mit 43, DevOps mit 38, Web-Frontend mit 36, Data Engineering mit 34 und vier Bereiche mit je 33: Python, SQL, Architektur und Algorithmen. Vierzehn kleinere machten den Rest aus: iOS, Linux-CLI, C++, Java Spring, Testing und QA, BI, SEO, Rust, Node.js, PHP, LLM-Memory, Audio und Voice, Schreiben und Go.

Das ist kein Plan. Es ist eine Landkarte davon, wo meine Zeit tatsächlich hingeht, wenn ich mit Agenten arbeite: LoRAs trainieren, C++-Plugins debuggen, recherchieren. Jeder Bereich hatte seine eigene Liste von Stellen gesammelt, an denen es für mich schiefgegangen war, und diese Listen wurden zum Gerüst.

Wissen altert nicht in einem Tempo

Algorithmen und Mathematik sind stabil: Eine Karte über amortisierte Analyse oder Netzwerkfluss, vor drei Jahren geschrieben, stimmt noch. Diffusionstraining, Inferenzoptimierung und ComfyUI-Nodes ändern sich alle paar Monate, und was im Herbst funktionierte, ist im Frühjahr überholt. Kachelweise Diffusion auf sehr großen Fotos, über die ich in Warum Diffusion auf 40-Megapixel-Fotos Nähte zeichnet geschrieben habe, gehört zu diesen schnellen Themen.

Deshalb trägt jeder Bereich seine eigene Aktualitätsschwelle. Stabile Bereiche haben keine. In schnellen Bereichen wird eine Karte, die älter als 60 Tage ist, zur Überprüfung markiert, und ein Hook, der einmal am Tag läuft, setzt sie auf eine Liste „prüfen und aktualisieren“. Das ist keine Löschwarnung. Es ist eine Erinnerung, dass sich das Thema wahrscheinlich bewegt hat und die Karte gegen den heutigen Stand geprüft werden muss. Veraltete Karten kommen so von selbst zur Prüfung, statt den Agenten still in die Irre zu führen.

Links statt Vektoren

Die naheliegende Architektur dafür ist eine Vektordatenbank mit RAG obendrauf. Sie findet semantisch nahe Texte schnell und funktioniert in der Produktion gut. Ich habe bewusst keine verwendet, aus drei Gründen.

Ein Vektorspeicher ist für Menschen nicht lesbar. Markdown kann ich in einem Texteditor öffnen, mit grep durchsuchen, in Git vergleichen, in eine E-Mail kopieren oder ausdrucken und an die Wand heften. Das funktioniert heute und wird in zehn Jahren auf jedem Computer funktionieren, ohne Spezialwerkzeug. Ein Vektorspeicher ist ein Binärformat, das nur sein eigener Client versteht. Wechselst du den Anbieter, verlierst du den Dienst, bricht die API, und die Daten werden zu einem Haufen Zahlen, den niemand lesen kann. Ich wollte, dass die Wissensbasis einen Werkzeugwechsel übersteht, statt von Werkzeugen abzuhängen.

Vektorisierung ist nahezu unumkehrbar. Ein Embedding ist eine verlustbehaftete Einwegkompression. Ohne die Originalabschnitte daneben ist eine Datei voller Embeddings nutzlos, denn lesbaren Text zurückzugewinnen ist fast unmöglich. Es gibt Forschung zur Embedding-Inversion, aber sie funktioniert bei sehr kurzen Fragmenten, braucht dasselbe Embedding-Modell und einen separat trainierten Decoder. Außerdem bindet die Vektorisierung dich an ein Embedding-Modell: Wechselst du für bessere Qualität das Modell, musst du alles neu indexieren, weil alte Vektoren im neuen Raum nichts bedeuten.

Und die für mich wichtigste: Ein Linkgraph hält fest, welche Themen benachbart sind, nicht welche Texte ähnlich sind. Vektorähnlichkeit findet Themen, die sich im Vokabular und in den Konzepten überschneiden. In echter Arbeit verlaufen die wertvollen Verbindungen oft zwischen Themen, die weit auseinanderliegen. Meine Karte zur Kafka-Replikation verlinkt auf eine Karte zum Speicher-Profiling, nicht weil die Themen sich ähneln, sondern weil das Tuning eines Consumers ein Speicherleck zutage förderte und die Erfahrung sie zu Nachbarn machte. Im Embedding-Raum liegen „Replikation in einer verteilten Queue“ und „Speicher-Profiling in Python“ weit auseinander, und semantische Suche baut diese Brücke nicht. Ein handgeschriebener Wiki-Link baut sie, und jetzt ist ein Agent, der über Kafka liest, einen Schritt von Speicher-Profiling entfernt.

Die Mechanik ist einfach. Karten verweisen aufeinander als [[flux-klein-9b-inference]], [[two-phase-commit]], [[saga-pattern]]. Beim Bauen löst ein Python-Hook jeden Slug in einen relativen Pfad auf. Wird ein Slug nicht gefunden, erscheint eine Warnung im Log, und im strikten Modus schlägt der Build fehl, sodass ein kaputter Link nie auf der Live-Seite landet. Im April gab es über 2.100 solcher Links. Das ist der ganze Wissensgraph: keine Embeddings, keine Vektordatenbank, kein RAG. Markdown und grep. Ein Agent öffnet die Karte zu verteilten Transaktionen, sieht die benachbarten Themen unter „See Also“, folgt einem und arbeitet weiter. Drei Schritte vom Einstiegspunkt zu einem funktionierenden Muster.

Es ist dieselbe Idee wie die [[filename]]-Links im Memory meiner Agenten, beschrieben in Meine CLAUDE.md hat 582 Zeilen.

Die Seite ist ein Build des Repositorys

Alles auf happyin.space ist eine statische Seite, die aus Markdown in einem offenen Repository gebaut wird. Keine Datenbank, kein Backend, keine versteckte Schicht. Die Datei docs/kafka/broker-architecture.md wird nach dem Build zur Seite happyin.space/kafka/broker-architecture/, und das ist der ganze Mechanismus.

Daher kann jeder das Projekt forken und in etwa fünf Minuten lokal laufen lassen:

git clone https://github.com/AnastasiyaW/knowledge-space.git
cd knowledge-space
pip install -r requirements.txt
mkdocs serve        # then open http://localhost:8000

Das ergibt eine lokale Kopie mit jeder Karte, der vollen Suche und dem Linkgraphen. Von dort aus kannst du meine Bereiche entfernen, eigene hinzufügen und deine Agenten auf den lokalen Build statt auf die öffentliche Seite zeigen lassen. So nutze ich es selbst: Meistens ist der lokale Build geöffnet, und die öffentliche Seite ist ein Spiegel.

Ein vollständiger Neuaufbau dauerte etwa fünf Sekunden, auf einem alten Laptop genauso schnell wie auf einer Workstation, weil darunter die Art von statischem Site-Generator liegt, die die Branche seit fünfzehn Jahren nutzt. Ein Agent, der mit einer lokalen Kopie arbeitet, verbraucht keine Token für einen Netzwerk-Roundtrip oder fürs Warten auf ein Deployment: neu bauen, Karte öffnen, Rezept übernehmen.

Derselbe Build-Schritt hält die Links ehrlich. Er geht jeden [[slug]] durch, findet die passende Karte und schreibt den relativen Pfad. Findet er keine, schlägt der Build fehl. Ich sehe das lokal, bevor ich committe, und CI führt dieselbe Prüfung im strikten Modus aus, wo jeder kaputte Link das Deployment blockiert. Im April waren das mehr als 2.100 Links, und keiner war kaputt. Und weil die Seite das Repository ist, liegt alles in Git: Man sieht, wie sich eine Karte verändert hat, welche Fakten nach welchem Recherchelauf dazukamen und wann sie zuletzt angefasst wurde. Für eine Basis, die nach dem Tempo ihres Alterns sortiert ist, zählt diese Historie.

Wie Recherche hineinkommt

Der Ablauf ist so eingerichtet, dass ich nie Daten von Hand verschiebe. Ich habe mehrere Claude-Konten, jeweils mit mehreren offenen Chats, und in jedem kann irgendwann ein Deep-Research-Lauf starten: neue Modelle, Optimierungen, Fehler, alles Mögliche. Früher lebte das Ergebnis bis zum Ende des Chats. Jetzt folgt jeder dieser Chats derselben festen Regel: Wenn ein Recherchelauf fertig ist, legt er eine Kopie des Ergebnisses an einem zentralen Ort ab.

Dieser Ort ist ein Claude-Code-Projekt, das an das knowledge-space-Repository gebunden ist und einen eigenen Ordner research/inbox/ hat, in den Rohdumps aus jedem Chat auf jedem Konto gesammelt werden. Kein Kopieren und Einfügen, nur eine Regel, die jeder Chat beim Start liest und bei Abschluss seiner Recherche befolgt.

Dann folgt ein zweiter Durchgang. Eine eigene Sitzung im knowledge-space-Projekt arbeitet die Inbox ab: Sie liest jeden Rohdump, zieht die konkreten Fakten und Fallstricke heraus, verpackt sie ins Kartenformat um und gleicht sie mit dem ab, was in diesem Bereich schon steht, damit Duplikate bestehende Karten ergänzen statt sich zu vervielfachen. Dann prüft sie die Wiki-Links, führt den Build aus, liest den Diff und pusht. Eine solche Sitzung ergibt meist 20 bis 40 neue oder ergänzte Karten über einige Stunden.

Die Modellstufung ergibt sich daraus direkt, und hier habe ich endlich einen Einsatz für Sonnet gefunden. Für mich lag es bisher zwischen „zu clever für einfache Dinge“ und „zu einfach für alles Interessante“. Aber „einen rohen Recherchedump lesen, die Fakten herausziehen, ins Kartenformat umpacken, mit den Nachbarn im Ordner vergleichen“ ist genau diese Art Arbeit: mechanisch, aber mit Sprache darin. Sonnet packt Text genauso gut um wie das größere Modell und kostet deutlich weniger, deshalb laufen die Recherchechats und der Inbox-Durchgang darauf. Die Wiki-Links prüfen, entscheiden, ob zwei Karten zusammengeführt werden sollen, oder einen Konflikt zwischen zwei Quellen auflösen, ist Verstehen-Entscheiden-Gestalten, und das geht an das stärkere Modell. Der Kostenunterschied ist ein Vielfaches, ohne Qualitätsverlust.

Das Ergebnis ist ein Fluss. Ich mache meine Hauptarbeit, führe unterwegs in verschiedenen Chats Recherchen durch, und die Basis füllt sich, ohne dass ich etwas verschiebe oder formatiere.

Nutzen und selbst beitragen

Am einfachsten nutzt man es, indem man den Agenten auf happyin.space/llms.txt zeigen lässt und er Karten holt, wenn er sie braucht. Das allein verkürzt das erste Drittel der Token, das früher für die Orientierung draufging.

Die nächste Stufe ist Mitarbeit. Das Repository hat zwei Dateien dafür: CONTRIBUTING.md, einen allgemeinen Leitfaden für Seiten und das Einreichen von Änderungen, und AGENTS.md, Anweisungen für deinen Agenten. Sie beschreiben das Kartenformat, wie dicht der Text sein soll, was unter Gotchas gehört, wie man Wiki-Links schreibt und wie man einen Pull Request mit einer neuen Karte oder einer Korrektur öffnet. Gib deinem Agenten den Leitfaden und ein frisches Rechercheergebnis, und er baut die Karte selbst. Deine Recherche geht in die Basis ein, du zahlst nicht mehr dafür, und alle anderen auch nicht. Die README nennt die MIT-Lizenz.

Je mehr Recherche in der Basis steckt, desto weniger muss jemand sie noch einmal machen. Je mehr Menschen und Agenten Karten einreichen, desto mehr unerwartete Brücken zwischen Bereichen entstehen, und die sind die wertvollen. Die Projektseite auf dieser Website ist happyin.space.

Was sich seit April geändert hat

Update, September 2026. Die README des Repositorys meldet jetzt mehr als 1.287 Artikel in 28 Bereichen und mehr als 3.139 Querverweise. Das meiste Wachstum sind zwei neue Arten von Seiten: projects/ mit 388 Seiten, eine pro Werkzeug, Modell oder Produkt, das eine Nachrichtenpipeline verfolgt, und organizations/ mit 45 Seiten, eine pro Firma oder Labor. Die Aktualitätsregel ist in der README jetzt ein Vierstufenzyklus: stabil, jährlich, alle sechs Monate und monatlich, wobei Bildgenerierung und Agenten-Frameworks in der monatlichen Gruppe stehen.

Die Zahlen aus April oben (785 Karten, 26 Bereiche, mehr als 2.100 Links, die 60-Tage-Schwelle, ein Build in fünf Sekunden) stimmten am Veröffentlichungstag, und ich habe sie so belassen. Dieselbe Vorliebe für schlichte Dateien statt eines Dienstes, angewandt auf mehrere Agentensitzungen, die gleichzeitig arbeiten, steht in Mehrere Claudes auf einem Repo.