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

На столе лежит коммерческое предложение от студии разработки: полёт мысли на пять страниц, срок «восемь недель» и мелкая строка внизу — «доработки по отдельному счёту». Решение кажется техническим, а на деле это вопрос о том, кто будет отвечать за агента через два месяца после сдачи, когда клиенты начнут задавать вопросы, которых не было в техзадании.

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

Три пути к одному агенту

Разработка ИИ-агента распадается на три модели, и они не сводятся к разнице в цене.

Своими силами — штатный сотрудник настраивает агента сам, без привлечения разработчиков со стороны. Обычно это происходит на платформе: инструкция, база знаний, действия собираются в интерфейсе кабинета.

Через подрядчика — интегратор или студия берёт настройку на себя. Часть работы всё так же идёт через платформу, часть (если нужна связь с вашей собственной системой) требует кода на стороне подрядчика.

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

Что реально настраивается без кода

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

Без кода собираются:

• инструкция агента — системный промпт, который задаёт, кто агент и в каких случаях зовёт человека;
• база знаний трёх форматов: пары вопрос-ответ для прямых вопросов, документы с поиском по смыслу для развёрнутых текстов, таблицы для меняющихся данных вроде прайса;
• действия — запись в CRM, смена статуса заявки, уведомление менеджеру, планирование напоминания;
• LLM-барьеры — проверка ответа перед отправкой, с перегенерацией или заменой на фиксированную фразу; два готовых барьера, «Числа только из источников» и «Контроль скидки», включаются без единой строки кода;
• интеграции с готовыми сервисами — Google-календарь, CRM, каналы вроде Telegram и WhatsApp; подключаются через ключи и авторизацию в интерфейсе.

Показателен и обратный случай: платформа умеет настраивать часть этих же действий по текстовому описанию задачи: «нужно, чтобы при записи клиента нам в Telegram приходило уведомление с его именем и телефоном» превращается в готовую настройку без ручного заполнения полей. Результат остаётся конфигурацией в кабинете компании: разработкой это назвать сложно, хотя внешне выглядит как диалог с исполнителем.

Где без разработчика не обойтись

Граница здесь проходит по одному вопросу: существует ли для задачи готовый способ подключения. Сложность самой задачи почти не влияет на ответ.

Когда данные и логика живут в собственной системе компании (например в 1С), платформа не подключается к ней напрямую: структура базы у каждой компании своя, готового канала для неё нет. Работает это через HTTP-сервис: сначала на стороне 1С публикуется веб-сервис с нужными методами, а затем в агенте настраивается действие «Вебхук», которое к этим методам обращается. Опубликовать сам сервис — задача программиста 1С, и без неё связка не соберётся, сколько бы ни было опыта в настройке агента. Как выглядит эта настройка целиком — в статье про ИИ-агента и 1С.

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

Как выглядят три пути на одних и тех же вопросах

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

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

Агент — не проект со сдачей

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

Модель «сдал и забыл» здесь плохо стыкуется с реальностью. Коммерческое предложение со сроком «восемь недель» описывает разработку, но молчит про сопровождение: про то, кто в девятую неделю поправит формулировку, которая раздражает клиентов. Выбор между тремя путями решает вопрос скорости: кто и как быстро внесёт правку через полгода работы, когда цена запуска давно забыта. Как устроен сам цикл этих правок после запуска — в разборе внедрения ИИ-агента.

Прежде чем подписывать предложение

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

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

Частые вопросы