DI agentų orkestravimas: gedimai, patvirtinimai ir pakartotiniai bandymai

Kai prie to paties projekto dirba keli agentai, tai atrodo itin efektyvu. Vienas planuoja darbą, kitas rūpinasi dizainu, o trečias rašo kodą. Tai veikia tol, kol nustoja veikti. O gedimų pasitaiko dažniau, nei norėtųsi.

Norint išvengti šių gedimų, reikia kruopščiai suprojektuoti darbo eigas. Tad išsiaiškinkime, kas daro orkestruojamas darbo eigas nepatikimas, ir apžvelkime geriausią orkestravimo praktiką, užtikrinančią patikimumą gamybinėje aplinkoje.

DI agentų orkestravimas koordinuoja kelis DI agentus, modelius ir įrankius, kad būtų atlikta kelių etapų užduotis. Tačiau kažkas – žmogus ar sistema – vis tiek turi nuspręsti, kuris agentas pradeda pirmas, kokią informaciją jis gauna ir kas nutinka jam baigus. Tai yra orkestruotojo vaidmuo – DI agento, veikiančio kaip vadovas, arba programine įranga valdomo vykdymo sluoksnio.

Paprastai tariant, orkestravimo sluoksnis suskaido tikslą į mažesnes užduotis, seka priklausomybes, paveda vykdymą tinkamiems agentams, valdo bendrą kontekstą ir sujungia rezultatus.

Orkestravimo vykdymo variklio schema: tikslas ir planas, nukreipimas agentams, izoliuotas įrankių vykdymas, struktūrizuoti rezultatai, nuolatinė darbo eigos būsena ir tikrinimo bei sprendimo žingsnis, kuris kartoja bandymą, grąžina, pristabdo, laukia arba pereina prie kitos užduoties.

Pažiūrėkime, kas vyksta, kai pateikiate orkestruotojui užduotį.

Panagrinėkime pavyzdį iš Perplexity Computer seminaro: klientų paskyrų analitikos skydelio kūrimas naudojant informaciją iš Salesforce, Snowflake, el. pašto, kalendoriaus ir naujausių naujienų.

Suprasti tikslą ir suplanuoti darbą. Orkestruotojas pradeda nuo pageidaujamo rezultato ir suskaido jį į užduotis su aiškiai apibrėžtomis priklausomybėmis. Mūsų skydelio pavyzdyje tai reiškia informacijos rinkimą iš skirtingų šaltinių ir jos pavertimą galutiniu rezultatu. Planuotojas nustato, kurie žingsniai priklauso nuo kitų, o kuriuos galima vykdyti nepriklausomai.
Nukreipti užduotis tinkamiems agentams. Orkestruotojas nustato užduotis, kurių priklausomybės patenkintos, ir paveda darbą specializuotiems agentams ar modeliams. Priklausomos užduotys laukia, kol bus įvykdytos jų prielaidos. Perplexity Computer naudoja kelis pažangiausius modelius ir skirtingas darbo eigos dalis nukreipia toms užduotims tinkamoms sistemoms. Tai taip pat leidžia nepriklausomą darbą vykdyti lygiagrečiai.
Vykdyti įrankių iškvietimus kontroliuojamose aplinkose. Agentai sąveikauja su savo aplinka per įrankius, pvz., žiniatinklio paiešką, API, prijungtas programas, failų operacijas ar kodo vykdymą. Vykdymo sluoksnis atlieka šiuos veiksmus ir grąžina rezultatus agentams.
Perduoti rezultatus ir kontekstą tarp agentų. Kai agentas baigia savo užduotį, kitam grandinėje esančiam agentui reikia atitinkamo rezultato, kad galėtų tęsti. Perdavimo įraše gali būti užduoties ID, nuoroda į rezultatą, schemos versija ir šaltinio metaduomenys. Orkestruotojas koordinuoja šiuos perdavimus ir išlaiko kontekstą, reikalingą tolesniems žingsniams. Svarbu tai, kad agentams nereikia savo konteksto languose laikyti visos kiekvieno kito agento darbo istorijos.
Vykdymo būseną registruoti atskirai nuo agentų konteksto. Agentams pradedant, užbaigiant užduotis arba patiriant nesėkmę, vykdymo variklis atnaujina nuolatinį darbo eigos įrašą: užduočių būsenas, vykdymo bandymus, nuorodas į rezultatus ir likusį darbą. Šis įrašas leidžia orkestruotojui sekti pažangą ir tęsti darbą po pertrūkių, nepasikliaujant LLM, kad šis atkurtų darbo eigą iš pokalbio istorijos.
Patikrinti rezultatus ir nuspręsti, kas toliau. Kai užduotis grąžina rezultatą, orkestravimo sluoksnis patikrina, ar jos išvestis atitinka numatytą kontraktą ir ar įvykdytos kitos užduoties priklausomybės. Aptikus problemą, darbo eiga gali grįžti į ankstesnį žingsnį taisymui arba būti pristabdyta. Priešingu atveju ji juda link užbaigimo.

Už iš pažiūros paprasto DI agentų orkestravimo slypi daugybė judančių dalių. Tai, kaip organizuojate agentų koordinavimą, lemia, kiek kontroliuojate vykdymą. Ir, žinoma, visas šis koordinavimas sukuria papildomų sąnaudų. Todėl jis ne visada apsimoka.

Apsvarstykite kelių agentų orkestravimą, kai skirtingoms užduoties dalims reikia skirtingos kompetencijos, nepriklausomą darbą galima vykdyti lygiagrečiai arba negalite iš anksto nustatyti kito žingsnio.

Taigi orkestravimas naudingas trimis atvejais:

Užduotims reikia skirtingų specializacijų. Pavyzdžiui, programavimo projektui gali būti naudinga turėti atskirus planavimo, dizaino, kūrimo ir peržiūros agentus.
Nepriklausomas užduotis galima vykdyti lygiagrečiai. Užuot vienam agentui viską atlikus nuosekliai, keli agentai gali dirbti vienu metu ir grąžinti savo rezultatus orkestruotojui.
Problema yra atviro pobūdžio. Agentams gali tekti išbandyti skirtingus metodus, priimti sprendimus ir bendradarbiauti, o ne laikytis iš anksto nustatytos sekos.

Kitais atvejais orkestravimas tėra brangi mada. Daugiau agentų taip pat reiškia daugiau koordinavimo ir galimai didesnes žetonų sąnaudas.

„Paprastai pradedu nuo paprasčiausio varianto ir plėtoju toliau. Jei žinome žingsnius ir jie kartojasi, greičiausiai tai yra darbo eiga. Priežastį įtraukti kelis agentus matau tik tada, kai jie turi skirtingas atsakomybes, leidimus ar naudotojus“, – sako Josh Spilker, AirOps paieškos rinkodaros vadovas.

Net ir tada pasverkite naudą atsižvelgdami į papildomus modelio iškvietimus, perdavimus, delsą ir gedimų taškus.

Trys įprasti agentų koordinavimo struktūrizavimo būdai – centralizuotas, decentralizuotas ir hierarchinis orkestravimas. Tinkamos architektūros pasirinkimas priklauso nuo vieno klausimo: Kas valdo darbą ir kaip agentai koordinuojasi tarpusavyje?

Taikant centralizuotą orkestravimą, procesą valdo vienas orkestruotojas. Jis suskaido užduotį, paveda darbą specializuotiems agentams, seka jų pažangą ir sujungia jų rezultatus.

Centralizuoto orkestravimo schema: vienas orkestruotojas gauna naudotojo užklausą ir paveda darbą tyrimo, analizės ir dizaino agentams, kurių kiekvienas naudoja savo įrankius, o jų rezultatai sujungiami į galutinį skydelį.

Kompromisas: Centralizuotas koordinavimas palengvina vykdymo sekimą ir bendrų taisyklių taikymą viename valdymo taške. Tačiau orkestruotojas gali tapti kliūtimi, o jo gedimas gali sutrikdyti visą darbo eigą, nebent sistema palaiko atkūrimą.

Taikant decentralizuotą orkestravimą, agentai koordinuojasi tiesiogiau, užuot pasikliovę vienu vadovu, priimančiu kiekvieną sprendimą. Jie gali keistis žinutėmis, skaityti bendrą būseną ir savarankiškai nustatyti tolesnius žingsnius.

Decentralizuoto orkestravimo schema: tyrimo, analizės, dizaino ir peržiūros agentai tiesiogiai bendrauja tarpusavyje bei su bendra būsena ir įrankiais, kad sukurtų galutinį skydelį.

Kompromisas: Agentai gali veikti nelaukdami centrinio planuotojo, todėl šis metodas naudingas tiriamajam darbui ir savarankiškiems indėliams. Tačiau koordinuoti tampa sunkiau, kai agentai nesutaria, atnaujina bendrą informaciją arba turi pasiekti nuoseklų rezultatą.

Hierarchinis orkestravimas išplečia vadovo metodą per kelis lygius. Aukščiausio lygio orkestruotojas paveda atsakomybę pavaldiems orkestruotojams, kurie koordinuoja savo specializuotų agentų grupes.

Įsivaizduokite įmonės darbo eigą, kurioje dalyvauja pardavimų, finansų ir teisės komandos. Aukščiausio lygio orkestruotojas galėtų pavesti kiekvieną darbo srautą konkrečios srities koordinatoriui. Tada tie koordinatoriai valdytų savo specializuotus agentus ir teiktų apibendrintus rezultatus.

Tokia struktūra gali padėti, kai darbo eigos per plačios, kad vienas orkestruotojas galėtų jas veiksmingai valdyti.

Hierarchinio orkestravimo schema: aukščiausio lygio orkestruotojas paveda darbą pardavimų, finansų ir teisės orkestruotojams, kurių kiekvienas valdo du specializuotus agentus, o jų darbas sujungiamas į apibendrintą rezultatą.

Kompromisas: Hierarchijos leidžia komandoms pasidalyti koordinavimo atsakomybes ir galimai suvaldyti gedimus atskirose šakose. Tačiau jos įveda papildomų perdavimų, sudėtingesnį būsenos valdymą ir didesnes veiklos sąnaudas. Vietinis atkūrimas taip pat priklauso nuo to, kaip įgyvendinti kontroliniai taškai ir vykdymo būsena.

Šių architektūrų palyginimas:

Kriterijai	Centralizuotas	Decentralizuotas	Hierarchinis
Atsakomybė už vykdymą	Delegavimą valdo vienas orkestruotojas	Agentai koordinuojasi per lygiaverčius agentus arba bendrą būseną	Atsakomybė paskirstyta tarp orkestravimo lygių
Būsenos nuoseklumas	Lengviau koordinuoti per vieną valdymo tašką	Reikia aiškaus sinchronizavimo ir konfliktų sprendimo	Reikia koordinavimo šakų viduje ir tarp jų
Gedimų izoliavimas	Centrinis valdiklis gali tapti kritine priklausomybe	Atskirų agentų gedimai gali būti nepriklausomi, tačiau bendra infrastruktūra išlieka kritiškai svarbi	Jei numatytas atkūrimas, gedimai gali būti apriboti šakų viduje
Politikų taikymas	Bendras kontrolės priemones galima taikyti centralizuotai	Politikos turi būti nuosekliai taikomos visiems dalyviams	Kontrolės priemones galima taikyti visuotiniu ir sričių lygmenimis
Operacinis sudėtingumas	Paprastai mažesnis	Didesnis koordinavimo sudėtingumas	Didesnis sudėtingumas dėl kelių orkestravimo lygmenų

Verta suprasti dar vieną skirtumą. Architektūra lemia, kas koordinuoja agentus. Vykdymo modelis lemia, kaip vyksta jų užduotys.

Štai trys vykdymo modeliai:

Nuoseklios darbo eigos: agentai dirba iš anksto nustatyta tvarka, o vieno agento rezultatas tampa kito įvestimi.
Lygiagretus vykdymas: nepriklausomi agentai dirba vienu metu.
Perdavimu grindžiamas vykdymas: užduočiai progresuojant valdymas pereina tarp specializuotų agentų. Tai naudinga, kai kitas agentas yra geriau pasirengęs atlikti kitą žingsnį, tačiau kiekvienas perdavimas turi išsaugoti informaciją, reikalingą darbui tęsti.

Šie modeliai vienas kito neatmeta ir neatitinka orkestravimo architektūrų santykiu vienas su vienu. Tikslas – pasirinkti paprasčiausią struktūrą, kuri atitiktų jūsų darbo eigos priklausomybes, koordinavimo reikalavimus ir priimtinas operacines sąnaudas.

Orkestruojant gali sutrikti bet kas – nuo paprastų nepastebėjimų iki sudėtingų kliūčių. Kartais agentas gali net atrodyti tinkamai atliekantis savo darbą, nors visa darbo eiga žlunga. Remdamiesi praktikų patirtimi, surinkome dažniausias klaidas, dėl kurių orkestruotos darbo eigos tampa nepatikimos, – atkreipkite į jas dėmesį:

Informaciją prarandantys agentų perdavimai. Orkestratorius perduoda specializuotam agentui apibendrintą planą, tačiau santraukoje praleidžiami apribojimai, priklausomybės ar įgyvendinimo detalės.
Per ankstyvas rezultatų sujungimas (fan-in). Tolesnis agentas pradeda jungti rezultatus dar nepasibaigus visoms ankstesnėms užduotims.
Nedeterministiniai bendros būsenos atnaujinimai. Lygiagretūs agentai rašo į tuos pačius būsenos raktus be aiškiai apibrėžtos sujungimo semantikos. Atsižvelgiant į tai, kaip karkasas apdoroja atnaujinimus, tai gali lemti prarastus įrašus, dubliuotus duomenis, nuo eiliškumo priklausančią išvestį ar vienas kitam prieštaraujančius pakeitimus.
Kontrolinio taško ir šalutinio poveikio neatitiktis. Užduotis atlieka išorinę operaciją, tačiau jos sėkmingas įvykdymas nėra patvariai įrašomas prieš sugendant darbiniam procesui. Atkuriant orkestratorius mato nebaigtą užduotį ir paleidžia ją iš naujo.
Lenktynių sąlygos atnaujinant vykdymą po žmogaus patvirtinimo. Vykdymo pristabdymas ir atnaujinimas sukelia savų sinchronizavimo problemų.
Delegavimo ciklai ir pakartotinių bandymų gausėjimas. Agentai vis perduoda darbą vieni kitiems, nes jų atsakomybės persidengia, priklausomybės yra ciklinės arba užbaigimo sąlygos neaiškios.
Instrukcijų lygmens kontrolės priemonės, klaidingai laikomos vykdymo saugumu. Orkestratorius gali nurodyti agentams nesinaudoti tam tikrais ištekliais ar neatlikti jautrių veiksmų, tačiau modelio instrukcijos neužtikrina operacinės sistemos leidimų, tinklo apribojimų ar autorizacijos ribų. Perplexity saugumo inžinerijos tyrimas parodo, kodėl agentai, siekdami teisėtų tikslų, gali peržengti saugumo ribas net ir be kenkėjiškų instrukcijų

Atkreipkite dėmesį, kokios skirtingos šios klaidos. Per ankstyvas planuoklio perėjimas ar dviprasmiškas įrašas į išorinę sistemą gali lemti neteisingą rezultatą, tačiau jie kyla skirtingose vykdymo gyvavimo ciklo dalyse. Todėl patikimam orkestravimui neužtenka patobulinti raginimų ar pridėti pakartotinių bandymų.

Neaiškūs tikslai ir miglotas atlikimo apibrėžimas dažnai lemia nuviliančius agentų sugeneruotus rezultatus. Sprendimas – raginimo sutartis (agento darbų apimtis): susitarkite dėl tikslo, apribojimų, išvesties formato ir nesėkmės sąlygų prieš pradedant vykdymą.

Pavyzdžiui, štai kaip galėtumėte apibrėžti sutartį agentui, atsakingam už protarpiais nepavykstančio integracinio testo taisymą:

Tikslas: nustatyti ir pašalinti nestabilaus atsiskaitymo API integracinio testo priežastį.
Įvestys: testo išeities kodas, CI nesėkmių žurnalai, naujausi pakeitimų įrašai (commits) ir susijęs programos kodas.
Apribojimai: neišjunkite testų, nesušvelninkite tvirtinimų (assertions) ir nekeiskite nesusijusio programos veikimo.
Laukiama išvestis: kodo pataisa, pagrindinės priežasties paaiškinimas ir testų vykdymo rezultatai.
Priėmimo kriterijai: anksčiau nepavykęs testas sėkmingai įvykdomas 10 kartų iš eilės, o susijęs regresijos testų rinkinys sėkmingai praeina.
Nesėkmės sąlygos: nepavyksta nustatyti pagrindinės priežasties, pataisa sukelia regresijų arba reikiama testavimo aplinka nepasiekiama.

Tačiau yra ir dar viena svarbi dalis: kada agentas turėtų sustoti?

Agentas neturėtų be galo kartoti iteracijų vien todėl, kad dar negavo patenkinamo rezultato. Apibrėžkite, kas laikoma sėkmingu užbaigimu, kada grąžinti iš dalies atliktą užduotį ir kada sustoti, nes reikalavimo įvykdyti neįmanoma. Nustatykite didžiausią delegavimo gylį ir iteracijų ribas arba vykdymo biudžetus, kad neišspręstos užduotys netaptų begaliniais ciklais.

Grįžkime prie mūsų CI pavyzdžio. Galėtumėte apibrėžti tokias sustabdymo sąlygas:

Sėkmė: pataisa sėkmingai praeina 10 testų paleidimų iš eilės ir susijusį regresijos testų rinkinį.
Iteracijų riba: agentas gali išbandyti ne daugiau kaip dvi galimas pataisas.
Vykdymo biudžetas: agentas turi sustoti po 60 minučių, net jei problema lieka neišspręsta.
Delegavimo riba: agentas gali deleguoti darbą vienam specializuotam agentui, o toliau deleguoti subagentams negalima.
Dalinis užbaigimas: jei abu bandymai nepavyksta arba baigiasi laiko limitas, agentas grąžina savo išvadas, bandytus pakeitimus ir testų rezultatus.
Užblokuotas vykdymas: jei testavimo aplinka nepasiekiama, agentas sustoja ir praneša apie kliūtį, užuot teigęs, kad pavyko.

Kartais kūrėjai orkestratoriui suteikia per daug atsakomybių, ir užuot koordinavęs specializuotus agentus, jis pats pradeda rašyti kodą, derinti ar atlikti išsamias peržiūras. Taip susidaro kliūtis: orkestratorius išeikvoja savo konteksto biudžetą įgyvendinimo detalėms, atideda delegavimą, o atsakomybė už rezultatus tampa neaiški.

Tad leiskite orkestratoriams atlikti savo darbą ir užtikrinkite perdavimus remdamiesi konkrečiais artefaktais: pradine užduotimi, susijusiomis įvestimis, išvesties artefaktais, vykdymo būsena ir visomis neišspręstomis problemomis.

Panagrinėkime šį pavyzdį: status: completed reiškia agentui paskirtą darbą, o ne visą darbo eigą. Kadangi testų būsena vis dar pending, orkestratorius neturėtų patvirtinti galutinio rezultato.

json

{
  "task_id": "fix-42",
  "status": "completed",
  "artifact_ref": "patch-17",
  "test_status": "pending",
  "blockers": []
}

Agento pokalbio istorija nėra patikimas darbo eigos pažangos įrašas. Kai jo konteksto langas prisipildo, automatinis glaudinimas gali pašalinti svarbias detales. O jei darbinis procesas sugenda, kitam agentui reikia žinoti, kurie žingsniai iš tikrųjų buvo atlikti.

Pavyzdžiui, jei kodavimo agentas sugeneruoja pataisą ir tada sugenda, kitas darbinis procesas turėtų gauti išsaugotą artefaktą ir tęsti nuo įrašytos darbo eigos būsenos. Tačiau jei agentas taip pat paleido išorinį CI vykdymą, orkestratorius, prieš kartodamas veiksmą, turi atskirai suderinti to vykdymo būseną

Todėl vykdymo būseną laikykite atskirai nuo agento darbinio konteksto. Užduočių būsenas, vykdymo bandymus, atliktus žingsnius ir artefaktų nuorodas saugokite patvarioje saugykloje. Tuo tarpu įkelkite tik su dabartine agento užduotimi susijusias instrukcijas, įvestis ir rezultatus, užuot grūdę visą vykdymo istoriją į jo konteksto langą.

Tarkime, jūsų CI agentas paleidžia testų vykdymą, tačiau baigiasi API užklausos skirtasis laikas. Ar testų vykdymas nepasileido, ar CI paslauga įtraukė jį į eilę ir prarado atsakymą?

Pasibaigęs skirtasis laikas nebūtinai reiškia, kad operacija nepavyko. Todėl prieš nuspręsdami, kas bus toliau, turite atskirti klaidų tipus:

Laikinos klaidos (429, 503): kartokite su ribotu eksponentiniu atidėjimu ir atsitiktiniu svyravimu (jitter), atsižvelgdami į Retry-After, kai jis pateikiamas.
Tikrinimo arba leidimų klaidos (400, 403): sustokite arba ištaisykite pagrindinę problemą, užuot kartoję tą pačią užklausą.
Neaiškūs rezultatai (skirtasis laikas pasibaigė po galimo įrašymo): prieš bandydami dar kartą patikrinkite, ar operacija pavyko.

Pastaba: net ir klaidoms, kurias galima kartoti, reikia ribų. Nustatykite kiekvieno įrankio iškvietimo skirtąjį laiką, apribokite pakartotinių bandymų skaičių ir bendrą jų trukmę bei taikykite bendrą darbo eigos terminą, kad įdėtiniai agentai negalėtų vis iš naujo paleisti tos pačios operacijos. Jei priklausomybė nuolat neveikia, naudokite grandinės pertraukiklį (circuit breaker), kad laikinai sustabdytumėte užklausas.

Operacijoms, turinčioms išorinį šalutinį poveikį, kiekvienam loginiam veiksmui priskirkite stabilų idempotentiškumo raktą ir naudokite jį per visus pakartotinius bandymus. Jei API palaiko dublikatų šalinimą serverio pusėje, ji gali atpažinti pasikartojančias užklausas ir neatlikti veiksmo du kartus. Jei nepalaiko, pateikite užklausą išorinei sistemai naudodami koreliacijos ID ar kitą patikimą nuorodą.

Kai negalite nustatyti, kas įvyko, sustokite ir eskaluokite problemą.

Mūsų CI agento pakartotinių bandymų logikos pavyzdys, užrašytas pseudokodu:

python

op_id = get_or_create_operation_id(
    task_id=task_id,
    patch_id=patch_id,
    action="start_ci_run"
)

try:
    return ci.start_run(commit, request_id=op_id)
except TimeoutError:
    run = ci.find_by_request_id(op_id)
    if run:
        return run

    if ci.supports_idempotency:
        return bounded_retry(
            lambda: ci.start_run(commit, request_id=op_id)
        )

    raise NeedsReconciliation(op_id)

Pastaba apie kodą: pavyzdyje daroma prielaida, kad CI API palaiko vykdymų paiešką pagal užklausos ID. Laukas request_id apsaugo nuo dublikatų tik tada, jei teikėjas aiškiai garantuoja idempotentiškumą. bounded_retry() yra iliustracinis pseudokodas. Produkcinėje aplinkoje pakartotinius bandymus turėtų riboti ir kiekvienos operacijos pakartotinių bandymų biudžetas (didžiausias bandymų skaičius arba praėjęs laikas), ir bendras darbo eigos terminas.

Ilgesnėms, kelias paslaugas apimančioms darbo eigoms apsvarstykite Saga šabloną, kad koordinuotumėte kompensuojamuosius veiksmus, kai vėlesni žingsniai nepavyksta. Tik atminkite, kad kompensavimas ne visada reiškia visišką atšaukimą. Duomenų bazės atnaujinimą atšaukti galite, o išsiųsto el. laiško – ne.

Čia reikia suderinti du dalykus: kiek modelio pajėgumų reikia kiekvienai užduočiai ir kiek užduočių galite vykdyti vienu metu. Suklydę bet kuriuo atveju rizikuojate, kad agentai konkuruos dėl bendrų API kvotų arba remsitės tik brangiais protavimo modeliais.

Renkantis modelį, modelio pajėgumus ir protavimo pastangas derinkite prie užduoties sudėtingumo – paprasta, bet gana dažnai nepaisoma. Atminkite, kad galite patys konfigūruoti maršruto parinkimo taisykles ir vertinti modelius arba naudoti orkestravimo platformą, kuri modelį parenka už jus.

Pavyzdžiui, Perplexity Computer režimas „Effort Mode“ leidžia pasirinkti, kiek pastangų skirti užduočiai, nereikia rankiniu būdu rinktis modelio. Pasirinkite Light, Standard, High arba Ultra, ir Perplexity automatiškai parinks orkestruojantį modelį bei jo protavimo lygį. Tada tas orkestratorius deleguoja antrines užduotis pagalbiniams agentams, kurie gali naudoti skirtingų teikėjų modelius.

Perplexity vertina modelių konfigūracijas pagal kokybę ir kainą, teikdama pirmenybę pigesnėms parinktims, kurios duoda panašius rezultatus. Jei norite patys pasirinkti modelį ir protavimo lygį, taip pat galite naudoti valdiklius Custom.

Lygiagretumo ribą turėtų lemti jūsų infrastruktūra ir išorinės priklausomybės. Patikrinkite bendrų API užklausų ir žetonų spartos ribas, tada atlikite darbo eigos apkrovos testus didindami lygiagretumą. Stebėkite, ar pralaidumas didėja, ar užklausos pradeda kauptis eilėje, lėtėti arba grąžinti 429 klaidas.

Kad išteklių naudojimas būtų nuspėjamas, taikykite išteklių ribas ir planavimo kontrolės priemones:

Kontroliuokite lygiagretumą ir užklausų spartą: apribokite vienu metu vykdomų iškvietimų skaičių kiekvienai paslaugai, o perteklinį darbą įtraukite į eilę. Atminkite, kad vien lygiagretumo riba neužtikrins užklausų per minutę ar žetonų per minutę ribų.
Stebėkite žetonų ir išlaidų biudžetus: apskaitykite naudojimą visoje darbo eigoje, įskaitant subagentus, ir nebepradėkite naujų darbų, kai likusio biudžeto nepakanka.
Taikykite vykdymo terminus: nustatykite užduočių ir darbo eigos laiko ribas, o kur palaikoma – perduokite atšaukimą veikiantiems agentams.
Paisykite priklausomybių: tolesnes užduotis pradėkite tik tada, kai yra prieinamos joms reikalingos įvestys, užuot paleidę visus agentus vienu metu.

Niekada neprašykite modelio spręsti, ar jo paties veiksmai saugūs. Vietoj to suteikite agentams mažiausių privilegijų leidimus, o rizika grindžiamas patvirtinimo taisykles taikykite programos kode. Jei agentai vykdo kodą, izoliuokite tą vykdymą nuo savo pagrindinės aplinkos ir apribokite prieigą prie failų, tinklų ir prisijungimo duomenų. Taip apribojama žala, jei agentas suklysta arba įvykdo nesaugų kodą.

„Skeptiškai vertinu pernelyg sudėtingas kelių agentų sistemas, ypač kai agentai peržiūri ir tvirtina vienas kito darbą. Gali nutikti taip, kad keli agentai užtikrintai perduoda tą pačią klaidą toliau, o niekas jos iš tikrųjų nepastebi“, – perspėja Spilker.

Patvirtinimo eigos diagrama: agentas pasiūlo operaciją su parametrais, tiksliniu ištekliumi ir būsenos versija; žmogus ją patvirtina arba atmeta; patvirtintos operacijos dar kartą patikrinamos ir vykdomos izoliuotoje aplinkoje su ribota prieiga prie failų, tinklo ir prisijungimo duomenų. Atmestos ar nebegaliojančios užklausos uždaromos, o pakeistoms užklausoms reikia naujo patvirtinimo.

Veiksmams, kuriems reikia žmogaus patvirtinimo, pristabdykite vykdymą ir išsaugokite tikslią siūlomą operaciją:

jos parametrus
jos tikslinį išteklių
jos įrašo (commit) arba būsenos versiją
peržiūrėtojo sprendimą

Taip pat apibrėžkite, kas nutinka, jei patvirtinimas atmetamas, nustoja galioti arba jį reikia eskaluoti. Tai būtina sistemoms, kurios leidžia atnaujinti vykdymą, nes atnaujinant pertrauktą mazgą kodas vykdomas iš naujo nuo to mazgo pradžios. Bet koks šalutinis poveikis prieš pertraukimą gali pasikartoti.

Taigi, jei patvirtinimas atmetamas arba nustoja galioti, užklausa uždaroma. Jei prieš vykdymą pasikeičia tikslinis įrašas (commit), parametrai ar leidimai, anuliuokite patvirtinimą ir paprašykite naujo.

Spilker taip pat nepritaria idėjai, kad tikslas yra visiškai autonomiški, nuo pradžios iki galo veikiantys agentai. „Mano manymu, geresnis būdas – sukurti kelis tikslingus agentus su aiškiomis atsakomybėmis, apibrėžtais leidimais ir žmogaus peržiūra tinkamuose taškuose. Efektyvumo vis tiek pasieksite, neatsisakydami visiškos kontrolės“, – apibendrina jis.

Ar kada nors agentas jums pranešė Sėkmė, nors iš tikrųjų jam nepavyko? Erzina, jei ne siutina, o greitai to ištaisyti nepavyksta, nes galutinis agento pranešimas nebūtinai nurodys, kur įvyko klaida.

Norėdami tai ištirti, atsekite, kas vyko vykdymo metu, ir nepriklausomai patikrinkite rezultatus. Tad skirkime šiek tiek laiko problemai izoliuoti ir išspręsti.

Prieš derindami agento raginimus, užfiksuokite visą vykdymo kelią. Jums reikia sekimo duomenų (trace), kurie susietų agentų iškvietimus, įrankių iškvietimus, klaidas ir pakartotinius bandymus tame pačiame darbo eigos vykdyme.

OpenTelemetry GenAI semantinės konvencijos suteikia standartizuotą būdą šioms operacijoms aprašyti. Pavyzdžiui, invoke_workflow žymi darbo eigos vykdymą, invoke_agent – agento iškvietimą, o execute_tool – įrankio iškvietimą. Kiekviena operacija gali būti įrašyta kaip span su jos trukme, būsena ir susijusiais metaduomenimis.

Šis žingsnis suteikia vykdymo kelio sekimo duomenis, todėl galite nustatyti, kur agentas užstrigo.

plaintext

invoke_agent  generate_patch   OK
execute_tool  start_ci_run     OK  run_id=9812
execute_tool  get_ci_result    TIMEOUT

agent_response: "Success"

Iliustracinis vykdymo sekimo pavyzdys.

Kur tik įmanoma, naudokite programines patikras. Tikrinkite išvestis pagal JSON schemas, vykdykite vienetų ir integracinius testus, patikrinkite, ar yra reikiami artefaktai, ir teikite užklausas išorinėms sistemoms, kad patvirtintumėte, jog veiksmai iš tikrųjų pavyko.

Išvestims, kurioms reikia subjektyvaus vertinimo ir kurių todėl negalima įvertinti programinėmis patikromis, pasitelkite nepriklausomą peržiūros agentą. Vienas iš būdų – įgyvendintojo, peržiūrėtojo ir sprendėjo ciklas, kai vienas agentas sukuria artefaktą, naujo konteksto peržiūrėtojas nustato problemas, o sprendėjas jas pašalina prieš vėl paleidžiant patikrą.

Vis tiek turite, kur įmanoma, patikrinti peržiūrėtojo išvadas, o jei kartotiniams vertinimams naudojate LLM pagrįstus vertintojus, kalibruokite jų sprendimus pagal žmonių peržiūrėtus pavyzdžius.

Iki šiol atsekėte, ką vykdė agentai, ir patikrinote, ar jų rezultatai buvo teisingi. Bet kas nutinka, kai darbinis procesas sugenda įpusėjus užduočiai arba API sąsaja, jau priėmusi užklausą, neatsako per skirtąjį laiką? Gali nustebinti, bet jūsų darbo eiga įprastomis sąlygomis gali veikti puikiai, tačiau sutrikti atkūrimo metu.

Norėdami tai patikrinti, bandomojoje aplinkoje sąmoningai sukelkite gedimus:

Imituokite API skirtojo laiko viršijimą
Sukelkite darbinių procesų strigtis tarp įrašymo į išorines sistemas ir kontrolinių taškų
Grąžinkite netinkamo formato įrankių išvestis
Priverstinai nutraukite patvirtinimų galiojimą

Po kiekvieno testo išnagrinėkite vykdymo pėdsaką ir pažiūrėkite, kurie žingsniai buvo atlikti, nuo kurios vietos darbo eiga buvo tęsiama ir ar kurie nors veiksmai buvo pakartoti arba praleisti. Tada peržiūrėkite faktinius rezultatus.

Tarkime, jūsų CI agentas siunčia užklausą paleisti testų vykdymą, bet API atsakymo nesulaukiama per skirtąjį laiką. Agentas bando dar kartą, gauna sėkmingą atsakymą ir praneša Success. Viskas atrodo gerai, kol patikrinate CI paslaugą ir pamatote, kad vietoj vieno buvo sukurti du testų vykdymai.

Todėl turėtumėte patikrinti ir darbo eigos užfiksuotą būseną, ir faktinius pokyčius išorinėse sistemose. Atkūrimo testas turėtų būti laikomas sėkmingu tik tada, kai darbo eiga pasiekia numatytą būseną be nenumatyto šalutinio poveikio.

Aptiktus gedimus įtraukite į regresijos testus, kad būsimi pakeitimai jų vėl neatneštų.

Galiausiai sėkmė reiškia, kad darbo eiga išlaikė privalomus patikrinimus, o jos išoriniai rezultatai buvo patikrinti.

Izoliuotai veikiantys agentai gali teisingai atlikti savo atskiras užduotis, tačiau kartu duoti nenuoseklius rezultatus. Įsivaizduokite, kad pardavimų agentas 10:00 gauna kliento sąlygas, kainodaros agentas 10:05 apskaičiuoja pasiūlymą pagal atnaujintas kainas, o teisės agentas tikrina sutartį, kuri buvo pakeista 10:07. Kiekvienas agentas dirba su skirtinga momentine verslo būsenos kopija, todėl jų rezultatai gali vienas kitam prieštarauti.

Įmonės mastu ši problema tampa dar ryškesnė, nes agentai sąveikauja su keliomis nepriklausomai atnaujinamomis sistemomis, veikia turėdami skirtingus leidimus ir nebūtinai dalijasi kontekstu ar vykdymo būsena.

Nustatykite apribojimus keliais lygmenimis: didžiausią įrankių iškvietimų pakartojimų skaičių, didžiausią agento iteracijų skaičių, delegavimo gylį ir bendrą darbo eigos terminą. Prieš kartodami bandymą, klasifikuokite gedimus. Gavę laikinus 429 atsakymus, laikykitės Retry-After reikšmės, jei ji pateikta. Kitu atveju naudokite ribotą eksponentinį atidėjimą su atsitiktiniu svyravimu (jitter).

Po validavimo arba leidimų klaidų nebekartokite nepakeistų užklausų. Jei paskesnė paslauga pakartotinai sutrinka, grandinės pertraukiklis (circuit breaker) gali neleisti agentams generuoti papildomos apkrovos.

Atkūrimo mechanizmas priklauso nuo jūsų vykdymo aplinkos. Naudojant LangGraph, nuolatinis kontrolinių taškų saugojimo komponentas, pvz., PostgresSaver, saugo grafo būseną pagal thread_id, todėl vykdymą galima tęsti nuo išsaugotos būsenos. Naudojant Temporal, kitas darbinis procesas gali atkurti darbo eigą pakartotinai paleisdamas jos įvykių istoriją. Pakartotinio paleidimo metu jis iš naujo panaudoja anksčiau užfiksuotus veiklų (activity) rezultatus.

Jei programa iš naujo įdiegiama, kol darbo eigos dar vykdomos, išsaugota būsena ir vykdymo istorijos gali nebebūti suderinamos. Temporal šią problemą sprendžia per Worker Versioning ir darbo eigų pataisas (patching). Kontroliniais taškais pagrįstose sistemose suplanuokite schemų migracijas ir, prieš diegdami nesuderinamus pakeitimus, išbandykite atkūrimą su esamomis išsaugotomis būsenomis.

Kelis kartus vykdykite tas pačias reprezentatyvias užduotis ir atskirkite pass@k (ar bent vienas iš k bandymų yra sėkmingas) nuo pass^k (ar visi k bandymai yra sėkmingi)

Vertinkite rezultatus pagal užduočių kategoriją ir darbo eigos versiją, o ne remkitės vienu bendru sėkmės rodikliu. Stebėkite sėkmę iš pirmo bandymo, nuoseklumą per pakartotinius vykdymus, p95 delsą, vienos atliktos užduoties kainą ir dalį atvejų, kai reikia žmogaus įsikišimo. Pateikite sėkmės rodiklių imčių dydžius ir neapibrėžties intervalus.

Kas yra DI agentų orkestravimas?

Kaip veikia DI agentų orkestravimas: vykdymo variklio viduje

Kada reikėtų naudoti DI agentų orkestravimą?

DI agentų orkestravimo architektūros ir jų kompromisai

Centralizuotas orkestravimas

Decentralizuotas orkestravimas

Hierarchinis orkestravimas

Nuoseklus, lygiagretus ir perdavimu grindžiamas vykdymas

Dažniausios DI agentų orkestravimo klaidos

7 geriausios DI agentų orkestravimo praktikos patikimam veikimui produkcinėje aplinkoje

1. Apibrėžkite aiškias užduočių sutartis, priėmimo kriterijus ir sustabdymo sąlygas

2. Neapkraukite orkestratorių ir užtikrinkite struktūrizuotus perdavimus

3. Išsaugokite darbo eigos būseną ir kontroliuokite konteksto augimą

4. Kurkite nesėkmes įvertinančius pakartotinius bandymus ir atkuriamą įrankių vykdymą

5. Paskirstykite ir lygiagretinkite darbą taikydami aiškius išteklių biudžetus

6. Taikykite patvirtinimus ir izoliuokite agentų vykdymą

7. Nepriklausomai tikrinkite išvestis ir testuokite atkūrimo elgseną

Atsekite darbo eigą, kad nustatytumėte, kas nepavyko

Nepriklausomai peržiūrėkite išvestį

Įterpkite gedimus, kad patikrintumėte atkūrimą

DI agentų orkestravimo DUK

Kodėl izoliuotai veikiantys DI agentai nebeveikia patikimai įmonės mastu?

Kaip išvengti begalinių pakartotinių bandymų ciklų DI agentuose?

Kaip po strigties tęsti DI agento darbo eigą?

Kaip išbandyti DI agentų orkestravimo patikimumą?