Обзор AI-агентов: как читать каталог и что выбрать

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

TL;DR: как читать этот обзор

1. Класс важнее названия. Ассистент общего назначения, корпоративный агент, агент-разработчик и конструктор навыков решают разные задачи.
2. Смотрите на данные, а не на модель. Ключевой вопрос — к каким источникам у агента есть доступ и как он их цитирует.
3. Русский язык проверяется отдельно. Ассистент, блестящий на английском, может проваливаться на русских документах.
4. Цена — не главный фильтр. Дороже обходится пилот, который не масштабируется.
5. Проверка. Сайты шести продуктов из обзора отвечают 200 — их можно изучить до разговора с продавцом.

Проблема, которую это решает

Запрос «что взять» обычно приходит с готовым ответом внутри: «нам нужен AI-агент, покажите, что есть». Дальше начинается сравнение несравнимого — голосового ассистента с корпоративным поиском по документам, потому что оба названы агентами.

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

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

Что такое AI-агент и какие бывают классы

flowchart TB
  A["ассистент общего назначения"] --> U["пользователь: голос и чат"]
  B["корпоративный агент"] --> O["офисные данные и документы"]
  C["агент-разработчик"] --> CODE["код и репозиторий"]
  D["конструктор навыков"] --> BOT["боты и сценарии"]

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

Возможности: что реально умеют разные классы

Эта таблица объясняет, почему «мы возьмём то же, что у всех» не работает: у всех — это ассистент для сотрудников, а задача может требовать доступа к регламентам.

Российские агенты: что есть на рынке

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

Корпоративные агенты: что дают и чего стоят

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

Замеры и цифры

Проверено 12.11.2026: доступность публичных страниц продуктов из обзора.

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

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

Сильные стороны продукта

• Категория зрелая. Ассистенты существуют годами, у них есть накопленная практика и понятные ограничения.
• Русский язык поддержан. Все российские продукты из обзора работают с русским как с основным.
• Корпоративные решения связаны с документами. Это главный источник пользы: ответы по своим регламентам, а не по общим знаниям модели.
• Есть конструкторы. Если готовый продукт не подходит, сценарий можно собрать из блоков.
• Доступность проверяема. Публичные страницы и документация открыты, пилот можно спланировать до покупки.
• Разные ценовые модели. От бесплатных ассистентов до премиальных корпоративных подписок.

Установка: как провести пилот

flowchart LR
  TASK["задача"] --> DATA{"данные где?"}
  DATA -- внутри компании --> CORP["корпоративный контур"]
  DATA -- общедоступные --> PUB["публичный сервис"]
  CORP --> CHECK["проверка: языки, RAG, цена, аудит"]
  PUB --> CHECK
  CHECK --> PILOT["пилот на одной команде"]

Самая частая ошибка пилота — отсутствие метрики. Без неё итог звучит как «вроде удобно», и решение принимается по впечатлению самого громкого участника.

Настройка: критерии выбора

flowchart TD
  P1["доступ к своим данным: RAG или индекс"] --> V{"всё закрыто?"}
  P2["языки и качество на русском"] --> V
  P3["цена и лимиты"] --> V
  P4["журнал действий и права"] --> V
  V -- да --> GO["пилот"]
  V -- нет --> STOP["не внедрять"]

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

Почему каталоги агентов стареют быстрее всего

Есть закономерность: любой список AI-продуктов старше полугода содержит ошибки. Причины три, и все они не про лень авторов.

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

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

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

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

Как выглядит хороший пилот агента

Пилот отличается от демонстрации одной вещью: у него заранее определён результат. Покажите демо трём людям — получите три мнения. Запустите пилот с метрикой — получите решение.

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

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

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

И четвёртая, которую пропускают чаще всего: фиксация даты и версии. Агент на другой модели — другой продукт. Если через полгода результат изменится, без записи версии вы не поймёте, в чём дело.

Что делать, если готовый продукт не подходит

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

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

Второй — собственный агент на своей модели. Это уже проект: индекс документов, права, журнал, оценка качества. Дорого, но оправданно там, где данные нельзя выносить наружу.

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

Подводные камни

• Слово «агент» перегружено. Чат-бот с готовыми ответами и система, планирующая шаги, называются одинаково.
• Модель меняется без предупреждения. Поведение того же продукта через полгода может отличаться — фиксируйте версии и даты замеров.
• Цены быстро устаревают. Любая цифра из обзора — ориентир на дату, а не оферта.
• Публичный ассистент не видит ваши документы. Не путайте его с корпоративным агентом.
• Доступ к документам — это и риск. Чем шире контур, тем важнее права и аудит.
• Русский язык надо проверять на своих текстах. Терминология и аббревиатуры ломают качество чаще, чем грамматика.
• Код 200 на сайте ничего не гарантирует. Доступ может быть ограничен по региону или типу аккаунта.
• Пилот без метрики бесполезен. «Понравилось» — не результат.
• Каталоги устаревают. Список продуктов живёт месяцы; критерии выбора — годы.
• Не все классы применимы к вашей задаче. Агент-разработчик не решит задачу поддержки клиентов, как бы хорош ни был.
• Интеграции дороже подписки. Реальная стоимость — часы на подключение источников.

Вопросы, которые стоит задать продавцу

Список короткий, но он экономит месяцы.

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

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

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

Четвёртый: как выглядит ограничение прав. Кто определяет, какие документы видит конкретный сотрудник, и как это меняется при переводе в другой отдел.

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

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

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

Что было в исходной статье и что изменилось

Исходник — каталог на 106 015 знаков: таблицы по регионам и разборы продуктов, от MWS Agent и Олега до GitHub Copilot и Microsoft 365 Copilot. Материал местами точный, но он обрывался: после раздела про Microsoft 365 Copilot стояла фраза о продолжении в следующих разделах, а разделов про Европу и остальной мир так и не появилось.

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

Чек-лист

• [ ] Сформулировать задачу так, чтобы её результат можно было измерить.
• [ ] Определить класс агента: ассистент, корпоративный, разработчик, конструктор.
• [ ] Перечислить данные, к которым нужен доступ.
• [ ] Проверить, умеет ли продукт работать с этими данными.
• [ ] Уточнить права и аудит действий.
• [ ] Проверить качество на русском на своих документах.
• [ ] Уточнить актуальные цены и лимиты у продавца.
• [ ] Спланировать пилот: одна команда, две недели, метрика.
• [ ] Зафиксировать дату и версию замера.
• [ ] Принять решение по результатам, а не по впечатлениям.

FAQ

Итог

Обзор AI-агентов полезен не списком имён, а рамкой: четыре класса систем, у каждого своя метрика качества. Российские продукты сильны в доступе к локальным сервисам, корпоративные — в связке с документами компании, конструкторы — в гибкости сценариев. Проверка 12.11.2026 подтвердила: шесть публичных адресов живы, изучать продукты можно до разговора с продавцом. Дальше начинается то, что не покажет ни один каталог: пилот на своих данных с заранее agreed метрикой.

Цитата: Каталог агентов говорит, что существует; выбор начинается с вопроса, какие данные агент увидит.

Связанные материалы

• MD.Scribe 3.1.0: переименование и починка обновлятора — пример продукта, где документация идёт в комплекте с кодом.
• github-wiki-llm-writer: вики репозитория с проверкой фактов — как агент пишет документацию с источниками.
• ctf-collect-to-file: весь код в один документ — сборка контекста для модели, без которого агент бесполезен.
• RAGRAF 0.11.0: контракт-пин и пробы поведения — индекс кода как база знаний агента.
• CF7 Spam Checker Pro: защита формы — пример проверки LLM-классификатора на живом трафике.

LLM Summary

• Тема: практический обзор AI-агентов — классы систем, российские и корпоративные продукты, критерии выбора.
• Классы: ассистент общего назначения, отраслевой помощник, корпоративный агент, агент-разработчик, мультиагентная система, конструктор навыков.
• Российские продукты из исходного каталога: MWS Agent (МТС, оркестратор с подагентами), Олег (Тинькофф, банковский помощник), Алиса (Яндекс, поиск и граф знаний), Маруся (VK), Салют (Сбер, связка с GigaChat), Aimylogic (Just AI, конструктор навыков).
• Корпоративные: GitHub Copilot (подсказки кода), Microsoft 365 Copilot (документы, почта, календарь).
• Проверено 12.11.2026: публичные адреса Алисы, СберБанк Онлайн, Маруси, GitHub Copilot, Microsoft 365 Copilot и Aimylogic отвечают HTTP 200.
• Критерии выбора: доступ к данным (RAG или индекс), цитирование источников, качество на русском, права, аудит, цена, интеграции, контур развёртывания.
• Порядок пилота: одна задача с метрикой, ограниченная группа, две недели, письменная обратная связь, решение по результатам.
• Границы исходного материала: каталог охватывал Россию и начало США; разделы про Европу и остальной мир остались обещанием, поэтому в новой версии перечень сокращён до проверяемых примеров.
• Не проверялось: цены и условия лицензирования, реальное поведение агентов на конкретных данных, актуальность версий продуктов.
• Ссылки: https://alice.yandex.ru/, https://github.com/features/copilot, https://sysadministrator.ru/obzor-ai-agentov-kak-vybrat/

Промт для агента (установка и настройка)

Готовый промт: скопируйте блок целиком. Файла AGENTS.md у этой задачи нет (это не репозиторий), источник шагов — критерии и порядок пилота из статьи.

Задача: выбрать класс AI-агента под конкретную задачу и провести ограниченный пилот с измеримым результатом.

Шаг 1. Сформулировать задачу и метрику: что должно улучшиться и как это измерить (время, доля ошибок, число обращений).
Шаг 2. Определить класс: ассистент общего назначения, отраслевой помощник, корпоративный агент, агент-разработчик, конструктор навыков.
Шаг 3. Перечислить данные: какие документы и системы нужны агенту, где они лежат, кто владелец.
Шаг 4. Проверить доступ к данным: есть ли индекс или RAG, как обновляется, показывает ли цитаты.
Шаг 5. Проверить права: разграничение доступа и журнал действий.
Шаг 6. Проверить русский язык на своих текстах: терминология, аббревиатуры, формальные формулировки.
Шаг 7. Уточнить у продавца актуальные цены, лимиты и условия развёртывания (облако или свой контур).
Шаг 8. Запустить пилот: одна команда, две недели, заранее agreed метрика.
Шаг 9. Собрать письменную обратную связь и сравнить с метрикой.
Шаг 10. Принять решение: масштабировать, менять продукт или закрыть направление.

Запрещено:
- сравнивать продукты разных классов по одному списку критериев;
- считать «удобно» результатом пилота без метрики;
- публиковать цены из статьи как актуальные: они меняются;
- путать публичного ассистента с корпоративным агентом, у которого есть доступ к внутренним документам;
- отдавать агенту доступ ко всем документам сразу, без разграничения прав;
- считать HTTP 200 на сайте продукта доказательством доступности сервиса для вашей компании.

Что считать успехом: задача с метрикой сформулирована, класс выбран осознанно, данные и права определены, пилот завершён с измеримым результатом и решением.