MI aģentu orķestrēšana: kļūmes, apstiprinājumi un atkārtoti mēģinājumi

Vairāku aģentu darbs pie viena projekta izklausās ārkārtīgi efektīvs. Viens plāno darbu, cits nodarbojas ar dizainu, bet trešais raksta kodu. Tas darbojas, līdz vairs nedarbojas. Un kļūmes notiek biežāk, nekā gribētos.

Lai novērstu šīs kļūmes, nepieciešama rūpīga darbplūsmu izstrāde. Tāpēc aplūkosim, kas padara orķestrētas darbplūsmas neuzticamas, un izpētīsim orķestrēšanas paraugpraksi uzticamai darbībai produkcijas vidē.

MI aģentu orķestrēšana koordinē vairākus MI aģentus, modeļus un rīkus, lai paveiktu vairāku soļu uzdevumu. Taču kādam — vai kaut kam — joprojām ir jāizlemj, kurš aģents darbojas pirmais, kādu informāciju tas saņem un kas notiek pēc tam, kad tas pabeidz darbu. Tā ir orķestrētāja loma — MI aģents, kas darbojas kā vadītājs, vai programmatūras vadīts izpildes slānis.

Vienkārši sakot, orķestrēšanas slānis sadala mērķi mazākos uzdevumos, seko atkarībām, deleģē izpildi piemērotajiem aģentiem, pārvalda kopīgo kontekstu un apvieno rezultātus.

Orķestrēšanas izpildes dzinēja diagramma: mērķis un plāns, maršrutēšana uz aģentiem, rīku izpilde izolācijā, strukturēti rezultāti, pastāvīgs darbplūsmas stāvoklis un validācijas un lēmuma solis, kas atkārto mēģinājumu, atgriežas, pauzē, gaida vai pāriet pie nākamā uzdevuma.

Aplūkosim, kas notiek pēc tam, kad orķestrētājam ir uzdots uzdevums.

Aplūkosim piemēru no Perplexity Computer darbnīcas: klientu kontu analītikas informācijas paneļa izveide, izmantojot informāciju no Salesforce, Snowflake, e-pasta, kalendāra un jaunākajām ziņām.

Izprast mērķi un saplānot darbu. Orķestrētājs sāk ar pieprasīto rezultātu un sadala to uzdevumos ar skaidri noteiktām atkarībām. Mūsu informācijas paneļa piemērā tas nozīmē informācijas apkopošanu no dažādiem avotiem un tās pārvēršanu gatavā nododamā rezultātā. Plānotājs nosaka, kuri soļi ir atkarīgi no citiem un kurus var izpildīt neatkarīgi.
Novirzīt uzdevumus piemērotajiem aģentiem. Orķestrētājs identificē uzdevumus, kuru atkarības ir izpildītas, un deleģē darbu specializētiem aģentiem vai modeļiem. Atkarīgie uzdevumi gaida savus priekšnosacījumus. Perplexity Computer izmanto vairākus vismodernākos modeļus, novirzot dažādas darbplūsmas daļas sistēmām, kas ir piemērotas šiem uzdevumiem. Tas arī ļauj neatkarīgu darbu veikt paralēli.
Izpildīt rīku izsaukumus kontrolētās vidēs. Aģenti mijiedarbojas ar savu vidi, izmantojot rīkus, piemēram, tīmekļa meklēšanu, API, savienotās lietojumprogrammas, failu darbības vai koda izpildi. Izpildes slānis veic šīs darbības un atgriež rezultātus aģentiem.
Nodot rezultātus un kontekstu starp aģentiem. Kad aģents pabeidz savu uzdevumu, nākamajam aģentam ķēdē ir nepieciešams attiecīgais rezultāts, lai turpinātu. Nodošanas ierakstā var būt uzdevuma ID, atsauce uz rezultātu, shēmas versija un avota metadati. Orķestrētājs koordinē šīs nodošanas, vienlaikus saglabājot kontekstu, kas nepieciešams turpmākajiem soļiem. Svarīgi, ka aģentiem nav jāglabā savos konteksta logos visa citu aģentu darba vēsture.
Reģistrēt izpildes stāvokli atsevišķi no aģenta konteksta. Kad aģenti sāk, pabeidz vai neizpilda uzdevumus, izpildes dzinējs atjaunina pastāvīgu darbplūsmas ierakstu ar uzdevumu statusiem, izpildes mēģinājumiem, atsaucēm uz rezultātiem un atlikušo darbu. Šis ieraksts ļauj orķestrētājam sekot progresam un atsākt darbu pēc pārtraukumiem, nepaļaujoties uz to, ka LLM rekonstruēs darbplūsmu no sarunu vēstures.
Validēt rezultātus un izlemt, kas notiks tālāk. Kad uzdevums atgriež rezultātu, orķestrēšanas slānis pārbauda, vai tā izvade atbilst gaidītajam līgumam un vai nākamā uzdevuma atkarības ir izpildītas. Ja tiek atrasta problēma, darbplūsma var atgriezties pie kāda no iepriekšējiem soļiem labošanai vai tikt pauzēta. Pretējā gadījumā tā turpinās līdz pabeigšanai.

Aiz šķietami vienkāršas MI aģentu orķestrēšanas slēpjas daudz kustīgu daļu. Tas, kā organizējat aģentu koordināciju, nosaka, cik liela kontrole jums ir pār izpildi. Un, protams, visa šī koordinācija rada papildu izmaksas. Tāpēc tā ne vienmēr ir tā vērta.

Apsveriet vairāku aģentu orķestrēšanu, ja dažādām uzdevuma daļām nepieciešamas atšķirīgas zināšanas, neatkarīgu darbu var veikt paralēli vai nākamo soli nav iespējams noteikt iepriekš.

Tādējādi orķestrēšana ir noderīga trīs scenārijos:

Uzdevumiem nepieciešamas dažādas specializācijas. Piemēram, programmēšanas projektā varētu noderēt atsevišķi plānošanas, dizaina, izstrādes un pārskatīšanas aģenti.
Neatkarīgus uzdevumus var veikt paralēli. Tā vietā, lai viens aģents visu paveiktu secīgi, vairāki aģenti var strādāt vienlaikus un atgriezt savus rezultātus orķestrētājam.
Problēmai nav iepriekš noteikta risinājuma ceļa. Aģentiem var būt jāizpēta dažādas pieejas, jāpieņem lēmumi un jāsadarbojas, nevis jāseko iepriekš noteiktai secībai.

Citos gadījumos orķestrēšana ir tikai dārga modes tendence. Vairāk aģentu nozīmē arī vairāk koordinācijas un, iespējams, lielākas tokenu izmaksas.

„Parasti es sāku ar vienkāršāko variantu un turpinu no tā. Ja mēs zinām soļus un tie ir atkārtojami, tā, visticamāk, ir darbplūsma. Iemeslu ieviest vairākus aģentus es redzu tikai tad, ja tiem ir atšķirīgi pienākumi, atļaujas vai lietotāji,” saka Josh Spilker, AirOps meklēšanas mārketinga vadītājs.

Pat tad izvērtējiet ieguvumus salīdzinājumā ar papildu modeļu izsaukumiem, nodošanām, latentumu un kļūmju punktiem.

Ir trīs izplatīti veidi, kā strukturēt aģentu koordināciju — centralizēta, decentralizēta un hierarhiska orķestrēšana. Pareizās arhitektūras izvēle ir atkarīga no viena jautājuma: kas kontrolē darbu un kā aģenti koordinējas savā starpā?

Centralizētā orķestrēšanā procesu pārvalda viens orķestrētājs. Tas sadala uzdevumu, deleģē darbu specializētiem aģentiem, seko to progresam un apvieno to rezultātus.

Centralizētas orķestrēšanas diagramma: viens orķestrētājs saņem lietotāja pieprasījumu un deleģē to izpētes, analīzes un dizaina aģentiem, no kuriem katrs izmanto savus rīkus, un to rezultāti tiek apvienoti galīgajā informācijas panelī.

Kompromiss: centralizēta koordinācija atvieglo izpildes izsekošanu un kopīgu noteikumu piemērošanu vienā kontroles punktā. Tomēr orķestrētājs var kļūt par vājo vietu, un tā kļūme var pārtraukt visu darbplūsmu, ja vien sistēma neatbalsta atkopšanu.

Decentralizētā orķestrēšanā aģenti koordinējas tiešāk, nevis paļaujas uz vienu vadītāju, kas pieņem katru lēmumu. Tie var apmainīties ar ziņojumiem, lasīt kopīgo stāvokli un patstāvīgi noteikt savus nākamos soļus.

Decentralizētas orķestrēšanas diagramma: izpētes, analīzes, dizaina un pārskatīšanas aģenti tieši sazinās cits ar citu, kā arī ar kopīgo stāvokli un rīkiem, lai izveidotu galīgo informācijas paneli.

Kompromiss: aģenti var darboties, negaidot centrālo plānotāju, tāpēc šī pieeja ir noderīga izpētes darbam un neatkarīgiem ieguldījumiem. Taču koordinācija kļūst sarežģītāka, ja aģentiem ir atšķirīgi viedokļi, tie atjaunina kopīgo informāciju vai tiem jānonāk pie konsekventa rezultāta.

Hierarhiskā orķestrēšana paplašina vadītāja pieeju vairākos līmeņos. Augstākā līmeņa orķestrētājs deleģē atbildību pakārtotiem orķestrētājiem, kas koordinē savas specializēto aģentu grupas.

Iedomājieties uzņēmuma darbplūsmu, kurā iesaistītas pārdošanas, finanšu un juridiskās komandas. Augstākā līmeņa orķestrētājs varētu deleģēt katru darba virzienu konkrētai jomai paredzētam koordinatoram. Šie koordinatori pēc tam pārvaldītu savus specializētos aģentus un ziņotu apkopotus rezultātus.

Šāda struktūra var palīdzēt, ja darbplūsmas ir pārāk plašas, lai viens orķestrētājs tās efektīvi pārvaldītu.

Hierarhiskas orķestrēšanas diagramma: augstākā līmeņa orķestrētājs deleģē darbu pārdošanas, finanšu un juridiskajiem orķestrētājiem, no kuriem katrs pārvalda divus specializētus aģentus, un to darbs tiek apvienots kopējā rezultātā.

Kompromiss: hierarhijas ļauj komandām sadalīt koordinācijas pienākumus un, iespējams, apstrādāt kļūmes atsevišķos zaros. Tomēr tās rada papildu nodošanas, sarežģītāku stāvokļa pārvaldību un lielākas darbības izmaksas. Lokālā atkopšana ir atkarīga arī no tā, kā ir ieviesti kontrolpunkti un izpildes stāvoklis.

Šo arhitektūru salīdzinājums:

Kritēriji	Centralizēta	Decentralizēta	Hierarhiska
Atbildība par izpildi	Deleģēšanu kontrolē viens orķestrētājs	Aģenti koordinējas ar citiem aģentiem vai caur kopīgo stāvokli	Atbildība ir sadalīta starp orķestrēšanas līmeņiem
Stāvokļa konsekvence	Vieglāk koordinēt, izmantojot vienu kontroles punktu	Nepieciešama skaidri noteikta sinhronizācija un konfliktu apstrāde	Nepieciešama koordinācija zaru ietvaros un starp tiem
Kļūmju izolācija	Centrālais kontrolleris var kļūt par kritisku atkarību	Atsevišķu aģentu kļūmes var notikt neatkarīgi, taču kopīgā infrastruktūra joprojām ir kritiska	Kļūmes var ierobežot atsevišķos zaros, ja sistēma ir izstrādāta atkopšanai
Politiku piemērošana	Kopīgās kontroles var piemērot centralizēti	Politikas jāpiemēro konsekventi visiem dalībniekiem	Kontroles var piemērot globālā un domēnu līmenī
Darbības sarežģītība	Parasti zemāka	Augstāka koordinācijas sarežģītība	Augstāka sarežģītība vairāku orķestrēšanas slāņu dēļ

Ir vēl viena atšķirība, ko vērts izprast. Arhitektūra nosaka, kas koordinē aģentus. Izpildes modelis nosaka, kā norit to uzdevumi.

Pastāv trīs izpildes modeļi:

Secīgas darbplūsmas: aģenti strādā iepriekš noteiktā secībā, un viena aģenta rezultāts kļūst par cita aģenta ievaddatiem.
Paralēla izpilde: neatkarīgi aģenti strādā vienlaikus.
Uz nodošanu balstīta izpilde: uzdevumam virzoties uz priekšu, kontrole pāriet starp specializētiem aģentiem. Tas ir noderīgi, ja cits aģents ir labāk sagatavots nākamā soļa veikšanai, taču katrā nodošanā jāsaglabā informācija, kas nepieciešama darba turpināšanai.

Šie modeļi nav savstarpēji izslēdzoši, un tie neatbilst orķestrēšanas arhitektūrām attiecībā viens pret vienu. Mērķis ir izvēlēties vienkāršāko struktūru, kas atbalsta jūsu darbplūsmas atkarības, koordinācijas prasības un pieļaujamo darbības papildslodzi.

Orķestrēšanā var noiet greizi jebkas — no vienkāršām neuzmanības kļūdām līdz sarežģītiem šķēršļiem. Dažreiz aģents pat var šķietami pareizi paveikt savu darbu, kamēr darbplūsma kopumā cieš neveiksmi. Balstoties uz praktiķu pieredzi, esam apkopojuši dažas biežākās kļūdas, kuru dēļ orķestrētas darbplūsmas kļūst neuzticamas, — pievērsiet tām uzmanību:

Aģentu nodošana ar informācijas zudumu. Orķestrētājs nodod specializētam aģentam plāna kopsavilkumu, taču kopsavilkumā pazūd ierobežojumi, atkarības vai ieviešanas detaļas.
Priekšlaicīga rezultātu apvienošana (fan-in). Lejupējais aģents sāk apkopot rezultātus, pirms visi augšupējie uzdevumi ir pabeigti.
Nedeterministiski koplietotā stāvokļa atjauninājumi. Paralēli aģenti raksta vienās un tajās pašās stāvokļa atslēgās bez skaidri definētas apvienošanas semantikas. Atkarībā no tā, kā ietvars apstrādā atjauninājumus, tas var izraisīt zaudētus ierakstus, dublētus datus, no secības atkarīgu izvadi vai konfliktējošas izmaiņas.
Kontrolpunktu un blakusefektu nesakritība. Uzdevums veic ārēju darbību, taču tās veiksmīgā izpilde netiek noturīgi reģistrēta, pirms izpildes process avarē. Atkopšanās laikā orķestrētājs redz nepabeigtu uzdevumu un palaiž to atkārtoti.
Sacīkšu stāvokļi, atsākot darbu pēc cilvēka apstiprinājuma. Izpildes apturēšana un atsākšana rada savas sinhronizācijas problēmas.
Deleģēšanas cilpas un atkārtojumu pastiprināšanās. Aģenti atkārtoti nodod darbu cits citam, jo to pienākumi pārklājas, atkarības ir cikliskas vai pabeigšanas nosacījumi ir neskaidri.
Instrukciju līmeņa kontroles, ko kļūdaini uzskata par izpildes drošību. Orķestrētājs var likt aģentiem nepiekļūt noteiktiem resursiem vai neveikt sensitīvas darbības, taču modeļa instrukcijas nenodrošina operētājsistēmas atļauju, tīkla ierobežojumu vai autorizācijas robežu ievērošanu. Perplexity drošības inženierijas pētījums uzsver, kāpēc aģenti var šķērsot drošības robežas, tiecoties sasniegt leģitīmus mērķus, pat bez ļaunprātīgām instrukcijām

Ievērojiet, cik atšķirīgas ir šīs kļūmes. Gan priekšlaicīga plānotāja pāreja, gan neskaidrs ārējs ieraksts var radīt nepareizu iznākumu, taču tās rodas dažādās izpildes dzīves cikla daļās. Tāpēc uzticamai orķestrēšanai nepietiek tikai uzlabot uzvednes vai pievienot atkārtojumus.

Neskaidri mērķi un nenoteikta pabeigtības definīcija bieži noved pie aģentu radītiem rezultātiem, kas sagādā vilšanos. Risinājums ir uzvednes līgums (aģenta darba apjoma apraksts): vienojieties par mērķi, ierobežojumiem, izvades formātu un kļūmes nosacījumiem pirms izpildes sākuma.

Piemēram, lūk, kā varētu definēt līgumu aģentam, kas atbild par tāda integrācijas testa labošanu, kurš laiku pa laikam neizdodas:

Mērķis: noteikt un novērst nestabila norēķinu API integrācijas testa cēloni.
Ievaddati: testa pirmkods, CI kļūmju žurnāli, nesenie komiti un attiecīgais lietojumprogrammas kods.
Ierobežojumi: neatspējojiet testus, nemīkstiniet apgalvojumus un nemainiet nesaistītu lietojumprogrammas darbību.
Sagaidāmā izvade: koda ielāps, pamatcēloņa skaidrojums un testu izpildes rezultāti.
Pieņemšanas kritēriji: iepriekš neizdevies tests tiek sekmīgi izpildīts 10 secīgās palaišanas reizēs, un attiecīgais regresijas testu komplekts tiek izpildīts sekmīgi.
Kļūmes nosacījumi: pamatcēloni nav iespējams noteikt, labojums rada regresijas vai nepieciešamā testa vide nav pieejama.

Taču ir vēl viena svarīga daļa: kad aģentam jāapstājas?

Aģentam nevajadzētu turpināt iterācijas bezgalīgi tikai tāpēc, ka tas nav sasniedzis apmierinošu rezultātu. Definējiet, kas ir veiksmīga pabeigšana, kad jāatgriež daļēji pabeigts uzdevums un kad jāapstājas, jo prasību nav iespējams izpildīt. Iestatiet maksimālo deleģēšanas dziļumu un iterāciju ierobežojumus vai izpildes budžetus, lai neatrisināti uzdevumi nepārvērstos bezgalīgās cilpās.

Atgriezīsimies pie mūsu CI piemēra. Varētu definēt šādus apturēšanas nosacījumus:

Veiksme: labojums sekmīgi iztur 10 secīgas testu palaišanas un attiecīgo regresijas testu komplektu.
Iterāciju ierobežojums: aģents drīkst izmēģināt ne vairāk kā divus iespējamos labojumus.
Izpildes budžets: aģentam jāapstājas pēc 60 minūtēm, pat ja problēma joprojām nav atrisināta.
Deleģēšanas ierobežojums: aģents drīkst deleģēt darbu vienam specializētam aģentam bez tālākas deleģēšanas apakšaģentiem.
Daļēja pabeigšana: ja abi mēģinājumi neizdodas vai beidzas laika limits, aģents atgriež savus konstatējumus, izmēģinātās izmaiņas un testu rezultātus.
Bloķēta izpilde: ja testa vide nav pieejama, aģents apstājas un ziņo par šķērsli, nevis apgalvo, ka uzdevums izpildīts veiksmīgi.

Dažreiz izstrādātāji uztic orķestrētājam pārāk daudz pienākumu, un tā vietā, lai koordinētu specializētos aģentus, tas pats sāk rakstīt kodu, atkļūdot vai veikt detalizētus pārskatus. Tas rada vājo vietu: orķestrētājs iztērē savu konteksta budžetu ieviešanas detaļām, aizkavē deleģēšanu un izpludina atbildību par rezultātiem.

Tāpēc ļaujiet orķestrētājiem darīt savu darbu un nodrošiniet nodošanu, atsaucoties uz konkrētiem artefaktiem: sākotnējo uzdevumu, attiecīgajiem ievaddatiem, izvades artefaktiem, izpildes statusu un jebkādām neatrisinātām problēmām.

Apskatiet šo piemēru: status: completed attiecas uz aģentam uzdoto darbu, nevis uz visu darbplūsmu. Tā kā testi joprojām ir statusā pending, orķestrētājam nevajadzētu apstiprināt gala rezultātu.

json

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

Aģenta sarunu vēsture nav uzticams darbplūsmas progresa ieraksts. Kad tā konteksta logs piepildās, automātiskā saspiešana var izmest svarīgas detaļas. Un, ja izpildes process avarē, nākamajam aģentam jāzina, kuri soļi patiešām tika pabeigti.

Piemēram, ja kodēšanas aģents ģenerē ielāpu un pēc tam avarē, nākamajam izpildes procesam jāizgūst saglabātais artefakts un jāturpina no reģistrētā darbplūsmas stāvokļa. Taču, ja aģents arī palaida ārēju CI izpildi, orķestrētājam šī izpilde jāsaskaņo atsevišķi, pirms darbība tiek atkārtota

Tāpēc glabājiet izpildes stāvokli atsevišķi no aģenta darba konteksta. Saglabājiet uzdevumu statusus, izpildes mēģinājumus, pabeigtos soļus un artefaktu atsauces noturīgā krātuvē. Tikmēr ielādējiet tikai tās instrukcijas, ievaddatus un rezultātus, kas attiecas uz aģenta pašreizējo uzdevumu, nevis piebāziet visu izpildes vēsturi tā konteksta logā.

Pieņemsim, ka jūsu CI aģents palaiž testu izpildi, bet API pieprasījumam iestājas noildze. Vai testu izpildi neizdevās sākt, vai arī CI pakalpojums to ievietoja rindā un pazaudēja atbildi?

Noildze ne vienmēr nozīmē, ka darbība neizdevās. Tāpēc pirms lēmuma par turpmāko rīcību ir jānošķir kļūdu veidi:

Īslaicīgas kļūdas (429, 503): atkārtojiet ar ierobežotu eksponenciālu atkāpi un nejaušu nobīdi (jitter), ievērojot Retry-After, ja tas norādīts.
Validācijas vai atļauju kļūdas (400, 403): apstājieties vai novērsiet pamatproblēmu, nevis atkārtojiet to pašu pieprasījumu.
Neskaidri iznākumi (noildze pēc iespējama ieraksta): pirms atkārtota mēģinājuma pārbaudiet, vai darbība izdevās.

Piezīme: pat atkārtojamām kļūdām ir vajadzīgi ierobežojumi. Iestatiet noildzi katram rīka izsaukumam, ierobežojiet atkārtojumu skaitu un kopējo atkārtojumu laiku un nosakiet vispārēju darbplūsmas termiņu, lai ligzdoti aģenti nevarētu atkal un atkal restartēt to pašu darbību. Ja kāda atkarība atkārtoti cieš kļūmi, izmantojiet ķēdes pārtraucēju (circuit breaker), lai uz laiku apturētu pieprasījumus.

Darbībām ar ārējiem blakusefektiem piešķiriet katrai loģiskajai darbībai stabilu idempotences atslēgu un izmantojiet to visos atkārtojumos. Ja API atbalsta servera puses dublikātu novēršanu, tas var atpazīt atkārtotus pieprasījumus, neveicot darbību divreiz. Ja neatbalsta, vaicājiet ārējai sistēmai, izmantojot korelācijas ID vai citu autoritatīvu atsauci.

Ja nevarat noskaidrot, kas notika, apstājieties un eskalējiet problēmu.

Mūsu CI aģenta atkārtojumu loģikas piemērs pseidokodā:

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)

Piezīme par kodu: Piemērā pieņemts, ka CI API atbalsta izpilžu meklēšanu pēc pieprasījuma ID. Parametrs request_id novērš dublikātus tikai tad, ja nodrošinātājs skaidri garantē idempotenci. bounded_retry() ir ilustratīvs pseidokods. Produkcijas vidē atkārtojumi jāierobežo gan ar katras darbības atkārtojumu budžetu (maksimālo mēģinājumu skaitu vai pagājušo laiku), gan ar vispārējo darbplūsmas termiņu.

Garākām darbplūsmām, kas aptver vairākus pakalpojumus, apsveriet Saga modeli, lai koordinētu kompensējošās darbības, ja vēlākie soļi neizdodas. Tikai atcerieties, ka kompensācija ne vienmēr nozīmē pilnīgu atritināšanu. Datubāzes atjauninājumu var atsaukt, bet e-pasta nosūtīšanu atsaukt nevar.

Šeit jāsabalansē divas lietas: cik lielas modeļa spējas nepieciešamas katram uzdevumam un cik uzdevumu varat izpildīt vienlaikus. Kļūdoties kādā no tām, riskējat, ka aģenti sacentīsies par koplietotām API kvotām vai paļausies tikai uz dārgiem spriestspējas modeļiem.

Attiecībā uz modeļa izvēli pielāgojiet modeļa spējas un spriestspējas piepūli uzdevuma sarežģītībai — tas ir vienkārši, bet diezgan bieži netiek ievērots. Ņemiet vērā, ka varat vai nu paši konfigurēt maršrutēšanas noteikumus un novērtēt modeļus, vai izmantot orķestrēšanas platformu, kas modeli izvēlas jūsu vietā.

Piemēram, Perplexity Computer piepūles režīms (Effort Mode) ļauj izvēlēties, cik daudz piepūles uzdevums ir pelnījis, manuāli neizvēloties modeli. Izvēlieties Light, Standard, High vai Ultra, un Perplexity automātiski atlasa orķestrējošo modeli un tā spriestspējas līmeni. Pēc tam šis orķestrētājs deleģē apakšuzdevumus atbalsta aģentiem, kuri var izmantot dažādu nodrošinātāju modeļus.

Perplexity novērtē modeļu konfigurācijas pēc kvalitātes un izmaksām, dodot priekšroku lētākām iespējām, kas nodrošina līdzvērtīgus rezultātus. Varat arī izmantot pielāgotās vadīklas (Custom), ja vēlaties paši izvēlēties modeli un spriestspējas līmeni.

Attiecībā uz paralēlismu ierobežojumu jānosaka jūsu infrastruktūrai un ārējām atkarībām. Pārbaudiet koplietoto API pieprasījumu un tokenu ātruma ierobežojumus, pēc tam veiciet darbplūsmas slodzes testēšanu ar pieaugošu vienlaicīgumu. Vērojiet, vai caurlaidspēja uzlabojas vai arī pieprasījumi sāk nonākt rindā, palēnināties vai atgriezt 429 kļūdas.

Lai resursu patēriņš būtu prognozējams, ieviesiet resursu ierobežojumus un plānošanas kontroles:

Kontrolējiet vienlaicīgumu un pieprasījumu ātrumu: ierobežojiet vienlaikus izpildāmo izsaukumu skaitu katram pakalpojumam un ievietojiet lieko darbu rindā. Atcerieties, ka vienlaicīguma ierobežojums vien nenodrošina pieprasījumu minūtē vai tokenu minūtē ierobežojumus.
Sekojiet tokenu un izmaksu budžetiem: uzskaitiet lietojumu visā darbplūsmā, ieskaitot apakšaģentus, un pārtrauciet jauna darba palaišanu, ja atlikušais budžets ir nepietiekams.
Ieviesiet izpildes termiņus: iestatiet uzdevumu un darbplūsmas laika ierobežojumus un, ja tas tiek atbalstīts, nododiet atcelšanu tālāk strādājošajiem aģentiem.
Ievērojiet atkarības: sāciet lejupējos uzdevumus tikai tad, kad ir pieejami to nepieciešamie ievaddati, nevis palaidiet visus aģentus vienlaikus.

Nekad nelūdziet modelim pašam izlemt, vai tā darbības ir drošas. Tā vietā piešķiriet aģentiem minimālās nepieciešamās atļaujas un ieviesiet uz risku balstītus apstiprināšanas noteikumus lietojumprogrammas kodā. Ja aģenti izpilda kodu, izolējiet šo izpildi no resursdatora vides un ierobežojiet piekļuvi failiem, tīkliem un akreditācijas datiem. Tas ierobežo kaitējumu, ja aģents kļūdās vai izpilda nedrošu kodu.

„Esmu skeptisks pret pārlieku sarežģītām vairākaģentu sistēmām, īpaši tad, ja aģenti pārskata un apstiprina cits cita darbu. Var gadīties, ka vairāki aģenti pārliecināti nodod tālāk vienu un to pašu kļūdu, un neviens to patiesībā nepamana,” brīdina Spilkers.

Apstiprināšanas plūsmas diagramma: aģents ierosina darbību ar parametriem, mērķa resursu un stāvokļa versiju; cilvēks to apstiprina vai noraida; apstiprinātās darbības tiek atkārtoti validētas un izpildītas izolētā vidē ar ierobežotu piekļuvi failiem, tīklam un akreditācijas datiem. Noraidītie pieprasījumi un pieprasījumi, kuru termiņš beidzies, tiek slēgti, un mainītiem pieprasījumiem nepieciešams jauns apstiprinājums.

Darbībām, kurām nepieciešams cilvēka apstiprinājums, apturiet izpildi un saglabājiet precīzu ierosināto darbību:

tās parametrus
tās mērķa resursu
tās komita vai stāvokļa versiju
pārskatītāja lēmumu

Turklāt definējiet, kas notiek, ja apstiprinājums tiek noraidīts, beidzas tā termiņš vai nepieciešama eskalācija. Tas ir būtiski atsākamiem ietvariem, jo, atsākot pārtrauktu mezglu, kods tiek izpildīts no šī mezgla sākuma. Visi blakusefekti pirms pārtraukuma var tikt izpildīti vēlreiz.

Tātad, ja apstiprinājums tiek noraidīts vai beidzas tā termiņš, pieprasījums tiek slēgts. Ja pirms izpildes mainās mērķa komits, parametri vai atļaujas, anulējiet apstiprinājumu un pieprasiet jaunu.

Spilkers arī neatbalsta priekšstatu, ka mērķis ir pilnībā autonomi pilna cikla aģenti. „Manuprāt, labāka pieeja ir izveidot dažus mērķtiecīgus aģentus ar skaidriem pienākumiem, definētām atļaujām un cilvēka pārskatīšanu īstajos brīžos. Jūs joprojām iegūstat efektivitāti, neatsakoties no pilnīgas kontroles,” viņš secina.

Vai jums kādreiz aģents ir ziņojis par veiksmi, lai gan patiesībā cieta neveiksmi? Tas kaitina, ja ne tracina, un problēmu nav ātri novērst, jo aģenta pēdējais ziņojums ne vienmēr norādīs, kur radās kļūda.

Lai to izpētītu, izsekojiet, kas notika izpildes laikā, un neatkarīgi pārbaudiet rezultātus. Tāpēc veltīsim nedaudz laika problēmas izolēšanai un novēršanai.

Pirms atkļūdojat aģenta uzvednes, fiksējiet visu izpildes ceļu. Jums ir nepieciešams trasējums, kas vienas darbplūsmas izpildes ietvaros sasaista aģentu izsaukumus, rīku izsaukumus, kļūdas un atkārtotos mēģinājumus.

OpenTelemetry GenAI semantiskās konvencijas nodrošina standartizētu veidu, kā aprakstīt šīs darbības. Piemēram, invoke_workflow apzīmē darbplūsmas izpildi, invoke_agent — aģenta izsaukumu, bet execute_tool — rīka izsaukumu. Katru darbību var reģistrēt kā span ar tās laika datiem, statusu un attiecīgajiem metadatiem.

Šis solis sniedz izpildes ceļa trasējumu, lai jūs varētu noteikt, kur aģents ir aizķēries.

plaintext

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

agent_response: "Success"

Ilustratīvs izpildes trasējums.

Kur vien iespējams, izmantojiet programmatiskas pārbaudes. Validējiet izvades pret JSON shēmām, palaidiet vienībtestus un integrācijas testus, pārbaudiet, vai pastāv nepieciešamie artefakti, un vaicājiet ārējām sistēmām, lai apstiprinātu, ka darbības patiešām izdevās.

Izvadēm, kurām nepieciešams subjektīvs vērtējums un kuras tāpēc nevar novērtēt ar programmatiskām pārbaudēm, ieviesiet neatkarīgu pārskatītāja aģentu. Viena pieeja ir īstenotāja–pārskatītāja–risinātāja cilpa, kurā viens aģents izveido artefaktu, pārskatītājs ar svaigu kontekstu identificē problēmas un risinātājs tās novērš, pirms validācija tiek palaista vēlreiz.

Pārskatītāja konstatējumi joprojām ir jāvalidē, kur tas iespējams, un, ja atkārtotiem novērtējumiem izmantojat uz LLM balstītus vērtētājus, kalibrējiet to spriedumus pret cilvēka pārskatītiem piemēriem.

Līdz šim jūs esat izsekojuši, ko aģenti izpildīja, un pārbaudījuši, vai to izvades rezultāti bija pareizi. Bet kas notiek, ja darba process avarē uzdevuma vidū vai API pārsniedz noildzi jau pēc pieprasījuma pieņemšanas? Pārsteidzoši, bet jūsu darbplūsma normālos apstākļos var darboties nevainojami, taču atkopšanas laikā – neizdoties.

Lai to pārbaudītu, testa vidē apzināti ieviesiet kļūmes:

Simulējiet API noildzes
Izraisiet darba procesu avāriju starp ierakstiem ārējās sistēmās un kontrolpunktiem
Atgrieziet nepareizi formatētas rīku izvades
Ļaujiet apstiprinājumu derīgumam beigties

Pēc katra testa pārbaudiet izpildes trasējumu, lai redzētu, kuri soļi tika izpildīti, kurā vietā darbplūsma atsāka darbu un vai kādas darbības tika atkārtotas vai izlaistas. Pēc tam pārskatiet faktiskos rezultātus.

Pieņemsim, ka jūsu CI aģents nosūta pieprasījumu sākt testa palaišanu, bet API atbilde pārsniedz noildzi. Aģents mēģina vēlreiz, saņem veiksmīgu atbildi un ziņo Success. Viss izskatās kārtībā, līdz pārbaudāt CI pakalpojumu un atklājat, ka vienas testa palaišanas vietā tika izveidotas divas.

Tāpēc jāpārbauda gan darbplūsmas reģistrētais stāvoklis, gan faktiskās izmaiņas ārējās sistēmās. Atkopšanas testam jābūt sekmīgam tikai tad, ja darbplūsma sasniedz gaidīto stāvokli bez neparedzētām blakusietekmēm.

Atklātās kļūmes pievienojiet saviem regresijas testiem, lai turpmākas izmaiņas tās atkal neieviestu.

Galu galā sekmīga izpilde nozīmē, ka darbplūsma ir izturējusi visas obligātās pārbaudes un tās ārējie rezultāti ir pārbaudīti.

Izolēti aģenti var pareizi izpildīt savus atsevišķos uzdevumus, taču kopā sniegt nekonsekventus rezultātus. Iedomājieties, ka pārdošanas aģents iegūst klienta noteikumus plkst. 10.00, cenu noteikšanas aģents plkst. 10.05 aprēķina piedāvājumu, izmantojot atjauninātas cenas, un juridiskais aģents pārbauda līgumu, kas tika mainīts plkst. 10.07. Katrs aģents strādā ar atšķirīgu uzņēmuma darbības momentuzņēmumu, tāpēc to rezultāti var būt savstarpēji pretrunīgi.

Uzņēmuma mērogā problēma kļūst izteiktāka, jo aģenti mijiedarbojas ar vairākām neatkarīgi atjauninātām sistēmām, darbojas ar atšķirīgām atļaujām un ne vienmēr koplieto kontekstu vai izpildes stāvokli.

Nosakiet ierobežojumus vairākos līmeņos: maksimālo rīku izsaukumu atkārtojumu skaitu, maksimālo aģenta iterāciju skaitu, deleģēšanas dziļumu un kopējo darbplūsmas termiņu. Pirms atkārtota mēģinājuma klasificējiet kļūmes. Īslaicīgu 429 atbilžu gadījumā ievērojiet Retry-After, ja tas ir norādīts. Pretējā gadījumā izmantojiet ierobežotu eksponenciālu atkāpšanos ar nejaušu nobīdi (jitter).

Pēc validācijas vai atļauju kļūdām pārtrauciet nemainītu pieprasījumu atkārtošanu. Ja pakārtots pakalpojums atkārtoti neizdodas, ķēdes pārtraucējs (circuit breaker) var neļaut aģentiem radīt papildu slodzi.

Atkopšanas mehānisms ir atkarīgs no jūsu izpildlaika vides. Izmantojot LangGraph, pastāvīgs kontrolpunktu saglabātājs, piemēram, PostgresSaver, glabā grafa stāvokli, piesaistot to thread_id, un tādējādi izpildi var turpināt no saglabātā stāvokļa. Izmantojot Temporal, cits darba process var rekonstruēt darbplūsmu, atkārtoti izspēlējot tās notikumu vēsturi. Atkārtotās izspēles laikā tiek atkārtoti izmantoti iepriekš reģistrētie aktivitāšu rezultāti.

Ja lietojumprogramma tiek izvietota no jauna, kamēr darbplūsmas vēl darbojas, saglabātais stāvoklis un izpildes vēstures var vairs nebūt saderīgi. Temporal šo problēmu risina ar Worker Versioning un darbplūsmu ielāpošanu. Sistēmās, kuru pamatā ir kontrolpunkti, plānojiet shēmu migrācijas un pirms nesaderīgu izmaiņu ieviešanas pārbaudiet atkopšanu ar esošajiem saglabātajiem stāvokļiem.

Izpildiet vienus un tos pašus reprezentatīvos uzdevumus vairākas reizes un nošķiriet pass@k (vai vismaz viens no k mēģinājumiem ir sekmīgs) no pass^k (vai visi k mēģinājumi ir sekmīgi)

Mēriet rezultātus pa uzdevumu kategorijām un darbplūsmas versijām, nevis paļaujieties uz vienu apkopotu sekmības rādītāju. Sekojiet pirmā mēģinājuma sekmībai, konsekvencei atkārtotās izpildēs, p95 latentumam, izmaksām par katru pabeigto uzdevumu un to uzdevumu īpatsvaram, kuros nepieciešama cilvēka iejaukšanās. Sekmības rādītājiem norādiet izlases lielumu un nenoteiktības intervālus.

Kas ir MI aģentu orķestrēšana?

Kā darbojas MI aģentu orķestrēšana: ieskats izpildes dzinējā

Kad izmantot MI aģentu orķestrēšanu?

MI aģentu orķestrēšanas arhitektūras un to kompromisi

Centralizēta orķestrēšana

Decentralizēta orķestrēšana

Hierarhiska orķestrēšana

Secīga, paralēla un uz nodošanu balstīta izpilde

Biežākās MI aģentu orķestrēšanas kļūmes

7 MI aģentu orķestrēšanas paraugprakses uzticamai darbībai produkcijas vidē

1. Definējiet skaidrus uzdevumu līgumus, pieņemšanas kritērijus un apturēšanas nosacījumus

2. Neapgrūtiniet orķestrētājus un nodrošiniet strukturētu darba nodošanu

3. Saglabājiet darbplūsmas stāvokli un kontrolējiet konteksta pieaugumu

4. Izstrādājiet atkārtojumus, kas ņem vērā kļūmes, un atkopjamu rīku izpildi

5. Maršrutējiet un paralelizējiet darbu ar skaidriem resursu budžetiem

6. Ieviesiet apstiprinājumus un izolējiet aģentu izpildi

7. Neatkarīgi pārbaudiet izvades un testējiet atkopšanās darbību

Izsekojiet darbplūsmu, lai noteiktu, kas nogāja greizi

Neatkarīgi pārskatiet izvadi

Apzināti izraisiet kļūmes, lai pārbaudītu atkopšanos

Bieži uzdotie jautājumi par MI aģentu orķestrēšanu

Kāpēc izolēti MI aģenti nedarbojas uzņēmuma mērogā?

Kā novērst bezgalīgus atkārtotu mēģinājumu ciklus MI aģentos?

Kā atsākt MI aģenta darbplūsmu pēc avārijas?

Kā pārbaudīt MI aģentu orķestrēšanas uzticamību?