Мульти агенты V2

Это руководство раскрывает архитектуру Мульти агентов V2: подробно описываются ее основные концепции, варианты использования, состояние потока и подробные справочники узлов.

Основная концепция

Мульти агенты V2 — значительное развитие архитектуры OSMI-AI с упором на явную оркестрацию рабочего процесса и гибкость. В отличие от V1, где логика агентного графа во многом опиралась на внешние фреймворки, V2 предлагает проектировать весь флоу из набора специализированных самостоятельных узлов, разработанных нативно как базовые компоненты OSMI-AI.

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

Архитектура V2 включает систему зависимостей узлов и очередь исполнения, точно соблюдающие заданные связи и обеспечивающие изоляцию компонентов. Это позволяет реализовывать циклы, ветвления по условиям, human-in-the-loop, и другие шаблоны — делая флоу более мощным, поддерживаемым и расширяемым.

Отличия мульти агентов от платформ автоматизации

💬 Взаимодействие между агентами

Поддерживается мультимодальная коммуникация между агентами. Супервайзер-агент формулирует и делегирует задачи нескольким агентам-исполнителям, а их результаты возвращаются супервайзеру. На каждом шаге доступна полная история диалога, чтобы супервайзер выбирал следующий шаг, а исполнители понимали задачу, выбирали интеграции и выполняли действия. Такой коллаборативный паттерн обычно отсутствует в классических no-code/automation инструментах.

🙋‍♂ Человек в цикле

Выполнение может приостанавливаться в ожидании ввода человека, без блокировки основного потока. Чекпоинты сохраняются, и флоу можно возобновить с того же места даже после рестарта приложения. Агентов можно настроить на запрос разрешения перед использованием инструментов (аналогично тому, как Claude запрашивает подтверждение для MCP-инструментов)

📖 Общее состояние

Общий стейт позволяет обмениваться данными между агентами (и ветками флоу). Cм. раздел "Понимание состояния потока".

⚡ Стриминг

Поддержка Server-Sent Events (SSE) для потоковой передачи ответов LLM или агента в реальном времени. Потоковая передача также позволяет подписываться на обновления выполнения по мере продвижения рабочего процесса.

🌐 MCP-интеграции

Мульти агенты интегрирует MCP - интеграции как часть флоу, а не только как «интеграции агента». Можно подключать официальные MCP (GitHub, Jira, Brave Search и др.) и разрабатывать свои.

Мульти агенты V2 — справочник узлов

Ниже — назначение, ключевые параметры, входы и выходы каждого узла.

1. Стартовый узел

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

• Функционал: определяет способ запуска рабочего процесса и задаёт начальные условия. Может принимать ввод либо непосредственно из чат-интерфейса, либо через настраиваемую форму, отображаемую пользователю. Также позволяет инициализировать параметры состояния рабочего процесса Состояние потока в начале выполнения и управлять обработкой памяти диалога в рамках текущего запуска.
• Параметры конфигурации
  • Тип ввода: определяет способ запуска рабочего процесса — через ввод в чате пользователем или через отправленную форму Form Input.
    • Название формы, Описание формы, Типы полей формы: при выборе ввода через форму позволяют настроить внешний вид формы для пользователя, задав различные типы полей с подписью и именами параметров.
  • Эфемерная память: при включении указывает рабочему процессу начать выполнение, игнорируя все предыдущие сообщения из диалога, то есть с чистого состояния памяти.
  • Состояние рабочего процесса: определяет полный набор начальных пар ключ-значение для состояния выполнения $flow.state. Все ключи состояния, которые будут использоваться или обновляться последующими узлами, должны быть объявлены и инициализированы здесь.
• Входные данные: принимает начальные данные, запускающие рабочий процесс — это либо сообщение из чата, либо данные, отправленные через форму.
• Выходные данные: предоставляет единственный выход для подключения к первому рабочему узлу, передавая начальные входные данные и инициализированное состояние рабочего процесса.

2. Узел LLM

Предоставляет прямой доступ к настроенной большой языковой модели (LLM) для выполнения задач ИИ, позволяя рабочему процессу при необходимости выполнять извлечение структурированных данных.

• Функционал: этот узел отправляет запросы в LLM на основе заданных инструкций (сообщений) и контекста. Он может использоваться для генерации текста, суммирования, перевода, анализа, ответов на вопросы и генерации структурированного JSON-вывода согласно заданной схеме. Имеет доступ к памяти текущего диалога и может читать/записывать данные в состояние рабочего процессат Flow State.
• Параметры конфигурации
  • Модель: определяет AI-модель выбранного сервиса — например, GPT-4o от OpenAI или Google Gemini.
  • Сообщения: задают входные данные для LLM в виде последовательности ролей — Система, Пользователь, Ассистент, Разработчик — для управления ответом ИИ. В текст можно вставлять динамические данные через {{ variable }}.
  • Память: при включении определяет, должен ли LLM учитывать историю текущего диалога при формировании ответа.
    • Тип памяти, Размер окна, Максимальное количество токенов: при включении определяет, должен ли LLM учитывать историю текущего диалога при формировании ответа.
    • Входящее сообщение: указывает параметр или текст, который добавляется как последнее сообщение пользователя в конец текущего контекста диалога (включая начальный контекст и память) перед обработкой LLM/Агентом.
• Формат возвращаемого ответа: настраивает, как классифицируется вывод LLM — как сообщение от пользователя или ассистента — что влияет на дальнейшую обработку памяти и журналирование
• Структурированный JSON-вывод: даёт команду LLM форматировать ответ согласно определенной JSON-схеме с ключами, типами данных и описаниями, что обеспечивает предсказуемость и удобочитаемость для машин.
• Обновление состояния рабочего процесса: позволяет узлу изменять состояние выполнения $flow.state во время работы, обновляя заранее заданные ключи. Например, можно сохранить результат работы этого узла под определённым ключом для доступа последующих узлов.
• Входные данные: узел использует данные из начального триггера рабочего процесса или выходных данных предыдущих узлов, включая их в поля сообщений или входящего сообщения. Также может получать значения из $flow.state, если входные параметры на него ссылаются.
• Выходные данные: генерирует ответ LLM в виде обычного текста или структурированного JSON-объекта. Категория вывода — пользователь или ассистент — определяется настройкой формата возвращаемого ответа.

3. Узел агента

Представляет автономную ИИ-сущность, способную рассуждать, планировать и взаимодействовать с инструментами или источниками знаний для достижения заданной цели.

• Функциональность:

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

• Параметры настройки:
  • Модель: указывает модель ИИ из выбранного сервиса (например, GPT-4 от OpenAI или Google Gemini), которая управляет рассуждениями и принятием решений агента.
  • Сообщения: определяют начальный разговорный ввод, цель или контекст для агента, структурированные в виде последовательности ролей — System, User, Assistant, Developer. Можно вставлять динамические данные через {{ variable }}.
  • Инструменты: указывают, какие предопределённые инструменты OSMI-AI агент может использовать для достижения целей.
    • Для каждого выбранного инструмента можно включить флаг "Требуется вмешательство человека", означающий, что выполнение инструмента может при необходимости приостановиться для запроса вмешательства человека.
  • Источники знаний/База документов: настройка доступа к информации в управляемых OSMI-AI баз документов.
    • База документов: выбирает преднастроенную базу, из которого агент может извлекать информацию. База должна быть заранее подготовлена и заполнена.
    • Описывать знания: предоставляет описание содержания и назначения данной базы документов на естественном языке. Это помогает агенту понять, какой информацией оно обладает и когда целесообразно его запрашивать.
  • Знания/БД векторов: настройка доступа к внешним, ранее существующим бд векторов как дополнительных источников знаний для агента
    • БД векторов: выбирает конкретную заранее сконфигурированную векторную базу данных, по которой агент может выполнять запросы.
    • Модель встраивания: указывает модель векторизации, ассоциированную с выбранным БД вектором, обеспечивая совместимость для запросов.
    • Имя знания: присваивает этому БД вектору знаний короткое, информативное имя, которое агент может использовать как ссылку.
    • Описать знания: предоставьте естественноязычное описание содержания и назначения этого БД вектора, чтобы направлять агента на то, когда и как использовать этот конкретный источник знаний.
    • Возврат исходных документов: если включено, инструктирует агента включать информацию об исходных документах вместе с данными, полученными из БД вектора.
  • Память: если включено, определяет, следует ли агенту учитывать историю текущей ветки разговора при принятии решений и формировании ответов.
    • Тип памяти, размер окна, максимальный лимит токенов: если память используется, эти настройки уточняют, как управляется и представляется история разговора агенту - например, включать все сообщения, только последние обращения, или сводку.
    • Входное сообщение: задает параметр или текст, который будет добавлен в конец существующего контекста разговора как самое последнее сообщение пользователя — включая начальный контекст и память — перед обработкой LLM/агентом.
  • Возврат ответа: настраивает, как итоговый вывод или сообщение агента будет классифицировано — как сообщение пользователя или сообщение помощника — что может повлиять на обработку последующими системами памяти или логированием.
  • Обновление состояния потока: позволяет узлу изменять состояние выполнения рабочего процесса $flow.state во время выполнения, обновляя предопределённые ключи. Это позволяет, например, сохранять вывод этого узла агента под таким ключом, чтобы он был доступен для последующих узлов.
• Входные данные: этот узел принимает данные от предыдущих узлов или триггера рабочего процесса и подготавливает их к дальнейшей обработке. Часто включает поля cообщения или поле ввода сообщения или передаваемые данные.
• Выходные данные: возвращает обработанные данные для следующего шага или финальный результат, полученный после выполнения рассуждений, планирования и использования инструментов.

4. Узел инструментов

Обеспечивает механизм прямого и детерминированного выполнения конкретного, заранее заданного инструмента OSMI-AI в последовательности рабочего процесса. В отличие от узла агента, где LLM динамически выбирает инструмент на основе рассуждений, узел инструмента точно выполняет выбранный инструмент, указанный проектировщиком рабочего процесса во время конфигурации.

• Функциональность: этот узел используется, когда в рабочем процессе требуется выполнение известной, конкретной возможности в определённый момент, с готовыми входными данными. Он обеспечивает детерминированное действие без вовлечения рассуждений LLM для выбора инструмента.
• Как это работает
  1. Срабатывание: когда выполнение рабочего процесса достигает узла инструмента, он активируется.
  2. Идентификация инструмента: он определяет конкретный выбранный инструмент OSMI-AI в его настройках.
  3. Разрешение входных аргументов: он рассматривает конфигурацию входных аргументов инструмента. Для каждого обязательного входного параметра выбранного инструмента.
  4. Выполнение: он вызывает соответствующий код или API-запрос, связанный с выбранным инструментом OSMI-AI, передавая разрешённые входные аргументы.
  5. Генерация результата: он получает результат, возвращённый выполнением инструмента.
  6. Распространение результата: он делает этот результат доступным через свой выходной якорь для использования последующими узлами.

Параметры конфигурации:

• Выбор инструмента из списка: выберите конкретный зарегистрированный OSMI-AI инструмент, который этот узел будет выполнять, из выпадающего списка.
• Входные аргументы: определите, как данные из вашей рабочей цепочки поступают в выбранный инструмент. Этот раздел динамически адаптируется в зависимости от выбранного инструмента, отображая его конкретные необходимые входные параметры:
  • *Имя аргумента: для каждого входного параметра, которого требует выбранный инструмент (например, input для калькулятора), данное поле будет показывать ожидаемое имя параметра, определённое самим инструментом.
  • Укажите значение аргумента: задать значение для соответствующего параметра, используя динамическую параметр, такую как {{ previousNode.output }}, {{ $flow.state.someKey }}, либо введя статический текст.
• Обновление состояния потока: позволяет узлу изменять состояние выполнения рабочего процесса $flow.state во время выполнения, обновляя предопределённые ключи. Это делает возможным, например, сохранить вывод этого узла инструмента под таким ключом, чтобы он был доступен для последующих узлов.
• Входные данные: значения для аргументов инструмента, получаемые из предыдущих узлов, $flow.state, или статических настроек.
• Выходные данные: отдаёт необработанный результат работы инструмента, например, JSON-строку, текст или число.

5. Узел настройщика поиска

Выполняет целенаправленный поиск информации в настроенных баз документов.

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

Конфигурационные параметры:

• Источники знаний/База документов: укажите, какая(ие) заранее настроенная(ые) и заполненная(ые) база(ы) документов должена(ы) запрашивать этот узел для поиска релевантной информации.
• Запрос на извлечение: определите текст запроса, который будет использоваться для поиска в выбранных баз документов. Можно вставлять динамические данные с помощью {{ variables }}.
• Формат вывода: выберите, как должна быть представлена найденная информация — как обычный текст или как текст с метаинформацией, которая может включать такие детали, как названия или местоположения исходных документов.
• Обновление состояния потока: позволяет узлу изменять состояние рабочего процесса $flow.state во время выполнения, обновляя заранее определённые ключи. Например, можно сохранить вывод этого узла под определённым ключом, делая его доступным для последующих узлов.

Входные данные: требуется строка запроса — часто передаваемая как параметр из предыдущего шага или ввода пользователя — и обращается к выбранным базам документов для получения информации.

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

6. HTTP узел

Обеспечивает прямое взаимодействие с внешними веб-службами и API через протокол HTTP.

• Функциональность: Узел позволяет рабочему процессу взаимодействовать с любой внешней системой, доступной по HTTP. Он может отправлять запросы различных типов (GET, POST, PUT, DELETE, PATCH) на указанный URL, что позволяет интеграцию с сторонними API, получение данных с веб-ресурсов или вызов внешних вебхуков. Узел поддерживает настройку методов аутентификации, пользовательских заголовков, параметров запроса и различных типов тела запроса для удовлетворения требований разных API.
• Параметры конфигурации
  • Учетные данные HTTP: выберите заранее настроенные учетные данные — такие как Basic Auth, Bearer Token или API Key — для аутентификации запросов к целевому сервису.
  • Метод запроса: укажите HTTP-метод для запроса — например, GET, POST, PUT, DELETE или PATCH.
  • Целевой URL: полный URL внешнего конечного адреса, к которому будет отправлен запрос.
  • Заголовки запроса: установите необходимые HTTP-заголовки как пары ключ-значение, которые будут включены в запрос.
  • Параметры запроса URL: определите пары ключ-значение, которые будут добавлены к URL в качестве параметров запроса.
  • Тип тела запроса: выберите формат данных для тела запроса, если отправляете данные — доступны следующие варианты: JSON, необработанный текст, форма данных или x-www-form-urlencoded.
  • Тело запроса: укажите фактические данные для методов, таких как POST или PUT. Формат данных должен соответствовать выбранному типу тела. При необходимости динамические данные можно вставлять с помощью .
  • Тип ответа: укажите, как рабочий процесс должен обрабатывать ответ, полученный от сервера — возможные варианты: JSON, Текст (Text), Array Buffer или Base64 для двоичных данных.
• Входные данные: получает конфигурационные данные, такие как URL, метод, заголовки и тело запроса, часто с использованием динамических значений из предыдущих шагов рабочего процесса или из $flow.state.
• Выходные данные: возвращает ответ, полученный от внешнего сервера, обработанный в соответствии с выбранным типом ответа.

7. Узел состояния

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

• Функциональность: Узел служит точкой принятия решения, оценивая один или несколько заданных условий для направления рабочего процесса по различным путям. Он сравнивает входные значения — которые могут быть строками, числами или булевыми значениями — с помощью различных логических операторов, таких как равно, содержит, больше, или пусто. В зависимости от того, являются ли эти условия истинными или ложными, выполнение рабочего процесса продолжается по одному из отдельных выходных путей, связанных с этим узлом.
• Конфигурационные параметры
  • Условия: набор логических правил, которые узел будет оценивать.
    • Тип: укажите тип сравниваемых данных для этого правила — строка, число или логический тип.
    • Значение 1: определите первое значение для сравнения. При необходимости можно вставлять динамические данные с помощью {{ variables }}.
    • Оператор: выберите логический оператор, который будет применяться между Значением 1 и Значением 2 — например, равно, не равно, содержит, больше, пусто.
    • Значение 2: определите второе значение для сравнения, если выбранному оператору оно необходимо. Также сюда можно вставлять динамические данные через {{ variables }}.
• Входные данные: требуются данные для Значения 1 и Значения 2 для каждого условия, которое оценивается. Эти значения поступают из выводов предыдущих узлов или извлекаются из $flow.state.
• Выходные данные: предоставляют несколько точек выхода, соответствующих булевому результату (истина/ложь) оценённых условий. Прохождение рабочего процесса продолжается по конкретному пути, связанному с той точкой выхода, которая соответствует результату.

8. Узел агента условий

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

• Функциональность: Узел использует модель большого языка (LLM) для маршрутизации рабочего процесса. Он анализирует предоставленные входные данные в соответствии с набором заданных пользователем "Сценариев" — возможных исходов или категорий — руководствуясь высокоуровневыми инструкциями на естественном языке, которые определяют задачу принятия решения. ЛМ затем определяет, какой сценарий наилучшим образом соответствует текущему входному контексту. Исходя из этой классификации на базе ИИ, выполнение рабочего процесса продолжается по конкретному пути, связанному с выбранным сценарием. Узел особенно полезен для задач распознавания пользовательских намерений, сложной условной маршрутизации или тонких ситуационных решений, когда простые заранее определённые правила — как в узле условий — недостаточны.
• Конфигурационные параметры
  • Модель: указывайте модель ИИ из выбранного сервиса, которая будет выполнять анализ и классификацию сценариев.
  • Инструкции: определите общую цель или задачу для ЛМ в форме естественного языка — например, «Определить, связана ли просьба пользователя с продажами, поддержкой или общим вопросом».
  • Вход: укажите данные, часто текст из предыдущего этапа или пользовательский ввод, используя {{ variables }}, которые ЛМ проанализирует для принятия решения о маршрутизации.
  • Сценарии: настройте массив, который определяет возможные исходы или отдельные пути, которые может принять рабочий процесс. Каждый сценарий описывается на естественном языке — например, «Запрос на продажу», «Запрос поддержки», «Общий вопрос» — и каждый соответствует отдельной точке выхода узла.
• Входные данные: требуются данные для анализа и инструкции для руководства ЛМ.
• Выходные данные: обеспечивают несколько точек выхода, по одной для каждого заданного сценария. Рабочий процесс продолжается по тому пути, который ЛМ определяет как наиболее подходящий для входных данных.

9. Узел итерации

Выполняет заданный «пподпоток» — последовательность узлов, вложенных внутри него — для каждого элемента массива входных данных, реализуя цикл «для каждого».

• Функциональность: Узел предназначен для обработки коллекций данных. Он принимает массив, который можно указать напрямую или сослаться через параметр, в качестве входных данных. Для каждого отдельного элемента этого массива узел последовательно выполняет последовательность других узлов, расположенных внутри его границ на графической панели.
• Конфигурационные параметры
  • Массив входных данных: указывает массив, по которому будет происходить итерация. Передается через ссылку на параметр, в которой хранится массив из вывода предыдущего узла или из flow.state — например, {{ flow.state.itemList }}.
  • Входные данные: требуется предоставить массив в параметр ввода массива.
  • Выходные данные: обеспечивают одну точку выхода, которая активируется только после завершения выполнения вложенного подпотока для всех элементов массива. Передаваемые через этот выход данные могут включать агрегированные результаты или конечное состояние параметров, изменённых внутри цикла, в зависимости от конструкции подпотока. Узлы, расположенные внутри блока итерации, имеют свои собственные входные и выходные соединения, которые определяют порядок операций для каждого элемента.

10. Циклический узел

Явно перенаправляет выполнение рабочего процесса обратно к ранее выполненному узлу.

• Функциональность: Узел позволяет создавать циклы или повторные попытки внутри рабочего процесса. Когда выполнение достигнет узла цикла, оно не продолжит движение вперёд к новому узлу, а «перескочит» обратно к указанному целевому узлу, который уже был выполнен ранее в текущем запуске рабочего процесса. Это вызывает повторное выполнение этого целевого узла и всех последующих узлов в этой части потока.
• Конфигурационные параметры
• Обратная ссылка: выберите уникальный идентификатор ранее выполненного узла в текущем рабочем процессе, к которому необходимо возвратиться.
• Максимальное количество циклов: определяет максимальное число раз, которое эта операция цикла может быть выполнена в рамках одного запуска рабочего процесса, чтобы избежать бесконечных циклов. Значение по умолчанию — 5.
• Входные данные: получает сигнал запуска для активации. Внутренне отслеживает количество повторных циклов, выполненных в рамках текущего запуска.
• Выходные данные: узел не имеет стандартного выходного маркера, который указывал бы на дальнейшее направление выполнения. Его основная функция — перенаправлять поток выполнения обратно к целевому узлу «Вернуться к», после чего рабочий процесс продолжает выполнение дальше.

11. Узел ввода от человека

Приостанавливает выполнение рабочего процесса для запроса явного ввода, одобрения или обратной связи от человека — ключевой компонент для процессов с участием человека в цикле (Human-in-the-Loop, HITL).

• Функциональность: Узел останавливает автоматическое выполнение рабочего процесса и отображает информацию или вопрос человеку, через интерфейс чата. Передаваемый пользователю контент может быть либо статичным заранее заданным текстом, либо динамически сгенерированным моделью большого языка (LLM) на основе текущего контекста рабочего процесса. Пользователю предоставляются конкретные варианты действия — например, «Продолжить», «Отказать» — и, при включенной настройке, поле для ввода текстовой обратной связи. После того, как пользователь сделает выбор и отправит ответ, рабочий процесс продолжает выполнение по соответствующему маршруту, связанному с выбранным действием.
• Конфигурационные параметры
  • Тип описания: определяет, как формируется сообщение или вопрос для пользователя — либо статический текст, либо динамический, сгенерированный LLM.
    • Если Тип описания — фиксированныйxed (статический текст):
      • Описание: этот параметр содержит точный текст, который будет показан пользователю. Поддерживается вставка динамических данных через {{ variables }}.
    • Если Тип описания — динамический контент:
      • Модель: выбирает модель ИИ из выбранного сервиса, которая будет генерировать сообщение для пользователя.
      • Промпт: предоставляет инструкции или запрос для выбранной модели LLM для генерации отображаемого пользователю сообщения.
  • Обратная связь: если включена, пользователю будет предложено оставить отзыв через окно обратной связи, и этот отзыв будет добавлен к выходным данным узла.
• Входные данные: получает сигнал запуска для приостановки рабочего процесса. Может использовать данные из предыдущих этапов или из $flow.state через параметры в полях описание или промпт при необходимости динамического контента.
• Выходные данные: предоставляют две точки выхода — каждая соответствует конкретному действию пользователя: одна — «продолжить», другая — «отказать». Рабочий процесс продолжит выполнение по тому пути, который связан с точкой выхода, соответствующей выбранному пользователем действию.

12.Узел прямого ответа

Отправляет конечное сообщение пользователю и завершает текущий путь выполнения.

• Функциональность: Узел служит точкой завершения для отдельной ветви или всего рабочего процесса. Он принимает настроенное сообщение — которое может быть статичным текстом или динамическим содержимым из переменной — и передаёт его непосредственно конечному пользователю через интерфейс чата. После отправки данного сообщения выполнение по этой конкретной ветви завершается; дальнейшие узлы, подключённые к этой ветке, не выполняются.
• Конфигурационные параметры
  = Сообщение: задаёт текст или параметр {{ variable }}, содержащую содержимое, которое будет отправлено в качестве финального ответа пользователю.
• Входные данные: получает содержимое сообщения, которое взято из результата предыдущего узла или сохранено в $flow.state.
• Выходные данные: у узла отсутствуют выходные точки, так как его функция — завершить выполнение маршрута после отправки ответа. Финальный ответ пользователю и завершение ветки исполнения.

13. Узел пользовательской функции

Обеспечивает механизм выполнения пользовательского Javascript-кода на стороне сервера внутри рабочего процесса.

• Функциональность: Узел позволяет писать и запускать произвольные фрагменты JavaScript, предоставляя эффективный способ реализации сложных преобразований данных, уникальной бизнес-логики или взаимодействия с ресурсами, не поддерживаемыми другими стандартными узлами. Код выполняется в среде Node.js и имеет определённые способы доступа к данным:
  • Входные параметры: значения, переданные через конфигурацию входных параметров, доступны внутри функции, обычно с префиксом $. Например, если определяется входной параметр userid, к нему можно обратиться как $userid.
  • Контекст потока: доступны стандартные параметры конфигурации потока, такие как $flow.sessionId, $flow.chatId, $flow.agentId, $flow.input — исходные данные, запустившие рабочий процесс — а также весь объект $flow.state.
  • Пользовательские параметры: любые пользовательские параметры, созданные в OSMI-AI, например $vars.<variable-name>.
  • Библиотеки: функция может использовать любые библиотеки, импортированные и доступные в окружении бэкэнд-среды OSMI-AI. Функция должна возвращать строковое значение по завершении выполнения.
• Параметры конфигурации
  • параметры ввода: настройте массив определений параметров входа, которые будут переданы в область видимости вашей Javascript-функции. Для каждой переменной необходимо указать:
    • Имя параметра: имя, под которым этот параметр будет доступна внутри Javascript-кода, обычно с префиксом $ — например, если указать myValue, то к ней можно обратиться как $myValue, что соответствует отображению свойств схемы ввода.
    • Значение переменной: реальные данные, которые присваиваются переменной, могут быть статичным текстом или динамическим значением из рабочего процесса, например {{ previousNode.output }} или {{ $flow.state.someKey }}.
  • Javascript-функция: поле для редактирования кода, в котором пишется серверный Javascript-функция. Эта функция должна в конце возвращать строковое значение.
  • Обновление состояния потока: позволяет узлу изменять состояние выполнения рабочей цепочки $flow.state во время работы, обновляя заранее определённые ключи. Например, можно сохранить строковый вывод этой функции под определённым ключом, чтобы он был доступен следующим узлам.
• Входные данные: получает данные через параметры, настроенные в входных параметров. Также может косвенно обращаться к элементам контекста $flow и $vars.
• Выходные данные: производит строковое значение, возвращённое выполненной Javascript-функцией.

14. Выполнение узла потока

Обеспечивает вызов и выполнение другого полного агента или мульти агента внутри текущего рабочего процесса.

• Функциональность: Этот узел работает как вызывающий подработку подпроцесса, способствуя модульному дизайну и повторному использованию логики. Он позволяет текущему рабочему процессу запускать отдельный, заранее созданный поток — по его имени или ID в экземпляре OSMI-AI — передавать ему начальный ввод, при необходимости переопределять конкретные настройки целевого потока для этого запуска, а затем получать его конечный результат обратно для дальнейшей обработки.
• Параметры конфигурации
  • Подключение учетных данных: при необходимости укажите учетные данные API агента, если вызываемый поток требует аутентификации или специальных разрешений для выполнения.
  • Выбор потока: укажите конкретный агент или мульти агент, который этот узел выполнит, из списка доступных потоков в вашем экземпляре OSMI-AI.
  • Ввод: определите данные — статический текст или {{ variable }} — которые будут переданы в качестве основного входа вызываемому потоку при его запуске.
  • Переопределение конфигурации: по желанию, укажите JSON-объект с параметрами, которые переопределят стандартные настройки целевого потока для этого конкретного запуска — например, временно изменить модель или подсказку, используемую в под-потоке.
  • Базовый URL: по необходимости укажите альтернативный базовый URL для экземпляра OSMI-AI, хранящего целевой поток. Это полезно в распределённых системах или при доступе к потокам через разные маршруты. По умолчанию используется URL текущего экземпляра, если не задано иное.
  • Возвращать ответ как: определите, как следует классифицировать окончательный результат выполненного под-потока при возвращении его в текущий рабочий процесс — как сообщение пользователя или сообщение помощника.
  • Обновление состояния потока: позволяет узлу изменять рабочее состояние $flow.state во время выполнения, обновляя заранее заданные ключи. Например, можно сохранить вывод этого узла выполнения потока под определённым ключом, делая его доступным для последующих узлов.
• Входные данные: необходим выбор целевого потока и входных данных для его запуска.
• Выходные данные: производит окончательный результат, возвращённый выполненным целевым рабочим процессом, и форматирует его согласно параметру "Обратный ответ как".

Понимание состояния потока

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

Что такое состояние потока?

• Состояние потока ($flow.state) — это рантаймовое хранилище типа «ключ-значение», которое разделяется между узлами в рамках одного выполнения.
• Оно функционирует как временная память или общий контекст, который существует только на протяжении данного запуска/исполнения.

Назначение состояния потока

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

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

Как работает состояние потока

1. Инициализация/Объявление ключей

• Все ключи состояния, которые будут использоваться на протяжении всего рабочего процесса, должны быть проинициализированы их значениями по умолчанию (даже если они пустые) с использованием параметра Состояние потока внутри узла старта. Этот шаг фактически объявляет схему или структуру вашего $flow.state для данного рабочего процесса. Здесь вы задаёте исходные пары ключ-значение.

2. Обновление состояния / Изменение существующих ключей

• Многие операционные узлы — например, LLM, Агент, Инструмент, HTTP, Ретриверы, Пользовательская функция — включают параметр Обновить состояние потока в своей конфигурации.
• Этот параметр позволяет узлу изменять значения уже существующих ключей внутри $flow.state.
• Значение может быть статическим текстом, прямым выводом текущего узла, выводом предыдущего узла и множеством других параметров. Введите чтобы увидеть все доступные параметры.
• Когда узел выполняется успешно, он обновляет указанные ключи в $flow.state новыми значениями. Новые ключи не могут быть созданы операционными узлами; могут обновляться только заранее определённые ключи.

Чтение из состояния

• Любой входной параметр узла, который принимает параметр, может читать значения из $flow.state.
• Используйте конкретный синтаксис: {{ $flow.state.yourKey }} , заменив yourKey на фактическое имя ключа, которое было объявлено в узле старта.
• Например, промпт узла LLM может содержать: "...на основе статуса пользователя: {{ $flow.state.customerStatus }}".

Область видимости и сохранение состояния:

• Оно создаётся и инициализируется при начале выполнения рабочего процесса и уничтожается по его завершении.
• Не сохраняется между различными сессиями пользователя или отдельными запусками одного и того же рабочего процесса.
• Каждое параллельное выполнение рабочего процесса сохраняет собственное независимое состояние $flow.state.