Большинство команд, стремящихся повысить эффективность ИИ-агентов, используют одни и те же рычаги: увеличивают контекстные окна, добавляют документы и совершенствуют промпты. В этой статье утверждается, что такой подход в корне неверен. Не хватает не дополнительной информации. Не хватает управления. Именно грамотно спроектированный уровень управления отличает агента, работающего в демонстрации, от агента, работающего в производственной среде.
Увеличение памяти ИИ-агента, числа документов или контекстного окна не делает его умнее, а лишь замедляет и удорожает его работу. Настоящий эффект даёт способность агента выбирать, что и когда ему нужно, вместо того чтобы обрабатывать всё сразу.
Надёжность обеспечивает цикл, а не модель. Агент, впечатляющий на демонстрации, отличается от агента, надёжно работающего в производственной среде, не качеством ИИ, а способностью системы проверять собственную работу. Агенты, которые на каждом шаге планируют, действуют, наблюдают и проверяют, сами обнаруживают ошибки, а не уверенно выдают неверные результаты.
Сегодня большинство ИИ-агентов — по сути чат-боты с дополнительными шагами: у них нет механизма, позволяющего понять, движутся ли они верным путём, когда нужно остановиться или сменить подход. Полноценный уровень управления — чёткие критерии успеха, структурированное состояние и валидационные проверки — превращает нечто, лишь похожее на агента, в систему, которой действительно можно доверять.
Что вы ели вчера на обед?
Вряд ли вы перебирали все свои воспоминания, пока не дошли до сочетания «вчера + обед». Вы сразу обратились к той части опыта, где хранятся эти понятия. Это полезная модель мышления при создании агентов:
Огромное контекстное окно — не память.
Набор извлечённых документов — не понимание.
Длинная цепочка рассуждений (CoT) — не надёжность.
Это лишь компоненты. Но агент воспринимается как агент благодаря тому же, что позволяет мозгу не перебирать всю историю жизни: управлению.
В недавнем обзоре «Агентные рассуждения для больших языковых моделей» удачно обобщён и назван сдвиг, который многие из нас ощущали при разработке: от рассуждений внутри модели к рассуждениям через взаимодействие. Эта публикация — не пересказ той статьи. Это попытка воплотить данный сдвиг в практической архитектуре систем:
Если создавать агентов как чат-ботов с инструментами, вы будете сталкиваться с теми же сбоями, что и у чат-ботов, только ошибки станут дороже.
Долгое время стандартный рецепт «как сделать модель умнее» выглядел примерно так: улучшить промпты, добавить цепочку рассуждений (CoT), самосогласованность или улучшения на основе выборки и, возможно, поиск.
ReAct стал переломным моментом, потому что сделал последовательность «мысль → действие → наблюдение» естественной. Но обратите внимание на неявное ограничение: зачастую всё это сводится к «выводу с одним примером, но с большим числом токенов». В обзоре идея сформулирована точнее: агентные рассуждения предполагают масштабирование взаимодействия во время тестового вывода, превращая вывод в итеративный процесс, где модель, память и среда постоянно участвуют в цикле.
Если вы создавали или использовали агентов, которые впечатляют на демонстрациях, но оказываются ненадёжными в реальных процессах, эта статья для вас.
Опишу схему, которую я часто встречал и, безусловно, сам реализовывал в разных вариантах:
Взять хорошую чат-модель
Добавить несколько инструментов: поиск, запросы к БД и, возможно, выполнение кода
Добавить RAG
Добавить системный промпт «Ты — автономный агент»
Поместить всё это в цикл while до остановки или истечения времени
Поздравляем: вы получили нечто, похожее на агента. Но такая система обычно даёт сбои вполне предсказуемым образом:
Раздувание контекста: каждое наблюдение добавляется в конец, и промпты превращаются в археологические слои.
Беспорядочное использование инструментов: уверенный выбор не того инструмента становится типичным сбоем.
Нет условий остановки: агент продолжает работу, потому что может, а не потому что должен.
Нет дисциплины заземления: агент не замечает своей ошибки, если не заставить его её проверить.
Память = история чата: это всё равно что вести журналы и называть их обучением.
Поэтому «агенты» часто кажутся волшебными на демонстрациях, но создают хаос в производственной среде. Наш опыт внедрения агентных систем в производственную среду подтверждает это: когда вы оцениваете уже не модель, а систему, среди возможных проблем оказываются навигация, аккуратность использования инструментов, сокращение контекста и проектирование оценки, а не только ответ на вопрос «правильно ли ответила модель».
Тогда возникает вопрос: каким должен быть агент?
Чтобы перейти от абстракции к конкретике, рассмотрим простой и понятный рабочий процесс: «Забронируй мне на следующий вторник билет из Лондона в Нью-Йорк. Прибытие — до 18:00. Цена — не более 900 фунтов. Место у прохода».
Типичная реализация, внешне похожая на агента, выглядит так:
Сразу извлекает множество документов с правилами авиакомпаний и поездок, даже если они пока не нужны.
Вызывает инструмент поиска, вставляет в промпт длинный список результатов и «выбирает один».
Преждевременно оформляет бронирование, не проверив ограничения по времени прибытия, багажу, месту и правилам.
В случае неудачи повторяет попытку немного иначе, но не понимает, что изменилось и какой урок был извлечён.
Проблема не в неспособности модели рассуждать, а в том, что система не управляет рабочим процессом.
Более агентная версия рассматривает задачу как интерактивный процесс с явно заданным состоянием и проверками:
ПЛАНИРОВАНИЕ: повторить ограничения и перечислить недостающие сведения, например: «Какой аэропорт предпочтительнее?» или «Допустима одна пересадка?».
ДЕЙСТВИЕ: вызвать поиск авиабилетов со структурированным запросом: диапазоном дат, ограничением по времени прибытия и бюджетом.
НАБЛЮДЕНИЕ: сохранить результаты в компактном объекте состояния — пять лучших вариантов с ценой, временем прибытия и пересадками, — а не вставлять огромный массив данных.
ОБНОВЛЕНИЕ: уточнить запрос, если ограничения не соблюдены, например: «Прибытие до 18:00 — слишком строгое условие. Расширить временной диапазон или увеличить бюджет?».
ПРОВЕРКА: запустить валидаторы: «прибытие < 18:00», «цена ≤ 900 фунтов», «правила соблюдены», «выбор места доступен».
ОСТАНОВКА: только после того, как API бронирования вернёт подтверждение и будут пройдены все проверки.
Изменение кажется небольшим, но имеет решающее значение. Извлечение выполняется по необходимости, а не рефлекторно; контекст управляется — состояние структурируется, а не просто накапливается; проверка встроена в цикл, а не перекладывается на пользователя. Замените «бронирование авиабилета» на «создание заказа на закупку», «оформление возврата», «изменение производственной конфигурации» или «выпуск PR» — суть останется прежней: когда агент может действовать, цикл важнее промпта.
В упомянутом выше обзоре агентные рассуждения разделены на три уровня: базовый (планирование, использование инструментов, поиск), саморазвивающийся (обратная связь и память) и коллективный (координация нескольких агентов).
Но более глубокая идея такова: рассуждения становятся основным принципом организации планирования, принятия решений и проверки, а не просто способом создать правдоподобную цепочку рассуждений (CoT). Это звучит абстрактно, пока не сопоставишь идею с изменениями в архитектуре. Важно запомнить три основных положения:
Хороший агент не должен извлекать данные всегда. Извлечение — это решение, а не рефлекс.
Вот практическое правило:
Если система извлекает данные на каждом ходу, вы создали не механизм извлечения, а налог на контекст.
В реальной работе это встречается постоянно. При отладке производственного инцидента вы не загружаете в контекст все журналы, а на основе текущей гипотезы решаете, какие метрики и записи запросить дальше. Это и есть «агентное извлечение». Вот более конкретная схема:
Определить, нужно ли извлечение
Если да: составить запрос, получить данные, просмотреть и извлечь нужное
Если данные противоречат друг другу: выполнить извлечение снова
И только затем обобщить
Именно здесь «агентный RAG» начинает отличаться от традиционного RAG: извлечение становится осознанным этапом рассуждений, а не стадией конвейера по умолчанию.
Как только вы перестаёте оценивать «модель» и начинаете оценивать «систему», отслеживание состояния и трассировка приобретают значение.
Одна из вещей, о которых индустрия теперь говорит более предметно, — наблюдаемость рабочих процессов агентов. Например, в OpenAI Agents SDK встроены трассировка и панель Traces, где записываются запуски агентов: генерации, вызовы инструментов, передачи задач, защитные механизмы и пользовательские события. Это позволяет пошагово отлаживать и проверять произошедшее.
Это не просто «желательная возможность». Именно этим система, которую можно отладить, отличается от системы, которую можно оценить лишь по ощущениям.
На мой взгляд, самая практичная часть обзора — предельно ясное описание обратной связи. В нём выделены три режима: рефлексивная обратная связь (сгенерировать → оценить → исправить), параметрическая адаптация (обучение через дообучение или RL) и обратная связь на основе валидатора (повторять, пока проверка не будет пройдена).
Большинству команд стоит начать с обратной связи на основе валидатора: это скучно, зато эффективно. Если вы можете написать хоть какой-нибудь валидатор, который запускает модульные тесты, проверяет схему, применяет бизнес-правила и ограничения («возврат свыше X требует эскалации») или подтверждает достоверность («ссылки на источники обязательны»), то недетерминированный результат модели можно превратить в то, чему действительно можно доверять.
Один из неочевидных сдвигов здесь прост: в мире агентов надёжность часто больше зависит от цикла, чем от модели.
Вот самый простой цикл, который, по моему опыту, стабильно улучшает поведение без обучения:
Работайте по шагам: Планирование → Действие → Наблюдение → Обновление.
После каждого действия кратко излагайте результат наблюдения в 1–3 пунктах.
Останавливайтесь при выполнении критериев успеха или исчерпании бюджета; возвращайте лучший известный результат и список оставшихся неопределённостей.
Смысл не в том, чтобы заставить модель отвечать многословно. Смысл в том, чтобы сделать систему понятной и на каждом шаге заставлять её сверяться с реальностью. Хорошо знакомый инженерам пример — заземление с замкнутым циклом по принципу CI:
Планирование: предложить список изменений
Действие: запустить тесты и линтер
Наблюдение: разобрать ошибки
Обновление: внести исправления и повторить
Вот несколько вопросов, которые обычно выявляют непреднамеренные недостатки архитектуры агента:
«Мой агент сам решает, какие данные извлекать, или извлечение выполняется всегда?»
Безусловное извлечение увеличивает задержку и затраты, размывает контекст и повышает риск получить мусор на выходе из-за мусора на входе.
«Может ли мой агент заметить собственную ошибку?»
Если единственный сигнал обратной связи для агента — раздражение пользователя, вы занимаетесь обучением с подкреплением ценой человеческих страданий. Цикл повторных попыток с валидатором — самый простой способ заставить его свериться с реальностью.
«Можно ли записывать данные в память и улучшается ли она со временем?»
Если ваша «память» лишь пополняется историей чата, то на деле вы просто ведёте журналы. Важно, как память представлена в обзоре: это не просто стенограмма, а динамически растущий контекст, который агенты со временем уточняют.
Журналы сообщают, что произошло, а память — что делать в следующий раз. История чата — это стенограмма. Память — это развивающаяся политика в отношении того, что стоит сохранить на будущее.
Для начала подойдёт небольшая таблица «извлечённых уроков»: ключ составляют тип задачи, инструмент и вид сбоя, а значение описывает, что сработало и чего следует избегать. Цель не в том, чтобы построить идеальный граф знаний. Цель — добиться накопительного эффекта: сочетание памяти и обратной связи превращает агентов из «помощников без состояния» в системы, которые со временем совершенствуются.
Возникает соблазн привлечь больше агентов, но зачастую это лишь многократно увеличивает затраты на координацию. Хорошая схема «минимально жизнеспособной команды»:
Координатор: разбивает задачу на части и распределяет их
Исполнитель: вызывает инструменты и вносит изменения
Критик или оценщик: проверяет правильность и риски
Хранитель памяти: записывает и систематизирует извлечённые уроки
Если вы не можете объяснить зону ответственности каждого агента, скорее всего, несколько агентов вам пока не нужны.
Если мы действительно принимаем эту смену парадигмы, то перестаём помещать всё в промпты, считать сбои окончательными результатами и оценивать агентов как чат-ботов. Вместо этого мы начинаем воспринимать агентов такими, какие они есть: программными системами, где язык служит плоскостью управления, а надёжность обеспечивает цикл.
Прежде чем добавлять ещё одну модель, добавьте ещё один цикл оценки. Прежде чем извлекать всё подряд, сделайте извлечение условным. Сначала выпустите один валидатор, а не десять. Относитесь к памяти как к набору стратегических решений, а не как к базе данных. А переходя к мультиагентной системе, начните с двух агентов, а не с двадцати. Это не правила, а подходы, выдержавшие проверку в производственной среде.