Die Agent-Stack-Frage: Vektordatenspeicher, Hypergraphen und Codieraufgaben

Der Drang, immer mehr hinzuzufügen

Wenn man sich die Berichterstattung dieses Jahres über KI-Agenten durchliest, fällt vor allen einzelnen Aussagen eines besonders ins Auge: Die Ratschläge besagen fast immer, etwas hinzuzufügen – eine Speicherschicht, ein Graph, ein Orchestrierungsframework, ein Abrufpipeline mit drei Neubewertungsschritten. Mehr Agenten, die die bereits vorhandenen Agenten überwachen. Dahinter steckt der stillschweigende Glaube, dass Komplexität Fortschritt bedeutet und dass ein System, das nicht komplexer ist als vor sechs Monaten, zurückbleibt.

Ein erheblicher Teil dieser Technologiestacke wurde vermutlich bereits von jedem erstellt und verteidigt, der das hier liest. Deshalb lohnt es sich, einen kurzen Blick auf eine Gruppe von Argumenten zu werfen, die das Gegenteil behaupten: Die anspruchsvolle Erweiterung, die Sie hinzugefügt haben, hat vermutlich noch nicht ihren Platz verdient. Die meisten gegensätzlichen Technikartikel sind im Grunde umgekehrte Werbebotschaften – genauso selbstsicher, aber genauso beweisarm. Diese drei Beispiele unterscheiden sich, weil jedes auf etwas beruht, das überprüft werden kann – sei es ein Benchmark-Ergebnis, ein struktureller Beweis oder eine einfache Beschreibung davon, wie ein Arbeitstag abläuft. Dieser Standard gilt auch für jeden anderen Technologiestack, einschließlich Ihres eigenen.

Jedes dieser Beispiele zeigt einen Punkt, an dem die Branche nach mehr Struktur suchte, obwohl das eigentliche Problem an einer weniger offensichtlichen Stelle lag.

Beispiel eins: Agenten-Speicher und Vektor-Speicher

Das Speichern von Agenteninformationen in einem Vektorlagern dauert in der Regel etwa eine halbe Minute. Jemand stellte fest, dass der Agent die Informationen über verschiedene Sitzungen hinweg speichern sollte, woraufhin die Lösung folgte: Einbetten, speichern und über Ähnlichkeit abrufen. Alle Tutorials arbeiten auf diese Weise, wodurch es zur Standardlösung wurde – ohne dass jemand sie mit einfacheren Methoden verglichen hätte.

In einer Veröffentlichung dieses Jahres wurde genau dieser Test durchgeführt. Im LoCoMo-Benchmark erzielte eine Baseline, die aus einer Ordnerstruktur mit Textdateien sowie grep bestand, bessere Ergebnisse als mehrere finanzierte, speziell dafür entwickelte Speichellösungen. Der Vergleich fand nicht unter kontrollierten Bedingungen statt. Systeme mit Einbettungstechniken, Ähnlichkeitssuche und manchmal Graphenspeicher verloren gegenüber einer Konfiguration, die erst nachmittags zusammengestellt werden musste.

Wenn man darüber nachdenkt, erscheint die Erklärung klar. Die Ähnlichkeitssuche findet passende Ergebnisse – sie denkt jedoch nicht. Sie ist gut darin, Texte zu finden, die inhaltlich einer Anfrage ähneln. Bei Aufgaben, die Gedächtnisleistungen erfordern, wie zum Beispiel das Erkennen, dass ein vor drei Wochen bekanntes Faktum durch eines von gestern ersetzt wurde, oder dass zwei gespeicherte Informationen miteinander kollidieren und eine überwiegen muss, versagt sie. Ein Index hat kein Zeitverständnis und kein Konzept von Korrekturen, weshalb er die nächstgelegenen Vektoren zurückgibt und es dem Modell überlässt, festzustellen, dass zwei der fünf besten Ergebnisse sich widersprechen.

Ein weiterer Unterschied betrifft die Vertrautheit und nicht die Fähigkeit. Die Modelle wurden mit enormen Mengen an Material über die Arbeit mit Dateien trainiert: Öffnen, Suchen, Bearbeiten, Auflisten von Ordnern, Nachverfolgen von Importen. Dateien gehören zum ursprünglichen Material ihrer Trainingsdaten, und eine Kombination aus grep sowie einer Schleife zum Lesen von Dateien nutzt dieses direkt. Im Gegensatz dazu muss ein Vektorabfragesystem eines Anbieters vom Modell innerhalb des eigenen Kontextfensters erlernt werden, wobei es zuvor nur wenig damit in Berührung kam. Dadurch wird eine bereits vorhandene Fähigkeit gegen eine ersetzt, die das Modell mitten in der Aufgabe erlernen muss, und es entstehen zusätzliche Verzögerungen durch Einbettung und Abruf.

Ein Entscheidungshilfe-Tool für die beiden Optionen, die nebeneinander dargestellt werden, sieht wie folgt aus.

WHEN A FILESYSTEM + GREP BASELINE IS ENOUGH        WHEN YOU ACTUALLY NEED A VECTOR STORE
------------------------------------------------   ------------------------------------------------
Single-agent or small-team memory                  Retrieval across a corpus too large to
                                                    fit or scan in context at all
Facts that change over time and need               Cross-document semantic search where
correction, not just accumulation                  keyword overlap is genuinely weak
Memory the model itself writes,                    Centralized memory shared by many agents
manages, and re-reads in its own loop               that needs access control and auditing
Debuggable state, plain text you can                Multi-hop or relational reasoning across
open, diff, and edit by hand                        thousands of entities where similarity
                                                     search is doing real narrowing work

Wie der dateibasierte Loop aussieht

„Verwende einfach Dateien“ klingt vage, bis es um Code geht. Diese Version benötigt keinen gehosteten Dienst.

import os
import subprocess
from datetime import datetime
MEMORY_DIR = "agent_memory"
def write_memory(topic: str, content: str) -> str:
    os.makedirs(MEMORY_DIR, exist_ok=True)
    path = os.path.join(MEMORY_DIR, f"{topic}.md")
    timestamp = datetime.utcnow().isoformat()
    with open(path, "a", encoding="utf-8") as f:
        f.write(f"\n## {timestamp}\n{content}\n")
    return path
def recall(query: str) -> str:
    # ripgrep if you have it, grep -r works fine too
    result = subprocess.run(
        ["rg", "-i", "-C", "2", query, MEMORY_DIR],
        capture_output=True, text=True
    )
    return result.stdout or "no matches"
def list_topics() -> list[str]:
    if not os.path.isdir(MEMORY_DIR):
        return []
    return [f[:-3] for f in os.listdir(MEMORY_DIR) if f.endswith(".md")]

Geben Sie dem Modell diese drei Funktionen als Werkzeuge und lassen Sie es entscheiden, wann gespeichert, wann gesucht und wann eine ganze Datei mit kurzen Themen geladen werden soll. Das Ergebnis ist Speicher ohne Einbettungskosten, ohne eine Datenbank, die gehostet oder bezahlt werden muss, und mit einem Zustand, den man bei Problemen in jedem Editor öffnen kann. Wenn dieser Ansatz schließlich an seine Grenzen stößt, liegt der Grund konkret vor – beispielsweise ein zu großes Korpus, das nicht schnell mit grep durchsucht werden kann, oder eine mehrstufige Frage, die eine Schlüsselwortsuche nicht beantworten kann. Das rechtfertigt einen Vektor-Speicher weitaus besser als das Kopieren eines Tutorials.

Das bedeutet keineswegs, dass Vektor-Datenbanken nicht existieren sollten. Es heißt lediglich, man solle nicht sofort zu einer greifen, bevor man die langweilige Basislösung getestet hat. Versuchen Sie zunächst den vollen Kontext, das Dateisystem zusammen mit grep und wenden Sie ein kostenpflichtiges Speicherprodukt nur dann an, wenn es diese Basislösung deutlich übertrifft, um die Kosten sowie den Verlust an Fehlersuchmöglichkeiten auszugleichen. Die meisten Agentenspeicher müssen diese Hürde selten überschreiten.

Fall zwei: Hypergraphen in RAG

Im letzten Jahr war die Standardlösung die Vektordatenbank. In diesem Jahr ist es das graphbasierte RAG, und Hypergraphen kommen zum Einsatz, wenn ein Team der Ansicht ist, dass ein gewöhnlicher Wissensgraph nicht ausreicht, um alle Informationen darzustellen. Dieser Ansatz klingt plausibel. Eine normale Kante verbindet zwei Knoten, doch viele Fakten beinhalten mehr Beteiligte. Nehmen wir die Freigabe einer Ausgabe: Eine Person genehmigt im Namen eines Finanzteams den Bericht eines Kollegen, wobei die Kosten aus dem vierteljährlichen Marketingbudget gedeckt werden. Das sind bereits fünf Parteien in einem einzigen Fakt. Wenn man diese in Paare aufteilt, entweder wird es nicht mehr zu einem einzigen atomaren Ereignis oder es werden mehrere binäre Kanten benötigt, die von Abfragen wieder zusammengefügt werden müssen. Eine Hyperkante verbindet hingegen beliebig viele Knoten auf einmal, wodurch sie als zuverlässige Methode zur Speicherung solcher Fakten erscheint. Teams entwickeln daher Hypergraphen-basiertes RAG in der Erwartung, dass diese Zuverlässigkeit die Informationsabrufung verbessert.

Ein anderer Artikel verglich diese Erwartung mit dem funktionsfähigen Code eines Papers über Hypergraph-RAG anstelle seines Abstracts und stieß auf etwas fast Komisches. HyperGraphRAG, das darauf ausgelegt ist, native Hyperkanten zu fördern, speichert alles in einer herkömmlichen Graph-Datenbank mit binären Kanten. Seine eigenen Autoren zeigen, dass es nichts an Qualität verliert, wenn jede Hyperkante in einige binäre Kanten um einen für das Ereignis erstellten Knoten umgewandelt wird, sodass jede Form exakt aus der anderen wiederaufgebaut werden kann.

Dieser Aspekt bestimmt das gesamte Argument. Angenommen, ein natives Hyperkante und ein verfestigter Cluster binärer Kanten weisen genau dieselbe Inkidenzstruktur auf, und einer von ihnen kann ohne Mühe den anderen erzeugen. Dann hat die Wahl zwischen ihnen keine Auswirkungen auf das Modellieren und entspricht lediglich der Auswahl eines Speicherformats. Ein Kommentator fasste die Mathematik prägnant zusammen: Die beiden Formen sind dieselbe Inkidenzstruktur, und die Breite des Hypertrees ändert sich nur um eine Konstante, wenn die Arität begrenzt ist. Die Breite des Hypertrees bestimmt, wie aufwendig eine Abfrage ist. Die Anzahl der Sprünge nicht, genauso wenig wie die Anzahl der Teilnehmer, die in eine Kante gepackt sind. Konvertieren Sie Ihre Darstellung, verschieben Sie diesen Wert um eine Konstante, halten Sie jede Tatsache bei einer begrenzten Anzahl von Teilnehmern (fünf Personen, die eine Ausgabe genehmigen, nicht fünfhundert), und die Schwierigkeit der Abfrage bleibt unverändert.

Warum das Menschen überrascht

Es ist ein leichter Fehler, den man machen kann. Die Anzahl der Sprünge erscheint intuitiv, da mehr Knoten zwischen Frage und Antwort auf eine schwierigere Abfrage hindeuten. Die Breite des Hypertrees ist hingegen weitaus weniger intuitiv: Sie gehört zur Theorie der Constraint-Befriedigung und Abfragedichte und weicht von der Anzahl der Sprünge auf eine Weise ab, die man erst erkennen kann, wenn man genauer hinschaut. Man kann Strukturen hinzufügen, die für eine bestimmte Abfrage die Anzahl der Sprünge verringern, während sie der Komplexitätsklasse der Abfrage, zu der sie gehört, nichts nützen oder sogar leicht schaden. Beispiele in wissenschaftlichen Arbeiten mögen beeindruckend wirken, verraten aber trotzdem nichts über die Maßzahl, die im Allgemeinen Fall gilt.

Bevor man sich für einen einfachen Graphen, einen reifizierten Graphen oder einen nativen Hypergraphenspeicher entscheidet, hilft diese Vergleichsmöglichkeit.

REPRESENTATION          WHAT IT ADDS                     WHAT IT ACTUALLY CHANGES
---------------------   -------------------------------  --------------------------------
Plain binary graph       Simplest to build and query      Baseline; loses atomicity of
                         with standard graph tooling      multi-participant facts
Reified binary graph     Recovers atomicity via an        Same incidence structure as a
(event node + roles)     explicit "event" node             hyperedge; hypertree width
                                                            shifts by a constant only
Native hypergraph        Hyperedges as first-class         No reduction in query
store                    objects, arguably cleaner          complexity class over a
                         to write against                   reified graph; new storage
                                                             engine to run and maintain

Das macht die Graphstruktur für RAG nicht sinnlos. Die mehrstufige relationale Suche profitiert tatsächlich von Graphen im Vergleich zur flachen Vektorsuche, und das bestreitet niemand. Der Einwand betrifft den zusätzlichen Schritt vom Graphen zum Hypergraphen. Sobald der Nachweis die Argumentation ersetzt, führt dieser Schritt zu übersichtlicheren Datenmodellen, erfordert eine neue Art von Infrastruktur zur Verwaltung und lässt unberührt, was darüber entscheidet, ob Abfragen schnell oder langsam abgewickelt werden. Wenn die Suchleistung schwach ist, ist die Lösung mit entsprechenden Belegen in der Regel eine bessere Graphenerstellung oder eine intelligentere Suchstrategie für bereits erstellte Graphen – nicht ein exotischerer Kantentyp.

Fall drei: Was die Arbeit eines Senior Engineers tatsächlich ausmacht

Sowohl die vorherigen Fälle beziehen sich auf die Sucharchitektur. Der letzte Fall unterscheidet sich, da es hier nicht um die Wahl eines Tools geht, sondern darum, woraus die Arbeit eines Senior Engineers besteht.

Ein Technologieleiter, der ein fünfköpfiges Team in einem Unternehmen mit mehr als tausend Mitarbeitern führt, schrieb, dass KI 95 Prozent seiner Arbeit nicht übernehmen kann. Er beginnt mit dem, was wie ein Zugeständnis klingt: Das Schreiben von Code nimmt mit großem Abstand den kleinsten Teil seiner Zeit in Anspruch. Sein Team arbeitet nach dem Prinzip „Du baust es, du betreibst es“, wodurch die Überwachung der Systeme in den Händen seiner eigenen Ingenieure liegt und nicht in denen einer separaten Betriebsgruppe, die die Produktion als Angelegenheit anderer betrachten könnte. Sein Morgen beginnt um 8:30 Uhr mit der Überprüfung von Pull-Requests. Der eingehende Code, der größtenteils von KI-Agenten erstellt wurde, ist eindeutig besser als das, was er vor zwei Jahren geprüft hatte. Er stellt nicht in Frage, dass KI guten Code schreiben kann – er akzeptiert das voll und ganz – und weist anschließend darauf hin, wie wenig dies seine eigentliche Arbeit verändert.

Dies stellt eine gängige Annahme bei der Betrachtung von Agentenstapeln in Frage – nämlich dass die Fähigkeiten das Tempo der Automatisierung bestimmen. Wenn ein Modell korrekten Code erzeugt, so die Logik, braucht das Programmieren keine Menschen mehr, und die Automatisierung der Aufgabe folgt dem Anteil, der mit der Codeerstellung verbracht wird. Der Technologieleiter behauptet, diese Gleichung habe nie gezählt, und KI mache den Fehler lediglich sichtbar. Seine Aufgabe bestand nicht hauptsächlich aus Programmieren. Es ging vor allem um Koordination: Entscheidungen darüber, was gebaut werden soll und in welcher Reihenfolge, Verhandlungen über den Umfang mit Personen mit kollidierenden Prioritäten, Überprüfung und Unterstützung von Entscheidungen anderer, Übernahme von Kommunikationsaufgaben, Betreuung junger Ingenieure sowie Vermittlung zwischen den Anforderungen der Stakeholder und dem, was das System sicher unterstützen kann. Keine dieser Aufgaben ist eine Programmieraufgabe.

Das ist vermutlich der am meisten übersehene Aspekt in den Diskussionen unter Entwicklern in diesem Jahr – mehr noch als jedes Vergleichsmessinstrument –, denn er erklärt, warum bei vielen Senior-Entwicklern, sogar bei begeisterten täglichen Nutzern, deutlich bessere Codierungsnoten sowie eine deutlich einfachere Arbeit nicht zusammengekommen sind. Dass die SWE-bench-Werte innerhalb von ein paar Jahren von einstelligen Werten in die Siebziger steigen, ist ein echter und großer Fortschritt. Das bedeutet jedoch nicht, dass die Arbeitsbelastung um 70 Prozent abnimmt, denn die Codeerstellung war nie 70 Prozent der Arbeit – schon gar nicht, seit die Rolle auch die On-Call-Dienste, den Entwicklungsplan sowie Pull Requests umfasst.

Eine Einschränkung: Der dritte Punkt lässt sich auf andere Einstellungen nicht so reibungslos übertragen wie die ersten beiden. Behauptungen bezüglich Vektordatenbanken und Hypergraphen können anhand von Benchmarks oder Beweisen überprüft werden. Die Aufteilung zwischen Koordination und Codearbeit in der Woche eines Senior Engineers variiert je nach Unternehmensgröße, Teamreife, ob die zusätzliche Arbeit auf Fehlfunktionen oder auf wesentliche Aufgaben zurückzuführen ist, sowie nach der eigenen Erfahrung des Mitarbeiters. Ein Fünf-Personen-Team in einem tausendköpfigen Unternehmen mit einer „Bau-es-und-Lass-es-laufen“-Politik stellt eine bestimmte Art von Job dar und repräsentiert nicht alle ingenieurtechnischen Positionen. Die Richtung der Korrektur erscheint weiterhin im Großen und Ganzen richtig. Die Fähigkeiten der Agenten begrenzen, wie viel von der Codeverfassung automatisiert werden kann, und sagen fast nichts über den Koordinationsaspekt aus, der niemals von der Tippgeschwindigkeit oder Codequalität abhing.

Das gemeinsame Muster

Legen Sie die drei Fälle nebeneinander – die Lektion bezieht sich nicht speziell auf Vektordatenbanken, Hypergraphen oder KI-Fähigkeiten. Es geht vielmehr um die Kluft zwischen der Stelle, an der ein Bereich den Engpass vermutete, und der tatsächlichen Stelle dieses Engpasses.

CASE                WHERE COMPLEXITY WAS ADDED         WHERE THE REAL BOTTLENECK WAS
------------------  ----------------------------------  --------------------------------
Agent memory         Vector embeddings, similarity       Whether the model can use a
                     search, sometimes a graph layer      retrieval method it already
                     on top of that                        has deep fluency with
RAG structure         Native hyperedges, a new             The complexity class governing
                      storage engine, more                  query cost, which the fancier
                      elaborate graph modeling               structure barely touches
"How much of the      An assumption that model             Whether the job was ever
job gets automated"   capability alone predicts             mostly about the thing the
                       the automatable fraction              model is good at

Keine der fortschrittlichen Optionen ist deshalb falsch, weil sie existiert. Vektordatenbanken haben tatsächliche Anwendungsbereiche, Hypergraphen könnten an Stellen helfen, die bisher noch niemand entdeckt hat, und KI-Agenten beseitigen tatsächlich viel monotone Arbeit in der Ingenieurarbeit, was der Technologieleiter anerkennt. Der Fehler bestand darin, die Frage zu übergehen, ob die zusätzliche Komplexität sich auf das eigentliche Engpassproblem richtet oder nur auf das, für das es am einfachsten ist, eine aufwändige Lösung zu entwickeln.

Diese Gewohnheit erstreckt sich weit über die Entwicklung von Agenten hinaus. Ein zusätzliches Layer hinzuzufügen ist einfacher, als zu prüfen, ob der ursprüngliche Standard jemals fair damit verglichen wurde. Eine neue Abstraktion gilt als sichtbarer Fortschritt, auf den man verweisen und den man als Upgrade bezeichnen kann. Zu überprüfen, ob grep bereits die Aufgabe erledigt, ob die Abfragedichte tatsächlich verbessert wurde oder ob das Problem, das eine ganze Woche in Anspruch nimmt, tatsächlich das ist, was man angenommen hat, dauert länger, fühlt sich schwieriger an und endet manchmal mit der Entscheidung, mit der Entwicklung aufzuhören.

Checkliste vor dem nächsten Layer

Eine kurze Liste, die vor dem Hinzufügen eines weiteren Layers mit jedem Stack abgeglichen werden sollte:

1. Have I benchmarked the boring baseline, not just assumed it loses?
   (full-context, grep, a plain graph, a human doing the coordination)
2. Does the new structure change the metric that actually governs cost
   or quality, or does it just look more sophisticated on a diagram?
3. Am I reaching for this because a benchmark or proof told me to,
   or because it's what the tutorials and the funded products default to?
4. If I strip this layer back out, what specifically breaks?
   If I can't name it precisely, I probably don't need the layer yet.
5. Am I solving the bottleneck I actually have, or the bottleneck
   that's most interesting to build a sophisticated solution for?

Das alles spricht nicht dafür, weniger Ingenieurarbeit zu leisten. Es spricht dafür, die Ingenieursanstrengungen darauf zu verwenden, herauszufinden, wo sich das Engpassproblem befindet, bevor man etwas Komplexes baut, das davon ausgeht, die Antwort bereits zu kennen. Die drei Autoren taten dies nicht aus Gegensinn. Sie führten die unattraktiven Überprüfungen durch, und diese Überprüfungen standen im Widerspruch zur gängigen Annahme. Das ist ein weitaus höheres Maßstab als eine provokante These mit einem auffälligen Schlagzeilenformat – und genau daran sollte jede Architektur gemessen werden.