Создание ИИ-агента начинается не с промпта: разбор задачи до первой строчки кода

К нам приходит директор по развитию из компании, которая ничего плохого не делала: продаёт стройматериалы, ведёт заказчиков в 1С, отвечает клиентам по почте. И говорит: «Нам нужен ИИ-агент». Иногда — «AI-агент». Иногда — «нейросеть, которая сама всё делает». Иногда — «как у соседей, они хвастались на конференции».

Первый вопрос, который мы задаём в ответ, обычно ломает половину встречи. Не «на какой модели соберём» и не «GigaChat Pro или YandexGPT». А совсем простой: «А что именно он должен делать, чтобы вы поняли, что он работает».

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

Что такое ИИ-агент, если убрать маркетинговую пыль

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

Мы обычно объясняем так. Обычный скрипт делает то, что записано в его коде: если А, тогда Б. LLM без агентности — это модель, которая на входе получает текст, на выходе отдаёт текст, и всё. А ИИ-агент — это когда модель сама решает, что ей нужно сделать: сходить в 1С, поднять карточку клиента, посмотреть переписку, посчитать остатки, сформулировать ответ, а если чего-то не хватает — переспросить.

Ключевое слово — «сама решает». Именно это отличает ИИ-агентов для бизнеса от чат-ботов и от простой обёртки над LLM. И именно из-за этой самостоятельности стоимость разработки и поддержки уходит в другую весовую категорию.

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

Три вопроса, после которых половина проектов схлопывается

За годы мы вывели небольшой чек-лист. Он не про технологии — он про то, есть ли задача вообще.

Первый вопрос: сколько вариантов действий у решения. Если сотрудник в этой роли всегда делает одно и то же — принимает заявку, заносит в 1С, отвечает шаблоном, — это не задача для ИИ-агента. Это RPA, интеграция или скрипт. Агент нужен там, где нельзя заранее написать блок-схему: например, поступает письмо, и в зависимости от контекста нужно то ли поднять договор, то ли позвать менеджера, то ли переспросить у клиента.

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

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

После этих трёх вопросов часть заказчиков уходит переосмысливать. Часть остаётся, и с ними уже можно разговаривать про то, как создать ИИ-агента конкретно под их задачу.

С чего начинается создание ИИ-агента: не с кода и не с модели

Дальше есть соблазн сразу открыть репозиторий и начать писать промпт. В 2026 году с этим ещё хуже, чем раньше: у всех подряд появились свои Agent SDK. У OpenAI — Agents SDK, у Google — ADK, у Anthropic — свой набор с иерархическими субагентами. LangGraph, CrewAI, Microsoft Agent Framework — все обрели enterprise-фичи и научились работать с MCP. У Яндекса — Agent Atelier и MCP Hub. У GigaChat — function calling и своя обвязка. Соблазн взять любой фреймворк и «просто попробовать» огромный.

Мы этот соблазн стараемся давить. Не потому что фреймворки плохие, а потому что если сначала не понял задачу, никакой фреймворк не спасёт.

Порядок работы у нас примерно такой.

Сначала — карта работы одного человека. Мы садимся с сотрудником, который сейчас решает эту задачу руками. Не с руководителем, который «примерно знает, как это устроено». Именно с исполнителем. И просим показать пять реальных кейсов от начала до конца: вот пришло письмо, вот я открыл 1С, вот я посмотрел эту вкладку, вот я подумал, вот я ответил.

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

Дальше — инструменты. Мы выписываем всё, куда человеку приходится ходить: 1С, CRM, почта, папка с договорами на диске, справочник в Excel. Каждый такой пункт — потенциальный MCP-сервер или инструмент для агента. И тут же становится понятно, где мы упрёмся: если справочник живёт в голове у Петра Сергеевича, никакой ИИ-агент его оттуда не достанет.

И только потом — модель, промпт, обвязка. Здесь как раз идёт нормальный инженерный выбор: если данные должны остаться в российском контуре — смотрим на GigaChat Pro, YandexGPT, T-Pro для локального запуска. Если задача агентно-сложная и есть право работать с зарубежными провайдерами — сравниваем актуальные варианты по цене и качеству под конкретный сценарий, а не по общим бенчмаркам.

Как выглядит первый работающий ИИ-агент

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

Черновик — важное слово. На первых неделях агент ничего не отправляет сам. Менеджер видит его предложение и либо принимает, либо правит, либо отклоняет. И вот эти отклонения — самое ценное, что происходит на проекте. Каждое несогласие сотрудника с агентом — либо ошибка в промпте, либо дырка в данных, либо тот самый скрытый контекст из головы Петра Сергеевича, который мы не выцепили на первой встрече.

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

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

Что мы поняли за десятки таких проектов

Самое дорогое в создании ИИ-агента — не токены и не разработка. Самое дорогое — согласиться делать не то, что нужно бизнесу. Красивый агент, который решает задачу, которой на самом деле нет, съедает бюджет ничуть не хуже, чем сложная архитектура.

Поэтому да, мы разрабатываем ИИ-агентов для бизнеса. Но начинаем всегда с одного и того же разговора: покажите, как это делает живой человек, и объясните, почему сейчас это перестало вас устраивать. Если после этого разговора мы понимаем, что задача не для агента, — так и говорим. Проще потерять один заказ, чем полгода спустя разбираться, почему заказчик разочарован в самой идее.

А вы как в своей компании определяете, что задача действительно созрела для ИИ-агента, а не для нормальной автоматизации?

Похожие статьи

• Кодекс ИИ-агента в продакшене: правила, которые мы выписали после нескольких дорогих ошибок
• ИИ-агент для учётной системы «Гермес»: как мы построили платформу ИИ-агентов вокруг легаси-ERP
• Локальный ИИ-агент без интернета: как мы собрали помощника инженера на T-Lite и MCP внутри периметра заказчика
• Разработка ИИ-агентов закончилась — началось обучение: как менеджер учит агента без единой строчки кода