Operator Memory speichert das Wissen von Coding-Agenten als Markdown-Dateien im Projektordner statt als Textschnipsel in einer Vektordatenbank. Entwickler Kevin Liao hält Gedächtnis-Plugins für den falschen Ansatz, belastbare Messwerte für sein eigenes Werkzeug fehlen allerdings noch.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Mit Operator Memory will Kevin Liao Coding-Agenten eine Erkundung ersparen, die nach seiner Rechnung in jeder neuen Sitzung rund 80.000 Tokens kostet, weil die Absichten hinter einem Projekt nirgends aufgeschrieben stehen. Seinen Gegenentwurf begründet Liao im Essay „Agents Don’t Need Memory. They Need Documentation.“ vom 3. Oktober.[1]
Das Wichtigste in Kürze
- Operator Memory legt Spezifikationen, Entscheidungen und Recherchen als Markdown-Dateien ab und hält sie aktuell.
- Das Plugin ist kostenlos und steht unter der BSD-3-Clause-Lizenz.
- claude-mem und Mem0 setzen dagegen auf Vektorsuche über Gesprächsschnipsel.
- Kontextdateien verteuerten Agentenläufe in einer ETH-Studie um mehr als 20 Prozent.
Was macht Operator Memory anders als Gedächtnis-Plugins?
Operator Memory pflegt Dokumente statt eines Gesprächsprotokolls. Der Agent liest vor jeder Aufgabe einen Katalog der vorhandenen Dateien, öffnet die passenden und schreibt Änderungen danach in dieselbe Datei zurück, statt einen neuen Datenbankeintrag anzulegen.[2]
Das verbreitete Gedächtnis-Plugin claude-mem, ein Open-Source-Projekt mit rund 98.600 GitHub-Sternen, fasst Sitzungen per KI zusammen und holt die Zusammenfassungen über SQLite und die Vektordatenbank Chroma zurück.[3] Liao nennt dieses Prinzip eine Lotterie: Über die Ähnlichkeitssuche kämen passende Schnipsel in den Kontext, ohne Hinweis darauf, ob diese noch aktuell sind.[1]
Operator verteilt das Wissen auf drei Ordner: .operator/ bleibt privat auf dem Rechner, .operator-shared/ wandert mit dem Repository ins Git, und ~/.operator/user/ hält persönliche Regeln über alle Projekte hinweg.[2]
Installiert wird ein Hilfsprogramm per npm, danach ein Adapter je Umgebung. Als voll unterstützt führt das Projekt Claude Code, Codex, OpenCode, Pi und den DeepSeek-Harness, Kiro steht eine Stufe darunter. Das Repository entstand Mitte August und zählt knapp 400 Sterne.[2]
Helfen Kontextdateien Coding-Agenten überhaupt?
Nur eingeschränkt, zeigt eine Studie der ETH Zürich. Kontextdateien wie AGENTS.md verteuerten die Agentenläufe im Schnitt um mehr als 20 Prozent, ohne die Erfolgsquote generell zu verbessern.[4]
Die Forscher um Martin Vechev testeten vier Coding-Agenten. Von Sprachmodellen erzeugte Dateien brachten keinen messbaren Vorteil, von Entwicklern geschriebene halfen leicht. Allgemeine Projektübersichten halfen den Agenten nicht, Vorgaben zu unüblichen Arbeitsweisen dagegen schon.[4]
Liao schreibt seinem Agenten vor, nur festzuhalten, was nicht schon im Code steht.[1] Offen bleibt, ob die automatisch erzeugten Code-Indizes des Plugins denselben Kostenaufschlag verursachen, denn Liao legt keine Benchmarks vor. Gängige Gedächtnistests wie LoCoMo prüften nur das Abrufen von Chatverläufen, argumentiert der Entwickler.[5] Mem0 wirbt genau mit diesem Test und meldet dort 92,5 Punkte.[6]
So arbeiten die Werkzeuge
Was die ETH Zürich gemessen hat
Operator Memory macht Agentenwissen prüfbar wie Code, den Beweis für bessere Ergebnisse muss das Plugin aber noch liefern.
Michael Dobler, Herausgeber Dr. Web
Was bedeutet das für Agenturen und Entwicklerteams?
Teams mit Coding-Agenten legen Projektwissen am besten als Dateien im Repository ab, wo auch Menschen mitlesen. Wichtiger als die Wahl des Werkzeugs ist, veraltete Einträge zu löschen, statt neue anzuhängen.
Google beschreibt seit Juni mit dem Open Knowledge Format Wissen ebenfalls als Sammlung von Markdown-Dateien, und das Framework Blume baut Dokumentation gleich für Menschen und Agenten. Huaweis MindMemOS geht den Gegenweg und räumt sein Gedächtnis per „Dreaming“ offline auf, also mit genau jenen Hintergrundprozessen, die Liao für Token-Verschwendung hält.
Agenturen sollten den geteilten Ordner wie Quellcode behandeln. Jeder Push macht .operator-shared/ für alle sichtbar, die das Repository lesen dürfen, also auch für Freelancer und Kunden. Zugangsdaten und personenbezogene Details aus Projektgesprächen haben dort nichts verloren, weil sich solche Daten aus einer Git-Historie nur mit Aufwand entfernen lassen. Ein fester Termin zum Ausmisten hilft ebenfalls, denn Konfigurationsdateien für KI-Agenten wachsen unbemerkt.
Quellen
[1] Kevin Liao: „Agents Don’t Need Memory. They Need Documentation.“
[2] Aerovato: „Operator Memory“ auf GitHub
[3] claude-mem: „Persistent Context Across Sessions for Every Agent“ auf GitHub
[4] ETH Zürich, LogicStar.ai: „Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?“
[5] Kevin Liao: „Benchmarks? Evals?“, Antwort im Issue-Tracker von Operator Memory
[6] Mem0: „The Memory Layer for AI Agents“ auf GitHub
Mehr Newshunger?
- „Der Plan-Modus ist tot“: Warum Nuanced mit langen KI-Spezifikationen scheiterte
- Spielen Web-Frameworks im Zeitalter der Coding-Agenten noch eine Rolle?
- fglibs.com: Ein Katalog für UI-Effekte, den KI-Assistenten per MCP abfragen
- Selbstlernende KI-Agenten: EverMinds offener Stack aus China lernt aus jedem Fehler
- Behavior Specs: Ein offener Standard macht das Verhalten von KI-Agenten prüfbar
