От языка к действию: как устроены агентные ИИ‑системы

Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги.

Получившие широкое распространение в последние годы технологии искусственного интеллекта состоят из множества различных направлений, которые могут пересекаться друг с другом или существенно отличаться.

Сегодня мы попробуем разобраться в том, чем агент принципиально отличается от большой языковой модели (LLM).

Для начала давайте посмотрим, что собой представляет LLM или RAG‑система.

RAG (Retrieval‑Augmented Generation) — это архитектурный подход в области искусственного интеллекта, который соединяет возможности большой языковой модели с доступом к внешним базам знаний.

Обычная RAG‑система обрабатывает запрос за один проход: получая данные на вход, она собирает контекст, генерирует ответ и затем завершает работу.

Однако при выполнении практических задач такого подхода, как правило, недостаточно, и здесь на сцену выходит ИИ‑агент.

Он работает уже в замкнутом цикле:

1. Воспринимает не только цель, но и историю предыдущих действий.

2. Рассуждает о следующем действии.

3. Вызывает необходимые инструменты.

4. Наблюдает полученный результат.

5. Снова возвращается к рассуждению.

Эти действия он будет циклично повторять вплоть до достижения цели или исчерпания денег на счёте, лимита итераций.

Это различие даёт нам фундаментальный скачок возможностей.

Так, в классическом сравнении с задачей «уведомить клиента о задержке» чат‑бот лишь генерирует текст письма, тогда как агент самостоятельно:

• запрашивает в CRM просроченные заказы;

• формирует для каждого письмо с конкретными датами;

• отправляет их через почтовый API;

• обновляет статус в базе;

• в конце проверяет, что все заказы обработаны.

В этом и заключается суть агентного ИИ: превращение языкового понимания в исполнимую и проверяемую цепочку действий.

Эволюция алгоритмов рассуждения и планирования

Итак, разобравшись с базовыми отличиями, давайте теперь поговорим об эволюции алгоритмов.

Представленная способность агента «думать» опирается на несколько парадигм рассуждения.

Базовой здесь является Chain‑of‑Thought (CoT), в которой говорится, что модель обязана показывать промежуточные шаги. Это полезно для математики и логических задач, но при этом ошибки в длинной цепочке накапливаются.

Но наиболее практичной остаётся парадигма ReAct, в которой рассуждение и действие чередуются.

Цикл «мысль → действие → наблюдение» повторяется, позволяя агенту динамически корректировать стратегию по обратной связи от среды.

В свою очередь, Reflexion добавляет механизм языковой саморефлексии, когда агент записывает собственные неудачи в память и учитывает их в последующих попытках.

На первом этапе агент генерирует первоначальный ответ, далее он проверяется на корректность, и затем ревизор создаёт вербальную критику для следующей итерации.

Библиотека reflexion-agent формализует этот цикл через функции solve и evaluate: пользователь определяет обе функции, а агент сам управляет итерациями до успеха или, опять‑таки, до исчерпания максимального числа попыток.

Наиболее мощной парадигмой на сегодня остаётся LATS (Language Agent Tree Search), опубликованная на ICML 2024.

LATS применяет алгоритм поиска по дереву Монте‑Карло (MCTS) к агентам LLM, достигая эффективности 92,7% pass@1 на HumanEval с GPT-4.

Такой результат представляет собой качественный скачок относительно ReAct, который на той же модели показывал около 80%.

Здесь ключевой архитектурной идеей является разделение генератора действий и оценщика ценности на отдельные роли.

Так, генератор предлагает k альтернативных действий, а оценщик независимо оценивает перспективность состояния, чтобы оценка не «рационализировалась» самим генератором.

Пакет smolagents-lats предоставляет готовую реализацию с параметрами:

• n_branches — количество кандидатов на шаг, по умолчанию 3;

• max_depth — глубина дерева, по умолчанию 4;

• exploration_weight — константа UCT, по умолчанию 1.4.

Для решения задач кодинга с верифицируемыми результатами (тесты проходят/не проходят) LATS использует внешнюю среду как источник правды о награде: test runner, linter, type checker возвращают объективную оценку, которая затем распространяется обратно по дереву.

Однако здесь есть и более амбициозное направление — это гибрид LLM с классическими планировщиками.

В рамках LLM+P модель переводит задачу с естественного языка в формализованное описание на PDDL, передаёт его решателю вроде Fast Downward, а затем переводит результат обратно на естественный язык.

Такая комбинация использует языковое понимание LLM, сохраняя полноту и гарантии оптимальности классического планировщика.

Использование инструментов как усилитель возможностей агента

Использование инструментов является наиболее заметной чертой, отличающей агентный ИИ от традиционных LLM.

Через интерфейсы вызова функций агент получает доступ к поисковикам, исполнению кода, файловой системе и внешним API.

Так, исследование Toolformer (Schick et al., NeurIPS 2023) показало, что LLM способна обучиться использованию инструментов с самосупервизией.

Этот процесс состоит из трёх этапов:

1. Генерация кандидатов. На первом этапе модель генерирует кандидатов вызовов API в тексте. Например, для предложения «Pittsburgh is known as the Steel City» модель порождает варианты вроде:

   [QA("What other name is Pittsburgh known by?")]

2. Исполнение вызова. На втором этапе каждый вызов исполняется внешним API, и результат подставляется обратно.

3. Фильтрация. На третьем этапе мы производим фильтрацию, когда вызов сохраняется, только если его результат снижает перплексию (насколько хорошо модель предсказывает данные) следующего токена.

При этом формально полезность вычисляется как:

min(L_no_api, L_non_executed) - L_executed

Для предложения о Питтсбурге полезность составила 1.3, то есть исполненный вызов QA помог модели лучше предсказать продолжение текста.

Обученная на таких данных GPT‑J 6B показала производительность, сопоставимую с GPT-3 175B, в задачах фактического дополнения и математических вычислений.

Этот результат имеет прямое следствие для современных систем, так как использование инструментов возникает при масштабировании.

Меньшие модели страдают от аннотаций инструментов, большие, наоборот, выигрывают.

Именно поэтому frontier‑модели 2026 года имеют встроенное надёжное использование инструментов, тогда как большинство 7B‑моделей нуждаются в явном дообучении для надёжных вызовов.

Качество проектирования интерфейсов инструментов сильно влияет на производительность.

Так, при слишком большом числе инструментов точность выбора у модели падает; при размытых описаниях схем параметров агент может выбрать не тот инструмент или построить невалидные аргументы.

При этом исполнение кода представляет собой особый, сильный инструмент, теоретически способный заменить множество специализированных средств, а работа Code as Policies доказывает, что представление действий через код обладает хорошей обобщающей способностью в задачах планирования манипуляций роботами.

Мультиагентные системы как разделение труда, кооперация и эмерджентное поведение

У мультиагентной архитектуры есть своя интуиция, которая заключается в том, что вместо выполнения всей задачи одним агентом несколько специализированных агентов работают по своим ролям.

Так, AutoGen предоставляет слой абстракции для определения ролей агентов, протоколов коммуникации и оркестрации задач.

Например, координатор:

1. Получает высокоуровневую задачу.

2. Декомпозирует её на подзадачи.

3. Делегирует специализированным агентам.

4. Синтезирует итоговый результат.

В CrewAI кооперация встроена в абстракцию через флаг allow_delegation=True.

Когда он включён, агент автоматически получает два инструмента:

• Delegate work to coworker — передать задачу коллеге с указанием контекста;

• Ask question to coworker — задать уточняющий вопрос.

Роли агентов определяются через role, goal и backstory; например, researcher ищет информацию, writer создаёт контент, editor проверяет качество.

В примере с написанием статьи о будущем ИИ в здравоохранении writer ведёт задачу, но может делегировать исследование researcher‘у, а editor получает черновик как контекст через параметр context=[writing_task].

Для выявления заметных различий в поведении фреймворков можно использовать эмпирические бенчмарки.

В тесте AIMultiple на задаче обработки неструктурированных данных AutoGen продемонстрировал наивысшую эффективность.

Так, при обработке четырёх независимых колонок JSON модель сгенерировала один ответ с четырьмя параллельными вызовами инструментов, завершив задачу за 3 хода LLM, 8 170 промпт‑токенов и медианную задержку 47 секунд.

LangGraph на той же задаче показал 9 150 токенов и 70 секунд, причём число вызовов инструментов варьировалось от 6 до 16 из‑за склонности к повторному выполнению уже завершённых шагов.

LangChain с последовательным AgentExecutor сделал 4 вызова инструментов за 4 отдельных хода LLM, затратив 10 070 токенов и 86 секунд — прямое измерение стоимости последовательного выполнения против параллельного.

Для наглядности результаты можно представить в таблице:

В денежном выражении при ценах GPT-4o ($2.50/M входных, $10.00/M выходных токенов) и 1 000 задач в день разница составляет:

• LangGraph (оптимизированный) — ~$12–18/день;

• CrewAI — ~$18–28/день;

• AutoGen — ~$25–40/день.

Так, если команда запускает 10 000 агентных задач в день, разница между фреймворками может достигать $47 000–$80 000 в год.

Архитектура памяти и персистентности

Память определяет способность агента сохранять согласованность в долгосрочных задачах.

Текущие системы в основном полагаются на краткосрочный диалоговый контекст и векторный поиск, что явно недостаточно для сложных сценариев.

LangGraph использует механизм контрольных точек (checkpointing) для персистентности состояния между сессиями.

Пакет langgraph-checkpoint-aws предоставляет AgentCoreMemorySaver, который сохраняет состояние графа для комбинаций actor_id/session_id, позволяя агенту возобновлять работу после сбоя.

В свою очередь, пакет checkpnt решает проблему, поднятую в issue #5790 LangGraph: команда langgraph dev намеренно заменяет настроенный checkpointer на in‑memory хранилище, вынуждая разработчиков использовать LangGraph Platform.

Checkpnt предлагает drop‑in замену через CheckpntSaver.from_sqlite(), сохраняя состояние на диск без привязки к платформе.

Операции включают:

• save — сохранение;

• restore — восстановление;

• handoff — передача состояния между агентами с сохранением цепочки родителей;

• timeline — полная история выполнения;

• expire — автоматическое удаление по TTL.

Фреймворк Microsoft Agent Framework предоставляет встроенную поддержку checkpointing через FileCheckpointStorage.

Состояние executor’ов сохраняется через ctx.set_executor_state(), кросс‑executor состояние — через ctx.set_state().

В отличие от AutoGen, где механизмы persistence приходится реализовывать внешне, Agent Framework создаёт контрольные точки автоматически при каждом запуске workflow.

Reflexion‑подход к памяти принципиально иной, так как здесь вместо сохранения полного состояния агент накапливает вербальные рефлексии о неудачах.

Библиотека reflexion-agent хранит рефлексии по task_id и извлекает релевантные при следующей попытке, форматируя их для включения в промпт.

Это, с одной стороны, компактнее полного состояния, но, с другой, оно менее детерминировано.

Практическое направление представляет собой гибридную иерархию памяти, когда мы используем:

• векторное хранилище для крупномасштабного архивирования;

• граф знаний для символического вывода;

• модуль внимания для динамической приоритизации.

В мультиагентных средах распределение значимых фактов через gossip‑протокол может снизить сложность выборки на агента.

Безопасность и контроль

Расширение возможностей действий агента означает и расширение поверхности атаки.

И здесь ключевым является принцип изоляции, когда мы можем запускать агентов в песочнице, ограничивая их возможность подключения к локальным и сетевым ресурсам.

Конкретные меры могут включать в себя:

• запрет всего входящего и исходящего сетевого трафика по умолчанию с последующим открытием только необходимых соединений через списки доступа на межсетевом экране;

• сегментирование среды выполнения агента, инфраструктуры вывода и песочницы выполнения команд;

• ограничение доступа к учётным данным и данным.

AutoGen и CrewAI предоставляют встроенные механизмы code execution config с указанием рабочей директории, но изоляция процессов остаётся ответственностью разработчика.

Вторым уровнем защиты является верификация действий.

Для этого LATS использует внешние оракулы (test runner, linter) как источник объективной обратной связи, что одновременно служит механизмом контроля, так как агент не может «убедить себя» в успехе, если тесты не проходят.

Для задач без формальной верификации остаётся LLM‑as‑judge с калиброванной шкалой оценки.

Итог

В этой статье мы рассмотрели агентные системы, поговорив о том, что они собой представляют, какие технологии входят в их состав и какие перспективы развития нас ожидают.

Также мы сделали небольшое сравнение различных решений и поговорили о том, как обеспечивать безопасность агентских систем.

В целом важно понимать, что без агентов сейчас невозможно представить ни одну более‑менее серьёзную систему, использующую ИИ.

Данные технологии прочно вошли в нашу жизнь и в дальнейшем будут использоваться ещё активнее.

Понимать, как устроены ИИ‑агенты, — одно. Совсем другое — собрать систему, которая не просто генерирует ответы, а самостоятельно выполняет задачи, использует инструменты и взаимодействует с другими агентами. Чтобы перейти от теории к практике, важно разобраться в архитектуре таких решений и научиться выстраивать совместную работу агентов.

На бесплатных уроках OTUS разберём, как это реализовать:

• 28 октября в 18:00. «ИИ‑агенты на основе LLM и мультиагентные системы». Записаться.

• 23 ноября в 20:00. «Команда ИИ‑агентов в разработке Python‑проекта: как организовать совместную работу специализированных агентов». Записаться.

Ещё больше практических тем об искусственном интеллекте, разработке и современных технологиях — в календаре мероприятий.