Bewertung des Agentenverhaltens: Ergebnisse, Entwicklungspfade und Produktionsfeedback
Wie man agierende Systeme jenseits der Endantwort beurteilt: LangChain, LangGraph und LangSmith den Rollen zuordnen, Leistungstrends sowie Kontext bewerten und Produktionsfehler in die Bewertungen einbeziehen.
Quellen: Building Better Agentic AI Systems: What I Learned About Deep Agents, LangSmith Engine & Evals
Mit den heutigen Modellen und Frameworks dauert es einen Nachmittag, um einen KI-Agenten in einer Demo zum Laufen zu bringen. Der schwierige Teil beginnt, wenn dieser Agent in einem echten Produkt eingesetzt wird: Er wählt das falsche Werkzeug, erhält unzureichenden Kontext, nimmt einen nicht geplanten Weg oder gibt eine scheinbar richtige, aber in Wirklichkeit falsche Antwort zurück. Dieser Artikel betrachtet den Entwicklungslebenszyklus, der solche Systeme zuverlässig macht, mit Schwerpunkt auf der Bewertung: Was muss gemessen werden, auf welcher Ebene und wie können alle Produktionsfehler in Prüfungen umgewandelt werden, die verhindern, dass sie erneut auftreten. Die Beispiele nutzen das LangChain-Ecosystem (LangChain, LangGraph, LangSmith und Deep Agents), doch die Konzepte gelten für jeden anderen Stack.
Von einem einzelnen LLM-Aufruf zu einem agilen System
Eine grundlegende Funktion eines LLMs ist leicht vorstellbar: Eine Anfrage wird eingegeben, es erfolgt ein Modellaufruf und anschließend kommt eine Antwort heraus.
User → Prompt → LLM → Response
Ein Agent ist etwas Besonderes. Gegeben ein Ziel kann er die Arbeit in Aufgaben aufteilen, Dokumente abrufen, APIs aufrufen, Tools ausführen, den Zustand speichern, einen Teil der Arbeit an einen anderen Agenten weitergeben, Zwischenergebnisse prüfen, von Fehlern wiederherstellen und anschließend seine nächste Aktion wählen. Eine vereinfachte Darstellung dieses Steuerflusses:
USER GOAL
│
▼
AGENT
│
PLAN
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
TOOLS MEMORY SUBAGENT
│ │ │
└──────────────┼──────────────┘
│
▼
DECIDE / ACT
│
More work needed?
↙ ↘
YES NO
│ │
└── LOOP ▼
RESULT
Beachten Sie die Schleife am Ende: Der Agent entscheidet ständig, ob weitere Arbeit erforderlich ist, und jede Iteration kann Tools, Speicher oder Subagenten betreffen. Zu diesem Zeitpunkt liefert man keine Modellantwort mehr, sondern führt ein System aus. Das ist für die Qualität wichtig, denn die endgültige Antwort ist nur so gut wie die Kette der Entscheidungen, die sie hervorgebracht haben. Ein korrektes Modell mit einem schlechten Abrufschritt oder ein guter Plan, der mit dem falschen Tool ausgeführt wird, ergeben dennoch ein schlechtes Ergebnis.
Rollen zuweisen: LangChain, LangGraph und LangSmith
Eine praktische Möglichkeit, die drei Hauptprodukte von LangChain auseinanderzuhalten, besteht darin, jedes mit der ingenieurtechnischen Frage zu verknüpfen, die es beantwortet.
- LangChain bietet Funktionen rund um das Modell: Modulintegrationen, Tools, Datenabruf sowie Verbindungen zu externen Datenquellen. Die zentrale Frage dabei ist: Was muss die Anwendung können, um zu funktionieren?
- LangGraph kümmert sich um die Orchestrierung, sobald Workflows agierend werden – mit Zuständen, bedingten Verzweigungen, Schleifen, Toolaufrufen, menschlichen Freigabeschritten sowie Koordination mehrerer Agenten. Die zentrale Frage lautet: Wie sollte der Workflow ablaufen?
- LangSmith befasst sich mit dem, was nach dem Go-Live des Systems geschieht: Welche Tools wurden aufgerufen, welchen Kontext hatte das Modell, wo trat Verzögerung auf, welche Schritt versagte, warum wurde eine Entscheidung getroffen – und ob die neue Version tatsächlich besser ist als die alte. Die zentrale Frage ist: Was ist wirklich passiert, und war es gut?
Wenn sie übereinander angeordnet sind, verläuft der Ablauf von einem Geschäftsziel über Kapazitäten und Orchestrierung bis zu einem Ergebnis, das anschließend beobachtet und bewertet wird, damit das Team daraus lernen kann.
BUSINESS GOAL
│
▼
LANGCHAIN
Models • Tools • Data
│
▼
LANGGRAPH
State • Flow • Decisions
│
▼
AGENT SYSTEM
│
▼
RESULT
│
▼
LANGSMITH
Observe • Trace • Eval
│
▼
LEARN
Der letzte Pfeil ist der wichtige. Die Beobachtung stellt keinen Endzustand dar; sie dient dem Lernen. Falls die Unterscheidung zwischen LangChain und LangGraph noch unklar ist, behandelt unser Vergleich von Chains und stateful Graphen dieses Thema ausführlich.
Verwendung von Agenten zur Verbesserung weiterer Agenten: LangSmith Engine
Die Protokollierung zeigt genau an, was ein Agent getan hat, doch ein einzelnes Protokoll allein löst nichts. Jemand muss es trotzdem lesen, herausfinden, was schiefgelaufen ist, prüfen, ob derselbe Fehler auch anderswo auftritt, die Ursache finden, das System ändern und bestätigen, dass dadurch nichts anderes beschädigt wurde. Das ist bei einer geringen Anzahl von Ausführungen noch handhabbar, doch bei Tausenden von Produktionsprotokollen völlig aussichtslos.
Die LangSmith Engine, eine neuere Funktion von LangSmith zum Zeitpunkt der Erstellung dieses Textes, setzt einen Agenten für diese Analyse ein. Sie durchsucht Produktionsprotokolle nach wiederkehrenden Mustern und Fehlern, gruppiert verwandte Probleme, hilft bei der Diagnose und schlägt Verbesserungen vor. Entscheidend ist, dass die von ihr gefundenen Fehler in die Bewertung einfließen können, sodass ein heute entdecktes Problem morgen einer expliziten Überprüfung unterzogen wird. Konzeptionell sieht der Ablauf wie folgt aus:
PRODUCTION AGENT
│
▼
TRACES
│
▼
LANGSMITH ENGINE
│
▼
Detect Patterns
│
▼
Diagnose Issues
│
▼
Suggest Improvement
│
▼
Add Evals
│
▼
Regression Testing
│
▼
Review / Deploy
│
└────────► Observe Again
Jede Phase verengt das Problem: Rohdaten werden zu Mustern, Muster zu Diagnosen, Diagnosen zu möglichen Lösungen, und diese werden durch weitere Bewertungen sowie Regressionstests geprüft, bevor sie von einem Menschen überprüft und eingesetzt werden. Anschließend beginnt der Kreislauf erneut mit neuen Rohdaten.
Der Wandel besteht darin, wie mit diesen Rohdaten umgegangen wird. Anstatt sie nur während eines Incidents zu nutzen, werden sie zur Rohstoffbasis für kontinuierliche Verbesserungen. Genau so funktioniert bereits die ausgereifte Qualitätsentwicklung in herkömmlichem Softwareentwicklungsprozess: Ein Produktionsfehler sollte nicht mit einem Patch enden, sondern mit einem Test, der verhindert, dass derselbe Fehlertyp erneut unbemerkt auftaucht. Automatisierte Diagnosen ersetzen jedoch nicht die Notwendigkeit einer Überprüfung. Vorgeschlagene Änderungen an Anweisungen oder Tool-Definitionen können Nebenwirkungen haben, weshalb die Überprüfungs- und Regressionsschritte weiterhin Bestandteil des Prozesses bleiben.
Tiefe Agenten für langfristige Aufgaben
Manche Anfragen beinhalten viel Arbeit. Betrachten wir eine solche Anfrage im Bereich Qualitätsmanagement. Bei einer neuen Produktanforderung muss der Agent die entsprechenden Dokumente durchsehen, die riskantesten Benutzerflüsse markieren, Testszenarien dafür entwerfen, in den Code eindringen, der diese Flüsse umsetzt, und seine Erkenntnisse festhalten.
Damit diese Aufgabe erledigt werden kann, muss ein Agent planen, Dateien lesen, Wissen abrufen, Tools aufrufen, gegebenenfalls Code ausführen, vorläufige Erkenntnisse speichern, spezialisierte Aufgaben delegieren und sich daran erinnern, was er bereits gelernt hat. Die Struktur dieser Arbeit:
Understand Goal
│
▼
Create Plan
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Read Files Use Tools Search Knowledge
│ │ │
└─────────────┼─────────────┘
│
Delegate Work
│
▼
SUBAGENTS
│
▼
Combine Findings
│
▼
RESULT
Deep Agents ist das Agentenframework von LangChain, das für diese Art von langfristiger Arbeit konzipiert ist. Es vereint Planung, Tools, Dateiverwaltung, Kontextmanagement, Fähigkeiten, Speicher und Unteragenten, sodass man diese Komponenten nicht einzeln zusammenstellen muss.
Das Interessante ist nicht darin, dass ein Agent mehr leisten kann, sondern wie die Autonomie strukturiert ist. Dem Agenten zwanzig Werkzeuge zur Verfügung zu stellen, macht ihn nicht besser – oft verschlechtert das sogar die Auswahl der Werkzeuge. Jede Aufgabe auf fünf Unteragenten aufzuteilen, verbessert die Architektur ebenfalls nicht automatisch, denn jeder Übergang kostet Token und kann den Kontext verlieren. Je leistungsfähiger die Bausteine werden, desto wichtiger sind die Entscheidungen bei ihrer Gestaltung. Eine nützliche Vorgehensweise ist es, einen Unteragenten nur hinzuzufügen, wenn eine Teilaufgabe einen isolierten Kontext oder ein anderes Werkzeugset benötigt, und die Liste der Werkzeuge für jeden Agenten so klein wie möglich zu halten, wie es die Aufgabe zulässt.
Der Betrieb von Agenten ist ein separates Problem: Gemanagte Deep Agents
Die Entwicklung eines leistungsfähigen Agents sowie sein zuverlässiges Betreiben in der Produktion sind zwei unterschiedliche ingenieurtechnische Aufgaben. Ein langlaufender Agent muss in der Lage sein, Unterbrechungen zu überstehen, seinen Zustand beizubehalten, mit Dateien zu arbeiten, Code sicher auszuführen, Fortschritte an die Benutzeroberfläche zu übertragen, Speicherinhalte zu speichern und ausreichend Telemetriedaten bereitzustellen, damit Ingenieure rekonstruieren können, was geschehen ist.
Managed Deep Agents, ein gehostetes Angebot im selben Ökosystem zum Zeitpunkt der Erstellung dieses Textes, richtet sich an diese operative Ebene. Das Verhältnis zwischen den beiden lässt sich als Verhalten obenauf und Infrastruktur für die Laufzeit darunter beschreiben:
DEEP AGENT
Planning • Tools • Files • Subagents
│
▼
Agent Behavior
│
▼
MANAGED DEEP AGENTS Durable Execution
Persistence
Sandboxes
Memory
Streaming
Identity
Tracing / Evaluation
Der Agent definiert sein Verhalten durch Planung, Werkzeuge, Dateien und Subagenten. Die verwaltete Schicht bietet zuverlässige Ausführung, Persistenz, Sandboxes, Speicher, Streaming, Identitätsmanagement sowie Tracing inklusive Bewertungsfunktionen. Die allgemeine Erkenntnis gilt unabhängig davon, ob man einen verwalteten Service nutzt oder etwas selbst betreibt: Intelligenzmodelle sind ein Bestandteil einer produktiven KI-Architektur, und die darum herumliegende Infrastruktur verdient gleiche Aufmerksamkeit. Unser Vergleich von Runtime-Harnesses und komponierten Frameworks untersucht den Kompromiss zwischen Eigenentwicklung und Nutzung vorhandener Lösungen.
Warum Agenten das traditionelle Testing untergraben
Das herkömmliche Testing basiert auf Determinismus. Man gibt einer Funktion eine bekannte Eingabe, erhält eine Ausgabe und überprüft diese.
Input → Function → Output → Assertion
Wenn man eine API mit einer festgelegten Anfrage aufruft, kann man den Statuscode, das Antwortschema, die Payload, die Header sowie die Geschäftsregeln überprüfen. Agenten passen nicht in dieses Muster. Bitten Sie einen Agenten, ein Produktionsproblem zu untersuchen und die wahrscheinliche Ursache herauszufinden. Mal liest er zunächst die Logs und fragt anschließend eine Datenbank ab; ein anderes Mal prüft er die Dokumentation, ruft eine API auf und liest erst danach die Logs. Die Vorgehensweisen unterscheiden sich, doch beide können zu einer fundierten Schlussfolgerung gelangen.
Auch das Umgekehrte ist möglich – und gefährlicher: Eine scheinbar richtige Endlösung, obwohl der Agent sich auf eine unzuverlässige Quelle verlassen hat, ein ungeeignetes Werkzeug verwendet hat oder aus falschen Gründen zur richtigen Schlussfolgerung gelangt ist. Eine präzise Abgleichsprüfung der Ausgabe kann diese Fälle nicht unterscheiden. Genau das füllen die Evaluierungen aus.
Was eine Evaluation misst
Eine praktikable Definition: Eine Bewertung misst, wie gut ein KI-System im Vergleich zu den für eine bestimmte Aufgabe wichtigen Standards abgeschnitten hat. Die Kriterien stammen von der Aufgabe selbst, nicht vom Framework.
Nehmen wir einen Agenten, der aus einer Anforderung Testszenarien erzeugt. Dass er zehn Testfälle in validem JSON zurückgegeben hat, sagt fast nichts aus. Die aussagekräftigen Informationen beziehen sich auf die Qualität:
GENERATED TESTS
│
▼
EVALUATE
│
┌────────────────┼────────────────┐
│ │ │
Coverage Correctness Relevance
│ │ │
├──────── Hallucination ──────────┤
│ │
└──────────── Duplication ─────────┘
│
▼
QUALITY SIGNAL
In der Praxis werden diese Aspekte zu konkreten Fragen:
- Umfassen die Tests tatsächlich die Anforderung?
- Ist jeder Testfall dazu relevant?
- Hat der Agent Verhaltensweisen erfunden, die das Produkt nicht hat?
- Wurde ein wichtiges negatives oder Randfallszenario übersprungen?
- Sind mehrere der zehn Testfälle im Grunde Duplikate?
Jede Frage kann zu einem Bewertungskriterium werden: Einige sind deterministisch (Erkennung von Duplikaten durch normalisierten Text oder Embeddings), andere benötigen ein Referenzdatensatz (Überprüfung gegen bekannte Anforderungen), und wieder andere erfordern in der Regel einen LLM als Urteilsinstanz oder menschliche Etiketten (halluzinierte Funktionalitäten). Strukturelle Überprüfungen wie die Gültigkeit des Schemas sind weiterhin sinnvoll, doch eher als Grundlage denn als Definition für Erfolg.
Drei Bewertungsebenen: Antwort, Schritt und Verlauf
Mit Agenten muss man nicht nur die endgültige Ausgabe bewerten. Es gibt mindestens drei nützliche Bewertungskriterien:
- Die endgültige Antwort: Ist die Antwort korrekt, vollständig und relevant?
- Ein einzelner Schritt: Hat der Agent beispielsweise das richtige Werkzeug für dieses Teilproblem mit vernünftigen Argumenten gewählt?
Hier ist eine typische Bahn für einen Frage-Antwort-Agenten:
User Goal
│
▼
Agent
│
├── Search Documentation
│
├── Query Database
│
├── Call API
│
└── Generate Answer
Die endgültige Antwort ist lediglich der letzte Knoten. Für viele Anwendungen spielt der Weg genauso eine Rolle wie das Ziel – beispielsweise ob der Agent vor dem Abfragen von Produktionsdaten Dokumentation konsultiert hat oder ob er eine API-Aufruf vorgenommen hat, den es nicht zu tätigen gab. Die Bewertung der Handlungsabläufe wird unerlässlich, sobald Agenten Daten ändern, Tickets erstellen, Code ausführen, Workflows auslösen oder innerhalb von Unternehmenssystemen agieren können, denn eine schädliche Zwischenschritt ist bereits ein Versagen, selbst wenn die endgültige Nachricht gut aussieht. Die Überprüfung der Handlungsabläufe kann streng sein (genaue erwartete Abfolge), nachsichtig (erforderliche Schritte in beliebiger Reihenfolge, verbotene Schritte fehlen) oder durch ein Modell bewertet werden; angesichts der oben beschriebenen Abweichungen im Weg sind nachsichtige Überprüfungen in der Regel der richtige Ausgangspunkt.
Offline- und Online-Bewertungen als ein einziger Zyklus
Die Bewertung lässt sich natürlicherweise in zwei Modi aufteilen, die mit bekannten Softwarepraktiken übereinstimmen.
Offline: Freigabe bei bekannten Fällen
Vor der Freigabe wird eine Offline-Bewertung anhand sorgfältig ausgewählter Datensätze und Szenarien durchgeführt. Dabei werden repräsentative Fälle mit der zu prüfenden Agentenversion abgewickelt, bewertet und mit der aktuellen Version verglichen, um zu entscheiden, ob sie veröffentlicht werden soll.
Known Dataset
│
▼
Agent Version
│
▼
Run Evals
│
▼
Compare Results
│
▼
Release Decision
Das ist die Agentenäquivalente zu einem Regressionstest in CI-Prozessen. Da die Modellausgaben bei verschiedenen Durchläufen variieren, hilft es, jeden Fall mehrmals auszuführen und die Verteilungen der Bewertungsergebnisse statt einzelner Ergebnisse miteinander zu vergleichen.
Online: Lernen aus echtem Verkehr
Durch die Online-Bewertung werden die Abläufe in der Produktion bewertet – und genau dort treten die Überraschungen auf. Nutzer stellen Fragen, die niemand vorhergesehen hat, externe Tools versagen, der Kontext ist unvollständig, die Daten ändern sich unterwegs und Agenten folgen Pfaden, die in keinem Datensatz enthalten sind. Die Bewertung einer Stichprobe aus Live-Spuren bringt solche Fälle ans Licht.
Der Kreis schließt sich
Die beiden Modi werden bei Verbindung weitaus wertvoller: Jeder bedeutende Produktionsfehler, der online gefunden wird, wird dem Offline-Datensatz hinzugefügt, sodass die nächste Version dagegen getestet werden kann.
OFFLINE EVALS
│
▼
BUILD
│
▼
DEPLOY
│
▼
PRODUCTION TRACES
│
▼
ONLINE EVALS
│
▼
DISCOVER FAILURE
│
▼
ADD FAILURE TO DATASET
│
└────────► OFFLINE EVALS
Im Laufe der Zeit spiegelt das Offline-Toolset nicht mehr wider, was das Team von den Nutzern erwartet, sondern vielmehr, was sie tatsächlich tun. Seien Sie bei der Übernahme von Produktionsdaten in Datensätze auf Privatsphäre bedacht; entfernen oder synthetisieren Sie sensible Felder, bevor sie zu dauerhaften Testdaten werden.
Verhalten von Agenten als neue Qualitätsdimension
Nichts davon ersetzt die traditionelle Testung. UI-, API-, Integrationstests, Datenvalidierung sowie Tests zur Leistung und Sicherheit bleiben für jedes zuverlässige Produkt notwendig. Agentenbasierte Systeme fügen eine weitere Ebene hinzu: die Qualität des Verhaltens der Agenten. Diese Ebene wirft eigene Fragen auf:
- War das von ihm ausgewählte Tool das Richtige?
Als Modell strukturiert, unterscheiden sich diese Fragen stark von der klassischen Testpyramide:
AGENT QUALITY
│
┌─────────────────┼─────────────────┐
│ │ │
OUTCOME TRAJECTORY CONTEXT
QUALITY QUALITY QUALITY
│ │ │
▼ ▼ ▼
Correctness Tool Usage Groundedness
Relevance Decisions Relevance
Completeness Efficiency Freshness
│
┌────────┴────────┐
│ │
MEMORY RECOVERY
│ │
▼ ▼
Accuracy Failure Handling
Relevance Retry Behavior
Die Qualität des Ergebnisses umfasst Richtigkeit, Relevanz und Vollständigkeit. Die Qualität der Vorgehensweise beinhaltet die Nutzung von Werkzeugen, getroffene Entscheidungen sowie Effizienz und gliedert sich in Aspekte der Speicherung (Genauigkeit und Relevanz dessen, was abgerufen wird) sowie der Fehlerbehandlung (Umgang mit Fehlern und Verhalten bei erneuten Versuchen). Die Qualität des Kontexts umfasst Grundlage, Relevanz und Aktualität. Jeder „Leaf“ kann mit einem oder mehreren Bewertungskriterien verknüpft werden, wodurch insgesamt ein viel umfassenderes Bild entsteht als eine einfache Bestätigung oder Ablehnung der Endantwort. Die Umsetzung dieser Ansätze erfordert neue Vorgehensweisen im Bereich des Agententests, der Überwachbarkeit, der Bewertung von Vorgehensweisen, von Regressionstests für KI-Systeme, der Bewertung in der Produktion sowie kontinuierlicher Verbesserungen – hier überschneiden sich die Aufgabenbereiche von Qualitätsingenieuren und KI-Ingeneuren zunehmend. Zum sicheren Aspekt desselben Problems siehe unseren Leitfaden zu LangChain-Schutzmechanismen und Middleware.
Praktische Änderungen für Ihre eigenen Agentenprojekte
Die Lektion aus all dem ist, nicht jede neue Funktion zu übernehmen. Es geht eher um das Gegenteil: Bei der Architektur bewusster vorgehen.
- Definieren Sie Bewertungskriterien bereits bei der Gestaltung des Agenten, nicht erst nach seiner Veröffentlichung.
- Betrachten Sie die Beobachtbarkeit als Teil der ursprünglichen Architektur und nicht als später hinzugefügten Bestandteil.
- Leiten Sie Produktionsprotokolle als Feedback an die Entwicklungsabteilung weiter, nicht nur als Beweismittel bei Vorfällen.
- Sorgen Sie dafür, dass jeder bedeutende Produktionsfehler in einer zukünftigen Bewertung berücksichtigt wird.
- Passen Sie die Komplexität dem Problem an. Manchmal reicht ein einfacher Agent aus; manchmal ist eine LangGraph-Orchestrierung gerechtfertigt; manchmal profitiert eine Aufgabe tatsächlich von Subagenten, persistenter Kontextverwaltung oder einem vollständigen Agentenframework.
Die Technologie sollte dem Problem folgen, niemals umgekehrt.
Der Verbesserungskreislauf
Frameworks kommen und gehen; die dauerhafte Idee ist ein Zyklus.
LEARN
│
▼
BUILD
│
▼
OBSERVE
│
▼
EVALUATE
│
▼
IMPROVE
│
└──────────► LEARN AGAIN
Man lernt ein Konzept und baut damit. Das Bauen macht sichtbar, was man nicht verstanden hat. Das Ausführen zeigt Probleme auf, die man nicht vorhergesehen hat. Die Bewertung ersetzt Annahmen durch Beweise, Beweise fördern die Verbesserung, und Verbesserungen zeigen in der Regel das Nächste auf, was man lernen muss.
Kernpunkte
- Ein Agent ist ein System von Entscheidungen; beurteile die Entscheidungen, nicht nur den endgültigen Text.
- Gib jedem Tool eine klare Aufgabe: LangChain für Funktionen, LangGraph für Orchestrierung, LangSmith für Beobachtung und Bewertung.
- Bewerte auf drei Ebenen – Antwort, Schritt und Entwicklungspfad – und bevorzuge bei variablen gültigen Pfaden nachsichtige Prüfungen des Entwicklungspfads.
- Vereine Online- und Offline-Bewertungen, damit Produktionsfehler zu Regressionsfällen werden.
Modelle, Frameworks und gehostete Produkte in diesem Bereich ändern sich schnell, daher sollten Sie die aktuelle Dokumentation zu Funktionen wie der LangSmith Engine und den Managed Deep Agents prüfen. Die Disziplin, zu beobachten, zu messen und die Erkenntnisse wieder in das System einzubringen, sorgt dafür, dass Ihre Agenten auch bei ständigen Veränderungen weiterhin vertrauenswürdig bleiben.