Az AI-ügynökök orkesztrációjának bevált gyakorlatai: hibák, jóváhagyások és újrapróbálkozások kezelése

Rendkívül hatékonynak hangzik, ha több ügynök dolgozik ugyanazon a projekten. Az egyik megtervezi a munkát, a másik a dizájnt intézi, a harmadik pedig megírja a kódot. Ez működik is – egészen addig, amíg nem. A hibák pedig gyakrabban fordulnak elő, mint szeretnénk.

Ezeknek a hibáknak a megelőzése gondos munkafolyamat-tervezést igényel. Nézzük meg tehát, mitől válnak megbízhatatlanná az orkesztrált munkafolyamatok, és ismerjük meg az orkesztráció legjobb gyakorlatait az éles üzemi megbízhatóság érdekében.

Mi az MI-ügynökök orkesztrációja?

Az MI-ügynökök orkesztrációja több MI-ügynököt, modellt és eszközt hangol össze egy többlépéses feladat elvégzéséhez. Valakinek – vagy valaminek – azonban továbbra is el kell döntenie, melyik ügynök fut először, milyen információkat kap, és mi történik, miután végzett. Ez az orkesztrátor szerepe, amely lehet egy menedzserként működő MI-ügynök vagy egy szoftveresen vezérelt végrehajtási réteg.

Egyszerűen fogalmazva az orkesztrációs réteg kisebb feladatokra bont egy célt, nyomon követi a függőségeket, a megfelelő ügynökökre bízza a végrehajtást, kezeli a megosztott kontextust, és egyesíti a kimeneteket.

Hogyan működik az MI-ügynökök orkesztrációja: a végrehajtó motor belülről

Nagyítás

Nézzük meg, mi történik, miután feladatot ad egy orkesztrátornak.

Vegyünk egy példát a Perplexity Computer workshopjából: egy ügyfélintelligencia-irányítópult elkészítése a Salesforce, a Snowflake, az e-mailek, a naptár és a friss hírek információi alapján.

1. A cél megértése és a munka megtervezése. Az orkesztrátor a kért eredményből indul ki, és explicit függőségekkel rendelkező feladatokra bontja azt. Irányítópult-példánkban ez a különböző forrásokból származó információk összegyűjtését és kész munkatermékké alakítását jelenti. A tervező meghatározza, mely lépések függnek másoktól, és melyek futtathatók egymástól függetlenül.
2. A feladatok továbbítása a megfelelő ügynökökhöz. Az orkesztrátor azonosítja azokat a feladatokat, amelyek függőségei teljesültek, és a munkát specializált ügynökökre vagy modellekre bízza. A függő feladatok megvárják az előfeltételeiket. A Perplexity Computer több élvonalbeli modellt használ, és a munkafolyamat különböző részeit az adott feladatokra alkalmas rendszerekhez irányítja. Ez azt is lehetővé teszi, hogy a független munkák párhuzamosan fussanak.
3. Eszközhívások végrehajtása ellenőrzött környezetekben. Az ügynökök eszközökön keresztül lépnek kapcsolatba a környezetükkel, például webes kereséssel, API-kkal, csatlakoztatott alkalmazásokkal, fájlműveletekkel vagy kódvégrehajtással. A végrehajtási réteg futtatja ezeket a műveleteket, és visszaadja az eredményeket az ügynököknek.
4. Eredmények és kontextus átadása az ügynökök között. Amikor egy ügynök befejezi a feladatát, a láncban következő ügynöknek szüksége van a releváns kimenetre a folytatáshoz. Egy átadási rekord tartalmazhat feladatazonosítót, kimeneti hivatkozást, sémaverziót és forrás-metaadatokat. Az orkesztrátor koordinálja ezeket az átadásokat, miközben megőrzi a további lépésekhez szükséges kontextust. Fontos, hogy az ügynököknek nem kell a saját kontextusablakukban hordozniuk minden más ügynök munkájának teljes előzményét.
5. A végrehajtási állapot rögzítése az ügynökkontextustól elkülönítve. Ahogy az ügynökök elindítják, befejezik vagy sikertelenül zárják a feladatokat, a végrehajtó motor frissít egy tartós munkafolyamat-rekordot a feladatok állapotával, a végrehajtási kísérletekkel, a kimeneti hivatkozásokkal és a hátralévő munkával. Ez a rekord lehetővé teszi, hogy az orkesztrátor nyomon kövesse az előrehaladást, és megszakítások után folytassa a munkát anélkül, hogy egy LLM-re kellene hagyatkoznia a munkafolyamat beszélgetési előzményekből történő rekonstruálásához.
6. Az eredmények ellenőrzése és a következő lépés eldöntése. Amikor egy feladat visszatér, az orkesztrációs réteg ellenőrzi, hogy a kimenete megfelel-e az elvárt szerződésnek, és teljesülnek-e a következő feladat függőségei. Ha probléma merül fel, a munkafolyamat javítás céljából visszatérhet egy korábbi lépéshez, vagy szüneteltethető. Ellenkező esetben a befejezés felé halad.

A látszólag egyszerű MI-ügynök-orkesztráció mögött rengeteg mozgó alkatrész dolgozik. Az, hogy hogyan szervezi meg az ügynökök koordinációját, meghatározza, mekkora kontrollja van a végrehajtás felett. És persze ez a koordináció többletterhet is jelent. Ezért nem mindig éri meg.

Mikor érdemes MI-ügynök-orkesztrációt használni?

Akkor érdemes a többügynökös orkesztrációt fontolóra venni, ha a feladat különböző részei eltérő szakértelmet igényelnek, a független munkák párhuzamosan futhatnak, vagy a következő lépést nem lehet előre meghatározni.

Az orkesztráció tehát három esetben hasznos:

• A feladatok különböző specializációkat igényelnek. Egy programozási projektnek például előnyös lehet, ha külön ügynök végzi a tervezést, a dizájnt, a fejlesztést és az ellenőrzést.
• A független feladatok párhuzamosan futhatnak. Ahelyett, hogy egyetlen ügynök mindent egymás után végezne el, több ügynök dolgozhat egyszerre, és visszaküldheti az eredményeit egy orkesztrátornak.
• A probléma nyitott végű. Előfordulhat, hogy az ügynököknek különböző megközelítéseket kell kipróbálniuk, döntéseket kell hozniuk és együtt kell működniük ahelyett, hogy egy előre meghatározott sorrendet követnének.

Ezeken kívül az orkesztráció csupán egy költséges trend. A több ügynök több koordinációt és potenciálisan magasabb tokenköltségeket is jelent.

„Általában a legegyszerűbb megoldással kezdem, és onnan építkezem. Ha ismerjük a lépéseket, és azok megismételhetők, az valószínűleg egy munkafolyamat. Csak akkor látom értelmét több ügynök bevezetésének, ha eltérő felelősségi körökkel, jogosultságokkal vagy felhasználókkal rendelkeznek” – mondja Josh Spilker, az AirOps keresőmarketingért felelős vezetője.

Még ekkor is mérlegelje az előnyöket a további modellhívásokkal, átadásokkal, késleltetéssel és hibapontokkal szemben.

MI-ügynökök orkesztrációs architektúrái és azok kompromisszumai

Az ügynökök koordinációjának három gyakori felépítési módja a központosított, a decentralizált és a hierarchikus orkesztráció. A megfelelő architektúra kiválasztása egyetlen kérdésen múlik: Ki irányítja a munkát, és hogyan koordinálnak egymással az ügynökök?

Központosított orkesztráció

A központosított orkesztrációban egyetlen orkesztrátor irányítja a folyamatot. Felbontja a feladatot, a munkát szakosodott ügynökökre bízza, nyomon követi az előrehaladásukat, és egyesíti az eredményeiket.

Nagyítás

A kompromisszum: A központosított koordináció megkönnyíti a végrehajtás nyomon követését és a közös szabályok alkalmazását egyetlen vezérlési ponton. Az orkesztrátor azonban szűk keresztmetszetté válhat, és a meghibásodása az egész munkafolyamatot megszakíthatja, hacsak a rendszer nem támogatja a helyreállítást.

Decentralizált orkesztráció

A decentralizált orkesztrációban az ügynökök közvetlenebbül koordinálnak egymással, ahelyett hogy egyetlen menedzserre hagyatkoznának minden döntésnél. Üzeneteket válthatnak, olvashatják a megosztott állapotot, és önállóan határozhatják meg a következő lépéseiket.

Nagyítás

A kompromisszum: Az ügynökök anélkül működhetnek, hogy egy központi tervezőre várnának, ami ezt a megközelítést hasznossá teszi a feltáró jellegű munkához és a független hozzájárulásokhoz. A koordináció azonban nehezebbé válik, amikor az ügynökök nem értenek egyet, megosztott információkat frissítenek, vagy egységes eredményre kell jutniuk.

Hierarchikus orkesztráció

A hierarchikus orkesztráció több szintre terjeszti ki a menedzseralapú megközelítést. Egy legfelső szintű orkesztrátor alárendelt orkesztrátorokra ruházza a felelősséget, amelyek a szakosodott ügynökök saját csoportjait koordinálják.

Gondoljunk egy olyan vállalati munkafolyamatra, amelyben értékesítési, pénzügyi és jogi csapatok vesznek részt. Egy legfelső szintű orkesztrátor minden munkaterületet egy adott szakterületre szakosodott koordinátorra bízhat. Ezek a koordinátorok ezután a saját szakértő ügynökeiket irányítanák, és összesített eredményekről számolnának be.

Ez a struktúra akkor lehet hasznos, ha a munkafolyamatok túl szerteágazóak ahhoz, hogy egyetlen orkesztrátor hatékonyan kezelje őket.

Nagyítás

A kompromisszum: A hierarchiák lehetővé teszik a csapatok számára, hogy felosszák egymás között a koordinációs felelősségi köröket, és a hibákat akár az egyes ágakon belül kezeljék. Ugyanakkor további átadásokkal, összetettebb állapotkezeléssel és nagyobb működési többletteherrel járnak. A helyi helyreállítás attól is függ, hogyan valósítják meg az ellenőrzőpontokat és a végrehajtási állapotot.

Az architektúrák összehasonlítása:

Szekvenciális, párhuzamos és átadásalapú végrehajtás

Van még egy különbség, amelyet érdemes megérteni. Az architektúra határozza meg, ki koordinálja az ügynököket. A végrehajtási minta pedig azt, hogyan haladnak előre a feladataik.

A három végrehajtási minta a következő:

• Szekvenciális munkafolyamatok: Az ügynökök előre meghatározott sorrendben dolgoznak, és az egyik ügynök eredménye a másik bemenetévé válik.
• Párhuzamos végrehajtás: Egymástól független ügynökök dolgoznak egyidejűleg.
• Átadásalapú végrehajtás: A feladat előrehaladtával a vezérlés szakosodott ügynökök között vándorol. Ez akkor hasznos, ha a következő lépés kezelésére egy másik ügynök alkalmasabb, bár minden átadásnak meg kell őriznie a folytatáshoz szükséges információkat.

Ezek a minták nem zárják ki egymást, és nem feleltethetők meg egy az egyben az orkesztrációs architektúráknak. A cél az, hogy azt a legegyszerűbb struktúrát válassza, amely támogatja a munkafolyamat függőségeit, koordinációs követelményeit és az elfogadható működési többletterhet.

Gyakori hibák az MI-ügynökök orkesztrációjában

Az orkesztráció során bármi elromolhat, az egyszerű figyelmetlenségektől a bonyolult akadályokig. Néha egy ügynök látszólag helyesen végzi a dolgát, miközben a teljes munkafolyamat kudarcot vall. A szakemberek tapasztalatai alapján összegyűjtöttük a megbízhatatlan orkesztrált munkafolyamatok mögött álló leggyakoribb hibákat – érdemes figyelni rájuk:

• Információvesztéssel járó ügynökátadások. Az orkesztrátor összefoglalt tervet ad át egy szakosodott ügynöknek, de az összefoglalóból kimaradnak korlátozások, függőségek vagy megvalósítási részletek.
• Idő előtti összefésülő (fan-in) végrehajtás. Egy későbbi lépésért felelős ügynök már azelőtt elkezdi összesíteni az eredményeket, hogy az összes megelőző feladat befejeződött volna.
• Nem determinisztikus frissítések a megosztott állapotban. A párhuzamos ügynökök ugyanazokba az állapotkulcsokba írnak, egyértelműen meghatározott egyesítési szemantika nélkül. Attól függően, hogy a keretrendszer hogyan kezeli a frissítéseket, ez elveszett írásokat, duplikált adatokat, sorrendfüggő kimenetet vagy ütköző módosításokat eredményezhet.
• Eltérés az ellenőrzőpontok és a mellékhatások között. Egy feladat külső műveletet hajt végre, de a sikeres végrehajtás nem kerül tartósan rögzítésre, mielőtt a feldolgozó hibára futna. Helyreállításkor az orkesztrátor befejezetlen feladatot lát, és újra lefuttatja.
• Versenyhelyzetek az emberi jóváhagyás utáni folytatáskor. A végrehajtás szüneteltetése és folytatása saját szinkronizációs problémákat okoz.
• Delegálási hurkok és felerősödő újrapróbálkozások. Az ügynökök újra és újra egymásnak adják át a munkát, mert a felelősségi köreik átfedik egymást, a függőségek körkörösek, vagy a befejezési feltételek nem egyértelműek.
• Végrehajtási biztonságnak vélt utasításszintű kontrollok. Egy orkesztrátor utasíthatja az ügynököket, hogy ne férjenek hozzá bizonyos erőforrásokhoz, vagy ne hajtsanak végre érzékeny műveleteket, de a modellnek adott utasítások nem érvényesítenek operációs rendszeri jogosultságokat, hálózati korlátozásokat vagy engedélyezési határokat. A Perplexity biztonságtechnikai kutatása rávilágít, miért léphetik át az ügynökök a biztonsági határokat jogos céljaik követése közben, akár rosszindulatú utasítások nélkül is

Figyelje meg, mennyire különböznek ezek a hibák. Egy idő előtti ütemezőállapot-váltás vagy egy nem egyértelmű külső írás egyaránt hibás eredményhez vezethet, de a végrehajtási életciklus különböző részeiből erednek. Ezért a megbízható orkesztrációhoz több kell, mint a promptok javítása vagy újrapróbálkozások hozzáadása.

7 bevált gyakorlat az MI-ügynökök orkesztrációjához a megbízható éles működésért

1. Határozzon meg explicit feladatszerződéseket, elfogadási kritériumokat és leállási feltételeket

A homályos célok és a tisztázatlan „kész” definíció gyakran vezetnek kiábrándító eredményekhez az ügynökök munkájában. A megoldás a promptszerződés (egy ügynöknek szóló feladatleírás): még a végrehajtás megkezdése előtt állapodjon meg a célban, a korlátozásokban, a kimeneti formátumban és a hibafeltételekben.

Például így határozhat meg szerződést egy olyan ügynök számára, amelynek egy időnként hibára futó integrációs teszt javítása a feladata:

• Cél: A fizetési (checkout) API instabil integrációs tesztje mögötti ok azonosítása és javítása.
• Bemenetek: A teszt forráskódja, a CI hibanaplói, a legutóbbi commitok és a releváns alkalmazáskód.
• Korlátozások: Ne kapcsoljon ki teszteket, ne lazítsa az ellenőrzéseket (assertionöket), és ne módosítsa az alkalmazás nem kapcsolódó működését.
• Elvárt kimenet: Egy kódjavítás (patch), a kiváltó ok magyarázata és a tesztfuttatás eredményei.
• Elfogadási kritériumok: A korábban hibára futó teszt 10 egymást követő futtatás során sikeres, és a releváns regressziós tesztcsomag is sikeresen lefut.
• Hibafeltételek: A kiváltó ok nem állapítható meg, a javítás regressziókat okoz, vagy a szükséges tesztkörnyezet nem érhető el.

Van azonban egy másik fontos szempont is: mikor kell az ügynöknek leállnia?

Az ügynök ne iteráljon a végtelenségig csak azért, mert még nem hozott kielégítő eredményt. Határozza meg, mi számít sikeres befejezésnek, mikor kell egy részben elvégzett feladatot visszaadni, és mikor kell leállni, mert egy követelmény nem teljesíthető. Állítson be maximális delegálási mélységet és iterációs korlátokat vagy végrehajtási kereteket, hogy a megoldatlan feladatokból ne legyenek végtelen hurkok.

Térjünk vissza a CI-példánkhoz. A következő leállási feltételeket határozhatja meg:

• Siker: A javítás 10 egymást követő tesztfuttatáson és a releváns regressziós tesztcsomagon is sikeresen átmegy.
• Iterációs korlát: Az ügynök legfeljebb két javítási kísérletet tehet.
• Végrehajtási keret: Az ügynöknek 60 perc után le kell állnia, még akkor is, ha a probléma megoldatlan marad.
• Delegálási korlát: Az ügynök egyetlen szakosodott ügynöknek delegálhat munkát, további alügynököknek pedig már nem.
• Részleges befejezés: Ha mindkét kísérlet sikertelen, vagy lejár az időkorlát, az ügynök visszaadja a megállapításait, a megkísérelt módosításokat és a teszteredményeket.
• Blokkolt végrehajtás: Ha a tesztkörnyezet nem érhető el, az ügynök leáll, és jelzi az akadályt ahelyett, hogy sikert állítana.

2. Tartsa egyszerűen az orkesztrátorokat, és írja elő a strukturált átadásokat

A fejlesztők néha túl sok feladatot bíznak az orkesztrátorra, amely ahelyett, hogy a szakosodott ügynököket koordinálná, maga kezd kódot írni, hibát keresni vagy részletes ellenőrzéseket végezni. Ez szűk keresztmetszetet hoz létre: az orkesztrátor a megvalósítás részleteire költi a kontextuskeretét, késlelteti a delegálást, és elmossa az eredményekért viselt felelősséget.

Hagyja tehát, hogy az orkesztrátorok a saját dolgukat végezzék, és írja elő, hogy az átadások konkrét műtermékekre hivatkozzanak: az eredeti feladatra, a releváns bemenetekre, a kimeneti műtermékekre, a végrehajtási állapotra és az esetleges megoldatlan problémákra.

Vegyük a következő példát: a status: completed az ügynökre bízott munkára vonatkozik, nem a teljes munkafolyamatra. Mivel a tesztek még pending állapotban vannak, az orkesztrátornak nem szabad jóváhagynia a végeredményt.

3. Tárolja tartósan a munkafolyamat állapotát, és tartsa kordában a kontextus növekedését

Az ügynök beszélgetési előzményei nem megbízható nyilvántartásai a munkafolyamat előrehaladásának. Amikor megtelik a kontextusablak, az automatikus tömörítés fontos részleteket hagyhat ki. Ha pedig egy feldolgozó összeomlik, a következő ügynöknek tudnia kell, mely lépések készültek el ténylegesen.

Ha például a kódoló ügynök létrehoz egy javítást, majd összeomlik, a következő feldolgozónak le kell kérnie a mentett műterméket, és a rögzített munkafolyamat-állapottól kell folytatnia. Ha azonban az ügynök egy külső CI-futtatást is elindított, az orkesztrátornak a művelet megismétlése előtt külön egyeztetnie kell ezt a futtatást

Tartsa tehát külön a végrehajtási állapotot az ügynök munkakontextusától. A feladatok állapotát, a végrehajtási kísérleteket, az elvégzett lépéseket és a műtermék-hivatkozásokat tartós tárolóban mentse. Közben csak az ügynök aktuális feladatához kapcsolódó utasításokat, bemeneteket és eredményeket töltse be, ahelyett hogy a teljes végrehajtási előzményt a kontextusablakába zsúfolná.

4. Tervezzen hibatudatos újrapróbálkozásokat és helyreállítható eszközvégrehajtást

Tegyük fel, hogy a CI-ügynöke elindít egy tesztfuttatást, de az API-kérés túllépi az időkorlátot. Vajon a tesztfuttatás el sem indult, vagy a CI-szolgáltatás sorba állította, és csak a válasz veszett el?

Az időtúllépés nem feltétlenül jelenti azt, hogy a művelet sikertelen volt. Ezért különbséget kell tenni a hibák között, mielőtt eldönti, mi történjen ezután:

• Átmeneti hibák (429, 503): Próbálkozzon újra korlátos exponenciális visszalépéssel és véletlenszerű késleltetéssel (jitter), a Retry-After értékét figyelembe véve, ha meg van adva.
• Validálási vagy jogosultsági hibák (400, 403): Álljon le, vagy javítsa ki a mögöttes problémát ahelyett, hogy ugyanazt a kérést ismételné.
• Nem egyértelmű kimenetelek (időtúllépés egy esetleges írás után): Mielőtt újra megkísérelné, ellenőrizze, hogy a művelet sikeres volt-e.

Megjegyzés: Még az újrapróbálható hibáknak is korlátok kellenek. Állítson be időkorlátot minden eszközhívásra, korlátozza az újrapróbálkozások számát és teljes idejét, és érvényesítsen egy átfogó munkafolyamat-határidőt, hogy a beágyazott ügynökök ne indíthassák újra és újra ugyanazt a műveletet. Ha egy függőség ismételten hibára fut, egy megszakító (circuit breaker) segítségével ideiglenesen állítsa le a kéréseket.

A külső mellékhatásokkal járó műveleteknél rendeljen minden logikai művelethez egy stabil idempotenciakulcsot, és használja újra az újrapróbálkozások során. Ha az API támogatja a szerveroldali deduplikációt, felismerheti az ismételt kéréseket anélkül, hogy kétszer végrehajtaná a műveletet. Ha nem, kérdezze le a külső rendszert egy korrelációs azonosító vagy más hiteles hivatkozás alapján.

Ha nem tudja megállapítani, mi történt, álljon le, és eszkalálja a problémát.

Példa a CI-ügynökünk újrapróbálkozási logikájára pszeudokódban:

Megjegyzés a kódhoz: A példa feltételezi, hogy a CI API támogatja a futtatások kérésazonosító szerinti lekérdezését. A request_id csak akkor akadályozza meg a duplikációkat, ha a szolgáltató kifejezetten garantálja az idempotenciát. A bounded_retry() szemléltető pszeudokód. Éles környezetben az újrapróbálkozásokat a műveletenkénti újrapróbálkozási kerettel (maximális kísérletszám vagy eltelt idő) és az átfogó munkafolyamat-határidővel is korlátozni kell.

A több szolgáltatáson átívelő, hosszabb munkafolyamatoknál fontolja meg a Saga mintát a kompenzáló műveletek koordinálására, ha a későbbi lépések meghiúsulnak. Ne feledje azonban, hogy a kompenzáció nem mindig jelent teljes visszaállítást. Egy adatbázis-frissítést visszafordíthat, de egy elküldött e-mailt már nem vonhat vissza.

5. Irányítsa és párhuzamosítsa a munkát explicit erőforráskeretekkel

Itt két dolgot kell egyensúlyban tartani: mekkora modellképességre van szüksége az egyes feladatoknak, és hány feladatot futtathat egyidejűleg. Ha bármelyiket elrontja, fennáll a veszélye, hogy az ügynökök a megosztott API-kvótákért versengenek, vagy kizárólag drága érvelő modellekre támaszkodnak.

A modellválasztás során igazítsa a modell képességeit és az érvelési ráfordítást a feladat összetettségéhez – egyszerű, mégis gyakran figyelmen kívül hagyott szempont. Az útválasztási szabályokat beállíthatja és a modelleket értékelheti saját maga is, vagy használhat olyan orkesztrációs platformot, amely elvégzi Ön helyett a modellválasztást.

Például a Perplexity Computer Effort Mode funkciójával eldöntheti, mekkora ráfordítást érdemel egy feladat, anélkül hogy manuálisan kellene modellt választania. Válassza a Light, Standard, High vagy Ultra lehetőséget, és a Perplexity automatikusan kiválasztja az orkesztráló modellt és annak érvelési szintjét. Ez az orkesztrátor ezután részfeladatokat delegál a támogató ügynököknek, amelyek különböző szolgáltatók modelljeit is használhatják.

A Perplexity minőség és költség szempontjából értékeli a modellkonfigurációkat, és előnyben részesíti azokat az olcsóbb lehetőségeket, amelyek hasonló eredményeket adnak. Ha inkább saját maga választaná ki a modellt és az érvelési szintet, a Custom vezérlőket is használhatja.

A párhuzamosításnál a korlátot az infrastruktúrája és a külső függőségek határozzák meg. Ellenőrizze a megosztott API-k kérés- és tokenalapú sebességkorlátait, majd végezzen terheléses tesztet a munkafolyamatán növekvő egyidejűséggel. Figyelje, hogy javul-e az átviteli sebesség, vagy a kérések elkezdenek sorba állni, lelassulni vagy 429-es hibákat visszaadni.

Az erőforrás-felhasználás kiszámíthatósága érdekében érvényesítsen erőforráskorlátokat és ütemezési szabályozókat:

• Szabályozza az egyidejűséget és a kérések gyakoriságát: Korlátozza a szolgáltatásonként folyamatban lévő hívások számát, a többletmunkát pedig állítsa sorba. Ne feledje, hogy az egyidejűségi korlát önmagában nem érvényesíti a percenkénti kérés- vagy tokenkorlátokat.
• Kövesse nyomon a token- és költségkereteket: Vegye számításba a teljes munkafolyamat felhasználását, beleértve az alügynököket is, és ne indítson új munkát, ha a fennmaradó keret nem elegendő.
• Érvényesítsen végrehajtási határidőket: Állítson be időkorlátokat a feladatokra és a munkafolyamatokra, és ahol lehetséges, továbbítsa a megszakítást a futó ügynököknek.
• Vegye figyelembe a függőségeket: A későbbi feladatokat csak akkor indítsa el, amikor a szükséges bemeneteik rendelkezésre állnak, ahelyett hogy minden ügynököt egyszerre indítana.

6. Írjon elő jóváhagyásokat, és különítse el az ügynökök végrehajtási környezetét

Soha ne a modellre bízza annak eldöntését, hogy a saját műveletei biztonságosak-e. Ehelyett adjon az ügynököknek a legkisebb szükséges jogosultságot, és az alkalmazáskódban érvényesítsen kockázatalapú jóváhagyási szabályokat. Ha az ügynökök kódot futtatnak, különítse el ezt a futtatást a gazdakörnyezettől, és korlátozza a fájlokhoz, hálózatokhoz és hitelesítő adatokhoz való hozzáférést. Ez mérsékli a kárt, ha az ügynök hibázik vagy nem biztonságos kódot futtat.

„Szkeptikus vagyok a túlbonyolított többügynökös rendszerekkel szemben, különösen, ha az ügynökök egymás munkáját ellenőrzik és hagyják jóvá. Könnyen előfordulhat, hogy több ügynök is magabiztosan továbbadja ugyanazt a hibát, anélkül hogy bárki ténylegesen kiszúrná” – figyelmeztet Spilker.

Nagyítás

Az emberi jóváhagyást igénylő műveleteknél szüneteltesse a végrehajtást, és mentse el pontosan a javasolt műveletet, azaz:

• a paramétereit
• a célerőforrását
• a commitját vagy állapotverzióját
• a felülvizsgáló döntését

Határozza meg azt is, mi történik, ha a jóváhagyást elutasítják, ha lejár, vagy ha eszkalációra van szükség. Ez elengedhetetlen a folytatható keretrendszereknél, mivel egy megszakított csomópont folytatásakor a kód annak a csomópontnak az elejétől fut újra. A megszakítás előtti mellékhatások így ismét lefuthatnak.

Ha tehát a jóváhagyást elutasítják vagy lejár, a kérés lezárul. Ha a cél-commit, a paraméterek vagy a jogosultságok a végrehajtás előtt megváltoznak, érvénytelenítse a jóváhagyást, és kérjen újat.

Spilker azt az elképzelést sem támogatja, hogy a teljesen autonóm, végponttól végpontig működő ügynökök jelentenék a célt. „Szerintem jobb megközelítés néhány fókuszált ügynököt létrehozni egyértelmű felelősségi körökkel, meghatározott jogosultságokkal és a megfelelő pontokon emberi felülvizsgálattal. Így is hatékonyságot nyerünk, anélkül hogy lemondanánk a teljes kontrollról” – foglalja össze.

7. Ellenőrizze a kimeneteket függetlenül, és tesztelje a helyreállítási viselkedést

Előfordult már, hogy egy ügynök Success állapotot jelentett, pedig valójában hibára futott? Bosszantó, sőt dühítő, és a javítás sem gyors, mert az ügynök utolsó üzenete nem feltétlenül árulja el, hol csúszott félre a dolog.

A kivizsgáláshoz kövesse nyomon, mi történt a végrehajtás során, és ellenőrizze függetlenül az eredményeket. Szánjunk tehát egy kis időt a probléma elkülönítésére és megoldására.

Kövesse nyomon a munkafolyamatot a hiba azonosításához

Mielőtt az ügynök promptjainak hibakeresésébe kezdene, rögzítse a teljes végrehajtási útvonalat. Olyan nyomkövetésre (trace) van szükség, amely ugyanazon munkafolyamat-futtatás alatt összekapcsolja az ügynökhívásokat, az eszközhívásokat, a hibákat és az újrapróbálkozásokat.

Az OpenTelemetry GenAI szemantikai konvenciói szabványos módot kínálnak ezeknek a műveleteknek a leírására. Például az invoke_workflow a munkafolyamat végrehajtását, az invoke_agent egy ügynökhívást, az execute_tool pedig egy eszközhívást azonosít. Minden művelet rögzíthető egy-egy span formájában az időzítésével, állapotával és a releváns metaadataival együtt.

Ez a lépés nyomon követhetővé teszi a végrehajtási útvonalat, így azonosíthatja, hol akadt el egy ügynök.

Egy szemléltető végrehajtási nyomkövetés.

Ellenőrizze a kimenetet függetlenül

Ahol csak lehet, alkalmazzon programozott ellenőrzéseket. Validálja a kimeneteket JSON-sémák alapján, futtasson egység- és integrációs teszteket, ellenőrizze, hogy a szükséges műtermékek léteznek-e, és kérdezze le a külső rendszereket annak megerősítésére, hogy a műveletek valóban sikeresek voltak.

A szubjektív megítélést igénylő kimenetekhez – amelyek így programozott ellenőrzésekkel nem értékelhetők – vonjon be egy független felülvizsgáló ügynököt. Az egyik megközelítés a megvalósító–felülvizsgáló–feloldó hurok, amelyben az egyik ügynök létrehoz egy műterméket, egy friss kontextusú felülvizsgáló azonosítja a problémákat, egy feloldó pedig kezeli azokat, mielőtt a validálás újra lefutna.

A felülvizsgáló megállapításait továbbra is validálnia kell, ahol lehetséges, és ha LLM-alapú értékelőket használ ismételt kiértékelésekhez, kalibrálja az ítéleteiket emberek által felülvizsgált példák alapján.

Idézzen elő hibákat a helyreállítás teszteléséhez

Eddig nyomon követted, mit hajtottak végre az ügynökök, és ellenőrizted, hogy helyesek-e a kimeneteik. De mi történik, ha egy worker a feladat közepén összeomlik, vagy egy API egy kérés elfogadása után időtúllépésbe fut? Meglepő módon előfordulhat, hogy a munkafolyamatod normál körülmények között tökéletesen működik, a helyreállítás során viszont hibázik.

Ennek teszteléséhez szándékosan injektálj hibákat egy tesztkörnyezetben:

• Szimulálj API-időtúllépéseket
• Idézd elő a workerek összeomlását a külső írások és az ellenőrzőpontok között
• Adj vissza hibás formátumú eszközkimeneteket
• Hagyd lejárni a jóváhagyásokat

Minden teszt után vizsgáld meg a végrehajtási nyomkövetést, hogy lásd, mely lépések futottak le, hol folytatódott a munkafolyamat, és ismétlődött vagy kimaradt-e valamelyik művelet. Ezután ellenőrizd a tényleges eredményeket.

Tegyük fel, hogy a CI-ügynököd kérést küld egy tesztfuttatás elindítására, de az API-válasz időtúllépés miatt elmarad. Az ügynök újrapróbálkozik, sikeres választ kap, és Success eredményt jelent. Minden rendben lévőnek tűnik, amíg meg nem nézed a CI-szolgáltatást, és rá nem jössz, hogy egy helyett két tesztfuttatás jött létre.

Ezért a munkafolyamat rögzített állapotát és a külső rendszerekben bekövetkezett tényleges változásokat is ellenőrizned kell. Egy helyreállítási teszt csak akkor legyen sikeres, ha a munkafolyamat nem szándékolt mellékhatások nélkül éri el a várt állapotot.

A feltárt hibákat vedd fel a regressziós tesztjeid közé, hogy a jövőbeli változtatások ne hozzák vissza őket.

Végső soron a siker azt jelenti, hogy a munkafolyamat teljesítette az előírt ellenőrzéseket, és a külső eredményeit is ellenőrizték.

Gyakori kérdések az AI-ügynökök orkesztrációjáról

Miért mondanak csődöt nagyvállalati méretekben az elszigetelten működő AI-ügynökök?

Az elszigetelten működő ügynökök egyenként helyesen végezhetik el a feladataikat, együttesen mégis következetlen eredményeket adhatnak. Képzeld el, hogy egy értékesítési ügynök 10:00-kor lekéri az ügyfél feltételeit, egy árazási ügynök 10:05-kor frissített árakkal számít ki egy árajánlatot, egy jogi ügynök pedig egy 10:07-kor módosult szerződést ellenőriz. Minden ügynök a vállalkozás más-más pillanatképével dolgozik, így a kimeneteik ellentmondhatnak egymásnak.

A probléma nagyvállalati méretekben még hangsúlyosabbá válik, mert az ügynökök több, egymástól függetlenül frissülő rendszerrel lépnek kapcsolatba, eltérő jogosultságokkal működnek, és nem feltétlenül osztoznak a kontextuson vagy a végrehajtási állapoton.

Hogyan előzhetők meg a végtelen újrapróbálkozási ciklusok az AI-ügynököknél?

Állíts be korlátokat több szinten: az eszközhívások újrapróbálkozásainak maximális számát, az ügynökiterációk maximális számát, a delegálási mélységet és a munkafolyamat teljes határidejét. Az újrapróbálkozás előtt osztályozd a hibákat. Átmeneti 429-es válaszok esetén vedd figyelembe a Retry-After értékét, ha meg van adva. Egyéb esetekben használj korlátos exponenciális visszalépést (backoff) véletlenszerű késleltetéssel (jitter).

Validációs vagy jogosultsági hibák után ne próbálkozz újra változatlan kérésekkel. Ha egy downstream szolgáltatás ismételten hibát ad, egy megszakító (circuit breaker) megakadályozhatja, hogy az ügynökök további terhelést generáljanak.

Hogyan folytatható egy AI-ügynök-munkafolyamat összeomlás után?

A helyreállítási mechanizmus a futtatókörnyezettől függ. LangGraph használatakor egy perzisztens checkpointer, például a PostgresSaver, egy thread_id alatt tárolja a gráf állapotát, így a végrehajtás a mentett állapotból folytatódhat. Temporal használatakor egy másik worker az eseményelőzmények újrajátszásával rekonstruálhatja a munkafolyamatot. Az újrajátszás során újrahasznosítja a korábban rögzített activity-eredményeket.

Ha az alkalmazást a munkafolyamatok futása közben telepítik újra, előfordulhat, hogy a mentett állapot és a végrehajtási előzmények már nem kompatibilisek. A Temporal ezt a Worker Versioning és a munkafolyamatok patchelése segítségével kezeli. Ellenőrzőpont-alapú rendszereknél tervezd meg a sémamigrációkat, és az inkompatibilis változtatások bevezetése előtt teszteld a helyreállítást a meglévő mentett állapotokon.

Hogyan tesztelhető az AI-ügynökök orkesztrációjának megbízhatósága?

Futtasd le többször ugyanazokat a reprezentatív feladatokat, és különböztesd meg a pass@k (azaz hogy a k próbálkozásból legalább egy sikeres-e) és a pass^k (azaz hogy mind a k próbálkozás sikeres-e) mutatót

Az eredményeket feladatkategóriánként és munkafolyamat-verziónként mérd, ne egyetlen összesített sikerességi arányra hagyatkozz. Kövesd nyomon az első próbálkozásra elért sikert, az ismételt futtatások közötti konzisztenciát, a p95-ös késleltetést, a teljesített feladatonkénti költséget és az emberi beavatkozást igénylő esetek arányát. A sikerességi arányokhoz add meg a mintaméreteket és a bizonytalansági intervallumokat.