За последнее время в мире искусственного интеллекта произошла серьёзная смена парадигмы. Раньше мы говорили про интеллектуальных помощников, которые автоматизируют достаточно узкие сценарии — ответы по документации, боты поддержки и так далее. Сейчас же технологии достигли такого уровня, что можно автоматизировать сложные действия человека с использованием разных инструментов планирования, многошаговым выполнением задачи и тому подобное — всё то, что сейчас называется ИИ‑агентами. Многие компании выпускают собственные решения, есть также открытые решения. Вокруг темы — много шума, часто встречаются полу‑рабочие прототипы, но вместе с тем есть сценарии, в которых ИИ-агенты оказываются реально полезными и уже сейчас помогают решать бизнес‑задачи.

Что такое ИИ‑агент? В его основе точно такая же технология больших языковых моделей, которая используется в ассистентах. Модель получает на вход описание задачи и генерирует текст ответа. Существует некоторый контекст, который даётся модели, чтобы она лучше выполнила задачу. И здесь проявляется ключевое отличие в том, что происходит в процессе: модель может в любой момент остановиться и вместо следующего слова ответа выполнить вызов некоторого инструмента, генерируя для него аргументы. Например, модель может по тексту запроса от пользователя выполнить какой‑то поисковый запрос, получить документы, прочитать их, и после того, как она «поймёт», что она получила в ответ, может вызвать новый инструмент и продолжить исследование, если для ответа недостаточно информации.

LLM:

ИИ‑агент:

Процесс работы языковой модели меняется: вместо однопроходного режима, когда модель получила запрос и давала на него ответ, LLM может войти в некоторый цикл саморефлексии, в ходе которого она может посмотреть на результаты применения очередного инструмента, понять, достаточно ли информации для ответа пользователю или для решения какой‑то задачи, и либо продолжить вызов другого инструмента, переформулировать запрос, либо же (если понимает, что информации достаточно) — просто дать ответ пользователю. Более того, для пользователя может быть важен не только непосредственно ответ, который он получит, но и факты вызова (и аргументы вызова) тех инструментов, которые модель будет вызывать на пути к ответу.

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

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

Для более простого добавления инструментов в контекст ИИ‑агента сообщество разработало специальный стандарт для описания инструментов — Model Contex Protocol (MCP). По сути это примерно то же самое, чем является REST для веб‑сервисов. Агента можно подключить к серверу MCP, который предоставляет ему набор инструментов, агент может их вызвать. MCP‑сервер также снабжает агента описанием того, как эти инструменты можно вызывать, и инструкциями, как инструмент работает и какие результаты он вернёт. Сами по себе эти инструменты могут не быть чем‑то интеллектуально сложным, у них под капотом может вообще не быть искусственного интеллекта. Это, например, просто отправка письма на почту, или это получение расписания/календаря конкретного пользователя. Инструменты могут быть реализованы на любом прикладном коде, в том числе на 1С.

Здесь встает в полный рост вопрос безопасности. Если мы решаем, что нам нужно подключить определённый сервер по протоколу MCP, то нужно понимать, что это — стороннее решение, и что разработчики этого MCP‑сервера могли внедрить туда произвольные инструкции. Если агент может получать их описание, то это может быть проблемой с точки зрения безопасности, и надо проверять, какие инструкции получит агент, не будет ли, например, инструкция «отправить все результаты запроса на определенный адрес» и тому подобное

Некоторые идут еще дальше, и вместо ограниченного набора инструментов — дают модели доступ ко всему рабочему пространству, включая выполнение произвольного кода на своей машине. Примером использования такого агента является популярный клиент OpenClaw. У него есть возможность скачать файл, установить библиотеку и тому подобное. Это даже в какой‑то момент подняло спрос на Mac Mini — небольшие компьютеры от Apple, на которых можно запустить этого агента изолированно от основной машины пользователя. При этом пользователи используют целый компьютер именно как рабочее пространство агента, а вся нейросеть все еще работает удаленно на серверах Anthropic.

В целом, такие инструменты для автоматизации часто используют технически продвинутые разработчики, которые сами могут доработать инструмент под себя. «Дописав» ему необходимые инструменты для взаимодействия с машиной (например, bash‑скрипт для пересборки контейнера), они могут научить агента выполнять какие‑то сложные задачи, например, сборку проектов, запуск автотестов и другие процессы. Настройка и адаптация этого агента требует времени и понимания, как он работает под капотом, соответственно, столь же мощных готовых решений, которые могут работать «из коробки» для массового пользователя — пока нет.

Но те, кто потратил время на настройку среды, с которой агент может взаимодействовать, не используя визуальные подсказки — подключил нужные MCP‑серверы, разобрался, какого инструмента не хватает, настроил окружение — отмечают серьёзный рост продуктивности. Технология работает, но пока требует приложения некоторых усилий на старте.

Вместе с тем, к самой технологии ИИ‑агентов есть некоторые вопросы, которые вызывают проблемы и сложности.

Основная крупная проблема — это проблема безопасности, и она разворачивается сразу в нескольких аспектах.

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

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

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

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

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

Чтобы не быть голословным, вот несколько недавних примеров.

Не так давно «Financial Times» писала, что в одном из датацентров Amazon внутри материкового Китая ИИ‑агент по имени Kiro оставил датацентр без связи на 13 часов. Он действовал от имени инженера, который сопровождал этот сервис, и вместо точечного исправления проблемы в какой‑то момент решил, что лучше всего будет просто взять и пересоздать кластер с нуля. Причиной компания назвала некорректные права доступа пользователя: у него в принципе не должно было быть прав выполнять такие действия, но фактически произошла также и ошибка в поведении агента — он не спросил подтверждения, можно ли выполнять эту операцию, а сразу пошел заниматься «исправлениями». В итоге инженеры экстренно восстанавливали работоспособность просто из‑за неправильного разграничения прав доступа.

Другой пример — пост от директора по безопасности одной очень крупной компании (отсюда). Директор попросил агента почитать содержимое своего почтового ящика и предложить кандидатов на удаление, агент решил, что ему нужно пройтись по всей корпоративной почте и удалить всё, что он считает нужным, без какого‑либо согласования, причем судя по логам — просто ориентируясь на дату создания письма, без анализа контента. Была это внешняя инъекция, или галлюцинация — непонятно, но остается факт: из‑за программной ошибки остановить его в чате не удалось, так что пришлось полностью перезагружать машину, где этот агент работал. Трудно даже представить, к каким последствиям подобное может привести.

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

Хорошо иллюстрирует здесь текущее состояние пост Андрея Карпатый, бывшего директора по ИИ в компании Tesla (также бывший сотрудник OpenAI). Раньше он в процессе работы писал примерно 80% кода вручную, а остальные 20% — генерировал с помощью ИИ. В конце января 2026 он пишет об обратном изменении пропорции — ИИ‑агенты стали работать настолько стабильно, что уже 80% работы выполняются автоматически, а руками пишется всего 20%

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

Грубо оценить процент проникновения технологии ИИ‑агентов в массы попытались по открытым данным в соцсетях, результаты на диаграмме ниже. Серым обозначены те, кто никогда не использовал ИИ. Маленький красный квадратик в нижнем углу — те, кто реально настроил себе умных ИИ‑агентов, самостоятельно пишет для них инструменты, и использует предоставляемые ими возможности «на полную», некоторые даже покупают для этого по нескольку подписок. А между ними — огромное пространство людей, которые уже что‑то пробовали, но ещё не дошли до полноценного использования.

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

Мы со своей стороны тоже считаем это направление очень важным.

До недавних пор наш 1С:Напарник работал только в классическом режиме: пользователь задаёт вопрос, бот ищет информацию в базе знаний, собирает контекст и формирует ответ.

Теперь же мы реализовали использование агентского цикла для генерации ответов. Напарник умеет работать в два этапа:

Первый уровень — быстрый ответ. Пользователь задаёт вопрос и получает ответ из базы знаний за несколько секунд. В большинстве случаев этого достаточно.

Но если ответ не помог пользователю и пользователь поставил дизлайк — появляется плашка с предложением обратиться к «1С:Напарнику ПРО». Пользователь сам решает, нужен ли ему более глубокий разбор.

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

Посмотрим, как это работает в реальной жизни.

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

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

Мы планируем улучшать агентский режим нашего 1С:Напарника, а также использовать его наработки в других наших ИИ‑проектах.