Vairums MI komandu, kas cenšas uzlabot aģentu veiktspēju, izmanto vienus un tos pašus līdzekļus: lielākus konteksta logus, vairāk dokumentu un gudrākas uzvednes. Šajā rakstā apgalvots, ka šāda pieeja ir pilnīgi aplama. Trūkstošais elements nav vairāk informācijas. Tā ir kontrole. Labi izstrādāts kontroles slānis atšķir aģentu, kas darbojas demonstrācijā, no tāda, kas darbojas produkcijas vidē.
Lielāka atmiņa, vairāk dokumentu vai garāks konteksta logs nepadara MI aģentu gudrāku — tikai lēnāku un dārgāku. Patiesos ieguvumus sniedz aģenta mācīšana izvēlēties, kas un kad tam vajadzīgs, nevis visu patērēt uzreiz.
Uzticamību nodrošina cikls, nevis modelis. Atšķirību starp aģentu, kas pārsteidz demonstrācijā, un tādu, kas spēj darboties produkcijas vidē, nenosaka MI kvalitāte, bet gan tas, vai sistēma pārbauda savu darbu. Aģenti, kas katrā solī plāno, rīkojas, novēro un pārbauda, paši atklāj savas kļūdas, nevis pārliecinoši sniedz nepareizus rezultātus.
Mūsdienās vairums MI aģentu būtībā ir tērzēšanas roboti ar papildu soļiem — tiem nav mehānisma, kas ļautu noteikt, vai tie virzās pareizi, kad apstāties vai kad izmēģināt citu pieeju. Pienācīgs kontroles slānis — skaidri panākumu kritēriji, strukturēts stāvoklis un validācijas pārbaudes — pārvērš aģentam līdzīgu objektu par kaut ko patiešām uzticamu.
Ko jūs vakar ēdāt pusdienās?
Droši vien jūs nepārtināt visas savas atmiņas, līdz nonācāt pie «vakardiena + pusdienas». Jūs uzreiz pievērsāties tai pieredzes daļai, kurā atrodami šie jēdzieni. Tas ir noderīgs domāšanas modelis aģentu veidošanai:
Milzīgs konteksta logs nav atmiņa.
Izgūtu dokumentu kaudze nav izpratne.
Gara domu ķēde nav uzticamība.
Tās ir sastāvdaļas. Taču tas, kas liek aģentam šķist kā aģentam, ir tas pats, kas neļauj jūsu smadzenēm ar pilno pārlasi pārmeklēt visu dzīves vēsturi: kontrole.
Nesen publicētā aptauja — Agentic Reasoning for Large Language Models — lieliski apkopoja (un nosauca) pārmaiņas, ko daudzi no mums izjutuši izstrādes laikā: no spriestspējas modeļa iekšienē uz spriestspēju mijiedarbības procesā. Šis ieraksts nav minētā darba kopsavilkums. Tas ir mēģinājums pārvērst šīs pārmaiņas praktiskā sistēmu projektēšanas pieejā:
Ja veidosiet aģentus kā tērzēšanas robotus ar rīkiem, turpināsiet saskarties ar tērzēšanas robotu kļūmēm, tikai kļūdas būs dārgākas.
Kādu laiku mūsu ierastā recepte «padarīt modeli gudrāku» būtībā bija šāda: labākas uzvednes, domu ķēde, paškonsekvence vai iztvērumā balstīti uzlabojumi un varbūt arī meklēšana.
ReAct bija pagrieziena punkts, jo padarīja secību «doma → darbība → novērojums» dabisku. Taču ievērojiet netiešo ierobežojumu: daudz kas joprojām kļūst par «vienpiemēra izsecināšanu, tikai ar vairāk marķieriem». Aptaujas formulējums ir precīzāks: aģentiskā spriestspēja uzsver mijiedarbības mērogošanu testa laikā, pārvēršot izsecināšanu iteratīvā procesā, kurā modelis, atmiņa un vide pastāvīgi paliek ciklā.
Ja esat veidojis (vai lietojis) aģentus, kas demonstrācijās šķiet iespaidīgi, bet reālās darbplūsmās ir trausli, šis raksts ir domāts jums.
Aprakstīšu bieži redzētu pieeju (kuras versijas noteikti esmu veidojis arī pats):
Paņemiet labu tērzēšanas modeli
Pievienojiet dažus rīkus (meklēšanu, datubāzes vaicājumus, varbūt koda izpildi)
Pievienojiet RAG
Pievienojiet sistēmas uzvedni “you are an autonomous agent”
Ievietojiet to visu while ciklā, līdz tas apstājas vai iestājas taimauts
Apsveicam — jums ir aģentam līdzīgs objekts. Taču tas mēdz kļūdīties paredzamos veidos:
Uzpūsts konteksts: tiek pievienots ikviens novērojums, un uzvednes kļūst par arheoloģiskiem slāņiem.
Haotiska rīku lietošana: «nepareizais rīks, bet ar pārliecību» kļūst par ierasto kļūmes režīmu.
Nav apstāšanās nosacījumu: tas turpina darboties tāpēc, ka var, nevis tāpēc, ka vajadzētu.
Nav enkurošanas disciplīnas: tas nepamana, ka kļūdās, ja vien jūs nepiespiežat to pārbaudīt.
Atmiņa = tērzēšanas vēsture: būtībā tā ir žurnālu rakstīšana, ko nodēvē par mācīšanos.
Tāpēc «aģenti» demonstrācijās bieži šķiet maģiski, bet produkcijas vidē — haotiski. To apliecina arī mūsu pieredze, ieviešot aģentiskas sistēmas produkcijas vidē: tiklīdz vērtējat nevis modeli, bet sistēmu, kļūmju režīmi ietver navigāciju, rīku lietošanas disciplīnu, konteksta apcirpšanu un novērtēšanas sistēmas izstrādi, nevis tikai jautājumu «vai modelis atbildēja pareizi».
Tādēļ rodas jautājums: kādam jābūt mērķtiecīgi veidotam aģentam?
Lai tas būtu mazāk abstrakti, aplūkosim vienkāršotu darbplūsmu, ko vairums cilvēku spēj iztēloties: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Izplatīta «aģentam līdzīga» realizācija darbojas šādi:
Tā uzreiz izgūst virkni aviokompāniju un ceļošanas noteikumu dokumentu (pat ja neviens no tiem vēl nav vajadzīgs).
Tā izsauc meklēšanas rīku, uzvednē ielīmē garu rezultātu sarakstu un «izvēlas vienu».
Tā priekšlaicīgi veic rezervāciju, nepārbaudot ierobežojumus (ierašanās laiku, bagāžu, sēdvietu un noteikumus).
Ja mēģinājums neizdodas, tā mēģina vēlreiz nedaudz citādi, taču bez skaidras izpratnes par to, kas mainījās vai ko tā iemācījās.
Kļūmes iemesls nav modeļa nespēja spriest — problēma ir tā, ka sistēma nekontrolē darbplūsmu.
Aģentiskāka versija uztver uzdevumu kā interaktīvu procesu ar skaidri definētu stāvokli un pārbaudēm:
PLĀNOT: atkārtoti formulēt ierobežojumus un uzskaitīt trūkstošo informāciju (piemēram, «kurai lidostai dodat priekšroku?» vai «vai der viens savienotais reiss?»).
RĪKOTIES: izsaukt lidojumu meklēšanu ar strukturētu vaicājumu (datumu diapazons, ierašanās ierobežojums, budžets).
NOVĒROT: saglabāt rezultātus kompaktā stāvokļa objektā (pieci labākie varianti ar cenu, ierašanās laiku un pārsēšanos), nevis ielīmēt milzīgu teksta blāķi.
ATJAUNINĀT: precizēt vaicājumu, ja ierobežojumi nav izpildīti (piemēram, «ierašanās pirms plkst. 18.00 ir pārāk stingrs nosacījums — paplašināt laika diapazonu vai palielināt budžetu?»).
PĀRBAUDĪT: palaist validētājus («ierašanās < 18.00», «cena ≤ £900», «atbilst noteikumiem», «pieejama sēdvietas izvēle»).
APSTĀTIES: tikai tad, kad rezervēšanas API atgriež apstiprinājumu un visi validētāji ir sekmīgi.
Izmaiņas ir niansētas, taču izšķirošas. Izgūšana notiek ar nosacījumiem, nevis refleksīvi; konteksts tiek pārvaldīts — stāvoklis ir strukturēts, nevis uzkrāts — un verifikācija ir iekļauta ciklā, nevis atstāta lietotāja ziņā. Aizstājiet «lidojuma rezervēšanu» ar «iepirkuma pasūtījuma izveidi», «atmaksas izsniegšanu», «produkcijas vides konfigurācijas maiņu» vai «PR piegādi», un stāsts būs tas pats: tiklīdz aģents spēj rīkoties, cikls kļūst svarīgāks par uzvedni.
Iepriekš minētajā aptaujā aģentiskā spriestspēja iedalīta trīs līmeņos: pamata (plānošana, rīku lietošana un meklēšana), pašattīstošā (atgriezeniskā saite un atmiņa) un kolektīvā (vairāku aģentu koordinācija).
Taču dziļākā doma ir šāda: spriestspēja kļūst par plānošanas, lēmumu pieņemšanas un verifikācijas organizējošo principu, nevis tikai ticamas domu ķēdes ģenerēšanu. Tas izklausās abstrakti, līdz sasaistāt šo ideju ar izmaiņām savā arhitektūrā. Jāatceras trīs galvenie aspekti:
Labs aģents nedrīkst uztvert izgūšanu kā darbību, kas «jāveic vienmēr». Izgūšana ir lēmums, nevis reflekss.
Lūk, praktisks pamatprincips:
Ja sistēma veic izgūšanu katrā mijiedarbības reizē, jūs neesat izveidojis izgūšanu — jūs esat ieviesis konteksta nodokli.
Reālajā darbā tas notiek visu laiku. Atkļūdojot incidentu produkcijas vidē, jūs neievietojat kontekstā visus žurnālus; balstoties uz pašreizējo hipotēzi, jūs izlemjat, kurus rādītājus vai žurnālus izgūt nākamos. Tā ir «aģentiska izgūšana». Lūk, konkrētāka pieeja:
Izlemiet, vai nepieciešama izgūšana
Ja jā: sagatavojiet vaicājumu, izgūstiet, pārskatiet un izvelciet vajadzīgo
Ja pierādījumi ir pretrunīgi: izgūstiet vēlreiz
Tikai tad apkopojiet secinājumus
Te arī «aģentiskais RAG» sāk atšķirties no tradicionālā RAG: izgūšana kļūst par apzinātu spriešanas soli, nevis darbplūsmas noklusējuma posmu.
Tiklīdz pārstājat vērtēt «modeli» un sākat vērtēt «sistēmu», stāvokļa izsekošana un trasēšana kļūst būtiska.
Viena lieta, ko nozare nu jau definē daudz skaidrāk, ir aģentu darbplūsmu novērojamība. Piemēram, OpenAI Agents SDK ir iebūvēta trasēšana un Traces informācijas panelis, kas reģistrē aģenta izpildes (ģenerēšanu, rīku izsaukumus, uzdevumu nodošanu, aizsargmehānismus un pielāgotus notikumus), lai varētu soli pa solim atkļūdot un auditēt notikušo.
Tā nav tikai «vēlama iespēja». Tā ir atšķirība starp sistēmu, kuru var atkļūdot, un tādu, kuru var novērtēt tikai pēc sajūtām.
Manuprāt, aptaujas praktiski noderīgākā daļa ir tās tiešā pieeja atgriezeniskajai saitei. Tajā izdalīti trīs atgriezeniskās saites režīmi: reflektīva atgriezeniskā saite (ģenerēt → kritizēt → pārskatīt), parametriska pielāgošana (mācīšanās ar papildapmācību/RL) un validētāja vadīta atgriezeniskā saite (mēģināt atkārtoti, līdz validētāja pārbaude ir sekmīga).
Vairumam komandu būtu jāsāk ar validētāja vadītu atgriezenisko saiti, jo tā ir garlaicīga, bet efektīva. Ja varat uzrakstīt jebkādu validētāju, kas veic vienībtestus, pārbauda shēmu, piemēro uzņēmējdarbības noteikumus vai ierobežojumus («bez eskalācijas neatmaksāt vairāk par X») vai pārbauda faktu patiesumu («jānorāda atsauces»), varat pārvērst nedeterministisku modeļa izvadi par kaut ko patiešām uzticamu.
Viena no šeit sastopamajām «nezināmajām nezināmajām» pārmaiņām ir vienkārša: aģentu pasaulē uzticamību bieži vairāk nodrošina cikls, nevis modelis.
Šī ir vienkāršākā cikla disciplīna, kas, pēc manas pieredzes, droši uzlabo darbību bez apmācības:
Darbojieties pa soļiem: plānot → rīkoties → novērot → atjaunināt,
pēc katras darbības apkopojiet novērojumus 1–3 aizzīmēs,
apstājieties, kad sasniegti panākumu kritēriji vai iztērēts budžets; atgrieziet labāko zināmo rezultātu un atlikušās neskaidrības.
Mērķis nav padarīt modeli daudzvārdīgu. Mērķis ir padarīt sistēmu saprotamu un katrā solī piespiest to «saskarties ar realitāti». Inženieriem labi saprotams piemērs ir CI stila slēgtā cikla enkurošana:
Plānot: ierosināt izmaiņu sarakstu
Rīkoties: palaist testus/lintēšanu
Novērot: parsēt kļūmes
Atjaunināt: veikt labojumus un mēģināt vēlreiz
Daži jautājumi, kas mēdz atklāt nejauši radušos aģentu konstrukcijas:
«Vai mans aģents izvēlas, ko izgūt, vai arī es vienmēr veicu izgūšanu?»
Ja izgūšana notiek bez nosacījumiem, par to maksāsiet ar lielāku aizkavi un izmaksām, konteksta atšķaidīšanu un augstāku principa «atkritumi iekšā, atkritumi ārā» risku.
«Vai mans aģents spēj pamanīt, ka kļūdās?»
Ja vienīgais aģenta atgriezeniskās saites signāls ir «lietotājs kļūst aizkaitināts», jūs īstenojat RL uz cilvēku ciešanu rēķina. Validētāja vadīts atkārtotu mēģinājumu cikls ir vislabākais veids, kā likt tam pārbaudīt realitāti.
«Vai atmiņā var rakstīt, un vai tā laika gaitā uzlabojas?»
Ja jūsu «atmiņa» tikai papildina tērzēšanas vēsturi, jūs būtībā rakstāt žurnālus. Aptaujas skatījums uz atmiņu ir būtisks: atmiņa kļūst par dinamiski augošu kontekstu, ko aģenti laika gaitā pilnveido, nevis tikai sarunas pierakstu.
Žurnāli parāda, kas notika, bet atmiņa — ko darīt nākamreiz. Tērzēšanas vēsture ir sarunas pieraksts. Atmiņa ir pastāvīgi pilnveidota politika par to, ko vērts saglabāt turpmākai izmantošanai.
Praktisks sākums ir neliela «gūto atziņu» tabula, kuras atslēga ietver uzdevuma veidu, rīku un kļūmes režīmu, bet vērtība — to, kas darbojās un no kā izvairīties. Mērķis nav izveidot nevainojamu zināšanu grafu. Mērķis ir panākt kumulatīvu uzlabojumu: atmiņa un atgriezeniskā saite pārvērš aģentus no «palīgiem bez stāvokļa» par sistēmām, kas laika gaitā kļūst labākas.
Ir vilinoši problēmai piesaistīt vairāk aģentu, taču tas bieži vien tikai palielina koordinācijas izmaksas. Labs «minimālās dzīvotspējīgās komandas» modelis:
Koordinators: sadala uzdevumu un piešķir tā daļas
Izpildītājs: izsauc rīkus un veic izmaiņas
Kritiķis/vērtētājs: pārbauda pareizību un riskus
Atmiņas pārzinis: pieraksta un atlasa gūtās atziņas
Ja nevarat paskaidrot, par ko atbild katrs aģents, vairāki aģenti jums, visticamāk, vēl nav vajadzīgi.
Ja patiešām pieņemam šo paradigmas maiņu, mums, visticamāk, jāpārstāj uzvednēs sabāzt visu iespējamo, uzskatīt kļūmes par gala izvadi un vērtēt aģentus kā tērzēšanas robotus. Tā vietā jāsāk uztvert aģentus tādus, kādi tie ir: programmatūras sistēmas, kurās valoda ir vadības plakne, bet uzticamību nodrošina cikls.
Pirms pievienojat vēl vienu modeli, pievienojiet vēl vienu novērtēšanas ciklu. Pirms izgūstat visu, padariet izgūšanu atkarīgu no nosacījumiem. Ieviesiet vienu validētāju, pirms ieviešat desmit. Uztveriet atmiņu kā politikas lēmumus, nevis datubāzi. Un, pārejot uz vairāku aģentu sistēmu, sāciet ar diviem aģentiem, nevis divdesmit. Tie nav noteikumi — tie ir modeļi, kas izturējuši pārbaudi produkcijas vidē.