Die besten Tools für die AI-Agent-Evaluation: Phoenix, LangSmith, DeepEval

Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Kein Tool für die Agent-Evaluation kann ein gutes Testdesign ersetzen. Beginnen Sie mit den Fehlern, die das Produkt erkennen muss: eine falsche endgültige Antwort, eine schlechte Tool-Auswahl, ungültige Argumente, einen unsicheren Seiteneffekt, eine ineffiziente Trajectory oder eine Regression bei Latency und Kosten. Wählen Sie anschließend das Tool danach aus, wo diese Tests ausgeführt werden müssen.

Verwenden Sie Phoenix, wenn Open Tracing und Self-Hosting wichtig sind. Verwenden Sie LangSmith, wenn Datasets, Traces, Annotation und Experimente in einem verwalteten Workflow zusammengeführt werden sollen. Verwenden Sie DeepEval, wenn die Evaluation wie Tests in einer Python-CI-Pipeline aussehen muss. Ergänzen Sie Promptfoo für eine lokale CLI, Matrix-Tests und Red-Team-Fälle.

Zuletzt geprüft: 10.08.2026. Der Vergleich gewichtet Trace-Tiefe, Trajectory- und Final-Response-Evaluation, Dataset-Workflow, CI-Ergonomie, Self-Hosting und Provider-Portabilität.

Entscheidungstabelle

BedarfBester AusgangspunktWarum
OpenTelemetry Traces und Self-HostingPhoenixOpen-Source-Tracing, Evaluations, Datasets und Experimente verwenden OpenTelemetry- und OpenInference-Konventionen.
Verwaltete Traces, Datasets und ReviewsLangSmithEs evaluiert Trajectories und Final Responses und kann mit Agents außerhalb von LangChain arbeiten.
Python-Tests und CI GatesDeepEvalEnd-to-End- und komponentenbasierte Agent-Evaluation passen zu einem testorientierten Workflow.
Lokale Matrix-Tests und Red TeamingPromptfooDie Open-Source-CLI und -Library führen wiederholbare Evaluations und Security-Fälle in der CI aus.
Produktspezifische Policy- oder Tool-ChecksBenutzerdefinierte EvaluatorsGenerische Judges kennen Ihre Berechtigungen, irreversiblen Aktionen, Budgets oder Business-Invarianten nicht.

Trajectory und Ergebnis evaluieren

Eine korrekte endgültige Antwort kann einen fehlerhaften Pfad verbergen. Ein Agent kann das falsche Tool aufrufen, unnötige Retries ausführen, sensible Argumente offenlegen oder ohne Belege zu einer plausiblen Antwort gelangen. Umgekehrt sollte eine andere, aber gültige Tool-Sequenz nicht allein deshalb fehlschlagen, weil sie von einem Golden Trace abweicht.

Führen Sie separate Checks durch für:

  • die Korrektheit der endgültigen Antwort und die Unterstützung durch Belege
  • die Tool-Auswahl und die Gültigkeit der Argumente
  • erforderliche, verbotene oder wiederholte Aktionen
  • Policy-Entscheidungen und Freigabegrenzen
  • die Effizienz der Trajectory, Latency und Kosten
  • die Wiederherstellung nach Tool-Fehlern oder Teilergebnissen

Verwenden Sie nach Möglichkeit deterministische Assertions. Setzen Sie Model Judges für semantische Fragen ein, kalibrieren Sie sie anhand geprüfter Beispiele und speichern Sie Model und Prompt des Judges mit jedem Ergebnis.

Ein praktischer erster Stack

  1. Instrumentieren Sie das Harness mit stabilen Feldern für Traces und Tool Calls.
  2. Machen Sie aus Fehlern in Production ein kleines Regression-Dataset.
  3. Ergänzen Sie deterministische Checks für Schemas, verbotene Aktionen, Budgets und erforderliche Belege.
  4. Ergänzen Sie einen kalibrierten semantischen Judge für Ergebnisse, die sich nicht mit Regeln bewerten lassen.
  5. Führen Sie schnelle Fälle bei jeder Änderung und eine umfassendere Suite vor dem Release aus.
  6. Sampeln Sie Production Traces auf neue Fehlermuster und übernehmen Sie diese als Tests.

Weiterführende Lektüre

Referenzen