AI-агент vs чат-бот vs workflow

Коротко

Чат-бот, workflow и AI-агент часто называют одним словом. Из-за этого компании покупают не ту систему. Иногда нужен разговорный интерфейс. Иногда нужен понятный процесс. Иногда нужна программа, которая сама выбирает следующий шаг, вызывает инструменты, проверяет результат и останавливается, если риск слишком высокий.

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

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

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

Практическое правило простое. Если процесс можно нарисовать блок-схемой и все развилки известны, начинайте с workflow. Если вход от пользователя свободный, но действия ограничены, делайте чат-бота с понятной передачей человеку. Если задача требует планирования, поиска, повторных попыток, выбора tools и решения “остановиться или продолжать”, тогда агент может быть правильной формой.

Самая частая ошибка — называть агентом любой бот с ChatGPT. Настоящий агент не просто говорит. Он действует внутри систем: ищет данные, вызывает API, обновляет CRM, пишет черновик, создаёт задачу, проверяет результат tool, отказывается от опасного шага и оставляет логи.

Чем больше автономии, тем важнее evals, ограничения, наблюдаемость и human-in-the-loop. Хороший агент не тот, который никогда не спрашивает человека. Хороший агент знает, когда ему нельзя идти дальше самому.

Карта выбора между чат-ботом, workflow и AI-агентом по разговору, предсказуемому процессу и автономным действиям — Выбирать надо по ответственности системы, а не по модному названию в презентации.

Главное отличие — автономия

Проще всего разделить эти три формы одним вопросом: кто решает следующий шаг?

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

У workflow следующий шаг задаёт описание процесса. Пришла заявка, система классифицировала её, применила правила, вызвала нужные интеграции и отправила дальше. LLM может отвечать за один этап: summary, extraction, классификацию. Но маршрут всё равно заранее спроектирован людьми.

У агента следующий шаг выбирается во время работы. У агента есть цель и набор tools. Он может искать документы, смотреть запись в CRM, вызывать pricing API, писать черновик, замечать нехватку данных, задавать вопрос пользователю или пробовать другой путь. IBM описывает AI agents как системы, которые автономно выполняют задачи с помощью доступных инструментов, а в документации OpenAI Agents SDK агентные приложения строятся вокруг контекста, tools, handoffs, streaming и tracing.

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

Когда чат-бот — правильный продукт

Чат-бот — это разговорный интерфейс. Он подходит, когда главная работа состоит в том, чтобы принять живую человеческую формулировку и ответить внутри ограниченной области.

Хорошие задачи для чат-бота:

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

Ключевое слово — “ограниченной”. Бот поддержки должен понимать, какие темы покрывает, на какие источники опирается и когда обязан передать кейс человеку. Ему не нужно планировать действия по пяти системам, если бизнес-задача звучит как “ответить или эскалировать”.

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

Граница чат-бота: разговор, база знаний и передача человеку как ограниченная поверхность поддержки — Чат-бот вызывает доверие не смелостью, а понятной границей: ответить, уточнить или передать человеку.

Когда workflow безопаснее

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

Например:

В WhatsApp приходит заявка.
Система достаёт имя, телефон, город, продукт и намерение.
Проверяет, есть ли такой телефон в CRM.
Создаёт или обновляет лид.
Назначает менеджера по региону и загрузке.
Отправляет уведомление.
Записывает недостающие поля для follow-up.

Внутри этой схемы может быть AI. Извлечение полей может делать модель. Классификацию тоже. Черновик ответа тоже. Но сам путь не импровизируется.

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

Для небольших компаний это напрямую связано с подходом из статьи Как внедрить ИИ в малый бизнес: выбрать один повторяющийся процесс, собрать реальные примеры и не расширять первую версию раньше времени.

Детерминированный workflow с шагами классификации, проверки, обновления CRM, уведомления и логирования — Когда маршрут известен, workflow проще тестировать, объяснять и чинить.

Когда AI-агент стоит риска

Агент становится полезен, когда workflow нельзя полностью нарисовать заранее.

Представим sales assistant, который получает мутное сообщение: “Клиент со вчерашнего звонка хочет enterprise, но всё время сравнивает нас с дешёвым тарифом. Что ему отправить?” Жёсткий workflow может классифицировать и направить запрос. Чат-бот может ответить общими правилами. Агент может сделать больше: найти лид, прочитать предыдущие notes, проверить обсуждавшийся тариф, посмотреть правила скидок, написать черновик, отметить ценовое исключение и попросить подтверждение у руководителя перед отправкой.

Вот этот цикл с tools и есть отличие. Агент ценен не потому, что у него есть чат. Он ценен потому, что умеет двигаться по контексту и системам.

Агенты имеют смысл, когда задаче нужны:

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

Поэтому современные платформы для агентов так много говорят про tools и connectors. Anthropic представила Model Context Protocol как способ подключать AI assistants к системам, где живут данные. Microsoft описывает Copilot agents как программные сущности, которые помогают автоматизировать и выполнять бизнес- или учебные процессы вместе с человеком или от его имени. Общее направление видно: агенты выходят из окна чата и начинают касаться работы.

Именно здесь появляется риск.

Цикл AI-агента: цель, контекст, планирование, вызов инструмента, наблюдение, повторная попытка и проверка человеком — Агент — это цикл: выбрать, сделать, проверить и либо продолжить, либо остановиться.

Ошибки у них разные

Эти три формы ломаются по-разному, поэтому защищать их надо по-разному.

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

Workflow может неверно классифицировать заявку, записать плохие структурированные данные, пропустить согласование или отправить кейс не тому владельцу. Ущерб уже операционный: неправильное состояние CRM, пропущенный SLA, дубли работы, невидимый backlog.

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

Поэтому “AI-агент или чат-бот” — не вопрос названия. Архитектура меняет радиус поражения. Бот с плохим ответом раздражает. Агент, который обновил не ту сделку, отправил неверное обещание или прочитал закрытый документ, уже создаёт production-инцидент.

Для систем с retrieval та же логика раскрыта в статье Как построить хороший RAG: если найден не тот источник, финальный ответ уже под угрозой. У агентов к этому добавляются выбор tool и качество действия.

Границы риска для чат-бота, workflow и AI-агента с точками проверки человеком — Чем сильнее система влияет на рабочее состояние бизнеса, тем яснее должны быть правила остановки.

Практичная матрица выбора

Перед покупкой или разработкой пройдитесь по этой матрице.

Чат-бот

Когда подходит: пользователю нужен разговорный вход.

Автономия: низкая. Отвечает, уточняет, ищет или передаёт человеку.

Риск: плохой совет, пропущенная эскалация, слабый UX.

Workflow

Когда подходит: маршрут известен и повторяется.

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

Риск: неверная классификация, плохая маршрутизация, хрупкая интеграция.

AI-агент

Когда подходит: нужны планирование, tools и решение по ситуации.

Автономия: высокая. Выбирает действия внутри заданной границы.

Риск: неверный tool, небезопасное действие, скрытый цикл, слабый audit trail.

Неудобная правда в том, что многим проектам нужен гибрид. В продажах чат-бот может быть интерфейсом, workflow — маршрутом лида, а агент — только для мутных случаев, где заранее не видно путь. Это обычно здоровее, чем делать всю систему агентной с первого дня.

Автономию лучше наращивать ступенями

Автономия должна появляться слоями.

Сначала read-only помощь. Система отвечает из проверенной базы знаний, делает summary тикета или пишет черновик. Человек смотрит результат.

Потом структурная подготовка. Система извлекает поля, предлагает теги, готовит обновление CRM или рекомендует следующий шаг. Человек всё ещё подтверждает.

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

Только после evals и логов стоит разрешать рискованные действия: отправлять сообщения, менять этап сделки, применять скидки, оформлять возвраты или принимать решения, которые влияют на клиентов и сотрудников.

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

Лестница автономии: read-only ответы, черновики, действия с подтверждением, низкорисковые записи и автономные рискованные действия — Не прыгайте от ответов к самостоятельным действиям. Пусть система заслужит каждое новое право.

Что тестировать перед запуском

Чат-ботам, workflow и агентам всем нужны проверки, но eval-набор меняется вместе с автономией.

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

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

Для агента проверяют цепочку действий:

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

Это практическая сторона статьи Зачем AI-проекту evals. Evals позволяют выдавать автономию дозированно. Команда может решить: агент пишет черновик, но не отправляет; создаёт внутреннюю задачу, но не меняет цену; отвечает по публичному регламенту, но не трогает закрытые документы.

Доска evals для ответов чат-бота, шагов workflow, tool calls агента, подтверждения человеком и обратной связи из production — С ростом автономии evals переходят от качества ответа к качеству действий.

Как сузить первую версию

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

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

Нормальные первые версии часто выглядят скучно:

бот поддержки отвечает из небольшой базы знаний и чисто эскалирует;
workflow входящих лидов достаёт поля и создаёт задачу менеджеру;
HR-ассистент отвечает по регламентам со ссылками, но не решает исключения;
sales agent пишет follow-up и обновляет внутренние notes только после подтверждения;
ассистент по документам ищет и суммаризирует, но отказывается, если источников мало.

Скучная форма — плюс. Она даёт увидеть живое использование, собрать ошибки и понять, где дополнительная автономия правда поможет. Многие агентные проекты проваливаются потому, что стартуют с “пусть делает всё”, а не с “пусть закроет вот этот болезненный кусок”.

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

Примеры из рабочих процессов

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

В продажах часто первым идёт workflow. Intake, enrichment, распределение, reminders и CRM hygiene повторяются. Агент становится полезен, когда следующий шаг зависит от грязного контекста: прошлых возражений, правил цены, product fit и согласований руководителя. Подробнее это разобрано в статье ИИ для отдела продаж.

Во внутренней базе знаний всё упирается в retrieval. Для FAQ может хватить простого чат-бота. RAG-ассистент нужен там, где ответ должен ссылаться на регламенты, документы и права доступа. Агент помогает, когда вопрос составной: надо найти, сравнить и потом сделать follow-up действие.

В операционных процессах workflow часто недооценивают. Многие “идеи для агента” на деле оказываются process automation с одним AI-шагом. Это не менее серьёзно. Часто это надёжнее.

Итог

Используйте самую маленькую систему, которая ответственно решает задачу.

Выбирайте чат-бота, когда разговор — главный интерфейс, а граница действий узкая. Выбирайте workflow, когда маршрут известен и повторяется. Выбирайте AI-агента только там, где нужны решение по ситуации, выбор tools, повторные попытки и управляемый путь к действию.

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