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

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

Из чего складывается работа

Пять частей, примерно в таком порядке трудозатрат:

1. Постановка и критерий готовности. Самая недооценённая часть. Пока непонятно, как проверить результат, дальше идти нельзя.
2. Инструменты и интеграции. Доступ к базам, API, внутренним системам. Здесь обычно всплывает, что нужного API нет или в нём нет нужного поля.
3. Цикл агента и его границы. Лимиты, обработка ошибок, идемпотентность.
4. Верификация и наблюдаемость. Проверка факта вместо отчёта, логи по шагам, метрики.
5. Прогон на реальных данных и правки. Больше половины итоговых доработок появляется отсюда.

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

Стек

Что используется на практике и почему:

Язык. Python или TypeScript. Выбор определяется не задачей, а тем, на чём написано остальное, - агенту нужно ходить в ваши системы.

Вызовы модели. Официальный SDK провайдера. Совместимый эндпоинт от посредника выглядит так же, но иногда отличается в деталях - лучше знать об этом заранее, чем ловить на проде.

Состояние. Обычная база данных. Агенту нужно помнить, что уже сделано, и это то, что защищает от повторного выполнения при перезапуске.

Очередь. Для фоновых задач, ретраев и ограничения параллельности. Без неё всплеск нагрузки превращается в упор в лимиты провайдера.

Логи по шагам. Не общий лог приложения, а именно история решений агента: контекст, выбранный инструмент, результат. Без этого разбор инцидента невозможен.

Фреймворк - по желанию. Он экономит день на старте и стоит недели, когда нужное поведение не ложится в его абстракции. На простом цикле выгоднее свой код; на сложной мультиагентной схеме готовая обвязка окупается.

Что занимает больше всего времени

По убыванию:

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

Поведение при сбоях. Что делать, если интеграция недоступна, если ответ пришёл наполовину, если агент перезапустился в середине. Здесь же идемпотентность - см. идемпотентные пайплайны.

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

Границы уверенности. Где агент решает сам, а где отдаёт человеку. Настраивается по измеренным данным; наугад этот порог не ставится.

Стоимость. Первая версия почти всегда дороже допустимого. Оптимизация - это сокращение контекста и маршрутизация задач по моделям, см. роутер моделей.

Как принимать результат

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

Что требовать:

• Прогон на вашей реальной выборке, не на подготовленной. Сто настоящих записей информативнее любой презентации.
• Измеренные цифры: доля успешных завершений, доля передач человеку, среднее и максимальное число шагов, стоимость запуска.
• Проверку сбоев: отключите интеграцию и посмотрите, что система делает. Правильный ответ - явная ошибка, а не сообщение об успехе.
• Логи, по которым видно ход решения.
• Ответ на вопрос, что происходит при повторном запуске. Если ответа нет, идемпотентности нет.
• Документированный способ отката и выключения.

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

Про сроки

Оценка, которая обычно оказывается близкой к правде: неделя на постановку и узкий прототип, две-три недели на инструменты, цикл и верификацию, ещё две на прогон, правки и вывод. Дальше - поддержка, потому что данные и модели меняются.

Сроки резко растут, если нужных интеграций нет и их надо делать с нуля. Это стоит выяснить до оценки, а не после.

Обсудить свою задачу, сроки и стоимость - на странице услуг. Что должно быть сделано до запуска - во внедрении. Разбор на конкретном кейсе - здесь. Общая картина - гид по ИИ-агентам.