Auf dieser Seite
Ein grüner Test kann eine fehlende Regel verbergen. In diesem Beispiel soll ein Agent einen Store mit einer E-Mail-Plattform verbinden. Ein Testserver nimmt eine Kontaktänderung an und liefert ein sauberes 200 zurück. Der Agent schließt seine Aufgabe ab und der Test ist bestanden.
Das echte Zielsystem hat eine zusätzliche Regel: Das benutzerdefinierte Attribut muss deklariert sein, bevor eine Kontaktänderung es setzen kann. Der Testserver bildete diese Regel nicht ab. Sein grünes Ergebnis belegt etwas über den Agenten in der Testumgebung. Über die fehlende Regel im Live-System belegt es nichts.
Das ist der zentrale Kompromiss einer Simulation. Sie macht gefährliche oder teure Aktionen wiederholbar. Gleichzeitig entsteht ein zweites System, dessen Verhalten vom ersten abweichen kann.
Eine Testumgebung macht Aktionstests möglich
Gib einem handelnden Agenten ein Ziel, eine Umgebung und einen beobachtbaren Endzustand. Eine Quelldiskussion über simulierte Agentenumgebungen beschreibt diese Struktur am Beispiel von Browser- und Wissensaufgaben. In der Umgebung kann eine prüfende Instanz den hinterlassenen Zustand mit einem bekannten Sollzustand vergleichen.
Für eine Integration könnte die Testumgebung einige Zielsystemoperationen anbieten: Felder auflisten, Kontakt anlegen, Kontakt ändern und erneut auslesen. Sie könnte einen Testdatensatz mit dem deklarierten Feld FNAME und dem fehlenden Feld CUSTOM_TIER bereitstellen. Ein Test könnte den Agenten um einen Zuordnungsvorschlag bitten und anschließend einen Schreibvorgang zurückweisen, der CUSTOM_TIER vor dessen Definition nutzt.
Die Testumgebung ist hilfreich, weil jeder Durchlauf im selben Zustand beginnt. Ändere jeweils nur eine Bedingung: ein fehlendes Feld, eine abgelehnte Berechtigung, eine veraltete Schema-Version oder eine mehrdeutige Kennung. Anschließend vergleichst du die Aufrufsequenz und den resultierenden Zustand bei unterschiedlichen Modellen oder Prompts.
Das ist aussagekräftiger als eine reine Textfrage dazu, was der Agent tun würde. Es prüft, was er in einer kontrollierten Umgebung tatsächlich aufgerufen hat.
Gib der Testumgebung vor und nach jedem Aufruf einen Zustand, nicht nur eine vorbereitete Antwort. Legt der Agent einen Kontakt zweimal an, sollte der zweite Aufruf das Duplikatverhalten zeigen, das du testen willst. Liest er nach dem Schreiben ein Feld aus, sollte die Antwort den gespeicherten Zustand enthalten. Andernfalls kann der Agent bestehen, indem er eine plausible Anfrage sendet, während der Test nie feststellt, ob die Sequenz den beabsichtigten Datensatz erzeugt hat.
Genauigkeit gehört zum Test
Ein berechtigter Einwand lautet: „Der Anbieter hat eine Sandbox. Warum noch eine Testumgebung bauen?“ Nutze die Sandbox des Anbieters, wenn sie den benötigten Fall abdeckt und die Daten schützt. Eine lokale Testumgebung lohnt sich, wenn du deterministische Zurücksetzungen, gezielte Fehler oder Aufrufe testen musst, die sich in der Sandbox des Anbieters nicht einrichten lassen. Sie verursacht jedoch Wartungsaufwand. Jede nachgebildete Regel kann falsch sein oder veralten.
Die offizielle Brevo-API für Kontakte besagt, dass Kontaktattribute im Konto vorhanden sein müssen und Werte mit einem falschen deklarierten Typ ignoriert werden. Eine Testumgebung, die jeden fehlerhaften Wert zurückweist, würde sich anders verhalten als der dokumentierte Fall. Sie könnte den Agenten erwarten lassen, dass ein Fehler eintritt, der tatsächlich ausbleibt.
Halte fest, welche Anbieterregeln die Testumgebung abdeckt. Führe eine kleine Zahl von Vertragsprüfungen gegen die echte API oder ihre unterstützte Testumgebung aus. Entdeckt eine Prüfung eine Abweichung, aktualisiere die Simulation und ergänze den Fall, der sie sichtbar gemacht hat. Die Simulation ist ein Modell des Anbieters, kein Ersatz für ihn.
Dieselbe Sorgfalt gilt für Zeitabläufe. Eine Testumgebung, in der jeder Schreibvorgang sofort sichtbar wird, kann einen Workflow übersehen, der zu früh ausliest. Verzögert sie jeden Schreibvorgang, erfindet sie womöglich Fehler, die beim Anbieter nicht auftreten. Bilde Zeitabläufe nur dort nach, wo sie für die geprüfte Entscheidung relevant sind, und kennzeichne den Rest als außerhalb der Simulation. Ein bestandener Test hat dann eine genaue Bedeutung: Dieser Agent hat diese Aktionen unter diesen modellierten Regeln abgeschlossen.
Tajos Brevo-Connector-Anleitung beschreibt dasselbe praktische Problem aus Sicht der Händler:innen: Eine erfolgreiche Anfrage kann ein Feld trotzdem leer lassen. Ein Test ist nur hilfreich, wenn er das Feld prüft und nicht bloß die HTTP-Antwort.
Ein simuliertes Zielsystem testet einen Agenten anhand modellierter Regeln. Vertragsprüfungen vergleichen diese Regeln mit dem Live-System, bevor eine begrenzte Vorschau startet.
Von der sicheren Probe zu begrenzten Belegen
Auf eine bestandene Simulation sollte eine kleine Live-Vorschau folgen. Wähle einige Datensätze mit ausdrücklich definierten Sollzuständen im Zielsystem. Nimm einen gewöhnlichen Datensatz, ein fehlendes optionales Feld und einen Datensatz auf, dessen Einwilligungsstatus Marketing ausschließt. Prüfe, was das Zielsystem tatsächlich speichert. Leite das Ergebnis nicht allein aus den Anfragefeldern ab.
Eine synthetische Vorschau und eine Zielprüfung beantworten verschiedene Fragen. Tajos Zuordnungsvorschau testet eine Umwandlung ohne Schreibvorgang im Zielsystem. Die vorgeschlagene Aktivitätsansicht unten zeigt die spätere Grenze: Auch eine angewendete Aktualisierung braucht eine Prüfung des Zielzustands. Solange dieser Schritt als ausstehend markiert ist, wird die Probe nicht mit einem Beleg verwechselt.
Ein abgeschlossener Schreibvorgang braucht weiterhin Belege
Wurde die Kundensynchronisierung abgeschlossen?
Schreibvorgang angewendet. Prüfung ausstehend.
Der Zielzustand wurde noch nicht geprüft.
Sync-Aktivität
- Anfrage angenommen
- Aktualisierung angewendet
- Zielprüfung ausstehend
Beispielhafter Durchlauf · 14:32 UTC
Was wir wissen
- Antwort des Anbieters
- Angenommen
- Ergebnis des Schreibvorgangs
- Angewendet
- Rücklesung aus dem Zielsystem
- Ausstehend
Ein erfolgreicher Aufruf belegt den Endzustand nicht.
Vorgeschlagenes Layout auf Grundlage von Tajos Aktivitätsverlauf. Die Illustration ergänzt einen Prüfstatus und behauptet nicht, dass die Rücklesung aus dem Zielsystem bereits implementiert ist.
Die Vorschau braucht einen begrenzten Umfang und eine klare Abbruchbedingung. Ein Fehler sollte die umfassende Aktivierung verhindern und auf die konkrete Abweichung hinweisen: Felddefinition, Kennung, Typ, Berechtigung oder Zeitablauf. Eine erfolgreiche Vorschau beweist nicht, dass sich alle künftigen Datensätze gleich verhalten. Sie zeigt aber, dass der Vertrag für die ausgewählten Fälle heute funktioniert.
Diese Abfolge trennt zwei Fragen. Die Simulation fragt: „Befolgt der Agent die entworfene Regel, wenn wir die Umgebung kontrollieren?“ Die Live-Vorschau fragt: „Passt die entworfene Regel zu diesem Anbieterkonto?“ Keine der beiden Fragen kann die andere ersetzen.
Die Anleitung zu Reverse ETL erklärt, warum sich die endgültige Aufgabe über viele Datensätze wiederholt. Durch diese Wiederholung verstärkt sich jede Abweichung zwischen dem simulierten und dem echten Vertrag.
Probiere es in einer Welt aus, die du zurücksetzen kannst. Prüfe danach die Welt, die du nicht zurücksetzen kannst.
Häufig gestellte Fragen
Was lässt sich mit einem simulierten Zielsystem testen?
Eine Simulation kann prüfen, ob ein Agent die erwarteten Aufrufe auswählt, Berechtigungen einhält, bekannte Fehler behandelt und den erwarteten Zustand hinterlässt.
Was lässt sich damit nicht belegen?
Die Simulation kann nicht beweisen, dass ihr Anbietermodell vollständig ist. Undokumentiertes Verhalten, Zeitabläufe und kontospezifische Konfigurationen können davon abweichen.
Was sollte auf eine erfolgreiche Simulation folgen?
Führe eine begrenzte Vorschau oder einen Canary-Test im tatsächlichen Zielsystem aus und prüfe den entstandenen Zustand, bevor du die Integration umfassend aktivierst.