TI-agendi 5 kihti: mida juht peab teadma

„Enamik inimesi arvab siiani, et TI-agent on lihtsalt ChatGPT hea promptiga." Selle lausega algab Sunil Ramlochan’i artikkel „The AI Agent Stack Is Not a Prompt. It’s a Production System" ja edasi nimetab autor seda veendumust „lohutavaks müüdiks". Kasulik tõde on tema sõnul mujal: päris agent sarnaneb pigem väikese tööoperatsioonisüsteemiga. Tal on aju, käed, mälu, reeglid, logid, taastamisplaanid ja keegi, kes vastutab, kui agent teeb midagi valesti.

Artikli tees mahub ühele reale: agent on terve virn. Töökindluse annab talle ümbritsev arhitektuur, mudel ise või õnnestunud prompt on vaid üks koostisosa. Pilt on insenerlik, seega vaatame seda teiselt poolt – mis sellest virnast puudutab juhti, kes koodi ei kirjuta, aga otsustab, kas agenti tööle panna.

Kõigepealt kõrvaldame peamise segaduse, sedasama, millele autor vastu vaidleb. „Agent" töötab põhimõtteliselt teisiti kui vestlusliides: prompt annab ühe küsimuse ja ühe vastuse. Agent saab eesmärgi ja töötab tsüklis: mõistab ülesannet, otsustab, mida edasi teha, valib tööriista, kasutab seda, hindab tulemust, mõtestab toimunut ja jätkab, peatub või kutsub inimese. Artikkel viitab ausalt OpenAI agentide ehitamise juhendile, kus agenti defineeritakse süsteemina mudelitest, tööriistadest, juhistest ja piirangutest. Just see tsükkel eristab agenti tavalisest automatiseerimisest: agent ei vasta ühe repliigiga, vaid viib asja lõpuni.

Autor jagab selle „väikese tööarvuti" viieks kihiks. Vaatame neid juhi silmade läbi.

Kiht 1: mudel – aju, aga mitte kogu keha

Mudel on see osa, mis arutleb, plaanib ja kirjutab. Kogu tähelepanu läheb temale, sest see näeb välja nagu maagia: tugevam mudel – paremad arutlused, vähem ilmseid vigu. Aga autor sõnastab karmilt: tootmiskeskkonnas pole mudel sageli kõige keerulisem osa.

Tugev mudel kukub ikkagi läbi, kui tal on ligipääs valedele tööriistadele, ta ei pääse ligi õigele kontekstile, mäletab aegunud infot, tal pole õiguste piire, tema otsust pole hiljem logidest kontrollitav või talle on üldse antud ülesanne, mille oleks pidanud lahendama tavalise algoritmiga. Artikli võrdlus on tabav: mudel on nagu peakokk restoranis. Ka suurepärasele kokale on vaja puhtaid tooraineid, töökorras kööki, tellimusi, toiduohutuse kontrolli ja juhatajat, kes peatab töö, kui midagi läheb valesti.

Juhile järeldub siit kaks asja. Esimene puudutab raha: sõna „agent" taga on mudelipäringute voog, kus iga päring maksab, ja see ei sarnane sugugi ühe fikseeritud kuutellimisega. Teine puudutab ootusi: ärge lootke, et kallim mudel kompenseerib nõrka arhitektuuri. „Võtke parim mudel, mida suudate põhjendada," kirjutab autor, aga ärge arvake, et see katab protsessi augud.

Kiht 2: tööriistad – agendi käed ja tema peamine risk

Tööriistad on see, millega agent välismaailmas tegutseb: otsing, API-d, andmebaasid, meil, kalendrid, koodi käivitamine, failid, maksesüsteemid, sisemised ärirakendused. Just siin, kirjutab autor, lakkab agent olemast tekstigeneraator ja saab täitjaks. Ja just siin kasvab järsult „kahjuraadius". See on täpselt see üleminek, mis kolm aastat tagasi tõi kaasa trendi BYOA – Bring Your Own Agent: niipea kui tööriist saab ligipääsu päris süsteemidele, hakkavad organisatsioonilised küsimused tehnilistest ette jõudma.

Halb vastus on üht tüüpi viga. Rämpsu kirjutamine andmebaasi, kogemata saadetud kiri, topelt teostatud tagasimakse, lekkinud fail – see on hoopis teine kategooria. Seepärast on tööriistade piirid nii olulised. Autor pakub küsimuste nimekirja, mida tasub välja kirjutada igaühel, kes kavatseb anda agendile ligipääsu päris süsteemidele: millistele tööriistadele on agendil ligipääs, millised toimingud on ainult lugemiseks, millised nõuavad kinnitust, kas agent saab kirjutada tootmissüsteemidesse, kas päringud logitakse, kas viga saab tagasi pöörata, kas pahatahtlik sisend võib agenti petta ja panna teda tööriista kuritarvitama.

Kihi põhimõte: paljud agentide läbikukkumised tulenevad just haprast suhtlusest tööriistadega – mudeli arutlusvõime on siin peaaegu kõrvaline. Niipea kui agent saab õiguse tegutseda, vajab ta arendusdistsipliini, ja ainult hoolika promptiga siin enam läbi ei saa. Autori praktiline põhimõte – käsitle tööriistu nagu tootmis-API-sid: minimaalsed õigused, ranged skeemid, kinnitussammud, ettevaatlikkus kirjutamisoperatsioonidega.

Huvitav, et see kõik – tööriistad, õigused, kinnitusskeemid – kõlab nagu jutt arhitektuurist. Aga arhitektuuri all peitub midagi lihtsamat: oskus selgelt sõnastada, mida agent peab tegema, millises kontekstis ja milliste piirangutega. Ilma selle sõnastuseta hakkab ka hästi kirjutatud agent „juurde mõtlema" – ja just siis muutuvad tööriistad ohtlikuks.

Kiht 3: mälu ja selle elutsükkel

„Mälu kõlab lihtsalt. Las agent jätab kasuliku meelde. Lihtne, eks? Mitte päris," kirjutab autor. Mälu on nelja tüüpi: lühiajaline (mis toimub praeguses ülesandes), sessioonimälu (mis oli praeguses vestluses), pikaajaline semantiline mälu (teadmised, mida taaskasutatakse aja jooksul) ja transaktsioonimälu (olek, mis peab olema täpne: tellimused, staatused, õigused, kinnitused). Lühiajaline mälu on sisuliselt mudeli kontekstiaken ja sel on teada piirid: pikad promptid kaotavad infot keskel ning agent pärib selle omaduse.

See on üks raskemaid kihte, sest mälu toimib siin pideva otsustusena: mida meeles pidada, mida unustada, kellele see nähtav on, kuidas mitte lasta ühe kasutaja kontekstil teise sessiooni lekkida, kuidas mitte lasta aegunud andmetel tulevasi otsuseid mürgitada. Riski illustreerib autor ilmekalt: müügiagent, kes mäletab eelmise kvartali soodustuspoliitikat; meditsiiniagent, kes on seganud kahe patsiendi märkmed; finantsagent, kes jättis meelde kinnituse, aga mitte tingimust, millega see oli seotud. Järeldus mahub ühte lausesse: mälu agendis toimib nagu andmebaas tagajärgedega – märkmikuks seda pidada on ohtlik.

Juhi jaoks tõlgendub see ebamugava küsimusena igale alltöövõtjale või teenusepakkujale: mida täpselt teie agent pöördumiste vahel meeles peab ja kes garanteerib, et ta mu kliente omavahel segi ei aja? Autori soovitus – anna mälule elutsükkel: andmete päritolu, aegumistähtaeg, ligipääsuõigused, kustutusreeglid ja kasutaja-, sessiooni-, äri- ning süsteemimälu eraldatus.

Kiht 4: käituskeskkond – kus „mõtlemine" muutub tsükliks

Virna keskmes on agendi käituskeskkond, seesama tsükkel: mõista eesmärki, otsustada, mida edasi teha, valida tööriist, kasutada seda, hinnata tulemust, mõtestada ja jätkata, peatuda või paluda abi. Autor seob selle mustri ReAct-lähenemisega (reasoning and acting) ja rõhutab lihtsat asja: agent viib ülesande lõpuni; ühe repliigiga asi ei lõpe.

Ja just siin kõik lähebki katki. Tsükkel võib jääda ringi käima. Tööriist võib tagastada halbu andmeid. Mudel võib tulemust valesti tõlgendada. Kordus võib kogemata sama toimingu topelt sooritada. Seepärast on käituskeskkond täitmise juhtimine ja valem „LLM lihtsalt mõtleb" ei kirjelda siin pooltki tööst. Kogu artikli olulisim soovitus juhile peitub just siin: ärge projekteerige agenti ühe pika promptina. Projekteerige teda tööprotsessina olekuga, kontrollpunktidega, peatumistingimustega ja inimese kontrollimisega seal, kus see on vajalik.

See pöörab raami ümber. „Kirjeldada protsess oleku ja kontrollpunktidega" – see on täpselt see töö, mida juht teeb, kui ehitab reglamenti või annab meeskonnale ülesande. Agendi tsükkel meenutab kahtlaselt seda, kuidas töötab elav inimene: sai ülesande, plaanis sammud, tegi midagi, vaatas tulemust, korrigeeris. Vahe on selles, et inimesel on terve mõistus ja hirm eksida, agendil aga ainult need piirangud, mille sa talle ette oled pannud.

Kiht 5: jälgitavus, turvalisus ja juhtimine

Viimane kiht mähib kogu virna ja autor nimetab seda piiriks demo ja usaldusväärse süsteemi vahel. See on kiht, mis võimaldab meeskonnal vastata: mida agent tegi, miks just nii, millist tööriista kasutas, mida tööriist tagastas, kui palju käivitus maksis, kas järgis reegleid, kas mõtles välja, kas lekitas privaatseid andmeid, kas jäi tsüklisse, kas inimene kinnitas riskantse sammu. Ilma selle kihita, kirjutab autor, muutub agentide silumine folkloori: meeskond vaidleb toimunu üle, selle asemel et vaadata.

Aga edasi tuleb kõige olulisem eristus ja see on puhtalt juhtimislik. „Jälgitavus ütleb sulle, mis juhtus. Juhtimine otsustab, mida üldse tohib juhtuda." Töölaud näitab, et agent kavatseb teha midagi riskantset. Juhtimine määrab, kes saab ta peatada, mis tingimusel ja kellele see otsus kuulub. Autor viitab otse riskide klassifikatsioonile OWASP Top 10 LLM-idele (kus prompt injection on nimetatud suureks ohuks) ja NIST AI Risk Management Framework’ile kui orientiirile.

Sinu jaoks on sisu järgmine. Kui teenusepakkujad joonistavad tulevikku, kus „agendid juhivad keerulisi protsesse", kaob märkamatult küsimus: kes vastutab, kui agent eksib. See kiht vastab ausalt – kriitilistes punktides vastutab inimene. Autori soovitus – ärge piirduge logidega: määrake eskalatsioonireeglid, kinnitusprotsessid, auditikirjed, poliitikaülevaatused, eelarvelimiidid ja hädapeatamise tingimused.

Kõige nõrgem koht: kihtidevaheline õmblus

Siin teeb artikkel pöörde, mida on kerge vahele jätta, aga ei tasuks. Autor kirjutab, et agendi virna kõige raskem koht pole ehk üldse eraldi kiht – vaid sidekude nende vahel. Käituskeskkond valib tööriista, tööriist muudab äriolekut, mälukiht salvestab tulemuse, mudel tõlgendab seda, jälgitavuskiht logib otsuse, turvalisuskiht otsustab, kas lubada järgmist sammu. Kui kasvõi üks neist üleandmistest on ebatäpselt kirjeldatud, muutub kogu süsteem hapras.

Ja siin nimetab autor mitteromaantilist tõde: töökindluse tagavad „igavad" inseneriasjad – lõplikud automaadid, idempotentsusvõtmed, kordused kaitsega, limiidid, õiguste piirkonnad, testid, hindamiskogumid, auditlogid, tagasipööramisteed ja kontrollpunktid inimese osalusega. Agent võib tunduda tark, aga tootmiskeskkonnas vastutab töökindluse eest distsiplineeritud projekteerimine ja mudeli intellekt iseenesest seda ei garanteeri.

Juhi jaoks on see pilt kihtidevahelist üleandmistest kahtlaselt tuttav. Vastutus hägustub, kontekst kaob üleandmisel, koordineerimiskulud kasvavad – need on iga elava meeskonna probleemid, kus ülesanne käib käest kätte. Seepärast soovitavad autor ja OpenAI juhend teha otsus „üks agent või mitu" samamoodi, nagu otsustate, kas palgata veel inimesi: alustage ühega, pigistage temast maksimum ja keerukustage struktuuri alles siis, kui üks enam ei saa hakkama. Sama loogika on Google Cloud’i raporti taga uuest juhi rollist kui agenditiimi supervisorist – ainult et teenusepakkuja joonistab viis autonoomset agenti juba täna, insenerid aga soovitavad ausalt alustada ühega ja hästi kirjeldatud õmblustega nende vahel.

Mida selle kõigega juhil praktikas peale hakata

Autor lõpetab artikli loosungiga „Agendid pole maagia. Need on juhitud autonoomia" ja pakub kontrollnimekirja: enne agendi käivitamist küsida sügavamalt kui „kas see töötab". Küsida tasub hoopis: „kas seda agenti saab usaldada, kui tal on päris kasutajad, päris andmed, päris tööriistad, päris kulud ja päris tagajärjed". Demo elab õnnestunud promptiga. Tootmiskeskkond nõuab arhitektuuri, teste, õigusi, mäludistsipliini, jälgitavust, kaitset ja selget omanikku.

Tõlgime selle sammudeks juhile, kes koodi ei kirjuta, aga tahab aru saada, kas tal on agendi jaoks ülesanne ja kas ta on selleks valmis.

Kõigepealt leidke kandidaat. Vaadake oma nädal läbi ja kirjutage välja protsessid, mis korduvad, koosnevad mitmest sammust ja sisaldavad hargnemisi „oleneb olukorrast". Mitte ühekordised päringud nagu kirja mustand või koosoleku kokkuvõte – nende jaoks pole agenti vaja, piisab tavalisest promptist. Just protsessid: sissetulevate pöördumiste töötlus, korrapärane aruanne mitmest allikast, CV-de esmane sorteerimine. See on Benedict Evansi kriteerium: TI automatiseerib hästi ülesandeid ja halvasti – otsustusi, seega on agent põhjendatud seal, kus protsessis on koht otsustusele. Konkreetne näide sellisest üleminekust on agentne andmeanalüüs, kus vahe vestluse ja agendi vahel saab ilmseks kolmel reaalsel juhi failil.

Edasi kirjeldage protsess just nimelt tööprotsessina mitme sammuga – täpselt selleks kutsub artikkel üles. Üks pikk prompt siin ei tööta. Jagage ülesanne sammudeks, siduge iga sammuga konkreetne toiming ja vajalik tööriist, kirjeldage ebatavalised juhud ja märkige tingimata, milliste sammude juures peab otsuse tegema inimene. Kui te ei suuda protsessi sõnadega selgelt kirjeldada, ei suuda seda täita ka ükski agent. See ongi valmisoleku kontroll ja seda saab teha kohe praegu, tavalises vestlusliideses.

Siin on prompt, mis muudab teie tööreglamendi mustandiks tulevase agendi tööprotsessist – sama viie kihi loogika järgi, millest artikkel räägib. Näiteks on pandud tüüpiline klienditoe protsess – hommikuste pöördumiste läbitöötamine; asendage see enda omaga:

Hea tulemus märgib tagasimaksed ja vaidlusalused maksed kohustusliku peatumisena inimesele üleandmisega – kui mudel seda ei teinud, on ülesanne liiga ebamääraselt sõnastatud.

Kui mustand on valmis, andke see kontrollimiseks teisele mudelile – las ta leiab augud enne, kui viite ülesande arendajatele. Allpool on näiteks juba veidi „kammitud" mustand samast klienditoe protsessist; pange siia enda oma:

Hea ülevaataja haarab kohe kinni sammust 4: tagasimakse alla 50 eurot vormistab agent ise, ilma kontrollpunktita – rahaline toiming ilma inimese allkirjata ongi selle mustandi peamine auk.

Pange tähele: mõlemad sammud teete tavalises vestlusliideses, enne kui üldse jutuks tuleb päris agendi arendamine. Kõige kallim viga on tellida keerukas agent protsessi jaoks, mida te ise ei suutnud selgelt kirjeldada.

Kokkuvõtteks

„Juhitud autonoomia" – see on täpne nimetus sellele, mida juht tegelikult juurutab: mida rohkem vabadust agent saab, seda rohkem struktuuri on tema ümber vaja, ja selle struktuuri projekteerimine – sealhulgas otsus, kus autonoomia on lubatud ja kus jääb inimese allkiri – on oma olemuselt juhtimistöö. Vastutus ei kao seejuures kuhugi, see nihkub täitmiselt kontrollpunktide projekteerimisele.

Ja baasoskus selle kõige all on üks ja seesama – nii üksiku prompti kui agendi jaoks. See on oskus täpselt sõnastada, mida soovite, milliste andmetega ja milliste piirangutega – sisuliselt needsamad hea prompti 5 elementi, ainult et rakendatuna tervele protsessile. Ilma selle oskuseta ei tööta ei prompt ega agent. Sellest tasub alustada.

Seotud artiklid

Juhid ja TI: kasutavad kõigist rohkem – aga mitte juhtimiseks

Miks TI-piloodid tehases surevad demo ja tootmise vahel

40 GigaChat juhtumit: kontrollime Sberi võrdlusuuringut andmetega

Kuidas juurutada TI-d tootmises: samm-sammuline plaan juhile