Na tej stronie
Zielony wynik testu może ukrywać brakującą regułę. W tym ilustracyjnym przypadku agent ma połączyć sklep z platformą emailową. Serwer testowy przyjmuje aktualizację kontaktu i zwraca schludne 200. Agent kończy zadanie, a test przechodzi.
Rzeczywisty system docelowy ma jeszcze jedną regułę: atrybut niestandardowy trzeba zadeklarować, zanim aktualizacja kontaktu będzie mogła go ustawić. Serwer testowy nie uwzględnił tej reguły. Jego zielony wynik dowodzi czegoś o agencie w świecie testowym. Nie dowodzi niczego o brakującej regule w świecie rzeczywistym.
To podstawowa wymiana w symulacji. Umożliwia bezpieczne powtarzanie działań ryzykownych lub kosztownych. Tworzy też drugi system, którego zachowanie może oddalić się od pierwszego.
Zamiennik pozwala badać działania
Aby przetestować agenta, który działa, daj mu cel, środowisko i obserwowalny stan końcowy. Omówienie symulowanych środowisk agentów opisuje taką strukturę dla zadań przeglądarkowych i pracy z wiedzą. Środowisko pozwala weryfikatorowi porównać stan pozostawiony przez agenta ze znanym dobrym wynikiem.
W integracji zamiennik może udostępniać niewielki zestaw operacji docelowych: listę pól, utworzenie kontaktu, aktualizację kontaktu i odczyt po zmianie. Może zawierać przykład z zadeklarowanym polem FNAME i nieobecnym polem CUSTOM_TIER. Test może poprosić agenta o mapowanie, a następnie odrzucić zapis używający CUSTOM_TIER przed utworzeniem definicji.
Zamiennik jest użyteczny, bo każdy przebieg zaczyna się od tego samego stanu. Można zmieniać jeden warunek naraz: brakujące pole, odmowę dostępu, starą wersję schematu lub niejednoznaczny identyfikator. Można porównać sekwencję wywołań i wynikowy stan agenta między modelami lub promptami.
To mocniejsze od pytania tekstowego o to, co agent zrobiłby. Bada, co naprawdę wywołał w kontrolowanym świecie.
Przykład testowy powinien mieć stan przed każdym wywołaniem i po nim, a nie tylko zaprogramowaną odpowiedź. Jeśli agent utworzy kontakt dwa razy, drugie wywołanie powinno ujawnić zachowanie związane z duplikatem, które chcesz zbadać. Jeśli agent odczyta pole po zapisie, odczyt powinien zwrócić zapisany stan. Inaczej przejdzie test, wysyłając wiarygodne żądanie, podczas gdy test nie odkryje, czy sekwencja utworzyła zamierzony rekord.
Wierność jest częścią testu
Uczciwy zarzut brzmi: „Dostawca ma środowisko testowe. Po co budować kolejne?”. Korzystaj ze środowiska dostawcy, gdy obsługuje potrzebny przypadek i bezpiecznie przechowuje dane. Lokalny zamiennik ma sens, jeśli potrzebujesz deterministycznego resetu, celowych błędów lub testu wywołań niemożliwych do przygotowania u dostawcy. Wymaga też utrzymania. Każda odtworzona reguła może być błędna lub się zestarzeć.
Oficjalna dokumentacja API kontaktów Brevo mówi, że atrybuty kontaktu muszą istnieć na koncie, a wartości o niewłaściwym zadeklarowanym typie są ignorowane. Zamiennik odrzucający każdą błędną wartość zachowywałby się inaczej niż w opisanym przypadku. Mógłby nauczyć agenta oczekiwać błędu, który nigdy nie przyjdzie.
Zapisz, które zachowania dostawcy obejmuje zamiennik. Utrzymuj niewielki zestaw testów kontraktowych wobec prawdziwego API lub wspieranego środowiska testowego. Gdy test ujawni różnicę, popraw zamiennik i dodaj przypadek, który ją wykrył. Symulacja jest modelem dostawcy, nie jego zamiennikiem.
Ta sama dyscyplina dotyczy czasu. Zamiennik, w którym każdy zapis natychmiast staje się widoczny, może przeoczyć proces odczytujący dane zbyt wcześnie. Zamiennik opóźniający każdy zapis może wymyślić błędy nieobecne u dostawcy. Modeluj opóźnienia tylko tam, gdzie wpływają na badaną decyzję, a resztę oznacz jako poza zakresem symulacji. Test zaliczony w takim środowisku znaczy dokładnie: agent wykonał te działania według tych modelowanych reguł.
Przewodnik Tajo po konektorze Brevo opisuje ten sam problem od strony sprzedawcy: udane żądanie może pozostawić pole puste. Test pomaga tylko, gdy sprawdza pole, nie samą odpowiedź HTTP.
Symulowany cel bada agenta według modelowanych reguł. Testy kontraktu porównują te reguły z rzeczywistym celem przed ograniczonym podglądem.
Od bezpiecznej próby do ograniczonego dowodu
Po udanej symulacji powinien nastąpić mały podgląd na żywo. Wybierz kilka rekordów o jawnie określonych stanach docelowych. Dodaj zwykły rekord, rekord bez pola opcjonalnego i rekord, którego stan zgody zakazuje użycia marketingowego. Sprawdź, co cel faktycznie zapisuje. Nie wyciągaj wniosku tylko z wysłanego żądania.
Próba na danych syntetycznych i kontrola systemu docelowego odpowiadają na różne pytania. Podgląd mapowania Tajo testuje przekształcenie bez zapisu do systemu docelowego. Proponowany widok aktywności pokazuje kolejny próg: nawet zastosowana aktualizacja wymaga sprawdzenia stanu docelowego. Gdy ten krok jest oznaczony jako oczekujący, próby nie da się pomylić z dowodem.
Zakończony zapis nadal wymaga dowodów
Czy synchronizacja klienta dobiegła końca?
Zapis zastosowany. Weryfikacja oczekuje.
Stan w systemie docelowym nie został jeszcze sprawdzony.
Aktywność synchronizacji
- Żądanie przyjęte
- Aktualizacja zastosowana
- Kontrola systemu docelowego oczekuje
Przykładowe wykonanie · 14:32 UTC
Co wiemy
- Odpowiedź dostawcy
- Przyjęte
- Wynik zapisu
- Zastosowana
- Ponowny odczyt z systemu docelowego
- Oczekuje
Udane wywołanie nie dowodzi stanu końcowego.
Proponowany układ oparty na rejestrze aktywności Tajo. Ilustracja dodaje stan weryfikacji, ale nie twierdzi, że ponowny odczyt z systemu docelowego jest już wdrożony.
Podgląd powinien mieć wąski zakres i jasny warunek zatrzymania. Błąd powinien powstrzymać szeroką aktywację i wskazać konkretną różnicę: definicję pola, identyfikator, typ, uprawnienie lub czas. Udany podgląd nie dowodzi, że każdy przyszły rekord zachowa się tak samo. Pokazuje jednak, że kontrakt działa dziś dla wybranych przypadków.
Ta sekwencja oddziela dwa pytania. Symulacja pyta: „Czy agent stosuje zaprojektowaną regułę, gdy kontrolujemy świat?”. Podgląd na żywo pyta: „Czy zaprojektowana reguła pasuje do tego konta dostawcy?”. Żadne nie zastępuje drugiego.
Przewodnik po reverse ETL wyjaśnia, dlaczego końcowe zadanie powtarza się na wielu rekordach. To powtarzanie wzmacnia każdą różnicę między symulowanym a rzeczywistym kontraktem.
Ćwicz w świecie, który możesz zresetować. Potem sprawdź ten, którego nie możesz.
Najczęściej Zadawane Pytania
Co można przetestować w symulowanym systemie docelowym?
Można sprawdzić, czy agent wybiera oczekiwane wywołania, respektuje uprawnienia, obsługuje znane błędy i pozostawia oczekiwany stan w symulacji.
Czego symulacja nie dowodzi?
Nie potwierdza, że jej model zachowania dostawcy jest kompletny. Nieudokumentowane zachowania, opóźnienia i konfiguracja konkretnego konta mogą się różnić.
Co zrobić po zaliczeniu symulacji?
Uruchom ograniczony podgląd lub test na małej grupie w rzeczywistym systemie docelowym, a przed szeroką aktywacją sprawdź wynikowy stan.