Разработка агента идёт по тому же порядку, что и любой ИИ-проект, но добавляет четыре работы, которых в проекте бота нет: проектирование инструментов, ограничение полномочий, песочница для безопасных прогонов и тестирование многошаговых сценариев. Именно они, а не «более умная модель», определяют разницу в стоимости и сроках.
Общий порядок работ — выбор процесса, проверка достижимости, пилот, промышленный запуск, сопровождение — разобран в статье «Этапы внедрения ИИ в компании». Здесь только то, что специфично для агентов.
Что добавляет агент к обычному ИИ-проекту
1. Проектирование инструментов
У бота нет инструментов: он получает вопрос и отдаёт текст. У агента каждое действие — отдельная функция с описанием, параметрами и проверками. Это проектная работа, сопоставимая по объёму с разработкой API.
Здесь же принимается решение о зернистости: дать агенту один универсальный инструмент «выполнить запрос к CRM» или пять узких — «создать заявку», «найти клиента», «изменить статус». Узкие проще ограничить и проверить, универсальные гибче и опаснее. Механика описана в статье «Function calling».
2. Ограничение полномочий
Определяется, что агенту разрешено: какие записи он может менять, на какие суммы, сколько действий в час, какие операции требуют подтверждения человека. Работа не техническая, а согласовательная — решения принимает владелец процесса, а не разработчик.
Пропуск этого этапа — самая дорогая ошибка агентских проектов: она обнаруживается уже после того, как агент что-то сделал не то. Подробнее — «Ограничение действий ИИ-агента».
3. Песочница
Агент, который меняет данные, нельзя отлаживать в рабочей системе. Нужна копия CRM или тестовый контур, где прогоны безопасны. Если у компании такого контура нет, его создание становится частью проекта — и это ощутимая статья, которую часто не закладывают.
4. Тестирование сценариев, а не ответов
Проверить бота — значит сравнить ответы с эталонными. Проверить агента так нельзя: он выполняет разное число шагов, и правильных путей к цели может быть несколько. Тестируется результат сценария целиком плюс поведение в нештатных ситуациях: инструмент недоступен, данные противоречивы, цель недостижима. См. «Тестирование ИИ-агента перед запуском».
Из чего складывается стоимость
| Статья | Что влияет на цену |
|---|---|
| Обследование процесса | сколько шагов, сколько исключений, кто принимает решения |
| Проектирование инструментов | число внешних систем и операций в каждой |
| Интеграции | наличие API, качество документации, права доступа |
| Логика агента | простой сценарий или ветвление с проверками |
| Ограничения и подтверждения | сколько операций требует согласования |
| Песочница | есть ли тестовый контур или нужно создавать |
| Тестирование | число сценариев и нештатных ситуаций |
| Сопровождение | постоянная статья, не разовая |
Главный множитель стоимости — число внешних систем. Агент, работающий с одной CRM по документированному API, и агент, связывающий CRM, почту, склад и бухгалтерию, — проекты разного порядка, даже если формулировка задачи звучит похоже.
Второй по значимости — состояние API. Система с современным документированным интерфейсом подключается предсказуемо. Устаревшая учётная система без API превращает интеграцию в основную часть бюджета, а иногда делает проект невозможным в разумные деньги.
Общая структура затрат ИИ-проекта — разовые, регулярные и скрытые — разобрана в статье «Структура затрат на внедрение ИИ».
Что удорожает проект незаметно
- Нет тестового контура. Создание песочницы может оказаться сопоставимо с самим агентом.
- Права доступа не выданы. Ожидание доступов к учётной системе — частая причина срыва сроков, не связанная с разработкой.
- Исключения не описаны. «Обычно делаем так, но если клиент из другого региона, то иначе» — каждое такое правило нужно выяснить и заложить.
- Нет владельца процесса. Решения о полномочиях агента принимать некому, проект встаёт.
- Требование полной автономности. Отказ от подтверждений резко повышает требования к тестированию и ограничениям.
Последний пункт стоит обсуждать в самом начале: агент с подтверждением критичных действий дешевле, быстрее и безопаснее полностью автономного, а разница в пользе часто невелика.
Порядок работ
- Выбор процесса и оценка применимости. Действительно ли нужен агент, а не бот или обычная автоматизация — см. «Агент или чат-бот».
- Обследование. Полный разбор шагов, исключений и точек принятия решений. Здесь же выясняется состояние API.
- Проверка достижимости. Прототип на реальных данных в песочнице: справляется ли модель с выбором шагов на вашем материале.
- Проектирование инструментов и полномочий.
- Разработка и интеграции.
- Тестирование сценариев, включая нештатные.
- Пилот с подтверждениями. Даже если целевое состояние — автономность, начинать стоит с подтверждения каждого действия: это даёт данные о том, где агент ошибается.
- Постепенное снятие подтверждений по операциям, где статистика набрана.
- Промышленный запуск и сопровождение.
Пункты 7 и 8 — не осторожность ради осторожности. Это единственный способ узнать реальную частоту ошибок до того, как они станут необратимыми.
Сроки
Точные сроки зависят от числа систем и состояния их API, но соотношение устойчиво: на интеграции и согласование полномочий уходит больше времени, чем на логику самого агента. Разработчики обычно оценивают вторую часть и недооценивают первую.
Отдельно стоит закладывать время на накопление статистики в режиме подтверждений — его нельзя ускорить, оно определяется потоком реальных задач.
Пример: как одна и та же формулировка даёт разные проекты
Задача звучит одинаково: «агент обрабатывает входящие заявки». Разберём три ситуации, отличающиеся только обстоятельствами.
Ситуация А. Одна облачная CRM с документированным API.
Работы: обследование, три инструмента (найти клиента, создать заявку, назначить ответственного), проверки, тестирование. Песочница — тестовый контур CRM, поднимается штатно. Полномочия обсуждаются за одну встречу: всё обратимо, подтверждение нужно только на ответ клиенту.
Ситуация Б. Та же CRM плюс складская система без публичного API.
Добавляется: выяснение способа доступа к складу, разработка сервиса-посредника, обработка недоступности второй системы, тестирование сценариев, где одна система ответила, а вторая нет. Число инструментов растёт с трёх до шести, а число тестовых сценариев — примерно вчетверо, потому что проверяются комбинации состояний двух систем.
Ситуация В. То же, что Б, плюс агент сам отвечает клиенту.
Добавляется необратимое действие. Значит: механизм подтверждения, интерфейс для согласующего, журнал решений, статистика для последующего снятия подтверждений, а на пилоте — участие человека в каждом обращении.
| А | Б | В | |
|---|---|---|---|
| Внешних систем | 1 | 2 | 2 |
| Инструментов | ~3 | ~6 | ~7 |
| Тестовых сценариев | базовый набор | ×4 | ×4 + согласование |
| Песочница | штатная | нужна своя для склада | то же |
| Необратимые действия | нет | нет | есть |
Соотношение трудоёмкости между А и В — не проценты, а разы. При этом формулировка задачи от заказчика во всех трёх случаях будет одна и та же.
Практический вывод. Прежде чем просить оценку, ответьте на три вопроса: сколько систем, есть ли у каждой API и есть ли необратимые действия. Оценка без этих ответов — выдуманное число, и расхождение вскроется в середине проекта.
Частые вопросы
Сколько стоит разработка ИИ-агента?
Цена определяется числом внешних систем, состоянием их API и количеством исключений в процессе, а не «сложностью ИИ». Агент к одной CRM с документированным API и агент, связывающий четыре системы, различаются кратно при одинаковой формулировке задачи. Назвать сумму до обследования процесса нельзя — это будет выдуманное число.
Чем разработка агента отличается от разработки чат-бота?
Добавляются четыре работы: проектирование инструментов с проверяемыми параметрами, ограничение полномочий, песочница для безопасных прогонов и тестирование сценариев целиком вместо сравнения ответов с эталонными. Каждая из них отсутствует в проекте бота, и вместе они объясняют разницу в стоимости и сроках.
Что дольше всего в проекте агента?
Интеграции и согласование полномочий, а не логика агента. Ожидание доступов к учётной системе, выяснение негласных исключений в процессе и решения о том, что агенту разрешено, регулярно занимают больше времени, чем разработка. Если у системы нет API, интеграция может стать основной частью бюджета.
Можно ли обойтись без песочницы?
Нежелательно. Агент меняет данные, и отладка в рабочей системе означает реальные последствия каждой ошибки на этапе, когда ошибки неизбежны. Если тестового контура нет, его создание закладывается в проект — это дешевле, чем разбирать последствия. Исключение — агенты, работающие только на чтение.
Стоит ли сразу делать агента полностью автономным?
Нет. Разумная последовательность — запустить с подтверждением каждого действия, накопить статистику ошибок и снимать подтверждения по операциям, где она набрана. Полная автономность с первого дня резко повышает требования к тестированию и ограничениям, а выигрыш в пользе часто оказывается небольшим.
Что дальше
Перед разработкой стоит убедиться, что задача агентская, — «Агент или чат-бот», и посмотреть, где агенты окупаются, — «15 сценариев применения». Альтернатива собственной разработке — «Платформа или разработка». Общие затраты ИИ-проекта — «Структура затрат».
Обследование процесса и оценка объёма работ — это аудит процессов, с которого начинается разработка и внедрение ИИ.