Већина тимова за вештачку интелигенцију који желе боље перформансе агената посеже за истим полугама: већим прозорима контекста, већим бројем докумената и паметнијим инструкцијама. Овај чланак тврди да је тај инстинкт потпуно погрешан. Не недостаје нам више информација. Недостаје контрола. Добро осмишљен контролни слој раздваја агента који ради у демонстрацији од оног који ради у продукцији.
Већа меморија, више докумената или дужи прозор контекста не чине агента вештачке интелигенције паметнијим, већ само споријим и скупљим. Прави напредак долази када агента научите да изабере шта му је потребно и када, уместо да све обрађује одједном.
Поузданост потиче од петље, а не од модела. Разлика између агента који одушеви у демонстрацији и оног који се добро покаже у продукцији није у квалитету вештачке интелигенције, већ у томе да ли систем проверава сопствени рад. Агенти који у сваком кораку планирају, делују, посматрају и проверавају сами уочавају своје грешке, уместо да самоуверено греше.
Већина данашњих агената вештачке интелигенције у суштини су четботови са додатним корацима: немају механизам да знају да ли напредују, када треба да стану или када да покушају другачије. Одговарајући контролни слој — јасни критеријуми успеха, структурирано стање и валидационе провере — претвара нешто што само личи на агента у систем којем заиста можете веровати.
Шта сте јуче ручали?
Вероватно нисте премотали свако сећање које сте икада имали док нисте стигли до „јуче + ручак“. Одмах сте прешли на део искуства у којем се ти појмови налазе. То је користан ментални модел за прављење агената:
Огроман прозор контекста није меморија.
Гомила преузетих докумената није разумевање.
Дугачак начин резоновања није поузданост.
То су састојци. Али оно због чега агент заиста делује као агент исто је оно због чега ваш мозак не претражује грубом силом читаву вашу животну историју: контрола.
Недавни преглед — Agentic Reasoning for Large Language Models — одлично је сажео (и именовао) помак који су многи од нас приметили током развоја: од резоновања унутар модела ка резоновању кроз интеракцију. Овај текст није сажетак тог рада. Он је покушај да се тај помак преточи у практичан дизајн система:
Ако агенте правите као четботове са алатима, и даље ћете добијати типичне грешке четботова, само ће оне бити скупље.
Неко време се наш подразумевани приступ „побољшању памети модела“ у суштини сводио на боље инструкције, начин резоновања, самодоследност / побољшања заснована на узорковању и можда мало претраге.
ReAct је био прекретница јер је образац „мисао → радња → запажање“ учинио природним. Али уочите имплицитно ограничење: много тога се и даље своди на „закључивање с једним примером, али са више токена“. Преглед то прецизније формулише: агентско резоновање наглашава скалирање интеракције током тестирања — претварање закључивања у итеративни процес у чијој петљи стално остају модел, меморија и окружење.
Ако сте правили (или користили) агенте који делују импресивно у демонстрацијама, али су крхки у стварним радним токовима, ово је за вас.
Описаћу образац који сам често виђао (и чије сам варијанте свакако и сам правио):
Узмите добар модел за ћаскање
Додајте неколико алата (претрагу, упит бази података, можда извршавање кода)
Додајте RAG
Додајте системску инструкцију “you are an autonomous agent”
Све то ставите у while петљу док се не заустави или не истекне време
Честитамо, добили сте нешто што личи на агента. Али то обично отказује на предвидљиве начине:
Надувавање контекста: свако запажање се додаје, па инструкције постају археолошки слојеви.
Насумично испробавање алата: „погрешан алат, али самоуверено“ постаје подразумевани начин отказа.
Нема услова за заустављање: наставља зато што може, а не зато што треба.
Нема дисциплине утемељења: не примећује да греши ако га не приморате на то.
Меморија = историја ћаскања: што се у суштини своди на вођење евиденције које називамо учењем.
Зато „агенти“ често делују чаробно у демонстрацијама, а неуредно у продукцији. То потврђује и наше искуство са увођењем агентских система у продукцију: када више не оцењујете модел већ систем, начини отказа обухватају навигацију, дисциплиновану употребу алата, сажимање контекста и дизајн евалуације, а не само питање „да ли је модел тачно одговорио“.
Питање, дакле, постаје: како изгледа наменски осмишљен агент?
Да ово не би остало апстрактно, ево једноставног радног тока који већина људи може да замисли: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Уобичајена имплементација која личи на агента изгледа овако:
Одмах преузима мноштво докумената о правилима авио-компанија / путовања (чак и ако још нису потребни).
Позива алат за претрагу, умеће дугачак списак резултата у инструкцију и „бира један“.
Прерано резервише без провере ограничења (времена доласка / пртљага / седишта / правила).
Ако не успе, покушава поново на мало другачији начин, али без јасне представе о томе шта се променило или шта је научио.
Проблем није у томе што модел не уме да резонује, већ у томе што систем не контролише радни ток.
Верзија са израженијим агентским својствима третира задатак као интерактиван процес са експлицитним стањем и проверама:
ПЛАНИРАЈ: понови ограничења и наведи податке који недостају (нпр. “which airport preference?” / “is 1 stop ok?”).
ДЕЛУЈ: позови претрагу летова помоћу структурираног упита (распон датума, ограничење времена доласка, буџет).
ПОСМАТРАЈ: сачувај резултате у сажетом објекту стања (пет најбољих опција са ценом, доласком и преседањима), а не у огромној налепљеној маси текста.
АЖУРИРАЈ: прецизирај упит ако ограничења нису испуњена (нпр. “arrival before 6pm is too strict—widen time window or raise budget?”).
ПРОВЕРИ: покрени валидаторе (“arrival < 18:00,” “price ≤ £900,” “policy compliant,” “seat selection available”).
ЗАУСТАВИ: тек када API за резервације врати потврду и све провере валидатора буду успешне.
Промена је суптилна, али пресудна. Преузимање је условно (није рефлекс), контекстом се управља (стање је структурирано, а не само нагомилано), а провера је део петље (није препуштена кориснику). Замените „резервацију лета“ са „прављењем наруџбенице“, „одобравањем повраћаја новца“, „изменом продукционе конфигурације“ или „испоруком PR-а“ и прича остаје иста: када агент може да делује, петља је важнија од инструкције.
Претходно поменути преглед организује агентско резоновање у три слоја: основни (планирање, употреба алата и претрага), саморазвијајући (повратне информације и меморија) и колективни (координација више агената).
Али дубља идеја гласи: резоновање постаје водећи принцип планирања, одлучивања и провере, а не само генерисања уверљивог начина резоновања. То звучи апстрактно док не утврдите шта се тиме мења у вашој архитектури. Треба запамтити три кључне ствари:
Добар агент не треба да третира преузимање као нешто што се „увек ради“. Преузимање је одлука, а не рефлекс.
Ево практичног правила:
Ако ваш систем преузима податке при сваком кораку, нисте направили механизам за преузимање, већ порез на контекст.
То се стално дешава у стварном раду. Када отклањате продукциони инцидент, не убацујете све евиденције у контекст, већ на основу тренутне хипотезе одлучујете које метрике и евиденције следеће треба преузети. То је „агентско преузимање“. Ево конкретнијег обрасца:
Одлучите да ли вам је потребно преузимање
Ако јесте: саставите упит, преузмите, прегледајте и издвојте
Ако су докази противречни: преузмите поново
Тек онда обједините закључке
Ту „агентски RAG“ почиње да се разликује од традиционалног RAG-а: преузимање постаје промишљен корак резоновања, а не подразумевана фаза процеса.
Чим престанете да оцењујете „модел“ и почнете да оцењујете „систем“, праћење стања и тока постаје важно.
Сектор је у међувремену почео отвореније да говори о видљивости радних токова агената. На пример, OpenAI Agents SDK има уграђено праћење и контролну таблу Traces, која бележи извршавања агента (генерисања, позиве алата, предаје задатака, заштитне механизме и прилагођене догађаје), како бисте корак по корак могли да отклоните грешке и проверите шта се догодило.
То није нешто што је тек „лепо имати“. То је разлика између система у којем можете да отклањате грешке и оног који можете само да процените по осећају.
По мом мишљењу, најприменљивији део прегледа јесте то колико непосредно говори о повратним информацијама. Повратне информације дели на три режима: рефлексивне повратне информације (генериши → критикуј → преради), параметарско прилагођавање (учење финим подешавањем / RL-ом) и повратне информације засноване на валидатору (понављање док се не прође провера валидатора).
Већина тимова треба да почне од повратних информација заснованих на валидатору јер су једноставне и делотворне. Ако можете да напишете било какав валидатор који покреће јединичне тестове, проверава шему, спроводи пословна правила / ограничења („без повраћаја новца изнад X без ескалације“) или утврђује чињеничну тачност („извори су обавезни“), недетерминистички излаз модела можете претворити у нешто чему заиста можете веровати.
Један од неочекиваних помака овде је једноставан: у свету агената поузданост често више потиче од петље него од модела.
Ово је најједноставнија дисциплина петље коју сам пронашао, а која поуздано побољшава понашање без обуке:
Радите у корацима: Планирај → Делуј → Посматрај → Ажурирај,
После сваке Радње сажмите Запажање у 1–3 ставке,
Зауставите се када су критеријуми успеха испуњени или је буџет потрошен; вратите најбољи познати резултат и преостале неизвесности.
Циљ није да модел буде опширан. Циљ је да систем буде разумљив и да се у сваком кораку примора на „додир са стварношћу“. Пример близак инжењерима јесте утемељење у затвореној петљи, налик CI процесу:
Планирај: предложи списак измена
Делуј: покрени тестове / линтер
Посматрај: рашчлани грешке
Ажурирај: исправи и покушај поново
Неколико питања која обично разоткривају случајно настале дизајне агената:
„Да ли мој агент бира шта ће преузети или ја увек све преузимам?“
Ако је преузимање безусловно, платићете већим кашњењем и трошковима, разводњавањем контекста и већим ризиком да лош улаз произведе лош излаз.
„Може ли мој агент да примети да греши?“
Ако је једини сигнал повратне информације вашег агента то што се корисник изнервира, спроводите RL уз људску патњу. Петља поновних покушаја заснована на валидатору најчистији је начин да га суочите са стварношћу.
„Да ли се у меморију може уписивати и да ли она временом постаје боља?“
Ако ваша „меморија“ само дописује историју ћаскања, у суштини водите евиденцију. Начин на који преглед представља меморију је важан: она постаје контекст који се динамички развија и који агенти временом усавршавају, а не само транскрипт.
Евиденција вам говори шта се догодило, а меморија шта да урадите следећи пут. Историја ћаскања је транскрипт. Меморија је политика која се развија и одређује шта вреди сачувати за убудуће.
Практичан почетак је мала табела „научених лекција“, чији кључ чине врста задатка, алат и начин отказа, а вредност оно што је успело и што треба избегавати. Циљ није да направите савршен граф знања. Циљ је да створите кумулативно побољшање понашања: меморија и повратне информације претварају агенте из „помоћника без стања“ у системе који временом постају бољи.
Примамљиво је додати још агената да би решили проблем, али то често умножава трошкове координације. Добар образац „минимално одрживог тима“:
Координатор: рашчлањује и додељује
Извршилац: позива алате / уноси измене
Критичар/оцењивач: проверава исправност/ризик
Чувар меморије: бележи/уређује научене лекције
Ако не можете да објасните за шта је сваки агент одговоран, вероватно вам још није потребно више агената.
Ако заиста прихватимо промену парадигме, вероватно ћемо престати да трпамо све у инструкције, третирамо грешке као коначне излазе и оцењујемо агенте као четботове. Уместо тога, почећемо да третирамо агенте као оно што јесу: софтверске системе у којима је језик контролна раван, а поузданост потиче од петље.
Пре него што додате још један модел, додајте још једну петљу за евалуацију. Пре него што преузмете све, учините преузимање условним. Испоручите један валидатор пре него што испоручите десет. Третирајте меморију као скуп одлука о правилима, а не као базу података. А када прелазите на више агената, почните са два, а не са двадесет. То нису правила, већ обрасци који су опстали у продукцији.