Co může dokázat simulovaný cílový systém

Zelený test může skrývat chybějící pravidlo. V tomto ilustrativním případě má agent propojit obchod s e-mailovou platformou. Testovací server přijme aktualizaci kontaktu a vrátí úhledné 200. Agent úlohu dokončí a test projde.

Skutečný cíl má jednu další podmínku: vlastní atribut musí být deklarován předtím, než jej aktualizace kontaktu může nastavit. Testovací server ji nemodeloval. Jeho zelený výsledek dokazuje něco o agentovi v testovacím světě. O chybějícím pravidle v živém systému nedokazuje nic.

To je základní kompromis simulace. Nebezpečné nebo drahé akce lze opakovat. Současně však vzniká druhý systém, jehož chování se může od prvního odchýlit.

Náhrada umožňuje testovat akce

Chcete-li testovat jednajícího agenta, dejte mu cíl, prostředí a pozorovatelný koncový stav. Zdrojová diskuse o simulovaných prostředích agentů popisuje tuto strukturu pro úlohy v prohlížeči a znalostní práci. Prostředí umožňuje kontrole porovnat stav, který agent zanechal, se známým správným výsledkem.

U integrace může náhrada vystavit několik cílových operací: vypsat pole, vytvořit kontakt, aktualizovat kontakt a znovu jej načíst. Testovací sada může obsahovat deklarované pole FNAME a chybějící pole CUSTOM_TIER. Test může požádat agenta o návrh mapování a odmítnout zápis používající CUSTOM_TIER, pokud definice neexistuje.

Náhrada pomáhá, protože každý běh začíná stejným stavem. Vždy lze změnit jedinou podmínku: chybějící pole, odmítnuté oprávnění, zastaralou verzi schématu nebo nejednoznačný identifikátor. Lze porovnávat posloupnost volání a výsledný stav různých modelů nebo promptů.

Je to silnější než textová otázka, co by agent udělal. Testuje to, co v kontrolovaném světě skutečně zavolal.

Každému volání dejte stav před i po něm, nejen předpřipravenou odpověď. Vytvoří-li agent kontakt dvakrát, druhé volání má ukázat chování při duplikátu, které chcete testovat. Pokud po zápisu čte pole, čtení má vrátit uložený stav. Jinak může agent projít testem odesláním věrohodného požadavku, aniž test zjistí, zda posloupnost vytvořila zamýšlený záznam.

Věrnost je součást testu

Oprávněná námitka zní: „Dodavatel má sandbox, proč stavět další?“ Použijte sandbox dodavatele, pokud umožňuje potřebný případ a bezpečně zachází s daty. Místní náhrada si své místo zaslouží, když potřebujete deterministické resetování, cílené poruchy nebo test volání, která sandbox neumí připravit. Vyžaduje však údržbu. Každé modelované pravidlo může být chybné nebo zastarat.

Oficiální API kontaktů Brevo říká, že atributy kontaktu musí v účtu existovat a hodnoty nesprávného deklarovaného typu jsou ignorovány. Náhrada odmítající každou špatně formátovanou hodnotu by se chovala jinak než tento zdokumentovaný případ. Mohla by agenta naučit čekat chybu, která ve skutečnosti nepřijde.

Sepište, které chování dodavatele náhrada pokrývá. Udržujte malou sadu smluvních sond vůči skutečnému API nebo jeho podporovanému testovacímu prostředí. Když sonda najde rozdíl, aktualizujte náhradu a přidejte případ, který jej odhalil. Simulace je model dodavatele, ne jeho náhrada.

Stejná kázeň platí pro čas. Náhrada, která každý zápis okamžitě zpřístupní, může přehlédnout postup čtoucí příliš brzy. Náhrada, která každý zápis zdrží, může vymyslet selhání, která dodavatel nemá. Modelujte čas jen tam, kde ovlivňuje testované rozhodnutí, a zbytek označte za mimo rozsah simulace. Prošlý test pak znamená přesně: tento agent vykonal tyto akce podle těchto modelovaných pravidel.

Průvodce konektorem Brevo od Tajo popisuje stejný praktický problém z pohledu obchodníka: úspěšný požadavek může zanechat pole prázdné. Test má smysl, jen když ověří pole, ne pouze HTTP odpověď.

Simulovaný cíl obnovitelný stav známé poruchy

Smluvní sondy srovnání chování záznam rozdílů

Živý cíl nastavení účtu pozorovaný stav

Simulovaný cíl testuje agenta podle modelovaných pravidel. Smluvní sondy je porovnávají se živým cílem před omezeným náhledem.

Od bezpečné zkoušky k omezeným důkazům

Po úspěšné simulaci má následovat malý živý náhled. Vyberte několik záznamů s jasně určenými očekávanými cílovými stavy. Zahrňte běžný záznam, chybějící nepovinné pole a záznam, jehož stav souhlasu zakazuje marketingové použití. Ověřte, co cíl skutečně uložil. Nevyvozujte výsledek jen z těla požadavku.

Syntetický náhled a kontrola cílové služby odpovídají na různé otázky. Náhled mapování Tajo zkouší převod bez zápisu do cíle. Navržený pohled na aktivitu níže ukazuje další hranici: i provedená změna vyžaduje kontrolu stavu v cíli. Poslední krok zůstává označen jako čekající, aby se zkouška nezaměnila za důkaz.

TajoIlustrace konceptu · Ukázková data

Dokončený zápis stále potřebuje důkaz

Skončila synchronizace zákazníků?

Aplikace Tajo MCPAktivita

Zápis byl proveden. Ověření čeká.

Stav v cílové službě zatím nebyl zkontrolován.

Aktivita synchronizace

1. Požadavek přijat
2. Změna provedena
3. Kontrola cílové služby čeká

Ukázkové spuštění · 14:32 UTC

Co víme

Odpověď poskytovatele

Přijato

Výsledek zápisu

Provedeno

Zpětné načtení z cíle

Čeká

Zobrazit původní událost

Úspěšné volání nedokazuje konečný stav.

Navržený pohled na důkazy

Zkontrolovat aktivitu

Navržené uspořádání vychází z přehledu aktivity Tajo. Ilustrace přidává stav ověření; netvrdí, že zpětné načítání z cíle už bylo implementováno.

Náhled má mít úzký rozsah a jasnou podmínku zastavení. Selhání má zabránit široké aktivaci a ukázat přesný nesoulad: definice pole, identifikátor, typ, oprávnění nebo časování. Úspěšný náhled nedokazuje, že všechny budoucí záznamy dopadnou stejně. Dokazuje však, že smlouva dnes pro vybrané případy funguje.

Tato posloupnost odděluje dvě otázky. Simulace se ptá: „Dodržuje agent navržené pravidlo, když ovládáme svět?“ Živý náhled se ptá: „Odpovídá navržené pravidlo tomuto účtu dodavatele?“ Jedna otázka nenahradí druhou.

Průvodce reverzním ETL vysvětluje, proč se výsledná práce opakuje na mnoha záznamech. Opakování zvětšuje každý rozdíl ponechaný mezi simulovanou a skutečnou smlouvou.

Zkoušejte ve světě, který můžete obnovit. Potom zkontrolujte svět, který obnovit nemůžete.