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

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

Что именно называют разработкой ИИ-агента

ИИ-агент — это не просто окно для диалога с нейросетью. Он получает цель, работает с данными и выполняет последовательность действий. Например, агент для продаж может принять заявку из Telegram, найти клиента в CRM, определить стадию сделки, подготовить персональный ответ и поставить менеджеру задачу. На каждом шаге есть правила: какие данные разрешено читать, что можно менять автоматически и когда нужно попросить подтверждение.

Удобно разделять агента на пять частей:

• канал общения: Telegram, почта, сайт или CRM;
• модель, которая понимает текст и выбирает следующий шаг;
• инструменты: таблицы, календарь, база клиентов, API магазина;
• память и контекст: история переписки, карточка клиента, инструкции компании;
• контроль: лимиты, подтверждения, журнал действий и обработка ошибок.

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

Здесь полезно отличать агента от обычной автоматизации. В жёстком сценарии автоматизация всегда выполняет один и тот же маршрут. Агент может выбрать действие из нескольких вариантов, прочитать неструктурированный текст и объяснить человеку, почему остановился. Но там, где правила однозначны — например, записать дату в таблицу — обычная интеграция часто надёжнее и дешевле.

Три способа создать ИИ-агента

Заказать индивидуальную разработку

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

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

Собрать на платформе без кода

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

Для таких задач подходит Мой агент: сервис рассчитан на работу с прикладными задачами, а не только на свободный диалог. На базовой модели DeepSeek V4 Pro подписка стоит 1990 ₽ в первый месяц по акции до 1 августа 2026 года, затем базовая цена первого месяца — 2490 ₽, а со второго месяца — 990 ₽/мес плюс расход токенов. Отдельная задача считается по объёму: например, короткий ответ клиенту стоит до 1 ₽, разбор почты за день — примерно 6 ₽, еженедельный отчёт по таблицам — примерно 10 ₽. Это ориентиры для базовой модели; на тяжёлых моделях вроде Claude Opus или GPT-5 расчёты могут быть в 3–5 раз дороже.

Написать всё самостоятельно

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

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

Как проходит разработка: от задачи до запуска

1. Формулировка результата

Плохая формулировка звучит так: «Нужен умный агент для отдела продаж». Хорошая — так: «Каждое утро агент читает новые заявки, распределяет их по трём категориям, готовит черновик ответа и отправляет менеджеру список на подтверждение».

Зафиксируй единицу работы, частоту и критерий успеха. Это может быть время ответа, доля правильно классифицированных обращений, количество подготовленных черновиков или часы, которые сотрудник перестал тратить на рутину. Без этой цифры невозможно понять, окупилась ли разработка.

2. Описание сценария и исключений

Нарисуй процесс обычными словами. Что происходит с новой заявкой? Что делать, если нет телефона? Что считать срочным обращением? Как агент поступает с недовольным клиентом? Какие сообщения нельзя отправлять автоматически?

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

3. Выбор модели и инструментов

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

Затем составь список инструментов. Не подключай CRM, почту, календарь и десять таблиц «на будущее». Каждая интеграция расширяет поверхность ошибок. Первая версия может читать одну папку, брать данные из одной таблицы и писать результат в Telegram. После проверки добавляй следующий инструмент.

4. Сборка прототипа

Прототип должен выполнять один сценарий от начала до конца. Например: сообщение из Telegram → извлечение имени и запроса → поиск инструкции → черновик ответа → отправка человеку на подтверждение. На этом этапе важнее увидеть реальные сбои, чем отполировать интерфейс.

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

5. Тестирование на реальных примерах

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

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

6. Запуск и наблюдение

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

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

В моей практике: почему узкий сценарий выигрывает

За четыре месяца я собрал 12 сервисов без знания кода. Главный вывод оказался не про конкретную нейросеть: быстрее всего пользу показывал не «универсальный цифровой сотрудник», а один небольшой процесс с понятным входом и выходом. Когда агент сразу пытался одновременно вести почту, продажи, контент и документы, становилось трудно понять, где именно он приносит результат.

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

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

Если задача связана с продажами, после базовой версии логично посмотреть материалы про ИИ для продаж, автоматизацию Битрикс24 и ИИ для amoCRM. Это соседние сценарии, но в каждом нужны свои правила доступа и проверки.

Сколько стоит разработка и где чаще всего переплачивают

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

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

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

Для самостоятельного изучения можно начать с курса по ИИ и автоматизации, а если нужен именно программный путь — посмотреть, как устроен Claude Code. Но не путай обучение разработке с быстрым запуском рабочего сценария: иногда готовая платформа позволяет проверить гипотезу раньше и дешевле.

Как выбрать путь именно для своей задачи

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

Перед стартом ответь на пять вопросов:

1. Какой конкретный результат должен появиться после работы агента?
2. Как часто возникает задача и сколько времени она занимает сейчас?
3. Какие данные агент читает, а какие ему запрещены?
4. Где обязательно подтверждение человека?
5. Какую цифру мы сравним через две недели после запуска?

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