Если вы хоть раз просили ChatGPT что‑то сделать и получали в ответ длинный текст без какого‑либо реального действия — вы работали с обычной языковой моделью. Она умеет генерировать текст, но сама ничего не делает: не лезет в интернет, не запускает код, не сохраняет файлы. Просто отвечает.
LLM‑агент — это другая история. Это система, которая получает задачу и начинает её решать: ищет информацию, пишет и запускает код, вызывает API, сохраняет результаты. Она не просто говорит «вот как это можно сделать» — она берёт и делает.
В этой статье разберём, как такие системы устроены изнутри: из каких компонентов состоят, как принимают решения, какие инструменты используют и где обычно ломаются.
Чем агент отличается от обычного чат‑бота
Хороший способ понять разницу — аналогия с сотрудником.
Представьте, что вы наняли консультанта. Один вариант: вы задаёте ему вопрос, он думает и даёт развёрнутый совет. Всё. На этом его работа заканчивается. Второй вариант: вы ставите ему задачу, он сам разбирается как её решить, звонит нужным людям, собирает данные, пишет отчёт и кладёт вам на стол готовый результат.
Первый — это языковая модель. Второй — агент.
Технически разница в том, что агент работает в цикле. Он не просто генерирует один ответ и останавливается — он последовательно рассуждает, вызывает инструменты, получает результаты, снова рассуждает, снова вызывает инструменты — и так до тех пор, пока задача не будет выполнена или агент не решит, что зашёл в тупик.
Из чего состоит агент: четыре компонента
Любой LLM‑агент, независимо от фреймворка и задачи, строится на четырёх базовых элементах.
Языковая модель — ядро системы. Это мозг агента. Именно модель читает задачу, рассуждает о том, что нужно сделать, решает какой инструмент вызвать и формулирует финальный ответ. Всё остальное — это обвязка вокруг неё.
Важный момент: качество агента сильно зависит от качества модели в основе. Слабая модель будет плохо рассуждать, выбирать неправильные инструменты и застревать в петлях. Поэтому для серьёзных агентов обычно берут самые мощные доступные модели, а не самые дешёвые.
Память — как агент помнит контекст. У агента есть несколько «слоёв» памяти. Самый очевидный — это контекстное окно модели: всё, что сейчас находится в промпте. Это краткосрочная память — она сбрасывается при каждом новом запуске.
Но кроме этого агент может работать с внешней памятью: векторными базами данных, файлами, обычными реляционными БД. Туда он сохраняет информацию между сессиями — факты, которые узнал, результаты прошлых задач, инструкции, которые нужно помнить всегда.
Инструменты — руки агента. Именно инструменты делают агента агентом, а не просто умным чат‑ботом. Инструмент — это любая функция, которую модель может вызвать: поиск в интернете, запуск Python‑кода, обращение к базе данных, отправка HTTP‑запроса, работа с файловой системой.
Модель не исполняет инструменты сама — она только говорит «хочу вызвать такой‑то инструмент с такими‑то параметрами», а уже среда исполнения запускает реальный код и возвращает результат обратно в контекст.
Среда исполнения — оркестратор всего. Это то, что связывает все компоненты вместе: принимает задачу, запускает цикл работы агента, вызывает инструменты по команде модели, управляет памятью, следит за тем чтобы агент не ушёл в бесконечную петлю. В коде это обычно реализуется через фреймворки — LangGraph, CrewAI, AutoGen — или пишется вручную.
Как агент думает: цикл Observe — Think — Act
Сердце любого агента — это петля обратной связи. Агент не просто линейно выполняет шаги — он постоянно наблюдает за ситуацией, принимает решение о следующем действии, выполняет его, смотрит на результат и снова принимает решение.
Самый популярный паттерн называется ReAct — от слов Reasoning и Acting. Выглядит это примерно так:
Агент получает задачу: «Найди последние новости про релиз GPT-5 и напиши краткое резюме на русском.»
Дальше начинается цикл:
-
Шаг 1 — рассуждение. Агент думает: «Мне нужно найти новости про GPT-5. У меня есть инструмент поиска. Вызову его с запросом ‘GPT-5 release news’.»
-
Шаг 2 — действие. Агент вызывает инструмент поиска. Реальный код делает запрос к поисковику и возвращает список статей.
-
Шаг 3 — наблюдение. Агент читает результаты: «Окей, вот три статьи. В первой написано, что релиз был в мае. Во второй — основные возможности. Мне этого достаточно для резюме.»
-
Шаг 4 — снова рассуждение. «У меня есть достаточно информации. Теперь напишу резюме на русском.»
-
Шаг 5 — финальный ответ. Агент формирует ответ и останавливается.
Если бы информации не хватило — агент сделал бы ещё один поисковый запрос, потом ещё один, и так до тех пор пока не получит что нужно, или пока не достигнет лимита шагов.
Один из ключевых вопросов при проектировании агентов — откуда он знает, что задача выполнена? Обычно это либо явная проверка («все пункты задания закрыты»), либо модель сама решает что дальше делать нечего, либо внешний лимит на количество итераций.
Если хочешь сам почувствовать как разные модели рассуждают — попробуй этого телеграм‑бота. Внутри ChatGPT, Gemini, Grok и DeepSeek, бесплатно и с ответами в реальном времени. Интересно давать одинаковый запрос разным моделям и смотреть как они по‑разному выстраивают логику.
Инструменты: что даём агенту в руки
Набор инструментов определяет, что агент вообще может делать. Давайте пройдёмся по основным категориям.
Поиск информации. Это может быть веб‑поиск, поиск по внутренним документам через векторную базу данных, SQL‑запросы к реляционным данным. Поиск — один из самых частых инструментов, потому что большинство задач требуют каких‑то данных которых у агента нет в голове.
Исполнение кода. Агент пишет Python‑код и тут же его запускает. Это мощнейший инструмент: с его помощью можно делать вычисления, обрабатывать данные, строить графики, работать с файлами. Именно code execution делает агентов полезными для аналитических задач.
Работа с файлами и базами данных. Читать и писать файлы, делать запросы к БД, работать с таблицами. Нужно для задач где есть реальные данные компании.
Внешние API. Отправить письмо, создать задачу в Jira, получить погоду, запросить данные из CRM — всё что доступно через HTTP‑запросы.
Браузер. Агент управляет браузером как человек: кликает на кнопки, заполняет формы, скролит страницы. Используется там, где нет API, но нужно взаимодействовать с веб‑интерфейсом.
Есть одна деталь, которую часто недооценивают: то, как вы описываете инструмент, напрямую влияет на то, будет ли агент им правильно пользоваться. Описание инструмента — это фактически документация для модели. Если написать расплывчато, агент будет вызывать инструмент невпопад или передавать неправильные параметры.
Хорошее описание инструмента отвечает на три вопроса: что этот инструмент делает, когда его нужно использовать, и какие параметры он принимает. Плохое описание — это просто название функции без контекста.
Фреймворки: что использовать на практике
Писать агента с нуля можно, но обычно не нужно. Вот основные фреймворки которые сейчас используют в продакшне.
LangGraph — пожалуй, самый популярный выбор для серьёзных проектов. Агент описывается как граф состояний: узлы — это действия, рёбра — переходы между ними. Это даёт очень точный контроль над тем, как агент принимает решения. Кривая обучения выше чем у других, но зато гибкость максимальная.
CrewAI — если нужно быстро стартовать с мультиагентностью. Интуитивная концепция «команды с ролями»: создаёшь агентов с именами и описаниями, назначаешь им задачи, они работают вместе. Хорошо подходит для прототипирования.
AutoGen от Microsoft — фокус на диалоге между агентами. Агенты могут обсуждать задачу между собой и принимать совместные решения. Хорошо для задач где нужна «дискуссия» а не просто последовательное выполнение.
LlamaIndex Workflows — если ваш агент много работает с документами и RAG. LlamaIndex вообще изначально создавался для работы с данными, поэтому в этой нише у него сильные позиции.
Важное наблюдение: фреймворки развиваются очень быстро, и то что было актуально полгода назад уже может быть устаревшим. Поэтому перед выбором стоит смотреть не только на фичи, но и на активность разработки и размер комьюнити.
Где агенты ломаются: реальные проблемы
Было бы нечестно написать статью про агентов и не поговорить о том, где они регулярно падают.
Галлюцинации при вызове инструментов. Модель может выдумать параметры которых не существует, вызвать инструмент с неправильным форматом данных, или решить что инструмент вернул успех, хотя там была ошибка. Помогает явная валидация возвращаемых данных и чёткие описания инструментов.
Бесконечные петли. Агент застревает: вызывает инструмент, не получает нужного результата, вызывает снова, снова не получает — и так до исчерпания бюджета токенов. Решение простое — всегда ставить лимит на количество итераций и явно обрабатывать ситуацию когда лимит достигнут.
Стоимость. Агент делает много вызовов модели — каждая итерация цикла, каждый вызов инструмента с обработкой результата. На сложных задачах это быстро превращается в заметные расходы. Перед запуском в продакшн стоит посчитать среднее количество итераций и умножить на стоимость токенов.
Безопасность. Агент с доступом к файловой системе и возможностью запускать код — это потенциальная дыра, если задачи приходят от пользователей. Всегда нужно думать о том, что плохой пользователь может попросить агента сделать, и ограничивать возможности через разрешения и песочницы.
Отладка. Когда что‑то пошло не так — понять где именно бывает сложно. Хорошая практика — логировать каждый шаг агента: рассуждение, вызов инструмента, результат. Большинство нормальных фреймворков поддерживают tracing из коробки, например через LangSmith или Phoenix.
Когда агент нужен, а когда нет
Напоследок — самый практичный вопрос.
Агент оправдан, когда задача требует нескольких шагов с разными инструментами, когда заранее неизвестно точно сколько шагов понадобится, и когда между шагами нужны промежуточные решения на основе полученных данных.
Агент не нужен, когда задача решается одним хорошим промптом, когда последовательность шагов всегда одинакова и её можно захардкодить, или когда критична предсказуемость — агенты по природе своей менее детерминированы чем простые пайплайны.
Частая ошибка — строить агента там, где достаточно цепочки промптов. Агент добавляет сложность: его сложнее отлаживать, он дороже в работе и непредсказуемее в поведении. Если задача хорошо структурирована и шаги известны заранее — лучше сделать простой детерминированный пайплайн.
Но когда задача действительно открытая, когда нужна адаптация под результат каждого шага — вот тут агенты раскрываются в полную силу. Это не серебряная пуля, но в нужном месте — очень мощный инструмент.
Область агентов развивается стремительно. Год назад большинство агентов были прототипами. Сейчас они уже работают в продакшне в сотнях компаний — пишут код, анализируют данные, автоматизируют рутину. Понимание того как они устроены — уже не академический интерес, а практический навык для любого разработчика который работает с ИИ.
Автор: Lordneo
