Agenten-Speicher als Markdown-Dokumente: Ein lesbares Gedächtnis ist immer noch ein Gedächtnis

Kevin Liao hat am 3. Oktober einen Essay veröffentlicht, dessen Titel den Großteil der Argumentation schon erledigt: Agenten brauchen kein Gedächtnis, sie brauchen Dokumentation. Seine Kritik richtet sich gegen das Memory-Plugin, wie es meistens ausgeliefert wird, eine Pipeline, die Sitzungsprotokolle in Schnipsel zerlegt, sie einbettet und die paar nächstgelegenen an jeden Prompt hängt. Seine Liste dessen, was dabei schiefgeht, ist kurz und größtenteils richtig. Der Satz, den ich daraus behalten würde, ist dieser:

Similarity search ranks how close two snippets are in embedding space. That’s it. You don’t know which is correct, current, or what’s missing.

Sein Ersatz ist ein Arbeitsbereich aus schlichtem Markdown, den der Agent liest, bevor er arbeitet, und danach überarbeitet. Aus „Bauen und Vergessen“ wird „Nachschlagen, Bauen, Aktualisieren“. Er hat das als Operator Memory veröffentlicht, und es ist sorgfältiger gebaut, als der Essay auf seinem Raum zeigen kann: eine feste Orientierung, die in jede Sitzung geladen wird, Kataloge, die sagen, wann sich das Öffnen eines Dokuments lohnt, private und geteilte Bereiche. Die Auto-Memory von Claude Code hat dieselbe Grundform, typisierte Notizen in Markdown-Dateien unter einem MEMORY.md-Index, alles von Hand editierbar.

Der Richtung stimme ich zu. Ich pflege einen Speicher-Server für Agenten, agent-recall, und auch darin steckt keine Vektordatenbank: Es ist eine SQLite-Datei mit Volltextsuche über Entitäten und die Fakten, die an ihnen hängen. Aber der Essay schreibt dem Format und der Schleife mehr zu, als sie leisten. Zusammenhängende Dokumente beheben zwei seiner fünf Fehler, den verlorenen Kontext und das Ranking nach Ähnlichkeit, und lesbare Dateien beheben einen dritten, die Prüfbarkeit. Was sie nicht garantieren: dass eine Seite aktuell ist, dass der Agent die richtige geöffnet hat oder dass sich zwei Schreiber einig waren. Das hing nie davon ab, wie die Bytes gespeichert sind, also zieht es mit allem anderen in den Ordner um. Dort ist es schwerer zu sehen, denn eine Datei, die man öffnen kann, sieht aus wie eine, die jemand geprüft hat. Ein Markdown-Ordner gibt dir eine sehr gute Ansicht. Ob er auch eine solide Aufzeichnung darüber führt, wie sich die Dinge geändert haben, ist eine andere Frage.

Was löst ein Markdown-Gedächtnis für Agenten tatsächlich?

Den fünften Fehler auf Liaos Liste löst Markdown.

The store is unauditable.

Ein Vektorspeicher ist nicht buchstäblich versiegelt; die meisten halten den Originaltext neben jedem Embedding vor und lassen dich Datensätze auflisten und löschen. Aber niemand liest zehntausend Payloads über einen Datenbank-Client, und einen Ordner mit Markdown kannst du an einem Sonntagnachmittag durchlesen, von Hand korrigieren und committen. Dieser Unterschied wiegt mehr, als es klingt. Ein Eintrag, den niemand liest, ist ein Eintrag, den niemand korrigiert, und ein Gedächtnis, das niemand korrigiert, wächst nur.

Man sollte sich aber ansehen, welche Art von Lösung das ist. Prüfbarkeit ist etwas, das der Speicher einem Leser anbietet. Sie bewirkt nichts, bis jemand liest, und der Leser, von dem sie ausgeht, ist ein Mensch mit eingeplanter Zeit. Operators eigener Workflow-Leitfaden geht mit dieser Lücke offen um: Agenten bevorzugen den Status quo, heißt es dort, und zögern, Dokumente zusammenzuführen, ein zu groß gewordenes aufzuteilen oder ein veraltetes zu kürzen, also brauchen diese Schritte dein Urteil. Das Format macht die Prüfung möglich. Machen musst du sie trotzdem selbst.

Warum ist die Gedächtnis-Landkarte immer noch eine Retrieval-Schicht?

Den vierten Fehler muss der Essay am dringendsten mit Dokumentation lösen.

Agents can’t search for what they don’t know.

Beide Systeme beantworten ihn gleich, mit einer Landkarte. Claude Code lädt zu Beginn einer Sitzung die ersten 200 Zeilen oder 25KB von MEMORY.md, je nachdem, was zuerst erreicht ist, und öffnet die Themendateien nur, wenn Claude entscheidet, dass es sie braucht. Operator legt seine Kataloge und den Hauptindex in jede Sitzung und gibt jedem Unterindex eine read_if-Bedingung, einen Satz, der sagt, wann sich das Öffnen lohnt. Das schlägt Top-k-Ähnlichkeit, und zwar deutlich. Der Agent sieht, was es gibt, bevor er eine Anfrage formuliert, und die Routing-Regeln sind Sätze, die du lesen und korrigieren kannst.

Es bleibt trotzdem Retrieval. Welche Seite der Agent öffnet, entscheidet er danach, wie gut eine einzeilige Beschreibung zur Aufgabe vor ihm passt, und dieses Urteil fällt das Modell statt der Kosinus-Distanz. Das Problem der unbekannten Unbekannten übersteht den Umzug in engerer Form: Wenn die Beschreibung für die Aufgabe, so wie der Agent sie liest, nicht relevant aussieht, bleibt die Seite zu, und nichts hält fest, dass sie zu blieb. Die Landkarte hat auch eine Größe. Jenseits der 200 Zeilen von Claude Code wird ein Eintrag beim Start nicht mehr angekündigt, und von da an findet einen Fakt nur ein Agent, der schon von sich aus auf die Idee kam, danach zu suchen.

Ist veraltetes Agenten-Gedächtnis ein Format- oder ein Zeitproblem?

Den dritten Fehler kann das Format datieren, aber nicht heilen.

The past is treated as truth.

Eine Markdown-Seite, die sagt, der Auth-Dienst nutze ein bestimmtes Token-Format, ist am Morgen nach der Formatänderung genauso veraltet wie ein eingebetteter Schnipsel mit derselben Aussage. Lesbarkeit macht einen Satz nicht aktuell. Liaos Antwort ist der Aktualisierungsschritt: Der Agent überarbeitet, was veraltet ist, solange das ganze Bild noch in seinem Kontext liegt. Das funktioniert für alles, was eine Sitzung berührt hat. Für einen Fakt, der sich geändert hat, ohne dass eine Sitzung dabei war, etwa durch den Commit eines Kollegen oder eine Entscheidung aus einem Meeting, garantiert es nichts: Eine spätere Sitzung kann die Seite nur reparieren, wenn irgendetwas sie dorthin schickt. Operators Architektur sagt das ganz offen, und sein Workflow bittet dich, den Index nach einem großen Pull auffrischen zu lassen. Das Brain kann nach einem git pull trotzdem veralten, und die Antwort des Designs lautet, dass die veraltete Seite wenigstens eine gewöhnliche, prüfbare Datei ist. Ich halte das für die richtige Antwort und für eine unvollständige. Eine Seite, die man hätte prüfen können, und eine Seite, die jemand geprüft hat, sind verschiedene Zustände, und der Ordner sieht in beiden gleich aus.

Datumsangaben helfen, und sie reichen weniger weit, als es scheint. Seit v2.1.214 schreibt Claude Code einen modified-Zeitstempel in das Frontmatter einer Memory-Datei, jedes Mal, wenn Claude eine Datei mit Frontmatter schreibt. Das sagt, wann sich die Datei zuletzt geändert hat, nicht, wann irgendein Satz darin zuletzt wahr war. agent-recall geht auf der Seite der Aufzeichnung einen Schritt weiter. Ändert sich der Wert eines Fakts, wird der alte nicht überschrieben: Er wird mit dem Zeitpunkt seiner Ablösung geschlossen und aufbewahrt, mit einem optionalen Label für seine Quelle, sodass du fragen kannst, was der Speicher an einem beliebigen Tag über diesen Fakt glaubte. Das gilt für diese Schlüssel-Wert-Fakten, nicht für alles im Speicher. Ich habe es so gebaut, weil ich wissen musste, was wann wahr war, nicht nur, was jetzt wahr ist. Die ehrliche Grenze ist dieselbe wie beim Zeitstempel. Beide Uhren halten fest, wann der Speicher etwas erfahren hat, nicht, wann sich die Welt geändert hat. Eine Uhr am Schreibvorgang ist trotzdem viel wert, denn sie macht aus einem unsichtbaren veralteten Fakt einen datierbaren.

Der leisere Preis eines Dokuments ist das Überschreiben. Einen Satz zu bearbeiten, ist bei einer lesbaren Seite das Naheliegende, und auf einer Seite ohne Versionskontrolle entfernt es genau die Belege, die eine Prüfung bräuchte. Operators geteilter Bereich liegt in Git, seine Historie bleibt also erhalten. Sein privater Bereich wird absichtlich dem globalen Git-Ignore hinzugefügt. Ob ein Dokument-Gedächtnis seine Vergangenheit behält, hängt davon ab, wo jede Seite gerade liegt. Das ist eine Speicher-Policy, und das Format legt sie nicht für dich fest.

Wer darf eine Gedächtnis-Seite eines Agenten ändern?

Das Problem, das ich ergänzen würde, steht gar nicht auf Liaos Liste, weil es erst auftaucht, wenn mehr als ein Agent schreibt. agent-recall prüft beim Schreiben den Scope, weil zwei Agenten einmal widersprüchliche Daten in dieselbe Entität geschrieben haben. Diese Prüfung ist enger, als sie klingt: Sie hindert einen Agenten daran, außerhalb seines Scopes zu schreiben, aber zwei Agenten, die beide denselben Fakt setzen dürfen, liefern sich weiterhin ein Rennen. Der spätere Schreibvorgang gewinnt, der frühere Wert bleibt in der Historie. Freitext-Notizen sind nicht einmal so streng: Zwei widersprüchliche stehen einfach nebeneinander. Ein geteilter Markdown-Ordner hat dasselbe Problem in leiserer Form. Der Konflikt besteht dann aus zwei Absätzen in einer Datei, die sich widersprechen, oder aus einer Bearbeitung, die eine andere still ersetzt. Operator regelt, welcher Anweisungsbereich welchen überstimmt. Welcher Agent welche Seite umschreiben darf, regelt nichts.

Dann ist da noch die Frage, wer der Schreiber ist. Der Aktualisierungsschritt bedeutet, dass der Agent einen Bericht über seine eigene Arbeit schreibt, der in einem späteren Fenster mit dem Rang von etwas zurückkommt, das du geschrieben hast, und dazu habe ich schon ausführlich argumentiert. Ein lesbares Gedächtnis macht den Bericht leicht überprüfbar. Es ändert nicht, wer ihn geschrieben hat.

Warum steckt das Lesen ins Gedächtnis in der Harness, während das Schreiben nur ein Satz im Prompt ist?

Liao betont deutlich, was Operator weglässt: keine Summarizer, keine Kuratoren, keine nächtlichen Umschreiber, kein Hintergrundprozess, der Tokens verbrennt. agent-recall hat so etwas, ein Sprachmodell, das aus dem Speicher ein Briefing schreibt, und das gibt es, weil Agenten mit einem rohen Dump aus Hunderten Einträgen nichts anfangen konnten. Ein Ordner mit Dokumenten umgeht das größtenteils, weil er selektiv lädt, aber die einzelnen Seiten und die Landkarten wachsen trotzdem, und eine Seite, die zu lang ist, um sie ganz zu lesen, hat dasselbe Problem im Kleinen. Irgendjemand hält sie kurz. Das kannst du von Hand machen, der Agent kann es beim Aktualisieren tun, oder ein Summarizer erledigt es beim Lesen. Operator legt die Arbeit auf den Agenten und deine Anleitung, was eine faire Entscheidung ist, und die Tokens werden trotzdem ausgegeben, nur innerhalb der Sitzung statt über Nacht.

Wenn es darum geht, das Gedächtnis ins Fenster zu bringen, sind sich beide Designs einig, und ich halte beide für richtig. Operator injiziert seine Orientierung in seiner OpenCode-Integration in jeden Modellaufruf. agent-recall liefert sein Briefing über einen SessionStart-Hook in Claude Code. In beiden Fällen passiert das Laden, ohne das Modell zu fragen, und das ist wichtig, denn ein Prompt ist keine Invariante. Das Schreiben funktioniert in keinem von beiden so. Der Server von agent-recall enthält Anweisungen, die den Agenten auffordern, Wichtiges unterwegs zu speichern, und diese Anweisungen gibt es, weil Agenten die Memory-Tools ignorierten, bis man es ihnen sagte. Etwas gesagt zu bekommen, bleibt trotzdem nur eine Empfehlung. Operators Aktualisierungsschritt ist ebenfalls eine Anweisung. Die Leseseite ist in die Harness gewandert, die Schreibseite ist immer noch eine Bitte, und auf der Schreibseite ruht das ganze Design.

Wie sollte Agenten-Gedächtnis aussehen: eine Aufzeichnung mit Uhr und eine Seite obendrauf?

Die Linie, die ich ziehen würde, verläuft also nicht zwischen Gedächtnis und Dokumentation. Sie verläuft zwischen dem, was du liest, und dem, was dessen Historie aufbewahrt. Die Aufzeichnung braucht das, worauf die Liste des Essays eigentlich zeigte: Werte, die ihre Vergangenheit behalten, statt überschrieben zu werden, eine Regel, wer was ändern darf, einen Weg ins Fenster, den die Harness erzwingt, und ein Signal von außerhalb der Sitzungen, wenn sich die Welt bewegt. Versioniertes Markdown kann diese Aufzeichnung sein, wenn jede Seite unter Versionskontrolle liegt und jemand für den Auslöser verantwortlich ist, der sie mit der Welt abgleicht. Eine Datenbank mit einer Markdown-Ansicht obendrauf ist ein anderer Weg dorthin. Der Exporter von agent-recall schreibt die aktuellen Faktwerte in schlichte Dateien und lässt ihre Änderungshistorie in der Datenbank, und genau diese Aufteilung meine ich. Was nicht funktioniert, ist die lesbare Seite als Ersatz für all das, unversioniert und nur gepflegt, wenn zufällig eine Sitzung vorbeikommt. So ein Aufbau erbt jedes Überschreiben, jede ungeöffnete Seite und jeden selbstsicheren veralteten Satz, den der Essay den Vektoren angelastet hat.

Ein lesbares Gedächtnis ist eine echte Verbesserung. Es bleibt ein Gedächtnis, mit allen Problemen, die ein Gedächtnis hat.