Как мы встроили ИИ-агентов в платформу SimpleOne архитектура, сценарии, безопасность

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

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

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

Архитектура ИИ-агентов в SimpleOne

GenAI работает на всех уровнях платформы: в Low-code инструментах, в ESM, в готовых бизнес-приложениях вроде ITSM. ИИ в SimpleOne — это встроенный слой платформы, наравне с правами доступа, рабочими процессами и бизнес-правилами.

За оркестрацию моделей отвечает наш технологический партнёр Ainergy. Архитектурный фундамент платформы SimpleOne обеспечивает работу с корпоративными знаниями через RAG и механизмы безопасности. На базе этих технологий стоят конкретные универсальные инструменты: агенты, готовые ИИ-сервисы для встраивания в конструктор рабочих процессов (workflow) и интерфейсы.

Именно так ИИ-агенты стали частью бизнес-процессов на платформе. Вот из чего агент состоит:

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

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

Адаптер объединяет два типа инструментов: методы и MCP-инструменты. Для агента они равнозначны — он просто видит единый список и выбирает из него нужное.

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

Инструменты (Tools) — действие, которое агент может вызвать через MCP-сервер: получить данные, найти документ, создать запись, обратиться к внешней системе.

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

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

Важная архитектурная особенность — гибридная модель исполнения агентов. По умолчанию агенты работают в нативном рантайме внутри SimpleOne: в той же среде, где живут бизнес-данные и процессы. Агент обращается к объектам платформы напрямую, без промежуточных интеграций и внешних контейнеров — любое действие, доступное пользователю в интерфейсе, доступно агенту на уровне платформы. Это даёт прямой доступ к данным, предсказуемую безопасность (данные не покидают периметр) и меньше точек отказа, чем у схем с внешним рантаймом.

Параллельно платформа поддерживает работу с внешними агентскими рантаймами через MCP — для случаев, когда у клиента уже есть собственная инфраструктура агентов на open-source стеке или когда данные сосредоточены не в SimpleOne, а во внешних системах. Оба варианта можно комбинировать в рамках одной платформы.

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

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

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

Как использовать агента

Настроенного ИИ-агента в SimpleOne можно вызвать из трёх точек, в зависимости от задачи и контекста.

Конструктор рабочих процессов (Workflow)

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

Например, такой процесс можно собрать для разработки. Этапы стандартные: проработка требований, разработка, ревью, тестирование, документирование, деплой. Каждый из них — это не один блок. За разработкой стоят десятки обращений к Git и отдельная среда исполнения, за тестированием — генерация и прогон автотестов, за документированием — своя логика. Часть работы выполняется не в рантайме платформы, а на внешней инфраструктуре через MCP.

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

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

Виджет через API

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

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

Универсальный интеллектуальный ассистент

Готовый диалоговый интерфейс на платформе — частный случай API-вызова, который не нужно собирать с нуля. Подробнее в следующем разделе.

Агент с агентами, или диалоговый интерфейс

В большинстве корпоративных систем ИИ-ассистент существует отдельно от рабочих процессов — это чат, который отвечает на вопросы, но не имеет доступа к данным и действиям внутри платформы. Мы для самообслуживания в корпорации сделали «агента с агентами» — универсального интеллектуального ассистента. За диалоговым интерфейсом стоят агенты с настроенными адаптерами, методами и инструкциями.

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

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

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

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

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

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

Кейс: агент-аналитик по инцидентам в ИТ-поддержке

Покажем ещё один пример агентской деятельности — это первый агентский PoC, который команда SimpleOne собрала на платформе. Реального внедрения за ним пока нет, но он хорошо показывает, как агент работает от настройки до результата.

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

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

В адаптере агента шесть методов, которые он может вызывать — порядок и выбор агент определяет самостоятельно на каждом шаге:

1. Задать вопрос, уточнить параметры задачи;
2. Найти таблицу инцидентов, где на платформе хранятся нужные данные;
3. Найти данные в таблице, собрать закрытые инциденты за конкретный период;
4. Анализировать данные — языковая модель обрабатывает полученные инциденты;
5. Создать статью для базы знаний;
6. Закрыть сессию.

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

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

Финальное решение остаётся за человеком: после того как статья сформирована, её проверяет сотрудник и только затем одобряет для публикации. Агент автоматизирует рутину — сбор, обработку, черновик — но не подменяет человека там, где нужна оценка и ответственность.

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

Безопасность и контроль доступа

Агенты на GenAI-платформе SimpleOne работают на фундаменте платформенной безопасности, которая уже есть в системе. Агент действует от имени пользователя, запустившего сессию: платформенные права вычисляются динамически в момент обращения к данным и применяются именно к этому пользователю. Это означает, что агент не может получить доступ к данным, которые недоступны самому пользователю, — даже если нужный метод есть в адаптере. Все действия фиксируются в платформенном журнале: кто, когда, через какого агента и что сделал с данными.

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

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

Если коротко, то получится трёхуровневая модель:

1. Платформенные права определяют, что пользователь вообще может делать в системе.
2. Доступ к агенту определяет, каких агентов он может запускать.
3. В разработке: доступ к методам определяет, какие инструменты агент может использовать в его сессии.

Что будет дальше

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

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

MCP расширяет эту логику на внешние системы: агент получает доступ к внешним инструментам, таким как Jira, Confluence, системы мониторинга и любые другие, через единый механизм. А сама платформа может выступать MCP-сервером для внешних агентов — тогда корпоративные данные и процессы SimpleOne становятся частью любой агентской экосистемы, которую использует компания. Об этом, кстати, мы уже писали в другом материале.