Разработка и внедрение ИИ-агентов: архитектура, стек, цена, риски
Агент отличается от чат-бота одним признаком — правом на действие в ваших системах. Разбираю, как он устроен внутри, где окупается, из чего складывается стоимость разработки ИИ-агента и что ломается при внедрении.
Разработка ИИ-агентов — это передача машине права совершать действия в ваших системах: менять статус сделки, отправлять письмо, создавать задачу, формировать документ. Внедрение ИИ-агентов окупается там, где процесс частый, регламентированный и дорогой в ручном исполнении, и проваливается там, где регламента нет и решение каждый раз принимается «по ситуации». Ниже — как агент устроен внутри, чем разработка AI-агентов отличается от разработки чат-бота, из чего складывается цена и что ломается при подключении к боевому контуру.
Что вы заказываете, когда заказываете разработку ИИ-агентов
Разработка ИИ-агентов отличается от всего остального в мире ИИ ровно одним признаком: агент имеет право на действие. Языковая модель генерирует текст. Ассистент подсказывает человеку. Агент сам меняет состояние вашей системы — и за это состояние потом отвечает компания, а не модель. Внедрение ИИ-агентов — это, по сути, найм сотрудника без трудового договора, которому вы выдаёте доступы к CRM, почте и складу.
Именно поэтому разговор про разработку AI-агентов начинается не с выбора модели, а с вопроса «какие действия мы готовы отдать» и «что произойдёт, если действие будет ошибочным». В проектах, которые я видел, до 70% времени первого контура уходит не на промпты и не на код, а на описание границ: что агент делает сам, что делает с подтверждением, чего не делает никогда.
Если вы ещё не решали более общий вопрос — нужна ли вам собственная система или хватит готового сервиса, — сначала стоит посмотреть, как вообще устроена разработка ИИ и как ставить задачу подрядчику. Агент — частный и самый дорогой случай этой разработки.
Агент — это не «умный бот». Агент — это делегированное полномочие. Всё остальное в проекте — техника исполнения этого полномочия.Владимир Герасимов
Чат-бот, ассистент, агент, мультиагентная система: четыре уровня права на действие
Четыре уровня различаются не «умом», а объёмом полномочий. Чат-бот отвечает по сценарию. ИИ-ассистент отвечает свободно, но результат применяет человек. ИИ-агент сам выбирает инструмент и выполняет действие. Мультиагентная система распределяет задачу между несколькими агентами с разными ролями и правами. Разработка ИИ-чат-ботов и разработка ИИ-агентов — это два разных проекта по бюджету, срокам и рискам, хотя внешне оба выглядят как окно переписки.
| Уровень | Что решает | Право на действие | Типовой срок первого контура |
|---|---|---|---|
| Чат-бот со сценарием | Отвечает на частые вопросы по дереву | Нет. Только текст | 2–4 недели |
| ИИ-ассистент | Ищет, обобщает, готовит черновик | Нет. Действие выполняет человек | 4–8 недель |
| ИИ-агент | Доводит задачу до результата в системе | Да, в пределах регламента | 8–16 недель |
| Мультиагентная система | Ведёт сквозной процесс с несколькими ролями | Да, с разделением прав между ролями | от 4 месяцев |
Практический вывод простой. Если вам нужна разработка ИИ-бота для ответов на типовые вопросы — не платите за агента. Если нужна разработка ИИ-помощника, который собирает информацию из нескольких систем и отдаёт человеку готовый черновик, — тоже не платите за агента. Внедрение ИИ в чат-бот первой линии закрывает 60–70% запросов, с которыми ко мне приходят «за агентом», и стоит в три-пять раз дешевле.
Самая частая ошибка — заказать агента там, где хватило бы ассистента. Компания платит за планировщик, guardrails и аудит-лог, а использует систему как поиск по базе знаний. Разработка ИИ-ассистентов в этом сценарии даёт тот же эффект в P&L при существенно меньшей смете. Внедрение ИИ-ассистента к тому же не требует ответа на юридический вопрос «кто отвечает за автоматическое действие» — действие по-прежнему совершает сотрудник.
Архитектура ИИ-агента: семь узлов, без которых это демо
Архитектура и разработка ИИ-агентов держатся на семи узлах: цель, память, инструменты, планировщик, критик, guardrails и аудит-лог. Демо, которое собирают за неделю, обычно содержит два из них — модель и инструменты. Продакшен-агент требует всех семи, и именно недостающие пять определяют разницу между «работает на показе» и «работает в понедельник утром на реальном потоке».
Формальный признак «задача закрыта». Без него агент либо крутится в цикле, либо останавливается на полпути и считает это успехом.
Короткая (контекст диалога), рабочая (состояние задачи) и долгая (база знаний, история клиента). Разные хранилища, разные сроки жизни, разные права доступа.
Функции с описанным контрактом: прочитать сделку, создать задачу, отправить письмо. Каждый инструмент отдельно помечен как читающий или изменяющий данные.
Разбивает задачу на шаги и выбирает инструмент. Здесь же ограничение на число шагов и на стоимость одного прогона.
Второй проход, который проверяет результат до его применения: полнота, формат, соответствие регламенту. Дешёвый способ убрать большую часть брака.
Жёсткие правила вне модели: белый список действий, лимиты на суммы и объёмы, обязательное подтверждение человеком, запрет на работу с определёнными полями.
Полная запись: что агент видел, что решил, что сделал, что вернула система. Без этого невозможен ни разбор инцидента, ни улучшение качества.
Отдельно скажу про критика и аудит-лог. В проектах, которые я видел, именно эти два узла чаще всего вырезают из сметы «на первом этапе, потом добавим». Потом не добавляют. Через три-четыре месяца случается первый спорный случай, разобрать его нечем, и доверие к системе падает до нуля за один разговор с руководителем.
Хороший маркер зрелости проекта: попросите подрядчика показать не диалог с агентом, а трассу одного выполненного задания — цепочку «вход → план → вызовы инструментов → результат». Если такой трассы нет, перед вами демо, а не система, независимо от того, как она выглядит на экране.
Стек: на чём собирают агентов и при чём тут LangChain
Стек агента состоит из четырёх слоёв: модель, оркестратор, слой инструментов и интеграционный слой. Модель может быть облачной или развёрнутой в вашем контуре. Оркестратор — это код, который связывает планировщик, память и вызовы инструментов; в большинстве проектов это Python. Запрос «искусственный интеллект с LangChain: разработка ИИ-агентов» отражает реальность рынка: LangChain-подобные оркестраторы стали дефолтом, но они не обязательны и не бесплатны по сложности.
Я отношусь к фреймворкам спокойно. Оркестратор экономит недели на старте и добавляет слой абстракции, который потом мешает отлаживать. Для одного-двух сценариев с пятью инструментами собственный код на Python часто проще и предсказуемее. Для десятка сценариев с общей памятью и ролями фреймворк оправдан. То, что сейчас называют агентной инженерией, — это практическое руководство по AI-разработке в этой конкретной области, а не новая дисциплина: те же требования к контрактам, тестам и логам, что и в обычном бэкенде.
Свой код или фреймворк
- Выбирают фреймворк первым решением проекта.
- Инструменты пишут «под сценарий», без контракта и без тестов.
- Промпт правят руками после каждой жалобы — регрессий никто не ловит.
- Модель выбирают самую сильную на все шаги подряд.
- Сначала описывают процесс и список действий, потом выбирают инструменты разработки.
- Каждый инструмент — функция с валидацией входа и выхода и отдельным тестом.
- Набор из 50–200 реальных кейсов, на котором прогоняют любое изменение промпта.
- Тяжёлая модель — на планирование и критику, лёгкая — на рутинные шаги. Разница в стоимости прогона бывает в разы.
Мне регулярно пишут в формате «учимся на Питоне разработке AI-агента, что читать дальше». Отвечаю одинаково: язык здесь наименьшая проблема. Заказная разработка ПО и AI-агентов упирается не в синтаксис, а в то, что процесс внутри компании не описан — и агенту нечего исполнять.
Где ИИ-агенты окупаются: семь процессов с понятной экономикой
ИИ-агент окупается на процессах с тремя признаками одновременно: высокая частота, письменный регламент, измеримая цена ручного исполнения. Внедрение ИИ-агентов в бизнес-процессы даёт эффект в первую очередь на «конвейере» — там, где одно и то же действие повторяется сотни раз в месяц. Ниже семь процессов, которые в моей практике чаще других доходят до продакшена и остаются там.
- Первая линия поддержки. Агент отвечает, проверяет статус в системе, создаёт обращение и эскалирует человеку по чётким признакам. Снимает типовой поток, не трогая сложные случаи.
- Обработка входящих заявок. Квалификация, обогащение данными, назначение ответственного, первичный ответ в течение минуты. Здесь агент почти всегда даёт эффект за счёт скорости реакции, а не за счёт экономии ФОТ.
- Документооборот. Разбор входящих документов, сверка реквизитов и сумм, маршрутизация на согласование, подготовка ответных писем.
- Подготовка коммерческих предложений. Сбор параметров сделки, подстановка условий из прайса и матрицы скидок, сборка КП, отправка на проверку менеджеру.
- Контроль дебиторки. Ежедневная выборка просрочек, вежливые напоминания по эскалационной лестнице, фиксация обещаний оплаты, передача сложных случаев юристу.
- ИИ-менеджер по продажам. Разработка ИИ-менеджера имеет смысл на потоковых сделках с коротким циклом: ведение переписки, дожим до следующего шага, запись всего в карточку. На сложных длинных сделках — нет.
- ИИ-сотрудник в бэк-офисе. Разработка ИИ-сотрудников для рутинных операций закупок, кадрового документооборота, сверок и отчётности — там, где действия предсказуемы и проверяемы.
Цифры выше — диапазоны из проектов, которые я видел, а не отраслевая статистика. Разброс между компаниями огромный и зависит в основном от качества данных и от того, насколько процесс описан до начала работ. Отраслевые особенности — где эффект появляется быстрее, а где упирается в регулирование — я разбираю в материале о внедрении ИИ по отраслям.
Отдельный класс: агент в проектной работе
Помощник ИИ для проектов — это не то же самое, что агент в операционном процессе. Здесь ценность в подготовке и контроле, а не в автоматическом действии. Типичный ИИ-бот для создания проекта собирает черновик устава, реестр рисков, календарный план и матрицу ответственности из брифа и переписки; ИИ-бот проектного офиса следит за сроками и подсвечивает расхождения план-факт. Разработка ИИ-агента для бизнеса в этом контуре обычно останавливается на уровне ассистента — и это правильно, потому что цена ошибки в проектных решениях высокая, а частота низкая. Подробнее — в материале об ИИ в управлении проектами.
Где ИИ-агент не окупается
ИИ-агент не окупается на редких, не описанных и юридически чувствительных процессах. Если действие совершается реже нескольких раз в неделю, если каждое решение требует профессионального суждения, если ошибка стоит дороже годовой экономии — агент не нужен, нужен нормальный интерфейс для человека.
- Процесс без письменного регламента: агенту нечего исполнять, а «пусть научится по переписке» не работает на действиях.
- Меньше 50–100 однотипных операций в месяц: экономия не покрывает даже поддержку.
- Решения с высокой ценой ошибки и без возможности отката — платежи, отгрузки, юридически значимые ответы без человека в контуре.
- Данные разбросаны по файлам и головам сотрудников: сначала данные, потом агент.
- Нет владельца процесса на стороне бизнеса: некому принимать решения о границах и не с кого спросить за метрику.
- Процесс через квартал меняется целиком: вы оплатите разработку дважды.
Отказ от агента — нормальный результат диагностики. Чаще всего вместо него мы находим один-два участка, где та же деньги дают простая интеграция и ассистент. Как в принципе выбирается первый процесс и почему четыре пилота из пяти не доходят до прибыли — в опорном материале о внедрении ИИ в бизнес.
Разберу два-три ваших процесса по критериям частоты, регламента и цены ошибки и скажу прямо, где агент даст деньги, а где вы переплатите за архитектуру.
Стоимость разработки ИИ-агента: из чего складывается вилка
Стоимость разработки ИИ-агента складывается из пяти статей: постановка и регламент, интеграционный слой, ядро агента, контур безопасности и приёмки, поддержка. Разработка ИИ-агента цена которого названа до описания процесса — это не смета, а лотерея: одна и та же формулировка задачи разворачивается в проект, отличающийся по трудоёмкости в пять раз. Ниже структура, по которой я разбираю любое предложение подрядчика.
| Статья | Что в неё входит | Доля бюджета |
|---|---|---|
| Постановка и регламент | Описание процесса, список действий, границы полномочий, сценарии эскалации | 15–30% |
| Интеграционный слой | Доступ к CRM, ERP, почте, телефонии; права, справочники, тестовый контур | 20–35% |
| Ядро агента | Планировщик, память, инструменты, критик, промпты, тестовый набор кейсов | 20–30% |
| Безопасность и приёмка | Guardrails, аудит-лог, пилот на ограниченном потоке, метрики качества | 10–20% |
| Поддержка, год | Дообучение на новых кейсах, реакция на изменения систем, стоимость прогонов модели | 15–25% от разработки ежегодно |
Три статьи, которые не попадают в первое предложение подрядчика
Три вещи, которые чаще всего не попадают в первую смету и потом всплывают. Первое — стоимость прогонов модели на реальном объёме: в демо она незаметна, на потоке становится отдельной строкой операционных расходов. Второе — работа на стороне заказчика: кто-то должен размечать кейсы и принимать результат. Третье — доработка систем-приёмников: часто выясняется, что нужного поля в CRM просто нет.
Когда меня спрашивают, сколько стоит разработка ИИ-ассистента, я отвечаю встречным вопросом: сколько операций в месяц и сколько стоит одна в ручном исполнении. Без этих двух чисел цена бессмысленна. Полные вилки бюджетов по типам задач и формулу расчёта эффекта в рублях я собрал отдельно — в материале о стоимости внедрения ИИ и расчёте ROI.
Посчитаю трудоёмкость по пяти статьям выше на вашем процессе и покажу, какие строки подрядчик обычно не указывает в первом предложении.
Интеграция ИИ-агента с CRM и внутренними системами
Интеграция ИИ-агентов с CRM — это не «подключить API», а описать набор разрешённых операций над карточками и правила разрешения конфликтов. Агент должен уметь читать сделку, писать в ограниченный список полей, создавать задачу и комментарий — и не должен уметь удалять, объединять и менять ответственного без подтверждения. ИИ-менеджер, интеграция с CRM у которого сделана «полными правами», рано или поздно испортит данные, и восстанавливать их будет дороже, чем стоил проект.
Технически подключение выглядит одинаково для любой системы: сервисная учётная запись с урезанными правами, отдельный тестовый контур, идемпотентные операции и очередь на повтор при сбое. Интеграция ИИ-агента с BPMSoft, Битрикс24, amoCRM или самописной системой различается объёмом работы по справочникам, а не принципом. Механику подключения — способы, локальные модели, контур безопасности и типовые ошибки — я подробно разбираю в статье об интеграции ИИ в существующие системы.
- Сервисный пользователь с минимально необходимыми правами, а не админский токен.
- Белый список полей на запись и явный чёрный список действий.
- Идемпотентность: повтор запроса не создаёт вторую сделку и не отправляет письмо дважды.
- Тестовый контур с копией справочников — агент не учится на боевых данных.
- Все действия агента помечены источником, чтобы их можно было отфильтровать и откатить.
- Бот с интеграцией ИИ в мессенджере — отдельный канал, а не отдельная логика: правила действий общие.
Риски внедрения ИИ-агентов: право действия, эскалация, откат
Главные риски внедрения ИИ-агентов лежат не в качестве текста, а в праве действия. Три из них закрывают большую часть реальных инцидентов: избыточные полномочия, отсутствие эскалации и невозможность отката. Всё остальное — качество ответов, тон, галлюцинации — лечится тестовым набором и критиком, а эти три ломают процесс целиком.
- Ограничьте полномочия по умолчаниюАгент начинает с прав «только чтение», действия добавляются по одному, после того как на пилоте набрана статистика по этому действию. Обратный порядок — выдать всё и потом урезать — на практике не случается никогда.
- Опишите эскалацию как правило, а не как настроение моделиПризнаки передачи человеку должны быть формальными: сумма выше порога, статус клиента, отсутствие данных, повторное обращение, эмоциональный маркер. Модель определяет, что признак сработал; решение об эскалации принимает код.
- Сделайте откат до запускаДля каждого изменяющего действия должна существовать обратная операция или компенсация. Если откат невозможен технически или юридически — это действие идёт через подтверждение человеком, без исключений.
- Введите лимиты на прогон и на суткиМаксимум шагов на задачу, максимум действий в час, максимум суммы. Лимит — это дешёвая страховка от цикла, в который агент иногда уходит.
- Назначьте владельца и метрикуОдин человек в бизнесе отвечает за долю автоматически закрытых задач, долю эскалаций и число инцидентов. Без владельца агент через полгода тихо отключают.
Отдельный вопрос — правовой контур: персональные данные, тайна переписки, ответственность за автоматическое решение в отношении клиента. Здесь я не даю универсальных ответов, потому что они зависят от отрасли и от того, что записано в ваших документах. Двенадцать типовых способов потерять деньги на ИИ и практику безопасной разработки я собрал в материале о рисках и проблемах внедрения ИИ.
Опасный момент наступает не в первый месяц, а на третий-четвёртый, когда команда привыкает к агенту и перестаёт проверять. Если к этому времени не выстроена выборочная проверка — скажем, ручной контроль случайных 5–10% действий, — ошибки накапливаются молча и обнаруживаются на закрытии периода.
Чек-лист готовности процесса к агенту
Процесс готов к агенту, если на все восемь пунктов ниже вы отвечаете «да» без оговорок. Шесть «да» из восьми — начинайте с ассистента. Меньше пяти — сначала наведите порядок в процессе, ИИ здесь ничего не исправит, а только зафиксирует беспорядок в коде.
- Процесс описан письменно, и описание совпадает с тем, как работают люди.
- Частота — от 100 операций в месяц, объём измерен, а не оценён на глаз.
- Известна стоимость одной ручной операции в деньгах или в минутах.
- Данные для решения лежат в системах, а не в головах и почтовых ящиках.
- Определён список действий и явные границы: что агент делает сам, что с подтверждением, чего не делает.
- Для каждого действия существует откат или компенсирующая операция.
- Есть владелец процесса со стороны бизнеса и согласованная метрика успеха.
- Есть 50–200 исторических кейсов, на которых можно измерить качество до запуска.
Этот чек-лист — сжатая версия диагностики, которую я провожу до старта. Как выглядит вся последовательность работ от диагностики до продакшена, я описал в материале о этапах и дорожной карте внедрения ИИ.
Кто это делает: своя команда, агентство, курс или советник
Разработку ИИ-агентов делают три типа исполнителей, и выбор между ними определяется не бюджетом, а тем, кто отвечает за постановку задачи. Своя команда сильна, когда процесс уникален и его нужно долго дорабатывать. Агентство по внедрению ИИ быстрее на старте и дороже в поддержке. Советник нужен там, где неочевидно, какой процесс вообще отдавать машине, — то есть в большинстве случаев.
Запрос «стратегическое агентство поддержки и формирования ИИ-разработок» я встречаю регулярно, и за ним обычно стоит понятная боль: подрядчиков много, каждый предлагает своё, а внутри компании нет человека, который может их сравнить по существу. Моя роль здесь — не заменить разработчиков, а поставить задачу так, чтобы её можно было принять и посчитать. Кто именно нужен в команде и какие компетенции нельзя отдавать наружу — в материале о команде и специалистах по ИИ.
Про обучение. Курс по разработке ИИ-агентов имеет смысл для вашей внутренней команды, если вы уже решили строить компетенцию внутри и у вас есть поток задач под неё. Курсы по внедрению ИИ-агентов для руководителя полезны иначе — они дают язык для разговора с подрядчиком. Но ни один курс не заменяет описанного процесса: я видел команды, прошедшие обучение и застрявшие ровно на том же месте — им нечего было автоматизировать.
География роли почти не играет. Запросы вида «разработка ИИ-агента Екатеринбург» или «разработка ИИ-агента Ташкент» отражают привычку искать подрядчика рядом, но агентные проекты собираются распределённо: доступ к системам даётся удалённо, а критичен не адрес команды, а её опыт в вашем классе процессов и готовность работать в вашем контуре безопасности.
Сформулирую техническое задание на понятном подрядчику языке, разберу поступившие предложения по структуре сметы и определю критерии приёмки, по которым агента можно будет запускать в боевой контур.
Работающая последовательность одна и та же почти во всех проектах: один процесс, одно действие, ограниченный поток, две недели наблюдения, затем расширение прав. Компании, которые начинают с «сделаем ИИ-сотрудника на весь отдел», в моей практике доходят до продакшена заметно реже тех, кто начал с одной операции и одной метрики.
Частые вопросы
ИИ-агент — это система, которая сама выполняет действия в ваших системах: меняет статус сделки, создаёт задачу, отправляет документ. Чат-бот только отвечает по сценарию, ИИ-ассистент отвечает свободно, но применяет результат человек. Разработка ИИ-чат-ботов и разработка ИИ-агентов различаются по бюджету и срокам в разы, хотя внешне обе системы выглядят как окно переписки.
Стоимость разработки ИИ-агента складывается из пяти статей: постановка и регламент (15–30% сметы), интеграционный слой (20–35%), ядро агента (20–30%), безопасность и приёмка (10–20%) и поддержка — ещё 15–25% от разработки ежегодно. Разработка ИИ-агента, цена которого названа до описания процесса, — это не смета, а лотерея: одна и та же формулировка задачи разворачивается в проекты, отличающиеся по трудоёмкости в пять раз. Точные вилки бюджетов разобраны в материале о стоимости внедрения ИИ.
В проектах, которые я видел, первый рабочий контур агента занимает 8–16 недель, ассистента — 4–8 недель, простого бота — 2–4 недели. Мультиагентная система с несколькими ролями — от четырёх месяцев. До 70% этого времени уходит не на код, а на описание процесса и границ полномочий.
Три главных риска связаны с правом на действие: избыточные полномочия, отсутствие формальной эскалации и невозможность отката. Лечатся они не качеством модели, а архитектурой: старт с прав «только чтение», эскалация по формальным признакам в коде, обратная операция для каждого изменяющего действия и лимиты на число шагов и суммы. Правовой контур и персональные данные я разбираю отдельно в материале о рисках и проблемах внедрения ИИ.
Интеграция ИИ-агентов с CRM — это описанный набор разрешённых операций над карточками, а не просто подключение по API. Нужны сервисный пользователь с урезанными правами, белый список полей на запись, идемпотентные операции и пометка источника у всех действий агента, чтобы их можно было отфильтровать и откатить. Интеграция ИИ-агента с BPMSoft, Битрикс24 или самописной системой различается объёмом работы по справочникам, а не принципом.
Нет, LangChain и подобные оркестраторы не обязательны. Для одного-двух сценариев с пятью инструментами собственный код на Python обычно проще и предсказуемее в отладке. Фреймворк оправдан там, где сценариев десяток, у них общая память и разные роли с разными правами.
Курс по разработке ИИ-агентов полезен внутренней команде, если решено строить компетенцию внутри и под неё есть поток задач. Курсы по внедрению ИИ-агентов для руководителя дают язык для разговора с подрядчиком, но не заменяют описанного процесса. Я видел команды, прошедшие обучение и застрявшие на том же месте: автоматизировать было нечего.
Процесс готов, если он описан письменно, идёт не реже 100 операций в месяц, стоимость одной операции измерена, данные лежат в системах, определены границы полномочий, для каждого действия есть откат, назначен владелец со стороны бизнеса и накоплено 50–200 исторических кейсов для замера качества. Восемь «да» — можно начинать с агента, шесть — начинайте с ассистента, меньше пяти — сначала наведите порядок в процессе.
Практически нет. Агентные проекты собираются распределённо: доступ к системам выдаётся удалённо через сервисные учётные записи и тестовый контур. Значение имеют опыт команды в вашем классе процессов и готовность работать по вашим правилам безопасности, а не адрес офиса.