Разработка ИИ-агентов для бизнеса: от первой задачи до результата

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ещё один термин, который встретится при разработке, — MCP. Это стандарт подключения AI-приложений к данным и инструментам. Он помогает организовать взаимодействие, но правила доступа и допустимые действия всё равно задают в проекте. Возможность подключиться к CRM ещё не означает право менять в ней любые сведения.

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

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

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

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

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

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

В кейсе «Нейрориторики» торгово-производственная компания получает письма через Битрикс24. Схема на n8n извлекает содержание, подготавливает текст, классифицирует обращение и передаёт подходящие заявки менеджерам. Уведомления уходят в Telegram.

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

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

Похожую пользу на уровне конкретной операции показывает System AI для The Srama Group: в кейсе описан ввод данных за 10–20 секунд вместо 4–5 минут. А изменение длительности всей продажи, упомянутое там же, уже требует отдельного разбора причин. На сделку влияют цена, спрос и работа менеджера, поэтому ускорение ввода данных нельзя автоматически перевести в рост выручки.

У Wiley есть сравнение с прежним ботом: по материалу Salesforce, в первые недели Agentforce улучшил разрешение обращений более чем на 40%. При этом приведённые рядом ROI 213% и годовая экономия 230 тысяч долларов относятся к более широкому внедрению Service Cloud. Приписывать эти деньги одному агенту было бы ошибкой.

В кейсе Intercom Fin собраны несколько клиентских примеров. Для Synthesia указаны более 6 тысяч обработанных диалогов и более 1 300 сэкономленных часов за полгода. Fundrise за три месяца автоматизировала более половины объёма поддержки; заявленная точность ответов составила 95%. У Lightspeed доля разрешённых обращений достигает 65% при стабильной удовлетворённости клиентов.

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

Даже период рядом с денежной суммой имеет значение. В кейсе Assembled о Thrasio заявлена экономия почти двух миллионов долларов, но её период не указан. Добавить при пересказе «в год» — значит изменить смысл результата.

В видео 3R.agency описан поиск закупок для производителя уличного освещения. Система получает данные через API, отбирает потенциально подходящие закупки, разбирает документы и архивы, ищет номенклатуру. Результат попадает в таблицу со ссылками и карточку amoCRM.

Автор заявляет сокращение времени поиска и обработки на 70–80%. Однако время работы алгоритма и время сотрудника различаются; труд на проверку и полнота поиска в описании не раскрыты. Самая полезная для проектирования деталь — возможность открыть документ и проверить, откуда взялась найденная позиция.

Похожий сценарий описывает ОМК ИТ в материале Yandex Cloud. При тестировании разбор тендерного документа стал примерно на 70% быстрее. Отдельно компания сообщает о внедрении обработки предложений поставщиков: время сократилось на 57%, количество ошибок — примерно на 10%. Это два разных сценария и два замера, их следует так и сохранять.

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

C.H. Robinson сообщала, что к апрелю 2025 года её AI-системы выполнили более 3 миллионов задач. Это показатель рабочего масштаба. Чтобы оценить экономию, дополнительно понадобятся данные о трудозатратах, исправлениях и стоимости обработки.

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

Есть полезные примеры и среди систем с меньшей самостоятельностью. Eaton описывает подготовку документов с Copilot, а Delivery Hero — восстановление доступа через согласования и API. В последнем случае использование языковой модели не подтверждено. Такие истории помогают увидеть, какие части задачи можно решить обычной автоматизацией или ассистентом.

У Adecco Group в кейсе указано ускорение полного процесса подбора на 28%. Отдельно измеряется подготовка кампаний. Результат относится к сочетанию данных, шаблонов и агентных действий, поэтому заранее приписывать весь эффект одному компоненту нельзя.

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

А в исследовании METR начала 2025 года 16 опытных разработчиков выполнили 246 задач в знакомых проектах. С доступными тогда AI-инструментами работа заняла на 19% больше времени. Этот результат относится к условиям эксперимента. В обновлении 2026 года авторы обсуждают влияние отбора участников и неопределённость новых оценок. Универсального процента ускорения разработки эти материалы не дают.

В контенте важно так же аккуратно разделять этапы. Автор кейса Generation AI / Just AI сообщает о сокращении времени подготовки материала с 4–5 до 1,5–2 часов при работе с Claude Code. Позже он описывает более сложную систему из нескольких агентов, но прежний замер нельзя автоматически приписать этой новой схеме.

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

Цена зависит от процесса и состава работ. В исследованной выборке есть ограниченное платформенное предложение за 30 тысяч рублей и заказная разработка от 500 тысяч. Они описывают разные продукты и не дают средней цены рынка. Перед заказом условия предложения нужно проверить заново.

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

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

Возьмём условный пример. Компания обрабатывает 1 000 однотипных задач в месяц. Раньше на каждую уходило шесть минут, после внедрения сотрудник тратит две минуты на проверку и завершение. Высвобождается 4 000 минут, или примерно 67 часов.

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

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

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

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

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

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

Для пилота стоит подготовить такие случаи:

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

Внешние письма и документы содержат данные, но могут содержать и попытки управлять системой: например, просьбу проигнорировать правила или отправить сведения по чужому адресу. Проверка вторым агентом может быть одним из защитных механизмов, однако сама по себе не даёт гарантии. Материалы OWASP и Yandex Cloud помогают составить техническую программу проверки.

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

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

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

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

Дальше работа строится по этапам:

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

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

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