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

Агент отличается от чат-бота не «умом», а последствиями. Бот возвращает текст на экран, и его ошибка остаётся на экране. Агент сам выбирает шаги и меняет данные в ваших системах — создаёт записи, назначает ответственных, отправляет сообщения. Его ошибка попадает в CRM, в учёт, в почту клиента.

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

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

Когда агент нужен, а когда нет

Честный разбор до начала работ экономит бюджет, поэтому начинаю с него.

Агент оправдан, если:

  • задача состоит из нескольких шагов, и порядок шагов заранее неизвестен — он зависит от промежуточных результатов;
  • нужно менять данные в других системах, а не только отвечать;
  • у этих систем есть API;
  • результат проверяем, а ошибка на большинстве шагов обратима.

Агент не нужен, если:

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

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

Сценарии, с которыми работаю

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

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

Квалификация и сопровождение сделок. Заполнение карточки, отслеживание просроченных этапов, подготовка сводок.

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

Автоматизация рутинных цепочек между несколькими системами, где шаги зависят от промежуточных результатов.

Разбор пятнадцати сценариев с оценкой сложности и требований — в статье «15 сценариев применения ИИ-агентов».

Что входит в разработку

Обследование и проверка применимости

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

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

Проектирование инструментов

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

Механика — «Function calling».

Ограничение полномочий

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

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

Интеграции

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

Тестирование

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

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

Запуск и сопровождение

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

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

От чего зависит стоимость

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

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

Разбор структуры затрат — «Разработка ИИ-агента: этапы и стоимость».

Чего я не делаю

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

Форматы работы

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

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

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

Сопровождение. Контроль качества, обновление сценариев, миграция при смене модели, оптимизация расходов.

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

На вопросы отвечает
Мосолов Игорь
Чем ИИ-агент отличается от чат-бота?
Бот отвечает текстом и ничего не меняет за пределами диалога. Агент сам выбирает последовательность шагов и выполняет действия в ваших системах — создаёт записи, назначает ответственных, отправляет сообщения. Отсюда и разница в стоимости: у агента появляются инструменты, права, подтверждения и тестирование сценариев, которых у бота нет.
Сколько стоит разработка агента?
Цена определяется числом внешних систем, состоянием их API и количеством исключений в процессе, а не «сложностью ИИ». Агент к одной CRM с документированным API и агент, связывающий четыре системы, различаются кратно при одинаковой постановке задачи. Сумму называю после обследования — раньше она была бы выдуманной.
Можно ли подключить агента к нашей CRM?
Если у системы есть API с нужными операциями — да. Проверяю на обследовании: не только наличие интерфейса, но и полноту операций, лимиты запросов и поведение при их превышении. Если API нет, честно скажу, что задача в разумные деньги не решается, и предложу альтернативу.
Не сделает ли агент чего-нибудь лишнего?
Это решается конструкцией, а не настройками модели. Агент получает отдельную учётную запись с минимальными правами и узкие инструменты вместо универсального доступа; лимиты и проверки выполняются кодом до обращения к вашей системе, а необратимые действия требуют подтверждения человеком. Всё, что недопустимо, сделано невозможным, а не запрещённым в инструкции.
Сколько времени занимает проект?
Больше всего времени уходит не на разработку, а на интеграции, получение доступов и выяснение негласных правил процесса. Поэтому срок называется после обследования. Проверка достижимости на ваших данных делается быстро и идёт первой — она показывает, имеет ли смысл продолжать.
С чего начать, если мы не уверены, что нам нужен агент?
С оценки применимости: разбираю процесс, проверяю достижимость на вашем архиве и говорю, агентская задача или нет. Часть обращений заканчивается выводом, что достаточно бота или обычной автоматизации, — это дешевле, и я об этом скажу.

Обсудить задачу

Расскажите про процесс, который хотите автоматизировать, — отвечу, подходит ли он для агента и что потребуется для запуска.
Name
Email
Phone
Имя
Телефон
E-mail
Комментарий
Ознакомлен(а) и даю согласие на обработку персональных данных в соответствии с  Политика обработки персональных данных, Согласие на обработку персональных данных
Заявка успешно отправлена

Дополнительные материалы

Разница между тремя классами решений сводится к одному: что система делает с результатом своей работы. Чат-бот отвечает текстом, ассистент готовит результат для человека, агент выполняет действия в других системах и доводит задачу до конца. Из этого следуют разная стоимость, разные риски и разные требования к контролю — поэтому вопрос «нам нужен бот или агент» решается до обсуждения технологий.
Разработка агента идёт по тому же порядку, что и любой ИИ-проект, но добавляет четыре работы, которых в проекте бота нет: проектирование инструментов, ограничение полномочий, песочница для безопасных прогонов и тестирование многошаговых сценариев. Именно они, а не «более умная модель», определяют разницу в стоимости и сроках.
Агент окупается там, где задача состоит из нескольких шагов, порядок шагов заранее неизвестен, а результат проверяем. Ниже пятнадцать сценариев, сгруппированных по сложности внедрения: от тех, что запускаются за недели, до требующих серьёзной подготовки. В конце — сценарии, где агент не нужен, хотя его часто предлагают.
Подключение ИИ-агента к CRM упирается не в ИИ, а в три обычных вопроса: есть ли у системы пригодный API, какие права выдать агенту и какие -операции он может выполнять без подтверждения. Ответы на них определяют и стоимость проекта, и его выполнимость — иногда выясняется, что задача в разумные деньги не решается, и лучше узнать это до начала работ.
Function calling — механизм, при котором модель не выполняет действие сама, а возвращает структурированное намерение его выполнить: имя функции и параметры. Решение о запуске принимает ваш код. Это ключевая деталь для понимания рисков: модель не имеет доступа к системам, у неё есть только право попросить, а проверки и полномочия остаются на стороне приложения.
MCP (Model Context Protocol) — открытый протокол, стандартизующий способ подключения инструментов и источников данных к языковым моделям. Он решает не техническую, а организационную задачу: описать интеграцию один раз и переиспользовать её в разных приложениях и с разными моделями, вместо того чтобы переписывать под каждое решение. Для одного агента с парой инструментов это лишний слой; окупается он при нескольких потребителях.
Несколько агентов вместо одного оправданы, когда задача распадается на части с разными инструментами и разными правами, а не когда она просто большая. Разделение ради «специализации» без такой границы почти всегда ухудшает результат: растут стоимость, задержка и сложность отладки, а качество не меняется. Начинать нужно с одного агента и делить его, только упёршись в конкретное ограничение.
У модели нет памяти: каждый запрос она обрабатывает с нуля, а всё, что «помнит» агент, ему передают заново с каждым обращением. Отсюда главное практическое следствие — память стоит денег: чем больше передаётся, тем дороже каждый шаг. Задача проектирования не в том, чтобы помнить всё, а в том, чтобы передавать необходимый минимум.
Ограничения агента строятся в коде и в правах доступа, а не в инструкции для модели. Формулировка «не создавай сделки дороже миллиона» — пожелание вероятностной системе, которая может его не выполнить; проверка суммы перед вызовом — гарантия, которая не зависит от того, что решила модель. Это главный принцип: всё, что нельзя нарушить, должно быть невозможно, а не запрещено.
Граница проходит не по «уровню доверия к ИИ», а по свойствам самого действия: обратимо ли оно и будет ли ошибка замечена. Обратимое и заметное действие агент может выполнять сам. Необратимое либо незаметное требует подтверждения человеком — независимо от того, насколько хорошо агент работает на тестах.
Агент сам решает, сколько шагов сделать, и это отличает его от бота с предсказуемой стоимостью обращения. Обратная сторона — он способен повторять действия бесконечно, расходуя деньги и, если действия меняют данные, создавая дубликаты. Защита строится не на качестве промпта, а на жёстких лимитах: число шагов, повторы, потолок расходов и время выполнения ограничиваются кодом.
Обработка входящих заявок — один из лучших первых сценариев для агента: объём высокий, шаги однотипные, а ошибка обратима — неверно оформленную заявку легко поправить. Агент разбирает обращение, извлекает данные, проверяет дубликаты, создаёт запись в CRM и назначает ответственного. Экономия возникает не на самом создании записи, а на разборе разнородных обращений, который до этого делал человек.
Работа с документами — задача, где агент даёт наибольшую экономию и требует наибольшего внимания к контролю. Он извлекает данные из счетов, накладных, анкет и договоров, сверяет их с учётной системой и заносит результат
Выбор определяется не бюджетом, а четырьмя вопросами: какие системы нужно подключить, где обрабатываются данные, насколько нестандартна логика и что будет при росте объёма. Платформа выигрывает на старте и на типовых сценариях; разработка окупается там, где платформа упирается в потолок.
Стоимость эксплуатации агента отличается от стоимости бота одним свойством: число обращений к модели на задачу заранее неизвестно. Бот делает одно обращение, агент — от трёх до тридцати, и решает это он сам. 
Агента нельзя проверить так же, как бота. У бота есть правильный ответ, с которым сравнивают выданный; у агента к цели ведут несколько допустимых путей, и число шагов заранее неизвестно. Поэтому проверяется результат сценария целиком плюс поведение в нештатных ситуациях, а не совпадение с эталоном.