Техническая реализация

Metabot Runtime: исполняющее ядро для долгоживущих цифровых процессов

Metabot — это платформа для разработки и сопровождения долгоживущих процессов, развивающихся во времени. В основе платформы находится собственное исполняющее ядро — stateful event—driven temporal runtime, предназначенный для управления коммуникационными, агентными и бизнес-процессами.

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

В отличие от Temporal.io, который оркестрирует задачи внутри микросервисов, Metabot управляет контурами Bot–Lead как первичными сущностями с коммуникационным контекстом.

Технически Metabot Runtime можно рассматривать как исполняющую среду, в которой пользовательские события, API-вызовы, сценарии, данные, память, LLM-операции и интеграции выполняются внутри единого долгоживущего контура.

Это отличает Metabot от классических chatbot framework, stateless-сервисов и простых workflow-конструкторов: платформа изначально проектировалась для процессов, которые не укладываются в короткую сессию запроса-ответа и требуют сохранения траектории во времени.

Ключевая архитектурная идея

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

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

Такой контур может принимать события из разных каналов, сохранять состояние между шагами, ожидать внешних callback, webhook или действий пользователя, возобновлять выполнение спустя часы, дни или недели, выполнять native-команды, JS-команды и LLM-операции, обращаться к внутренним таблицам и внешним API, порождать дочерние процессы и трассироваться на каждом этапе исполнения.

Именно эта модель делает Metabot пригодным для задач, где сценарий не является линейной цепочкой сообщений, а превращается в управляемую цифровую траекторию: сервисная заявка, AI-ассистент, программа лояльности, обучение, сопровождение сделки, обработка обращения, персонализированная рассылка, игра, турнир, onboarding или мультиагентный процесс.

Базовые примитивы ядра

Metabot Runtime оперирует набором примитивов первого класса. Эти примитивы формируют внутреннюю онтологию платформы и определяют, как в ней описываются процессы, агенты, пользователи, команды и состояние.

Bot / Agent

Bot — логическая сущность, обладающая идентичностью, состоянием и временем жизни.

Bot может выступать в роли коммуникационного агента, бизнес-процесса, сервисного контура, AI-ассистента, игровой сущности, ролевой персоны или интерфейса к корпоративной системе.

В отличие от классической модели чат-бота, где bot часто фактически сводится к обработчику входящих сообщений, Bot в Metabot существует во времени независимо от активного соединения с пользователем. Он может приостанавливать исполнение, ожидать внешних событий и возобновлять работу после callback или внутреннего таймера с сохранённым контекстом.

Lead

Lead — пользователь, клиент, подписчик, участник процесса или внешняя система, взаимодействующая с Bot.

Связка Bot–Lead образует контур взаимодействия: долгоживущий процесс, который не завершается вместе с текущим диалогом, а продолжает существовать, накапливая состояние, историю и атрибуты.

В этой модели пользователь — не просто отправитель сообщения, а участник процесса, для которого runtime удерживает индивидуальную траекторию.

Command

Command — атомарный шаг исполнения внутри контура.

В Metabot существуют два фундаментальных типа команд:

1. Native Command — предопределённый примитив ядра с фиксированной семантикой.
2. JS Command — полноценная программа на JavaScript, исполняемая в изолированном V8-контексте.

Такое разделение позволяет соединить low-code проектирование сценариев и full-code разработку бизнес-логики в одной среде исполнения.

Script / Temporal Flow

Script или Temporal Flow — долгоживущий процесс, состоящий из команд, условий, переходов, ожиданий и повторных входов.

Сценарий в Metabot — это не одноразовая линейная последовательность шагов, а исполняемая траектория, которая может останавливаться в произвольной точке, ждать действия пользователя или внешнего webhook, продолжаться по таймеру, ветвиться по состоянию, вызывать внешние API, выполнять AI-операции и возвращаться в контур после асинхронного события.

State & Memory

State & Memory — персистентное состояние контура.

Оно может включать атрибуты Bot и Lead, параметры текущего сценария, историю событий, результаты выполненных команд, данные из внутренних таблиц, контекст текущего диалога, память AI-агента, summary предыдущих взаимодействий и данные для маршрутизации следующего шага.

Состояние в Metabot является объектом первого класса: runtime не просто обрабатывает события, а удерживает контекст процесса во времени.

Request

Request — прикладная сущность, описывающая заявку, обращение, задачу или сервисный процесс.

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

Runtime Loop

Runtime Loop — центральная исполнительная петля платформы.

Она принимает входящие события, находит соответствующий Bot–Lead контур, восстанавливает состояние, определяет следующую команду, исполняет её, сохраняет результат и переводит процесс в следующее состояние: ответ, ожидание, вызов API, переход, завершение или запуск дочернего процесса.

Жизненный цикл события

┌─────────┐ ┌──────────┐ ┌─────────┐ ┌─────────┐
│ Ingest │ → │ Restore │ → │ Execute │ → │ Persist │
└─────────┘ └──────────┘ └─────────┘ └─────────┘

Ingest — событие нормализуется Communication Layer: мессенджер, API, webhook, cron, voice. Для runtime источник не принципиален: после нормализации это элемент единого потока.

Restore — runtime находит Bot–Lead контур, восстанавливает его состояние из PostgreSQL: атрибуты, историю, память агента, параметры сценария и точку ожидания. Если контур новый — создаётся.

Execute — на основе состояния и события runtime выбирает следующий шаг: Native-команда, JS-команда в V8, LLM Query, API-вызов, ветвление или запуск дочернего процесса.

Persist — результат команды, изменения атрибутов, переходы, ошибки и observability-данные атомарно сохраняются. Процесс переводится в новое состояние: ответ, ожидание, callback, завершение или порождение дочернего контура.

Два уровня команд: Low-Code и Full-Code

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

Native-команды

Native-команды — это предопределённые примитивы ядра с фиксированной семантикой.

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

Native-команды формируют low-code слой платформы. Они позволяют проектировать сценарии без написания кода, при этом сохраняя предсказуемость и управляемость исполнения.

JS-команды

JS-команды — это полноценные программы на JavaScript, исполняемые движком V8.

JS-команда может содержать сложную бизнес-логику, расчёты, обработку JSON, преобразование данных, API-вызовы, интеграционную логику, работу с таблицами, подготовку payload, вызов LLM и маршрутизацию сценария на основе внешних данных.

JS-команды образуют full-code слой платформы. Они позволяют вынести сложную прикладную логику внутрь того же runtime, в котором исполняется сценарий, без разрыва между low-code и backend-разработкой.

Почему это важно

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

В Metabot эти уровни соединены внутри одного контура исполнения. Native-команды, JS-команды, API-вызовы, данные и AI-операции могут быть шагами одного temporal flow.

LLM Query как execution step

В Metabot вызов языковой модели реализуется не как внешняя интеграция “сбоку”, а как управляемый шаг исполнения внутри runtime.

Это принципиально важно: LLM не заменяет сценарий и не существует отдельно от бизнес-логики. Модель становится одним из компонентов контура исполнения, наряду с API-вызовом, записью в БД, ветвлением или отправкой сообщения.

Типовая схема LLM Query выглядит так:

1. Runtime собирает контекст из текущего состояния, атрибутов, памяти и истории взаимодействия.
2. Формируется структурированный prompt с описанием задачи, ограничений и доступных функций.
3. При необходимости передаётся описание tools или JSON-схема ожидаемого результата.
4. Запрос отправляется к выбранной модели.
5. Модель возвращает structured output.
6. Runtime валидирует результат по заранее определённой схеме.
7. На основе результата сценарий маршрутизируется дальше: вызывается API, изменяется состояние, отправляется ответ или запускается другой процесс.

Такой подход позволяет использовать AI не как отдельный “чат с моделью”, а как управляемую когнитивную операцию внутри бизнес-процесса.

AI в Metabot может выполнять разные роли: классифицировать обращения, извлекать сущности, маршрутизировать заявки, генерировать ответы, работать с базой знаний, выполнять RAG/GraphRAG-поиск, готовить структурированный payload, управлять инструментами через function calling / tools и поддерживать мультиагентное взаимодействие.

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

Stateful execution и гарантии исполнения

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

Это требует другой модели исполнения по сравнению с классическим request-response backend.

Сохранение состояния

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

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

At-least-once execution

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

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

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

Такой подход делает систему устойчивой к сбоям, но не скрывает от разработчика важную инженерную границу: exactly-once поведение в распределённых системах требует явного проектирования идемпотентности на уровне операций.

Ожидания, таймеры и callback

Temporal runtime позволяет процессу не занимать активный поток исполнения во время ожидания.

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

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

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

Так как Metabot поддерживает исполняемые JS-команды и бизнес-плагины, безопасность runtime является отдельным архитектурным аспектом.

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

Каждая JS-команда исполняется в V8 Isolate с заданными лимитами: heap, CPU time, hard-kill по таймауту, без прямого сетевого доступа. Внешние вызовы выполняются только через явные runtime-адаптеры.

Уровни расширения

Платформа поддерживает два основных уровня плагинов.

Global-плагины

Global-плагины доступны на уровне сервера и формируют общую библиотеку расширений платформы.

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

Business-level плагины

Business—level плагины существуют в рамках конкретного бизнес-аккаунта.

Они позволяют создавать кастомную бизнес-логику для конкретного клиента или проекта, не влияя на другие аккаунты и не смешивая контексты исполнения.

JS и PHP расширения

JavaScript является предпочтительным уровнем расширения для большинства прикладных задач, потому что он исполняется в более контролируемом контексте.

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

Такое разделение позволяет совмещать гибкость расширения с контролем доступа и уровней ответственности.

Code-as-Message: доставка поведения как данных

Один из ключевых архитектурных принципов Metabot — Code—as—Message.

В классической серверной разработке бизнес-логика обычно оформляется как статический артефакт: код проходит CI/CD, собирается, разворачивается и начинает работать после redeploy сервиса.

В коммуникационных и AI-first системах бизнес-логика меняется быстрее: меняются сценарии, сегменты, условия, интеграции, тексты, промпты, правила маршрутизации, реакции на события.

Metabot смещает границу между кодом и данными:

• сценарии интерпретируются как структуры данных;
• JS-команды могут поставлять поведение внутрь runtime;
• плагины расширяют набор доступных команд;
• бизнес-логика может обновляться без полного redeploy всей платформы;
• low-code сценарии и full-code команды исполняются в одном контуре.

Это не означает отказа от контроля версий, тестирования или инженерной дисциплины. Каждая JS-команда вместе с новыми плагинами предварительно тестируется на stage, после чего передаётся на продуктовый сервер. Code-as-Message требует явного управления версиями поведения, правами доступа, трассировкой и контролем исполнения.

Главное преимущество такого подхода — скорость изменения бизнес-логики становится ближе к скорости изменения данных и коммуникационных сценариев.

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

Конструктор моделей данных и работа с данными

Metabot включает конструктор внутренних таблиц и механизм работы с данными внутри runtime.

Разработчик может создавать произвольные таблицы, определять их структуру, сохранять и читать данные из сценариев, связывать записи с Bot, Lead, заявками и процессами, использовать данные для маршрутизации и строить прикладную бизнес-логику поверх внутренних таблиц.

Встроенное хранение важно не только как удобная альтернатива внешним таблицам, но и как часть модели исполнения.

В качестве основного хранилища платформы используется PostgreSQL. В нём сохраняются артефакты runtime, персистентные данные, состояние процессов, внутренние таблицы, пользовательские атрибуты, история исполнения и прикладные сущности, с которыми работают сценарии и агенты.

Когда состояние, пользовательские атрибуты, сценарии и прикладные данные находятся внутри одного runtime-контура, уменьшается количество сетевых round-trip к внешним сервисам, упрощается трассировка, снижается latency и повышается связность процесса.

Для внешних систем Metabot поддерживает HTTP API, webhooks, внутренние и внешние endpoint, вызовы корпоративных систем, адаптеры к CRM, Service Desk, ERP и другим backend-системам, а также сценарии синхронизации данных.

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

Утилиты разработки и переноса конфигураций

Metabot включает утилиты для сопровождения проектов на уровне конфигураций и бизнес-логики.

Ключевые задачи этого слоя: перенос готовых конфигураций между различными серверами, выгрузка проекта на диск и работа с проектной структурой во внешних средах разработки, включая Cursor.AI и аналогичные AI-native IDE.

Это позволяет выносить сложную бизнес-логику из визуального редактора в инженерный контур разработки: анализировать сценарии как проект, работать с файлами, использовать AI-инструменты для рефакторинга и проектирования логики, а затем возвращать изменения обратно в runtime.

Observability: прозрачность исполнения

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

Metabot включает слой observability, который позволяет анализировать исполнение сценариев и процессов.

В фокусе observability находятся входящее событие и его источник, активный Bot–Lead контур, состояние перед исполнением, выбранная команда, входной payload, результат команды, изменение атрибутов, переход к следующему шагу, ошибки, повторные попытки, состояние ожидания и история взаимодействия.

Такая трассировка особенно важна для AI-first систем, где результат может зависеть от контекста, промпта, памяти, извлечённых данных и structured output модели.

Observability превращает сценарий из “чёрного ящика” в анализируемую последовательность состояний и переходов.

Архитектурные слои Metabot Runtime

Архитектура ядра организована как многослойная система, где каждый слой отвечает за свой класс задач.