Na tejto stránke
Zelený test môže skrývať chýbajúce pravidlo. V tomto ilustratívnom prípade má agent prepojiť obchod s e-mailovou platformou. Testovací server prijme aktualizáciu kontaktu a vráti úhľadnú odpoveď 200. Agent úlohu dokončí a test prejde.
Skutočný cieľ má ďalšie pravidlo: vlastný atribút musí byť definovaný skôr, než ho možno nastaviť aktualizáciou kontaktu. Testovací server toto pravidlo nemodeloval. Jeho zelený výsledok dokazuje niečo o agentovi v testovacom svete. O chýbajúcom pravidle v živom systéme nedokazuje nič.
To je základná výmena pri simulácii. Nebezpečné alebo drahé kroky sa dajú opakovať. Zároveň však vzniká druhý systém, ktorého správanie sa môže od prvého vzdialiť.
Náhrada umožňuje testovať činy
Ak chcete testovať konajúceho agenta, dajte mu cieľ, prostredie a pozorovateľný konečný stav. Zdrojová diskusia o simulovaných prostrediach pre agentov opisuje túto štruktúru pri úlohách v prehliadači a znalostnej práci. Prostredie umožňuje overovateľovi porovnať stav zanechaný agentom so známym správnym výsledkom.
Pri integrácii by náhrada mohla sprístupniť malý súbor cieľových operácií: vypísať polia, vytvoriť kontakt, aktualizovať ho a znova ho načítať. Mohla by obsahovať testovací stav s definovaným poľom FNAME a chýbajúcim CUSTOM_TIER. Test by mohol požiadať agenta, aby navrhol mapovanie, a potom odmietnuť zápis používajúci CUSTOM_TIER bez predchádzajúcej definície.
Náhrada je užitočná, pretože každý beh začína v rovnakom stave. Naraz môžete meniť jednu podmienku: chýbajúce pole, odmietnuté oprávnenie, zastaranú verziu schémy či nejednoznačný identifikátor. Medzi modelmi alebo promptmi môžete porovnávať postupnosť volaní agenta aj výsledný stav.
To je silnejší test než iba textová otázka, čo by agent urobil. Overuje, čo v kontrolovanom svete naozaj zavolal.
Testovacie dáta musia niesť stav pred každým volaním aj po ňom, nie iba pripravenú odpoveď. Ak agent vytvorí kontakt dvakrát, druhé volanie má odhaliť správanie pri duplicite, ktoré chcete testovať. Ak po zápise číta pole, čítanie má vrátiť uložený stav. Inak môže agent prejsť testom odoslaním vierohodnej požiadavky, hoci test nezistí, či jeho postupnosť vytvorila zamýšľaný záznam.
Vernosť patrí do testu
Oprávnená námietka znie: „Poskytovateľ má testovacie prostredie; načo budovať ďalšie?“ Použite ho, keď podporuje potrebný prípad a chráni dáta. Miestna náhrada má zmysel, ak potrebujete deterministický návrat do počiatočného stavu, zámerne vyvolané chyby alebo test volaní, ktoré prostredie poskytovateľa nedokáže pripraviť. Zároveň vyžaduje údržbu. Každé modelované pravidlo môže byť nesprávne alebo zostarnúť.
Oficiálna dokumentácia API kontaktov Brevo uvádza, že atribúty kontaktu musia byť prítomné v účte a hodnoty s nesprávnym definovaným typom sa ignorujú. Náhrada, ktorá odmietne každú chybnú hodnotu, by sa správala inak než tento zdokumentovaný prípad. Mohla by agenta naučiť očakávať chybu, ktorá nepríde.
Zapíšte si, ktoré správania poskytovateľa náhrada pokrýva. Udržiavajte malý súbor sond kontraktu proti skutočnému API alebo jeho podporovanému testovaciemu prostrediu. Keď sonda odhalí rozdiel, aktualizujte náhradu a pridajte prípad, ktorý ho odhalil. Simulácia je model poskytovateľa, nie jeho náhrada.
Rovnaká disciplína platí pre čas. Náhrada, ktorá okamžite zviditeľní každý zápis, môže prehliadnuť postup, ktorý číta príliš skoro. Náhrada, ktorá každý zápis oneskorí, môže vymyslieť zlyhania, ktoré poskytovateľ nespôsobuje. Časovanie modelujte len tam, kde ovplyvňuje testované rozhodnutie, a ostatné označte za hranicu simulácie. Úspešný test potom znamená presne toto: agent vykonal tieto kroky podľa týchto modelovaných pravidiel.
Tajov sprievodca konektorom Brevo opisuje rovnaký praktický problém z pohľadu obchodníka: úspešná požiadavka môže zanechať pole prázdne. Test má hodnotu len vtedy, keď kontroluje pole, nie iba odpoveď HTTP.
Simulovaný cieľ testuje agenta podľa modelovaných pravidiel. Sondy kontraktu porovnajú tieto pravidlá so živým cieľom pred ohraničenou ukážkou.
Od bezpečného nácviku k ohraničenému dôkazu
Po úspešnej simulácii má nasledovať malá živá ukážka. Vyberte niekoľko záznamov s jasne určeným očakávaným stavom v cieli. Zahrňte bežný záznam, chýbajúce voliteľné pole a záznam, ktorého stav súhlasu zakazuje marketingové použitie. Overte, čo cieľ skutočne uloží. Výsledok neodvodzujte len z obsahu požiadavky.
Syntetický náhľad a kontrola cieľovej služby odpovedajú na rôzne otázky. Náhľad mapovania Tajo skúša prevod bez zápisu do cieľa. Navrhovaný pohľad na aktivitu nižšie ukazuje ďalšiu hranicu: aj vykonaná zmena vyžaduje kontrolu stavu v cieli. Posledný krok zostáva označený ako čakajúci, aby sa skúška nezamenila za dôkaz.
Dokončený zápis stále potrebuje dôkaz
Skončila sa synchronizácia zákazníkov?
Zápis sa vykonal. Overenie čaká.
Stav v cieľovej službe sa zatiaľ neskontroloval.
Aktivita synchronizácie
- Požiadavka prijatá
- Zmena vykonaná
- Kontrola cieľovej služby čaká
Ukážkové spustenie · 14:32 UTC
Čo vieme
- Odpoveď poskytovateľa
- Prijaté
- Výsledok zápisu
- Vykonané
- Spätné načítanie z cieľa
- Čaká
Úspešné volanie nedokazuje konečný stav.
Navrhované rozloženie vychádza z prehľadu aktivity Tajo. Ilustrácia pridáva stav overenia; netvrdí, že spätné načítanie z cieľa už bolo implementované.
Ukážka má mať úzky rozsah a jasnú podmienku zastavenia. Zlyhanie má zabrániť širokej aktivácii a ukázať na presný nesúlad: definíciu poľa, identifikátor, typ, oprávnenie alebo časovanie. Úspešná ukážka nedokazuje, že sa všetky budúce záznamy budú správať rovnako, no potvrdzuje, že kontrakt dnes funguje pre vybrané prípady.
Tento postup oddeľuje dve otázky. Simulácia sa pýta: „Dodrží agent navrhnuté pravidlo, keď svet ovládame?“ Živá ukážka sa pýta: „Zodpovedá navrhnuté pravidlo tomuto účtu poskytovateľa?“ Jedna otázka nemôže zastúpiť druhú.
Sprievodca reverzným ETL vysvetľuje, prečo sa výsledná úloha opakuje na mnohých záznamoch. Opakovanie znásobuje každý rozdiel medzi simulovaným a skutočným kontraktom.
Nacvičujte vo svete, ktorý môžete obnoviť. Potom preskúmajte svet, ktorý obnoviť nemôžete.
Často Kladené Otázky
Čo možno testovať v simulovanom cieľovom systéme?
Či agent vyberie očakávané volania, rešpektuje oprávnenia, zvláda známe chyby a zanechá v simulácii očakávaný stav.
Čo simulácia nedokáže preukázať?
Nedokáže potvrdiť, že jej model poskytovateľa je úplný. Nedokumentované správanie, časovanie aj nastavenia konkrétneho účtu sa môžu líšiť.
Čo má nasledovať po úspešnej simulácii?
Spustite ohraničenú ukážku alebo skúšobný beh proti skutočnému cieľu a pred širšou aktiváciou skontrolujte výsledný stav.