Agent Evals & SWE-bench Benchmarking

1. Überblick über das Konzept und das Systemproblem

Die größte Gefahr bei der Entwicklung von Agentensystemen im Jahr 2026 ist die sogenannte „Behavioral Regression“:

• Sie ändern einen einzigen Satz im System-Prompt, damit der Agent Markdown besser formatiert, aber plötzlich stellt er fest, dass er das Datei-Lese-Tool nicht mehr aufruft.
• Sie wechseln vom Modell v1.2 zu v1.3, und der Agent beginnt doppelt so viele fehlerhafte Shell-Befehle auszuführen.
• Ohne automatisierte Tests verwandeln sich Agent-Projekte in „Schamanismus“, bei dem Entwickler die Qualität des Systems mit zwei bis drei manuellen Anfragen im Chat prüfen.

Agent Evals sind eine ingenieurwissenschaftliche Disziplin, die klassische TDD- und CI/CD-Prinzipien in die Welt der nicht-deterministischen Sprach-Agenten überträgt. Sie ermöglicht die quantitative Messung der Erfolgsquote (Pass Rate), der Kosten pro Aufgabe (Cost per Task) und der Latenzzeit (Latency).

2. Architektonische Taxonomie und mentales Modell

┌─────────────────────────────────────────────────────────────┐
│                 AGENT EVALUATION TAXONOMY                   │
├─────────────────────────────────────────────────────────────┤
│ 1. State-Based Evals (Кінцевий стан середовища):            │
│    • Unit / Integration Tests Pass (pytest, vitest == 0)    │
│    • File System Diff Verification (чи створено потрібні)   │
├─────────────────────────────────────────────────────────────┤
│ 2. Trajectory-Based Evals (Оцінка траєкторії думок):        │
│    • Tool Call Accuracy (чи викликано правильний тул)       │
│    • Step Efficiency (за скільки кроків досягнуто мету)     │
│    • Redundant Action Penalty (штрафи за повтори)           │
├─────────────────────────────────────────────────────────────┤
│ 3. LLM-as-a-Judge Evals (Семантична перевірка суддею):      │
│    • Response Tone & Adherence to Style Guides              │
│    • Completeness & Safety Compliance                       │
├─────────────────────────────────────────────────────────────┤
│ 4. Resource & Economic Evals:                               │
│    • Token Burn Rate per Resolved Issue                     │
│    • Wall-Clock Execution Time                              │
└─────────────────────────────────────────────────────────────┘

3. Technischer Pipeline und interne Mechanik

Ein typisches Framework zur Bewertung von Agenten (z. B. Inspect AI, Braintrust oder ein eigenes Docker Harness) arbeitet nach folgendem Zyklus:

1. Test Environment Reset: Start eines isolierten Docker-Containers mit dem initialen Commit des Codebases, in dem das Problem noch vorhanden ist.
2. Task Provisioning: Dem Agenten wird ausschließlich die Fehlerbeschreibung (issue.md) übermittelt.
3. Agent Trajectory Recording: Der Agent führt Befehle aus, liest Dateien und nimmt Änderungen vor. Alle Schritte werden im OpenTelemetry-/JSONL-Format aufgezeichnet (Aktions-Trajektorie).
4. Harness Evaluation:
   • Der Orchestrator extrahiert den generierten git diff.
   • Versteckte Verifikationstests (Fail-to-Pass-Tests) werden ausgeführt.
   • Der Status wird protokolliert: RESOLVED, FAILED, TIMEOUT oder OUT_OF_BUDGET.
5. Metric Aggregation: Berechnung des Gesamtprozentsatzes gelöster Aufgaben (Resolve Rate) für den Release des Agenten.

4. Praktische Engineering-Szenarien im Produktionsumfeld

01. CI/CD-Gate für Updates von Agent-Prompts

Vor dem Merge von Änderungen an der .cursorrules-Datei oder dem System-Prompt im Repository wird eine GitHub Action mit 30 synthetischen Tests ausgelöst. Wenn der Agent weniger als 90 % der Aufgaben löst, wird der Pull Request automatisch blockiert.

02. Auswahl des Modellanbieters nach ROI-Kriterien

Das Team bewertet: Lohnt es sich, $15 pro Million Tokens für ein Top-Modell zu zahlen, oder reicht ein neues Open-Source-Modell für $0,50? Die Durchführung von Evals auf den eigenen 100 Aufgaben liefert präzise Zahlen: Das Top-Modell löst 78 % der Aufgaben, das günstige Modell 74 %, kostet aber nur ein Zwanzigstel.

5. Fallstricke, häufige Fehler und Sicherheit

• Contamination (Verunreinigung des Trainingsdatensatzes): Öffentliche Benchmarks (wie der Basis-HumanEval) landen in den Trainingsdaten neuer Modelle, wodurch das Modell die richtige Antwort „auswendig lernt“, aber nicht logisch schlussfolgern kann. Verwenden Sie ausschließlich eigene geschlossene Evals oder SWE-bench Verified mit kontinuierlich aktualisierten Aufgaben.
• Flaky Evals (Instabile Tests): Die Nicht-Determiniertheit der Modelltemperatur kann zu einer Erfolgsrate von 80 % in einem Durchlauf und 65 % in einem anderen führen. Es sind mindestens 3–5 Durchläufe pro Aufgabe erforderlich (Pass@k-Metrik).
• Blindes Vertrauen in LLM-as-a-Judge: Die Verwendung eines anderen Modells zur Code-Bewertung leidet oft unter einer Voreingenommenheit zugunsten längerer Antworten.