Ist die RAG überholt, jetzt, wo Langzeitagenten wie Claude Cowork auftauchen?

Claude Cowork ist eine neue Agentenfunktion in der Claude Desktop App. Aus der Sicht eines Entwicklers ist es im Grunde ein automatisierter Task-Runner, der das Modell umgibt: Es kann lokale Dateien lesen, ändern und erzeugen und es kann mehrstufige Aufgaben planen, ohne dass Sie manuell nach jedem Schritt fragen müssen. Stellen Sie sich dieselbe Schleife hinter Claude Code vor, nur eben auf dem Desktop und nicht auf dem Terminal.

Die wichtigste Fähigkeit von Cowork ist seine Fähigkeit, über längere Zeiträume zu laufen, ohne den Status zu verlieren. Es stößt nicht an die übliche Zeitüberschreitung der Konversation oder das Zurücksetzen des Kontexts. Es kann weiterarbeiten, Zwischenergebnisse verfolgen und frühere Informationen sitzungsübergreifend wiederverwenden. Das erweckt den Eindruck eines "Langzeitgedächtnisses", auch wenn die zugrunde liegende Mechanik eher ein dauerhafter Aufgabenstatus und eine kontextuelle Übertragung ist. In jedem Fall unterscheidet sich die Erfahrung von dem traditionellen Chat-Modell, bei dem alles zurückgesetzt wird, es sei denn, Sie bauen eine eigene Speicherschicht auf.

Dies wirft zwei praktische Fragen für Entwickler auf:

1. Wenn sich das Modell bereits an vergangene Informationen erinnern kann, wo passt dann noch RAG oder agentisches RAG hinein? Wird RAG ersetzt werden?

2. Wenn wir einen lokalen Agenten im Cowork-Stil wollen, wie implementieren wir dann selbst ein Langzeitgedächtnis?

Der Rest dieses Artikels geht auf diese Fragen im Detail ein und erklärt, wie Vektordatenbanken in diese neue "Modellgedächtnis"-Landschaft passen.

Claude Cowork vs. RAG: Was ist der Unterschied?

Wie ich bereits erwähnt habe, ist Claude Cowork ein Agentenmodus innerhalb von Claude Desktop, der lokale Dateien lesen und schreiben, Aufgaben in kleinere Schritte aufteilen und ohne Statusverlust weiterarbeiten kann. Er behält seinen eigenen Arbeitskontext bei, so dass mehrstündige Aufgaben nicht wie eine normale Chatsitzung zurückgesetzt werden.

RAG (Retrieval-Augmented Generation) löst ein anderes Problem: Es gibt einem Modell Zugang zu externem Wissen. Man indiziert seine Daten in einer Vektordatenbank, ruft für jede Abfrage relevante Teile ab und speist sie in das Modell ein. Diese Methode ist weit verbreitet, da sie LLM-Anwendungen eine Art "Langzeitgedächtnis" für Dokumente, Protokolle, Produktdaten und mehr bietet.

Wenn beide Systeme einem Modell helfen, sich zu "erinnern", was ist dann der eigentliche Unterschied?

Wie Cowork mit dem Speicher umgeht

Der Speicher von Cowork ist ein Schreib-Lese-Speicher. Der Agent entscheidet, welche Informationen aus der aktuellen Aufgabe oder Konversation relevant sind, speichert sie als Speichereinträge und ruft sie später ab, wenn die Aufgabe fortschreitet. Dadurch kann Cowork die Kontinuität über lange laufende Arbeitsabläufe hinweg aufrechterhalten - insbesondere bei solchen, die im Verlauf neue Zwischenzustände erzeugen.

Wie RAG und Agentic RAG mit dem Speicher umgehen

Standard-RAG ist ein abfragegesteuertes Retrieval: Der Benutzer stellt eine Frage, das System holt relevante Dokumente und das Modell verwendet diese, um zu antworten. Der Abfragekorpus bleibt stabil und versioniert, und die Entwickler kontrollieren genau, was in den Korpus eingeht.

Modernes agentenbasiertes RAG erweitert dieses Muster. Das Modell kann entscheiden, wann es Informationen abruft, was es abruft und wie es diese während der Planung oder Ausführung eines Arbeitsablaufs verwendet. Diese Systeme können lange Aufgaben ausführen und Werkzeuge aufrufen, ähnlich wie Cowork. Aber auch bei der agentenbasierten RAG bleibt die Abfrageschicht eher wissens- als zustandsorientiert. Der Agent ruft maßgebliche Fakten ab; er schreibt seinen sich entwickelnden Aufgabenzustand nicht in den Korpus zurück.

Man kann es auch anders sehen:

• Das Gedächtnis von Cowork ist aufgabenorientiert: der Agent schreibt und liest seinen eigenen sich entwickelnden Zustand.

• RAG ist wissensgesteuert: Das System ruft etablierte Informationen ab, auf die sich das Modell stützen sollte.

Reverse-Engineering Claude Cowork: Wie es ein langlaufendes Agentengedächtnis aufbaut

Cowork wird viel gepriesen, weil es mehrstufige Aufgaben bewältigt, ohne ständig zu vergessen, was es gerade getan hat. Aus der Sicht eines Entwicklers frage ich mich, wie er den Status über so lange Sitzungen hinweg beibehält? Anthropic hat die Interna nicht veröffentlicht, aber auf der Grundlage früherer Entwicklungsexperimente mit dem Speichermodul von Claude können wir ein vernünftiges mentales Modell zusammensetzen.

Claude scheint sich auf einen hybriden Aufbau zu stützen: eine persistente Langzeitspeicherschicht und Tools zum Abrufen auf Abruf. Anstatt die gesamte Konversation in jede Anfrage zu packen, greift Claude nur dann selektiv auf vergangenen Kontext zurück, wenn es ihn für relevant hält. Auf diese Weise kann das Modell die Genauigkeit hoch halten, ohne jedes Mal die Token zu verbrauchen.

Wenn Sie die Struktur der Anfrage aufschlüsseln, sieht sie ungefähr so aus:

[0] Static system instructions
[1] User memory (long-term)
[2] Retrieved / pruned conversation history
[3] Current user message

Interessant ist nicht die Struktur selbst, sondern die Art und Weise, wie das Modell entscheidet, was zu aktualisieren ist und wann eine Abfrage durchgeführt werden soll.

Benutzer-Speicher: Die persistente Schicht

Claude verfügt über einen Langzeitspeicher, der mit der Zeit aktualisiert wird. Und im Gegensatz zum eher vorhersehbaren Speichersystem von ChatGPT fühlt sich Claude etwas "lebendiger" an. Es speichert Erinnerungen in XML-ähnlichen Blöcken und aktualisiert sie auf zwei Arten:

• Implizite Aktualisierungen: Manchmal entscheidet das Modell einfach, dass etwas eine stabile Präferenz oder Tatsache ist und schreibt es stillschweigend in den Speicher. Diese Aktualisierungen erfolgen nicht sofort, sondern erst nach ein paar Runden, und ältere Erinnerungen können verblassen, wenn die zugehörige Unterhaltung verschwindet.

• Explizite Aktualisierungen: Mit dem Werkzeug memory_user_edits können die Benutzer den Speicher direkt verändern ("X merken", "Y vergessen"). Diese Schreibvorgänge erfolgen sofort und verhalten sich eher wie eine CRUD-Operation.

Claude führt im Hintergrund Heuristiken aus, um zu entscheiden, was gespeichert werden soll, und wartet nicht auf explizite Anweisungen.

Abruf von Gesprächen: Der On-Demand-Teil

Claude führt keine fortlaufende Zusammenfassung wie viele LLM-Systeme. Stattdessen verfügt es über eine Reihe von Abfragefunktionen, die es immer dann aufrufen kann, wenn es meint, dass ihm ein Kontext fehlt. Diese Abrufe erfolgen nicht bei jedem Zug - das Modell löst sie auf der Grundlage seiner eigenen internen Beurteilung aus.

Das herausragende Beispiel ist conversation_search. Wenn der Benutzer etwas Vages wie "das Projekt vom letzten Monat" sagt, ruft Claude oft dieses Tool auf, um relevante Züge auszugraben. Bemerkenswert ist, dass es auch dann funktioniert, wenn die Formulierung zweideutig oder in einer anderen Sprache ist. Das deutet ziemlich klar darauf hin:

• Eine Art semantischer Abgleich (Einbettung)

• Wahrscheinlich kombiniert mit Normalisierung oder leichter Übersetzung

• Schlüsselwortsuche für mehr Präzision

Im Grunde sieht dies sehr nach einem Miniatur-RAG-System aus, das in das Toolset des Modells integriert ist.

Wie sich das Abrufverhalten von Claude von einfachen Verlaufspuffern unterscheidet

Aus den Tests und Protokollen gehen einige Muster hervor:

• Der Abruf erfolgt nicht automatisch. Das Modell entscheidet selbst, wann es ihn aufruft. Wenn es der Meinung ist, dass es bereits über genügend Kontext verfügt, macht es sich gar nicht erst die Mühe.

• Die abgerufenen Chunks enthalten sowohl Benutzer- als auch Assistentennachrichten. Das ist nützlich - es bleiben mehr Nuancen erhalten als bei reinen Benutzerzusammenfassungen.

• Die Verwendung von Token bleibt überschaubar. Da der Verlauf nicht jedes Mal neu eingegeben wird, werden lange Sitzungen nicht unvorhersehbar aufgebläht.

Alles in allem fühlt es sich an wie ein LLM mit Abfrageerweiterung, nur dass die Abfrage als Teil der eigenen Argumentationsschleife des Modells erfolgt.

Diese Architektur ist clever, aber nicht kostenlos:

• Die Abfrage bringt zusätzliche Latenzzeiten und mehr "bewegliche Teile" mit sich (Indizierung, Einstufung, Neueinstufung).

• Das Modell schätzt gelegentlich falsch ein, ob es Kontext benötigt, was bedeutet, dass Sie die klassische "LLM-Vergesslichkeit" erleben, obwohl die Daten verfügbar waren.

• Die Fehlersuche wird schwieriger, weil das Verhalten des Modells von unsichtbaren Werkzeugauslösern abhängt, nicht nur von Eingaben.

Claude Cowork vs. Claude Codex im Umgang mit dem Langzeitgedächtnis

Im Gegensatz zu Claudes abruflastigem Aufbau geht ChatGPT viel strukturierter und vorhersehbarer mit dem Speicher um. Anstatt semantische Lookups durchzuführen oder alte Konversationen wie einen Mini-Vektorspeicher zu behandeln, injiziert ChatGPT Speicher direkt in jede Sitzung durch die folgenden Komponenten:

• Benutzer-Speicher

• Sitzungs-Metadaten

• Aktuelle Sitzungsnachrichten

Benutzer-Speicher

Der Benutzerspeicher ist die wichtigste langfristige Speicherschicht - der Teil, der über Sitzungen hinweg bestehen bleibt und vom Benutzer bearbeitet werden kann. Er speichert ziemlich standardmäßige Dinge: Name, Hintergrund, laufende Projekte, Lernpräferenzen und dergleichen. Jede neue Konversation bekommt diesen Block zu Beginn injiziert, so dass das Modell immer mit einer konsistenten Ansicht des Benutzers beginnt.

ChatGPT aktualisiert diese Schicht auf zwei Arten:

• Explizite Aktualisierungen: Benutzer können dem Modell sagen, dass es sich dies merken" oder das vergessen" soll, und der Speicher ändert sich sofort. Dies ist im Grunde eine CRUD-API, die das Modell durch natürliche Sprache offenlegt.

• Implizite Aktualisierungen: Wenn das Modell Informationen findet, die den OpenAI-Regeln für das Langzeitgedächtnis entsprechen, wie z. B. eine Berufsbezeichnung oder eine Vorliebe, und der Benutzer den Speicher nicht deaktiviert hat, fügt es diese von selbst hinzu.

Aus der Sicht des Entwicklers ist diese Schicht einfach, deterministisch und leicht zu durchschauen. Kein Einbetten von Suchvorgängen, keine Heuristik darüber, was zu holen ist.

Sitzungs-Metadaten

Sitzungsmetadaten befinden sich am anderen Ende des Spektrums. Sie sind kurzlebig, nicht persistent und werden nur einmal zu Beginn einer Sitzung eingefügt. Man kann sie sich als Umgebungsvariablen für die Konversation vorstellen. Dazu gehören Dinge wie:

• das Gerät, auf dem Sie sich befinden

• Konto-/Abonnementstatus

• grobe Nutzungsmuster (aktive Tage, Modellverteilung, durchschnittliche Gesprächslänge)

Mithilfe dieser Metadaten kann das Modell die Antworten an die aktuelle Umgebung anpassen, z. B. kürzere Antworten auf dem Handy schreiben, ohne den Langzeitspeicher zu belasten.

Aktuelle Sitzungsnachrichten

Dies ist der Standardverlauf mit gleitendem Fenster: alle Nachrichten in der aktuellen Konversation, bis das Token-Limit erreicht ist. Wenn das Fenster zu groß wird, werden ältere Nachrichten automatisch gelöscht.

Entscheidend ist, dass dieser Vorgang weder den Benutzerspeicher noch sitzungsübergreifende Zusammenfassungen betrifft. Nur der lokale Gesprächsverlauf schrumpft.

Die größte Abweichung von Claude besteht darin, wie ChatGPT mit "kürzlich geführten, aber nicht aktuellen" Unterhaltungen umgeht. Claude ruft ein Suchwerkzeug auf, um vergangenen Kontext abzurufen, wenn es ihn für relevant hält. ChatGPT macht das nicht.

Stattdessen speichert ChatGPT eine sehr leichtgewichtige , sitzungsübergreifende Zusammenfassung, die in jede Unterhaltung eingefügt wird. Ein paar wichtige Details zu dieser Schicht:

• Sie fasst nur Benutzernachrichten zusammen, nicht die Nachrichten von Assistenten.

• Sie speichert eine sehr kleine Menge von Elementen - ungefähr 15 - gerade genug, um stabile Themen oder Interessen zu erfassen.

• Sie führt keine Einbettungsberechnungen, keine Ähnlichkeitsbewertung und keine Abrufe durch. Es handelt sich im Grunde um vorgekauten Kontext, nicht um dynamisches Nachschlagen.

Aus technischer Sicht wird bei diesem Ansatz Flexibilität gegen Vorhersagbarkeit getauscht. Es gibt kein Risiko eines seltsamen Abruffehlers, und die Latenzzeit für die Inferenz bleibt stabil, da nichts spontan abgerufen wird. Der Nachteil ist, dass ChatGPT keine zufällige Nachricht von vor sechs Monaten abruft, wenn sie es nicht in die Zusammenfassungsschicht geschafft hat.

Herausforderungen bei der Beschreibbarkeit des Agentenspeichers

Wenn ein Agent von einem Nur-Lese-Speicher (typisch RAG) zu einem beschreibbaren Speicherwechselt , in demer Benutzeraktionen, Entscheidungen und Einstellungen protokollieren kann, steigt die Komplexität schnell an. Es geht nicht mehr nur um das Abrufen von Dokumenten, sondern um die Aufrechterhaltung eines wachsenden Zustands, von dem das Modell abhängt.

Ein System mit beschreibbarem Speicher muss drei echte Probleme lösen:

1. Was soll gespeichert werden: Der Agent braucht Regeln, um zu entscheiden, welche Ereignisse, Präferenzen oder Beobachtungen es wert sind, gespeichert zu werden. Ohne dies explodiert der Speicher entweder in seiner Größe oder füllt sich mit Rauschen.

2. Wie wird der Speicher gespeichert und geordnet: Nicht alle Erinnerungen sind gleich. Aktuelle Elemente, langfristige Fakten und flüchtige Notizen benötigen unterschiedliche Speicherebenen, Aufbewahrungsrichtlinien und Indizierungsstrategien.

3. Wie man schnell schreibt, ohne den Abruf zu beeinträchtigen: Der Speicher muss kontinuierlich beschrieben werden, aber häufige Aktualisierungen können die Qualität des Index beeinträchtigen oder Abfragen verlangsamen, wenn das System nicht für einen hohen Durchsatz an Einfügungen ausgelegt ist.

Herausforderung 1: Was ist es wert, gespeichert zu werden?

Nicht alles, was ein Benutzer tut, sollte im Langzeitspeicher landen. Wenn jemand eine temporäre Datei anlegt und sie fünf Minuten später wieder löscht, nützt es niemandem, dies für immer zu speichern. Hier liegt das Kernproblem: Wie entscheidet das System, was wirklich wichtig ist?

(1) Übliche Methoden zur Beurteilung der Wichtigkeit

Teams verlassen sich in der Regel auf eine Mischung von Heuristiken:

• Zeitbasiert: neuere Aktionen sind wichtiger als ältere

• Frequenzbasiert: Dateien oder Aktionen, auf die wiederholt zugegriffen wird, sind wichtiger

• Typbasiert: Einige Objekte sind von Natur aus wichtiger (z. B. Projektkonfigurationsdateien gegenüber Cache-Dateien)

(2) Wenn Regeln kollidieren

Diese Signale widersprechen sich oft. Eine Datei, die letzte Woche erstellt, aber heute stark bearbeitet wurde - sollte das Alter oder die Aktivität den Ausschlag geben? Es gibt keine einzige "richtige" Antwort, weshalb die Bewertung der Wichtigkeit schnell unübersichtlich werden kann.

(3) Wie Vektordatenbanken helfen

Vektordatenbanken bieten Ihnen Mechanismen zur Durchsetzung von Wichtigkeitsregeln ohne manuelle Bereinigung:

• TTL: Milvus kann Daten nach einer bestimmten Zeit automatisch entfernen

• Verfall: Ältere Vektoren können herabgewichtet werden, so dass sie auf natürliche Weise aus dem Abruf verschwinden.

Herausforderung 2: Speicher-Tiering in der Praxis

Wenn Agenten länger laufen, stapelt sich der Speicher. Es ist nicht nachhaltig, alles im schnellen Speicher zu halten, also braucht das System eine Möglichkeit, den Speicher in heiße (häufige Zugriffe) und kalte (seltene Zugriffe) Ebenen aufzuteilen.

(1) Entscheiden, wann der Speicher kalt wird

In diesem Modell bezieht sich "heißer" Speicher auf Daten, die für einen Zugriff mit geringer Latenz im RAM gehalten werden, während "kalter" Speicher sich auf Daten bezieht, die zur Kostenreduzierung auf die Festplatte oder den Objektspeicher verschoben werden.

Die Entscheidung, wann der Speicher kalt wird, kann auf unterschiedliche Weise getroffen werden. Einige Systeme verwenden leichtgewichtige Modelle, um die semantische Bedeutung einer Aktion oder Datei auf der Grundlage ihrer Bedeutung und jüngsten Verwendung zu schätzen. Andere verlassen sich auf eine einfache, regelbasierte Logik, wie z. B. das Verschieben von Speicher, auf den seit 30 Tagen nicht mehr zugegriffen wurde oder der seit einer Woche nicht mehr in den Abfrageergebnissen auftaucht. Die Benutzer können auch bestimmte Dateien oder Aktionen explizit als wichtig markieren, um sicherzustellen, dass sie immer heiß bleiben.

(2) Wo werden heißer und kalter Speicher gespeichert?

Einmal klassifiziert, werden heißer und kalter Speicher unterschiedlich gespeichert. Der heiße Speicher verbleibt im Arbeitsspeicher und wird für Inhalte verwendet, auf die häufig zugegriffen wird, wie z. B. den aktiven Aufgabenkontext oder die letzten Benutzeraktionen. Der kalte Speicher wird auf die Festplatte oder in Objektspeichersysteme wie S3 verlagert, wo der Zugriff zwar langsamer ist, aber die Speicherkosten viel niedriger sind. Dieser Kompromiss funktioniert gut, da der kalte Speicher nur selten benötigt wird und der Zugriff in der Regel nur für langfristige Referenzen erfolgt.

(3) Wie Vektordatenbanken helfen

Milvus und Zilliz Cloud unterstützen dieses Muster, indem sie Hot-Cold-Tiered-Storage ermöglichen und dabei eine einzige Abfrageoberfläche beibehalten, so dass Vektoren, auf die häufig zugegriffen wird, im Speicher verbleiben und ältere Daten automatisch in kostengünstigeren Speicher verschoben werden.

Herausforderung 3: Wie schnell sollte der Speicher beschrieben werden?

Herkömmliche RAG-Systeme schreiben Daten normalerweise in Stapeln. Indizes werden offline - oft über Nacht - neu aufgebaut und sind erst später durchsuchbar. Dieser Ansatz funktioniert für statische Wissensdatenbanken, ist aber für den Agentenspeicher nicht geeignet.

(1) Warum der Agentenspeicher Echtzeit-Schreibvorgänge benötigt

Der Agentenspeicher muss Benutzeraktionen erfassen, sobald sie geschehen. Wenn eine Aktion nicht sofort aufgezeichnet wird, kann es sein, dass bei der nächsten Konversationsrunde der entscheidende Kontext fehlt. Aus diesem Grund benötigen beschreibbare Speichersysteme Echtzeit-Schreibvorgänge und keine verzögerten Offline-Aktualisierungen.

(2) Das Spannungsverhältnis zwischen Schreibgeschwindigkeit und Abrufqualität

Echtzeitspeicher erfordern eine sehr geringe Schreiblatenz. Gleichzeitig hängt die Qualität des Abrufs von gut aufgebauten Indizes ab, und der Aufbau von Indizes braucht Zeit. Der Neuaufbau eines Index bei jedem Schreibvorgang ist zu teuer, aber eine Verzögerung der Indexierung bedeutet, dass neu geschriebene Daten für den Abruf vorübergehend unsichtbar bleiben. Dieser Kompromiss steht im Mittelpunkt des Designs von beschreibbarem Speicher.

(3) Wie Vektordatenbanken helfen

Vektordatenbanken lösen dieses Problem, indem sie das Schreiben von der Indizierung entkoppeln. Eine gängige Lösung besteht darin, Schreibvorgänge zu streamen und einen inkrementellen Indexaufbau durchzuführen. Am Beispiel von Milvus werden neue Daten zunächst in einen speicherinternen Puffer geschrieben, so dass das System hochfrequente Schreibvorgänge effizient verarbeiten kann. Noch bevor ein vollständiger Index erstellt ist, können gepufferte Daten innerhalb von Sekunden durch dynamische Zusammenführung oder ungefähre Suche abgefragt werden.

Wenn der Puffer einen vordefinierten Schwellenwert erreicht, baut das System Indizes in Stapeln auf und speichert sie. Dadurch wird die langfristige Abrufleistung verbessert, ohne dass Echtzeit-Schreibvorgänge blockiert werden. Durch die Trennung von schneller Ingestion und langsamer Indexerstellung erreicht Milvus ein praktisches Gleichgewicht zwischen Schreibgeschwindigkeit und Suchqualität, das für den Agentenspeicher gut geeignet ist.

Fazit

Cowork gibt uns einen Einblick in eine neue Klasse von Agenten - persistent, zustandsorientiert und in der Lage, Kontext über lange Zeiträume hinweg zu speichern. Aber es macht auch etwas anderes deutlich: Das Langzeitgedächtnis ist nur die Hälfte des Bildes. Um produktionsreife Agenten zu entwickeln, die sowohl autonom als auch zuverlässig sind, brauchen wir immer noch eine strukturierte Suche in großen, sich entwickelnden Wissensdatenbanken.

RAG verwaltet die Fakten der Welt; beschreibbarer Speicher verwaltet den internen Zustand des Agenten. Vektordatenbanken sitzen an der Schnittstelle und bieten Indizierung, hybride Suche und skalierbaren Speicher, so dass beide Ebenen zusammenarbeiten können.

Mit der weiteren Reifung von Langzeitagenten werden sich ihre Architekturen wahrscheinlich diesem hybriden Design annähern. Cowork ist ein deutliches Signal dafür, wohin sich die Dinge entwickeln - nicht in Richtung einer Welt ohne RAG, sondern in Richtung von Agenten mit reichhaltigeren Speicherstapeln, die von darunter liegenden Vektordatenbanken unterstützt werden.

Wenn Sie diese Ideen erforschen oder Hilfe bei Ihrer eigenen Einrichtung erhalten möchten, treten Sie unserem Slack-Kanal bei, um mit Milvus-Ingenieuren zu chatten. Und wenn Sie mehr praktische Hilfe benötigen, können Sie jederzeit eine Milvus-Sprechstunde buchen .