AI-agentide orkestreerimine: tõrked, kinnitused ja korduskatsed

Mitme agendi töötamine samas projektis tundub äärmiselt tõhus. Üks planeerib töö, teine tegeleb disainiga ja kolmas kirjutab koodi. See toimib seni, kuni enam ei toimi. Ja tõrkeid tuleb ette sagedamini, kui sooviksite.

Nende tõrgete vältimine nõuab hoolikat töövoogude projekteerimist. Seega vaatame, mis muudab orkestreeritud töövood ebausaldusväärseks, ja uurime orkestreerimise parimaid tavasid tootmiskeskkonna töökindluse tagamiseks.

AI-agentide orkestreerimine koordineerib mitut AI-agenti, mudelit ja tööriista, et täita mitmeetapiline ülesanne. Kuid keegi – või miski – peab ikkagi otsustama, milline agent käivitub esimesena, millist teavet see saab ja mis juhtub pärast selle lõpetamist. See on orkestraatori roll – juhina tegutsev AI-agent või tarkvaraga juhitav täitmiskiht.

Lihtsamalt öeldes jaotab orkestreerimiskiht eesmärgi väiksemateks ülesanneteks, jälgib sõltuvusi, delegeerib täitmise õigetele agentidele, haldab jagatud konteksti ja koondab väljundid kokku.

Orkestreerimise täitmismootori skeem: eesmärk ja plaan, suunamine agentidele, tööriistade isoleeritud täitmine, struktureeritud tulemused, püsiv töövoo olek ning valideerimis- ja otsustusetapp, mis proovib uuesti, naaseb, peatab, ootab või liigub edasi järgmise ülesande juurde.

Vaatame, mis juhtub pärast seda, kui annate orkestraatorile ülesande.

Võtame näite Perplexity Computeri töötoast: kliendikontode ülevaate juhtpaneeli loomine Salesforce'i, Snowflake'i, e-posti, kalendri ja värskete uudiste teabe põhjal.

Eesmärgi mõistmine ja töö planeerimine. Orkestraator alustab soovitud tulemusest ja jaotab selle selgete sõltuvustega ülesanneteks. Meie juhtpaneeli näites tähendab see teabe kogumist eri allikatest ja selle muutmist valmis tulemuseks. Planeerija määrab, millised etapid sõltuvad teistest ja millised saavad toimida iseseisvalt.
Ülesannete suunamine sobivatele agentidele. Orkestraator tuvastab ülesanded, mille sõltuvused on täidetud, ja delegeerib töö spetsialiseeritud agentidele või mudelitele. Sõltuvad ülesanded ootavad oma eeltingimuste täitumist. Perplexity Computer kasutab mitut tippmudelit, suunates töövoo eri osad süsteemidele, mis sobivad nendeks ülesanneteks. See võimaldab ka sõltumatut tööd paralleelselt teha.
Tööriistakutsete täitmine kontrollitud keskkondades. Agendid suhtlevad oma keskkonnaga tööriistade kaudu, nagu veebiotsing, API-d, ühendatud rakendused, failitoimingud või koodi käivitamine. Täitmiskiht käivitab need toimingud ja tagastab tulemused agentidele.
Tulemuste ja konteksti edastamine agentide vahel. Kui agent on oma ülesande lõpetanud, vajab ahelas järgmine agent jätkamiseks asjakohast väljundit. Üleandmiskirje võib sisaldada ülesande ID-d, väljundi viidet, skeemi versiooni ja allika metaandmeid. Orkestraator koordineerib neid üleandmisi, säilitades järgnevate etappide jaoks vajaliku konteksti. Oluline on see, et agendid ei pea kandma oma kontekstiaknas kõigi teiste agentide töö kogu ajalugu.
Täitmisoleku salvestamine agendi kontekstist eraldi. Kui agendid ülesandeid alustavad, lõpetavad või neis ebaõnnestuvad, uuendab täitmismootor püsivat töövookirjet ülesannete olekute, täitmiskatsete, väljundiviidete ja järelejäänud tööga. See kirje võimaldab orkestraatoril edenemist jälgida ja pärast katkestusi jätkata, ilma et peaks lootma LLM-ile, et see rekonstrueeriks töövoo vestluse ajaloo põhjal.
Tulemuste valideerimine ja edasise tegevuse üle otsustamine. Kui ülesanne tagastab tulemuse, kontrollib orkestreerimiskiht, kas selle väljund vastab oodatud lepingule ja kas järgmise ülesande sõltuvused on täidetud. Kui leitakse probleem, saab töövoog parandamiseks naasta varasemasse etappi või selle saab peatada. Vastasel juhul liigub see lõpetamise suunas.

Näiliselt lihtsa AI-agentide orkestreerimise taga on palju liikuvaid osi. See, kuidas agentide koordineerimist korraldate, määrab, kui palju kontrolli teil täitmise üle on. Ja loomulikult tekitab kogu see koordineerimine lisakoormust. Seega ei tasu see end alati ära.

Kaaluge mitme agendi orkestreerimist siis, kui ülesande eri osad vajavad erinevat asjatundlikkust, sõltumatut tööd saab teha paralleelselt või kui järgmist sammu ei saa ette kindlaks määrata.

Seega on orkestreerimisest abi kolmes olukorras:

Ülesanded nõuavad eri spetsialiseerumist. Näiteks võib programmeerimisprojekt saada kasu eraldi planeerimis-, disaini-, arendus- ja ülevaatusagentidest.
Sõltumatuid ülesandeid saab teha paralleelselt. Selle asemel, et üks agent kõik järjest lõpetaks, saavad mitu agenti töötada samaaegselt ja tagastada oma tulemused orkestraatorile.
Probleem on avatud lõpuga. Agendid võivad vajada erinevate lähenemisviiside uurimist, otsuste tegemist ja koostööd, selle asemel et järgida eelnevalt määratud järjestust.

Muul juhul on orkestreerimine lihtsalt kulukas trend. Rohkem agente tähendab ka rohkem koordineerimist ja potentsiaalselt suuremaid tokenikulusid.

„Tavaliselt alustan kõige lihtsamast variandist ja liigun sealt edasi. Kui teame etappe ja need on korratavad, on see tõenäoliselt töövoog. Näen põhjust mitme agendi kasutuselevõtuks ainult siis, kui neil on erinevad kohustused, õigused või kasutajad,“ ütleb Josh Spilker, AirOpsi otsinguturunduse juht.

Isegi siis kaaluge kasu võrreldes täiendavate mudelikutsete, üleandmiste, latentsuse ja tõrkekohtadega.

Agentide koordineerimist saab üles ehitada kolmel levinud viisil – tsentraliseeritud, detsentraliseeritud ja hierarhiline orkestreerimine. Õige arhitektuuri valik taandub ühele küsimusele: kes juhib tööd ja kuidas agendid omavahel koordineerivad?

Tsentraliseeritud orkestreerimise puhul juhib protsessi üks orkestraator. See jaotab ülesande osadeks, delegeerib töö spetsialistidest agentidele, jälgib nende edenemist ja koondab nende tulemused kokku.

Tsentraliseeritud orkestreerimise skeem: üks orkestraator võtab vastu kasutaja päringu ja delegeerib selle uurimis-, analüüsi- ja disainiagentidele, kellest igaüks kasutab oma tööriistu ning kelle tulemused koondatakse lõplikuks juhtpaneeliks.

Kompromiss: Tsentraliseeritud koordineerimine muudab täitmise jälgimise ja ühiste reeglite rakendamise ühes kontrollpunktis lihtsamaks. Samas võib orkestraatorist saada kitsaskoht ja selle tõrge võib katkestada kogu töövoo, kui süsteem ei toeta taastamist.

Detsentraliseeritud orkestreerimise puhul koordineerivad agendid omavahel otsesemalt, selle asemel et loota ühele juhile, kes teeb iga otsuse. Nad saavad vahetada sõnumeid, lugeda jagatud olekut ja iseseisvalt oma järgmised sammud määrata.

Detsentraliseeritud orkestreerimise skeem: uurimis-, analüüsi-, disaini- ja ülevaatusagendid suhtlevad otse üksteisega ning jagatud oleku ja tööriistadega, et luua lõplik juhtpaneel.

Kompromiss: Agendid saavad tegutseda keskset planeerijat ootamata, mistõttu sobib see lähenemisviis uurimusliku töö ja sõltumatute panuste jaoks. Kuid koordineerimine muutub keerulisemaks, kui agendid on eriarvamusel, uuendavad jagatud teavet või peavad jõudma ühtse tulemuseni.

Hierarhiline orkestreerimine laiendab juhipõhist lähenemisviisi mitmele tasandile. Kõrgeima taseme orkestraator delegeerib vastutuse alluvatele orkestraatoritele, mis koordineerivad oma spetsialistidest agentide rühmi.

Mõelge ettevõtte töövoole, mis hõlmab müügi-, finants- ja õigusmeeskondi. Kõrgeima taseme orkestraator võiks delegeerida iga töösuuna valdkonnapõhisele koordinaatorile. Need koordinaatorid haldaksid seejärel oma spetsialistidest agente ja annaksid aru koondtulemustest.

See struktuur võib aidata, kui töövood on liiga ulatuslikud, et üks orkestraator suudaks neid tõhusalt hallata.

Hierarhilise orkestreerimise skeem: kõrgeima taseme orkestraator delegeerib müügi-, finants- ja õigusorkestraatoritele, millest igaüks haldab kaht spetsialistidest agenti ning mille töö koondatakse ühtseks väljundiks.

Kompromiss: Hierarhiad võimaldavad meeskondadel jagada koordineerimiskohustusi ja potentsiaalselt käsitleda tõrkeid üksikute harude sees. Samas lisavad need täiendavaid üleandmisi, keerukamat olekuhaldust ja suuremat tegevuskulu. Kohalik taastamine sõltub ka sellest, kuidas kontrollpunktid ja täitmisolek on rakendatud.

Nende arhitektuuride võrdlus:

Kriteerium	Tsentraliseeritud	Detsentraliseeritud	Hierarhiline
Vastutus täitmise eest	Delegeerimist juhib üks orkestraator	Agendid koordineerivad omavahel või jagatud oleku kaudu	Vastutus on jaotatud orkestreerimistasandite vahel
Oleku järjepidevus	Lihtsam koordineerida ühe kontrollpunkti kaudu	Nõuab selgesõnalist sünkroonimist ja konfliktide käsitlemist	Nõuab koordineerimist harude sees ja vahel
Tõrgete isoleerimine	Keskne kontroller võib muutuda kriitiliseks sõltuvuseks	Üksikud agendid võivad iseseisvalt tõrkuda, kuid jagatud taristu jääb kriitiliseks	Tõrked võivad jääda harude piiresse, kui süsteem on taastamiseks kavandatud
Poliitikate jõustamine	Ühiseid kontrollmeetmeid saab jõustada tsentraalselt	Poliitikaid tuleb kõigi osaliste puhul järjepidevalt jõustada	Kontrollmeetmeid saab rakendada nii globaalsel kui ka domeeni tasandil
Operatiivne keerukus	Üldiselt madalam	Suurem koordineerimise keerukus	Suurem keerukus mitme orkestreerimiskihi tõttu

Tasub mõista veel üht erinevust. Arhitektuur määrab, kes agente koordineerib. Täitmismuster määrab, kuidas nende ülesanded edenevad.

Need on kolm täitmismustrit:

Järjestikused töövood: Agendid töötavad eelnevalt määratud järjekorras ning ühe agendi tulemus saab teise sisendiks.
Paralleelne täitmine: Sõltumatud agendid töötavad samaaegselt.
Üleandmispõhine täitmine: Ülesande edenedes liigub juhtimine spetsialiseerunud agentide vahel. See on kasulik, kui mõni teine agent suudab järgmise sammuga paremini toime tulla, kuid iga üleandmine peab säilitama jätkamiseks vajaliku teabe.

Need mustrid ei välista üksteist ega vasta üks-ühele orkestreerimisarhitektuuridele. Eesmärk on valida lihtsaim struktuur, mis toetab teie töövoo sõltuvusi, koordineerimisnõudeid ja vastuvõetavat operatiivset lisakoormust.

Orkestreerimisel võib viltu minna mis tahes – alates lihtsatest möödalaskmistest kuni keerukate takistusteni. Mõnikord võib agent isegi näiliselt oma tööd õigesti teha, samal ajal kui töövoog tervikuna ebaõnnestub. Praktikute kogemustele toetudes oleme kokku pannud mõned levinud vead, mis muudavad orkestreeritud töövood ebausaldusväärseks – hoidke neil silm peal:

Teavet kaotavad üleandmised agentide vahel. Orkestreerija edastab spetsialiseerunud agendile kokkuvõtliku plaani, kuid kokkuvõttest jäävad välja piirangud, sõltuvused või teostuse üksikasjad.
Enneaegne tulemuste koondamine (fan-in). Järgmise etapi agent hakkab tulemusi koondama enne, kui kõik eelnevad ülesanded on lõpule jõudnud.
Mittedeterministlikud jagatud oleku värskendused. Paralleelsed agendid kirjutavad samadesse olekuvõtmetesse ilma selgelt määratletud ühendamissemantikata. Olenevalt sellest, kuidas raamistik värskendusi käsitleb, võib see põhjustada kaotsiläinud kirjutusi, dubleeritud andmeid, järjekorrast sõltuvat väljundit või vastuolulisi muudatusi.
Kontrollpunkti ja kõrvalmõjude lahknevus. Ülesanne teeb välise toimingu, kuid selle edukat täitmist ei salvestata püsivalt enne, kui töötlusprotsess tõrkub. Taastamisel näeb orkestreerija lõpetamata ülesannet ja käivitab selle uuesti.
Võidujooksud inimese kinnituse järel jätkamisel. Täitmise peatamine ja jätkamine toob kaasa omaette sünkroonimisprobleemid.
Delegeerimistsüklid ja korduskatsete võimendumine. Agendid annavad tööd korduvalt üksteisele edasi, sest nende vastutusalad kattuvad, sõltuvused on ringikujulised või lõpetamistingimused on mitmetähenduslikud.
Juhiste tasandi kontrollide ekslik pidamine täitmise turvalisuseks. Orkestreerija võib keelata agentidel teatud ressurssidele juurde pääseda või tundlikke toiminguid teha, kuid mudelijuhised ei jõusta operatsioonisüsteemi õigusi, võrgupiiranguid ega autoriseerimispiire. Perplexity turbeinseneeria uuringud näitavad, miks agendid võivad õiguspäraseid eesmärke taotledes ületada turvapiire isegi ilma pahatahtlike juhisteta

Pange tähele, kui erinevad need tõrked on. Nii ajastaja enneaegne olekuüleminek kui ka mitmetähenduslik väline kirjutustoiming võivad anda vale tulemuse, kuid need saavad alguse täitmise elutsükli eri osadest. Seepärast nõuab usaldusväärne orkestreerimine enamat kui viipade täiustamist või korduskatsete lisamist.

Ebamäärased eesmärgid ja ebaselge valmisoleku määratlus viivad sageli selleni, et agentide loodud tulemused valmistavad pettumuse. Lahendus on viibaleping (agendi töö ulatuse kirjeldus): leppige eesmärk, piirangud, väljundvorming ja ebaõnnestumise tingimused kokku enne täitmise algust.

Näiteks saate aeg-ajalt ebaõnnestuva integratsioonitesti parandamise eest vastutava agendi lepingu määratleda järgmiselt:

Eesmärk: Tuvastage ja kõrvaldage ostu vormistamise API ebastabiilse integratsioonitesti põhjus.
Sisendid: Testi lähtekood, CI tõrkelogid, hiljutised commit’id ja asjakohane rakenduse kood.
Piirangud: Ärge keelake teste välja, ärge leevendage kontrollväiteid ega muutke rakenduse sellega mitteseotud käitumist.
Oodatav väljund: Koodiparandus, algpõhjuse selgitus ja testide käitamise tulemused.
Vastuvõtukriteeriumid: Varem ebaõnnestunud test läbib 10 järjestikust käivitust ja asjakohane regressioonitestide komplekt läbitakse edukalt.
Ebaõnnestumise tingimused: Algpõhjust ei õnnestu tuvastada, parandus toob kaasa regressioone või vajalik testikeskkond pole saadaval.

Kuid on veel üks oluline osa: millal peaks agent peatuma?

Agent ei tohiks lõputult itereerida ainult seetõttu, et ta pole veel rahuldavat tulemust saavutanud. Määratlege, mida loetakse edukaks lõpetamiseks, millal tagastada osaliselt lõpetatud ülesanne ja millal peatuda, sest nõuet ei ole võimalik täita. Seadke maksimaalne delegeerimissügavus ja iteratsioonipiirangud või täitmiseelarved, et lahendamata ülesanded ei muutuks lõpututeks tsükliteks.

Tagasi meie CI näite juurde. Võiksite määratleda järgmised peatumistingimused:

Edu: Parandus läbib 10 järjestikust testikäivitust ja asjakohase regressioonitestide komplekti.
Iteratsioonipiirang: Agent võib proovida kõige rohkem kahte parandusvarianti.
Täitmiseelarve: Agent peab 60 minuti pärast peatuma, isegi kui probleem jääb lahendamata.
Delegeerimispiirang: Agent võib delegeerida töö ühele spetsialiseerunud agendile, kuid edasine delegeerimine alamagentidele pole lubatud.
Osaline lõpetamine: Kui mõlemad katsed ebaõnnestuvad või ajapiirang saab täis, tagastab agent oma leiud, proovitud muudatused ja testitulemused.
Blokeeritud täitmine: Kui testikeskkond pole saadaval, agent peatub ja teatab takistusest, selle asemel et väita, et töö õnnestus.

Mõnikord annavad arendajad orkestreerijale liiga palju kohustusi ning spetsialiseerunud agentide koordineerimise asemel hakkab see ise koodi kirjutama, siluma või üksikasjalikke ülevaatusi tegema. See tekitab kitsaskoha: orkestreerija kulutab oma kontekstieelarve teostuse üksikasjadele, lükkab delegeerimist edasi ja hägustab vastutust tulemuste eest.

Seega laske orkestreerijatel oma tööd teha ja nõudke üleandmisi, mis viitavad konkreetsetele artefaktidele: algsele ülesandele, asjakohastele sisenditele, väljundartefaktidele, täitmise olekule ja kõigile lahendamata probleemidele.

Vaadake seda näidet: status: completed viitab agendile määratud tööle, mitte kogu töövoole. Kuna testid on endiselt olekus pending, ei tohiks orkestreerija lõpptulemust kinnitada.

json

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

Agendi vestlusajalugu ei ole töövoo edenemise usaldusväärne kirje. Kui agendi kontekstiaken täitub, võib automaatne tihendamine olulised üksikasjad välja jätta. Ja kui töötlusprotsess jookseb kokku, peab järgmine agent teadma, millised sammud on tegelikult lõpetatud.

Näiteks kui kodeerimisagent loob paranduse ja jookseb seejärel kokku, peaks järgmine töötlusprotsess salvestatud artefakti kätte saama ja jätkama salvestatud töövoo olekust. Kui agent käivitas aga ka välise CI käituse, peab orkestreerija selle käituse eraldi üle kontrollima, enne kui toimingut korratakse

Seega hoidke täitmise olek agendi töökontekstist eraldi. Salvestage ülesannete olekud, täitmiskatsed, lõpetatud sammud ja artefaktiviited püsivasse salvestusruumi. Samal ajal laadige ainult agendi praeguse ülesande jaoks asjakohased juhised, sisendid ja tulemused, selle asemel et toppida kogu täitmisajalugu tema kontekstiaknasse.

Oletame, et teie CI-agent käivitab testikäituse, kuid API-päring aegub. Kas testikäitus jäi käivitamata või pani CI-teenus selle järjekorda ja vastus läks kaotsi?

Ajalõpp ei tähenda tingimata, et toiming ebaõnnestus. Seepärast peate enne edasise tegevuse üle otsustamist vigu eristama:

Ajutised vead (429, 503): Proovige uuesti piiratud eksponentsiaalse ooteaja pikendamise ja juhusliku hajutusega (jitter), järgides päist Retry-After, kui see on olemas.
Valideerimis- või õigusvead (400, 403): Peatuge või parandage algpõhjus, selle asemel et sama päringut korrata.
Ebaselged tulemused (ajalõpp pärast võimalikku kirjutamist): Kontrollige enne uut katset, kas toiming õnnestus.

Märkus: Ka uuesti proovitavad vead vajavad piiranguid. Määrake igale tööriistakutsele ajalõpp, piirake korduskatsete arvu ja nende koguaega ning jõustage kogu töövoo tähtaeg, et pesastatud agendid ei saaks sama toimingut lõputult uuesti käivitada. Kui mõni sõltuvus korduvalt tõrgub, kasutage päringute ajutiseks peatamiseks kaitselülitit (circuit breaker).

Väliste kõrvalmõjudega toimingute puhul määrake igale loogilisele toimingule stabiilne idempotentsusvõti ja kasutage seda korduskatsetel uuesti. Kui API toetab serveripoolset dubleerimise vältimist, suudab see korduvad päringud ära tunda, ilma et toimingut kaks korda tehtaks. Kui ei toeta, pärige välissüsteemist teavet korrelatsiooni-ID või muu autoriteetse viite abil.

Kui te ei suuda kindlaks teha, mis juhtus, peatuge ja eskaleerige.

Näide meie CI-agendi korduskatsete loogikast pseudokoodina:

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)

Märkus koodi kohta: Näide eeldab, et CI API toetab käituste otsimist päringu ID järgi. Väli request_id hoiab duplikaate ära ainult siis, kui teenusepakkuja tagab selgesõnaliselt idempotentsuse. bounded_retry() on illustreeriv pseudokood. Tootmiskeskkonnas peaksid korduskatseid piirama nii toimingupõhine korduskatsete eelarve (maksimaalne katsete arv või kulunud aeg) kui ka kogu töövoo tähtaeg.

Mitut teenust hõlmavate pikemate töövoogude puhul kaaluge Saga-mustrit, et koordineerida kompenseerivaid toiminguid, kui hilisemad sammud ebaõnnestuvad. Pidage siiski meeles, et kompenseerimine ei ole alati täielik tagasipööramine. Andmebaasi värskenduse saab tagasi pöörata, kuid saadetud e-kirja tagasi võtta ei saa.

Siin tuleb tasakaalustada kahte asja: kui palju mudeli võimekust iga ülesanne vajab ja kui palju ülesandeid saate samaaegselt käitada. Kui eksite kummaski, riskite sellega, et agendid konkureerivad jagatud API-kvootide pärast või toetuvad ainult kallitele arutlusmudelitele.

Mis puudutab mudeli valikut, sobitage mudeli võimekus ja arutluspingutus ülesande keerukusega – lihtne, kuid sageli tähelepanuta jäetud põhimõte. Pange tähele, et võite kas ise marsruutimisreeglid seadistada ja mudeleid hinnata või kasutada orkestreerimisplatvormi, mis teeb mudelivaliku teie eest.

Näiteks võimaldab Perplexity Computer režiim Effort Mode valida, kui palju pingutust ülesanne väärib, ilma et peaksite mudelit käsitsi valima. Valige Light, Standard, High või Ultra ja Perplexity valib automaatselt orkestreeriva mudeli ning selle arutlustaseme. Seejärel delegeerib see orkestreerija alamülesanded abiagentidele, mis võivad kasutada eri teenusepakkujate mudeleid.

Perplexity hindab mudelikonfiguratsioonide kvaliteeti ja kulu, eelistades odavamaid valikuid, mis annavad võrreldavaid tulemusi. Kui eelistate mudeli ja arutlustaseme ise valida, saate kasutada ka valikut Custom.

Paralleelsuse puhul peaks piirang tulenema teie taristust ja välistest sõltuvustest. Kontrollige jagatud API-de päringu- ja tokenimäära piiranguid ning seejärel koormustestige oma töövoogu järjest suureneva samaaegsusega. Jälgige, kas läbilaskevõime paraneb või hakkavad päringud järjekorda kogunema, aeglustuma või tagastama 429-vigu.

Et ressursikasutus püsiks prognoositav, jõustage ressursipiirangud ja ajastamise kontrollid:

Kontrollige samaaegsust ja päringumäärasid: Piirake iga teenuse pooleliolevate kutsete arvu ja pange ülejääv töö järjekorda. Pidage meeles, et samaaegsuse ülempiir üksi ei jõusta päringute ega tokenite minutipiiranguid.
Jälgige tokeni- ja kulueelarveid: Arvestage kasutust kogu töövoo ulatuses, sealhulgas alamagentide oma, ja lõpetage uue töö käivitamine, kui järelejäänud eelarvest ei piisa.
Jõustage täitmise tähtajad: Seadke ülesannetele ja töövoogudele ajapiirangud ning edastage tühistamine töötavatele agentidele, kui see on toetatud.
Arvestage sõltuvustega: Käivitage järgmise etapi ülesanded alles siis, kui nende jaoks vajalikud sisendid on saadaval, selle asemel et käivitada kõik agendid korraga.

Ärge kunagi laske mudelil otsustada, kas tema enda toimingud on ohutud. Selle asemel andke agentidele load vähimate õiguste põhimõtte järgi ja jõustage riskipõhised kinnitusreeglid rakenduse koodis. Kui agendid käitavad koodi, isoleerige koodi täitmine oma hostkeskkonnast ning piirake juurdepääsu failidele, võrkudele ja mandaatidele. See piirab kahju, kui agent teeb vea või käitab ohtlikku koodi.

„Suhtun liiga keerukatesse mitmeagendilistesse süsteemidesse skeptiliselt, eriti kui agendid vaatavad üksteise tööd üle ja kinnitavad seda. Võib juhtuda, et mitu agenti annavad sama vea enesekindlalt edasi, ilma et keegi seda tegelikult tabaks,“ hoiatab Spilker.

Kinnitusvoo skeem: agent pakub välja toimingu koos parameetrite, sihtressursi ja olekuversiooniga; inimene kinnitab või lükkab selle tagasi; kinnitatud toimingud valideeritakse uuesti ja käitatakse isoleeritud keskkonnas, kus juurdepääs failidele, võrgule ja mandaatidele on piiratud. Tagasilükatud või aegunud taotlused suletakse ning muudetud taotlused vajavad uut kinnitust.

Inimese kinnitust vajavate toimingute puhul peatage täitmine ja salvestage täpne kavandatud toiming:

selle parameetrid
selle sihtressurss
selle commit või olekuversioon
ülevaataja otsus

Määratlege ka, mis juhtub, kui kinnitus lükatakse tagasi, aegub või vajab eskaleerimist. See on jätkatavate raamistike puhul hädavajalik, sest katkestatud sõlme jätkamisel käivitatakse kood selle sõlme algusest uuesti. Kõik enne katkestust toimunud kõrvalmõjud võivad uuesti aset leida.

Seega kui kinnitus lükatakse tagasi või aegub, suletakse taotlus. Kui siht-commit, parameetrid või õigused muutuvad enne täitmist, tühistage kinnitus ja taotlege uus.

Spilker ei toeta ka ideed, et eesmärgiks tuleks pidada täielikult autonoomseid, otsast lõpuni toimivaid agente. „Minu jaoks on parem lähenemine luua mõned kitsalt keskendunud agendid, millel on selged vastutusalad, määratletud õigused ja inimese ülevaatus õigetes kohtades. Nii saavutate ikkagi tõhususe, loobumata täielikust kontrollist,“ võtab ta kokku.

Kas teie agent on kunagi teatanud olekust Edukas, kuigi see tegelikult ebaõnnestus? See on tüütu, kui mitte lausa vihastav, ja selle parandamine ei käi kiiresti, sest agendi lõppsõnum ei pruugi teile öelda, kus asi viltu läks.

Uurimiseks jälgige, mis täitmise ajal juhtus, ja kontrollige tulemusi sõltumatult. Seega pühendame veidi aega probleemi isoleerimisele ja lahendamisele.

Enne agendi viipade silumist salvestage kogu täitmistee. Vajate jälge, mis seob agendi väljakutsed, tööriistakutsed, vead ja korduskatsed sama töövoo käituse alla.

OpenTelemetry GenAI semantilised konventsioonid pakuvad standardset viisi nende toimingute kirjeldamiseks. Näiteks invoke_workflow tähistab töövoo täitmist, invoke_agent agendi väljakutset ja execute_tool tööriistakutset. Iga toimingu saab salvestada vahemikuna (span) koos selle ajastuse, oleku ja asjakohaste metaandmetega.

See samm annab teile täitmistee jälje, nii et saate tuvastada, kus agent komistas.

plaintext

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

agent_response: "Success"

Illustreeriv täitmisjälg.

Kasutage võimaluse korral programmilisi kontrolle. Valideerige väljundeid JSON-skeemide alusel, käitage ühiku- ja integratsiooniteste, kontrollige, kas nõutavad artefaktid on olemas, ning pärige välissüsteemidest, kas toimingud tegelikult õnnestusid.

Subjektiivset hinnangut nõudvate väljundite puhul, mida seetõttu ei saa programmiliste kontrollidega hinnata, kaasake sõltumatu ülevaatusagent. Üks lähenemisviis on teostaja–ülevaataja–lahendaja tsükkel, kus üks agent loob artefakti, värske kontekstiga ülevaataja tuvastab probleemid ja lahendaja kõrvaldab need, enne kui valideerimine uuesti käivitub.

Ülevaataja leide tuleb siiski võimaluse korral valideerida ning kui kasutate korduvateks hindamisteks LLM-põhiseid hindajaid, kalibreerige nende hinnanguid inimeste üle vaadatud näidete põhjal.

Siiani oled jälginud, mida agendid täitsid, ja kontrollinud, kas nende väljundid olid õiged. Aga mis juhtub, kui töötlusprotsess jookseb ülesande poole peal kokku või API aegub pärast päringu vastuvõtmist? Üllataval kombel võib sinu töövoog tavatingimustes toimida täiesti korralikult, kuid taastamise ajal ebaõnnestuda.

Selle testimiseks tekita testkeskkonnas teadlikult tõrkeid:

Simuleeri API ajalõppe
Põhjusta töötlusprotsesside krahh väliste kirjutustoimingute ja kontrollpunktide vahel
Tagasta vigase vorminguga tööriistaväljundeid
Lase kinnitustel aeguda

Pärast iga testi uuri täitmisjälge, et näha, millised sammud käivitati, kust töövoog jätkus ja kas mõnda toimingut korrati või see jäeti vahele. Seejärel vaata üle tegelikud tulemused.

Oletame, et sinu CI-agent saadab päringu testkäivituse alustamiseks, kuid API vastus aegub. Agent proovib uuesti, saab eduka vastuse ja teatab: Success. Kõik näib korras olevat, kuni kontrollid CI-teenust ja avastad, et ühe testkäivituse asemel loodi kaks.

Seetõttu tuleks kontrollida nii töövoo salvestatud olekut kui ka tegelikke muudatusi välissüsteemides. Taastetest peaks õnnestuma ainult siis, kui töövoog jõuab oodatud olekusse ilma soovimatute kõrvalmõjudeta.

Lisa avastatud tõrked oma regressioonitestidesse, et tulevased muudatused neid uuesti sisse ei tooks.

Lõppkokkuvõttes tähendab edu, et töövoog läbis nõutavad kontrollid ja selle välised tulemused on kontrollitud.

Isoleeritud agendid võivad oma üksikud ülesanded õigesti täita, kuid koos anda vastuolulisi tulemusi. Kujuta ette, et müügiagent hangib kliendi tingimused kell 10.00, hinnastamisagent arvutab pakkumise uuendatud hindade põhjal kell 10.05 ja juriidiline agent kontrollib lepingut, mis muutus kell 10.07. Iga agent töötab ettevõtte erineva hetkeseisuga, mistõttu võivad nende väljundid üksteisele vastu rääkida.

Ettevõtte mastaabis muutub probleem teravamaks, sest agendid suhtlevad mitme süsteemiga, mis uuenevad üksteisest sõltumatult, töötavad erinevate õigustega ega pruugi jagada konteksti ega täitmisolekut.

Sea piirangud mitmel tasandil: tööriistakutsete korduskatsete maksimumarv, agendi iteratsioonide maksimumarv, delegeerimise sügavus ja kogu töövoo üldine tähtaeg. Klassifitseeri tõrked enne uuesti proovimist. Ajutiste 429 vastuste korral järgi päist Retry-After, kui see on olemas. Muul juhul kasuta piiratud eksponentsiaalset ooteaega koos juhusliku hajutusega (jitter).

Ära korda muutmata päringuid pärast valideerimis- või õigusvigu. Kui allavoolu teenus korduvalt ebaõnnestub, saab kaitselüliti (circuit breaker) takistada agentidel täiendava koormuse tekitamist.

Taastemehhanism sõltub sinu käituskeskkonnast. LangGraphi puhul salvestab püsiv kontrollpunktide salvesti, näiteks PostgresSaver, graafi oleku identifikaatori thread_id alla, mis võimaldab täitmist jätkata püsivalt salvestatud olekust. Temporali puhul saab teine töötlusprotsess töövoo rekonstrueerida, taasesitades selle sündmuste ajaloo. Taasesituse ajal kasutatakse uuesti varem salvestatud tegevuste tulemusi.

Kui rakendus juurutatakse uuesti ajal, mil töövood veel töötavad, ei pruugi salvestatud olek ja täitmisajalood enam ühilduda. Temporal lahendab selle Worker Versioningu ja töövoogude paikamise abil. Kontrollpunktipõhiste süsteemide puhul planeeri skeemimigratsioonid ja testi taastamist olemasolevate salvestatud olekutega enne ühildumatute muudatuste kasutuselevõttu.

Käivita samu esinduslikke ülesandeid mitu korda ja erista mõõdikut pass@k (kas vähemalt üks k katsest õnnestub) mõõdikust pass^k (kas kõik k katset õnnestuvad)

Mõõda tulemusi ülesandekategooriate ja töövoo versioonide kaupa, selle asemel et tugineda ühele koondatud edukuse määrale. Jälgi esimese katse edukust, järjepidevust korduvate käivituste lõikes, p95 latentsust, kulu lõpetatud ülesande kohta ja inimsekkumist vajavate juhtumite osakaalu. Esita edukuse määrade juures valimi suurused ja määramatuse vahemikud.

Mis on AI-agentide orkestreerimine?

Kuidas AI-agentide orkestreerimine toimib: pilk täitmismootori sisse

Millal peaksite kasutama AI-agentide orkestreerimist?

AI-agentide orkestreerimise arhitektuurid ja nende kompromissid

Tsentraliseeritud orkestreerimine

Detsentraliseeritud orkestreerimine

Hierarhiline orkestreerimine

Järjestikune, paralleelne ja üleandmispõhine täitmine

AI-agentide orkestreerimise levinud tõrked

7 parimat tava AI-agentide töökindlaks orkestreerimiseks tootmiskeskkonnas

1. Määratlege selged ülesandelepingud, vastuvõtukriteeriumid ja peatumistingimused

2. Hoidke orkestreerijad kerged ja nõudke struktureeritud üleandmisi

3. Salvestage töövoo olek püsivalt ja hoidke konteksti kasv kontrolli all

4. Kavandage tõrkeid arvestavad korduskatsed ja taastatav tööriistade täitmine

5. Suunake ja paralleelistage tööd selgete ressursieelarvete abil

6. Jõustage kinnitused ja isoleerige agentide täitmine

7. Kontrollige väljundeid sõltumatult ja testige taastumiskäitumist

Jälgige töövoogu, et tuvastada, mis läks valesti

Vaadake väljund sõltumatult üle

Tekitage taastumise testimiseks tahtlikult tõrkeid

AI-agentide orkestreerimise KKK

Miks isoleeritud AI-agendid ettevõtte mastaabis toimimast lakkavad?

Kuidas vältida AI-agentide lõputuid korduskatsete tsükleid?

Kuidas jätkata AI-agendi töövoogu pärast krahhi?

Kuidas testida AI-agentide orkestreerimise töökindlust?