Agent-Eval in 60 Minuten, wie Du herausfindest ob Dein Agent gut ist

Das groesste blinde Flecken-Thema bei Solo-Foundern die ihren ersten Agent gebaut haben: keiner weiss ob das Ding eigentlich gut ist. Du tippst ein paar Prompts ein, der Agent liefert was, sieht ok aus, fertig. Und dann aenderst Du den System-Prompt und es ist immer noch ok. Und dann zwei Wochen spaeter merkst Du dass irgendwo dazwischen die Qualitaet abgesackt ist. Aber wann? Bei welcher Anderung?

Genau da setzt Agent-Eval an. Du baust Dir einen kleinen Test-Set mit Inputs und einer Erwartung. Bei jeder Anderung läuft das durch und Du siehst eine Pass-Rate. Wenn die runtergeht weisst Du sofort dass Du was kaputt gemacht hast.

In den naechsten 60 Minuten baust Du genau das. Kein Framework, keine teure Tool-Subscription, einfach 20 Test-Cases und ein Skript das die durchlaufen lässt. Reicht für 80 Prozent der Use-Cases.

1. Den Agent festlegen den Du evaluieren willst

Such Dir den Agent aus den Du am haeufigsten benutzt. Nicht den coolsten, den meistgenutzten. Wenn Du den vor zwei Wochen aus dem Sub-Agent-Playbook gebaut hast und der jeden Tag läuft, dann ist das Dein Kandidat.

Schreib drei Saetze zur Aufgabe auf. Was ist der Input, was ist der Output, woran erkennst Du dass der Output gut ist. Beispiel: "Input ist eine Bug-Beschreibung in Klartext. Output ist ein GitHub-Issue-Titel mit unter 80 Zeichen plus drei Labels aus einer festen Liste. Gut heisst: Titel beschreibt das Problem in Aktiv-Form, Labels sind alle aus der Liste, kein erfundenes Label."

Diese drei Saetze sind die Spec. Ohne die kannst Du nicht evaluieren. Mit ihr ist alles was kommt nur noch Mechanik.

2. Die Eval-Set-Datei anlegen

Mach Dir im Projekt einen Ordner evals/ und drin eine Datei cases.json. Format ist eine Liste von Objekten, jedes Objekt ist ein Test-Case mit input und expected und einer id.

[
  {
    "id": "001-simple-bug",
    "input": "Login klappt nicht mit Sonderzeichen im Passwort",
    "expected": {
      "title_max_chars": 80,
      "title_must_contain": ["login", "passwort"],
      "labels_subset_of": ["bug", "auth", "ux", "security"]
    }
  }
]

expected ist keine exakte Output-Erwartung sondern eine Liste von Bedingungen die der Output erfuellen muss. Das ist wichtig. Eine exakte String-Erwartung wuerde nie pass-en weil LLM-Output variiert. Du willst Bedingungen die robust sind.

3. Mindestens zwanzig Test-Cases sammeln

Zwanzig ist die magische Zahl. Unter zehn ist Statistik-Quatsch, ueber fuenfzig fluffst Du nur die Wartung auf. Zwanzig Cases die echte Use-Cases abdecken plus zwei oder drei haessliche Edge-Cases, das ist der Sweet Spot.

Sammel die nicht aus dem Kopf. Geh in Deinen Chat-Verlauf, in Logs, in echte Tickets. Echte Inputs sind Gold. Erfundene Inputs sind oft zu sauber und decken Edge-Cases nicht ab. Wenn Du den Agent zwei Wochen benutzt hast hast Du schon zwanzig echte Inputs irgendwo rumliegen.

Markier die mindestens drei davon explizit als "war damals schwierig" oder "hat damals nicht funktioniert". Diese Cases sind Deine Regression-Tests. Wenn die wieder rausfallen weisst Du dass eine Anderung was kaputt gemacht hat.

4. Eine Check-Funktion pro Bedingung schreiben

Pro Erwartungs-Typ eine kleine Funktion die einen Bool zurueckgibt. Zum Beispiel title_max_chars checkt ob der Titel kuerzer ist als die erlaubte Zahl. labels_subset_of checkt ob alle ausgewaehlten Labels in der erlaubten Liste stehen. must_contain checkt ob bestimmte Stichwoerter im Output sind.

Halt das simpel. JavaScript, Python, was auch immer Du sowieso schreibst. Vier oder fuenf solche Mini-Funktionen reichen für den Anfang.

function checkTitleMaxChars(output, max) {
  return output.title.length <= max
}

function checkLabelsSubsetOf(output, allowed) {
  return output.labels.every(l => allowed.includes(l))
}

Wichtig: Eine Funktion macht genau eine Sache. Nicht "checkAll" mit zehn Conditionals drin. Sonst kannst Du spaeter nicht sagen welche Bedingung gefailt ist.

5. Das Runner-Skript bauen

Eine Schleife ueber die Cases. Pro Case rufst Du den Agent auf, kriegst den Output, lässt die Check-Funktionen drueber laufen, sammelst pro Case ein Pass oder Fail.

const cases = JSON.parse(fs.readFileSync('evals/cases.json'))
const results = []
for (const c of cases) {
  const output = await callAgent(c.input)
  const checks = runChecks(output, c.expected)
  results.push({
    id: c.id,
    pass: checks.every(c => c.passed),
    failed: checks.filter(c => !c.passed).map(c => c.name)
  })
}
console.log(`Pass-Rate: ${results.filter(r => r.pass).length}/${results.length}`)

Das Skript ist absichtlich dumm. Keine Parallelisierung, kein Caching, keine Retry-Logik. Du willst sehen ob Dein Agent gut ist, nicht den Runner optimieren. Wenn die zwanzig Cases zwei Minuten brauchen ist das absolut ok.

6. Den ersten Lauf machen und die Pass-Rate notieren

Lauf das Skript einmal mit dem aktuellen Agent. Notier Dir die Pass-Rate. Vermutlich nicht 20 von 20. Wenn doch, sind Deine Eval-Cases zu lasch.

Bei zwoelf von zwanzig liegt typischerweise ein Solo-Agent. Das ist nicht schlimm. Das ist Deine Baseline. Ab jetzt ist alles besser-machen oder schlechter-machen.

Schreib die Pass-Rate in eine Datei evals/baseline.txt mit Datum und kurzem Kommentar dazu. "2026-04-30: 12/20, gefailt sind hauptsaechlich die Cases mit unklarem Input." Dieser Kommentar ist Gold wenn Du in zwei Wochen wissen willst was damals nicht klappte.

7. Eine kleine Anderung am System-Prompt machen

Aender genau eine Sache. Zum Beispiel: in den System-Prompt schreibst Du einen Satz dazu wie der Agent mit unklarem Input umgehen soll. Nicht zehn Aenderungen gleichzeitig. Eine.

Lauf den Eval nochmal. Pass-Rate notieren. Wenn die hochgeht, super, Anderung behalten. Wenn die runtergeht, revertieren. Wenn sie gleich bleibt: vielleicht hilft die Anderung in echten Use-Cases trotzdem, aber Du hast keine Eval-Evidenz dass sie was bringt.

Das ist der Kern vom ganzen Eval-Pattern: Du machst die Anderung dass das Eval besser wird und nicht weil Dein Bauchgefuehl sagt es waere besser. Bauchgefuehl luegt, Eval-Pass-Rate luegt schwerer.

8. LLM-as-Judge für schwammige Bedingungen

Manche Bedingungen kannst Du nicht hart prüfen. "Der Titel klingt natürlich" ist so ein Beispiel. Da rufst Du ein zweites LLM auf, gibst ihm den Output und die Bedingung, und lässt es ein Pass oder Fail mit Begruendung zurueckgeben.

async function llmJudge(output, criterion) {
  const prompt = `
Output: ${output}
Criterion: ${criterion}
Antworte mit PASS oder FAIL und einem Satz Begruendung.
`
  const judgment = await callJudgeLLM(prompt)
  return judgment.startsWith('PASS')
}

Wichtig: Das Judge-LLM ist nicht der gleiche Agent den Du evaluierst. Sonst macht der sich selbst alles schoen. Nimm ein anderes Modell, idealerweise ein guenstiges weil das hundert Mal pro Run läuft. Haiku oder Gemini Flash sind gute Judges für solche Aufgaben.

LLM-as-Judge ist nicht perfekt. Rechne damit dass das Judge-Urteil ungefaehr 80 Prozent korrekt ist. Für einen Trend reicht das, für harte Compliance-Entscheidungen nicht.

9. Den Eval in Deinen Aenderungs-Workflow einbauen

Ab jetzt: jedes Mal wenn Du am Agent rumschraubst, läuft der Eval davor und danach. Du committest nicht eine Anderung ohne dass Du die Pass-Rate kennst. Wenn Du Git benutzt, schreibst Du die Pass-Rate in die Commit-Message. "Pass: 15/20 (war 14/20)".

Das hat einen psychologischen Effekt der nicht zu unterschaetzen ist: Du hoerst auf am Agent rumzubasteln wenn er auf 18/20 ist. Du machst nicht mehr "ich verbesser das mal noch ein bisschen" und schiesst dabei was kaputt. Die Pass-Rate ist Dein Stop-Signal.

10. Die Cases waxsen lassen wenn Dich was uberrascht

Wenn der Agent in echt Mist baut den der Eval nicht erkennt, dann ist Dein Eval die Luecke. Pack den Mist als neuen Case rein. Mit der Zeit wird der Eval-Set robust und faengt 90 Prozent der Probleme bevor sie in Production landen.

Das ist die wichtigste Regel: der Eval-Set ist lebendig. Er waechst mit dem Agent. Cases die nichts mehr testen rausschmeissen, neue rein, und einmal pro Quartal prüfen ob die alten Cases noch zur aktuellen Aufgabe passen.

Was als naechstes

Wenn Du den Eval einmal hast, ist der naechste Schritt Multi-Modell-Vergleich. Lass die gleichen zwanzig Cases gegen Sonnet, Haiku, Gemini Flash und GPT-5-mini laufen. Du wirst uberrascht sein wie unterschiedlich die Pass-Rates sind und wie oft das billigste Modell gar nicht so viel schlechter ist als das teuerste. Dafuer haben wir Lesson 1.5 "Modelle vergleichen" und Recipe 5.x "Modell-Routing nach Pass-Rate". Schau Dir auch das Playbook "Hooks gegen Halluzinationen" an wenn Du die Eval-Cases auf Robustheit prüfen willst.

Source

• Anthropic Cookbook: Evaluations Patterns, github.com/anthropics/anthropic-cookbook (Abschnitt evaluation/)
• Promptfoo Docs: promptfoo.dev/docs (offene Quelle, MIT-Lizenz, gut für eigene Eval-Setups)
• Inspect (UK AISI): inspect.ai-safety-institute.org.uk/docs (Open-Source-Eval-Framework, Python)