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

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

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С:Напарника, а также использовать его наработки в других наших ИИ-проектах.

Комментарии (3)


  1. CrushBy
    03.09.2026 07:53

    Забавная получилась пропорция. Три четверти статьи - пересказ, что такое ИИ-агенты, с вдохновляющим примером про командировку в Казань, где агент сам покупает билеты, бронирует отель и рассылает приглашения коллегам. А в последнем разделе выясняется, что агентский режим Напарника - это многошаговый поиск по документации. То есть от агента, который делает в системе всё то же, что и пользователь, осталось «RAG, умеющий искать больше одного раза». Это не агент из вашего же вступления, это ассистент 2023 года, которого пустили по циклу.

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

    По безопасности — логическое противоречие в соседних абзацах. Сначала: не можем гарантировать, что модель не обойдёт ограничения доступа. Через абзац: самое надёжное — гонять все вызовы инструментов под ролевой моделью от имени запустившего пользователя. Так если второе сделано, первое гарантируется автоматически: модель физически не получит то, что ей не отдаст сервер, и "решать" ей тут нечего. А если гарантий нет - значит, права проверяются не в том месте, и это проблема архитектуры, а не ИИ. Ролевая модель, которая держится на вежливости клиента, ролевой моделью не является.

    Ну и главный вопрос, который в статье аккуратно обойдён: где MCP-сервер самой 1С? Полстатьи про то, что MCP - это REST для агентов, предостережения про чужие серверы... а подключить Claude Code или Cursor к своей базе, чтобы агент создавал документы, читал регистры и запускал обработки под правами пользователя - можно? Потому что командировка в Казань из вступления - это ровно оно: инструменты-действия в учётной системе, а не поиск по ИТС. Мы у себя в lsFusion такой MCP-сервер к платформе прикрутили - агент под правами пользователя и данные читает, и действия выполняет, и никакой отдельной ПРО-кнопки для этого не понадобилось. Вот пример выполнения.


    1. shammer
      03.09.2026 07:53

      Вероятнее всего "ПРО" это уже за другой прайс, поэтому разделение


  1. dinar_007
    03.09.2026 07:53

    Вот с агентами меня больше всего напрягает даже не доступ туда, куда им нельзя, а вполне разрешённое действие, сделанное не туда :) Права у пользователя есть, подтверждение он машинально прожал — и агент бодро поменял 200 документов. Для 1С, мне кажется, нормальный откат цепочки действий вообще должен быть одной из базовых функций такого режима, где это технически возможно. Логи — хорошо, но после "всё готово" иногда гораздо нужнее кнопка "верни как было".