Что такое AI-агент и чем он отличается от чат-бота

AI-агент — это программа на основе языковой модели, которая получает цель, сама планирует шаги и выполняет их в рабочих системах компании: таск-трекере, CRM, почте, базе знаний. В отличие от чат-бота, агент не только отвечает, но и действует через подключённые инструменты, проверяет результат и повторяет попытку. Поэтому главный вопрос при внедрении агента не «какая модель умнее», а какие у него доступы и кто контролирует его действия.

Статья для основателей, руководителей IT и операционных директоров IT-компаний в Казахстане, которые слышат об AI-агентах со всех сторон и хотят понять, где они реально полезны. Разбираем, как агент устроен, чем отличается от чат-бота, скрипта и ассистента, где он даёт пользу в IT-компании, какие риски несёт, что такое MCP и как запустить первый сценарий без лишнего риска.

Как работает AI-агент

В основе агента языковая модель, та же технология, что стоит за ChatGPT или Claude. Сама по себе модель умеет только читать и писать текст. Агентом её делает цикл работы и набор инструментов.

Цикл выглядит так:

1. Цель. Человек или событие в системе ставит задачу: «разбери новые обращения в поддержку», «подготовь сводку по сделкам за неделю».
2. План. Модель решает, какие шаги нужны и в каком порядке.
3. Действие. Агент вызывает инструмент: ищет задачи в трекере, читает карточку сделки, создаёт черновик.
4. Проверка. Агент смотрит на результат и решает, достигнута ли цель, нужен ли ещё шаг или пора передать задачу человеку.

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

Обратная сторона: агент действует вероятностно. Чаще всего он поступит разумно, но иногда уверенно ошибётся, и заранее не всегда понятно, в каком случае. Хорошая архитектура агента строится вокруг этой особенности, а не делает вид, что её нет.

Чем AI-агент отличается от чат-бота, скрипта и ассистента

Термины часто смешивают, и из-за этого компании ждут от инструмента не того, что он умеет.

Инструмент	Что делает	Как принимает решения	Где ломается
Скрипт или правило автоматизации	Выполняет заданную последовательность при событии	По жёсткой логике «если — то»	Вход отличается от ожидаемого
Чат-бот	Отвечает на сообщения в диалоге	По сценарию или с помощью модели	Нужно действие в системе, а не ответ
AI-ассистент	Помогает человеку: пишет, резюмирует, ищет	Модель, но действие выполняет человек	Нужна работа без участия человека
AI-агент	Сам выполняет шаги в системах ради цели	Модель плюс инструменты и правила	Широкие права без контроля, неясная цель

Практическое правило: если задачу можно описать как «если X, то Y» без исключений, достаточно обычной автоматизации, и она надёжнее. Агент нужен там, где вход неструктурированный и решение зависит от смысла текста. Подробнее о выборе между правилами, скриптами и агентами в трекере мы писали в статье «Автоматизация в таск-трекере: правила, скрипты или AI-агенты».

Из чего состоит агент

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

Компонент	Что это	Вопрос, на который нужно ответить
Модель	Языковая модель, которая понимает и планирует	Где она работает и какие данные ей передаются
Инструменты	Действия, которые агенту разрешено вызывать	Что агент может сделать, а что нет
Доступы	Учётная запись и права в системах	Под чьим именем действует агент и с какими правами
Память	Контекст: история задачи, база знаний, прошлые решения	Какие данные агент видит и как долго их хранит
Правила	Инструкции, ограничения, точки подтверждения	Что агент делает сам, а что только после одобрения человека

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

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

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

Где агенты реально полезны в IT-компании

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

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

Управление задачами. Агент превращает заметки и переписку в черновики задач, сортирует входящие, находит дубли, пишет резюме длинных обсуждений и напоминает о задачах без движения. Например, в Plane с сентября 2026 года есть AI-агенты, которые работают внутри рабочего пространства, а у Atlassian есть Rovo. Что из этого уже работает, мы разбирали в статье «AI-агенты в управлении задачами».

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

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

Где агенты пока не справляются

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

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

Готовый агент или собственный

Агента можно получить тремя путями, и для первого сценария выбор пути важнее выбора модели.

Встроенный агент в системе, которой вы уже пользуетесь. Таск-трекеры, CRM и офисные пакеты добавляют AI-функции и агентов прямо в интерфейс. Плюсы: не нужна интеграция, права наследуются от системы, запуск занимает дни. Минусы: агент работает только внутри одной системы, а набор сценариев определяет вендор.

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

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

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

Риски и права доступа

Риск агента прямо пропорционален его правам. Агент без доступа к системам может только ошибиться в тексте. Агент с правами администратора CRM может за минуту массово изменить сотни сделок.

Базовые правила, которые мы применяем:

• Отдельная учётная запись. Агент не работает под логином сотрудника, иначе в журнале не отличить его действия от человеческих.
• Минимальные права. Только проекты и действия, нужные одному сценарию.
• Подтверждение человеком. Удаление, массовые изменения, сообщения клиентам, изменение сумм и этапов сделок проходят через одобрение.
• Журнал. Видно, что сделал агент, по какому запросу и было ли подтверждение.
• Расширение по итогам пилота. Права добавляют, когда понятно, где агент ошибается, а не заранее.

Подробная модель ролей, делегирования и контроля описана в статье «Права AI-агентов: RBAC, MCP и делегирование».

Контекст Казахстана. Данные, которые агент читает, — обращения клиентов, карточки сделок, переписка — почти всегда содержат персональные данные. Если агент использует облачную модель зарубежного провайдера, нужно понимать, какие фрагменты данных уходят в запросах и где они хранятся. Если важно, чтобы данные оставались в Казахстане, или контур чувствительный, есть путь с локальной моделью на своём сервере: например, Plane в версии Airgapped поддерживает локальную AI-модель без доступа в интернет.

MCP простыми словами

MCP (Model Context Protocol) — открытый стандарт, по которому AI-приложения подключаются к внешним системам. Раньше каждую связку «модель плюс CRM» или «модель плюс трекер» писали отдельно. С MCP система один раз публикует набор инструментов, а любой совместимый AI-клиент может их использовать. Создатели протокола сравнивают его с разъёмом USB-C для AI-приложений.

Что важно руководителю:

• MCP — это канал, а не защита. Агент получает ровно те возможности, которые даёт токен подключения.
• Многие системы уже поддерживают MCP. Например, у Plane есть MCP-коннекторы, через которые внешние AI-инструменты работают с задачами.
• Перед подключением спросите, какие инструменты открывает MCP-сервер, под какой учётной записью он работает и пишутся ли вызовы в журнал.

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

Как начать с одного сценария

Ошибка большинства компаний — начинать с «AI-стратегии» на всю организацию. Работает обратный путь: один сценарий, одна команда, понятная метрика.

Этап	Что делаем	Результат
Выбор сценария	Ищем частую однотипную работу с текстом, которую легко проверить	Один сценарий с владельцем
Описание	Записываем вход, ожидаемый результат, критерии ошибки и точки подтверждения	Инструкция для агента
Режим черновиков	Агент предлагает, человек подтверждает каждое действие	Видно, где агент ошибается
Оценка	Сравниваем время и качество с работой до агента	Решение: расширять, дорабатывать или остановить
Расширение	Часть действий переводим в автоматический режим, добавляем права	Рабочий сценарий в продакшене

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

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

Как мы это делаем

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

Как устроена работа и что входит в результат, описано на странице услуги автоматизации бизнеса и внедрения AI-агентов.

---

Источники. Описание протокола MCP: modelcontextprotocol.io. Plane: plane.so/pricing и репозиторий на GitHub.

Термины простыми словами

AI-агент

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

Языковая модель (LLM)

Нейросеть, обученная на больших объёмах текста, которая понимает запросы и генерирует ответы. Это «мозг» агента, например модели ChatGPT или Claude.

Инструменты агента

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

MCP (Model Context Protocol)

Открытый стандарт подключения AI-приложений к внешним системам. Позволяет один раз описать инструменты системы и использовать их из разных AI-клиентов.

RBAC (ролевой доступ)

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

Человек в контуре (human-in-the-loop)

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

Промпт и системные инструкции

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

Локальная модель

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