Warum das Memory eines Programmier-Agenten nur das Delta enthalten sollte und wie es gespeichert werden kann.
Das Speicher des Kodierungs-Agenten sollte nur das enthalten, was das Modell nicht erraten konnte. Vier Tests für jeden Eintrag, drei Anforderungen für den Speicher und warum Markdown in Git gut passt.
Quellen: Why Your Agent Needs Memory, and How to Organize It
Stellen Sie sich einen persönlichen Speicher für Erinnerungen vor, der für einen Programmieragenten auf einem einzigen Rechner gespeichert wird. Er enthält 181 Themendateien hinter einem 134 Zeilen umfassenden Index – und fast nichts davon stellt Wissen im üblichen Sinne dar. Der Agent versteht bereits Express-Middleware, die Struktur eines Playwright-Tests sowie die Funktion eines Dockerfiles, nachdem er über all drei weitaus mehr gelesen hat als irgendein Mensch. Jede Zeile in diesem Speicher existiert aus dem gegenteiligen Grund: Sie markiert einen Punkt, an dem eine bestimmte Situation von dem Durchschnitt abweicht.
Zwei Beispiele veranschaulichen diese Idee. Ein Deploy-Verifier blockiert eine Veröffentlichung, sobald eine Überprüfung nicht ausgeführt werden kann – und das ist beabsichtigt. Die Selbstfreigabestelle eines Release-Trainings liest .status anstelle von .conclusion; ein Detail, das einen Nachmittag gekostet hat, bevor es zu einer einzigen Zeile in einer Datei wurde.
Das ist die Form einer guten Agentenmemorie. Es handelt sich nicht um eine Kopie dessen, was der Agent weiß. Es ist das Delta, der verbleibende Teil. Alle sind sich einig, dass ein Agent eine Memorie benötigt, und niemand hat eine konkret definiert, daher umfasst der Rest dieses Textes zwei Schritte: erstens warum ein Agent überhaupt eine Memorie braucht und zweitens wie man sie organisiert. Der zweite Teil ist in vier Abschnitte unterteilt: Einfachheit bewahren, die Anforderungen an jede Memorieneinheit sowie an den Speicher, der Speicher, der diesen Anforderungen gerecht wird, und die Routine, mit dieser Memorie umzugehen.
Agentenmemorie ist keine menschliche Memorie
Der natürliche Instinkt ist es, analog zu argumentieren. Menschen erinnern sich an Dinge, also sollten es auch Agenten tun. Die Analogie versagt bereits beim ersten Schritt. Ein Mensch beginnt mit leeren Händen, weshalb die menschliche Memorie sowohl das Durchschnittliche als auch die Ausnahmen speichern muss. Ein Modell hingegen kommt bereits mit dem Durchschnittsvertag vorgefertigt – auf einer Skala, die über jeden einzelnen Menschen hinausgeht. Dem Modell mitzuteilen, was Middleware ist, liefert keine zusätzlichen Informationen; es fügen sich lediglich Token hinzu.
Tokens haben einen Preis, und genau da machen viele Menschen den Fehler. Kontext, der nicht benötigt wird, ist nicht neutral – er stellt einen Nettoverlust dar. In einer Studie zählten Forscher, wie häufig ein Modell API-Aufrufe korrekt durchführte. Wenn das Modell Dokumentation zu APIs erhielt, die es bereits gut kannte, und die Abrufung unvollkommen war, sank seine Rate an korrekten Aufrufen um 39 Prozentpunkte. Das Herunterladen solcher Dokumentationen für seltene APIs, die das Modell noch nicht gesehen hatte, half hingegen und steigerte die Genauigkeit um neun Punkte. Derselbe Inhalt und derselbe Ablauf – doch die Wirkung änderte sich ins Gegenteil.
So betrachtet ist eine Speicherdatei eine Art Unterschiedsbericht, der auf den bestehenden Annahmen des Modells aufgebaut ist. Jede Zeile, die eine bekannte Konvention wiederholt, konkurriert um die Aufmerksamkeit mit der einzigen Zeile, die wirklich wichtig ist – und genau an Aufmerksamkeit mangelt es.
Erhalten Sie nur das auf, was das Modell nicht hätte erraten können.
Wenn man echte Kontextdateien durch diesen Filter laufen lässt, verschwindet der größte Teil ihres Inhalts. Namensregeln, das Prinzip „Komposition statt Vererbung“ sowie die Struktur der Standardordner sind allgemein bekanntes Wissen, das von Lintern erfasst wird und bereits im Modell enthalten ist. Was übrig bleibt, sind in der Regel unpraktische Elemente: Workarounds, aufgegebene Pfade oder Eigenschaften, die in dieser Codebasis zutreffen, aber nirgendwo sonst.
In dem Beispielladen, der etwa 3.700 Zeilen lang ist (3.831, wenn auch der Index mitgezählt wird), gibt es keine Zeile, die angibt, welches Middleware-Tool verwendet wird oder wie man Tests strukturiert. Zeilen, die dazu dienen, ein bekanntes Tool zu erklären, werden entfernt, da das Modell dies bereits wusste – dadurch wurden unnötig Tokens bei jeder Anfrage verbraucht.
Der günstigste Speicher ist der, den man nicht benötigt
Falls ich mich richtig erinnere, hängt die Größe des Delta davon ab, wie stark sich ein Projekt vom üblichen Muster entfernt. Wenn man der üblichen Architektur folgt, muss dem Agenten fast nichts gezahlt werden, denn er kennt sich im Gebiet aus. Erfindet man hingegen ein eigenes Modulsystem, werden jede seiner Regeln zu Zeilen, die geschrieben, eingehalten und bei jeder Anfrage bezahlt werden müssen.
Es ist kein Benchmark nötig, um die Auswirkungen zu spüren. In einem etablierten Technologiestack erledigt der Agent seine Aufgabe einfach weiter. In einer Nischen-Sprache oder einem selbst entwickelten internen Framework hingegen pausiert er, tippt ins Blaue oder stellt Fragen. Um diese Lücke zu schließen, muss man den Kontext selbst tragen: man schreibt ihn auf, versioniert ihn und hält ihn dauerhaft aktuell.
Es gibt keinen sauberen A/B-Test für diese Behauptung, und es wäre unehrlich, so zu tun, als gäbe es einen. Die hier zitierte Forschung stützt den Mechanismus, während die Dateien einer Person nur die Praxis belegen, was jedoch kein Beweis für den Mechanismus ist. Die Erfahrung ist jedoch konsistent: Neue Arbeiten in gewöhnlichen Strukturen laufen schnell ab, während Arbeiten in großen, alten Systemen, in denen der größte Teil des Kontexts niemals aufgeschrieben wurde, langsamer voranschreiten – manchmal sogar langsamer als die manuelle Ausführung.
Daher sind Architekturentscheidungen zu Entscheidungen bezüglich des Speichers geworden. Wählt man das langweilige, weit verbreitete Muster, muss man nichts weiter dauerhaft warten. Jeder Abweichung vom üblichen Muster muss jemand eine Zeile aufschreiben und diese genau halten, und ein individueller Weg kostet bei jeder späteren Anfrage mehr, nicht nur bei derjenigen, die ihn erstellt hat.
Der schwierige Teil ist es, klein zu bleiben
Das ist der Grund. Die Art und Weise beginnt mit einer unangenehmen Tatsache: Was Speichersysteme in der Praxis zerstört, ist nicht das Vergessen, sondern die Anhäufung.
Die Nützlichkeit hinkt der Größe hinterher. Doppelte Menge an Speicher bedeutet nicht doppelten Wert, denn Unordnung sammelt sich schneller an als nützliche Informationen, und ab einem bestimmten Punkt liefert ein größerer Speicher schlechtere Ergebnisse als ein kleinerer – selbst bei den Fragen, für die er ursprünglich konzipiert wurde.
Konflikte nehmen schneller zu als die Größe. Jede neue Information kann mit jeder bestehenden in Widerspruch geraten, wodurch die Anzahl möglicher Konflikte viel schneller steigt als die Anzahl der Dateien. Ein Widerspruch kostet außerdem weitaus mehr als ein fehlender Datensatz. Wenn eine Information fehlt, ist das System unsicher – und Unsicherheit ist akzeptabel: Es fragt nach oder versagt dort, wo Menschen es sehen können. Wenn zwei Informationen miteinander im Widerspruch stehen, ist das System zuversichtlich, doch falsch – und da im System nichts als fehlerhaft erscheint, bemerkt es niemand.
Schlimmer noch: Die meisten Speichelösungen erkennen das Problem nicht. Die Vektorähnlichkeit erkennt zwar zwei Sätze zum selben Thema, bemerkt aber nicht, dass der eine „ja“ und der andere „nein“ sagt. Dadurch flacht der Wert ab, die Konflikte nehmen zu, und ab einer bestimmten Größe verschlechtert das Speichersystem die Leistung des Agents.
Der Speicher versagt selten offensichtlich. Er versagt, indem er zuversichtlich falsche Antworten liefert, obwohl jede Abfrage weiterhin erfolgreich ist.
Die Herausforderung besteht also nicht darin, immer mehr Daten anzuhäufen – schließlich tun das alle Lösungen gerne –, sondern darin, klein zu bleiben, während gleichzeitig ausreichend Leistung gegeben wird. Dafür ist das Löschen notwendig, und das Löschen bedeutet, eigene alte Texte zu bewerten.
Menschen neigen dazu, zunächst nach Struktur zu greifen. Wenn sie mit einem chaotischen Haufen konfrontiert sind, fügen sie eine Taxonomie aus Hierarchien, Kategorien, Graphen oder formalen Wissensstrukturen hinzu. Das führt jedoch zuverlässig zu negativen Ergebnissen. In einer Bewertung aus dem Jahr 2026 wurde die Erhöhung der Tiefe eines auf Anfrage arbeitenden Kontextindex mit demselben Modell getestet – die Genauigkeit sank dabei von 0,91 auf 0,64. Flache Strukturen übertrafen überall dort, wo sie getestet wurden, hierarchische Strukturen. Eine ausgefeilte Struktur beseitigt die Komplexität nicht; sie ist vielmehr eine weitere Komplexität, die auf der ersten liegt, und nun müssen beide gewartet werden.
Die Organisation des Gedächtnisses geht daher weniger darum, ein besseres Diagramm zu erstellen, sondern vielmehr darum, eine Hürde festzulegen, die jede „Linie“ überwinden muss, sowie einen Speicher bereitzustellen, der dieses Überwinden kostengünstig macht.
Vier Tests für jede Gedächtnis-Einheit
Die Hürde gilt für die Einheit selbst, nicht für das gesamte System. In einem Team sind dies auch die Kriterien, nach denen ein Prüfer vorgeht.
- Einfach und prägnant. Nur Sammelinformationen. Kein Satz existiert nur, um vollständig zu klingen. Eine Zeile, die nichts an dem Verhalten des Agenten ändert, ist reine Dekoration – und Dekoration hat ihren Preis.
- Konfliktfrei. Es dürfen keine zwei Fakten geben, die gleichzeitig wahr sein können. Dafür ist aktive Anstrengung nötig, da Konflikte langsam entstehen und niemals absichtlich erzeugt werden.
- Messbar nützlich. Das Speichern von Informationen macht einen Agenten nicht intelligenter. Es macht ihn lediglich schneller und kostengünstiger bei derselben Qualität, wodurch dieselben Antworten ohne erneute Auswertung bereitgestellt werden. Eine Datei, die bei einer echten Aufgabe keinen sichtbaren Zeit- oder Ressourcenvorteil bringt, rechtfertigt ihre Aufrechterhaltung nicht.
reference_-Dateien, festgelegte Regeln in 50 feedback_-Dateien und vorübergehende Zustände in 14 project_-Dateien. Ein Leser weiß bereits vor dem Öffnen einer Datei, was sie enthält.Ein veröffentlichtes Ergebnis scheint den dritten Test zu untergraben und unterstützt ihn tatsächlich. Forscher an der ETH Zürich führten einen Vergleich von Kontextdateien in Repositorien mit dem Fehlen solcher Dateien durch. Dabei wurde kein allgemeiner Vorteil bei der Erfolgsrate der Aufgaben festgestellt, stattdessen stieg der Inferenzaufwand um mehr als zwanzig Prozent, und von Maschinen erstellte Dateien erzielten leichte schlechtere Ergebnisse als das Fehlen jeglicher Dateien. Wenn man die Delta-Regel prüft, handelt es sich dabei nicht um ein gegenteiliges Ergebnis. Eine Datei, die durchschnittliches Wissen enthält, ist genau das, was die Regel voraussagt – sie verursacht Kosten, bringt aber keinen Vorteil. Die Erkenntnis besagt nicht, dass Kontextdateien versagen, sondern nur, dass Dateien, die das Durchschnittswissen wiedergeben, versagen, was auf die meisten von ihnen zutrifft.
Diskretion bedeutet daher weniger Schreiben und mehr Reduzierung: Jede Zeile bleibt dicht, und kein Paar von Zeilen darf widersprüchlich sein.
Addy Osmani ging im August von der Wartungsebene aus auf dasselbe Problem ein und argumentierte, dass Agentendateien mit der Verbesserung der Modelle veralten (sein Beitrag trägt den Titel „Prüfung der Agentendateien“), weshalb sie regelmäßig bereinigt und neu erstellt werden sollten anstatt endlos zu wachsen. Ein Speicher, der sich nur ausdehnt, zählt rückwärts.
Teilen Sie anschließend das Übriggebliebene nach Aufgaben auf, wie Sie es auch bei der eigenen Abruflogik tun. Was zum Schreiben von Texten geladen wird, unterscheidet sich von dem, was zum Debuggen einer Build-Version benötigt wird.
Niemand braucht einen gesamten Speicher. Was benötigt wird, ist das kleinste mögliche, korrekte Stück für die jeweilige Aufgabe.
Drei Anforderungen an den Speicher
Diese vier Tests sagen nichts darüber aus, wo die Dateien gespeichert sind – was die andere Hälfte der Organisation darstellt.
Ein Hinweis kommt von dem, was bereits vorhandene Tools miteinander teilen. AGENTS.md ist eine gewöhnliche Markdown-Datei an einem vorhersehbaren Pfad, und mehr als zwanzig Tools lesen sie, obwohl ihre Entwickler in fast allen anderen Bereichen konkurrieren. Konkurrierende Anbieter haben noch nie beide dieselbe Speichermanagement-API implementiert.
Eine Umfrage zu verfügbaren Code-Agenten (veröffentlicht auf Substack) zeigte, dass sieben davon ohne Koordination auf ein gemeinsames Design hinarbeiten: eine kleine Markdown-Datei, die stets im Kontext vorhanden ist, sowie ein größeres Archiv auf der Festplatte, das dann geöffnet wird, wenn eine Aufgabe dies erfordert. Keiner von ihnen nutzt Vektorabfragen. Obwohl sie keinen gemeinsamen Vergleichsmaßstab haben, erfüllen alle sieben dieselben drei Anforderungen.
Suchfunktion ohne Installation erforderlich. Unter „Suche“ versteht man in der Regel eine semantische Suche, was jedoch nicht einmal der übliche Fall ist. Anthropics eigenes Speichermittel ermöglicht das Anzeigen, Erstellen, Ersetzen, Einfügen, Löschen und Umbenennen von Inhalten, besitzt aber überhaupt keine Abfragemöglichkeit. Der Agent listet einen Ordner auf und liest dessen Inhalte. Eine Speichermethode, die nur dann funktioniert, wenn der Index erstellt wurde, die Embeddings aktuell sind und der Anbieter verfügbar ist, stellt eine Schwachstelle im Kontext dar. Sie muss weiterhin funktionieren, wenn all das nicht mehr gegeben ist.
Änderbar, während jemand zuschaut. Die sich selbst aktualisierende Speicherung ist der Bereich, der Schaden nimmt. Eine Überprüfung von 10.134 automatisch extrahierten Einträgen in der Produktion ergab laut Berichten, dass 97,8 % davon nutzlos waren. Eine weitere Studie ließ Modelle ihre erfolgreichen Ausführungen wieder in den Speicher speichern und stellte bei allen vier getesteten Agenten schlechtere Ergebnisse fest als ohne Speicherung. Der selbstschreibende Speicher verändert sich mit hoher Unsicherheit – nicht sanft –, weshalb jede Änderung als Unterschied sichtbar sein muss, ablehnbar und rückgängig machbar.
Wartbar mit bereits verfügbaren Tools. Korruption beendet selten ein Speichersystem. Vernachlässigung hingegen schon: Die Datei wird einmal geschrieben, niemand kümmert sich weiter darum, und sie wird allmählich ungenau. Laut einer Zusammenfassung einer Studie aus dem Jahr 2026 wurden die Hälfte der Kontextdateien nach dem ersten Commit nie mehr geändert, und die 6 %, die weiterhin überarbeitet wurden, gehörten Personen, die tatsächliche Vorteile durch den Agenten berichteten. Die Wartung muss im Editor erfolgen – also in der Such- und Versionskontrolllösung, die die Menschen ohnehin täglich nutzen.
Das ist die vollständige Spezifikation. Was noch fehlt, ist die Frage, welcher Speicher sie erfüllt.
Warum Markdown-Dateien in Git geeignet sind
Der Vorschlag, Dateien zu verwenden, ist nichts Neues. Autoren auf Medium haben in diesem Jahr mindestens sechsmal argumentiert, dass „Markdown Vektordatenbanken für die Agenten-Speicherung überlegen ist“, und in Threads auf Hacker News tauchen ständig Scherze auf, die letztendlich auf die Verwendung von Plain Text hinauslaufen. Was selten mitgeteilt wird, ist die Begründung dafür.
Drei Anbieter, die Speicherdatenbanken verkaufen, veröffentlichten innerhalb von drei Monaten Argumente gegen die Verwendung von Dateien, während die beiden Anbieter der führenden Agenten bereits auf Dateien setzten. Der Vorteil hier besteht nicht darin, etwas zu verkaufen, sondern lediglich darin, eine Dateiordner zu nutzen.
Was das Feld speichert
Was ein System speichert, bestimmt alles Weitere.
- Mem0 speichert einen vom LLM extrahierten Satz zusammen mit seiner Embedding-Darstellung – eine Zeile in einem Vektorindex. Was zurückkommt, ist nicht das ursprüngliche Dokument, sondern eine Paraphrase des Extraktors, und es lässt sich nicht öffnen.
- Zep speichert für jeden Fakt eine eingegebene Kante im Graphen und verfolgt pro Fakt zwei Zeitlinien, sodass jeder eine Gültigkeitsperiode aufweist. Korrekturen erfolgen durch Ersetzung: Die alte Kante wird als ungültig markiert, anstatt bearbeitet zu werden.
- Eine auf Vektoren spezialisierte Speicheralternative hat jahrelang Vektorarchive betrieben. Anfang 2026 wechselte sie den Standardspeicher für ihre Programmieragenten auf einen Baum aus Markdown-Dateien in einem Git-Repository und führte bei jeder Änderung einen Commit durch.
- Anthropic stellt ein Speichermittel bereit, das lediglich Dateioperationen im Verzeichnis
/memoriesvornimmt und vom eigenen Client des Kunden ausgeführt wird. Seine noch im Beta-Stadium befindliche Memory Stores API benennt die Ressourcen nach Pfaden im Dateisystem-Stil und löst gleichzeitige Schreibvorgänge mithilfe eines Inhaltshashes, was im Grunde dem Datenmodell von Git mit einer HTTP-Oberfläche entspricht. - Verbraucherassistenten liefern eine Zusammenfassung, die die Benutzer nur in der angezeigten Form einsehen können. Bis September 2026 existiert für keinen von ihnen eine dokumentierte, maschinenlesbare Exportversion.
Im Grunde liegt die eigentliche Trennlinie darin, ob an den Speicher zugegriffen werden kann – die Einteilung in Dateien versus Datenbanken übersieht dies. Alle nicht-dateibasierten Optionen haben eines gemeinsam: Der Speicher kann nicht zwischen zwei Zeitpunkten verglichen werden. Korrekturen erfolgen durch einen Schalterwechsel, nicht durch einen Commit.
Jede Gruppe hat Recht – und liegt teilweise falsch
Im März 2026 behauptete MatrixOrigin, statisches Markdown würde mit der Zeit verfallen und nichts durchsetzen. Fünf Wochen später veröffentlichte Mem0 einen Beitrag mit dem Titel „Ist das Gedächtnis Ihres KI-Agenten nur eine Datei? Das ist das Problem“, in dem argumentiert wurde, dass flache Dateien die vor-datenbankbezogenen Fehler der 1970er Jahre wiederholen: keine semantische Suche, kein zeitliches Denken, keine sicheren gleichzeitigen Schreibvorgänge und kein Vergessen. Im Juni fügte Zep hinzu: „Markdown ist kein Agentengedächtnis“, und betonte dabei, dass eine Markdown-Datei nur zeigt, was geschrieben wurde – niemals, was sie ersetzt hat oder warum.
Unterdessen speichert Anthropics eigener Programmieragent sein Gedächtnis als gewöhnliches Markdown auf der Festplatte, und Windsurfs Dokumentation rät stillschweigend dazu, alles, was aufbewahrt werden sollte, aus dem Gedächtnisspeicher heraus in Markdown unter Versionskontrolle zu übertragen. Es lohnt sich, zu beobachten, wer was verkauft.
Datenbankanbieter haben tatsächlich zwei gültige Argumente. Vektoren haben Vorteil, wenn die Frage und die Notiz kein gemeinsames Vokabular aufweisen – wie bei der Anfrage nach „dem Phänomen des Ausgebranntseins“ im Vergleich zu einer Notiz, die niemals das Wort „Ausgebranntsein“ verwendet. Nur eine Embedding-Technologie kann diese Lücke bei konstanter Geschwindigkeit bei Millionen von Datensätzen überbrücken. Grep kann nichts finden, was man nicht benennen kann.
Graphen haben Zeitvorteile. Um herauszufinden, was jemand letztens am Dienstag geglaubt hat und was es ersetzt hat, sind Fakten mit Start- und Enddaten erforderlich; ein Ähnlichkeitswert kann nicht angeben, welcher von zwei widersprüchlichen Fakten aktuell ist. Ein von Drittanbietern durchgeführter Neuvorlauf zu den zeitbezogenen Fragen eines Langzeitgedächtnis-Benchmarks ergab demnach 63,8 % für das Graphensystem gegenüber 49,0 % für das Vektorsystem. Bei beiden Ansätzen haben Dateien Nachteile.
Die Beweise – mit ihrer Einschränkung
Die Ergebnisse der Suche im Jahr 2026 überraschten die Branche. Agenten, die mit grep, find sowie dem direkten Lesen von Dateien vorgingen, übertrafen alle Baseline-Methoden basierend auf Schlüsselwörtern, Embedding-Technologien und Neubewertungen. Eine Benchmark-Studie zeigte, dass das Entfernen des Embedding-basierten Suchmechanismus und das Erlauben den Agenten, die Dateien direkt zu lesen, die Genauigkeit von 69 % auf 80 % steigerte, bei fast einem Drittel geringerer Kosten. Eine weitere Studie zu Fragen im Bereich Langzeitgedächtnis ergab, dass die einfache Schlüsselwortsuche in jeder Konfiguration mit integrierten Tool-Aufrufen der semantischen Suche überlegen war. Wenn die Ergebnisse jedoch als Dateien zurückkamen, änderte sich die Reihenfolge bei der Hälfte der Vergleichspaare – schließlich belohnten die Fragen die Findung exakter Informationen wie Datumsangaben, Zahlenwerten, Identifikatoren oder Fehlermeldungen.
Der Artikel zur agentenbasierten Suche enthält außerdem eine klare Einschränkung: Wenn die Anzahl der Dokumente von 100.000 auf 400.000 erhöht wird, sinkt die Genauigkeit derselben Methode von 80 % auf unter 40 %, während gleichzeitig dreimal so viele Toolaufrufe erforderlich sind. Grep funktioniert nur innerhalb eines bestimmten Umfangs und ist keine Naturgesetzlichkeit. Innerhalb dieses Rahmens hat Grep Vorteile hinsichtlich Qualität und Kosten, außerhalb versagt es jedoch.
Die ehrliche Frage ist daher, auf welcher Seite dieses Rahmens sich ein System befindet – und nicht, welche Methode im Allgemeinen vorteilhafter ist. Eine Sammlung von 181 Dateien ist hunderte Male kleiner als die Mengen, bei denen Probleme angeblich auftreten. Ein Produktionsmemoriesystem in einem großen Unternehmen wie LinkedIn ist das nicht – und niemand behauptet, es sollte Markdown verwenden.
Leistungsübersicht: Dateien gegenüber Alternativen
Gegenüber diesen drei Anforderungen erfüllen Markdown-Dateien jede einzelne nahezu ohne Kosten. Grep dient als Ersatzlösung – jede Änderung wird als Diff dargestellt (ein rückgängig machbarer Commit innerhalb eines Repositories) – und die Wartungstools sind bereits auf dem Desktop verfügbar.
Zwei weitere Vorteile entstehen kostenlos. Widersprüche treten auf, weil zwei widersprüchliche Fakten in Form von zwei Textzeilen statt in Form von zwei Float-Arrays vorliegen, und das gespeicherte Format dient gleichzeitig als Exportformat.
Der Kompromiss sollte benannt werden anstatt versteckt zu bleiben. Dateien sind den Embeddings unterlegen, wenn eine ungenaue Suche in vielen Dokumenten erforderlich ist. Die Lösung besteht darin, einen Index über den Dateien zu erstellen, der jederzeit neu aufgebaut werden kann, anstelle ihn an deren Stelle zu setzen. Basis-Memory-Lösungen bauen diesen Layer auf SQLite auf, memsearch auf Milvus, und Karpathys Idee der komponierten Wiki kommt ohne Embeddings aus und beschränkt sich auf eine einfache Indexseite. Wenn der Index die Speicherung darstellt, müssen Inspektion, Vergleich, Eigentumsrechte und Portabilität geopfert werden, um eine ohnehin bereits verfügbare Suchfunktion zu erhalten.
Wenn man etwas nicht mit grep durchsuchen, mit diff vergleichen und eine Zeile daraus löschen kann, dann ist das nicht das eigene Gedächtnis – es handelt sich dabei um jemandes Cache über einen selbst.
Wie ein laufendes System aussieht
Prinzipien sind kostengünstig, daher hier eine funktionierende Konfiguration.
- Schichten von Verweisen, ohne Manifest.** Die erste Datei, die der Agent öffnet, umfasst 21 Zeilen. Sie fungiert als Karte mit drei obersten Bereichen, jeweils einer Zeile, die auf tiefere Dateien verweisen. Einen Ebene tiefer enthält eine Projektdatei das wirklich Persönliche: das aktive Repository im Vergleich zu dem, das bei einem Umbenennen verloren ging, die Versionen, an denen alles gebunden ist, sowie die Kommunikationsregeln, die eingehalten werden müssen. In der Projekthierarchie befinden sich insgesamt 28 solcher Dateien, alle handgeschrieben, wobei jede nur geladen wird, wenn die Arbeit dorthin führt.
- Eine Datenbank, die der Agent schreibt, wird von einem Menschen freigegeben.** Daneben gibt es das automatische Speichersystem mit 181 Themendateien hinter einem 134 Zeilen langen Index. Nur der Index wird beim Start einer Sitzung geladen, und eine Themendatei wird sofort geöffnet, sobald eine Aufgabe sie benötigt.
Schichten zum Laden, nicht zum Schlussfolgern
Zählt man die oben genannten Ebenen, so gibt es vier – das ist die Tiefe, vor der das frühere Ergebnis von 0,91 auf 0,64 warnt. In dieser Studie war jedoch die Variable die Tiefe, während ein Index in jeder Konfiguration beibehalten wurde. Die beste Konfiguration bestand aus einem flachen Index pro Aufgabe: Der Agent liest diese in einer einzigen Durchlaufphase ein, bevor er entscheidet, was geöffnet werden soll, wodurch die Genauigkeit im Vergleich zur reinen Navigation fast verdoppelt wurde – bei etwa der Hälfte der Kosten. Die Ergebnisse verschlechterten sich nur dann, wenn der Index Zweige entwickelte, die das Modell wieder hinabklettern musste, um allein anhand der Etiketten zu erraten, welcher Zweig die richtige Antwort enthielt.
Der Index dieser Konfiguration ist eine einfache Sortierung: eine einzige Ebene, die bei Beginn einer Sitzung vollständig gelesen wird. Er umfasst 134 Einträge, jeweils etwa einen pro Thema, wobei jeder Eintrag die darauf verweisenden Dateien mit einer kurzen Zusammenfassung benennt. Es gibt keine Verzweigungen, sodass keine Raten notwendig sind. Es handelt sich um eine kleine, manuell gepflegte Routentabelle – keine Taxonomie, über die das Modell nachdenken muss – und sie kann unvollkommen sein: Elf der 181 Dateien fehlen darin. Die Themendateien sind klein, einfach strukturiert und werden vollständig gelesen; eine Ebene wird geöffnet, weil Arbeit in ihr Bereich gelangt ist, und nicht, weil eine Abfrage danach sucht. Das ist progressive Offenlegung.
Der Test ist einfach. Wenn das Modell allein anhand der Bezeichnungen raten muss, welche Verzweigung die Antwort enthält, wurde ein Baum aufgebaut und der Wert liegt bei 0,64. Wenn es den gesamten Index liest und eine Datei anhand ihres Namens öffnet, handelt es sich um eine Ladereihenfolge.
Die Struktur dient dazu, zu entscheiden, was geladen werden soll. Sie existiert nicht dafür, dass das Modell darüber nachdenken kann.
Schutz vor Abweichungen
Der Agent schlägt vor, die Änderung erscheint als Diff, und eine Person kann sie akzeptieren oder nicht. Dateien, die in Repositorien gespeichert sind, haben ihre eigene Historie, was bedeutet, dass die Frage, warum der Agent etwas für wahr hält, durch Lesen beantwortet werden kann – etwas, was weder ein Vektorlagertyp noch eine Speicherpágina eines Anbieters bieten kann. Eine von niemandem überprüfte Speicherung ist nur ein Gerücht mit Dateinamen.
Gelegentlich findet eine einfache Aufräumarbeit statt: Zeilen, die im Juni noch zutrafen, Dateien, die das Modell seitdem übernommen hat, sowie Regeln, die durch bessere ersetzt wurden, werden gelöscht. Speicher werden häufiger verkleinert, als die Leute erwarten.
Alles ist reiner Markdown auf der lokalen Festplatte und funktioniert ohne den Assistenten, der bei der Erstellung geholfen hat. Wenn nächstes Jahr eine leistungsstärkere Version verfügbar ist, richte sie auf denselben Ordner aus und setze fort.
Eine Überprüfung, die Sie heute durchführen können
Die Struktur passt auf eine Karte: vier Tests für jede beibehaltene Zeile, drei Anforderungen bezüglich des Speicherorts und eine menschliche Kontrolle zwischen dem Agenten und der Datei.
Um Ihre eigene Position zu ermitteln, öffnen Sie die Kontextdatei des Projekts – egal ob es CLAUDE.md, AGENTS.md oder irgendetwas anderes ist, was das Tool liest – und löschen Sie jede Zeile, die das Modell ohne Hilfe erraten hätte. Ein Reduzieren um die Hälfte ist ein realistisches Ergebnis. Geben Sie anschließend die nächste echte Aufgabe der gekürzten Datei und prüfen Sie, ob sich etwas verschlechtert. Danach fügen Sie jedes Mal, wenn der Agent bei etwas Fehler macht, das er nicht wissen konnte, eine einzige Zeile hinzu und lassen Sie diese wie Code überprüfen. Das ist die Disziplin – und sie skaliert nicht durch das Hinzufügen weiterer Elemente.
Der Agent kennt bereits den Durchschnittswert. Die einzige Aufgabe ist der Delta-Wert.
Verwandte Artikel
- Warum Agenten-Merkmalsmessungen irreführen – und wie man mit eigenen Daten bewerten kann — Offizielle Merkmalsranglisten weisen fehlerhafte Lösungskarten und Bewertungsmethoden auf. Trennen Sie die Informationsabrufung von den Antworten, fügen Sie Überprüfungen auf Konsistenz, Aktualität, Enthaltung und Vergesslichkeit hinzu sowie den Kostenverlauf.
- Prompt-Injection und die tödliche Dreifaltigkeit: Wie man KI-Agenten sichert — Warum Agenten Ihre Anweisungen nicht von denen eines Angreifers unterscheiden können, wie die EchoLeak- und GitHub MCP-Angriffe funktionierten und welche Schutzmaßnahmen wirksam sind.