Разработка ИИ-агентов: как собрать помощника, который реально работает

Слово «агент» за последние пару лет растянулось до бессмысленности. Для одних агент — это промпт в три абзаца. Для других — система с планировщиком, памятью и десятком инструментов. Расскажу, как выглядит разработка ИИ-агентов на практике, со стороны человека, который собирает такие штуки для рабочих задач.

Чем агент отличается от чат-бота

Чат-бот отвечает текстом. Агент действует и проверяет, что получилось.

Разница видна на простом примере. Спросите модель «какие письма пришли за неделю» — она сочинит правдоподобный список. Агент откроет почтовый ящик через API, прочитает реальные письма и вернёт то, что там лежит.

Минимальный набор признаков агента:

• Цель — человек говорит, чего хочет. Пошаговый маршрут агент выстраивает сам
• Инструменты — доступ к файлам, API, базе, браузеру
• Цикл — модель делает шаг, смотрит на результат, решает, что дальше
• Условие остановки — когда считать задачу выполненной

Уберите инструменты — останется генератор текста. Уберите цикл — останется однократный вызов модели.

Из чего собирается агент

Модель

Базовый слой. В агентных задачах решает устойчивость в вызове инструментов: модель должна корректно заполнять параметры и не выдумывать функции, которых нет. Абстрактная «умность» в вакууме тут вторична. Сильные модели дороже за токен и часто выходят дешевле в сумме — меньше циклов уходит на исправление ошибок.

Инструменты

Тут ломается большинство прототипов. Инструмент — это функция с описанием, которое читает модель. Описание важнее кода: выбор идёт по тексту.

Что помогает:

• Одна функция — одно действие. create_task и update_task лучше универсального manage_task с флагами
• В описании — когда применять и когда держаться подальше
• Понятные ошибки. "Проект не найден. Доступные: A, B, C" даёт модели шанс исправиться самой
• Пять-семь инструментов на агента. Дальше начинается путаница

Контекст

Агенту нужно знать, где он находится: какой проект, какие правила, что уже сделано. Часть контекста живёт в системном промпте, часть подтягивается по ходу. Грузить всё подряд бессмысленно: длинный контекст размывает внимание модели и дорого стоит.

Память

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

Как это делать по шагам

Опишите задачу как процесс. Возьмите то, что человек делает вручную, и запишите по шагам. Где смотрит данные, по каким признакам решает, что проверяет перед отправкой. Процесс, который не описывается словами, агент не выполнит.

Соберите самую простую версию. Один инструмент, один сценарий, никакой оркестрации. Цель — понять, справляется ли модель с ядром задачи.

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

Соберите набор проверок. Двадцать типичных случаев с известным правильным ответом. Поменяли промпт — прогнали набор. Без этого улучшения превращаются в гадание: поправили одно, сломали другое.

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

Что мешает чаще всего

Слишком широкая задача. «Агент, который ведёт всю переписку» не взлетит. «Агент, который сортирует входящие по трём папкам» — взлетит.

Нет способа проверить результат. Когда правильность определяется на глаз, качество плавает, и вы этого даже не заметите.

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

Игнорирование стоимости. Агент в цикле вызывает модель много раз. Посчитайте расход на типичной задаче до того, как запускать это на поток.

С чего начать

Выберите задачу, которую делаете руками каждую неделю: результат легко проверить, ошибка стоит дёшево. Разбор писем, подготовка черновиков, сверка таблиц.

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