Wie viel Speicher braucht Ihr Agent eigentlich?

Ein Jahr nachdem Tool-nutzende Agenten zum Standard geworden sind, um auf großen Sprachmodellen aufzubauen, wird eine Frage immer noch aus Gewohnheit statt durch Messung beantwortet: Wie viel Speicher sollte der Agent behalten? Viele Teams beginnen mit einer Einheitsentscheidung – „den gesamten Verlauf geben“ oder „alles in einem Vektorindex speichern“ – und entdecken die Kosten erst, wenn das Kontextfenster das Verhalten des Agenten zu diktieren beginnt. Speicher ist keine Ressource, die man spät im Projekt hinzufügt; es ist ein Budget, das man vom ersten Prompt an zuweist. Die praktische Frage ist nicht, ob Ihr Agent Speicher hat, sondern wie viel von jeder Art er benötigt und woher Sie das wissen.

Die Speicherpyramide: Warum Kapazität nicht einheitlich ist

Das Wort „Speicher“ verbirgt eine Pyramide verschiedener Aufbewahrungssysteme. Ganz unten liegt das rohe Transkript: jede Benutzernachricht, jeder Tool-Aufruf und jede Modellantwort seit dem Start des Agenten. Darüber liegt der Aufgabenstatus – die kleine Menge an Variablen, Zwischenplänen und Tool-Ausgaben, die definieren, was der Agent gerade tut. Noch höher liegen langfristige Fakten: Benutzerpräferenzen, Repository-Konventionen, API-Eigenheiten, die in früheren Sitzungen gelernt wurden. Schließlich gibt es noch das eigene Kontextfenster des Modells, das überhaupt kein Speicher ist, sondern ein kurzlebiges Arbeitsfeld, in dem alles andere um Platz konkurriert.

Diese Schichten verhalten sich unter Last unterschiedlich. Das Transkript wächst mit jedem Schritt linear und enthält oft Duplikate – jeder Wiederholungsversuch eines Tool-Aufrufs sendet die vorherige Fehlermeldung erneut. Der Aufgabenstatus wächst mit der Komplexität des aktuellen Ziels, schrumpft aber, wenn das Ziel abgeschlossen ist. Langfristige Fakten wachsen langsam und bleiben, einmal geschrieben, tendenziell relevant. Diese Schichten zu verwechseln, ist die häufigste Ursache für eine Überzuweisung von Speicher. Ein Team, das einen aufgeblähten Kontext sieht, nimmt normalerweise an, dass es einen größeren externen Speicher braucht, obwohl es in Wirklichkeit aufhören muss, alte Tool-Ausgaben erneut abzuspielen.

Der einzige ehrliche Weg herauszufinden, welche Schicht das Budget Ihres Agenten verbraucht, besteht darin, den Agenten zu instrumentieren, bevor man ihn optimiert. Das ist die Disziplin, die dieser Artikel durchgeht: eine minimale, abhängigkeitsarme Messumgebung, die Ihnen sagt, wohin Ihr Speicherbudget tatsächlich fließt.

Vier Lasten auf demselben Budget

Jedes Token im Kontextfenster Ihres Agenten gehört zu einer von vier Lasten. Den Unterschied zu verstehen, ist der Unterschied zwischen Raten und Ingenieursarbeit.

Gesprächslast ist das jüngste Hin und Her zwischen Benutzer und Agent. Es fühlt sich wesentlich an, aber der größte Teil ist es nicht. Sobald die Anfrage des Benutzers verstanden wurde, muss der genaue Wortlaut früherer Rückfragen selten wörtlich wiederholt werden.

Tool-Ausgabelast ist das serialisierte Ergebnis jeder Funktion, die der Agent aufgerufen hat. Dies ist der häufigste versteckte Aufbläher. JSON-Payloads von APIs sind ausführlich, verschachtelt und repetitiv. Ein einziger Tool-Aufruf, der 40 Datensätze zurückgibt, kann mehr Token verbrauchen als der Rest des Gesprächs zusammen, und der Agent ruft dasselbe Tool oft zweimal mit leicht unterschiedlichen Parametern auf.

Episodische Last ist die Erinnerung des Agenten daran, was er bereits versucht hat und wie das Ergebnis war. Ein Teil davon ist notwendig – man möchte nicht, dass der Agent einen fehlgeschlagenen Ansatz wiederholt. Der größte Teil lässt sich jedoch in einer einzigen Zeile zusammenfassen: „direkten SSH versucht, mit Berechtigungsfehler fehlgeschlagen, auf API umgestellt.“

Kontextuelle Last ist alles andere, was das Modell benötigt, um sich korrekt zu verhalten: das Systemprompt, Tool-Definitionen, Few-Shot-Beispiele und Formatierungsanweisungen. Diese Last ist konstant. Sie wächst nicht mit der Sitzung, reduziert aber den verfügbaren Platz für die anderen drei.

Wenn Praktiker fragen: „Wie viel Speicher braucht mein Agent?“, meinen sie normalerweise die Summe dieser Lasten. Die nützliche Antwort ist eine Aufschlüsselung, keine Gesamtsumme.

Was IBM Research' ALTK-Evolve uns sagt

Die Frage ist nicht nur ein Spielplatzproblem. Am 18. August 2026 veröffentlichte IBM Research einen Beitrag mit dem Titel „How Much Memory Does Your Agent Actually Need?“ im Hugging-Face-Blog, im Rahmen der ALTK-Evolve-Initiative. Schon der Titel ist bemerkenswert: Eine Industriewissenschaftsgruppe hat ausdrücklich gefragt, wie viel Speicher zählt, anstatt anzunehmen, dass mehr besser ist.

Ich werde den Blogbeitrag hier nicht Behauptung für Behauptung zusammenfassen, denn der Zweck dieses Artikels ist es, Ihnen ein praktisches Instrument zu geben, keine Zusammenfassung. Die relevante Erkenntnis, wie ich sie lese, ist, dass Speicheranforderungen nicht statisch sind. Ein Agent, der neue Werkzeuge freischaltet oder Zugang zu neuen Repositorys erhält, wird das Verhältnis von Tool-Ausgabelast zu Gesprächslast verändern. Eine Speicherkonfiguration, die zum Zeitpunkt der Bereitstellung großzügig ist, wird nach der Weiterentwicklung der Agenten-Werkzeuge verschwenderisch. Der Projektname „ALTK-Evolve“ deutet genau auf diese evolutionäre Sichtweise hin: Speicher sollte kontinuierlich abgestimmt werden, nicht einmalig festgelegt.

Wenn Sie die Speicherbemessung als Messproblem behandeln, können Sie jeden Agenten – unabhängig vom Framework – dazu bringen, seinen Speicherverbrauch mit Zahlen zu rechtfertigen. Wie das geht, zeigt der Rest dieses Artikels.

Anforderungen

Bevor Sie den Speicher Ihres Agenten messen können, benötigen Sie vier Dinge:

1. Zugriff auf den Anfragefluss des Agenten – Sie müssen in der Lage sein, jeden Austausch zwischen dem Agenten, seinen Werkzeugen und dem Modell zu protokollieren. In der Praxis bedeutet das einen kleinen Wrapper um Ihre bestehende Agentenschleife oder einen Protokollierungs-Hook, falls Ihr Framework einen bereitstellt.
2. Eine Möglichkeit, Token-Anzahlen zu schätzen – Das SDK Ihres LLM-Anbieters legt normalerweise usage-Daten im Antwortobjekt offen. Wenn nicht, verwenden Sie eine grobe Heuristik: Zeichen zählen und für englischen Text durch vier teilen, oder verwenden Sie den Tokenizer Ihres Anbieters.
3. Eine Python-Umgebung – Das unten verwendete Messwerkzeug verwendet nur die Standardbibliothek plus ein kleines Validierungspaket, funktioniert also in jeder Python-3.9+-Einrichtung.
4. Repräsentative Arbeitslasten – Messen Sie an realen Aufgaben, nicht an synthetischen. Ein Speicher-Audit eines Frage-Antwort-Agenten sieht ganz anders aus als ein Audit eines Codierungsagenten.

Sie benötigen keine Vektordatenbank, keine spezielle Observability-Plattform und keinen Framework-Wechsel. Sie brauchen ein Notebook und ein Gefühl dafür, was jede Zahl bedeutet.

Schritt-für-Schritt-Installation: Bauen Sie einen Speichermesser

Das Werkzeug, das wir bauen werden, ist bewusst klein: ein Logger, der jedes speicherbezogene Ereignis im Lebenszyklus des Agenten aufzeichnet und eine Zusammenfassung darüber ausgibt, wohin die Token geflossen sind. Es ersetzt nicht den vorhandenen Speicher Ihres Agenten; es beobachtet ihn.

Erstellen Sie zunächst ein dediziertes Verzeichnis, damit das Messwerkzeug von dem zu auditierenden Agenten getrennt bleibt.

mkdir agent-memory-meter && cd agent-memory-meter

Erstellen Sie als Nächstes eine virtuelle Umgebung, um zu verhindern, dass die Python-Abhängigkeiten den Systeminterpreter stören.

python -m venv .venv

Aktivieren Sie die Umgebung. Unter macOS und Linux verwenden Sie den Befehl source.

source .venv/bin/activate

Wenn Sie Windows verwenden, unterscheidet sich der Befehl geringfügig; verwenden Sie stattdessen das Aktivierungsskript im Ordner Scripts. Sobald die Umgebung aktiv ist, installieren Sie eine einzige Abhängigkeit für die Datenvalidierung.

pip install pydantic

Erstellen Sie nun das Messskript. Es definiert einen MemoryEvent-Datensatz und einen Logger, der die Ereignisse aggregiert.

# How Much Memory Does Your Agent Actually Need?
import json
import time
from pydantic import BaseModel


class MemoryEvent(BaseModel):
    timestamp: float
    step: int
    kind: str            # "user", "tool_output", or "assistant"
    tokens_in: int       # approximate prompt tokens consumed by this event
    tokens_out: int      # approximate completion tokens produced
    payload_chars: int   # length of the raw payload in characters


class MemoryLogger:
    def __init__(self):
        self.events = []

    def record(self, step, kind, tokens_in, tokens_out, payload):
        self.events.append(MemoryEvent(
            timestamp=time.time(),
            step=step,
            kind=kind,
            tokens_in=tokens_in,
            tokens_out=tokens_out,
            payload_chars=len(payload),
        ))

    def summary(self):
        total_prompt = sum(e.tokens_in for e in self.events)
        total_completion = sum(e.tokens_out for e in self.events)
        total_chars = sum(e.payload_chars for e in self.events)
        return {
            "events": len(self.events),
            "total_prompt_tokens": total_prompt,
            "total_completion_tokens": total_completion,
            "payload_kb": round(total_chars / 1024, 2),
        }


def main():
    log = MemoryLogger()
    log.record(1, "user", 120, 0, "List all open issues assigned to me")
    log.record(2, "tool_output", 0, 0,
               '{"issues": [{"id": 12, "title": "fix login", "assignee": "ada"}]}')
    log.record(3, "assistant", 0, 240,
               "There is one open issue assigned to you: fix login.")
    print(json.dumps(log.summary(), indent=2))


if __name__ == "__main__":
    main()

Das Skript protokolliert drei Arten von Ereignissen: eine Benutzernachricht, eine Tool-Ausgabe und eine Antwort des Assistenten. In Ihrem echten Agenten würden Sie log.record an jedem dieser Punkte aufrufen und dabei die von Ihrem Modellanbieter zurückgegebenen Token-Anzahlen verwenden. Führen Sie das Skript aus, um zu bestätigen, dass das Werkzeug funktioniert.

python memmeter.py

Sie sollten eine JSON-Zusammenfassung mit Ereigniszählern, Token-Summen und der Payload-Größe in Kilobyte sehen. Für dieses Spielzeugbeispiel sind die Zahlen klein; der Wert entsteht, wenn Sie den Logger in einen echten Agenten einbinden.

Nutzungsbeispiele: Die Zahlen lesen

Sobald der Logger an Ihren Agenten angeschlossen ist, lassen Sie ihn auf einem repräsentativen Satz von Aufgaben laufen. Nach einigen Sitzungen überprüfen Sie die Zusammenfassung und stellen vier Fragen.

Wie groß ist die Tool-Ausgabelast im Vergleich zur Gesprächslast? Wenn Tool-Ausgaben dominieren, gibt Ihr Agent sein Speicherbudget für rohe API-Antworten aus. Die Lösung ist kein größeres Kontextfenster, sondern engere Tool-Schemas oder ein Zusammenfassungsschritt, der ein Tool-Ergebnis auf die relevanten Felder kondensiert, bevor es wieder ins Gespräch eintritt. Ihre Messung sagt Ihnen in Kilobyte und Token, ob Sie das richtige Problem lösen.

Wie viele Ereignisse verweisen auf dieselbe Tatsache? Der Logger zeichnet Schrittnummern auf, sodass Sie wiederholte Tool-Aufrufe mit nahezu identischen Payloads erkennen können. Wenn dieselbe Issue-Liste drei Mal mit unterschiedlichen Filterparametern abgerufen wird, wird der Speicher des Agenten mit Fast-Duplikaten gefüllt. Ziehen Sie in Betracht, Tool-Ergebnisse nach Argumenten zu cachen, sodass der Speicher nur die erste Antwort und den Cache-Schlüssel enthält.

Ist die Vervollständigungsausgabe groß? Große Antworten des Assistenten werden in späteren Schritten des Gesprächs oft wörtlich erneut gesendet. Wenn Completion-Token die Zusammenfassung dominieren, spricht Ihr Agent mehr mit sich selbst als mit dem Benutzer. Kürzen Sie Chain-of-Thought-Ausgaben, bevor sie zum Transkript hinzugefügt werden.

Wie viel vom Kontextfenster würden diese Summen verbrauchen? Vergleichen Sie die gemessenen Summen mit dem Kontextlimit des Modells, das Sie einsetzen. Wenn Sie bei 10 % des Limits liegen, haben Sie Spielraum und sollten noch keinen externen Speicher hinzufügen. Wenn Sie bei 90 % liegen, ist die Lösung Reduktion vor Erweiterung – komprimieren Sie zuerst die Tool-Ausgaben, und erst dann erwägen Sie einen Langzeitspeicher für Fakten, die über Sitzungen hinweg Bestand haben.

Eine nützliche ergänzende Prüfung ist das Kompressionsverhältnis: Teilen Sie die Summe von payload_chars durch die Gesamtzahl der Token. Wenn das Verhältnis hoch ist – viele Zeichen pro Token – sind Ihre Payloads ausführlich und stark komprimierbar. Wenn es niedrig ist, enthält Ihr Speicher dichte Inhalte, die eine Zusammenfassung beschädigen würde, und Sie sollten stattdessen verhindern, dass einige Inhalte überhaupt in den Speicher gelangen.

Warum die Standardantwort normalerweise falsch ist

Die Standardantwort auf „Wie viel Speicher braucht mein Agent?“ ist normalerweise als ein Vielfaches des Kontextfensters formuliert: „genug, um die gesamte Sitzung zu halten“, oder „ein Vektorspeicher mit allem“. Beide Antworten weichen der eigentlichen Frage aus, die sich auf die Zusammensetzung des Speichers bezieht, nicht auf sein Volumen.

Umgebungskontext – das Systemprompt und die Tool-Definitionen – ist leicht zu durchdenken, weil er konstant ist. Sitzungsspeicher ist der Ort, an dem sich der Abfall versteckt. Ein Agent, der ein Suchwerkzeug aufruft, 600 Zeilen JSON erhält und dann über zwei Zeilen aus diesem Ergebnis nachdenkt, bezahlt effektiv für einen Speicher, der viel größer ist als die Informationen, die er nutzt. Die Alternative ist nicht, ihm mehr Speicher zu geben, sondern ihm weniger irrelevanten Speicher zu geben, gemessen mit einem Werkzeug wie dem obigen.

Genau deshalb ist die ALTK-Evolve-Perspektive wichtig. Wenn sich der Agent weiterentwickelt – neue Werkzeuge, neue Datenquellen, neue Benutzergewohnheiten – ändert sich das Speicherprofil. Eine Konfiguration, die für einen Zwei-Werkzeug-Agenten abgestimmt ist, wird für einen Zehn-Werkzeug-Agenten falsch sein. Die einzige nachhaltige Praxis ist, den Messer angeschlossen zu lassen, ihn regelmäßig laufen zu lassen und die Zahlen die Zuweisung bestimmen zu lassen.

Fazit

Der Speicherbedarf Ihres Agenten ist keine einzelne Zahl, die Sie nachschlagen oder einmal benchmarken können. Er ist eine Verteilung über Gespräch, Tool-Ausgabe, episodische Historie und konstanten Kontext – und diese Verteilung verschiebt sich, wenn sich der Agent ändert. Die praktische Antwort auf „Wie viel Speicher braucht Ihr Agent wirklich?“ lautet: genug, um die Aufgabe zu erledigen, ohne dieselben Daten erneut abzurufen, und nicht mehr. Der einzige Weg, diesen Punkt zu finden, ist zu messen.

Der hier vorgestellte leichtgewichtige Logger gibt Ihnen in wenigen Minuten eine Basislinie. Schließen Sie ihn an Ihren Agenten an, sammeln Sie Daten aus realen Arbeitslasten und handeln Sie auf der Grundlage der Aufschlüsselung: Komprimieren Sie Tool-Ausgaben, deduplizieren Sie wiederholte Ereignisse und reduzieren Sie, bevor Sie erweitern. Wie IBM Research' Frage im Hugging-Face-Blog nahelegt, verdient Speicher die gleiche empirische Behandlung wie jeder andere Teil des Systems. Behandeln Sie ihn als ein Budget, das gemessen wird, nicht als ein Feature, das maximiert wird, und Ihr Agent wird schneller laufen, weniger kosten und über das nachdenken, was tatsächlich wichtig ist.