Das Speichern von Sitzungsprotokollen ist für Agenten nicht hilfreich
(12gramsofcarbon.com)- Wenn ein Agent bei SWE-Aufgaben bereits Kontext wie Dokumente, PRs und Commits einsehen kann, bringt die Suche in früheren Sitzungsprotokollen keinen Leistungsvorteil
- Übliche Implementierungen speichern alle Transcripts in einer DB und machen sie dann über Vektorsuche, Elasticsearch, SQL-Suche oder Graphen per MCP oder CLI-Skill zugänglich; in mehrmonatigen Vergleichstests machte das jedoch keinen Unterschied und konnte die Modellqualität mitunter sogar verschlechtern
- In Umgebungen mit guten Commit-Messages, PR-Beschreibungen, Dokumentation und Metadaten sind wichtige Informationen bereits in Coding-Artefakten strukturiert festgehalten; Sitzungsprotokolle führen dazu, dass doppelte Informationen und temporäre Notizen erneut als Tokens gelesen werden
- Agenten sind schlecht darin, für Langzeitgedächtnis nötigen Kontext zu entfernen; da sie zustandslos sind, behandeln sie Code, Notizen und Tokens im Eingabekontext vollständig als Absicht, wodurch sich Intent Drift ansammeln kann
- Sitzungsprotokolle können für Team-Observability nützlich sein, sind als Mittel zur Leistungsverbesserung aber eher negativ; auch die wöchentlichen Änderungsvorschläge von nori bots mussten von Menschen als Diff geprüft werden, und die tatsächliche Annahmequote lag unter 20 %
Warum die Suche in Sitzungsprotokollen die Leistung nicht steigert
- Bei SWE-Aufgaben zeigte sich beim Abruf früherer Sitzungsprotokolle unter Bedingungen mit anderem verfügbarem Kontext ein Leistungsvorteil von 0
- Auch Versuche, Sitzungsprotokolle automatisch zu durchsuchen, um den Agentenkontext zu verbessern, brachten ohne menschliche Prüfung keinen großen Nutzen
- Eine typische sitzungsbasierte Memory-Architektur hat folgenden Ablauf
- Alle Transcripts der gesamten Organisation in einer DB speichern
- Darauf Ebenen für Vektorsuche, Elasticsearch und SQL-Suche hinzufügen
- Ambitioniertere Teams nutzen alle drei und ergänzen zusätzlich einen Graphen
- Dem Agenten per MCP oder über eine CLI mit Skills zugänglich machen
- Ein über mehrere Monate laufender Vergleich mit und ohne Ansatz zur Sitzungssuche zeigte: Dieser Zusatzaufwand machte keinen Unterschied und konnte das Modell in manchen Fällen verschlechtern
- Nützliche Informationen sind bereits in Coding-Artefakten strukturiert enthalten
- Codeänderungen enthalten gute Commit-Messages, PR-Beschreibungen, umfassende Dokumentation und Metadaten, die zusammen mit dem Code committet werden
- Agenten werden angewiesen, bei der Arbeit an bestimmtem Code Dokumentation und frühere PRs anzusehen
- Die Suche in Sitzungsprotokollen lässt sie Dinge erneut lesen, die sie bereits wissen, und verbraucht Tokens für temporäre Entscheidungen und Scratchpads, die man von Anfang an nicht festhalten wollte
Wo automatisches Memory ins Wanken gerät
- Agenten führen keine Memory-Bereinigung durch, die für den Erhalt von Langzeitgedächtnis wichtig ist
- In Tausenden von Sitzungen wurde praktisch kein Fall beobachtet, in dem Kontext tatsächlich entfernt wurde
- Das ist keine Eigenschaft, die sich per Prompt Engineering entfernen lässt; da Agenten zustandslos sind, behandeln sie alles im Eingabekontextfenster als Ground Truth
- Code, vorhandene Memories und alle Tokens werden als Ausdruck der Absicht behandelt – ebenso willkürliche Entscheidungen früherer Agentensitzungen oder Inhalte, die kein Mensch geprüft hat
- Dabei sammelt sich Intent Drift an
- Je stärker ein Agent eigenständig eine Memory-Basis aufbaut, desto mehr häufen sich falsche Interpretationen der Absichten aus früheren Eingaben
- Es gibt keine Coding-Benchmarks, die davon ausgehen, dass Eingabedaten verunreinigt sind; Modelle werden sogar benachteiligt, wenn sie annehmen, dass Eingabedaten falsch sind
- Es gibt auch keinen einfachen Weg, zugleich „lösche die Codebase nicht“ und „lösche Teile des Eingabekontexts“ zu erfüllen
- Automatisches Auswendiglernen endet letztlich in unnötigem Müllkontext, der Tokens verbraucht, Kosten erhöht und die Modellqualität senkt
- Sitzungsprotokolle können für Team-Observability nützlich sein, sind aber schwerlich als Werkzeug zu sehen, das Agenten besser macht
Der menschliche Review-Ansatz von nori bots
- Die Idee, Kontext im Lauf der Zeit zu lernen, ist nicht grundsätzlich unmöglich; nori bots prüfen jede Woche PRs, Slack, Drive und andere Vorgänge im Unternehmen und schlagen Änderungen an den eingebauten nori skillsets vor
- Die Änderungsvorschläge taggen das Team in Slack, standardmäßig werden sie aber alle abgelehnt
- Um eine Änderung anzunehmen, muss man sich den Diff selbst ansehen und prüfen, ob er der Absicht entspricht
- Die Annahmequote liegt unter 20 %, und man geht davon aus, dass die übrigen 80 % der „automatischen“ Updates das Modell verschlechtert hätten
- Wenn eine Organisation mit mehreren Hundert Personen solche Updates immer automatisch speichern würde, könnte das noch weniger tragfähig werden
1 Kommentare
Hacker-News-Meinungen
Ich musste daran denken, als OpenAI sagte, es habe ChatGPT eine Erinnerungsfunktion über Sitzungen hinweg gegeben. Am Ende fühlte es sich an wie eine Funktion, die ohne meine ausdrückliche Zustimmung allerlei Informationen über mich heraussucht und zwischen Prompts hinein kopiert.
Etwa so: „Vergleiche diese drei Autos. Ach ja, ich bin Dateningenieur, der Mädchenname meiner Mutter ist Joana, ich bin allergisch gegen schlechte Gedichte. Code sollte DRY sein, ich bevorzuge SQL gegenüber Python, und was ist die giftigste Blume in Skandinavien?“
Weil erinnerter Kontext in völlig unzusammenhängende Projekte und Gespräche durchsickerte und zu viel seltsamen Output erzeugte, ist das die Funktion, die ich als Erstes ausschalte.
Stimme stark zu. Das Erinnerungssystem von claude-code ist manchmal nützlich, aber viel häufiger schädlich, weil es alte Informationen heranzieht, die die aktuelle Arbeit verwässern. Ich habe oft gesehen, wie Claudes eigene Erinnerungen Claude massiv in die Irre geführt haben.
Ich vermute, es hat damit zu tun, dass das Modell wegen des Trainingsprozesses nicht zwischen „was gerade passiert“ und „was früher passiert ist“ unterscheiden kann. Wenn der Prozess, aus Erinnerungen Schlüsse zu ziehen, selbst Teil des Trainings gewesen wäre, wäre es vielleicht anders; so wirkt es wie eine Funktion, die erst zur Inferenzzeit angehängt wird und das Modell durcheinanderbringt.
LLMs sind nicht schlau genug, um auch nur leichte Kontextverschmutzung zu verkraften.
In dem Denkweg oder Kontext, der ihn dorthin gebracht hat, steckt eine Trägheit; lässt man ihn stehen, bleibt er klebrig haften.
Wenn das später dann aus der Erinnerung wieder hervorgeholt wird, ist das ziemlich nervig.
Die Idee, Erinnerungen ins Training einzubeziehen, ist interessant.
Was man mit Code „erreichen wollte“, ist meistens nicht wichtig. Wichtig ist, was der Code tatsächlich tut.
Sitzungslogs können sicher nützlich sein, aber nicht, wenn man darauf weiterentwickelt, sondern wenn man in die Validierungsphase geht. Also genau in dem Bereich zwischen Markdown-Plan und bestandenem CI, in dem 800 neue Zeilen Code entstanden sind und beim Anklicken grob in Ordnung aussehen.
Sitzungslogs können zeigen, welche manuelle Validierung stattgefunden hat. CI führt bestehende Tests aus, der Code zeigt, welche neuen Unit-Tests es gibt, aber das Sitzungslog zeigt, ob der Agent die App selbst mit Playwright bedient hat und ob er nicht nur die dev-, sondern auch die prod-Konfiguration gelesen und berücksichtigt hat.
Perfekt ist das nicht, aber nicht jede Validierungsarbeit muss zu einem Test werden, der für immer im Repository bleibt. Wir haben viel Nutzen daraus gezogen, Sitzungen erneut zu analysieren, um Stellen zu finden, an denen der Agent ohne Nachfrage Entscheidungen getroffen hat, und ihn zu zwingen, Validierungen für diese Entscheidungen in Betracht zu ziehen. So etwas ist von Anfang an schwer anzuweisen, wird in Sitzungslogs aber leicht sichtbar.
Ein nerviges Problem. Wegen einer früher gestellten hypothetischen Frage erfindet es ständig falsche Annahmen.
Nur weil ich darum gebeten habe, etwas zu recherchieren, nimmt es an, ich besäße ein Rechenzentrum und hätte viele GPUs.
Ich frage mich, ob das nicht einfach eine Form von bitter lesson ist. Der Kontext und die Agenten, die wir mühsam gebaut haben, werden wahrscheinlich verschwinden, sobald größere und bessere Modelle kommen.
Solche Gesprächsverläufe sind für weniger fähige Modelle sehr nützlich, für Frontier-Modelle aber vielleicht fast überflüssig.
Ich nutze ein Custom-Harness auf Basis von https://minimal-agent.com/; es basiert auf swe-mini-agent, und die Kernlogik umfasst etwa 50 Zeilen. Bash reicht völlig aus.
Bei kleinen Aufgaben ist es rund 8-mal schneller als die Standard-Harnesses der jeweiligen Modelle und verbraucht 8-mal weniger Tokens.
Bei großen Aufgaben habe ich es noch nicht viel getestet. Es funktioniert, aber in diesem Fall wirkt es weniger fokussiert und etwas weniger produktiv. Der 20.000-Token-Systemprompt großer Harnesses könnte wichtige Arbeit leisten, um den Softwareentwicklungs-Flow zu steuern. Ich habe zum Beispiel gehört, dass Fable einen Custom-Systemprompt für Claude Code hat; das könnte der Grund sein, warum es deutlich proaktiver agiert.
Deshalb würde ich gern glauben, dass Context Engineering weiterhin wertvoll ist. Allerdings scheint dieser Wert mit jedem neuen Modell abzunehmen, weil die Modelle insgesamt so feingetunt sind, dass sie weniger dumme Dinge tun, und man sie weniger an die Hand nehmen muss.
Zunächst glaube ich, dass Modelle weiterhin eine Kontextschicht brauchen. Eine Art, über Kontext nachzudenken, ist Kompression. Man stellt Kontext bereit, damit das Modell leichter herausfinden kann, was es tun soll. Selbst in einer Welt mit unendlicher Modellkapazität und unendlicher Kontextlänge wäre das weiterhin nützlich, weil man nicht jedes Mal alles von ersten Prinzipien aus neu herleiten müsste. Solange Modelle mit weniger Tokens besser arbeiten und wir auf Tokenkosten achten, ist Kontext eine nützliche, vielleicht notwendige Abkürzung.
Wenn man davon ausgeht, dass in irgendeiner Form eine Kontextschicht nötig ist, lautet die nächste Frage: welche Schicht? Hier stimme ich zu, dass es besser ist, mit Formen zu arbeiten, die dem Modell vertraut sind, etwa Markdown-Dateien neben dem Code. Aber das ist weniger eine Frage, ob Kontext nötig ist, sondern eher ein Problem überentwickelter Lösungen, die den Hauptnutzer, nämlich den Agenten, nicht verstehen.
Ich bin aber sehr gespannt, ob eine deutlich bessere Next-Token Prediction dieses ganze Konstrukt einfach veraltet wirken lässt. So oder so wird die Antwort viel offenlegen.
Man sollte nicht vergessen, dass auch die Struktur des Gehirns gelernt wird. Nur geschieht das auf Zeitskalen, die viel länger sind als ein einzelnes Menschenleben.
Ich stimme zu, dass man kein ausgefeiltes Memory-System bauen muss. Was es wert ist, behalten zu werden, sollte in Dokumentation, Guides, Source-Kommentaren, Commit-Messages und Tickets stehen.
Eine weitere Schicht ist nicht nötig. Jede denkbare Granularität wird bereits durch bestehende Best Practices abgedeckt.
Diese Erweiterung macht Folgendes: https://github.com/gitsense/pi-brains
Derzeit müssen „Menschen“ Routing-Regeln dafür definieren, wie auf Informationen zugegriffen wird, aber künftig ist Unterstützung für einen „Wissensagenten“ geplant, der Gespräche überwacht und bei Bedarf Kontext injiziert.
~/.claude/….In Projekten, in denen Memory nötig war, habe ich einfach eine Zeile in AGENTS.md ergänzt, die besagt, dass Erinnerungen in MEMORY.md gespeichert oder der Fortschritt in STATUS.md verfolgt werden soll.
Wenn man sie aber in einem Trace-Log taggt, kann man sie bei Bedarf effizient finden. Außerdem veraltet Dokumentation, während man Trace-Logs mit Commit-Hashes oder anderen Informationen versehen kann, um ihre Lebensdauer klarer zu machen.
Dem widerspreche ich deutlich.
Ich lasse Claude/Codex Logs schreiben [1]. Ich habe es lediglich per Prompt in AGENTS.md [0] angewiesen.
„Jede Session muss entweder ein Session-Log oder einen Plan erzeugen und am Ende eine verfasste Zusammenfassung anhängen. Standard ist ein Log; Pläne werden nur für substanzielle Designarbeit verwendet.“
Das ist enorm wertvoll. Zum Beispiel habe ich heute mehrere Sessions so begonnen: „Wie ist der Stand der Renovate-Arbeit?“, „Wir haben kürzlich an X gearbeitet, finde das bitte“, „Wurde das Backup-Problem behoben? Was sind die nächsten Schritte?“, „Dieser Bug ist wieder aufgetaucht. Hatten wir den nicht schon behoben?“
[0]: https://github.com/shepherdjerred/monorepo/blob/main/AGENTS....
[1]: https://github.com/shepherdjerred/monorepo/tree/main/package...
Insgesamt mag ich Memory-Systeme. Zur Einordnung: Ich nutze hauptsächlich Opus 4.8 + Max effort.
Es holt ziemlich oft relevante Dinge aus dem Memory hervor. Wenn ich zum Beispiel bitte, ein paar Kandidaten für selbst gehostete OIDC-Provider vorzuschlagen, sagt es etwas wie: „Angesichts der Größe des Betriebsteams könnte diese Option wegen X und Y besser passen.“
Natürlich könnte das eine Information sein, die in CLAUDE.md gehört. Aber in dem Fall war mir gar nicht in den Sinn gekommen, dass ich sie in CLAUDE.md aufnehmen sollte, und es war gut, dass das Memory sie hervorgeholt hat.
Manchmal liegt es auch daneben. Heute habe ich nach einem Authentifizierungsproblem gefragt, und es meinte: „Da ihr Apps hinter haproxy betreibt, könnte es an dieser Trusted-Proxy-Einstellung liegen.“ Für 95 % unserer Apps stimmt das und war erwähnenswert, aber diesmal nicht, also musste ich es korrigieren. Trotzdem: Wenn die App hinter einem Proxy gewesen wäre, hätte es viel Zeit sparen können, daher war es gut, dass es darauf hingewiesen hat.
Besonders schwierig wird es, wenn man häufig hypothetische Fragen stellt oder anderen bei Problemen hilft. Ein Mensch würde vermutlich nicht einfach annehmen, sondern Rückfragen stellen wie: „Geht es hier um das Betriebsteam von X? Ist dessen Größe noch Y?“ oder „Liegt diese App auch hinter einem Proxy wie die anderen Apps, über die du früher gesprochen hast?“
In solchem Kontext gibt es auch eine klare Hierarchie, die korrekt modelliert werden muss. Man kann zum Beispiel gleichzeitig in mehreren Teams involviert sein, für die unterschiedliche Regeln gelten; Menschen verstehen so etwas ganz natürlich.
Selbst wenn man Memory abschaltet, passiert so etwas innerhalb eines Gesprächs.
Es ist wie ein nerviger Freund, der sich an etwas aus einem früheren Gespräch erinnert und es einem ständig vorhält, obwohl man längst gewachsen ist und sich verändert hat.
Im Kern ist es ein Hardware-Problem. Eine Million Tokens ist nicht genug Kontext, um eine Codebase so zu verstehen, wie ein Mensch sie versteht.
Die Fähigkeit, selektiv zu vergessen, ist potenziell sehr wertvoll. Im Moment ersetzt sie aber nur ansatzweise die menschliche Fähigkeit, sich die grobe Form von etwas zu merken, es als uninteressant einzustufen und sich daran zu erinnern, dass es uninteressant ist.
Man sagt, Memory sei nur nützlich, wenn Menschen es anleiten, aber ich glaube, die richtige Lösung liegt tiefer. Vielleicht läuft es darauf hinaus, die gesamte Codebase und alle Agent-Sessions in ein Fine-Tuning des Modells zu stecken. Allerdings braucht man an diesem Punkt möglicherweise Anweisungen, bestimmte Sessions nicht ins Modell aufzunehmen. Oder auch nicht, und die bitteren Lektionen gelten vielleicht doch.