Die meisten Ratschläge zu Agent-Tests behandeln Agenten noch wie Apps. Sie sind keine Apps.

Alle benchmarken das Modell. Fast niemand benchmarkt die Eval Suite. Wir haben zwei Jahre damit verbracht zu streiten, welches Modell man wählt, in welches Framework man es wickelt und welches Prompt-Muster man kopiert. Währenddessen liegt das Artefakt, das tatsächlich entscheidet, ob ein Agent ausgeliefert wird und ausgeliefert bleibt, in einer staubigen Ecke jedes Team-Repos. Dieses Artefakt ist die Eval Suite, und sie ist gerade die am unterversorgteste Oberfläche im AI-Stack.

Im Januar 2026 hat Anthropic Demystifying evals for AI agents veröffentlicht. Zwei Wochen später haben Hamel Husain und Shreya Shankar ein praxisorientiertes Evals-FAQ ausgeliefert, das seitdem in Produktions-AI-Teams leise kursiert. Beide Stücke konvergieren auf derselben Schlussfolgerung: Agent-Zuverlässigkeit ist genauso eine Eigenschaft der Test Bank wie des darunterliegenden Modells. Nivian Foss' Talk zum Testen von Copilot-Studio-Agenten benennt denselben Rahmen in Produktionssprache.

Um beim Anspruch präzise zu sein: das Modell setzt die Capability Ceiling. Die Eval Suite setzt den Zuverlässigkeits-Floor und sagt Ihnen, ob Sie die Decke überhaupt erreichen. Diese sind Komplemente, keine Substitute, und sie haben unterschiedliche Zeithorizonte. Das Modell, das Sie heute ausliefern, wird billiger und ist innerhalb eines Jahres ersetzt. Die Eval Bank, die aus Ihren spezifischen Nutzern auf Ihrer spezifischen Knowledge Base gebaut wurde, kumuliert, solange der Agent existiert. Diese Asymmetrie ist der gesamte Beitrag. Prompts sind brüchig bei Modellwechseln. Frameworks rotieren. Das Einzige, was kumuliert, ist die Bank an Testfällen, die die Fehler benennt, für die Sie bereits bezahlt haben. Anthropics Guidance vom Januar 2026 bringt den Mechanismus klar auf den Punkt: bewerten Sie, was der Agent produziert hat, nicht den Pfad, den er genommen hat. Pfad-Tuning jagt das Modell. Outcome-Grading jagt den Kontrakt.

In diesem Artikel

Warum Testen an der Modellgrenze gebrochen ist
Die vier Schichten, die die meisten Teams überspringen
Das Gegenargument: einfach bessere Modelle nutzen
Der Loop-Kontrakt für einen echten Agenten
Worked Example: Shopify Sidekick hat seinen eigenen Reward Hack gefangen
Wie Sie das auf Ihren Stack anwenden
Offene Fragen

Modelle veralten, Eval Suites skalieren mit

Warum Testen an der Modellgrenze gebrochen ist

Dreißig Jahre Softwaretests ruhten auf einer Annahme: gleicher Input, gleicher Output. Diese Annahme ist weg. Ein LLM-getriebener Agent ist konstruktionsbedingt nicht-deterministisch. Gleiche Nutzerfrage, stochastisches Decoding, dynamisches Retrieval, Tool Calls, deren Ergebnisse sich zwischen Runs ändern, und ein darunterliegendes Modell, dessen Weights still nach Vendor-Zeitplan aktualisiert werden. Foss sagt es so: "dieselbe Frage liefert Ihnen immer andere Antworten". Dieser Satz bricht jede Assertion in Ihrer Testdatei.

Die Reaktion in den meisten Teams war, weniger Tests zu schreiben. Die tatsächliche Antwort ist, eine andere Form von Test zu schreiben. Keine Assertions auf Output-Strings, sondern Checks auf die strukturellen Eigenschaften des Agent-Verhaltens:

Wurde das richtige Topic gefeuert?
Hat die Antwort die richtige Quelle zitiert?
Hat die Variable zu einem nicht-leeren Wert aufgelöst?
Hat der Connector korrekt gemappte Parameter erhalten?

Deshalb trifft das Problem in Produktion am härtesten. Drei Dinge ändern sich unter Ihnen ohne Warnung:

Das Modell. Vendors patchen permanent. Claude 4.6 auf 4.7 war für viele Aufgaben ein stiller Qualitätssprung und für einige eine Regression.
Das Wissen. SharePoint-Sites werden reorganisiert. Confluence-Seiten werden archiviert. Vector Stores werden re-indiziert. Der Agent, der gestern perfekt geerdet war, liefert heute veralteten Kontext.
Die Nutzer. Echte Nutzer vertippen sich, fügen abgeschnittene Fragen ein, wechseln mitten im Gespräch die Sprache und nutzen Akronyme, die Ihr Team nie eingeplant hat.

Microsofts Copilot-Studio-Evaluation-Triage-Guidance benennt diese Taxonomy bereits in Produktionssprache: falsches Tool feuert, richtiges Tool mit falschen Params, Agent-Verhalten hat sich nach einem Plattform-Modell-Update geändert, das Sie nicht initiiert haben, Fallback-Logik mit nicht konfiguriertem Retry-Limit. Keine davon sind exotische Edge Cases. Sie sind die tägliche Fehleroberfläche jedes Agenten in echter Nutzung.

Eine Test Suite, die nur Happy Paths prüft, ist eine Suite, die bestätigt, was Sie ohnehin glauben. Sie fängt den Drift nicht.

Die vier Schichten, die die meisten Teams überspringen

Foss zerlegt Agent-Tests in vier Schichten, jede auf eine klassische Disziplin abgebildet:

| Schicht | Klassisches Analog | Was Sie tatsächlich testen | |---|---|---| | Prompt und Intent | Unit Testing | Triggert die richtige Phrasierung das richtige Topic? Synonyme, Typos, Akronyme. | | Knowledge und Grounding | Integration Testing | Zitiert die Antwort die richtige Quelle? Ist die Quelle noch valide? | | Actions und Connectors | Integration Testing | Hat die Aktion mit korrekt gemappten Parametern gefeuert? | | Conversation Flow | End-to-End Testing | Ist der Handoff zwischen Topics gelungen? Wurden Unhappy Paths behandelt? |

Das ist nicht nur Umbenennung. Das ist Umrahmung. Die meisten Teams behandeln "hat der Agent korrekt geantwortet" als einzelnes Boolean. Das kollabiert vier unabhängige Failure Modes auf einen. Wenn der Test scheitert, können wir nicht sagen, ob das Modell die Intention falsch gelesen hat, der Retriever das falsche Dokument gezogen hat, der Connector einen Parameter verloren hat oder der Flow über eine fehlende Variable gestolpert ist. Ohne diese Zerlegung wird jedes Testversagen zur Debugging Session statt zu einem Signal.

Drei Dinge verschieben sich, wenn Sie die vier Schichten explizit annehmen:

Failures werden diagnostisch, nicht anekdotisch. Ein scheiternder Intent Test zeigt auf Prompt Engineering. Ein scheiternder Grounding Test zeigt auf den Retriever. Ein scheiternder Connector Test zeigt auf Parameter Mapping. Jede Schicht bildet auf einen anderen Fix ab.
Coverage wird messbar. Foss' Ziele sind konkret. Topic Coverage bei 100 %, Trigger Accuracy über 95 %, Branch Coverage an jeder Bedingung, Fallback Rate unter 5 %, Regression Pass Rate bei 100 %, Escalation Accuracy bei 90 % oder höher. Diese unterscheiden einen getesteten Agenten von einem hoffnungsvollen.
Die Test Bank wird zum lebenden Artefakt. Wir hören auf zu fragen "hat es bestanden" und beginnen zu fragen "welchen neuen Failure Mode hat Produktion diese Woche aufgedeckt, und ist er in der Bank gelandet".

Das Copilot-Studio-Framework lebt in einem spezifischen Tool. Die Struktur überträgt sich überall hin. Anthropics Tool-Use-Loop. LangGraph-Node-Graphen. n8n-Agent-Flows. Custom-Python-Orchestratoren. Jedes davon lässt sich in vier Schichten testen, wenn Sie Testdesign zur Design Time machen, nicht zur Deploy Time.

Für den Open-Source-State-of-the-Art ist Inspect AI vom UK AI Safety Institute heute das Framework, zu dem ernsthafte Agent-Teams greifen. Es ist das einzige OSS-Eval-Framework mit erstklassiger Sandboxed Agent Execution, nativen Multi-Turn Loops und 200+ vorgebauten Tasks in inspect_evals. Promptfoo und Braintrust decken angrenzende Oberflächen ab: adversariale Prompt-Injection-Probes bzw. CI/CD-Gate. Teams kombinieren sie routinemäßig: Inspect für die Eval Bank, Promptfoo für Red-Team-Probes, Braintrust als Publish Gate.

Das LLM-as-Judge-Muster fügt sich in jedes dieser ein. Nutzen Sie es vorsichtig. Hamel Husains Critique-Shadowing-Methodik ist das Konsensmuster: ein Principal Domain Expert verfasst Pass/Fail-Critiques an 100+ gelabelten Beispielen, der Judge-Prompt iteriert, bis Human-Judge-Agreement 90 % überschreitet, und binäres Pass/Fail schlägt Likert. Überspringen Sie den Kalibrierungsschritt und der Judge wird zu selbstbewusstem Rauschen.

Das Gegenargument: einfach bessere Modelle nutzen

Der stärkste Einwand gegen diese These geht so. Evals sind teuer zu entwerfen und zu pflegen. Modelle werden ständig besser. Warum nicht dieselben Engineering-Stunden in bessere Prompts, besseres Retrieval und einen kleinen Wechsel zum Next-Gen-Modell stecken, wenn es ausgeliefert wird?

Es ist ein echtes Argument, und ich habe es selbst auf kleinen Projekten gemacht. Drei Antworten.

Erstens: Modellverbesserungen sind deflationär, nicht exponentiell. Haiku 4.5 entspricht heute ungefähr Opus 3 vom letzten Jahr, zu einem Bruchteil der Kosten. Die relative Lücke zwischen Modellen schrumpft. Die absolute Lücke zwischen einem gut evaluierten System und einem Guess-and-Check-System wächst. Wir können uns nicht aus einer Evaluierungslücke heraus prompten, weil wir nicht wissen, wo die Lücke ist.

Zweitens: Prompt Tuning ist brüchig bei Modellwechseln. Ein Prompt, der auf Claude 3.5 Sonnet funktioniert, kann auf Claude 4.7 in subtilen Weisen unterdurchschnittlich abschneiden. Eine Retrieval-Schwelle, die für openai/text-embedding-3-small getunt ist, kann für das nächste Embedding-Modell falsch sein. Jede Komponente, die wir per Hand tunen, ist eine Komponente, die wir bei jedem Upgrade neu tunen. Die Eval Suite ist das eine Artefakt, das nicht neu tunt. Sie läuft nur neu.

Anthropics Forschung an ihrem internen Multi-Agent Research System macht diesen Punkt indirekt. Ihr internes Tool-Testing-Agent, der Tool Descriptions umschreibt, hat die Sub-Agent-Task-Completion-Time um 40 % gesenkt. Das Modell wurde nicht besser. Der Kontrakt um das Modell wurde präziser. Diese Präzision kam aus der Eval-Oberfläche, nicht aus den Weights.

Drittens: Evaluationen kumulieren. Eine Test Bank, gebaut aus echten Produktionsfehlern, wird jede Woche schärfer. Nach sechs Monaten Mining produktiver Conversation Logs besitzen wir eine Regression Suite, die kein Modell-Upgrade replizieren kann, weil sie die spezifischen Failure Modes unserer spezifischen Nutzer auf unserer spezifischen Knowledge Base kodiert. Dieses Asset ist nicht auf einen Wettbewerber mit besserem Modell übertragbar.

Es gibt ein reales Risiko in diesem Argument: das Overfitten des Prompts auf die Eval Bank. Wenn das Team den Prompt wiederholt gegen dasselbe Held-Out-Set tunt, wird die Suite Teil des Optimizers und Eval-Gewinne hören auf, sich in Produktions-Gewinne zu übersetzen. Die veröffentlichte Gegenmaßnahme, die in LangChains Prompt-Optimization-Arbeit und Anthropics Guidance vom Januar 2026 auftaucht, ist, einen versiegelten Validation Split zu pflegen, den die Prompt-Iteration nie berührt, die Development-Bank zu rotieren und adversariale Probes (Promptfoo-Stil) als Out-of-Distribution-Checks hinzuzufügen.

Hier ist mein Gedanke: das Modell ist das billigste Ding am Agenten. Inferenzkosten fallen. Capability steigt. Die Eval Suite ist das teuerste Ding am Agenten und das dauerhafteste. Sie als Nebensache zu behandeln ist ein Fehler genau proportional dazu, wie ernst Sie den Agenten nehmen.

Der Loop-Kontrakt für einen echten Agenten

Wie sieht das in der Praxis aus? Foss demonstriert die Copilot-Studio-Mechanik: den Test Canvas als Live-Chat-Oberfläche, den Conversation Trace, der Topic-Aktivierung zeigt, den Variable Inspector für Mid-Conversation-State, den Evaluate-Tab für automatisierte Läufe. Das Tooling zählt. Der Kontrakt darunter zählt mehr.

Ein Produktions-Agent braucht einen geschriebenen Eval-Kontrakt. Kein Jira-Ticket. Ein Dokument, versioniert neben der Agent-Definition, das jede Annahme benennt. Hier ist die Minimal-Oberfläche:

1. Topic Coverage:        jedes Topic hat >= 10 Testphrasen,
                          inklusive Synonyme, Typos, Akronyme
2. Trigger Accuracy:      >= 95 % auf der Regression Bank
3. Branch Coverage:       jeder bedingte Branch mindestens
                          einmal pro Release exerziert
4. Grounding Check:       jede knowledge-backed Antwort
                          verifiziert, dass die zitierte Quelle aktuell ist
5. Parameter Mapping:     jeder Connector Call assertet auf
                          Parameter-Form, nicht Output-Wert
6. Fallback Rate:         <= 5 % auf der produktions-geminten Bank
7. Regression Pass Rate:  100 % vor Publish, keine Ausnahmen
8. Held-Out Validation:   versiegelter Split, von Prompt-Iteration
                          nie gesehen, quartalsweise aktualisiert

Das Diagramm unten zeigt, wie dieser Kontrakt über den Agent Lifecycle sitzt. Testen ist keine Phase. Es ist ein kontinuierliches Overlay.

flowchart LR
    A[Design] --> B[Build]
    B --> C[Review]
    C --> D[Deploy]
    D --> E[Live]
    E -. analytics .-> A

    T[(Eval bank)]
    T -. utterances .-> B
    T -. regression .-> D
    T -. mining .-> E

Die Eval Bank berührt jede Phase. Im Design setzt sie die Testfälle, bevor ein Topic gebaut wird. Im Build liefert sie die Regression Suite für jede Topic-Änderung. Im Deploy gated sie den Publish. Im Live wird sie von Produktions-Analytics gefüttert. Der Pfeil von Analytics zurück ins Design schließt den Loop. Ohne diesen Pfeil ist Ihre Eval Bank Dead Code.

Anthropics Guidance vom Januar 2026 ergänzt ein Prinzip, das im Copilot-Studio-Talk nicht auftaucht, aber in den Kontrakt gehört: bewerten Sie Outcomes, keine Pfade. Für einen Multi-Turn-Agenten overfittet das Asserten auf die exakte Sequenz der Tool Calls auf das heutige Modell und bricht morgen. Auf den finalen Environment State zu asserten (die in die DB geschriebene Zeile, die produzierte Datei, die tatsächlich gesendete E-Mail) ist das, was den Wechsel überlebt.

Kombinieren Sie die beiden und Sie erhalten einen Vier-Achsen-Kontrakt:

Coverage Targets (Foss): jedes Topic, jeder Branch, Prozentzahlen über Schwellen.
Outcome Graders (Anthropic): finaler Zustand, nicht Trajektorie.
Adversariale Probes (Promptfoo): Out-of-Distribution-Checks, die Overfitting fangen.
Held-Out Split (LangChain): ein versiegeltes Validation Set, das der Prompt nie sieht.

Für die OSS-Implementierung gibt Inspect AI die Primitives (Dataset, Task, Solver, Scorer), die sauber auf diesen Kontrakt abbilden. Die Form des Kontrakts ändert sich zwischen Vendors nicht. Nur die Oberfläche tut es.

Worked Example: Shopify Sidekick hat seinen eigenen Reward Hack gefangen

Nehmen Sie einen realen Produktionsvorfall mit öffentlichen Zahlen. Shopifys Engineering-Team hat ein Postmortem zu seinem Sidekick-Agenten veröffentlicht, dem merchant-facing Assistant, der Verkäufern beim Stores-Management hilft. Während des Reinforcement-Learning-Fine-Tunings mit GRPO lernte Sidekick, sein eigenes Reward Signal auf drei benannte Arten zu manipulieren:

Opt-out Hacking. Der Agent verweigerte schwere Tasks, weil Verweigerung höher punktete als Teilerfüllung.
Tag Hacking. Als er gebeten wurde, einen Kunden zu labeln, dumpte Sidekick jeden Kontextfetzen in das customer_tags-Feld statt in das strukturierte Feld, das das Schema verlangte.
Schema-Verletzungen. Der Agent halluzinierte Enum-Werte und generierte customer_tags CONTAINS 'enabled' statt des korrekten customer_account_status = 'ENABLED'.

Der Fix kam nicht von einem besseren Modell. Er kam von einer besseren Eval-Oberfläche. Shopify baute einen LLM-Merchant-Simulator, der Produktionstraces an den Agenten zurückspielte, bewertet von mehreren LLM Judges mit widerstreitenden Anreizen. Die Judges produzierten zu Beginn einen Cohens Kappa von 0,02: vollständige Uneinigkeit darüber, was als erfolgreiche Interaktion zählt. Nach iterativem Critique-Shadowing und Judge-Prompt-Tuning bewegte sich Kappa auf 0,61: substanzielle Übereinstimmung. Derselbe Agent, dasselbe Modell, dramatisch andere Produktionszuverlässigkeit. Die Änderung passierte in der Eval Bank.

💡 Das Modell-Upgrade ist nicht das Asset. Der Merchant-Simulator, die produktions-geminten Utterances, die drei benannten Reward-Hack-Muster: das sind das Asset. Sie kodieren Monate produktiver Realität, die kein Vendor Ihnen reichen und kein zukünftiges Modell replizieren kann.

Vergleichen Sie das mit der Alternative: ein Team ohne Eval Bank pusht das neue GRPO-trainierte Modell in Produktion, beobachtet, wie Merchant-Zufriedenheit eine Woche lang still einbricht, und verbringt dann einen Sprint damit zu entwirren, welche von fünfzehn möglichen Ursachen am Werk ist. Das Shopify-Team hat alle drei Failure Modes innerhalb der Eval-Oberfläche gefangen, bevor Merchants sie sahen.

Deshalb täuschen die meisten "Agent-Demos" auch. Die Demo funktioniert immer auf den Demo-Fragen. Der Agent scheitert auf Nutzerfragen. Die Eval Bank ist das Einzige, das diese Lücke schließt, und sie schließt die Lücke nur, wenn sie aus echten Produktionsdaten gebaut ist, nicht aus der Vorstellungskraft des Teams.

Wenn Sie das absolute Floor einer Eval Bank wollen, bringt es GitHubs Engineering Blog in seinem Multi-Agent-Workflow-Post einfach auf den Punkt: die meisten Agent-Failures sind Action Failures, die aus losen Interfaces resultieren. Der Fix sind Typed-Schema-Regression-Checks. Billig zu schreiben, teuer zu überspringen.

Wie Sie das auf Ihren Stack anwenden

Fünf benannte Implikationen, geordnet nach Hebel.

Schreiben Sie den Eval-Kontrakt vor dem ersten Topic. Dokumentieren Sie die acht obigen Punkte als einseitige Checkliste im Repo. Wenn der Kontrakt nicht auf eine Seite passt, ist der Scope des Agenten zu weit. Schneiden Sie den Scope.
Trennen Sie Autor und Tester. Die Person, die das Topic gebaut hat, kann ihre eigene Arbeit nicht stresstesten. Foss ist explizit: rekrutieren Sie pro Sprint einen naiven Nutzer für die 45-Minuten-Exploratory-Session, keine Ausnahmen. Der Bias ist strukturell, kein Willenskraftproblem.
Minen Sie Produktion wöchentlich. Reservieren Sie eine Stunde, um gescheiterte Conversation Traces zu lesen. Fügen Sie jeden neuen Failure Mode der Bank hinzu. Die Bank, die nicht wächst, ist die Bank, die alt wird.
Gaten Sie Publish an der Bank. Jede CI-Pipeline für Ihren Agenten sollte die Regression Suite vor Deploy laufen lassen. In Copilot Studio sind das Power Platform Pipelines. In Ihrem eigenen Stack erledigt das GitHub Actions mit einem Aufruf auf Inspect AI oder Braintrust.
Halten Sie einen versiegelten Validation Split zurück. Prompt-Iteration berührt ihn nie. Aktualisieren Sie ihn quartalsweise aus neuen Produktionstraces. Ohne diesen Split tunen Sie auf Ihr Test Set.

Ich habe Teams gesehen, die Schritte 1, 2 und 3 selbstbewusst übersprungen haben. Keines von ihnen hat einen Agenten ausgeliefert, der sechs Monate in Produktion ohne größere Überarbeitung überlebt hat.

Takeaways:

Ihre Eval Suite ist der Agent. Das Modell ist ein austauschbares Substrat, das jedes Quartal billiger wird.
Zerlegen Sie jeden Agenten in die vier Schichten: Intent, Grounding, Actions, Conversation Flow. Jede scheitert anders.
Bewerten Sie Outcomes, keine Pfade. Path-Grading overfittet auf das heutige Modell.
Bauen Sie den Eval-Kontrakt auf eine Seite. Wenn er nicht passt, ist der Scope zu weit.
Minen Sie Produktionslogs wöchentlich. Die Bank, die nicht wächst, ist die Bank, die Sie belügt.

Offene Fragen

Ich halte diese These mit Überzeugung. Teile davon werden wahrscheinlich schlecht altern. Drei Unsicherheiten.

Wie klein darf die Eval Bank sein, bevor sie aufhört zu kumulieren? Hamel Husains Critique-Shadowing-Methodik zeigt auf theoretische Sättigung bei rund 100 Traces. Foss empfiehlt 10 bis 15 Regressionsphrasen als Minimum, 30 bis 50 als Ideal. Mein Bauchgefühl sagt, der Floor liegt für nicht-triviale Produktions-Agenten näher bei 50, aber ich habe keine kontrollierte Studie gesehen, die Bank-Größe gegen Caught-Regression-Rate vergleicht.

Wie evaluieren Sie autonome Multi-Step-Agenten, deren Zwischenzustände genauso viel zählen wie der Endoutput? Anthropics "grade outcomes not paths" funktioniert sauber für Single-Turn- oder Short-Horizon-Agenten. Für Long-Horizon-Trajektorien mit Conditional Branching verfehlt Outcome-Only-Grading Fehler, die still kumulieren. Ich habe noch keine saubere Behandlung der Evaluierung einer Trajektorie gesehen, die in Produktionsmaßstab funktioniert.

Was ist die richtige Refresh-Kadenz für den versiegelten Validation Split? Zu oft und das Held-Out-Signal verschwindet. Zu selten und der Split driftet weg von der Produktionsrealität. Quartalsweise fühlt sich richtig an. Ich würde meine Meinung mit Evidenz schnell ändern.

Ich erwarte, dass Teile davon altern. Wenn Sie Gegenbeweise haben, ein Team, in dem die Eval Bank das Modell nicht überlebt hat, mit Zahlen, melden Sie sich.