«Сделайте нам AI-агента» — эта фраза за последний год прошла путь от хайпа до рядового пункта в задаче. Проблема в том, что под ней каждый понимает своё: для одного агент — это чат-бот с парой кнопок, для другого — автономная система, которая сама ходит по внутренним сервисам и принимает решения. Прежде чем что-то строить, стоит договориться, о чём вообще речь — иначе легко потратить месяц на то, что закрывалось одним промптом. Эта тема стала обязательной для AI-инженера, так что разберёмся по существу.
Что такое AI-агент — и чем он отличается от чат-бота
Самое короткое определение: агент — это языковая модель, которой дали инструменты и запустили в цикле. Дальше модель сама решает, что делать.
Чтобы почувствовать разницу, посмотрим на лестницу:
- Промпт. Один заход: на входе вопрос, на выходе текст. «Перепиши это письмо вежливее».
- Чат-бот. Цепочка промптов с памятью диалога. Помнит контекст, но по-прежнему только говорит.
- Агент. Модель плюс инструменты плюс право самой выбирать шаги. Получив цель «разберись, почему упал ночной отчёт», агент читает логи, ходит в базу, проверяет гипотезы и возвращается с ответом — а не с предложением «проверьте логи».
Граница проходит по двум признакам: появились ли у модели инструменты (возможность что-то сделать, а не только сказать) и есть ли у неё автономия в выборе действий. Чат-бот отвечает, агент — действует.
Анатомия агента: четыре части
За любым агентом, от простого до мультиагентной системы, стоят одни и те же четыре кирпича.
Модель — мозг
Это сама LLM, которая рассуждает и принимает решения. От её качества зависит, насколько разумно агент планирует шаги и насколько редко уходит в галлюцинации посреди траектории. Для агентных задач берут модели посильнее: на длинной цепочке действий слабая модель накапливает ошибки быстрее, чем успевает их исправлять.
Инструменты — руки
То, чем агент действует на мир: поиск, чтение файлов, запросы к API, выполнение кода, отправка письма. Инструмент описывается моделью как функция с понятным именем и параметрами, а модель решает, когда его вызвать. Чтобы не писать интеграцию под каждый сервис заново, инструменты всё чаще подключают через MCP-серверы — это стандартный разъём между агентом и внешним миром. Готовые серверы под типовые задачи мы собрали отдельно.
Память — знания
Контекстное окно — это короткая память: что происходило в текущей сессии. Но когда знаний больше, чем влезает в контекст, нужна долгая память — и здесь подключается RAG: агент достаёт релевантные куски из векторной базы ровно тогда, когда они нужны. Память и инструменты часто путают, хотя роли у них разные: инструменты позволяют сделать, память — вспомнить.
Цикл — то, что превращает модель в агента
Без цикла всё перечисленное так и осталось бы умным автодополнением. Именно повторение «решил — сделал — посмотрел на результат» даёт агенту способность доводить задачу до конца. О нём — отдельно.
Цикл агента: «подумал → сделал → посмотрел»
Сердце любого агента — простая петля:
- Рассуждение. Модель смотрит на цель и текущее состояние и решает: какой шаг сделать следующим.
- Действие. Вызывает инструмент с конкретными параметрами.
- Наблюдение. Получает результат — содержимое файла, ответ API, ошибку — и добавляет его в контекст.
- Повтор. С учётом нового знания модель планирует следующий шаг. Цикл крутится, пока задача не решена либо не сработал лимит.
Лучше всего это видно на агентах для кода. Когда Claude Code или Cursor в агентном режиме чинят баг, они не пишут патч с первой попытки: читают файлы, ищут по проекту, вносят правку, запускают тесты, видят падение, правят снова. Это и есть агентный цикл вживую — мы разбирали такие сценарии на практике.
Вся «магия» агента сводится к этой петле. Сложность не в ней, а в том, чтобы петля не закрутилась в бесконечность и не наделала дел по дороге.
Один агент или несколько: уровни сложности
Не каждой задаче нужен полноценный автономный агент. Полезно держать в голове шкалу — и брать минимально достаточный уровень.
- Жёсткий сценарий (workflow). Шаги заранее известны и зашиты в код: достать данные → суммировать → разложить по полям. Модель вызывается в фиксированных точках, маршрут не меняется. Предсказуемо, дёшево, легко отлаживать. 80% «агентных» задач на деле решаются здесь.
- Один агент с инструментами. Маршрут заранее неизвестен, модель сама выбирает шаги. Это честный агент, и для большинства реальных задач его достаточно.
- Мультиагентная система. Оркестратор раздаёт подзадачи агентам-специалистам и собирает результат. Звучит солидно, но цена и сложность отладки растут нелинейно: ошибку приходится искать уже не в одной траектории, а в их переплетении. Оправдано, когда задача честно бьётся на независимые куски — например, параллельный обзор большой кодовой базы.
Здравое правило: начинать с жёсткого сценария и поднимать автономию ровно тогда, когда без неё перестаёт получаться. Лишняя свобода агента — это не гибкость, это лишние способы ошибиться.
Где агенты уже работают
Спустя год экспериментов вырисовались области, где агенты дают реальную пользу, а не демку для презентации:
- Код. Самый зрелый сценарий: починить баг, провести рефакторинг, поднять каркас фичи, разобраться в незнакомом проекте. Здесь есть быстрая обратная связь — тесты и компилятор сразу говорят, сработало ли действие.
- Поддержка и ресёрч. Агент проходит по тикету: читает историю, лезет в документацию и базу заказов, готовит проект ответа. Человек проверяет и отправляет.
- Рутина с данными. Собрать выгрузку из нескольких источников, сверить, разложить по таблице, отметить аномалии.
Объединяет эти кейсы одно: у действий есть проверяемый результат, ошибка дёшево откатывается, а цена неверного шага невелика. Там, где обратной связи нет и каждое действие необратимо, автономный агент пока опасен — и это нормально.
Грабли: пять способов сжечь бюджет и доверие
- Накопление ошибок. Агент ошибся на третьем шаге, а следующие десять достраивал на основе неверного вывода. Длинные траектории умножают мелкие неточности — поэтому короткие, проверяемые шаги надёжнее одного монолитного плана.
- Бесконечный цикл. Агент дёргает один и тот же инструмент, не приближаясь к цели, и спокойно мотает счётчик токенов, пока кто-то не заметит. Лимит шагов и потолок бюджета ставят до первого запуска, а не после первого счёта.
- Незаметная стоимость. Каждый шаг пересылает модели весь накопленный контекст. Задача на 15 действий легко обходится в 10–20 раз дороже одиночного запроса. На прототипе незаметно, на масштабе — статья расходов.
- Права без границ. Агенту с доступом на запись в прод и без подтверждений однажды хватит одной уверенной галлюцинации, чтобы устроить инцидент. Песочница, режим «только чтение» по умолчанию и человек в контуре на необратимых действиях — базовая гигиена.
- Оценка на глазок. «Вроде работает» на пяти примерах — не метрика. Без набора тестовых задач с понятным критерием успеха каждое изменение промпта или модели превращается в лотерею, а деградацию замечают по жалобам пользователей.
Как собрать первого агента — без фреймворка
Самый недооценённый совет: первого агента стоит написать руками, без LangChain и аналогов. Базовый цикл — это 30–50 строк, и они дают понимание, которое потом экономит дни отладки.
Рабочий путь:
- Возьмите одну узкую задачу с проверяемым результатом. «Найти в репозитории, где определена функция, и показать её вызовы» лучше, чем «будь моим ассистентом».
- Дайте один-два инструмента. Поиск по файлам и чтение файла — уже хватает для осмысленного агента. Чем меньше инструментов, тем меньше способов запутаться.
- Соберите цикл. Отправить модели задачу и список инструментов → получить запрос на вызов → выполнить → вернуть результат в контекст → повторить, пока модель не скажет «готово».
- Поставьте ограничители сразу. Максимум шагов, потолок токенов, подтверждение на любое необратимое действие. Это не «потом причешем», это часть первой версии.
- Добавьте наблюдаемость. Логируйте каждый шаг: что подумал, что вызвал, что получил. Без трейса вы не отладите агента — он принципиально недетерминирован, и единственный способ понять провал постфактум это прочитать его траекторию.
Когда руками станет тесно — мультиагентность, готовые коннекторы, сложный трейсинг, — тогда и берите фреймворк под конкретную боль. Не раньше.
Когда агент не нужен
Самая дорогая ошибка — собрать автономного агента там, где хватало куда меньшего:
- Задача решается одним промптом. Если на входе текст и на выходе текст, агентный цикл — лишние затраты и лишние точки отказа.
- Маршрут известен заранее. Когда шаги предсказуемы, жёсткий сценарий с вызовами модели в нужных точках надёжнее и дешевле: меньше свободы — меньше сюрпризов.
- Цена ошибки высока, а отката нет. Там, где неверное действие необратимо, разумнее оставить решение человеку, а агенту отдать только подготовку.
Агент оправдан, когда маршрут заранее неизвестен, шагов много, а у действий есть быстрая проверяемая обратная связь. В остальных случаях более простой инструмент выигрывает и по цене, и по надёжности.
Куда расти дальше
Хороший агент на 20% про модель и на 80% про инженерию вокруг неё: инструменты, границы прав, наблюдаемость, оценка качества. Ровно поэтому вопросы про агентов, MCP и RAG стали стандартом на собеседованиях AI-инженеров — по ним сразу видно, собирал человек живую систему или пересказывает туториал.
Если хотите разобрать архитектуру своего агента с тем, кто уже наступил на эти грабли, — в базе менторов IT-ХОЗЯЕВА есть практикующие AI/ML-инженеры: ревью стека, помощь с первым проектом, подготовка к собеседованию. Доступ — на тарифе ХОЗЯИН, 1000 ₽/мес.