Чем ИИ-агент отличается от LLM и RAG-системы
Обычная LLM отвечает за один проход: получила промпт, сгенерировала продолжение, остановилась. RAG — архитектурный подход, который соединяет LLM с доступом к внешним базам знаний, и схема остаётся однопроходной: собрать контекст, сгенерировать ответ, завершить работу. Агент работает в замкнутом цикле. Он воспринимает цель и историю предыдущих действий, рассуждает о следующем шаге, вызывает инструмент, наблюдает результат и снова возвращается к рассуждению. Цикл повторяется до достижения цели либо до исчерпания лимита итераций или денег на счёте.
Разница видна по одному вопросу: кто выбирает следующий шаг. В RAG маршрут задан кодом заранее, поиск всегда идёт до генерации, и найденный фрагмент не может изменить сценарий. В агенте маршрут выбирает модель на каждом шаге, а среда возвращает наблюдения, по которым модель корректирует стратегию. Отсюда два следствия: агент берётся за задачи, где последовательность действий неизвестна заранее, и агент может уйти не туда.
Автономность у него условная. Он выбирает среди разрешённых инструментов и остаётся в пределах лимитов расходов, прав и детерминированных проверок, которые выставила система вокруг него. Фраза «агент сам решил» почти всегда означает «модель выбрала один из вариантов, которые ей разрешили».
| Критерий | LLM | RAG-система | ИИ-агент |
|---|---|---|---|
| Число проходов | один | один на запрос плюс поиск по индексу | много, пока задача не сойдётся |
| Состояние | только окно контекста | контекст и найденные фрагменты | история шагов, записи памяти, чекпоинты |
| Вызов инструментов | нет | поиск в базе знаний | API, базы данных, браузер, исполнение кода |
| Стоимость | предсказуема | предсказуема, растёт с длиной контекста | растёт с числом итераций и объёмом истории |
| Маршрут решения | фиксирован промптом | фиксирован кодом | выбирается моделью на каждом шаге |
| Точка выхода | конец генерации | конец генерации | цель достигнута или сработал лимит |
Из таблицы видно, откуда берётся разница в счёте за API. Вопрос к RAG-ассистенту стоит примерно одинаково при каждом повторе. Тот же вопрос к агенту обойдётся заметно дороже, если модель решит перепроверить данные двумя инструментами и трижды перепланировать шаги.
Практический критерий простой. Система, которая извлекает документ и готовит черновик ответа, остаётся RAG-ассистентом, даже если пишет красиво. Агент начинается там, где система сама выбирает действия, вызывает инструменты, держит состояние и доводит результат за несколько шагов. Как такие системы встраиваются в рабочие процессы компаний, разобрано в материале об ИИ-агентах внутри компании.
Определения RAG и агентного цикла, а также сравнение парадигм рассуждения ниже опираются на разбор «От языка к действию: как устроены агентные ИИ-системы». Тезис о сдвиге от ПО, следующего заранее заданным шагам, к ПО, которое преследует утверждённую цель, и перечень компонентов корпоративного агента — на материал Agentic AI in Enterprise Automation.
Цикл работы ИИ-агента: от цели до результата
Один виток цикла раскладывается на повторяемые шаги, и почти любая агентная система реализует именно их.
- Цель и ограничения. Формулируется задача, доступные инструменты, бюджет итераций и список запретов.
- Сбор контекста. Подтягиваются инструкции, данные из баз и результаты прошлых шагов.
- Рассуждение. Модель решает, чего не хватает для ответа и какое действие приблизит к цели.
- Выбор инструмента и аргументов. Формируется вызов: какой API, какие параметры, что делать с ответом.
- Вызов и наблюдение. Система исполняет вызов и возвращает модели результат: данные, код ошибки, текст страницы.
- Обновление состояния. Наблюдение дописывается в историю, память или чекпоинт.
- Проверка. Модель или внешний валидатор решает, достигнута ли цель и не пора ли остановиться.
- Повтор или выход. Цикл возвращается к шагу 3 либо завершается результатом, ошибкой или эскалацией к человеку.
Типичный корпоративный агент собирается из восьми частей: фундаментальная модель; определение цели и задачи; доступ к корпоративным знаниям и актуальным бизнес-данным; инструменты вроде API, баз данных, поиска, браузера и исполнения кода; оркестрационный цикл с планированием, повторами и передачами; политики, ограничители и точки одобрения; мониторинг, оценка и записи аудита; путь эскалации к человеку. Если из списка выпадает половина, получается либо чат-бот с доступом к поиску, либо опасный автомат с правами на запись.
Смысл агентного подхода в бизнесе описывают как сдвиг от ПО, которое повторяет каждый заранее заданный шаг, к ПО, которое преследует утверждённую цель: интерпретирует запрос, извлекает контекст, выбирает среди авторизованных инструментов, вызывает API, проверяет результат и передаёт исключения человеку. Выигрыш считается по результату, а не по числу реплик: закрыть обращение клиента вместо ответа на вопрос, выполнить низкорисковый запрос доступа вместо создания тикета, разобрать исключение по счёту вместо демонстрации его статуса.
Наличие естественно-языкового интерфейса не доказывает автоматизацию. Диалог может закончиться потому, что клиент ушёл, а не потому, что проблема решена.
Пример из практики задержек доставки. На запрос «где мой заказ» чат-бот генерирует вежливый текст. Агент идёт в CRM, вытаскивает просроченные заказы, сверяет статус у перевозчика, готовит письмо с конкретными датами, отправляет его через почтовый API, обновляет статус в базе и в конце проверяет, что все заказы обработаны. На этом цикле видно, почему нужны лимиты: сверка может упасть на таймауте, модель может уйти в повторные проверки, а каждый виток стоит токенов. Лимит итераций, потолок бюджета и предел по времени ставят не из осторожности, а потому что расходящийся цикл иначе не остановится.
Планирование и рассуждение в ИИ-агентах: CoT, ToT, ReAct, Reflexion, LATS
Парадигмы рассуждения отличаются тем, сколько вычислений они тратят на один шаг и насколько устойчивы к накоплению ошибок. Сравнение по этим осям полезнее, чем список названий.
| Парадигма | Механика | Цена | Слабое место | Когда брать |
|---|---|---|---|---|
| Chain-of-Thought | модель показывает промежуточные шаги | низкая, один проход | ошибка в середине цепочки тянет за собой остальные | математика, логика, разбор условий |
| Tree-of-Thought | рассуждение ветвится, есть возврат и отсечение | высокая: несколько ветвей на шаг | заметный рост вычислений и задержки | задачи поиска с проверяемым результатом |
| ReAct | чередование мысли, действия и наблюдения | средняя, зависит от числа витков | зацикливание на неудачных действиях | работа с инструментами и внешней средой |
| Reflexion | языковая саморефлексия: агент записывает выводы прошлых попыток | средняя плюс хранение заметок | риск закрепления неверного вывода | повторяемые задачи с правом на переделку |
| LATS | поиск по дереву Монте-Карло поверх рассуждений и действий | высокая: много проб и оценок | сложность настройки и цена прогона | задачи с дешёвой симуляцией и дорогой ошибкой |
Chain-of-Thought полезна для математики и логических задач, но ошибки в длинной цепочке накапливаются. Tree-of-Thought разворачивает рассуждение в дерево ветвей с возвратом и отсечением и потому надёжнее на задачах поиска, однако платить приходится вычислениями. Наиболее практичной для агентов остаётся ReAct: цикл «мысль — действие — наблюдение» повторяется, и агент корректирует стратегию по обратной связи от среды. Reflexion добавляет к этому механизм языковой саморефлексии, когда агент записывает результаты попыток и опирается на них дальше. LATS переносит на рассуждения идею поиска по дереву Монте-Карло: варианты пробуются, оцениваются и отбираются, что даёт качество на сложных задачах и высокий счёт за прогон.
Отдельная ветка — гибрид LLM с классическими планировщиками через PDDL. Формальное описание домена и целей даёт планировщику проверяемый план, а модель занимается переводами между человеческой постановкой и формальным языком. Такой вариант уместен, когда важнее воспроизводимость и доказуемость плана, чем гибкость. Цена — работа по описанию домена и потеря устойчивости на задачах, которые плохо формализуются.
По LATS и гибридам с PDDL в разобранных источниках нет сравнительных замеров, поэтому воспринимать их стоит как описания подходов, а не как подтверждённые цифры выигрыша. Описание CoT, ToT, ReAct и Reflexion приведено по материалу «От языка к действию».
Инструменты агента: Toolformer, описания и исполнение кода
Подход Toolformer строится на самосупервизии: модель учится сама решать, какой API вызвать, в какой момент и с какими аргументами, а обучающий сигнал берётся из того, помогает ли вызов предсказывать последующий текст. Для практики важен вывод, а не детали обучения: выбор инструмента — навык, который можно натренировать и, что дешевле, аккуратно ограничить.
Ключевой фактор точности — количество и качество описаний инструментов. Чем больше инструментов и чем расплывчатее описания, тем ниже точность выбора: модель путает похожие функции, подставляет аргументы из соседней схемы, вызывает инструмент там, где хватило бы ответа из контекста.
- Держите узкий набор инструментов под конкретную задачу, а не общий каталог «на всё».
- Описывайте параметры явно: тип, допустимые значения, единицы измерения, что делать при пустом значении.
- Давайте по одному-два примера вызова на инструмент, включая пример ошибки.
- Разграничивайте зоны ответственности: два инструмента не должны решать одну задачу с разными названиями.
- Проверяйте выбор на наборе типовых запросов и смотрите, где модель ошибается систематически.
Исполнение кода работает как универсальный инструмент: вместо десяти узких API агент получает среду, где сам пишет преобразование, парсинг или расчёт. Гибкость здесь максимальная, и риск тоже: код исполняется на реальной машине. Отсюда обязательные спутники — изоляция, лимиты по времени и памяти, ограничение файловой системы и проверка результата внешним валидатором. Описания инструментов относятся к архитектуре, а не к косметике промпта: от них зависит, сколько витков сделает агент и сколько токенов сожжёт.
Мультиагентные фреймворки: AutoGen, CrewAI и LangGraph
Публичных замеров AutoGen, CrewAI и LangGraph на одной и той же задаче обработки неструктурированных данных в разобранных источниках нет. Сравнивать разумно по устройству и по тому, откуда берутся токены и задержка; конкретные значения сильно зависят от задачи, модели и длины промптов.
Затраты растут по понятной причине. Каждый обмен между агентами — это дополнительные токены и сетевой вызов. Задержка складывается из последовательных шагов, и десять коротких реплик ждутся дольше, чем один большой ответ. История усиливает эффект: если каждый запрос отправляет все предыдущие сообщения, десятое сообщение может обойтись в несколько раз дороже первого, поэтому историю полезно суммаризировать или хранить факты отдельно и подмешивать только релевантный контекст.
| Фреймворк | Вокруг чего строится | Что даёт | Чем платите |
|---|---|---|---|
| AutoGen | диалог агентов | гибкие сценарии переписки между ролями, легко добавить участника | переписка разрастается, каждый обмен — токены и вызов |
| CrewAI | роли и задачи команды | понятная декомпозиция: роли, задачи, порядок выполнения | лишние передачи между ролями, если задачи не пересекаются |
| LangGraph | явный граф состояний | контроль ветвлений и циклов, чекпоинты, восстановление после сбоя | нужно самим проектировать граф и следить за размером состояния |
Рамка выбора проста и неудобна для любителей сложных схем. Один агент с хорошими инструментами чаще дешевле, быстрее и предсказуемее команды. Мультиагентность оправдана, когда подзадачи реально распараллеливаются или требуют разных ролей и независимых проверок: один собирает данные, второй проверяет, третий пишет итог. Когда все шаги жмутся последовательно, координация добавляет накладные расходы без выигрыша в качестве.
Для бюджета полезна метрика «стоимость качественно решённой задачи». Модель с низкой ценой за 1 млн токенов может чаще ошибаться, требовать повторного запроса или генерировать больше текста, и в итоге успешная операция выйдет дороже. Считать удобно на конкретных числах: при 100 ₽ за 1 млн входных и 500 ₽ за 1 млн выходных токенов запрос на 20 000 входных и 2 000 выходных токенов стоит 20 000 / 1 000 000 × 100 + 2 000 / 1 000 000 × 500 = 3 ₽. Дальше умножайте на число витков агента. Тарифы меняются, каталог цен стоит перепроверять перед расчётом; привычка логировать input и output по каждой операции, задавать бюджет на проект и ограничивать max_tokens экономит больше, чем выбор модели. Логика расчёта и рекомендации по контролю расхода токенов приведены по материалу о стоимости токенов нейросетей.
Память и персистентность агентных систем
Память агента делится на три уровня, и путать их дорого.
- Рабочая память: история шагов в контексте текущей задачи. Быстро, но каждый виток удорожает следующий запрос.
- Долговременная память: векторное хранилище с прошлыми наблюдениями, документами и выводами. Ищется по похожести, легко засоряется мусором.
- Структурная память: граф знаний с сущностями и связями. Даёт точные факты и переходы по связям, требует поддержки схемы.
Checkpointing в LangGraph сохраняет состояние графа после узла, поэтому выполнение можно продолжить с места сбоя, а не с начала, и разобрать по шагам, где агент свернул не туда. Рефлексии в Reflexion работают как память другого типа: записанные выводы прошлых попыток подставляются в следующие, и агент не повторяет ту же ошибку на второй итерации.
Гибридные схемы соединяют оба подхода: векторное хранилище отвечает за поиск похожего, граф знаний — за связи и факты, которые нельзя восстановить по сходству текста. Цена такой памяти в том, что она увеличивает контекст, а значит токены и задержку. Нужна стратегия забывания: что суммаризировать, что хранить как факт, что удалять после закрытия задачи. Как это выглядит в самописном агенте с оркестрацией, обработкой ошибок и метриками, разобрано в материале про архитектуру AI-агента с нуля.
Безопасность агентных систем: изоляция, ограничения и верификация
Главный риск формулируется без смягчений: вероятностному ПО выдали слишком много полномочий без чёткой идентичности, разрешений, доказательств и подотчётности. Отсюда набор мер, которые ставятся на уровне оркестрации, а не в промпте.
- Песочница для исполнения кода: отдельный контейнер, лимиты CPU и памяти, только нужные файлы на чтение.
- Ограничение сетевого доступа: белый список доменов и API, запрет произвольных исходящих запросов.
- Белые списки инструментов и прав: агент видит ровно те операции, которые ему разрешены, и не видит остальные.
- Точки одобрения человеком для действий с побочными эффектами: платежи, удаление, отправка писем клиентам.
- Верификация через внешние оракулы: test runner, linter и аналогичные проверки дают объективный сигнал «прошло/не прошло» вместо отчёта агента о своей работе.
- Мониторинг, оценка и записи аудита как обязательный слой: по логам видно, какой инструмент вызывался и с какими аргументами.
- Путь эскалации к человеку: если проверка не прошла дважды, задача уходит оператору, а не крутится дальше.
Детерминированные проверки полезны тем, что не зависят от настроения модели. Linter не согласится с «код выглядит корректно», тест упадёт независимо от уверенности агента в успехе. Замеров того, насколько именно такие проверки снижают долю опасных действий, в разобранных источниках нет, и обещать проценты по этому пункту не стоит.
Проектирование среды для агента, где границы, стимулы и отбор заданы заранее, а результат принимается по проверкам, разобрано отдельно: средовой подход к ИИ-агентам.
Когда агент оправдан: практические выводы
Чек-лист перед запуском. Если на большинство пунктов отвечаете «нет», хватит RAG-ассистента.
- Задача требует нескольких шагов и внешних действий, а не одного ответа по документам.
- Есть проверяемый критерий результата: тесты, сверка с базой, статус из API, подтверждение от человека.
- Полномочия можно урезать до конкретного набора инструментов, а бюджет и число итераций ограничить.
- Рост токенов и задержки приемлем для сценария: минута ожидания в порядке вещей или уже нет.
- Есть кому эскалировать и кто разбирает инциденты по логам.
- Цена ошибки известна и не требует невозвратных действий без подтверждения.
Для локальных ИИ-агентов ограничения чувствительнее: стоимость токенов заменяется временем GPU и пропускной способностью, а локальная модель на 7–14 млрд параметров обычно слабее в выборе инструментов. Помогает сужение: маленький набор функций, жёсткие схемы параметров, простые задачи и явные проверки. Если процесс редкий и разный от запуска к запуску, дорогая агентная обвязка не окупится.
Полезно помнить, что польза появляется не там, где планировали. Публичный кейс ИИ-агента для разработки показывает обратное: боевые задачи агент провалил, зато закрыл более 50% исследовательских запросов аналитиков. Вывод для планирования один: сначала измеряйте, где агент реально снимает работу.
| Термин | Что означает на практике |
|---|---|
| LLM | языковая модель, генерирующая текст; сама по себе не действует во внешней среде |
| RAG | подмешивание найденных фрагментов из внешней базы в контекст перед генерацией, один проход |
| Tools | инструменты агента: API, базы данных, поиск, браузер, исполнение кода |
| Оркестрационный цикл | код, который планирует шаги, повторяет вызовы, обрабатывает ошибки и передаёт управление |
| Guardrails | политики и ограничители: разрешения, белые списки, точки одобрения |
| Checkpointing | сохранение состояния агента после шага, чтобы продолжить работу и восстановиться после сбоя |
| Эскалация | передача задачи человеку, когда проверки не проходят или риск слишком высок |
Агент — инженерная система с ценой ошибки, а не магия. Считайте итерации, ограничивайте инструменты, ставьте проверки и начинайте с процесса, где результат можно измерить в деньгах или часах работы человека.