5 AI agendi töövoo mustrit, mis toimivad tootmises (koos koodiga)
19. november 2025
15 min lugemine
Enne arhitektuuri valikut: 4 küsimust, mida küsida
Enne kui hakata rääkima orkestreerimisest või uutest agentide raamistikest, tasub vastata neljale strateegilisele küsimusele. Need määravad ära, kui keeruliseks Teie AI-töövoog üldse peaks minema.
1. Kui palju vabadust agentidel tegelikult vaja on?
2. Kui oluline on konkreetse töövoo täpsus ja järjepidevus?
3. Millised on mahu- ja kulueeldused?
4. Kes vastutab töövoo hoolduse ja jälgitavuse eest?
Põhitöövood, millest alustada
Enamik agentseid lahendusi on kombinatsioon mõnest allolevast mustrist. Oluline ei ole leida „õiget“ mustrit esimesel katsel, vaid omada framework’i, mille piires saab mustreid turvaliselt katsetada ja A/B testida.
1. Järjestikune töövoog - vaikimisi struktuur
2. Paralleelne töötlemine - kiiruse võit
3. Hindamistsüklid - kvaliteedi ühtlustamiseks
4. Orkestreerija-tööline muster - mitu rolli, üks tervik
5. Ruutimine - erinevad rajad erinevatele päringutele
Mida juht peaks AI-agentse süsteemi juures mõõtma
Hea arhitektuur annab alles siis väärtust, kui seda on võimalik jälgida ja parandada. Ilma mõõdikuteta on keeruline otsustada, milline töövoo variant tegelikult parem on.
Põhinäitajad, mis tasub varakult kokku leppida
Katsetamine ja „testkaart“ päris kasutusjuhtumitest
Tüüpilised riskid ja kuidas neid raamides hoida
Agentse AI kasutuselevõtt ei tähenda, et riske pole; pigem on küsimus, kuidas need nähtavaks ja juhitavaks teha. Allpool mõned kohad, millega juhina tasub varakult arvestada.
Hallutsinatsioonid kui normaalne nähtus, mitte erand
Auditijälg ja selgitatavus
Praktiline juurutusplaan: samm-sammult, mitte „suur pauk“
Agentne AI-kiht ei pea valmis saama ühe korraga. Turvalisem ja paindlikum on läheneda sellele nagu pidevale katsetusprogrammile.
1. Alusta ühe selge kasutusjuhtumi ja lihtsa töövooga
Vali üks äriline valdkond, kus on selge kasu (nt sisetugi, dokumendikokkuvõtted, korduvate kliendiküsimuste lahendamine). Ehita sinna:
üks range rolliga agent,
3-5 selget sammu,
minimaalne, aga kasutatav logimine ja mõõdikud.
Esimene eesmärk ei ole „täiuslik AI-assistent“, vaid töövoog, mille käitumist on võimalik jälgida ja järgmises ringis parandada.
2. Lisa ruuterid ja hindamistsüklid sinna, kus andmed seda soovitavad
3. Orkestreerimine ja multi-agentne koostöö alles siis, kui lihtsamad mustrid jäävad kitsaks
Kokkuvõte
Vajad agentset AI-töövoogu?
Oleme aidanud klientidel ehitada mitmeastmelisi agentseid lahendusi dokumentide töötlemiseks, klienditoeks ja sisuloomeks. Kui otsid partnerit, kes aitaks valida sobivad töövoo mustrid, seada mõõdikud ja luua raamistikud katsetamiseks, räägime, kuidas sinu kasutusjuhtumit kõige mõistlikumalt lahendada.
Enamik AI-projekte algab ühest heast prompt’ist ja ühest mudelist. Esimene demo töötab - aga nii pea, kui lahendus puutub kokku päris kasutajate, päris andmete ja SLA-dega, selgub, et ühest „nutikast agendist“ ei piisa. Töövood, peavad arvestama kulude, kvaliteedi, latentsuse ja kontrolliga.
Heaks lähenemiseks ei ole üks õige arhitektuur, vaid võime katsetada erinevaid töövoo mustreid, võrrelda neid andmete põhjal ja valida olukorrale sobivaim. See artikkel on mõeldud tehnoloogiajuhtidele ja otsustajatele, kes tahavad aru saada, milliseid mustreid agentsete süsteemide ehitamisel kasutada - ja kuidas neid järk-järgult katsetada, mitte kõike korraga üle ehitada.
Ühes otsas on väga vabad agendid, kes otsustavad ise, milliseid tööriistu, millal ja kuidas kasutada. Teises otsas on lihtne, ette kirjutatud töövoog, kus mudel täidab väga konkreetseid samme.
Praktikas:
Rohkem vabadust sobib avatud probleemidele (nt klienditoe vestlused, uurivad analüüsid), kus iga sessioon on erinev ja tulemusi nagunii vaadatakse üle.
Rohkem kontrolli on mõistlik valdkondades, kus ootused järjepidevusele ja jälgitavusele on kõrged (finants, tervishoid, avalik sektor, standardiseeritud protsessid).
Heaks baasvalikuks on sageli kontrollitud töövoog, kuhu lisatakse agentidele rohkem otsustusruumi alles siis, kui käitumist on mõõdetud ja mõistetud.
Kõik vead ei ole võrdsed. Küsimus ei ole ainult „kas mudel eksib“, vaid kui oluline on konkreetse voogu läbiv info.
Madala olulisusega vood - ideede genereerimine, sisuloome mustandid, sisene dokumentatsioon. Vigu talutakse, inimene niikuinii kohendab.
Keskmise olulisusega vood - kliendisuhtlus, pakkumiste mustandid, raportite kokkuvõtted. Siin on mõistlik lisada vähemalt üks kvaliteedikontrolli samm.
Kõrge olulisusega vood - lepingutingimused, krediidiotsused, tundlikud avaldused. Siin on vaja mitmeastmelisi töövooge, hindamist ja sageli ka inimese lõplikku heakskiitu.
Olulisuse tase määrab, kui palju samme ja tagasiside-tsükleid tasub töövoogu lisada.
Iga lisasamm töövoos tähendab täiendavat LLM-kõnet. Kui töötlete sadakond päringut kuus, on arhitektuuri mõju kulule väike; kui maht on kümnetes või sadades tuhandetes, on mustri valik juba oluline finantsiline otsus.
Praktiline raamistik:
defineeri päringu klassid (lihtne / keskmine / keerukas, sisemine / väline, madala / kõrge väärtusega),
sea iga klassi jaoks eeldatav maksimaalne kulu ja vastuse aeg,
vali töövoo mustrid nii, et need piirväärtused oleks realistlikult saavutatavad.
Hiljem saab neid klasse ja piire andmete põhjal korrigeerida, aga oluline on, et otsus ei sünniks ainult „tunde järgi“.
Mitmeagendiline süsteem ei ole üks mudel, vaid terve kiht infrastruktuuri: ruuter, orkestreerija, töölised, tööriistad, hindajad. Kui sellel puudub selge omanik, muutub lahendus aja jooksul raskesti hallatavaks.
millised on operatiivsed tööriistad - logid, jälgimine, „replay“ keeruliste juhtumite jaoks, feature flag’id.
Nii on selge, kes juhib järgmisi iteratsioone, kui katsetate uusi mustreid või mudeleid.
Lihtsaim muster: selgelt defineeritud sammud kindlas järjekorras (nt sisendi analüüs → plaani loomine → mustandi loomine → vormindamine → kontroll).
Sobib hästi, kui:
ülesanne jaguneb loomulikult etappideks,
on oluline, et töövoog oleks arusaadav ja auditeeritav,
soovid võimalust iga sammu eraldi mõõta ja optimeerida.
Järjestikune töövoog on hea baas, mille peal testida erinevaid prompt’e, mudeleid ja tööriistakutsed - ilma, et arhitektuur oleks liigse keerukusega lukku keeratud.
Paralleelses mustris jookseb sama sisendi kohta mitu analüüsi korraga ja tulemused koondatakse hiljem. Näiteks: turvaanalüüs, stiilikontroll ja kokkuvõte.
See annab väärtust siis, kui:
kasutaja ootab vastust reaalajas,
eri analüüsid ei sõltu teineteise tulemustest,
osalist tulemust on parem näha kiiremini kui oodata üht suurt lõppvastust.
Katsetamiseks on hea alustada väikese hulga paralleelsete sammudega ja jälgida, kui palju see tegelikku vastuse aega ja kulu muudab.
Hindamistsüklis (evaluation loop) genereerib üks agent mustandi, teine hindab seda etteantud kriteeriumite järgi ning kas kinnitab või palub parandusi. Seda saab rakendada sama mudeliga teises rollis või teise mudeliga.
kasuta hindavat sammu esmalt valitud kõrge olulisusega voogudes,
võrdle mõõdikuid „ilma hindamiseta“ vs „hindamistsükliga“.
Nii võib üsna kiiresti selguda, millistes protsessides parandab hindamistsükkel kvaliteeti oluliselt ning kus on see pigem kulu, mis suurt vahet ei tee.
Orkestreerija otsustab, milliseid alamülesandeid vaja on, millises järjekorras ja milliste „töölistega“ need täita. Töölistel on selged rollid: näiteks „juriidiline analüüs“, „finantskokkuvõte“, „tehniline risk“.
Seda tasub kasutada siis, kui:
sama ülesanne vajab eri tüüpi kompetentse,
töövoog on niigi mitmeastmeline ja üks agent läheks liiga „üldiseks“,
asju on vaja selgelt struktureerida (nt keerukad klienditeekonnad, mitut domeeni puudutavad otsused).
Katsetamise mõttes tasub alustada väikese arvu töötajatega (2-3 rolli) ja vaadata, kas orkestreerimine lisab aru saadavat väärtust võrreldes lihtsama järjestikuse vooga.
Ruutija (router) aitab otsustada, milline töövoog või mudel sobib antud sisendile kõige paremini. Ruutimine võib toimuda nii reeglite, lihtsa klassifikaatori kui LLM-i abil.
Selle eesmärk on:
hoida kulusid kontrolli all (lihtsad päringud odavamasse voogu, keerukad põhjalikumasse),
pakkuda erinevatele kasutajagruppidele sobivat taset (nt tasuta vs tasuline teenus),
vähendada agentide „ülemõtlemist“ lihtsate juhtumite korral.
Ruutimist on mõistlik ehitada iteratiivselt: alustuseks paar selget haru (FAQ / vaja inimest / vaja eraldi töövoogu) ja hiljem, kui andmeid koguneb, saab reegleid ja mudelit täpsemaks keerata.
Soovitame defineerida vähemalt järgmised näitajad:
õnnestumise määr - mitu päringut lahendatakse ilma inimese sekkumiseta vastuvõetava kvaliteediga,
käsitsitöö osakaal - kui sagedasti peab inimene sekkuma ja kui palju aega see võtab,
keskmine kulu päringu klassi kohta - sh kõik töövoo sammud,
latentsus - time-to-first-token ja täieliku vastuse aeg,
üleandmise määr - kui tihti antakse päring automaatselt inimeselt üle või teise töövoogu.
Neid saab kasutada nii erinevate töövoovariantide A/B testimiseks kui ka otsustamiseks, kuhu järgmine optimeerimisring suunata.
Agentseid süsteeme on lihtne üle hinnata, kui vaadata ainult demodes kasutatud näiteid. Parem on luua:
väike, aga esinduslik testikomplekt päris või realistlikest päringutest,
mehhanism, mis võimaldab sama komplekti peal erinevaid töövoo variante jooksutada,
harjumus tulemusi regulaarselt üle vaadata ja mustreid võrrelda.
Nii muutub töövoo disain järjepidevaks katsetamiseks, mitte juhuslikuks prompt’i muutmiseks.
Suured keelemudelid teevad paratamatult vigu. Eesmärk ei ole neid nulli viia, vaid hoida need töövoogudes, kus vead on talutavad ning kus on olemas mõistlikud kaitsekihid.
Praktilised sammud:
kasuta ärikriitilistes voogudes eesmalt reeglipõhiseid kontrolli- ja kinnitussamme (nt lubatud väärtuste loendid, lihtsad arvutused, formaatkontroll),
lisa valitud kohtades mudelipõhine faktikontroll või hindaja roll,
hoia eraldi „rada“, kus nõutakse inimese heakskiitu enne lõpliku tegevuse tegemist (nt lepingu kinnitamine, püsikorralduse muudatus).
Reguleeritud valdkondades ja suuremates organisatsioonides on oluline, et hiljem oleks võimalik aru saada, kuidas konkreetse vastuseni jõuti.
See ei tähenda, et iga vastuse juurde peaks tulema pikk selgitus. Piisab, kui süsteem:
logib, millised töövoo sammud käivitusid,
näitab, milliseid tööriistu ja andmeallikaid kasutati,
seob iga sammu konkreetse mudeliversiooniga.
Nii saab probleemseid olukordi hiljem rekonstrueerida ja kasutada seda sisendina järgmiste katsetuste ja parenduste jaoks.
Kui esimesed kuud on reaalse kasutusega möödas, vaata logisid ja mõõdikuid:
millises voos kulub suhteliselt kõige rohkem ressursse,
kus on kõige rohkem käsitsi järelparandust,
milliste töövoogude puhul on ootus kvaliteedile kõige kõrgem.
Alusta muudatusi sealt:
lisa hindamistsükkel valitud voogu ja mõõda, kuidas see mõjutab tulemusi,
lisa lihtne ruuter, mis saadab lihtsad juhtumid odavamasse voogu ja keerukamad põhjalikumasse.
Nii on iga järgmine samm põhjendatud tegeliku kasutuse, mitte teoreetilise ideaali järgi.
Mitme agendi ja orkestreerijaga süsteemid on võimsad, kuid nende ehitamine ja hooldus nõuab rohkem pingutust. Neid tasub rakendada:
valitud kõrge mõjuga voogudes,
olukordades, kus on selge, miks lihtsamad mustrid enam ei piisa,
siis, kui tiimil on olemas baas kogemus lihtsamate agentsete voogude käitumisega.
Oluline on, et ka keerukam arhitektuur jääks katsetatavaks: samu kasutusjuhtumeid peaks saama jooksutada nii lihtsama kui keerukama töövoo peal ja tulemusi võrrelda.
Agentne AI ei ole üks toode ega raamistik, vaid viis, kuidas siduda mudelid, tööriistad ja protsessid ühtseks töövoogude kihiks. Edu ei tule ühest „geniaalsest prompt’ist“, vaid võimest:
kasutada sobivaid töövoo mustreid (järjestikused vood, paralleelsus, hindamistsüklid, orkestreerimine, ruutimine),
mõõta kulusid, kvaliteeti ja latentsust töövoo tasandil,
ja mis kõige olulisem - katsetada süsteemselt erinevaid variante ning lasta andmetel otsuseid suunata.
