Содержание
- Что такое ИИ-агент и чем он отличается от чат-бота
- Один агент или мультиагентная система
- Фреймворки и платформы: чем собирать
- RAG как фундамент полезного агента
- Роутинг моделей: отказоустойчивость и экономика
- Где агенты реально работают
- Боли и ограничения, о которых молчат
- Как внедрять: от пилота к продакшену
- FAQ
Про ИИ-агентов сейчас говорят все, но в бизнес-чатах звучит один и тот же честный вопрос: «Я везде читаю про агентов, но сплошная теория. А где практика? Желательно прикладная, для МСБ в РФ — кто реально внедрил и какой кейс они делают?» Эта статья — попытка ответить без хайпа: что такое агент на самом деле, когда он окупается, какими инструментами его собирать и где он гарантированно вас подведёт, если не учесть ограничения.
Материал ориентирован на тех, кто принимает решение о внедрении, и на команды, которым потом это эксплуатировать. Мы в Новакоме строим такие системы на Java/Kotlin-стеке и встраиваем их во внутренние корпоративные сервисы, поэтому ниже — практика, а не пересказ пресс-релизов.
Что такое ИИ-агент и чем он отличается от чат-бота
Коротко: чат-бот отвечает, агент действует. Обычный бот «не имеет права не ответить» — он генерирует текст на запрос. Агент же — это система, которая ставит цель, планирует шаги и использует инструменты (браузер, API, CRM, базу данных) для решения многошаговой задачи без постоянного контроля человека.
Классически у агента выделяют четыре свойства:
- Планирование — декомпозиция высокоуровневой цели в цепочку промежуточных задач.
- Память — краткосрочная (контекст диалога) и долгосрочная (опыт, факты, состояние между сессиями).
- Использование инструментов — вызовы внешних API, поиск, выполнение кода, работа с файлами.
- Рефлексия — способность оценить результат, заметить ошибку и переделать.
Канонический пример: задача «вот моя карта, организуй поездку» требует выбрать отели и билеты, пройти оформление и проверить, что бронь пришла. Это десятки мелких шагов, каждый из которых LLM выполнит легко, но связать их в правильную последовательность — отдельная и до сих пор нетривиальная задача. Именно планирование и долгосрочное видение остаются главной слабостью: «найти на странице кнопку покупки» модель умеет, а вот дойти до этой точки из исходного запроса — сложнее.
Важно держать в голове и трезвый взгляд скептиков: в основе LLM — предсказание токенов, и «чем больше данные прогоняются в цикле запросов-ответов, тем больше накапливается погрешность». Это не приговор агентам, но прямое следствие для архитектуры: нужны проверки, ограничения и человек в петле там, где цена ошибки высока.
Один агент или мультиагентная система
Не каждой задаче нужна мультиагентность. Часто достаточно одного агента с набором инструментов. Но когда задача распадается на разные роли — кто-то общается с пользователем, кто-то выполняет работу на бэкенде, кто-то проверяет результат — появляется смысл в нескольких специализированных агентах.
Идея «общества агентов» имеет и теоретическое, и эмпирическое подтверждение. Эмпирически даже простой приём — несколько раз опросить модель и провести мажоритарное голосование — стабильно повышает качество с ростом числа «голосов» (заметнее всего примерно до 10 участников). Архитектурно мультиагентность — это разделение на роли: один агент специфицирует задачу, другие исполняют заданные роли и могут коллаборировать, а критик оценивает результат внутри процедуры.
При этом есть и обратная сторона, которую слышно в инженерных чатах: «похоже, переборщили с агентами — пытаются выжать больше из технологии, но получается задрюченная LLM». Вывод практичный: мультиагентность — инструмент, а не самоцель. Начинайте с одного агента; разбивайте на несколько только тогда, когда роли действительно разные и появляется потребность в оркестрации и взаимной проверке.
Хорошая ментальная модель для разработчиков — акторная: независимые агенты, обменивающиеся сообщениями, с оркестратором, который маршрутизирует задачи. Это близко к тому, как устроены highload-системы на акторах и очередях, и переиспользует знакомые паттерны вместо изобретения новых.
Фреймворки и платформы: чем собирать
Порог входа сейчас низок как никогда. На рынке несколько слоёв инструментов.
Фреймворки для разработчиков (полный контроль, pro-code):
- LangGraph / LangChain — композиция цепочек и графов состояний агента.
- CrewAI — оркестрация ролевых автономных агентов.
- AutoGen (Microsoft) — мультиагентные приложения, диалог агентов между собой.
- Semantic Kernel (Microsoft) — встраивание ИИ-плагинов в корпоративные приложения.
- Claude Agent SDK (Anthropic) — SDK для построения агентов поверх Claude.
Отдельные слои закрывают память (Mem0, Letta), работу с браузером и компьютером (Open Interpreter, веб-агенты), мониторинг и бенчмаркинг (AgentOps). Экосистема open-source-инструментов с разрешительными лицензиями большая — собрать прототип можно быстро.
No/low-code платформы enterprise-уровня — для случаев, когда нет ресурсов на разработку с нуля. В России это направление активно растёт: появились корпоративные платформы для визуального создания агентов с готовыми коннекторами к десяткам сервисов (RAG, БД, CRM, мессенджеры), встроенными FinOps-инструментами для контроля расходов и возможностью развёртывания как в облаке, так и локально. В разработку таких систем вендоры вкладывают миллиарды рублей и позиционируют их как enterprise-ready. Параллельно растёт и использование агентов в самой разработке: внутренние замеры показывают рост активности на десятки процентов за квартал, при этом 60% сценариев — рутина и рефакторинг, и только около 15% — проектирование архитектуры.
Практический выбор такой: low-code платформа хороша для быстрого старта и типовых сценариев, собственная разработка на фреймворках — когда агента нужно глубоко встроить во внутренние системы, обеспечить контроль над данными и кастомную логику. Часто оптимален гибрид: ядро на платформе, критичные интеграции — кодом.
RAG как фундамент полезного агента
Агент без доступа к вашим данным — это просто красноречивый незнакомец. Полезным его делает RAG (retrieval-augmented generation): агент извлекает релевантные фрагменты из вашей базы знаний и опирается на них, а не на «общую эрудицию» модели. Полноценная RAG-система — это ретривер, реранкер, генератор и оценка качества, а не просто «подсунуть пару документов в промпт».
Для бизнеса RAG решает две проблемы сразу: снижает галлюцинации (ответ заземлён на факты) и позволяет работать с приватными данными, которые модель никогда не видела. Связка «агент + RAG + инструменты» — это и есть тот контур, который реально автоматизирует фронт- и бэк-процессы: один агент отвечает в чате, другой выполняет задачу на бэкенде, третий формирует отчётность.
Если данные чувствительны или есть требования по их хранению в РФ, RAG и сами модели можно разворачивать локально. Мы подробно разбирали экономику и приватность этого выбора в статье про локальные LLM против облачных API — для enterprise это часто решающий аргумент.
Роутинг моделей: отказоустойчивость и экономика
Зрелые внедрения почти никогда не завязаны на одного провайдера модели. «Всё больше бизнесов переходит на несколько AI-провайдеров — это выгодно и необходимо для отказоустойчивости»: сложные логические цепочки отдают одной модели, потоковую обработку сырых данных — другой.
За этим стоит простая идея оркестрации: разные модели хороши в разных задачах, поэтому логично иметь маршрутизатор, который для каждого запроса выбирает, куда его направить. За математику и сложные рассуждения отвечает дорогая мощная модель, а «переписать письмо простыми словами» сделает и маленькая. Такой подход даёт сопоставимое качество при заметно меньшей стоимости — и одновременно страхует от отказа или блокировки одного провайдера.
Практические следствия для архитектуры:
- Абстрагируйте провайдера. Код агента не должен знать, какая модель под капотом, — это слой за интерфейсом.
- Считайте стоимость с первого дня. FinOps для агентов — не роскошь: цикл «запрос-ответ» легко разрастается, и счёт за токены растёт нелинейно.
- Экономия на токенах ≠ обязательный переход на локальные модели. Локальные модели надо поддерживать, и это дорого. Решение принимается по совокупности приватности, стоимости и нагрузки, а не по лозунгу.
Где агенты реально работают
Возвращаясь к вопросу «где практика». Прикладные кейсы, которые уже приносят пользу:
- Малый и средний бизнес. Агенты для фитнес-клубов, салонов красоты, ресторанов: запись, ответы на типовые вопросы, обработка заявок, напоминания. Здесь агент закрывает рутину фронт-офиса.
- Поддержка и саппорт. Автоматизация первой линии: агент с RAG по базе знаний отвечает на повторяющиеся вопросы, эскалируя сложное человеку.
- Разработка. Рутина и рефакторинг, генерация тестов и одноразового boilerplate-кода, сборка проекта от репозитория до деплоя. Мы отдельно разбирали, что значит «ИИ пишет 90% кода» для заказной разработки — спойлер: до замены инженеров далеко, но продуктивность растёт.
- Исследование и анализ. Автономные агенты-исследователи, которые ищут информацию, анализируют и сводят результаты; в безопасности — агенты, автономно ищущие уязвимости в коде.
- Внутренние процессы enterprise. Мультиагентные пайплайны, где агенты распределяют роли, передают друг другу результаты и проверяют их, встроенные во внутренний корпоративный контур.
Общий знаменатель успешных кейсов: узкая, хорошо очерченная задача + доступ к данным + проверка результата. Чем размытее задача, тем выше шанс получить красивую демонстрацию, которая разваливается в продакшене.
Боли и ограничения, о которых молчат
Честный раздел, без которого внедрение превращается в разочарование.
- Накопление ошибок. В длинных цепочках погрешность растёт: агент исправляет ошибку в тексте или коде — и вносит новую. Чем длиннее автономная петля, тем нужнее контрольные точки и проверки.
- Галлюцинации в действиях. Агент генерирует правдоподобные, но нерабочие решения. Лечится «заземлением на исполнение»: реальный запуск кода/действия и обратная связь по результату, а не доверие к тексту.
- Интеграции затягиваются. На практике «интеграции затягиваются на месяцы, и разные ИИ-решения никак не структурированы». Без единого контура агенты превращаются в зоопарк разрозненных скриптов.
- Человек в петле обязателен. Даже сторонники агентных систем подчёркивают: ни одна концентрация интеллекта не должна сама себя регулировать — нужны роли, надзор и контроль, встроенные в архитектуру. Для продакшен-кода это означает обязательную проверку ai-generated результата.
- Стоимость поддержки. Локальные модели и сложные мультиагентные конструкции дороги в эксплуатации. Считайте TCO, а не только стоимость пилота.
Резюме: агенты дают реальный выигрыш на рутине и многошаговых, но проверяемых задачах. Они плохо подходят там, где нужна гарантированная корректность без надзора.
Как внедрять: от пилота к продакшену
Последовательность, которая снижает риск провала:
- Выберите одну узкую задачу с измеримой пользой. Не «внедрим ИИ», а «автоматизируем обработку заявок на запись» с метрикой (время ответа, доля автозакрытых обращений).
- Соберите данные и RAG. Качество агента определяется качеством базы знаний и ретривера, а не «магией» модели.
- Начните с одного агента и одного провайдера. Мультиагентность и роутинг добавляйте, когда упрётесь в ограничения.
- Заложите наблюдаемость и FinOps. Логи, трассировку цепочек, бюджет на токены — с первого дня.
- Поставьте человека в петлю на критичных шагах. Особенно там, где агент совершает действия (платежи, изменения данных, продакшен-код).
- Встройте в существующие системы. Реальная ценность появляется, когда агент работает внутри вашего контура — CRM, БД, внутренних сервисов, — а не в изолированной песочнице.
Именно последний пункт чаще всего и отделяет демо от работающего продукта: встроить агента во внутренние корпоративные системы, обеспечить контроль данных и надёжность — это инженерная задача на стыке ИИ и классической backend-разработки.
FAQ
Чем ИИ-агент отличается от чат-бота? Чат-бот отвечает на сообщения, агент выполняет действия: ставит цель, планирует шаги, использует инструменты (API, CRM, браузер) и проверяет результат. Бот не имеет права не ответить — агент имеет право действовать.
Нужна ли мультиагентная система? Не всегда. Начинайте с одного агента. Несколько агентов оправданы, когда задача распадается на разные роли (исполнитель, проверяющий, оркестратор) и нужна их координация.
Можно ли держать всё в российском контуре? Да. И сами модели, и RAG можно разворачивать локально; есть отечественные enterprise-платформы для создания агентов с локальным развёртыванием. Это снимает риски зависимости от внешнего провайдера и упрощает требования по данным.
Сколько стоит эксплуатация? Главная статья — токены: цикл «запрос-ответ» разрастается, и расходы растут нелинейно. Локальные модели убирают плату за токены, но добавляют стоимость инфраструктуры и поддержки. Решение принимается по TCO.
Можно ли доверять агенту писать продакшен-код? Частично. Агенты хороши для рутины, рефакторинга, тестов и boilerplate, но ai-generated код нужно внимательно проверять. Человек в петле обязателен.
Если вы хотите внедрить ИИ-агента в реальный бизнес-процесс — от RAG по вашей базе знаний до интеграции с CRM и внутренними сервисами — мы в Новакоме проектируем и встраиваем агентные системы на Java/Kotlin-стеке. Посмотрите наши услуги по разработке с ИИ и заказной разработке ПО или напишите нам с описанием задачи — честно оценим, где агент окупится, а где лучше обойтись без него.