Selbstverbessernde Agenten: Heilung, Lernen und kontrollierte Veränderung
Selbstverbessernde Agenten ohne Risiken: Laufzeit- Selbstheilung, Lernen über mehrere Ausführungen sowie Änderungen, die erst nach Bewertungen und Canaries bereitgestellt werden, auf LangGraph.
Quellen: Self-improving Agentic AI Applications — Feedback loop integration
Ein ReAct-ähnlicher Agent plant sorgfältig, ruft Tools auf, holt Informationen ab und führt mehrstufige Aufgaben aus. Das Problem beginnt erst, wenn er in der Produktion eingesetzt wird und jemand fragt, was passiert, wenn er etwas falsch macht. Kann er das erkennen? Kann er sich ohne Neustart des gesamten Workflows erholen? Kann er sich daran erinnern, was funktioniert hat, aus Korrekturen der Benutzer lernen und schließlich sein eigenes Verhalten verbessern?
Menschen fassen diese Fragen unter dem Begriff „Agent-Feedbackschleife“ zusammen – doch dieser Begriff ist irreführend. Die unten dargestellte Architektur kombiniert LangGraph mit MongoDB, Gemini auf Vertex AI sowie Arize Phoenix und umfasst die Wiederherstellung während des Betriebs, das Lernen aus Erfahrungen, kontinuierliche Bewertung sowie kontrollierte Verbesserungen.
Warum die naive Feedbackschleife gefährlich ist
Die verlockende Version einer Feedbackschleife ist kurz:
Agent produces answer
↓
LLM reflects on answer
↓
Agent learns
Es ist attraktiv, weil es einfach ist – und zugleich riskant. Wenn ein LLM seine eigene Ausgabe bewertet und sein zukünftiges Verhalten sofort ändert, kann ein Fehler zu einer Lektion werden, diese Lektion zu einem Gedächtnisinhalt und dieser wiederum Tausende späterer Entscheidungen prägen.
Ein sichereres Design basiert auf einem anderen Prinzip: Der Agent behebt die aktuelle Ausführung, die Plattform lernt aus vielen Ausführungen, und eine Steuerungsschicht entscheidet, was zum produktiven Verhalten wird.
Ein konkreter Fall: Ein Agent empfiehlt Lohn- oder Abzugscodes. Bei einer Ausführung wählt er den falschen Code, weil er niemals eine staatsspezifische Lohnpolitik abgerufen hat. Der naive Lernweg verläuft wie folgt:
Agent made mistake
↓
Agent reflects
↓
"Always retrieve state policy"
↓
Write lesson to memory
↓
Future agents use lesson
Mehrere Dinge können dabei schiefgehen. Die Diagnose könnte falsch sein. Die Regel könnte nur für eine bestimmte Art von Lohnabrechnungsgeschäft gelten. Spätere Änderungen in den Richtlinien könnten die Lektion überholt machen. Böswillige Benutzereingaben könnten die Auswertung beeinflussen. Zudem könnte die Lektion in einigen Fällen helfen, in anderen hingegen schaden.
Deshalb betrachtet ein besseres Design eine Lektion als Hypothese und nicht als Wahrheit.
Production failure
↓
Capture evidence
↓
Evaluate the run
↓
Identify recurring failure
↓
Generate lesson candidate
↓
Gather supporting and contradicting evidence
↓
Validate
↓
Canary test
↓
Activate
Der Wandel ist subtil. Der Agent schreibt sich nicht ständig neu. Die Plattform um ihn herum bewertet und entwickelt den Agenten kontinuierlich weiter.
Drei Ebenen mit unterschiedlicher Autorität
Es hilft, sich drei miteinander verbundene Ebenen vorzustellen.
+------------------------------------------------+
| RUNTIME PLANE |
| |
| plan -> act -> validate -> repair -> respond |
+-----------------------+------------------------+
|
v
+------------------------------------------------+
| LEARNING PLANE |
| |
| evaluate -> diagnose -> cluster -> learn |
+-----------------------+------------------------+
|
v
+------------------------------------------------+
| CONTROL PLANE |
| |
| test -> approve -> canary -> rollout -> rollback|
+------------------------------------------------+
Jedes Ebene arbeitet in ihrem eigenen Tempo und verfügt über einen unterschiedlichen Grad an Autorität. Die Laufzeitebene arbeitet innerhalb von Millisekunden oder Sekunden, und ihre einzige Aufgabe besteht darin, die aktuelle Anfrage zuverlässig abzuschließen. Die Lernebene analysiert viele Ausführungen über Minuten, Stunden oder Tage hinweg und entscheidet, was die zusammengeführten Erkenntnisse zeigen. Die Kontrollebene beurteilt, ob eine vorgeschlagene Verbesserung sicher genug ist, um in ein Produktionsverhalten umgesetzt zu werden. Bei einer adaptiven Agentenplattform sind nur wenige Designentscheidungen so wichtig wie die Trennung dieser drei Ebenen.
1. Selbstheilung in der Laufzeit
Beginnen wir mit dem unmittelbaren Problem: Ein Toolaufruf fehlschlägt. Eine vereinfachte Implementierung versucht einfach erneut, den Aufruf durchzuführen.
Tool failed
↓
Retry
↓
Retry
↓
Retry
Doch das Wiederholen des Versuchs ist keine Selbstheilung. Zur Heilung ist es notwendig, zu wissen was fehlgeschlagen ist und eine geeignete Wiederherstellungsstrategie zu wählen. Ein leistungsfähigereres LangGraph-Arbeitsablauf ähnelt eher diesem Ansatz:
User Request
|
v
Clarification Gate
|
v
Retrieve Context
|
v
Plan
|
v
Proposed Action
|
v
Action Guard
|
v
Execute Tool
|
v
Sanitize Tool Result
|
v
Validate Tool Result
|
v
Reason
|
v
Validate Answer
|
+------ uncertain ------> Critic
| |
| v
| Policy Router
| / | | \
| PASS REPAIR HUMAN FAIL
| |
+---------------------------+
|
v
Response
Mehrere Aspekte in diesem Diagramm verdienen Aufmerksamkeit.
Validieren, bevor man handelt
Stellen Sie sich einen Agenten vor, der Aktionen mit Nebenwirkungen ausführen kann: Aktualisierung von Mitarbeiterdaten, Erstellung einer Lohnabzugsmeldung, Einreichen einer Transaktion, Änderung eines Kontos oder Versendung einer Benachrichtigung. Das Überprüfen des Ergebnisses danach ist zu spät. Die Architektur benötigt einen Aktionsschutzmechanismus vor jeder nachfolgenden Änderung. Dieser Mechanismus bewertet Berechtigungen, Geschäftsregeln, verfügbare Beweise, ob die Aktion rückgängig gemacht werden kann, das Risikoniveau sowie ob eine Genehmigung erforderlich ist. Erst danach darf das Tool ausgeführt werden.
Dadurch ändert sich die Sicht auf die Validierung. Die Frage lautet nicht mehr „War die Aktion korrekt?“, sondern die viel sicherere „Haben wir ausreichende Beweise und Befugnisse, um dies zuzulassen?“
Auch die Ausgabe des Tools ist unzuverlässig
Ein weiteres Risiko wird übersehen. Agenten lesen Inhalte von Webseiten, Dokumenten, APIs, Suchmaschinen, Datenbanken und anderen Agenten, und dieses Material fließt in den Kontext des LLMs. Die Ergebnisse von Tools stellen daher einen weiteren Weg für Prompt-Injection dar, weshalb ein deterministischer Tool-Resultat-Sanitizer zwischen der Ausführung des Tools und dem Reasoning eingefügt werden sollte.
External Tool
|
v
Tool Result
|
v
Sanitizer
|
v
Validator
|
v
LLM
Zu den typischen Aufgaben eines Sanitizers gehören die Einhaltung von Ausgabetyp und -länge, die Ablehnung fehlerhafter Strukturen, das Escape von Texten, die wie Anweisungen aussehen, sowie das Erkennen möglicher Injection-Versuche. Eine strenge Einschränkung gilt: Kein LLM darf zur Überprüfung von Texten verwendet werden, die möglicherweise feindlich gesinnt sind.
Trennen Sie den Validator vom Kritiker
Ein gängiges Muster besteht darin, vom LLM bei jeder Anfrage zu fragen: „Ist diese Antwort korrekt?“ Das führt zu Verzögerungen und höheren Kosten und verleiht dem Modell zu viel Macht. Zunächst sollte eine deterministische Validierung erfolgen, zum Beispiel:
Schema correct?
Required fields present?
Allowed value?
Business invariant satisfied?
Evidence exists?
Policy satisfied?
Known contradiction detected?
Falls eine Software nachweisen kann, dass eine Antwort falsch ist, gibt es keinen Grund, ein anderes Modell zu fragen. Nur echte semantische Mehrdeutigkeiten erreichen den Kritiker, und selbst dann steuert der Kritiker den Arbeitsablauf nicht. Seine Rolle besteht in der Diagnose, und zwar in folgendem Sinne:
{
"correctness": 0.61,
"groundedness": 0.92,
"uncertainty": 0.73,
"defects": [
"missing_authoritative_evidence"
]
}
Ein deterministischer Policy-Router wählt anschließend aus vier möglichen Ergebnissen aus:
PASS
REPAIR
HUMAN REVIEW
SAFE FAIL
Die Aufteilung ist klar: Der LLM liefert Beweise und Urteile, während die Softwarerichtlinien die Autorität innehaben.
Die Reparatur sollte die Strategie ändern
Ein erneuter Versuch ist nur dann sinnvoll, wenn sich etwas geändert hat. Nehmen wir einen Agenten, der dies durchführt:
Search policy
↓
Generate recommendation
↓
Fail validation
Falls die Reparatur die untenstehende Abfolge mit derselben Anfrage, denselben Beweisen und derselben Argumentationsmethode wiederholt, handelt es sich dabei nicht um eine Wiederherstellung. Es ist lediglich eine Wiederholung.
Search policy
↓
Generate recommendation
Ein zuverlässiger Agent überwacht einige Felder.
failure signature
strategy fingerprint
attempt ID
repair strategy
remaining budget
quality delta
Dann gilt eine einfache Regel.
same failure
+
same strategy
+
same evidence
=
do not retry
Immer dann, wenn derselbe Fehler ein zweites Mal auf dieselbe Strategie stößt, sollte der Agent die Strategie wechseln, die Kontrolle an einen Menschen übergeben oder sicher versagen. Ein einfacher retry_count deckt dies nicht ab, weshalb eine selbstheilende Produktion Reparaturbudgets benötigt. Diese können Anrufe bei LLMs, Toolaufrufe, verstrichene Zeit, Ausgaben sowie semantische Reparaturversuche begrenzen. Das Ziel ist es nicht, auszuharren, bis etwas funktioniert – vielmehr sollen begrenzte Ressourcen in tatsächlich unterschiedliche Wiederherstellungsstrategien investiert werden.
Überprüfen, ob die Reparatur geholfen hat
Auch unterschiedliche Versuche können versagen, eine Verbesserung herbeizuführen. Nehmen wir an, ein Bewertungstool bewertet das ursprüngliche Ergebnis:
quality score = 0.54
Nach der ersten Reparatur:
quality score = 0.55
Nach dem zweiten:
quality score = 0.56
Auf dem Papier ist das eine Verbesserung, in der Praxis jedoch ein Rückschritt. Eine Repair Delta Gate fängt das ab.
delta = score_after_repair - score_before_repair
Wenn mehrere Reparaturen jeweils nur unbedeutende Verbesserungen bringen, hört der Zufluss von Ressourcen auf.
small delta
+
small delta
=
human review or safe failure
Das schützt vor einem der häufigsten Fehler bei Agenten – dem teuren Schlussfolgerungszyklus, der scheinbar aktiv ist, aber fast nichts erreicht.
Menschliche Überprüfung als Entscheidungsweg
Menschliche Überprüfung sollte nicht als Fehler gelten. Für bestimmte Aufgaben ist sie einfach die richtige endgültige Entscheidung. Zudem umfasst der Begriff „menschliche Überprüfung“ mehrere verschiedene Ergebnisse.
Human
|
+-----------+-----------+
| | |
Approve Edit Reject
| | |
Continue Validate Safe Fail
Request Repair
|
v
Repair
Jedes Ergebnis verläuft unterschiedlich, daher sollte jedes ausdrücklich im Diagramm dargestellt werden. LangGraphs Modell zur Unterbrechung und Wiederaufnahme eignet sich hier hervorragend, da der Arbeitsablauf abgespeichert, unterbrochen und anschließend wieder aufgenommen werden kann, sobald der Prüfer antwortet.
2. Lernen aus Erfahrungen über mehrere Ausführungen hinweg
Das Konzept des laufzeitbasierten Korrekturverfahrens beantwortet die Frage, wie dieser Antrag gerettet werden kann. Das Lernen aus Erfahrungen fragt, was der Antrag über zukünftige Anfragen lehrt. Dies gehört in der Regel in den Hintergrund. Sobald der Agent geantwortet hat:
run_completed
|
v
Evaluation worker
|
v
Gather feedback
|
v
Reflection
|
v
Candidate lesson
Niemand muss warten, während ein LLM darüber nachdenkt, was ein anderes LLM gelernt haben könnte. Die Latenz bleibt niedrig, und die Offline-Bewertung kann weitaus umfassender sein.
Feedback ist keine Wahrheit
Signale kommen aus vielen Richtungen. Ein Benutzer gibt eine negative Bewertung ab. Ein Experte korrigiert eine Antwort. Eine nachgelagerte API lehnt eine Transaktion ab. Eine Konformitätsprüfung entdeckt einen Fehler erst nach zwei Wochen. Diese sind nicht gleichwertig. Betrachten Sie das erste Paar von Fällen, in denen die Gleichwertigkeit nicht gegeben ist:
thumbs up != correct
thumbs down != incorrectuser correction != authoritative rule
Feedback sollte daher als rohe Beweismittel aufbewahrt und nach Zuverlässigkeit eingestuft werden, ungefähr wie folgt:
Authoritative business outcome
>
Expert human label
>
Deterministic rule
>
Calibrated evaluator
>
User feedback
>
Agent self-confidence
Das verhindert, dass Stimmungen fälschlicherweise als wahr angesehen werden.
Einige der besten Rückmeldungen kommen spät
Agenten starten oft Workflows, deren Erfolg nicht sofort sichtbar ist.
Agent recommends payroll code
|
v
Payroll system accepts
|
v
Two weeks later
|
v
Audit rejects transaction
Das nützliche Signal trifft erst lange nach Abschluss des LangGraph-Laufs ein, was bedeutet, dass jede wichtige Entscheidung eine kausale Abfolge benötigt. Übergeben Sie den run_id an nachgeschaltete Systeme, damit spätere Ergebnisse auf die dahinterliegende Entscheidung zurückverfolgt werden können. Andernfalls lernt das Lernsystem, dass etwas fehlgeschlagen ist, kann aber nicht feststellen welche Agentenentscheidung Anerkennung oder Schuld trägt. Das ist das klassische Kreditzuweisungsproblem.
Das Gedächtnis benötigt Steuerung
Sobald Agenten über mehrere Laufe hinweg lernen, wird das Gedächtnis gleichzeitig mächtig und gefährlich. Drei Kategorien sollten getrennt gehalten werden.
- Profilgedächtnis speichert Präferenzen eines Benutzers oder einer Einheit, wie beispielsweise die Präferenz für prägnante Erklärungen.
- Episodisches Gedächtnis dokumentiert etwas, das geschehen ist – zum Beispiel, dass Lauf 182 fehlgeschlagen ist, weil die Zustandsrichtlinie nicht abgerufen werden konnte.
Die prozedurale Erinnerung verändert das Verhalten am stärksten, weshalb sie der strengsten Kontrolle unterliegen sollte. Ein einziger fehlgeschlagener Ablauf darf niemals eine Produktionsprozedur erzeugen. Der Pfad sollte eher so aussehen:
Observation
↓
Candidate lesson
↓
Supporting evidence
+
Counterexamples
↓
Validation
↓
Active lesson
Eine Lektion sollte besser als Hypothese plus Beweise plus Umfang plus Vertrauen plus Lebenszyklus modelliert werden und nicht als Text, der in eine Vektormerzei geschrieben wird.
Gelerntes Wissen kann autoritatives Wissen nicht übertreffen
Agenten holen zwei Arten von Informationen ab. Authoritatives Wissen bezeichnet Richtlinien, Vorschriften, Konfigurationen, Referenzdaten sowie vertragliche Geschäftsregeln. Gelerntes Wissen umfasst Präferenzen, Erfahrungen, frühere Strategien, Beobachtungen und Lektionen. Beide sollten logisch getrennt bleiben, wobei eine sinnvolle Priorisierung besteht:
Authoritative policy
>
Tenant configuration
>
Approved procedural lesson
>
Episodic example
>
User preference
>
Unverified claim
>
LLM reflection
Andernfalls kann eine zuverlässig in Erinnerung gebliebene Lektion die tatsächlichen Richtlinien stillschweigend außer Kraft setzen.
Lektionen veralten
Was vor sechs Monaten nützlich war, kann heute falsch sein. Richtlinien, Produkte, APIs, Benutzerverhalten und Modelle ändern sich ständig. Aktive Lektionen benötigen eine Lebenszyklusverwaltung.
candidate
↓
validated
↓
active
↓
pending revalidation
↓
deprecated
↓
retired
Vergeben Sie jeder Lektion ein Zeitstempel für die Validierung und, wenn sinnvoll, eine Ablauf- oder Neuvalidierungsrichtlinie. Eine Änderung der Richtlinie kann dann eine Neubewertung aller auf dieser Richtlinie basierenden Lektionen auslösen, sodass das Wissen geregelt wird und nicht zu einem stetig wachsenden Pool von Embeddings wird.
3. Die Offline-Lernumgebung
Die nächste Schicht aggregiert Belege aus vielen Produktivlaufungen.
Runs
+
User Feedback
+
Human Reviews
+
Downstream Outcomes
+
Evaluation Scores
|
v
Failure Classification
|
v
Failure Clustering
Sagen wir, eine Woche des Laufens zeigt diese Verteilung:
missing state policy 178
wrong tool selected 63
bad tool argument 52
unsupported inference 41
output schema failure 11
Nun kann die Plattform erkennen, welche Probleme systemisch sind. Das ist etwas anderes, als von einem einzelnen fehlerhaften Agenten zu verlangen, über einen einzelnen fehlgeschlagenen Vorgang nachzudenken. Die Lernplattform erkennt Muster.
Nicht jeder Fehler ist ein Prompt-Problem
Prompt-Engineering ist nicht immer die Lösung. Wenn ein Agent ständig vergisst, vor der Empfehlung einer Maßnahme eine zuverlässige Richtlinie abzurufen, könnte das Hinzufügen einer Zeile zum Systemprompt, die ihn daran erinnert, helfen. Eine stärkere Lösung könnte eine strukturelle Regel sein:
Graph rule:
Policy retrieval must occur before this decision.
Weitere wiederkehrende Fehler können Änderungen in diesen Bereichen erfordern:
retrieval
tool schema
validator rule
routing
memory policy
clarification logic
action guard
model configuration
Ein ausgereifter Verbesserungsmotor schlägt mehrere mögliche Korrekturen vor und schreibt den Prompt nicht automatisch um.
Die Bewertung steht im Mittelpunkt
Falls ein System Verbesserungen erzeugen kann, aber nicht beurteilen kann, ob sie besser sind, gibt es keinen Lernzyklus, nur einen Mutationzyklus. Die Bewertung ist die Grundlage dieser Architektur.
Correctness
Groundedness
Retrieval relevance
Completeness
Tool selection
Tool arguments
Trajectory efficiency
Repair effectiveness
Safety
Latency
Cost
Business outcome
Die Bewertung muss sowohl die endgültige Antwort als auch den Weg umfassen, der zu ihr geführt hat. Zwei Agenten können dieselbe Antwort liefern. Agent A macht dies so:
Agent A
search -> answer
während Agent B das tut:
Agent B
search
-> wrong tool
-> retry
-> timeout
-> second search
-> repair
-> answer
Allein anhand der Endantwort sind sie äquivalent. Eine Bewertung der Bahn zeigt jedoch deutlich, dass dem nicht so ist.
Ein einzelner LLM-Bewerter reicht nicht aus
Es ist nützlich, wenn Gemini eine Antwort erstellt und ein anderer Gemini diese mit einer Anweisung bewertet, doch dies birgt das Risiko korrelierter Fehler, da der Bewertende die Blindstellen des Erstellers teilen könnte. Eine stärkere Bewertungsebene kombiniert mehrere Quellen.
Deterministic checks
+
Business outcomes
+
Human labels
+
Multiple evaluator rubrics
+
LLM judges
LLM-Bewerter sollten auch von Zeit zu Zeit mit von Menschen annotierten Beispielen verglichen werden. Das zeigt, inwieweit dem Bewerter vertraut werden kann, bevor seine Bewertungen darüber entscheiden, welche Lektionen vorgestellt werden.
Beobachtbarkeit gehört zum Lernen
Traditionelle Überwachung prüft lediglich, ob der Dienst verfügbar ist. Die Beobachtbarkeit von Agenten muss außerdem ermitteln, warum der Agent eine bestimmte Entscheidung getroffen hat. Eine gute Produktionsumgebung protokolliert einen Ablaufverlauf über die gesamte Ausführung von LangGraph.
Agent Run
|
+-- Retrieve Context
|
+-- Planner
|
+-- Tool Call
|
+-- Tool Result Validator
|
+-- Repair
|
+-- Critic
|
+-- Final Answer
Jeder Lauf sollte außerdem eine stabile Identität aufweisen, die mehrere Aufzeichnungen miteinander verbindet.
LangGraph execution
MongoDB events
Vertex AI calls
Evaluation results
Human feedback
Downstream outcomes
Diese Korrelation ist die Rohstoffbasis für den Schleifenprozess. Die Beobachtbarkeit ist dann nicht mehr nur ein Hilfsmittel zum Fehlersuchen, sondern wird Teil des Lernsystems.
Warum append-only-Ereignisse helfen
Es ist verlockend, den gesamten Ausführungspfad in ein einziges MongoDB-Run-Dokument zu packen. Zunächst funktioniert das, wird aber bei größeren Mengen problematisch. Halten Sie den Run stattdessen kompakt.
run_id
agent
release
outcome
latency
tool count
repair count
cost
Dann werden die Ausführungen als nur zum Hinzufügen geeignete Ereignisse aufgezeichnet.
run.started
retrieval.completed
tool.called
validation.failed
repair.started
human_review.requested
run.completed
Dadurch bleibt die kausale Reihenfolge gewahrt, es entstehen keine riesigen, wachsenden Dokumente, die verteilte Überwachung wird vereinfacht und die Fehleranalyse wird genauer.
Für Reproduzierbarkeit reicht eine Prompt-Version nicht aus
Das Verhalten eines Agenten hängt von mehr als nur seinem Systemprompt ab.
model
generation settings
graph version
tool definitions
validator rules
critic rubric
retrieval configuration
memory rules
security rules
Jeder Produktionslauf sollte daher eine unveränderliche Agenten-Version festlegen. Konzeptionell:
agent_release_43
|
+-- graph v12
+-- prompt v43
+-- Gemini configuration
+-- tools v17
+-- validator v11
+-- retrieval config v9
+-- memory policy v5
+-- evaluation suite v8
Einen fehlgeschlagenen Ausführungsvorgang kann man später erneut durchführen. Ohne diese Möglichkeit reduziert sich das Debuggen auf die Frage, welche Version eine Antwort geliefert hat, gefolgt von Stille.
Das Steuerungsflächenkonzept: Verbesserungen sichern den Zugang zur Produktion
Irgendwann erkennt das Lernsystem ein wiederkehrendes Versagen und entwirft eine Verbesserung. Die schlimmste Reaktion ist, diese sofort einzusetzen. Führen Sie sie stattdessen durch verschiedene Überprüfungsstufen:
Candidate Improvement
|
v
Historical Replay
|
v
Regression Evaluation
|
v
Shadow Production
|
v
Canary
|
v
Progressive Rollout
|
v
Production
In jeder Phase sollte der Kandidat mit der aktuellen Version verglichen werden. Dadurch kann die Genauigkeit verbessert und die Latenz erhöht werden, Halluzinationen verringert und der Bedarf an menschlicher Intervention gesteigert werden – oder ein bestimmter Aufgabentyp gefördert und ein anderer beeinträchtigt werden. Daher benötigt die Einführung neuer Versionen mehrere Schutzmechanismen.
Auch Lektionen benötigen „Canaries“
Die Langzeitmerkfähigkeit hat eine interessante Folge: Wenn eine neue prozedurale Lektion aktiviert und in den Kontext zukünftiger Agenten eingefügt wird, ändert sich ihr Verhalten – somit ist das Einfügen einer Lektion im Grunde eine Änderung des Anreizes. Die Aktivierung sollte als Experiment betrachtet werden und nicht sofort bei jedem geeigneten Durchlauf angewandt werden.
Historical replay
↓
5% canary
↓
Measure outcome
↓
25%
↓
Measure
↓
100%
Falls die Lektion die Leistung verschlechtert, führen Sie einen Rollback durch. Dann ist das Gedächtnis kein geheimnisvoller adaptiver Mechanismus mehr, sondern eine messbare Softwarefunktion.
Die endgültige Architektur
Insgesamt sieht die adaptive Agentenplattform ungefähr so aus:
USER
|
v
+------------------------------------------------------+
| RUNTIME |
| |
| clarify -> retrieve -> plan -> action guard |
| | |
| v |
| tool |
| | |
| sanitize |
| | |
| validate |
| | |
| reason |
| | |
| answer validate |
| | |
| critic if needed |
| | |
| policy router |
| / | \ |
| repair human pass |
+--------------------------+---------------------------+
|
agent events
|
v
+------------------------------------------------------+
| LEARNING |
| |
| traces + feedback + outcomes |
| | |
| v |
| evaluate |
| | |
| classify failures |
| | |
| cluster |
| / \ |
| lessons improvement candidates |
+--------+----------------------+----------------------+
| |
v v
+------------------------------------------------------+
| CONTROL |
| |
| validate -> replay -> shadow -> canary -> rollout |
| | |
| monitor |
| | |
| rollback |
+------------------------------------------------------+
Die Verantwortungsgrenzen sind absichtlich klar definiert. Der Laufzeitagent behebt Ausführungsfehler. Das Lernsystem erzeugt Hypothesen. Die Steuerungsplattform entscheidet, was als zuverlässiges Verhalten gilt.
Umfassende Betrachtung des Konzepts „selbstverbessernd“
Wenn man von einem „selbstverbessernden Agenten“ hört, stellen sich viele Menschen eine KI vor, die ihren eigenen Systemprompt umschreibt oder nach jedem Chat aktualisiert. Für Produktionsysteme ist das das falsche Denkmuster. Besser ist ein Kreislauf:
Observe
↓
Measure
↓
Diagnose
↓
Propose
↓
Test
↓
Promote
↓
Monitor
Die Intelligenz ist hier nicht auf das LLM beschränkt. Verschiedene Teile des Systems tragen dazu bei:
- Das LangGraph-Diagramm bestimmt die Ausführungsreihenfolge.
- Code-Validatoren stellen sicher, dass bereits bekannte Regeln eingehalten werden.
- Das LLM kümmert sich um alles, was unklar ist.
- MongoDB speichert den Zustand sowie angesammelte Erfahrungen.
- Tracing sammelt die Beweise.
- Bewertungstools messen die Qualität.
- Menschen treffen die Entscheidung, wenn das Risiko hoch und die Antwort unklar ist.
- Das Control Plane steuert alle Verhaltensänderungen.
Diese Verteilung verwandelt einen Agenten in ein adaptives Agentensystem.
Eine sinnvolle Build-Reihenfolge
Niemand muss den gesamten Zyklus auf einmal erstellen. Eine funktionierende Abfolge beginnt mit zuverlässiger Ausführung und einer Protokollierung bei jedem Lauf. Darüber hinaus kommen Aktionsschutzmechanismen, Validierung von Ergebnissen und Antworten, begrenzte Korrekturmaßnahmen sowie menschliche Überprüfung zum Einsatz. Als Nächstes folgt die Qualitätsmessung: Protokolle, Bewertung und Klassifizierung von Fehlern sowie ein nützliches Regressionssammlungsdatensatz. Erst wenn die Qualität zuverlässig gemessen werden kann, kommt die Erfahrungssammlung ins Spiel – mit Lernkandidaten, begrenztem Speicher, Aggregation von Beweismitteln, Verfallszeitkontrollen und verzögertem Feedback. Die kontrollierte Verbesserung ist die letzte Phase und umfasst Fehlerklustering, Generierung von Kandidaten, Wiederholungsbewertung, Schattenverkehr sowie schrittweise Einführung neuer Versionen.
Die Reihenfolge ist wichtig:
Reliability
↓
Observability
↓
Evaluation
↓
Learning
↓
Controlled adaptation
Bevor eine Bewertung stattfindet, zum Konzept des „Selbstlernens“ überzugehen, führt in der Regel zu einem System, das sich schneller verändert, als Ingenieure folgen können.
Das Ziel
Niemand sollte danach streben, einen Agenten zu schaffen, der sich selbst ändert. Ein besseres Ziel ist eine Plattform, die in der Lage ist, zu zeigen, wann ein Agent sich ändern sollte. Das Erinnern an frühere Gespräche reicht nicht aus, damit ein solcher Kreislauf Vertrauen verdient. Es bedarf einer disziplinierten Abfolge zwischen diesen Schritten:
production behavior
↓
evidence
↓
evaluation
↓
learning
↓
experimentation
↓
controlled production change
Genau auf dieser Kette beruht ein evidenzbasiertes, adaptives Agentensystem – und es ist die Architektur, die agierende KI benötigt, um von beeindruckenden Demonstrationen zu zuverlässigem Produktionssoftware zu werden.