Руководство пользователя ИС "Платформа ИИ"

Глоссарий

Общие сведения

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

Пользователи платформы взаимодействуют с тремя компонентами: Low-code Конструктор для визуального проектирования, проверки и публикации агентов, Agent Registry для поиска и просмотра доступных агентов и Platform Agent Gateway для вызова агентов по разрешённым интерфейсам. Agent Registry автоматически обнаруживает агентов, развёрнутых в Kubernetes, и отображает только активные записи, для которых у пользователя есть право просмотра.

Платформа поддерживает два типа реализации агентов — low-code (созданные в визуальном редакторе) и SDK (разработанные программно), а также два протокола взаимодействия — A2A и MCP. Протокол и тип реализации независимы: служба MCP может иметь тип low-code, а агент A2A — тип sdk.

Примечание: документ скомпилирован из разделов онлайн-документации Платформы ИИ.

Функциональные возможности

Общая последовательность работы

1. Создать Поток (Flow)

Откройте адрес Low-code Конструктора, предоставленный администратором вашей среды, и войдите через SSO.

Создайте новый Flow или откройте рабочую версию. Используйте только компоненты, доступные в разрешенной палитре — она задана действующей политикой компонентов. В версии 2026.3.5 компоненты PlatformRAG и PlatformMemory в палитре отсутствуют. Минимальный Flow содержит вход, PlatformLLM и выход.

Не добавляйте:

• внешних поставщиков моделей и векторных хранилищ;
• сетевые загрузчики с непроверяемым исходящим соединением;
• открытые ключи, пароли и токены;
• произвольный код, если он не разрешен действующей политикой компонентов.

Подробные действия приведены в руководстве по Low-code Конструктору.

2. Сохранить рабочую версию

Сохраните Flow до запуска проверки. Убедитесь, что название отражает назначение агента, а не адрес среды или имя автора. Любая правка после зафиксированной версии создает новую рабочую версию; повторное сохранение одной неизмененной версии дает одинаковую контрольную сумму SHA-256.

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

3. Проверить Flow

Запустите серверную проверку и дождитесь итогового состояния. Успешный результат содержит версию проверяющего модуля, версию политики и SHA-256 исходных данных. Проверка должна подтвердить:

• корректность структуры и отсутствие недопустимых циклов;
• наличие обязательных полей;
• соответствие действующей политике компонентов;
• отсутствие открытых секретов и запрещенных импортов;
• совместимость с принятой версией lfx;
• согласованность входных и выходных данных с карточкой агента.

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

4. Опубликовать Агента

Публикация выполняется прямо из интерфейса Low-code Конструктора через Control Plane:

1. Запустите проверку Flow и дождитесь успешного результата.
2. Откройте сохраненную рабочую версию и вызовите публикацию.
3. Система экспортирует Flow в канонический формат platform.low-code.flow/v2 и от вашего имени вызывает Control Plane.
4. Control Plane выполняет проверку, создает запись Агента и версии, а также операцию публикации.
5. Publisher собирает артефакт и разворачивает экземпляр агента в Kubernetes.

Ответ 202 Accepted означает, что операция публикации принята, а не что Агент уже готов к вызовам. О завершении публикации говорит конечный статус операции. Изменяемые поля Flow.data в публикацию не попадают; прямая загрузка схемы в OCI, Kubernetes или Agent Registry запрещена.

5. Дождаться готовности среды исполнения

После развертывания Publisher доводит Low-code Runtime до рабочего состояния. Готовность подтверждается конечным статусом операции публикации.

6. Найти агента

Agent Registry автоматически обнаруживает опубликованный экземпляр в Kubernetes. Запись появляется в каталоге только после формирования карточки агента и авторизационных данных, поэтому появление агента не мгновенно.

Откройте каталог и найдите агента по протоколу, типу реализации low-code, владельцу или по смыслу через поиск.

Если агент еще не появился:

1. подождите несколько секунд и повторите запрос;
2. проверьте, что операция публикации достигла конечного успешного статуса;
3. обратитесь к администратору Платформы ИИ с идентификатором операции публикации.

Подробности приведены в руководстве по Agent Registry.

Разработчик отдельного SDK-агента использует автоматическое обнаружение через Kubernetes по инструкции регистрации SDK A2A агента.

7. Вызвать агента

Карточка в Agent Registry содержит интерфейс вызова только когда одновременно выполнены четыре условия: выбранная версия агента готова, отношения доступа согласованы, публичный маршрут принят и связан с текущей службой Kubernetes, пользователь имеет право на вызов. Используйте только URL из карточки.

Platform Agent Gateway повторно проверяет токен и право вызова агента, затем заменяет исходный пользовательский токен на короткоживущее удостоверение, связанное с конкретным агентом.

Что пользователь увидит при ошибке

Работа с файлами

Если агент принимает файл, клиент передает FileRef, а не произвольный URL или путь к хранилищу. FileRef связан с пользователем, целевым агентом, операцией и сроком действия. Измененный, просроченный или предназначенный другому агенту FileRef отклоняется до выполнения схемы.

Не включайте в обращение:

• прямую ссылку на объектное хранилище;
• идентификатор файла внутреннего поставщика;
• пользовательский токен;
• содержимое секрета или профиля Vault.

Безопасная работа

• Не размещайте секреты, персональные данные и внутренние адреса в названии, описании или полях схемы.
• Не передавайте токены и FileRef через сообщения, снимки экрана и журналы.
• Не повторяйте запрос с побочным действием автоматически, если результат предыдущего вызова неизвестен.
• Сообщая об ошибке, передавайте безопасный traceId, время, версию агента и код ошибки, но не исходный токен и не полный текст запроса.

Платформенная память (Memory Service)

Важно: В релизе 2026.3.5 Memory Service поставляется как самостоятельный сервис и не интегрирован с другими компонентами Платформы ИИ. Компонент PlatformMemory отсутствует в палитре Low-code Конструктора, поэтому сервисом пользуются только агенты, подключённые к нему через Platform SDK.

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

Как это работает

Сохранение. После ответа пользователю агент асинхронно сохраняет релевантные факты в память. Ответ приходит сразу, ожидание не требуется. Факты могут включать ваши предпочтения, данные о задачах и контекст диалога.

Извлечение. Перед ответом агент ищет релевантные факты в памяти с помощью гибридного поиска (смыслового и по ключевым словам). Результаты упаковываются в лимит токенов, чтобы не перегружать запрос к модели.

Изоляция и безопасность

Память изолирована по скоупам — комбинации user_id, agent_id и run_id. Агент одного пользователя не может прочитать память другого. Факты разных рабочих пространств не смешиваются.

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

Управление записями о вас

В интерфейсе T1GPT откройте экран «Что агент обо мне помнит»: вы увидите список фактов с датой создания и категорией. Неверную запись можно отредактировать или удалить; изменения немедленно отражаются в поиске.

Платформенный RAG (Platform RAG)

Важно: В релизе 2026.3.5 Platform RAG поставляется как самостоятельный сервис и не интегрирован с другими компонентами Платформы ИИ. Компонент PlatformRAG отсутствует в палитре Low-code Конструктора, поэтому сервисом пользуются только агенты, которые обращаются к нему через Platform SDK.

Не путайте с Memory Service. Memory Service хранит знания о пользователе и сессии. Platform RAG работает с корпусом документов.

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

Коллекции

Коллекция — управляемый контейнер документов с закреплённым профилем эмбеддинга, моделью ACL (списка видимости) и стратегией чанкинга (разбиения текста на фрагменты). Все документы в коллекции индексируются единым способом, что обеспечивает согласованный поиск.

Коллекции создаются владельцем (обычно администратором или разработчиком агента). Право на чтение коллекции позволяет искать по ней; право на запись — загружать документы.

Приём документов

Документы принимаются асинхронно. После отправки документа система регистрирует задание, разбивает текст на фрагменты (чанки), создаёт их смысловые представления (эмбеддинги) и индексирует в коллекции.

Статусы задания:

• PENDING — задание в очереди на обработку;
• RUNNING — документ обрабатывается;
• DONE — документ успешно проиндексирован;
• FAILED — обработка завершилась ошибкой.

Повторная отправка документа с тем же идентификатором и содержимым не создаёт дубликат.

Поиск

Поиск по коллекции — гибридный: совмещает смысловое (векторное) и полнотекстовое (BM25) совпадение, объединяя результаты алгоритмом RRF (Reciprocal Rank Fusion).

Результат поиска — список цитат (фрагментов документов) с указанием doc_id, chunk_id, текста фрагмента и источника. Это позволяет проверить достоверность ответа и проследить происхождение информации.

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

Авторизация и видимость

Поиск в Platform RAG всегда учитывает права доступа. Документы и фрагменты, на которые у пользователя нет прав, исключаются из выдачи автоматически, независимо от того, какой агент выполняет запрос.

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

Работа агента с RAG

SDK-агент вызывает поиск по коллекции, указывая коллекцию и текст запроса; при необходимости агент может комбинировать результаты Platform RAG (корпус документов) и Memory Service (знания о пользователе).

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

Ограничения версии

В релизе 2026.3.5 сохраняются ограничения:

• PlatformRAG и PlatformMemory отсутствуют в палитре Low-code Конструктора; Platform RAG и Memory Service поставляются как самостоятельные сервисы и не интегрированы с другими компонентами Платформы ИИ — доступ только через Platform SDK;
• промышленная готовность семантического поиска не подтверждена;
• полный жизненный цикл задач A2A и расширенные возможности MCP не входят в гарантированный профиль.

Перед началом работы ознакомьтесь с известными ограничениями.

Права доступа и роли

Документация разделяет три пользовательские роли. Один человек может совмещать их, однако права и ответственность остаются разными.

Agent Registry и Low-code Конструктор используют токен пользователя, но выполняют разные проверки доступа. Возможность открыть Low-code Конструктор не дает права видеть любой агент в каталоге, а видимость агента не дает права на его вызов.

Основные операции

Работа в Low-code Конструкторе

Назначение Low-code Конструктора

Low-code Конструктор — визуальный редактор Платформы ИИ (исходный код — LangFlow), состоящий из клиентской и серверной частей. Он служит для создания и проверки Flow агента, а также для публикации проверенной версии схемы как агента в каталоге. Конструктор не исполняет промышленный запрос, не разворачивает Low-code Runtime и не управляет записями Agent Registry и разрешениями.

Перед началом

Получите у администратора:

• адрес Low-code Конструктора для вашей среды;
• рабочую область, в которой разрешено создавать Flow;
• право автора или редактора;
• название разрешенной политики компонентов;
• сведения о доступных профилях моделей в Vault без самих секретов.

Вход выполняется через SSO Платформы ИИ.

Создание схемы

1. Создайте пустой рабочий Flow.
2. Задайте понятное название и кратко опишите назначение агента.
3. Добавьте компонент входа сообщения.
4. Добавьте PlatformLLM и выберите разрешенный профиль модели.
5. Соедините выход модели с компонентом ответа.
6. Проверьте типы входных и выходных данных каждого соединения.
7. Сохраните рабочую версию до запуска проверки.

Разрешенные и отложенные компоненты

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

Вход, выход и управление потоком:

• ChatInput — точка входа сообщения (обязательна, минимум одна);
• ChatOutput — точка ответа (обязательна, минимум одна);
• Webhook — вход по внешнему вызову;
• ConditionalRouter — развилка по условию;
• LoopComponent — повторение блока;
• Listen, Notify — ожидание события и уведомление;
• HumanInput — подтверждение или ввод от человека.

Модели и агенты:

• PlatformLLM (языковая модель) и EmbeddingModel — генерация и смысловые представления;
• Prompt Template — шаблон промпта;
• Agent, A2AAgent — вызов другого агента;
• Memory — память диалога внутри схемы;
• SciboxModelComponent — специализированная модель платформы.

Обработка данных:

• ParserComponent — разбор структурированных данных;
• SplitText — разбивка текста на фрагменты;
• TypeConverterComponent — преобразование типов;
• DynamicCreateData — формирование данных на лету;
• Operations — типовые операции над данными.

Источники данных и файлы:

• APIRequest — запрос к API;
• URLComponent, UnifiedWebSearch — получение и поиск в вебе;
• MockDataGenerator — тестовые данные;
• File, FileSystemTool, SaveToFile — чтение, работа с файлами и сохранение результата.

Операции LLM и утилиты:

• BatchRunComponent — пакетный запуск;
• GuardrailValidator — проверка результата по правилам;
• SmartRouter — маршрутизация запроса к подходящей модели;
• CalculatorComponent — вычисления;
• CurrentDate — текущая дата и время.

В версии 2026.3.5 в палитре и в публикации недоступны:

• PlatformRAG и PlatformMemory — сервисы поставляются отдельно и подключаются только через Platform SDK;
• компоненты произвольного кода (интерпретатор Python, «умное» преобразование) — исполняют пользовательский код, что политика запрещает;
• SQLComponent (работы с базой данных), Knowledge, MemoryBase (накопительная база памяти), RunFlow (вложенный поток), LLMSelectorComponent, StructuredOutput — их поддержка средой исполнения еще не включена в текущий релиз;
• MCPTools — отдельная возможность, не рекламируемая в текущем профиле публикации.

Требования к схеме

Чтобы схему приняли проверка и публикация:

• в схеме есть хотя бы один ChatInput и один ChatOutput — они служат точками входа и выхода для вызова агента;
• все узлы взяты из разрешенных в политике;
• число узлов не превышает 128, число связей — 512;
• разрешены ветвление и циклы.

Секреты и профили моделей

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

1. сохраните схему без секрета;
2. запишите имя требуемого поставщика и рабочую область;
3. отправьте запрос администратору по принятому процессу управления секретами;
4. после создания профиля повторите проверку.

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

Сохранение версии

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

• идентификатор;
• номер рабочей версии;
• время сохранения;
• примененную политику компонентов;
• версию Low-code Конструктора, если она отображается.

Конструктор не позволяет перезаписать уже зафиксированную версию: любая правка создает новую рабочую версию. Повторное сохранение одной неизмененной версии дает одинаковую контрольную сумму SHA-256.

Проверка

Запустите серверную проверку и дождитесь итогового состояния. Успешный результат должен содержать версию проверяющего модуля, версию политики и SHA-256 исходных данных.

Типичные ошибки:

Подготовка к публикации

Публикации подлежит только рабочая версия Flow, прошедшая серверную проверку. Перед публикацией:

• убедитесь, что в схеме нет ручных правок компонентов вне действующей политики;
• замените секреты именами профилей Vault;
• проверьте, что изменяемые поля схемы не несут данных, которые нельзя передать потребителю;
• зафиксируйте номер рабочей версии и контрольную сумму SHA-256.

Не редактируйте JSON схемы вручную после успешной проверки: это отменит состояние проверки и потребует повторного прогона.

Публикация агента

В версии 2026.3.5 Low-code Конструктор публикует проверенную версию Flow как агента в каталоге Платформы ИИ прямо из интерфейса:

1. Запустите проверку Flow и дождитесь успешного результата.
2. Откройте сохраненную рабочую версию и вызовите публикацию в интерфейсе.
3. Система экспортирует Flow в канонический формат platform.low-code.flow/v2 и от вашего имени вызывает Control Plane.
4. Control Plane выполняет проверку, создает запись агента и версии, а также операцию публикации.
5. Publisher собирает артефакт и разворачивает экземпляр агента в Kubernetes.

Признаки успешной публикации:

• ответ 202 Accepted означает, что операция публикации принята, а не что агент уже готов к вызовам;
• о завершении публикации говорит конечный статус операции;
• напрямую обращаться в Control Plane из Конструктора нельзя — все запросы идут через шлюз платформы.

Ограничения публикации:

• изменяемые поля схемы в публикацию не попадают;
• неизвестный или измененный вручную компонент отклоняется с ошибкой;
• прямая загрузка схемы в OCI, Kubernetes или Agent Registry запрещена.

Проверка результата публикации

Когда операция публикации завершится:

1. откройте Agent Registry;
2. найдите агента по названию и типу реализации low-code;
3. сравните опубликованную версию с рабочей версией схемы, которую вы публиковали;
4. убедитесь, что интерфейс вызова виден только при наличии соответствующего права;
5. выполните проверочный вызов через Platform Agent Gateway;
6. сохраните безопасный traceId и результат вызова без секретов.

Если операция публикации осталась в промежуточном состоянии, обратитесь к администратору Платформы ИИ с идентификатором операции из Low-code Конструктора.

Полная версия руководства пользователя

Полная версия руководства пользователя Low-code Конструктора интегрирована в пользовательский веб-интерфейс визуального редактора.

Работа с Agent Registry

Назначение каталога

Agent Registry отображает список агентов, автоматически обнаруженных в Kubernetes.

Каталог возвращает только активные записи. Пользователь видит те из них, для которых авторизационное ядро подтвердило право просмотра. Создать, изменить, удалить или вызвать агента через каталог нельзя: состояние формируется из наблюдения, а вызов выполняется через Platform Agent Gateway.

Вход

Для входа откройте в браузере URL Swagger UI, нажмите Authorize и выберите oauth2Password и введите логин и пароль вашей учетной записи.

Базовый путь интерфейса — /api/v2. Для защищенных операций требуется удостоверение OIDC/JWT (Bearer); каждый ответ содержит traceId для диагностики.

Просмотр списка

Выполните GET /api/v2/agents?limit=20. Ответ содержит только активные записи, видимые пользователю. Каждая запись содержит безопасные сведения об агенте, выбранной версии, протоколе, состоянии и владельце.

Доступные фильтры:

• протокол protocol — a2a, mcp;
• тип реализации implementationType — sdk, low-code;
• владелец — ownerType вместе с ownerIssuer и ownerSubject;
• размер страницы limit (1–100, по умолчанию 20) и непрозрачный курсор cursor для постраничной навигации.

Протокол и тип реализации агента независимы и применяются совместно. Например, служба MCP может иметь тип low-code, а агент A2A — тип sdk. Значение mcp — это протокол, а не тип реализации.

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

Просмотр одной записи

GET /api/v2/agents/{agentId} принимает непрозрачный UUID. Запросы к отсутствующему и недоступному агенту возвращают одинаковый ответ 404. Это защищает сам факт существования агента.

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

Поле интерфейса вызова возвращается только когда:

1. выбранная версия агента готова;
2. отношения доступа согласованы;
3. публичный маршрут принят и связан с текущей службой Kubernetes;
4. пользователь имеет право на вызов.

Поиск

POST /api/v2/agents/search принимает текст запроса, рабочую область, фильтры протокола и типа реализации, максимальное число результатов topK и необязательный более строгий порог minScore. Поля userId, роли и готовое решение о доступе запрещены — доступ к каждому кандидату проверяется платформой.

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

Переход к вызову

Если в записи есть интерфейс, используйте только его URL — канонический HTTPS-адрес Platform Agent Gateway для конкретного агента и версии — без подмены агента, версии или внутренней службы через заголовок, параметр или тело. Вызов проходит через Platform Agent Gateway, который повторно проверяет токен и право на вызов агента agent#invoke, затем заменяет исходный пользовательский токен на короткоживущее удостоверение, связанное с конкретным агентом. Известный URL без права не позволяет обойти шлюз.

Состояния агента

В каталоге вы увидите только записи в состоянии active. Значение всех состояний:

Информация: В процессе обнаружения агента допустима кратковременная потеря его готовности.

Ошибки

Ответ об ошибке содержит код, сообщение, traceId и детали. Ошибка не раскрывает стек, токен, внутренний URL, текст запроса или карточки и существование запрещенного кандидата.

При обращении в поддержку передавайте traceId, время, HTTP-код и идентификатор агента.

Важно: Не передавайте токен, текст закрытого запроса, внутренний адрес и полное содержимое карточки.