Как мы сделали универсальный ИИ-инструмент, который может создавать сам себя

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

На GenAI-платформе SimpleOne мы сделали универсальный конструктор, ИИ-ассистента, который умеет работать с любыми данными и сущностями платформы. Его можно настроить под задачи любого отдела, а не только под одну заранее заданную роль. Рассказываем, как это получилось.

Что может конструктор

Отвечать в диалоговом интерфейсе. Ассистент отвечает в чате, в потоке, как привычная нейронка.

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

Запоминать информацию на трех уровнях:

• краткосрочная (сессионная) память;

• долгосрочная память — сквозь сессии;

• семантическая память — «портрет» пользователя: ассистент извлекает и запоминает факты о том, с кем общается. 

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

Использовать навыки и инструменты (tools). Тул — это конкретное действие, например, вызов метода платформы или внешней системы, подключённой через MCP-адаптер. Навык — это логика: описание того, как ассистенту работать с данными на конкретном шаге, например «сделай саммари из текста и напиши письмо в таком-то стиле». Навыки пишутся под задачу и подключаются к ассистенту наравне с тулами.

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

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

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

Подробнее об архитектуре агентов в другой статье

Где это помогает

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

Привычная оперативная помощь

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

Дальше — доступ к данным и действиям на платформе. Через тулы ассистент может создавать, читать и изменять практически любые сущности SimpleOne — то же самое, что доступно человеку через обычный интерфейс платформы, только через диалог. А благодаря MCP-адаптеру это не ограничивается SimpleOne: ассистент может читать и менять данные и во внешних подключённых системах — будь то Jira, Confluence или любая другая, для которой есть MCP-сервер. При этом работает это и в обратную сторону: сам SimpleOne может выступать как MCP-сервер, чтобы агенты из внешних сред (например, из IDE разработчика) могли создавать задачи или проверять статусы прямо в платформе. Подробнее про все три схемы подключения — в статье про MCP-агентов на платформе SimpleOne. 

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

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

А ещё агентов можно использовать для разработки на платформе, об этом мы уже рассказывали на Хабре.

Автоматизированное создание ИИ-агентов

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

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

Контроль, безопасность и прозрачность

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

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

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