ИИ-агенты для бизнеса: от чат-бота к системе, которая выполняет действия
Словом «агент» сейчас называют слишком много разных вещей. Я бы смотрел не на название, а на то, может ли система получить нужный контекст, выполнить ограниченное действие и проверить, что после этого произошло.
Сначала договоримся, что именно называем агентом
С AI-агентами сейчас есть простая проблема: этим словом называют почти всё подряд. Чат с хорошим системным промптом может называться агентом. Бот, который умеет вызвать одну функцию, тоже. А рядом под тем же названием продают систему, которая сама собирает контекст, выбирает инструмент, меняет состояние другого продукта и потом проверяет результат.
Для бизнеса это не терминологический спор. Если система только отвечает текстом, риск и ценность у неё одни. Если она может создать задачу, изменить запись в CRM, запустить расчёт или подготовить изменение в коде, требования становятся совсем другими.
Поэтому я использую довольно приземлённое определение: агент начинается там, где модель работает не только с сообщением пользователя, но ещё с текущим состоянием задачи, набором разрешённых инструментов и понятным циклом «получил данные → принял решение → выполнил действие → проверил результат».
Где заканчивается чат-бот и начинается рабочий агент
Чат-бот обычно живёт внутри диалога. Он получает вопрос, возможно подтягивает документы через RAG, формирует ответ и на этом заканчивает работу. Для поддержки, поиска по базе знаний или подготовки черновиков этого часто достаточно.
Агенту этого мало. Ему нужно понимать, что сейчас происходит в системе, какие действия вообще допустимы и какой результат считать успешным. Важная деталь: возможность вызвать API сама по себе ещё не делает систему агентной. Если модель просто нажимает одну заранее определённую кнопку, это скорее удобный интерфейс к автоматизации.
- Контекст: не весь доступный массив данных, а ровно то состояние, которое нужно для текущей задачи.
- Инструменты: ограниченный набор операций с понятными входами, выходами и правами.
- Состояние: агент должен понимать, что уже сделал и что изменилось после действия.
- Проверка: результат действия нужно уметь проверить, а не считать успешным только потому, что API вернул 200.
Контекст и инструменты важнее «самой умной модели»
На практике качество агентной системы очень быстро упирается не в выбор модели, а в качество контекста и инструментов. Можно взять сильную модель и дать ей половину проекта одним огромным промптом. Она будет много знать, но плохо понимать, что из этого относится к текущей задаче.
Мне ближе другой подход: контекст собирается под конкретный запрос. Сначала поиск находит релевантные участки, затем добавляются зависимости и текущее состояние, а уже после этого модель получает ограниченный набор действий. Такой JIT-контекст обычно полезнее, чем попытка каждый раз отправлять «всё, что у нас есть».
С инструментами та же история. Хороший tool для агента не должен быть слишком универсальным. Операция вроде «выполни произвольную shell-команду» удобна разработчику прототипа, но почти ничего не говорит о допустимом поведении системы. Намного спокойнее жить с инструментом уровня «прочитай файл», «подготовь ChangeSet», «запусти конкретную проверку» или «создай задачу с такими-то обязательными полями».
Как это выглядит в реальном рабочем контуре
В своей среде для работы с проектами я специально не хотел давать модели произвольный доступ к репозиторию. Задача была обратной: сделать так, чтобы AI видел актуальное состояние проекта, но любые изменения проходили через проверяемый процесс.
Поэтому контур получился многоступенчатым. Проект индексируется, retrieval находит релевантные фрагменты, под задачу собирается bounded JIT-контекст. Перед изменением можно оценить радиус затрагиваемых файлов и контрактов. Само изменение готовится через Direct ChangeSet, после него запускаются проверки, а итоговое состояние фиксируется новым snapshot.
Получилось менее эффектно, чем демонстрация «агент сам переписал полпроекта». Зато этим можно пользоваться каждый день. Если агент ошибается, понятно, на каком шаге это произошло. Если операция потенциально опасная, её можно вообще не выдавать модели или потребовать подтверждение.
Guardrails нужны не после первого инцидента, а до запуска
Самая неприятная ошибка в агентных системах — воспринимать подтверждение пользователя как единственную защиту. Человек быстро привыкает нажимать «разрешить», особенно если система большую часть времени работает правильно.
Нормальные ограничения лучше закладывать ниже: какие ресурсы видит инструмент, какие поля можно менять, какой объём операции допустим, какие проверки обязательны после действия. Подтверждение тогда остаётся дополнительным слоем, а не последней надеждой.
Ещё одна полезная привычка — логировать не внутренние рассуждения модели, а фактические действия: какой инструмент был вызван, с какими параметрами, что он вернул, что изменилось. Для диагностики это гораздо ценнее длинного текста о том, почему модель «решила» поступить именно так.
Какие процессы вообще имеет смысл отдавать агенту
Я бы не начинал с процесса, где агент должен полностью заменить человека. Хорошая первая задача обычно уже формализована, но пока требует нескольких ручных переходов между системами.
Например: собрать данные из нескольких источников и подготовить решение; проверить объект по набору правил и сформировать список проблем; создать черновик изменения и прогнать проверки; обработать входящее событие, обогатить его данными и предложить следующий шаг.
Плохой кандидат — процесс, где сама команда пока не может объяснить, что считать правильным результатом. Агент не исправит отсутствующие правила. Он просто быстрее автоматизирует неопределённость.
- Есть понятный вход и можно проверить выход.
- Большая часть шагов уже повторяется вручную.
- Ошибочное действие можно остановить, откатить или хотя бы обнаружить.
- У системы есть API или другой контролируемый способ выполнить операцию.
Как начать без большого «AI transformation» проекта
Первый агентный сценарий я бы ограничивал одной задачей и несколькими инструментами. Не нужно начинать с универсального ассистента, который знает всю компанию и может работать со всеми системами.
Сначала выбирается один процесс. Затем фиксируется, какой контекст нужен для решения и какие действия допустимы. После этого инструменты можно тестировать вообще без LLM: корректно ли они валидируют параметры, что происходит при повторном вызове, можно ли проверить результат.
Только когда эта механика устойчива, есть смысл подключать модель и смотреть, насколько хорошо она выбирает нужную операцию. Такой порядок не самый быстрый для красивой демки, зато сильно сокращает количество сюрпризов в production.
Вопросы
Чем ИИ-агент отличается от обычного чат-бота?
Чат-бот в первую очередь формирует ответ. Агент работает ещё с состоянием процесса и инструментами: может получить данные, выполнить ограниченную операцию и проверить её результат.
Нужен ли агенту RAG?
Не всегда. RAG полезен, когда нужно находить релевантный контекст в большой базе документов или данных. Для небольшого и хорошо структурированного процесса контекст можно собирать напрямую через API.
Что такое MCP в агентной системе?
MCP — способ описать доступные модели инструменты и ресурсы через единый протокол. Он удобен для интеграции, но сам по себе не решает вопросы прав, бизнес-валидации и безопасности.
Можно ли подключить агента к CRM или внутренней системе?
Да, если система даёт контролируемый API или можно построить отдельный интеграционный слой. Лучше выдавать агенту доменные операции, а не прямой доступ к базе данных.
Когда AI-агент бизнесу не нужен?
Когда задачу проще решить обычной автоматизацией, правила полностью детерминированы или команда пока не может определить, что считать правильным результатом.