26.06.2025 AI Engineering 5 Minuten Lesezeit

Service-Virtualisierung für Agenten

Agenten-Journeys enden an Systemen, gegen die Sie nicht in großem Umfang testen können: Zahlungsdienstleister, ERP-Backends, Partner-APIs. Wir übertragen Service-Virtualisierung auf Agenten — simulierte Gegenstellen hinter echten Verträgen, mit Zustand und Fehlerinjektion — und begründen, warum jedes simulierte Ergebnis ein explizites Label tragen muss. Mit geprüften Daten aus τ-bench, τ²-bench und Microcks 1.12.0.

Testen gegen unantastbare Systeme

Eine Agenten-Journey ist der vollständige Weg eines Agenten durch eine Aufgabe: Modellaufrufe, Tool-Aufrufe, Wiederholungen und die Zustandsänderungen, die sie auslösen. Viele der Werkzeuge am Ende dieses Weges gehören anderen. Zahlungsdienstleister, ERP-Backends, Carrier-APIs, Behördenregister. Gegen diese Systeme können Sie keine fünfhundert Evaluationsläufe fahren. Ratenlimits, Vertragsbedingungen, irreversible Seiteneffekte und Kosten pro Aufruf verbieten es. Getestet ist die Journey aber nur, wenn diese Aufrufe stattfinden.

Das Problem ist nicht neu. Das klassische Integrationstesten stand vor zwanzig Jahren vor derselben Wand und beantwortete sie mit Service-Virtualisierung. Neu ist der Client. Ein Agent ist ein nicht-deterministischer Client, und das verändert, wie eine brauchbare Simulation aussehen muss. Dieser Artikel beschreibt die Anpassung, und er benennt offen, was sie nicht leistet.

Eine Aufgabe kommt an — der Agent plant den nächsten Schritt. 1/4

Service-Virtualisierung kurz definiert

Service-Virtualisierung heißt: Eine Abhängigkeit wird durch eine simulierte Gegenstelle ersetzt, die das reale Protokoll der Abhängigkeit spricht und ihre reale Schnittstelle einhält. Der getestete Konsument wird nicht verändert und weiß nicht, dass er mit einer Simulation spricht. Werkzeuge wie WireMock, Mountebank, Hoverfly und Microcks tragen dieses Muster seit Jahren: Verhalten aufzeichnen oder spezifizieren, hinter der echten Endpunktform ausliefern, danach das Verhalten des Konsumenten prüfen.

Der Unterschied zum Ad-hoc-Mock ist wesentlich. Ein Mock lebt in Ihrem Testcode und spiegelt Ihre Annahmen. Ein virtualisierter Dienst lebt hinter der Leitung und spiegelt den Vertrag. Nur Letzterer lässt sich zwischen Teams teilen, unabhängig versionieren und von einem unveränderten Agenten ansprechen, der seinen echten Tool-Stack ausführt.

Warum Agenten klassische Mocks sprengen

Klassische Stubs setzen einen deterministischen Client voraus: bekannte Aufrufreihenfolge, bekannte Payloads, ein einziger Pfad. Agenten verletzen jede dieser Annahmen. Sie wählen die Reihenfolge zur Laufzeit, paraphrasieren Parameter, wiederholen nach Fehlern und explorieren. τ-bench hat das im Juni 2024 gezeigt: Aktuelle Function-Calling-Agenten lösten weniger als 50 Prozent der Aufgaben, und wiederholte Läufe derselben Aufgabe drifteten auseinander — pass^8 fiel in der Retail-Domäne unter 25 Prozent.

Ein Stub, der genau eine erwartete Anfrage beantwortet, deckt deshalb fast nichts ab. Die simulierte Gegenstelle muss sich wie ein Dienst verhalten: jede vertragskonforme Anfrage akzeptieren, Zustand über Aufrufe hinweg halten und ungültige Anfragen so ablehnen, wie es das reale System täte. Andernfalls besteht der Agent seine Tests in einem Korridor, den es in der Produktion gar nicht gibt.

Eigenschaft	Deterministischer Client	Agent als Client
Aufrufreihenfolge	Fest und vorab bekannt	Zur Laufzeit gewählt
Payloads	Exakt erwartete Werte	Jede vertragskonforme Variante
Wiederholungen	Skriptgesteuert	Emergent und modellabhängig
Abdeckungsziel	Ein Request-Response-Paar	Der Verhaltensraum des Vertrags
Testorakel	Antwortgleichheit	Endzustand und Journey-Prüfungen

Simulierte Gegenstellen hinter echten Verträgen

Das stabile Element in diesem Aufbau ist der Vertrag: ein OpenAPI-3.1-Dokument, eine gRPC-Proto-Datei, ein AsyncAPI-Kanal oder ein MCP-Tool-Schema. Die Simulation implementiert den Vertrag, der Agent konsumiert ihn, keiner kennt den anderen. Jede simulierte Antwort wird gegen das Schema validiert, jede Anfrage des Agenten ebenso. Eine Vertragsverletzung lässt den Test scheitern, unabhängig vom Aufgabenergebnis, denn sie sagt einen Produktionsfehler voraus, den kein Eval-Score entschuldigen kann.

Das Tooling hat in diesem Frühjahr aufgeschlossen. Microcks 1.12.0, veröffentlicht am 28. Mai 2025, stellt bestehende OpenAPI-, GraphQL- und gRPC-Mocks als MCP-Endpunkte bereit — über SSE nach der Protokollrevision 2024-11-05 und über Streamable HTTP nach der Revision 2025-03-26. MCP selbst wurde im November 2024 von Anthropic vorgestellt. Ein Agent erreicht ein virtualisiertes Backend damit über genau das Protokoll, das er auch in der Produktion nutzen würde.

Zustandsbehaftete Simulation und Fehlerinjektion

Zwei Erweiterungen trennen agententaugliche Virtualisierung vom bloßen Request-Replay. Erstens Zustand: Eine in Aufruf drei angelegte Bestellung muss in Aufruf sieben abrufbar sein, denn Agenten verifizieren ihre eigene Arbeit und verzweigen auf dem, was sie vorfinden. Zweitens Fehler: Timeouts, 429-Antworten, Teilausfälle und veraltete Lesezugriffe, deterministisch injiziert — denn Erholungsverhalten ist der testwürdigste Teil einer Journey und im Happy Path grundsätzlich unsichtbar.

Die Gegenstelle ist manchmal ein Mensch. τ²-bench, veröffentlicht am 9. Juni 2025, simuliert Nutzer mit eigenen Werkzeugen in einer Telekom-Support-Domäne. Die pass^1-Rate der Agenten fiel um rund 20 Prozentpunkte, sobald ein simulierter Nutzer in der Schleife war — GPT-4.1 erreichte dort 34 Prozent. Simulierte Menschen gehören aus demselben Grund in den Testaufbau wie simulierte Dienste: Die echten stehen im nötigen Testvolumen schlicht nicht zur Verfügung.

Simulierte Ergebnisse kennzeichnen

Jedes Ergebnis, das gegen eine Simulation entstanden ist, muss diese Tatsache als Datum tragen. Wir hängen an jeden Trace, jede Tool-Antwort und jeden Evaluationsdatensatz ein Simulationslabel — als explizites Feld, nicht als Namenskonvention. Das Label propagiert: Ein Bericht, der aus simulierten Episoden aggregiert wurde, ist selbst als simuliert gekennzeichnet, und eine Journey aus realen und simulierten Aufrufen wird als gemischt markiert.

Die Gründe sind konkret. Erstens ehrliches Reporting: Aus "die Journey besteht" wird sonst stillschweigend "die Journey besteht gegen unser Modell der Gegenstelle", und wer ein Dashboard liest, muss diesen Unterschied sehen können. Zweitens Kontamination: Agentengedächtnisse, Few-Shot-Beispielpools und Fine-Tuning-Datensätze aus Traces müssen simulierte Interaktionen zuverlässig ausschließen können. Ein ungelabelter simulierter Erfolg ist eine kleine Lüge mit langer Halbwertszeit.

Was Virtualisierung nicht beweist

Virtualisierung beweist, dass sich der Agent korrekt gegenüber Ihrem Modell der Gegenstelle verhält. Sie beweist nicht, dass dieses Modell stimmt. Undokumentiertes Verhalten, Vertragsdrift auf Anbieterseite, reale Latenzverteilungen und produktive Authentifizierungsflüsse liegen außerhalb der Simulation. Ein vertragskonformer Simulator kann semantisch trotzdem falsch sein, und zwar genau an den Stellen, die niemand zu spezifizieren dachte.

Wir behandeln simulierte Evaluation deshalb als Gate, nicht als Urteil. Sie läuft bei jeder Änderung, günstig und wiederholbar. Darauf folgt eine dünne Schicht überwachter Läufe gegen reale Sandboxes, wo es sie gibt, und ein gestufter Rollout mit engem Monitoring, wo es sie nicht gibt. Wer diese zweite Schicht auslässt, verwandelt eine Teststrategie in einen bloßen Glauben.

Ausblick vom Juni 2025

Drei Entwicklungen halten wir von heute aus für wahrscheinlich. Erstens wird MCP-native Virtualisierung eine eigene Werkzeugkategorie: Das Protokoll hat in acht Monaten drei Spezifikationsrevisionen erlebt — 2024-11-05, 2025-03-26 und das vor einer Woche veröffentlichte 2025-06-18 — und die Mock-Werkzeuge ziehen Release für Release nach. Zweitens werden API-Anbieter offizielle Simulatoren ausliefern, so wie sie heute SDKs ausliefern, weil der Verkehr von Agenten inoffizielle Sandboxes ökonomisch unhaltbar macht.

Drittens wächst das Simulationslabel über den Testaufbau hinaus. Sobald Agenten in der Produktion mit simulierten Komponenten arbeiten — Dry Runs, Schattenwerkzeuge, Probeumgebungen —, wird die Herkunft von Ergebnissen zur betrieblichen Anforderung statt zur reinen Testkonvention. Wir erwarten, dass die Kennzeichnung simulierter Ergebnisse binnen eines Jahres in Observability-Standards für Agenten auftaucht. Wer sie jetzt einführt, muss seine Daten später nicht mühsam entwirren.