07.07.2026 AI Engineering 6 Minuten Lesezeit

Simulation-First-Engineering für Agenten

End-to-End-Journeys von Agenten enden in Zustandsänderungen bei Behörden, ERP-Systemen und Partner-APIs — Systemen, gegen die sich nicht frei testen lässt. Dieser Artikel definiert das Simulation-First-Muster: Das reale Gegensystem wird hinter demselben Kontrakt gegen ein zustandsbehaftetes simuliertes getauscht. Wir ordnen das Muster gegenüber Service-Virtualisierung und Digital Twins ein und behandeln ehrliche Kennzeichnung, Last- und Angriffstests, die Fidelity-Lücke und den Weg zu Ökosystemen simulierter Gegensysteme.

Warum reale Gegensysteme Tests verhindern

Eine Agent-Journey ist die End-to-End-Ausführung eines Geschäftsprozesses durch einen Software-Agenten: Er sammelt Daten, ruft externe Systeme auf, reagiert auf deren Antworten und endet in einem prüfbaren Ergebnis. Das Gegensystem ist das externe System, gegen das die Journey läuft — der Annahmeserver einer Behörde, ein ERP, eine Partner-API. Weil das Ergebnis einer Journey eine Zustandsänderung im Gegensystem ist, heißt den Agenten testen: gegen das Gegensystem testen. Genau dort scheitert das Testen.

Produktive Gegensysteme haben irreversible Nebenwirkungen: Eine übermittelte Meldung ist ein Rechtsakt, eine gebuchte Bestellung bewegt Ware und Geld. Offizielle Sandboxes existieren, sind aber bewusst unvollständig. Die API-Sandbox der britischen Steuerbehörde HMRC lässt Zwei-Faktor-Authentifizierung und Identitätsprüfung weg; die Sandbox von Companies House ersetzt die interne Verarbeitung durch einen Mock, der Statusmeldungen liefert, ohne Registerdaten zu ändern. Dazu kommen Rate-Limits, fremdbestimmte Datenresets und kaum abrufbare Fehlerfälle. Ein Agent in Entwicklung braucht Hunderte Läufe pro Journey, auch absichtlich kaputte. Kein reales Gegensystem trägt das.

Zwei Peers — jeder mit eigenem Zustand und privatem Graph. 1/4

Der Tausch hinter dem Kontrakt

Simulation-First-Engineering baut den Agenten gegen einen Kontrakt und macht das Gegensystem dahinter austauschbar. Ein Kontrakt ist hier die maschinenlesbare Schnittstelle des Gegensystems: Endpunkte und Schemata (typischerweise OpenAPI), Protokoll und Authentifizierungsfluss und — oft vergessen — die Fehlersemantik. Ein simuliertes Gegensystem ist eine zweite Implementierung desselben Kontrakts mit eigenem Zustandsspeicher, ausrollbar überall dort, wo Tests laufen.

Zwei Regeln machen das Muster tragfähig. Erstens darf der Agent nicht wissen, welche Implementierung er vor sich hat: gleiche Tools, gleicher Codepfad, gleiche Retry-Logik; der Schalter liegt in der Umgebungskonfiguration, nie im Reasoning des Agenten. Ein Agent, der auf einen Testmodus verzweigt, testet einen anderen Agenten. Zweitens muss der Simulator zustandsbehaftet sein. Eine Journey, die einreicht, den Status abfragt und eine Ablehnung korrigiert, braucht ein Gegensystem, dessen Antworten von der Vorgeschichte abhängen. Konservenantworten testen das Parsen, nicht die Journey.

Was Service-Virtualisierung gelöst hat

Die Infrastruktur dafür ist nicht neu. Service-Virtualisierung stellt ein netzwerkfähiges Testdouble bereit, das das zu testende System über das echte Protokoll erreicht — im Unterschied zum In-Process-Mocking, das Objekte im Testrunner ersetzt. WireMock bietet Stub-Mappings als JSON, Record-and-Playback, zustandsbehaftete Szenarien, Fault Injection und simulierte Latenzen; Hoverfly zeichnet als Go-basierter Proxy Traffic auf und spielt ihn ab; Mountebanks Imposter decken HTTP, TCP und SMTP ab. Record-and-Replay ist das Arbeitspferd: echten Traffic einmal aufzeichnen, deterministisch beliebig oft abspielen.

Agenten brechen dieses Arbeitspferd. Record-and-Replay setzt voraus, dass der Client den aufgezeichneten Pfad wiederholt. Ein LLM-getriebener Agent tut das nicht: Er formuliert Requests je Lauf anders und wählt unterschiedliche Tool-Sequenzen zum selben Ziel. Ein Antwortarchiv kann ihm deshalb nicht antworten. Das simulierte Gegensystem muss ein Verhaltensmodell sein — Domänenzustand plus Übergangsregeln —, das Antworten auf nie aufgezeichnete Requests berechnet. Virtualisierungswerkzeuge bleiben darunter als Transport- und Fault-Injection-Schicht nützlich.

Ein Digital Twin ist kein Simulator

Der Begriff Digital Twin passt hier nicht, und der Unterschied ist wesentlich. Das Digital Twin Consortium definiert einen Digital Twin als "a virtual representation of real-world entities and processes, synchronized at a specified frequency and fidelity" (Dezember 2020); ISO/IEC 30173:2023 normiert die Terminologie, ISO 23247 eine Referenzarchitektur für Zwillinge in der Fertigung. Die Synchronisation mit einer realen Entität ist konstitutiv. Ein simuliertes Gegensystem ist absichtlich nicht synchronisiert: Es erzeugt kontrafaktischen Zustand, damit Journeys laufen können, ohne das reale System zu berühren. Es einen Twin zu nennen, behauptet eine Treue, die es nicht besitzt.

Technik	Ersetzt	Zustand	Mit Realität synchronisiert	Primärer Zweck
In-Process-Mock	Ein Objekt im Testprozess	Keiner oder minimal	Nein	Isolation im Unit-Test
Service-Virtualisierung	Einen Netzwerkdienst hinter seinem Protokoll	Geskriptet oder aufgezeichnet	Nein	Integrationstests ohne die Abhängigkeit
Simuliertes Gegensystem	Ein vollständiges Gegensystem hinter seinem Kontrakt	Verhaltensmodell mit fortlaufendem Zustand	Nein — bewusst kontrafaktisch	End-to-End-Journeys von Agenten
Digital Twin	Nichts — er spiegelt eine reale Entität	Spiegel des realen Zustands	Ja mit definierter Frequenz und Treue	Monitoring und Prognose

Simulierte Ergebnisse ehrlich kennzeichnen

Eine Journey erzeugt Artefakte: Bestätigungsnummern, Transaktions-IDs, Dokumente, Buchungen. Aus einem guten Simulator sind sie von echten nicht zu unterscheiden — absichtlich, und genau das ist die Gefahr. Ehrliche Kennzeichnung heißt Provenienz auf der Datenebene, nicht auf der UI-Ebene: Jeder in einem simulierten Lauf geschriebene Datensatz trägt eine maschinenlesbare Herkunftsmarkierung, simulierte Identifikatoren stammen aus einem reservierten Namensraum, generierte Dokumente sind sichtbar mit Wasserzeichen versehen. Ein Badge in der Oberfläche überlebt den Export in eine Tabelle nicht.

Daraus folgen drei Regeln. Provenienz beim Schreiben markieren, nie erst beim Anzeigen. Simulierte und reale Ergebnisse nie in eine Kennzahl aggregieren — eine Erfolgsquote, die stillschweigend simulierte Bestätigungen enthält, ist eine falsche Aussage. Und das persistente Gedächtnis eines Agenten darf simulierte Ergebnisse nie als Fakten über die reale Welt aufnehmen; simulierter Zustand muss in einer einzigen Operation löschbar sein.

Last- und Angriffstests auf Abruf

Zuverlässigkeit von Agenten ist eine statistische Eigenschaft — und Simulation das einzige bezahlbare Messinstrument. τ-bench (ICLR 2025) testet Agenten gegen LLM-simulierte Nutzer und bewertet den finalen Datenbankzustand; die Metrik pass^k fragt, ob alle k unabhängigen Läufe gelingen. GPT-4o mit Function Calling erreichte in der Retail-Domäne rund 61 % pass^1, aber nur etwa 25 % bei pass^8 — dieselbe Aufgabe, acht Läufe, kollabierende Konsistenz. Das gegen ein reales Gegensystem mit realen Rate-Limits zu messen, ist nicht praktikabel. τ²-bench (Juni 2025) erweitert den Aufbau auf Dual Control: Auch der simulierte Nutzer bedient Tools in der gemeinsamen Umgebung.

Derselbe Simulator trägt Fehler- und Angriffstests. Fault Injection liefert, was Sandboxes selten hergeben: 503-Bursts, Timeouts, tröpfelnde Antworten, schema-valide aber semantisch falsche Payloads, Regeländerungen mitten in der Journey. Angriffstests sind inzwischen produktisiert: Microsofts AI Red Teaming Agent (Public Preview, November 2025) fährt über 20 PyRIT-Angriffsstrategien, darunter Indirect Prompt Injection über gemockte Tool-Ausgaben; RAMPART (Open Source seit Mai 2026) kodiert solche Angriffe als pytest-Tests mit statistischen Bestehensregeln. Eine vergiftete Gegensystem-Antwort ist genau das, was nur ein simuliertes Gegensystem gefahrlos ausliefern kann.

Die Fidelity-Lücke

Ein Simulator kodiert Ihr Modell des Gegensystems — nie das Gegensystem selbst. Undokumentiertes Verhalten, Latenzverteilungen, Datenanomalien und Drift nach dem nächsten Release des Gegensystems bleiben in der Simulation unsichtbar und kehren bei der Integration zurück. Ein grüner Simulationslauf verifiziert den Agenten gegen den Kontrakt, wie Sie ihn verstehen. Er verifiziert weder den Kontrakt noch die Produktionsreife.

Vier Regeln begrenzen den Anspruch. Erstens ersetzt Simulation exploratives Testen und Regressionstests, nie die Zertifizierung: Die Konformitätsprüfung für Peppol-Service-Provider läuft auf dem zentralen Testbed von OpenPeppol, und die OZG-RE-Rechnungsplattform des Bundes verlangt ihre eigene Testumgebung. Zweitens gehört vor jedes Go-live eine Teilmenge der Journeys gegen die reale Sandbox oder einen Produktionspiloten. Drittens ist jede beobachtete Abweichung zwischen Simulator und Realität ein Defekt im Simulator und dort zu beheben. Viertens: Was sich nicht tragfähig modellieren lässt — etwa Gegensysteme mit intransparenten Ermessensentscheidungen —, wird nur als Vermutung simuliert.

Ausblick: Ökosysteme simulierter Gegensysteme

Die aktuellen Kosten des Musters: Jedes Team baut seine Simulatoren selbst. Der plausible nächste Schritt ist, dass Betreiber sie mitliefern — eine Behörde oder ein Plattformanbieter veröffentlicht neben der OpenAPI-Spezifikation einen ausführbaren Verhaltenssimulator, gemeinsam versioniert, sodass die Semantik des Gegensystems zum Testartefakt wird. Benchmarks modellieren bereits beide Seiten einer Interaktion als toolnutzende Parteien in einer gemeinsamen Umgebung; τ²-bench ist eine frühe Vorlage.

Wo beide Seiten eines B2B-Prozesses Agenten sind, wird das simulierte Gegensystem zum simulierten Agenten — und Testen vor Produktion heißt, beide Agenten in einer abgeschotteten Umgebung gegeneinander laufen zu lassen. Wir erwarten, dass ein Simulationsmodus zur Standardfähigkeit von Agentenplattformen reift: ein Laufzeitschalter erster Klasse, der Gegensysteme hinter unveränderten Kontrakten tauscht und die beschriebene Provenienzkennzeichnung erzwingt. Teams, die von Beginn an gegen Simulatoren bauen, testen nicht schneller — sie testen, was sonst untestbar ist.