Повеќето тимови за ВИ што сакаат подобри перформанси на агентите ги користат истите механизми: поголеми прозорци за контекст, повеќе документи и попаметни промптови. Оваа статија тврди дека тој инстинкт е целосно погрешен. Состојката што недостига не е повеќе информации. Туку контрола. Добро осмислениот контролен слој го разликува агентот што работи во демонстрација од оној што работи во продукција.
Поголема меморија, повеќе документи или подолг прозорец за контекст не го прават агентот за ВИ попаметен — туку само побавен и поскап. Вистинскиот напредок доаѓа кога агентот ќе научи да избира што му треба и кога му треба, наместо да обработува сè одеднаш.
Сигурноста произлегува од циклусот, а не од моделот. Разликата меѓу агент што импресионира на демонстрација и агент што се покажува во продукција не е квалитетот на ВИ, туку дали системот ја проверува сопствената работа. Агентите што планираат, дејствуваат, набљудуваат и проверуваат при секој чекор ги откриваат сопствените грешки наместо самоуверено да грешат.
Повеќето агенти за ВИ денес во основа се четботови со дополнителни чекори — немаат механизам да знаат дали се на вистинскиот пат, кога да запрат или кога да пробаат поинаков пристап. Соодветен контролен слој — јасни критериуми за успех, структурирана состојба и проверки за валидација — го претвора објектот што наликува на агент во нешто на кое навистина може да му се верува.
What did you have for lunch yesterday?
Веројатно не сте го репродуцирале секој спомен што некогаш сте го имале додека не стигнете до „вчера + ручек“. Веднаш сте преминале на делот од искуството каде што се наоѓаат тие поими. Тоа е корисен ментален модел за создавање агенти:
Огромен прозорец за контекст не е меморија.
Куп преземени документи не е разбирање.
Долг синџир на размислување не е сигурност.
Тоа се состојки. Но она што прави еден агент да делува како агент е истото што го спречува мозокот со груба сила да ја пребарува целата ваша животна историја: контролата.
Неодамнешниот преглед — Агентско расудување за големи јазични модели — одлично ја сумираше (и именуваше) промената што многумина од нас ја чувствуваат при развојот: од расудување во моделот кон расудување преку интеракција. Оваа објава не е резиме на тој труд. Таа е обид промената да се преточи во практичен дизајн на системот:
Ако создавате агенти како четботови со алатки, ќе продолжите да ги добивате истите начини на откажување како кај четботовите — само со поскапи грешки.
Извесно време, стандардниот пристап за „направи го моделот попаметен“ во основа беше: подобри промптови, синџир на размислување, самодоследност/подобрувања преку примероци и можеби пребарување.
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?”).
ДЕЈСТВУВАЈ: повикај го пребарувањето летови со структурирано барање (период, ограничување за пристигнување и буџет).
НАБЉУДУВАЈ: зачувај ги резултатите во компактен објект за состојбата (најдобрите 5 опции со цена, пристигнување и преседнувања), а не како огромен вметнат блок.
АЖУРИРАЈ: прецизирај го барањето ако ограничувањата не се исполнети (на пр., “arrival before 6pm is too strict—widen time window or raise budget?”).
ПРОВЕРИ: изврши валидатори („пристигнување < 18:00“, „цена ≤ £900“, „усогласено со правилата“, „достапен избор на седиште“).
ЗАПРИ: дури откако API-то за резервации ќе врати потврда и сите валидатори ќе поминат.
Промената е суптилна, но пресудна. Преземањето е условно (не рефлексно), контекстот е управуван (состојбата е структурирана, а не натрупана), а проверката е дел од циклусот (не му е препуштена на корисникот). Заменете го „резервирањето лет“ со „создавање налог за набавка“, „одобрување поврат“, „менување продукциска конфигурација“ или „испорачување PR“ и приказната е иста: штом агентот може да дејствува, циклусот е поважен од промптот.
Претходно споменатиот преглед го организира агентското расудување во три слоја: основен (планирање, употреба на алатки и пребарување), саморазвоен (повратни информации и меморија) и колективен (координација на повеќе агенти).
Но подлабоката идеја е дека расудувањето станува организациски принцип за планирање, одлучување и проверка — а не само за генерирање уверлив синџир на размислување. Тоа звучи апстрактно сè додека не го поврзете со промените во архитектурата. Треба да запомните три клучни точки:
Добриот агент не треба да го третира преземањето како нешто што „секогаш се прави“. Преземањето е одлука, а не рефлекс.
Еве практично правило:
Ако системот презема податоци при секој чекор, не сте изградиле механизам за преземање — сте создале данок на контекстот.
Ова постојано се појавува во реалната работа. Кога отстранувате продукциски инцидент, не ги истурате сите дневници во контекстот; врз основа на тековната хипотеза одлучувате кои метрики или дневници да ги преземете следно. Тоа е „агентско преземање“. Еве поконкретен образец:
Одлучете дали ви треба преземање
Ако да: составете барање, преземете, прегледајте, извлечете
Ако доказите се противречни: преземете повторно
Дури потоа синтетизирајте
Тука „агентскиот RAG“ почнува да се разликува од традиционалниот RAG: преземањето станува намерен чекор на расудување, а не стандардна фаза од процесот.
Штом ќе престанете да оценувате „модел“ и ќе почнете да оценувате „систем“, следењето на состојбата и текот стануваат важни.
Една работа што индустријата досега ја дефинираше појасно е набљудливоста на работните текови на агентите. На пример, Agents SDK на OpenAI доаѓа со вградено следење и контролна табла Traces што ги евидентира извршувањата на агентот (генерирања, повици на алатки, предавања, заштитни механизми и приспособени настани), токму за да можете чекор по чекор да утврдите и проверите што се случило.
Тоа не е само „добро да се има“. Тоа е разликата меѓу систем во кој можете да откривате грешки и систем што можете само површно да го проверите.
Според мене, најприменливиот дел од прегледот е неговиот директен пристап кон повратните информации. Тој ги дели повратните информации во три режими: рефлексивни повратни информации (генерирај → критикувај → ревидирај), параметарско приспособување (учење преку фино нагодување/RL) и повратни информации водени од валидатор (обидувај се повторно додека проверката не успее).
Повеќето тимови треба да почнат со повратни информации водени од валидатор бидејќи се здодевни, но ефикасни. Ако можете да напишете каков било валидатор што извршува единечни тестови, ја проверува шемата, поставува деловни правила/ограничувања („без поврат над X без ескалација“) или ја утврдува фактичката точност („потребни се цитати“), тогаш недетерминистичкиот излез од моделот можете да го претворите во нешто на кое навистина може да му се верува.
Една од промените од типот „не знаеме што не знаеме“ е едноставна: во светот на агентите, сигурноста често произлегува повеќе од циклусот отколку од моделот.
Ова е наједноставната дисциплина на циклусот што сигурно го подобрува однесувањето без обука:
Работете во чекори: Планирај → Дејствувај → Набљудувај → Ажурирај,
По секое дејство, сумирајте го набљудувањето во 1–3 точки,
Запрете кога ќе се исполнат критериумите за успех или ќе се достигне буџетот; вратете го најдобриот познат резултат и преостанатите неизвесности.
Целта не е моделот да стане опширен. Целта е системот да биде разбирлив и при секој чекор да се принуди да ја провери реалноста. Пример близок до инженерите е засидрувањето со затворен циклус, во стилот на CI:
Планирај: предложи список со измени
Дејствувај: изврши тестови/линтер
Набљудувај: анализирај ги неуспесите
Ажурирај: примени закрпа и обиди се повторно
Неколку прашања што обично откриваат случајни дизајни на агенти:
„Дали мојот агент избира што да преземе или јас секогаш преземам сè?“
Ако преземањето е безусловно, ќе платите со доцнење, трошоци, разводнување на контекстот и поголем ризик од принципот „лош влез — лош излез“.
„Може ли мојот агент да забележи дека греши?“
Ако единствениот сигнал за повратни информации на агентот е „корисникот се нервира“, применувате RL преку човечко страдање. Циклусот на повторни обиди воден од валидатор е најчистиот начин да му овозможите проверка на реалноста.
„Може ли да се запишува во меморијата и дали таа се подобрува со текот на времето?“
Ако вашата „меморија“ само ја дополнува историјата на разговорот, тогаш во основа пишувате дневници. Начинот на кој прегледот ја поставува меморијата е важен: таа станува контекст што динамично расте и што агентите го усовршуваат со текот на времето — а не само транскрипт.
Дневниците кажуваат што се случило, а меморијата кажува што да направите следниот пат. Историјата на разговорот е транскрипт. Меморијата е политика што се развива и одредува што вреди да се зачува за понатаму.
Практичен почеток е мала табела со „научени лекции“, организирана според клуч составен од типот на задача, алатката и начинот на неуспех, со вредност што кажува што успеало и што треба да се избегнува. Целта не е да изградите совршен графикон на знаење. Целта е да создадете однесување со кумулативен ефект: меморијата и повратните информации ги претвораат агентите од „помошници без состојба“ во системи што се подобруваат со текот на времето.
Примамливо е да додадете повеќе агенти за проблемот, но тоа често ги умножува трошоците за координација. Добар образец за „минимално одржлив тим“:
Координатор: расчленува и доделува
Извршител: повикува алатки и прави измени
Критичар/оценувач: ја проверува точноста и ризикот
Чувар на меморијата: ги запишува и уредува лекциите
Ако не можете да објасните за што е одговорен секој агент, веројатно сè уште не ви требаат повеќе агенти.
Ако навистина ја прифатиме промената на парадигмата, веројатно ќе престанеме да ставаме сè во промптовите, да ги третираме неуспесите како конечни резултати и да ги оценуваме агентите како четботови. И ќе почнеме да ги третираме агентите како она што се: софтверски системи во кои јазикот е контролна рамнина, а сигурноста произлегува од циклусот.
Пред да додадете уште еден модел, додајте уште еден циклус за евалуација. Пред да преземете сè, направете го преземањето условно. Испорачајте еден валидатор пред да испорачате десет. Третирајте ја меморијата како одлуки за политиката, а не како база на податоци. А кога преминувате на повеќе агенти, почнете со два, а не со дваесет. Ова не се правила, туку обрасци што опстанаа во продукција.