Wie ich messe, ob ein KI-Agent wirklich funktioniert

Inhaltsverzeichnis

Aktualisiert Mai 2026.

TL;DR: Die meisten Operatoren überspringen Evaluierungen vollständig und setzen einfach voraus, dass ihre Agenten funktionieren. Mein Framework: ein Golden Set von 5–10 bekannten Eingaben mit erwarteten Ausgaben erstellen, Bestehen/Nicht-Bestehen-Kriterien in einfacher Sprache definieren und Logs wöchentlich stichprobenartig prüfen. Kein ausgeklügeltes Eval-System aufbauen, bevor man 10 echte Läufe hat — das ist die Falle, die den Schwung zerstört.

[Operator-Perspektive] Ich betreibe mehr als 30 produktive KI-Agenten für meine Beratungsmarke und Pickleland, eine Pickleball-Anlage in Pflugerville, TX. Irgendwann merkte ich, dass ich mehr Zeit damit verbrachte, mir Sorgen zu machen, ob Agenten abweichen, als sie tatsächlich zu nutzen. Das ist das Eval-Framework, auf das ich mich eingependelt habe — kein Doktorat erforderlich, keine benutzerdefinierte Eval-Plattform, kein Python.

Das Problem, über das niemand spricht: Agenten driften still ab

Wenn ein menschlicher Mitarbeiter anfängt, seinen Job falsch zu machen, bemerkt man das normalerweise. Wenn ein KI-Agent anfängt, Unsinn zu produzieren, produziert er weiter Unsinn — still, im großen Maßstab, bis etwas so schlimm bricht, dass ein Mensch es endlich bemerkt.

Ich hatte einen Content-Agenten, der nach einem Modell-Update anfing, Haftungsausschlüsse wie “Als KI-Sprachmodell” anzuhängen. Ich hatte einen Event-Promoter-Agenten, der aufhörte, Ticket-Links einzufügen, weil sich ein Prompt-Variablenname geändert hatte. Keiner versagte lautstark. Beide verschlechterten sich einfach.

Die Lösung ist kein NASA-Überwachungssystem. Es ist eine einfache, wiederholbare Prüfung, die Abweichungen erkennt, bevor sie sich häufen.

Was eine Evaluierung wirklich ist (für Operatoren)

Ingenieure verwenden das Wort “Eval” für das Ausführen eines Benchmarks auf einem Modell. Für Operatoren meine ich etwas Einfacheres: einen wiederholbaren Test, der dir sagt, ob dein Agent noch das tut, wofür du ihn gebaut hast.

Drei Komponenten:

1. Golden Set — 5–10 echte Eingaben, die du bereits gesehen hast, mit erwarteten Ausgaben, von denen du weißt, dass sie gut sind
2. Bestehen/Nicht-Bestehen-Kriterien — Regeln in einfacher Sprache, was als Bestehen gilt
3. Eine geplante Prüfung — du oder dein Assistent führt den Test tatsächlich in einem bestimmten Rhythmus aus

Das ist alles. Du brauchst kein Framework. Du brauchst Disziplin.

Dein Golden Set aufbauen

Ziehe aus deinen Produktions-Logs. Finde 5–10 echte Eingaben, bei denen du bereits weißt, wie eine gute Ausgabe aussieht. Das ist dein Ground Truth.

Für meinen Content-Pipeline-Agenten ist das Golden Set 5 veröffentlichte Beiträge, die meine Stimm-Checkliste bestanden haben, als ich sie manuell schrieb. Für meinen Pickleland-Event-Promoter sind es 5 vergangene Facebook-Posts mit überdurchschnittlichem Engagement (Kommentare + Shares, nicht nur Likes).

Regeln für ein gutes Golden Set:

• Echte Eingaben, keine Hypothesen, die du dir ausgedacht hast
• Mindestens einen Grenzfall einschließen (eine schwierige Eingabe, eine kurze, eine mit ungewöhnlicher Formatierung)
• Erwartete Ausgaben dokumentieren — Screenshot, Textdatei, Tabellenzeile
• Nie aus dem Golden Set löschen; nur hinzufügen

Wenn der Agent zuletzt bestätigt funktionierte, schreibe genau auf, wie “gut” aussah. Das wird deine erwartete Ausgabe.

Bestehen/Nicht-Bestehen-Kriterien definieren

Vage Kriterien sind nutzlos. “Die Ausgabe sollte gut sein” besteht immer, weil du es rationalisierst.

Schreibe deine Kriterien als Checklisten-Punkte, die ein Nicht-Experte bewerten könnte. Hier sind die tatsächlichen Kriterien, die ich für meinen Content-Pipeline-Agenten verwende:

Bestehen/Nicht-Bestehen-Checkliste für den Content-Agenten:

• Beitrag hat ein TL;DR in den ersten 100 Wörtern
• Keine Phrasen wie “in der heutigen schnelllebigen Welt” oder “Als KI”
• Mindestens eine konkrete Zahl oder Statistik
• Wortanzahl liegt zwischen 800 und 2000
• Alle internen Links lösen auf (keine 404-Fehler)

Für den Pickleland-Event-Promoter:

Bestehen/Nicht-Bestehen-Checkliste für den Event-Promoter:

• Veranstaltungsname stimmt mit dem Quellkalender überein
• Datum und Uhrzeit sind korrekt
• Ticket-Link ist vorhanden und nicht defekt
• Text ist unter 280 Wörtern
• Post verwendet keine generischen Füllphrasen

Wenn 4 von 5 Checklisten-Punkten bestehen, ist der Lauf ein Bestehen. Wenn 3 oder weniger bestehen, ist es ein Nicht-Bestehen und ich untersuche es vor dem nächsten Lauf.

Claude als Richter verwenden

Für Agenten mit langen oder komplexen Ausgaben verwende ich Claude Sonnet als automatisierten Richter. Das ist schneller als manuelle Überprüfung und erkennt Dinge, die ich überfliegen würde.

Hier ist der Richter-Prompt, den ich für den Content-Agenten verwende:

You are evaluating a blog post written by an AI agent. Your job is to check whether it meets the operator's standards.

Evaluate the following post against these criteria:
1. Starts with a direct answer or TL;DR in the first 100 words (YES/NO)
2. Contains at least one concrete number or specific example (YES/NO)
3. Free of AI-speak filler ("As an AI", "in today's fast-paced world", "delve", "it's worth noting") (YES/NO)
4. Word count is between 800 and 2000 words (YES/NO)
5. Tone matches the reference: direct, first-person, opinionated, no fluff (YES/NO)

For each criterion, respond YES or NO with one sentence of explanation.
At the end, output PASS if 4 or 5 criteria are YES, FAIL otherwise.

Post to evaluate:
---
{{post_content}}
---

Ich betreibe das als Cloudflare Worker, der den neuesten Entwurf abruft, diesen Prompt abfeuert und das Ergebnis in eine Google Sheet schreibt. Der gesamte Prozess dauert 8 Sekunden und kostet etwa $0,003 pro Lauf.

Für den Event-Promoter ist der Richter-Prompt einfacher:

You are checking an AI-generated Facebook event post for accuracy and quality.

Source data:
- Event name: {{event_name}}
- Date: {{event_date}}
- Time: {{event_time}}
- Ticket URL: {{ticket_url}}

Generated post:
---
{{generated_post}}
---

Check:
1. Does the post correctly state the event name? (YES/NO)
2. Does the post correctly state the date and time? (YES/NO)
3. Does the post include the exact ticket URL? (YES/NO)
4. Is the post under 280 words? (YES/NO)
5. Is the tone inviting without using generic filler phrases? (YES/NO)

Output PASS if all 5 are YES, FAIL if any are NO. List which items failed.

Wo man schaut: Cloudflare Worker Logs

Wenn du Agenten auf Cloudflare Workers betreibst (was ich für die meisten meiner leichtgewichtigen tue), ist der eingebaute Log Tail dein bester Freund. Du brauchst keinen Drittanbieter-Logging-Service, um anzufangen.

Was ich in wöchentlichen Stichproben prüfe:

• Fehler und Ausnahmen — alles, was abstürzte oder ein Timeout hatte
• Token-Anzahl — wenn ein Lauf plötzlich dreimal so viele Tokens verbraucht, hat sich etwas geändert
• Latenzschwankungen — eine plötzliche Verlangsamung bedeutet meist, dass der Prompt länger wurde oder das Modell Schwierigkeiten hat
• Ausgabelängen-Drift — wenn die durchschnittliche Ausgabe von 600 auf 200 Wörter sank, hat der Agent sein Verhalten geändert

Ich verbringe jeden Montagmorgen 15 Minuten damit. Ich habe eine einfache Checkliste in Notion: Logs für jeden Agenten öffnen, Anomalien notieren, Token-Nutzung mit der Basislinie der letzten Woche vergleichen. Das ist der gesamte Prozess.

Die Tabellen-Evaluierung: unelegant, aber es funktioniert

Bevor ich jegliche Automatisierung hatte, führte ich Evaluierungen in einer Google Sheet durch. Ich verwende das immer noch für neue Agenten in den ersten 4 Wochen.

Struktur:

Fünf Zeilen pro Woche. Dauert 10 Minuten. Bei zwei aufeinanderfolgenden Nicht-Bestehens stoppst du den Agenten und korrigierst den Prompt, bevor du weiter machst.

Das ist peinlich low-tech. So habe ich auch drei Prompt-Regressionen entdeckt, bevor sie in die Produktion gelangten.

Was man NICHT tun sollte

Kein Eval-System aufbauen, bevor man 10 echte Läufe hat. Ich habe Gründer gesehen, die zwei Wochen damit verbrachten, eine ausgefeilte Eval-Pipeline für einen Agenten aufzubauen, den sie nur zweimal betrieben hatten. Du weißt nicht genug darüber, wie “gut” aussieht, bis du echte Produktionsdaten hast.

Nicht mit synthetischen Eingaben evaluieren, die du dir ausgedacht hast. Synthetische Testfälle verpassen die seltsamen Grenzfälle, die die Produktion an dich wirft. Immer mit echten Logs beginnen.

Nicht alles evaluieren. Wähle die 3–5 Agenten, bei denen ein Versagen wirklich schmerzen würde — kundenorientierte Ausgaben, alles, was öffentlich postet, alles, das eine Zahlung auslöst. Interne Hilfsagenten überspringen, bis du Kapazität hast.

Nicht zu früh automatisieren. Eine Tabelle, die du tatsächlich nutzt, schlägt ein Datadog-Dashboard, das du vergisst zu prüfen. Manuell anfangen, automatisieren, nachdem du die Prüfung 10 Mal ausgeführt hast und weißt, wonach du wirklich suchst.

Das Fazit des Operators

Evaluierungen müssen keine technische Qualität haben, um nützlich zu sein. Ein Golden Set von 5–10 echten Eingaben, eine Checkliste mit Bestehen/Nicht-Bestehen-Kriterien und 15 Minuten Log-Prüfung jeden Montag werden 80% der Agenten-Drift erkennen, bevor sie sich häufen. Fang dort an. Wenn du immer noch Agenten ohne jegliche Evaluierung betreibst, fliegst du blind — und irgendwann wird etwas so öffentlich scheitern, dass du dir wünschst, du hättest die 20 Minuten investiert.