Prieš kokius penkerius metus, kai kalbėdavai apie „agentus“ programinėje įrangoje, kolegos dažniausiai pagalvodavo apie kokį nors chatbotą arba automatizuotą skriptą, kuris tyliai suka ratus serveryje. Šiandien situacija visiškai kitokia. Daugiaagentės sistemos (angl. multi-agent systems, MAS) tapo viena karščiausių temų dirbtinio intelekto ir programinės inžinerijos sandūroje, ypač kai į žaidimą įsijungė didieji kalbos modeliai. Bet pati idėja – kad sudėtingą problemą galima išspręsti ne vienu monolitiniu algoritmu, o būriu savarankiškų, tarpusavyje bendraujančių komponentų – siekia dar praėjusio amžiaus dešimtmetį, kai akademinėje bendruomenėje pradėta rimtai galvoti apie paskirstytą dirbtinį intelektą.
Kas iš tikrųjų yra „agentas“ šitame kontekste
Terminas „agentas“ programinėje sistemoje reiškia kur kas daugiau nei tiesiog funkciją ar objektą. Agentas – tai autonominis vienetas, kuris gali suvokti savo aplinką, priimti sprendimus pagal turimą informaciją ir tikslus, bei veikti taip, kad tuos tikslus pasiektų, dažnai be tiesioginio žmogaus įsikišimo kiekviename žingsnyje. Skirtumas nuo įprastos funkcijos toks: funkcija atlieka tai, kas jai liepta, o agentas pats sprendžia, ką daryti, remdamasis turima informacija ir aplinkybėmis.
Klasikinėje agentų teorijoje išskiriamos kelios savybės, kurios apibrėžia, ar sistemą apskritai verta vadinti agentine: autonomija, socialumas (gebėjimas bendrauti su kitais agentais ar žmonėmis), reaktyvumas (reagavimas į aplinkos pokyčius) ir proaktyvumas (gebėjimas imtis iniciatyvos, o ne tik reaguoti). Kai turime ne vieną tokį vienetą, o keliolika ar keliasdešimt jų, veikiančių bendroje aplinkoje, susiduriame su daugiaagente sistema.
Svarbu suprasti, kad daugiaagentė sistema nebūtinai reiškia „daug dirbtinio intelekto modelių“. Agentai gali būti paprasti taisyklėmis paremti moduliai, robotai fabrike, prekybos botai biržoje arba sudėtingi LLM pagrindu veikiantys asistentai. Svarbiausia – jų sąveika ir gebėjimas kartu spręsti tai, ko vienas agentas išspręsti negalėtų arba spręstų neefektyviai.
Kodėl vienas didelis agentas nėra geriau nei dešimt mažų
Natūralus klausimas: kodėl tiesiog nesukūrus vieno itin galingo agento, kuris viską žinotų ir viską darytų? Praktika rodo, kad tai kelias į aklavietę dėl kelių priežasčių. Pirma, monolitinė sistema tampa sunkiai prižiūrima – kai vienas komponentas turi žinoti apie viską, bet koks pakeitimas gali sugriauti nesusijusią funkciją. Antra, monolitas blogai skaluojasi, ypač kai reikia lygiagrečiai apdoroti daug užduočių skirtingose srityse.
Daugiaagentis požiūris leidžia taikyti tą patį principą, kurį programinėje inžinerijoje žinome kaip „separation of concerns“ – kiekvienas agentas atsakingas už siaurą, gerai apibrėžtą sritį. Turite agentą, kuris ieško informacijos, kitą, kuris ją analizuoja, trečią, kuris priima galutinį sprendimą, ir ketvirtą, kuris viską patikrina prieš pateikiant rezultatą. Toks išskaidymas ne tik palengvina kūrimą, bet ir leidžia atskirus agentus tobulinti, keisti ar net pakeisti kitu modeliu, nesugriaunant visos sistemos.
Yra ir kita nauda – atsparumas gedimams. Jeigu vienas agentas „krenta“ arba grąžina blogą atsakymą, gerai suprojektuota sistema gali tai aptikti ir perduoti užduotį kitam agentui arba paleisti pakartotinį bandymą, neprarasdama viso proceso rezultatų.
Architektūros: kaip agentai susikalba tarpusavyje
Vienas svarbiausių klausimų projektuojant MAS – kokia bus komunikacijos topologija. Praktikoje dažniausiai matomi keli modeliai:
- Centralizuota architektūra su orkestratoriumi. Yra vienas „vadovaujantis“ agentas (dažnai vadinamas orchestrator arba supervisor), kuris paskirsto užduotis kitiems agentams ir surenka rezultatus. Tai paprasčiausia suprasti ir derinti architektūra, tačiau orkestratorius tampa siaura vieta – jei jis nesuveikia, žlunga visa sistema.
- Decentralizuota (peer-to-peer) architektūra. Agentai bendrauja tiesiogiai vieni su kitais, be centrinio koordinatoriaus. Tai atsparesnė sistema, tačiau ją kur kas sunkiau derinti ir prognozuoti jos elgesį, nes atsiranda emerginis elgesys – rezultatas, kurio niekas tiesiogiai neužprogramavo, tiesiog atsiranda iš sąveikų.
- Hierarchinė architektūra. Kelių lygių sistema, kur vieni agentai koordinuoja mažesnes agentų grupes, o virš jų yra dar aukštesnio lygio koordinatorius. Tai dažnai naudojama sudėtingose įmonių sistemose, kur reikia ir lankstumo, ir tam tikros kontrolės.
- „Rinkos“ modelis (blackboard architecture). Agentai nebendrauja tiesiogiai, o rašo ir skaito informaciją iš bendros erdvės, panašiai kaip skelbimų lenta. Kiekvienas agentas stebi šią erdvę ir reaguoja, kai atsiranda jam aktuali informacija.
Realiuose projektuose retai matai gryną vieną modelį – dažniausiai tai hibridas, kur, tarkim, kelios agentų grupės veikia decentralizuotai vidinėje logikoje, o tarp grupių yra centrinis koordinatorius, kuris rūpinasi bendru užduočių paskirstymu.
LLM agentai – naujas etapas, ne tik mada
Didieji kalbos modeliai iš esmės pakeitė tai, ką galima laikyti „agentu“. Anksčiau agento sprendimų logika buvo griežtai užprogramuota – taisyklių rinkiniai, sprendimų medžiai, o vėliau ir mašininio mokymosi modeliai konkrečioms užduotims. Su LLM agentu atsirado galimybė turėti universalų „protą“, kuris supranta natūralią kalbą, geba planuoti žingsnius, naudoti įrankius (API iškvietimus, duomenų bazes, paieškos sistemas) ir prisitaikyti prie situacijų, kurioms niekas iš anksto nerašė specialios logikos.
Čia atsirado ir konkretūs modeliai, kaip agentai turėtų mąstyti: ReAct metodas (reasoning + acting), kur agentas pakaitomis samprotauja ir veikia, tikrindamas rezultatus po kiekvieno žingsnio; planavimo-vykdymo (plan-and-execute) modelis, kur pirma sudaromas visas planas, o tik po to jis vykdomas žingsnis po žingsnio; taip pat reflektavimo mechanizmai, kai agentas pats įvertina savo ankstesnį atsakymą ir bando jį pagerinti prieš pateikdamas galutinį rezultatą.
Kai tokius LLM agentus sudedi į daugiaagentę sistemą, gauni įdomų dalyką – galima sukurti „skaitmeninę komandą“, kur vienas agentas veikia kaip tyrėjas, kitas kaip kritikas, trečias kaip kodo rašytojas, o ketvirtas kaip kokybės kontrolės specialistas. Kiekvienas turi savo „asmenybę“, apibrėžtą per sisteminę instrukciją (system prompt), ir savo siaurą atsakomybės sritį. Toks požiūris praktikoje dažnai duoda geresnius rezultatus nei bandymas priversti vieną modelį atlikti visą darbą per vieną užklausą, nes kiekvienas agentas gali sutelkti „dėmesį“ į mažesnę problemos dalį.
Karkasai ir įrankiai, su kuriais dirbama šiandien
Ekosistema aplink daugiaagentes sistemas per pastaruosius kelis metus išaugo neįtikėtinai greitai. Keletas dalykų, kuriuos verta žinoti, jei planuojate patys pradėti eksperimentuoti:
- LangGraph – biblioteka, leidžianti agentų darbo eigą aprašyti kaip grafą su būsenomis, o ne kaip tiesinę seką. Tai leidžia realizuoti ciklus, sąlyginius perėjimus tarp agentų ir sudėtingesnę logiką nei paprastas „vienas po kito“ modelis.
- CrewAI – karkasas, kuriame agentai apibrėžiami per roles, tikslus ir įrankius, o užduotys paskirstomos komandai (crew) panašiai kaip realiame projekte paskirstytum darbus žmonių komandai.
- AutoGen (Microsoft) – vienas pirmųjų plačiai naudotų karkasų, leidžiantis kurti pokalbio tipo agentų sąveikas, kur agentai „kalbasi“ tarpusavyje, kol pasiekia sprendimą arba užduoties pabaigą.
- OpenAI Swarm / Agents SDK – lengvesni, eksperimentiniai sprendimai, orientuoti į paprastesnį agentų perdavimą (handoff) tarp specializuotų vienetų.
Pasirinkimas priklauso nuo to, ko reikia konkrečiam projektui. Jeigu darbas paprastas ir tiesinis, sudėtingas karkasas gali tik apsunkinti gyvenimą – kartais paprasčiausias sprendimas yra kelios eiliniai funkcijų iškvietimai su aiškia logika, be jokio „agentiškumo“ apvalkalo. Agentai pateisina save tada, kai užduotis iš tiesų reikalauja dinaminio sprendimų priėmimo, kelių įrankių derinimo ir gebėjimo prisitaikyti prie nenuspėjamų situacijų.
Kur tai realiai naudojama, o ne tik demonstracijose
Pramonėje daugiaagentės sistemos jau seniai naudojamos ten, kur reikia koordinuoti daug savarankiškų vienetų. Logistikos įmonės naudoja agentų sistemas maršrutams optimizuoti – kiekvienas transporto vienetas veikia kaip agentas, derantis su kitais dėl geriausio krovinio paskirstymo. Finansų sektoriuje algoritminės prekybos sistemos jau dešimtmečius remiasi keliais nepriklausomais agentais, veikiančiais skirtingomis strategijomis ir konkuruojančiais ar bendradarbiaujančiais tarpusavyje.
Su LLM agentų atsiradimu sfera gerokai išsiplėtė. Programinės įrangos kūrimo įmonės eksperimentuoja su agentų komandomis, kurios pačios rašo, testuoja ir taiso kodą – vienas agentas suformuluoja architektūrą, kitas rašo kodą, trečias jį peržiūri, ketvirtas paleidžia testus. Klientų aptarnavimo sistemose vienas agentas priima užklausą ir nustato jos tipą, kitas ieško atsakymo žinių bazėje, trečias suformuluoja galutinį atsakymą klientui suprantama kalba. Moksliniuose tyrimuose agentų komandos naudojamos literatūros analizei – vienas agentas ieško šaltinių, kitas juos apibendrina, trečias tikrina, ar teiginiai neprieštarauja vieni kitiems.
Įdomus ir vis populiarėjantis pritaikymas – simuliacijos. Tyrėjai kuria virtualius „miestelius“ su dešimtimis LLM agentų, kurie turi savo atmintį, tikslus ir santykius su kitais agentais, ir stebi, kaip iš tokių paprastų sąveikų atsiranda sudėtingas socialinis elgesys. Tai naudinga ne tik akademiniam smalsumui, bet ir, pavyzdžiui, testuojant, kaip vartotojai galėtų reaguoti į naują produktą, prieš jį realiai išleidžiant.
Kur viskas dažniausiai sugenda
Būtų nesąžininga pasakoti tik apie sėkmės istorijas, nes daugiaagentės sistemos turi ir nemažai skaudžių taškų, kuriuos verta žinoti prieš pradedant kurti savo sistemą.
Pirmas ir dažniausias problemos šaltinis – klaidų kaupimasis. Jeigu turite penkis agentus, sujungtus grandinėje, ir kiekvienas turi 90 % tikslumą, bendras sistemos tikslumas gali nukristi iki maždaug 59 % (0,9 pakelta penktuoju laipsniu), nes klaidos ne atšaukia, o dažniausiai susikaupia. Tai reiškia, kad daugiau agentų nebūtinai reiškia geresnį rezultatą – kartais tai reiškia daugiau vietų, kur kažkas gali nutikti negerai.
Antra problema – kaina ir latencija. Kiekvienas agento „mąstymo“ ciklas su LLM reiškia papildomą API iškvietimą, papildomus žetonus, papildomas sekundes laukimo. Sistema su dešimčia agentų, kurie tarpusavyje diskutuoja kelis raundus, gali kainuoti kelias dešimtis kartų daugiau ir veikti kelias dešimtis kartų lėčiau nei vienas gerai suprojektuotas užklausos apdorojimas.
Trečia – derinimo sudėtingumas. Kai vienas agentas priima kitokį sprendimą, nei tikėjotasi, ir tas sprendimas keliauja per keturis kitus agentus prieš pasiekiant galutinį rezultatą, labai sunku suprasti, kur tiksliai procesas nuėjo ne ta kryptimi. Reikalingas rimtas dėmesys stebėjimui (observability) – kiekvieno agento įvesties, išvesties ir sprendimų žurnalavimui, kitaip derinimas virsta spėliojimu iš aklosios zonos.
Ketvirta, mažiau akivaizdi, bet svarbi problema – begalinės kilpos ir „susitarimo be pažangos“ situacijos. Kai du agentai nesutaria arba vienas kitą tikrina be aiškios sustojimo sąlygos, sistema gali suktis ratu, kol baigsis biudžetas žetonams arba viršys laiko limitą. Todėl bet kokioje realioje sistemoje būtina numatyti aiškias sustojimo ribas ir mechanizmus, leidžiančius žmogui įsikišti.
Praktiniai patarimai tiems, kas ruošiasi statyti savo agentų komandą
Jeigu jau nusprendėte, kad jūsų projektui daugiaagentė sistema tikrai reikalinga, o ne tiesiog patogi, štai keletas dalykų, kuriuos verta apgalvoti dar prieš rašant pirmą eilutę kodo.
Pradėkite nuo mažiausios veikiančios versijos – dviejų agentų su aiškia atsakomybe, o ne dešimties su neaiškiomis ribomis. Kiekvienam agentui suformuluokite tikslą taip konkrečiai, kad jis nesikirstų su kito agento tikslu. Neaiškios ribos tarp agentų – dažniausia priežastis, kodėl sistema pradeda elgtis nenuspėjamai.
Investuokite į stebėjimo įrankius nuo pat pradžių. Net paprastas struktūrizuotas žurnalavimas, rodantis, ką kiekvienas agentas gavo, ką grąžino ir kodėl priėmė būtent tokį sprendimą, sutaupys valandas derinimo vėliau. Yra ir specializuotų įrankių šiam tikslui, tačiau net paprasta savarankiškai sukurta žurnalų sistema geriau nei nieko.
Numatykite žmogaus patvirtinimo taškus kritiniuose sprendimuose. Ypač jei sistema atlieka veiksmus, kurių negalima atšaukti – siunčia el. laiškus, atlieka mokėjimus, keičia produkcinius duomenis – verta įterpti patvirtinimo langelį, kur žmogus peržiūri agento planuojamą veiksmą prieš jį vykdant.
Nustatykite aiškias sustojimo ribas – maksimalų žingsnių skaičių, maksimalų žetonų biudžetą, laiko limitą. Be to sistema anksčiau ar vėliau atsidurs begalinėje kilpoje, ir sąskaita už API naudojimą bus nemaloni staigmena.
Testuokite ne tik atskirus agentus, bet ir jų sąveikas. Vienas agentas gali puikiai veikti izoliuotai, tačiau sujungtas su kitais pradėti elgtis kitaip dėl konteksto, kurį gauna iš kitų agentų. Todėl integraciniai testai čia svarbesni nei įprastose sistemose.
Vietoj taško – ką verta pasiimti sau ateičiai
Daugiaagentės sistemos nėra stebuklinga lazdelė, kuri automatiškai išsprendžia visas sudėtingas užduotis vien todėl, kad sujungiate kelis dirbtinio intelekto modelius į vieną voratinklį. Tai architektūrinis sprendimas, turintis savo kainą – didesnį sudėtingumą, didesnes išlaidas, sunkesnį derinimą – ir savo naudą, kai užduotis iš tiesų reikalauja specializacijos, lygiagretumo ar dinaminio prisitaikymo prie situacijos. Prieš pradedant kurti agentų komandą, verta sau atsakyti į paprastą klausimą: ar ši užduotis tikrai reikalauja kelių savarankiškai mąstančių vienetų, ar tiesiog reikia gerai suprojektuoto, aiškaus proceso su vienu protingu sprendimu viduryje?
Jei atsakymas – taip, tikrai reikia kelių agentų – pradėkite nuo mažo, aiškiai apibrėžto masto, investuokite į matomumą ir stebėjimą nuo pirmos dienos, ir nebijokite atgal grįžti prie paprastesnio sprendimo, jei sudėtingumas pradeda viršyti naudą. Sritis vystosi neįtikėtinai sparčiai – tai, kas šiandien laikoma pažangiu sprendimu, po metų gali atrodyti gremėzdiška, palyginti su naujesniais karkasais ir modeliais. Bet pagrindiniai principai – aiški atsakomybių padalija, ribotos sąveikos, žmogaus kontrolė kritiniuose taškuose – liks aktualūs nepriklausomai nuo to, koks konkretus įrankis bus madingas kitais metais.
