Повечето екипи за ИИ, които се стремят към по-добра производителност на агентите, посягат към едни и същи лостове: по-големи контекстни прозорци, повече документи и по-умни подкани. Тази статия твърди, че този инстинкт е изцяло погрешен. Липсващата съставка не е повече информация. Тя е контролът. Добре проектираният контролен слой отличава агента, който работи в демонстрация, от този, който работи в реална среда.
По-голямата памет, повече документи или по-дългият контекстен прозорец не правят един ИИ агент по-умен, а само по-бавен и по-скъп. Истинското подобрение идва, когато научите агента да избира какво му трябва и кога, вместо да обработва всичко наведнъж.
Надеждността идва от цикъла, а не от модела. Разликата между агент, който впечатлява в демонстрация, и такъв, който издържа в реална среда, не е качеството на ИИ, а дали системата проверява собствената си работа. Агентите, които планират, действат, наблюдават и проверяват всяка стъпка, откриват собствените си грешки, вместо уверено да дават погрешни резултати.
Повечето ИИ агенти днес по същество са чатботове с допълнителни стъпки — нямат механизъм да разберат дали са на прав път, кога да спрат или кога да опитат друг подход. Подходящият контролен слой — ясни критерии за успех, структурирано състояние и проверки за валидност — превръща нещо, което само прилича на агент, в система, на която действително можете да се доверите.
Какво обядвахте вчера?
Вероятно не сте възпроизвели всеки свой спомен, докато стигнете до „вчера + обяд“. Насочили сте се направо към частта от опита си, където се намират тези понятия. Това е полезен мисловен модел за изграждане на агенти:
Огромният контекстен прозорец не е памет.
Купчина извлечени документи не е разбиране.
Дългото логическо мислене не е надеждност.
Това са само съставки. Но онова, което кара един агент да изглежда като агент, е същото, благодарение на което мозъкът ви не претърсва грубо цялата история на живота ви: контролът.
Неотдавнашният обзор — 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?”).
ПРОВЕРКА: изпълнете валидатори („пристигане < 18:00“, „цена ≤ £900“, „съответства на правилата“, „има избор на място“).
СПИРАНЕ: едва след като API за резервации върне потвърждение и всички проверки са успешни.
Промяната е фина, но решаваща. Извличането е условно, а не рефлекс; контекстът се управлява — състоянието е структурирано, а не натрупвано; проверката е част от цикъла, а не е оставена на потребителя. Заменете „резервиране на полет“ със „създаване на поръчка за покупка“, „възстановяване на сума“, „промяна на производствена конфигурация“ или „публикуване на PR“ и изводът е същият: щом агентът може да действа, цикълът е по-важен от подканата.
Споменатият по-горе обзор организира агентното структурирано анализиране в три слоя: основополагащ (планиране, използване на инструменти и търсене), саморазвиващ се (обратна връзка и памет) и колективен (координация между множество агенти).
По-дълбоката идея обаче е, че структурираното анализиране се превръща в организационен принцип за планиране, вземане на решения и проверка, а не служи само за генериране на правдоподобно логическо мислене. Това звучи абстрактно, докато не го съпоставите с промените в архитектурата си. Трябва да запомните три основни неща:
Добрият агент не трябва да приема извличането като нещо, което „винаги се прави“. То е решение, а не рефлекс.
Ето едно практично правило:
Ако системата ви извлича информация при всяка стъпка, не сте изградили извличане, а данък върху контекста.
Това се среща постоянно в реалната работа. Когато отстранявате производствен инцидент, не изсипвате всички регистрационни файлове в контекста, а според текущата си хипотеза решавате кои показатели и записи да извлечете след това. Това е „агентно извличане“. Ето по-конкретен модел:
Решете дали е необходимо извличане
Ако да: съставете заявка, извлечете, прегледайте и отделете важното
Ако доказателствата си противоречат: извлечете отново
Едва след това обобщете
Тук „агентният RAG“ започва да се различава от традиционния RAG: извличането става съзнателна стъпка от структурираното анализиране, а не стандартен етап на конвейера.
Щом спрете да оценявате „модел“ и започнете да оценявате „система“, проследяването на състоянието и действията става важно.
Едно нещо, което индустрията вече дефинира по-ясно, е наблюдаемостта на работните процеси с агенти. Например Agents SDK на OpenAI включва вградено проследяване и табло Traces, което записва изпълненията на агента (генерирания, извиквания на инструменти, предавания, предпазни механизми и персонализирани събития), за да можете да отстранявате грешки и да проверявате стъпка по стъпка какво се е случило.
Това не е просто „добре е да го има“. То отличава системата, в която можете да отстранявате грешки, от тази, която можете да проверявате само по усещане.
Според мен най-приложимата част от обзора е колко директно разглежда обратната връзка. Той разделя обратната връзка на три режима: рефлексивна обратна връзка (генериране → критика → преработване), параметрична адаптация (обучение чрез фина настройка/RL) и обратна връзка от валидатор (повторение до успешно валидиране).
Повечето екипи трябва да започнат с обратна връзка от валидатор, защото е скучна, но ефективна. Ако можете да напишете какъвто и да е валидатор, който изпълнява модулни тестове, проверява схема, налага бизнес правила/ограничения („без възстановяване на суми над X без ескалация“) или установява достоверност („изискват се цитати“), можете да превърнете недетерминирания изход от модела в нещо, на което действително да се доверите.
Една от промените, спадащи към „неизвестните неизвестни“, е проста: при агентите надеждността често идва повече от цикъла, отколкото от модела.
Ето най-краткия дисциплиниран цикъл, който според опита ми надеждно подобрява поведението без обучение:
Работете на стъпки: Планиране → Действие → Наблюдение → Актуализиране,
След всяко действие обобщавайте наблюдението в 1–3 точки,
Спрете, когато критериите за успех са изпълнени или бюджетът е изчерпан; върнете най-добрия известен резултат и оставащите неясноти.
Целта не е моделът да стане многословен. Целта е системата да стане разбираема и на всяка стъпка да бъде принуждавана да се „сверява с реалността“. Много близък до инженерната практика пример е привързването със затворен цикъл в стил CI:
Планиране: предложете списък с промени
Действие: изпълнете тестове/lint
Наблюдение: анализирайте неуспешните резултати
Актуализиране: приложете корекция и опитайте отново
Няколко въпроса, които обикновено разкриват случайно създадени агенти:
„Агентът ми избира ли какво да извлече, или винаги извличам информация?“
Ако извличането е безусловно, ще платите с по-голямо забавяне и разходи, размиване на контекста и по-висок риск от некачествени входни и изходни данни.
„Може ли агентът ми да разбере, че греши?“
Ако единственият сигнал за обратна връзка към агента е „потребителят се ядосва“, правите RL чрез човешко страдание. Цикълът с повторни опити, управляван от валидатор, е най-ясният начин агентът да се сверява с реалността.
„Може ли да се записва в паметта и подобрява ли се тя с времето?“
Ако вашата „памет“ просто добавя историята на чата, на практика записвате регистрационни файлове. Представянето на паметта в обзора е важно: тя се превръща в динамично разрастващ се контекст, който агентите усъвършенстват с времето, а не просто в стенограма.
Регистрационните файлове показват какво се е случило, а паметта — какво да направите следващия път. Историята на чата е стенограма. Паметта е развиваща се политика за това какво си струва да бъде запазено занапред.
Практично начало е малка таблица с „научени уроци“, организирана по ключ с типа задача, инструмента и начина на възникване на грешката и със стойност, описваща какво е проработило и какво да се избягва. Целта не е да изградите съвършен граф на знанията. Целта е да постигнете натрупващо се подобрение: паметта и обратната връзка превръщат агентите от „помощници без състояние“ в системи, които се усъвършенстват с времето.
Изкушаващо е да включите още агенти в решаването на проблема, но това често умножава разходите за координация. Добър модел за „минимално жизнеспособен екип“:
Координатор: разделя задачата и я възлага
Изпълнител: извиква инструменти и прави промени
Критик/оценител: проверява правилността и риска
Пазител на паметта: записва и подбира научените уроци
Ако не можете да обясните за какво отговаря всеки агент, вероятно още не са ви нужни множество агенти.
Ако наистина приемем промяната на парадигмата, вероятно ще спрем да тъпчем всичко в подкани, да третираме грешките като окончателни резултати и да оценяваме агентите като чатботове. И ще започнем да третираме агентите като това, което са: софтуерни системи, в които езикът е контролният слой, а надеждността идва от цикъла.
Преди да добавите още един модел, добавете още един цикъл за оценяване. Преди да извлечете всичко, направете извличането условно. Пуснете един валидатор, преди да пуснете десет. Третирайте паметта като решения на ниво политика, а не като база данни. А когато преминавате към множество агенти, започнете с два, а не с двадесет. Това не са правила, а модели, доказали се в реална среда.