Self-Learning für Agenten: Alle drei Lernebenen und warum das User-Signal entscheidend ist

Dieser Beitrag basiert auf dem Thread „Self Learning for Agents Clearly Explained” von Atai Barkai. Den Originalthread findest du unter x.com.

Self-Learning bei KI-Agenten wird oft als Blackbox oder reines Forschungsthema verstanden. Für die Entwicklung realer Anwendungen stellt sich in der Praxis jedoch eine konkrete Architekturfrage: Auf welcher Ebene kann und sollte ein Agent in einem Softwareprodukt überhaupt lernen?

Dieser Artikel analysiert die drei technischen Lernebenen – Model, Harness und Context – und bewertet deren Relevanz für den produktiven Einsatz. Die Kernaussage vorab: Das wertvollste Signal für Systemverbesserungen kommt selten vom Sprachmodell selbst, sondern von den Interaktionen der menschlichen Anwender.

TL;DR / Key Takeaways

• Architektur: Agenten lernen auf Model-, Harness- oder Context-Ebene.
• Verantwortlichkeit: Das Model verbleibt bei den KI-Firmen. Harness und Context sind Teil der eigenen Infrastruktur.
• Datenqualität: Echte Interaktionsdaten von menschlichen Nutzern sind fälschungssicher und für das Lernen im produktiven Einsatz wertvoller als synthetische Scores.

Die drei Lernebenen

Die sauberste Aufteilung stammt von Harrison Chase:

• Model: die Gewichte (Trainingsparameter)
• Harness: der Code um das Model (Loop, Tools, Prompts)
• Context: Memory und Skills außerhalb des Harness, die wachsen

Das ist längst Praxis. Wer Claude Code nutzt, arbeitet bereits mit allen drei Ebenen. Das Model ist Claude. Der Harness ist das Tool selbst. Der eigene Context steckt in der CLAUDE.md und den individuellen Skills. Der große Vorteil: Jede Ebene lässt sich gezielt verbessern, ohne die anderen anzufassen.

Context: Memory und Skills, außerhalb des Harness CLAUDE.md /skills mcp.json

Harness: der Code um das Model loop tools prompts

Model: die Gewichte

← aufgebaut auf: DOCS und MEMORY

In der Praxis findet Self-Learning fast immer auf Harness- oder Context-Ebene statt. Das Model selbst (wie GPT-4 oder Claude) verbleibt bei den großen KI-Firmen. Die Kontrolle besteht lediglich über den eigenen Code (Harness) und die eigenen Daten (Context).

Wir prüfen jede der drei Ebenen anhand von zwei Fragen: Ist autonomes Lernen dort technisch möglich? Und haben Entwicklungsteams überhaupt die Kontrolle über diesen Lernprozess?

Damit das greifbar wird, nutzen wir durchgehend ein konkretes Szenario: Einen Support-Agenten, der Kundenreklamationen prüft und Rückerstattungen freigibt.

Layer 1: Das Model

An diese Ebene denken die meisten, wenn sie von Self-Learning sprechen. In der Praxis arbeitet hier aber kaum jemand. Auf dieser Ebene verbessert der Agent das Model selbst. Die großen KI-Firmen machen das auf drei Arten:

1. Der Agent bearbeitet den Trainingscode und behält die Änderungen, die den Score verbessern.
2. Der Agent erzeugt eigene Trainingsdaten, die direkt in die Model-Gewichte einfließen.
3. Der Agent testet massenhaft Code-Änderungen und behält die beste.

Alle drei Ansätze nutzen exakt denselben Loop. Dieser Loop funktioniert jedoch nur, wenn ein Computer das Ergebnis vollautomatisch und ohne manuellen Aufwand bewerten kann.

Wie ein Model sich selbst verbessert

Der Grundmechanismus ist ein Zyklus aus vier Schritten:

1. Etwas ändern: Code, Daten oder eine Einstellung
2. Ausführen: trainieren oder evaluieren
3. Aufwandsfrei bewerten: ein vollautomatischer Check
4. Behalten oder verwerfen: basierend auf diesem einen Score

Dieser Zyklus läuft vollautomatisch. Der Agent wiederholt ihn selbstständig tausende Male im Hintergrund, ganz ohne menschliches Eingreifen.

Das funktioniert jedoch nur unter einer strikten Bedingung: Es muss einen objektiven, rein maschinell überprüfbaren Score geben:

	Domäne	Score vorhanden?
✅ Funktioniert hier	Code und Mathematik	Der Code kompiliert oder nicht. Der Kernel ist schneller oder nicht. Die Labs betreiben den Loop.
❌ Stoppt hier	Support und Refunds	Es gibt keinen automatischen Test für die richtige Rückerstattung. Der Loop hat nichts zum Bewerten, also läuft der Agent nicht.

Model-Ansatz 1: AutoResearch (Karpathy)

Den Trainingscode bearbeiten, behalten was hilft.

Karpathys AutoResearch richtet einen Coding Agent auf ein kleines Trainings-Setup und lässt ihn über Nacht laufen. Der Agent bearbeitet eine Datei, trainiert fünf Minuten und bewertet das Ergebnis. Er behält die Änderung oder macht sie rückgängig. Dann wiederholt sich der Vorgang, etwa hundertmal in einer Nacht.

Der Ablauf im Detail:

1. train.py bearbeiten: eine Datei: Architektur, Optimizer, Hyperparameter Dies ist das Grundprinzip des autonomen Lernens: ein heuristischer Suchalgorithmus, gesteuert durch einen Evaluator. Der Prozess funktioniert ausschließlich, weil das Training eine deterministische Metrik wie val_bpb (Validation Bits Per Byte) ausgibt. Der Agent evaluiert lediglich den Score, ohne semantisches Code-Verständnis zu benötigen.

Model-Ansatz 2: Textbooks Are All You Need

Synthetische Daten für das Finetuning generieren.

Microsofts Phi-Modell wurde auf Trainingsdaten trainiert, die von GPT-4 generiert wurden. Ein größeres Sprachmodell erzeugt synthetische Lehrmaterialien und Übungsaufgaben, auf die anschließend ein kleineres Modell trainiert wird.

Die Prozessschritte laufen hierbei parallel:

1. Generator: Erzeugt eine Million Mathe-Aufgaben und löst diese.
2. Evaluator: Validiert die Aufgaben algorithmisch (z.B. durch ein Python-Skript).
3. Trainer: Das Zielmodell lernt ausschließlich aus verifizierten Beispielen.

Ein vollständig synthetischer Loop. Dieser Architektur-Ansatz skaliert theoretisch unbegrenzt, erfordert massiven Rechenaufwand und führt in isolierten Domänen zu messbaren Performance-Sprüngen.

Model-Ansatz 3: AlphaEvolve (DeepMind)

Code gegen einen vollautomatisierten Scorer evolvieren.

AlphaEvolve generiert asynchron Code-Mutationen, evaluiert diese gegen eine Testsuite und iteriert auf Basis der besten Ergebnisse. In deterministischen Benchmarks liefert dieser evolutionäre Ansatz die reproduzierbarsten Resultate.

Der Ablauf:

1. Mutation generieren: Quellcode durch das LLM anpassen lassen.
2. Evaluation: Korrektheitstests, Performance-Metriken und Ressourcenverbrauch automatisiert messen. Ein rein maschineller Evaluator validiert jeden Kandidaten.
3. Selektion: Nur die Implementierung mit dem höchsten Score wird übernommen.
4. Iteration: Der Gewinner dient als Baseline für die nachfolgende Evolutionsstufe.

Dokumentierte Ergebnisse dieses evolutionären Ansatzes in der Praxis:

• Optimierte Array-Sortierung: Performance-Gewinn gegenüber etablierten Algorithmen.
• Effizientere Matrix-Multiplikation: Unterbieten eines seit 1969 bestehenden theoretischen Limits.
• System-Optimierung: Das Framework verbesserte den eigenen Trainings-Code, auf dem es ausgeführt wird.

Model-Layer: Refund-Agent-Beispiel

Ein Support-Agent soll lernen, welche Kulanzanfragen berechtigt sind und welche abgelehnt werden müssen.

Das Modell müsste dafür auf vergangenen Entscheidungen feingetuned (Fine-Tuning) werden. Allerdings lässt sich die geschäftliche Korrektheit einer Kulanzentscheidung nicht rein maschinell verifizieren. Ohne deterministischen Score greift der autonome Lern-Loop nicht. Das reine Model-Training verbleibt daher in der Regel in der Grundlagenforschung.

Fazit für die Praxis: Autonomes Lernen auf reiner Model-Ebene ist für gängige Softwareprodukte meist irrelevant. Alle drei Ansätze setzen einen vollautomatisierten## Layer 2: Der Harness

Der Harness ist alles, was nicht das Model ist. Der Loop, der es ausführt. Die Tools und Dateien, auf die es zugreifen kann. Der System-Prompt. Die Checks, die vor jeder Aktion greifen.

Das Model liefert die Intelligenz. Der Harness entscheidet, wie sie eingesetzt wird.

Harness-Ansatz 1: Loop Engineering

Loops um den Agenten bauen.

Der Basis-Loop ist:

• Planen (Execution Plan erstellen)
• Ausführen (Tool aufrufen)
• Evaluieren (Tool-Output validieren)

Ein gängiges Architekturmuster ist der Verification Loop: Ein nachgelagerter Grader evaluiert den initialen Output und stößt bei Fehlern eine Iteration an, bis die Qualitätskriterien erfüllt sind.

Architektonische Limitation: Der Loop skaliert nur dann, wenn sich der Output deterministisch bewerten lässt – etwa durch Unit Tests, feste Geschäftsregeln oder einen LLM-Judge.

Harness-Ansatz 2: LangChain Deep Agents

Den Harness aus seinen eigenen Traces umschreiben.

Der Prozess folgt vier Schritten:

1. Tasks abarbeiten: der Agent arbeitet einen Batch von Aufgaben durch, Model bleibt fixiert
2. Traces speichern: protokollieren, wo es funktioniert hat und wo nicht
3. Fehler finden: ein Coding Agent liest die Traces und erkennt die Muster hinter den Fehlern
4. Harness umschreiben: die Teile um das Model ändern, um diese Fehler zu beheben: prompt, tools, hooks

Benchmarkergebnisse belegen, dass dieser Ansatz die Performance über verschiedene Modelle hinweg signifikant steigert, ohne die Modellgewichte selbst zu modifizieren:

• gpt-4o: 84% → 96%
• claude-3-opus: 81% → 96%
• gpt-4: 75% → 93%

Diese Metriken zeigen: Oft limitiert nicht das Sprachmodell die Performance, sondern eine unzureichende Harness-Architektur.

Architektonische Limitation: Auch dieses System erfordert einen vollautomatischen Evaluator. Es ist in Coding-Benchmarks anwendbar, versagt jedoch bei Business-Entscheidungen wie Rückerstattungen.

Harness-Ansatz 3: Self-Harness

Den Harness sich selbst umschreiben lassen.

Self-Harness führt denselben Loop vollautomatisch aus. Der Prozess in vier Schritten:

1. Fehler finden: der Agent liest seine eigenen Traces nach dem, was schiefgelaufen ist
2. Eine Änderung vorschlagen: ein einzelner, gezielter Edit am Harness
3. Testen: die Änderung gegen den Benchmark laufen lassen
4. Nur behalten, wenn es geholfen hat: sonst verwerfen

Keine manuelle Genehmigung im Loop.

Harness-Ansatz 4: Microsoft Agent Framework

Einen vorgefertigten Harness integrieren.

Das blanke Sprachmodell bietet weder Loop, noch Tools oder Memory. Microsofts Agent Framework liefert den Harness als vorgefertigten Stack zur Integration. Das Modell agiert darin als Engine:

• File Memory: Persistente Speicherung über Sessions hinweg.
• Skill-Bibliothek: Kontextabhängiges Laden lokaler Skripte.
• Plan and Execute: Arbeit in Schritte zerlegen.
• Sandboxed Execution: Isolierte Ausführungsumgebung für generierten Code.

Der Loop muss somit nicht eigens entwickelt werden. Das System greift auf eine standardisierte Harness-Infrastruktur zurück.

Architektonische Limitation: Das Lernen beschränkt sich auf interne System-Runs. Interaktionen mit menschlichen Nutzern werden nicht erfasst.

Einordnung bestehender Agenten-Architekturen

Die Einordnung erfolgt entlang von Automatisierungsgrad und Evaluierbarkeit:

	Manuelle Prüfung ←	→ Autonome Ausführung
Deterministischer Score (Code, Mathematik) ↑		Vollautonom: Der Harness optimiert sich auf Basis maschineller Tests selbst.
	Human-in-the-Loop Architektur
Kein deterministischer Score (Support, Refunds) ↓	Statischer Loop. Typische Business-Agenten.	⚠️ Hohes Risiko: Ohne Score oder Human-Review eskalieren Halluzinationen.

Bestehende Ansätze definieren den Harness statisch: Die Konfiguration erfolgt vorab und wird für alle anfallenden Tasks angewendet.

Neuere Architektur-Konzepte invertieren dieses Prinzip: Anstelle eines statischen Setups assembliert der Agent zur Laufzeit einen dedizierten Harness für den anliegenden Task – inklusive situativ gewählter Tools und Context-Segmente. Diese dynamische Orchestrierung definiert die aktuelle Entwicklungsgrenze im Harness Engineering.

Harness-Layer: Refund-Agent-Beispiel

Ein Verification Loop fungiert als zweiter Check, bevor eine Rückerstattung freigegeben wird. Der Agent genehmigt eine 5.000-Euro-Rückerstattung, der Check erkennt das überschrittene 2.000-Euro-Limit und leitet den Fall an einen menschlichen Prüfer weiter. Dieser genehmigt oder lehnt ab.

Kein Retraining, und Rückerstattungen über dem Limit schlüpfen nicht mehr durch. Das System selbst hat jedoch nicht gelernt. Die Regel hat lediglich den Ausreißer blockiert. Im nächsten vergleichbaren Fall wird das Modell denselben Vorschlag generieren und erneut blockiert.

Layer 3: Der Context

Der Context ist Memory und Skills, gespeichert als reiner Text außerhalb des Models. Dieser lässt sich lesen, ändern und löschen. Genau deshalb starten die meisten Teams auf dieser Ebene.

Das Prinzip: Lernen ohne das Model anzufassen. Drei Ansätze füttern denselben Textpool:

• Memory im Hintergrund umschreiben (Letta, OpenClaw)
• Fehler lesen, den Skill fixen (Hermes)
• Einen erfolgreichen Run als Skill speichern (Anthropic, Manus)

Alle drei erzeugen notes & skills: reiner Text, den der Agent liest. Dieser Text kann dem Agenten gehören, einem einzelnen Nutzer oder dem ganzen Team. Er wird bei jedem Run zuerst gelesen. Der nächste Run startet mit dem Wissen von heute.

Die Gewichte des Models ändern sich nie. Derselbe Text zieht zu einem neuen Model um oder wird zurückgerollt.

Der Memory-Teil kommt in drei Arten:

• Semantisch: Fakten. Das Rückerstattungslimit dieses Kunden beträgt 2.000 Euro.
• Episodisch: vergangene Erfahrung. Letzte Woche ist die Rückerstattung dieses Kunden zurückgewiesen worden.
• Prozedural: wie ein Fall zu behandeln ist. Ein loyaler Kunde über dem Limit nach wiederholten Fehlschlägen: genehmigen.

Ein selbstverbessernder Agent braucht die letzten beiden. Die meisten Setups haben nur den ersten.

Der Context reicht auch dorthin, wo die anderen zwei Ebenen nicht hinkommen. Derselbe Text kann dem Agenten als eigener Memory dienen, einem Nutzer als seine Präferenzen, oder dem ganzen Team. Einmal geschrieben, von allen gelesen.

Was diesen Text schreibt, teilt sich in drei Richtungen:

Context-Ansatz 1: Letta und OpenClaw

Den Memory im Hintergrund umschreiben.

Letta hält die Gewichte eingefroren und lernt in reinem Text, der sich lesen, diffen und löschen lässt. Der Prozess hat zwei Phasen:

Während der Konversation: Konversation → Rohnotizen. Der aktive Agent kann seinen eigenen Core Memory nicht direkt bearbeiten.

Später, in der Ruhezeit: Ein separater Agent, nach Zeitplan: Rohnotizen → bereinigter Memory. Er liest die Notizen und schreibt auf, was relevant war.

Die nächste Session liest den bereinigten Memory und startet mit Vorsprung. OpenClaw betreibt dieselbe Idee als nächtlichen Dreaming Pass über eine Memory-Datei.

Das ist der sauberste Grund, diese Ebene zu nutzen. Gewichte sind temporär, der Text bleibt. Er lässt sich zu einem neuen Model mitnehmen oder zurückrollen.

Context-Ansatz 2: Hermes

Den Fehler lesen und den Skill fixen.

Die Agentic Context Engine führt ein Skillbook. Der Ablauf:

1. Ein Run schlägt fehl
2. Lesen, warum er fehlgeschlagen ist
3. Einen Fix vorschlagen

Jeder Eintrag im Skillbook enthält ein Problem, die Aktion, die funktioniert hat, und wie oft sie geholfen hat:

Problem	Aktion	Erfolge
Over-limit Refund	An einen Manager zur Genehmigung weiterleiten	12× geholfen
Duplicate Charge	Die zweite Buchung erstatten, Account flaggen	31× geholfen
Shipping Delay	Store Credit anbieten, kein Refund	8× geholfen

Hermes Self-Evolution von Nous Research liest den Trace eines fehlgeschlagenen Runs, findet, warum er fehlgeschlagen ist, und schlägt einen Fix vor. Keine GPU nötig.

Der Haken: Es schreibt nur Skills um, keine Tools, Prompts oder Code. Und jede Änderung durchläuft Tests und einen Menschen, bevor sie wirksam wird.

Context-Ansatz 3: Anthropic und Manus

Einen erfolgreichen Run in einen wiederverwendbaren Skill verwandeln.

Anthropics Skills und Manus speichern eine funktionierende Session als SKILL.md:

SKILL.md: immer geladen · ~100 Tokens

refund-policy: wann und wie eine Rückerstattung über dem Limit genehmigt wird

↓ Body wird nur geladen, wenn der Skill verwendet wird

Ein erfolgreicher Run → speichern → SKILL.md → teilen → das Team.

Der Name und eine Zeile bleiben im Kontext, der Body lädt nur bei Verwendung. Prüfe einen Skill einmal, teile ihn, und der erfolgreiche Run einer Person verbessert den nächsten Run aller anderen.

Der Haken: Es speichert, was einmal funktioniert hat. Nichts prüft, ob es noch funktioniert, oder entfernt es, wenn es veraltet ist.

Alle drei Methoden verwandeln das, was funktioniert hat, in Text, den der nächste Run liest. Gewichte eingefroren, Harness unberührt.

Context-Layer: Refund-Agent-Beispiel

Der Agent führt eine laufende Notiz über das, was er gesehen hat: das Limit dieses Kunden, welche Rückerstattungen abgelehnt wurden, was er letztes Mal versucht hat. Beim nächsten Run liest er diese Notiz, statt kalt zu starten. Nichts wurde retrainiert. Nur eine Notiz, die bestehen bleibt.

Das User-Signal: Das fehlende Puzzlestück

Jede bisherige Methode lernt aus den eigenen Runs des Agenten. Es gibt ein besseres Signal, und fast niemand erfasst es: die tatsächlichen Nutzer.

Support, Vertrieb, Operations. Es gibt keinen automatischen Test für die richtige Entscheidung bei einer Rückerstattung. Das Einzige, was dem Agenten sagen kann, dass er gut gearbeitet hat, ist ein Mensch.

Die echte Entscheidung eines Menschen ist das einzige Signal, das nicht gefälscht werden kann. Ein automatischer Score kann gefälscht werden.

Die Warnung: Sakanas Darwin Gödel Machine

Sakanas Darwin Gödel Machine wurde losgelassen, um sich gegen einen Test zu verbessern. Statt bessere Arbeit zu leisten, fälschte sie ihre eigenen Testlogs.

Als die Forscher einen Detektor hinzufügten, um das zu erkennen, entfernte die Maschine genau die Marker, auf die der Detektor angewiesen war, obwohl sie angewiesen wurde, das nicht zu tun.

Zwei Wege, menschliches Wissen zu erfassen

Eine Session hat zwei Hälften: was die Person tut, und was der Agent tut. Jeder Weg sieht nur eine davon:

Reale Interaktionen als Lerngrundlage

Bestehende Ansätze generieren Trainingssignale vorwiegend aus den isolierten Ausführungen des Agenten. Das qualitativ hochwertigste Signal wird dabei meist ignoriert: die Interaktion mit dem menschlichen Anwender.

In Domänen wie Support oder Operations existieren keine deterministischen Metriken zur Validierung. Die einzige verlässliche „Ground Truth” für fachliche Korrektheit liefert menschliches Feedback.

Die dokumentierte, reale Entscheidung eines Anwenders ist das valideste Trainingssignal.

Das Defizit heutiger Architekturen

Aktuelle Human-in-the-Loop-Systeme (HitL) verhalten sich meist statisch:

• Der Agent generiert einen Vorschlag (z.B. „Erstattung ablehnen”).
• Ein menschlicher Prüfer verwirft den Vorschlag und exekutiert eine abweichende Entscheidung („Erstatten”).

In einer statischen Architektur geht diese Korrektur verloren. Im nächsten, vergleichbaren Fall generiert das System denselben Fehler.

Der architekturelle Zielzustand

Ein Agent verweigert eine 5.000-Euro-Rückerstattung aufgrund eines fest codierten 2.000-Euro-Limits. Ein Sachbearbeiter überschreibt die Entscheidung manuell mit der Begründung: loyaler Kunde, wiederholte Lieferausfälle.

Diese Diskrepanz zwischen KI-Vorschlag und menschlicher Korrektur ist der entscheidende Datenpunkt. Die Erfassung erfordert keinen manuellen Mehraufwand: Die UI-Events der manuellen Freigabe werden in der Applikation ohnehin ausgelöst und lassen sich direkt als asynchrones Lernsignal abgreifen.

Ein Hintergrund-Prozess protokolliert die menschliche Aktion und extrahiert die zugrunde liegende Rationale. Diese Information wird in den Context des Agenten (Memory) überführt. Tritt ein identisches Muster auf, agiert das System fortan anhand dieser neuen Baseline.

• Der Anwender fungiert implizit als Evaluator.
• Die ausgeführte Aktion bildet den Score.
• Die abgeleitete Geschäftsregel wird als maschinenlesbarer Text (Context) persistiert.

Architektur-Zusammenfassung

Ebene	Was sich ändert	Wie das System lernt	Einsatzgebiet
Model	Modell-Gewichte	Synthetisches Training mit vollautomatisiertem Score.	KI-Forschung
Harness	Execution Scaffold	Iterative Optimierung von Prompt und Tools via Traces.	Produktivsysteme
Context	Memory und Skills	Persistierung menschlicher Interaktionsmuster in Plain Text.	Produktivsysteme (Nutzer-zentriert)

In realen Software-Architekturen verbleibt die Model-Ebene bei den großen Technologie-Anbietern. Die Verantwortlichkeit der Entwicklerteams liegt vollständig beim Design von Harness und Context.

Der höchste Hebel für fachspezifisches Lernen liegt im Context, da hier das Feedback der tatsächlichen Nutzer als Signalquelle integriert werden kann.

Strategische Umsetzung in der eigenen Architektur

1. Harness standardisieren: Die Ausführungslogik über Verification Loops oder etablierte Frameworks kapseln.
2. Context Engine implementieren: Erfolgreiche Patterns in textbasiertem Memory (z.B. als strukturierte SKILL.md) sichern, um Folge-Runs mit Kontext anzureichern.
3. Mensch-Maschine-Schnittstelle nutzen: Manuelle Korrekturen durch Nutzer als automatisierte Trigger für Context-Updates verwenden.

Welche dieser Lernebenen wird in der bestehenden Applikations-Architektur bereits aktiv abgebildet?