Luminarys AI: платформа AI-агентов с изолированными навыками и кластеризацией

Модульная платформа для запуска AI-агентов, где каждый навык работает в WebAssembly-песочнице, агенты масштабируются на кластер из разнородных машин, а навыки пишутся на Go, Rust или AssemblyScript.

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

Готовых решений на архитектурном уровне мы не нашли — и решили построить платформу с нуля. Назвали её Luminarys AI. В этой статье расскажу, что она умеет и какие задачи закрывает.

Проблема первая: навык делает что хочет

В большинстве агентских фреймворков tool — это функция с полным доступом к системе. Хочет — читает любой файл, хочет — ходит на произвольный URL, хочет — выполняет команды. Единственная защита — ручное подтверждение каждого действия. LLM комбинирует команды, формирует новые аргументы — и пользователь вынужден снова и снова выдавать разрешения, не всегда понимая, что именно он разрешает. Автономная работа при такой модели невозможна.

Это работает в прототипах. В продакшене — нет.

Наше решение: каждый навык компилируется в WebAssembly и выполняется в изолированной песочнице. Он физически не может выйти за пределы разрешений, объявленных в его конфигурации. Хочет HTTP? Только URL из белого списка. Хочет файлы? Только в указанных директориях. Хочет выполнить команду? Только из разрешённого набора, без возможности объединять команды в цепочки.

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

# Пример: навык для работы с оборудованием
id: hardware-monitor
permissions:
  fs:
    enabled: true
    dirs:
      - "/sys/class:ro"               # чтение sysfs (датчики, устройства)
      - "/dev/serial:rw"              # доступ к serial-портам
  shell:
    enabled: true
    allowlist:
      - "lsusb **"                    # только перечисленные команды
      - "i2cget **"
      - "cat /proc/cpuinfo"
    allowed_dirs:
      - "/tmp/hw-monitor"

Навык для мониторинга температуры CPU видит только /sys/class/thermal. Навык для управления GPIO на Raspberry Pi — только /sys/class/gpio. Навык для чтения I2C-датчиков — только i2cget. Каждый получает ровно тот доступ, который ему нужен — и ни байтом больше.

При загрузке навыка платформа проверяет, что его код соответствует объявленным требованиям. Если навык запрашивает доступ к ресурсу, которого нет в конфигурации — он просто не загрузится.

Проблема вторая: один язык для всех навыков

Есть задачи, с которыми LLM не справится сама: парсинг бинарных форматов (protobuf, PCAP, ELF), OCR и распознавание документов, точные математические и инженерные вычисления, работа с AST исходного кода, ML-inference на специализированных моделях. Для каждой такой задачи разработчикам приходится создавать отдельный MCP-сервер — со своим процессом, конфигурацией, деплоем.

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

Наше решение: навыки можно писать на разных языках. Сейчас поддерживаются Go, Rust и AssemblyScript. Планируются C/C++ и другие языки.

Каждый SDK подходит для своих задач:

• AssemblyScript — лучший выбор для большинства навыков. Компактные модули (~100 KB), знакомый TypeScript-синтаксис, быстрая компиляция. Идеален для файловых операций, HTTP, работы с текстом.

• Rust — для навыков, требующих максимальной производительности или подключения нативных библиотек. Парсинг бинарных протоколов, ML-inference (ONNX), AST-анализ через tree-sitter.

• Go — когда нужна богатая стандартная библиотека Go или встраивание скриптовых языков (JavaScript VM, Python engine).

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

# Разработчик пишет один файл:
skill.go    (или skill.rs, или skill.ts)

# Кодогенератор создаёт:
lmsk generate -lang go .

# Результат:
skill.wasm  → подписывается → skill.skill — готовый модуль

Один и тот же хост загружает навыки на разных языках одновременно — они работают рядом, вызывают друг друга, делят состояние.

Пример навыка: Go

// @skill:id      ai.example.hello
// @skill:name    "Hello Skill"
// @skill:version 1.0.0
// @skill:desc    "Simple greeting skill."
package main

import sdk "github.com/LuminarysAI/sdk-go"

// @skill:method greet "Return a greeting."
// @skill:param  name required "Person name"
// @skill:result "Greeting string"
func Greet(_ *sdk.Context, name string) (string, error) {
    return "Hello, " + name + "!", nil
}

Пример навыка: Rust

/// @skill:id      ai.example.hello
/// @skill:name    "Hello Skill"
/// @skill:version 1.0.0
/// @skill:desc    "Simple greeting skill."

use luminarys_sdk::prelude::*;

/// @skill:method greet "Return a greeting."
/// @skill:param  name required "Person name"
/// @skill:result "Greeting string"
pub fn greet(_ctx: &mut Context, name: String) -> Result<String, SkillError> {
    Ok(format!("Hello, {}!", name))
}

Пример навыка: AssemblyScript

/**
 * @skill:id      ai.example.hello
 * @skill:name    "Hello Skill"
 * @skill:version 1.0.0
 * @skill:desc    "Simple greeting skill."
 */
import { Context } from "@luminarys/sdk-as";

// @skill:method greet "Return a greeting."
// @skill:param  name required "Person name"
// @skill:result "Greeting string"
export function greet(_ctx: Context, name: string): string {
  return "Hello, " + name + "!";
}

Аннотации одинаковы во всех языках — @skill:method, @skill:param, @skill:result. Кодогенератор lmsk парсит их и генерирует dispatch-код, описание для MCP, валидацию параметров.

А для любителей вайбкодинга — в каждом SDK лежит AGENTS.md с полным описанием API на нужном языке. Скормите его вашему любимому AI-ассистенту, и он напишет навык за вас. Мы проверяли — справляется.

Проблема третья: один сервер, одна машина

Типичный AI-агент работает на одной машине. Нужно отлаживать код на ARM? Запускать на edge-устройствах? Мониторить парк IoT? Один сервер не справится.

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

Реальные сценарии:

• CI/CD: агент запускает тесты на Linux-slave, собирает Windows-бинарник на Windows-slave, результаты собирает master

• Работа с оборудованием: slave на Raspberry Pi читает I2C-датчики, slave на Jetson Nano обрабатывает видео с камеры, slave на x86-сервере управляет промышленным контроллером через serial-порт — для агента это единый набор инструментов

• IoT-парк: master в облаке, десятки slave на edge-устройствах. Каждый slave предоставляет навыки для своего оборудования — GPIO, SPI, UART, USB. Агент видит весь парк как одну систему

• Мониторинг инфраструктуры: навыки для чтения sysfs, SMART-данных дисков, температуры CPU/GPU, состояния сети — каждый в своей песочнице с минимальными правами

• Гетерогенные архитектуры: x86, ARM, RISC-V, MIPS — slave на любой платформе, master объединяет всё в единое пространство навыков

При отключении slave нода уведомляет кластер, master мгновенно обновляет список доступных инструментов для подключённых клиентов. При рестарте master — slaves автоматически переподключаются и перерегистрируют свои навыки.

Между нодами работает передача файлов через встроенный relay-сервер с аутентификацией, шифрованием и проверкой целостности.

Проблема четвёртая: одна модель на все задачи

GPT-4 отлично генерирует текст, но для кода лучше подойдёт специализированная модель. Для SQL — модель, обученная на схемах БД. Для Rust — модель, знающая borrow checker.

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

Конфигурация моделей — в одном файле, без рестарта:

models:
  code_default: "deepseek-coder"
  language_overrides:
    rust: "rust-specialist"
    sql:  "sql-specialist"
  general: "claude-sonnet"

Совместимость: MCP

Платформа говорит на Model Context Protocol — открытом стандарте от Anthropic. Это значит:

• Claude Desktop, Claude Code, Cursor, Qwen Code — подключаются из коробки

• MCP Inspector работает для отладки

• Любой MCP-совместимый клиент видит навыки как инструменты

• Поддерживаются все транспорты: Streamable HTTP (/mcp), Legacy SSE (/sse), stdio

• Для Open WebUI и подобных систем доступен OpenAPI-эндпоинт (/openapi.json)

Не нужно писать адаптеры — стандартный протокол, стандартные инструменты.

Агентский режим (в разработке)

Мы проектируем агентскую систему с учётом реальных рабочих нагрузок, а не только интерактивного диалога «вопрос → один инструмент → ответ».

Батчевое выполнение

Агент может вызывать несколько инструментов за один шаг — синхронно или асинхронно:

• Синхронный батч: «прочитай три файла и верни результат когда все готовы». Платформа выполняет вызовы параллельно, собирает результаты и возвращает их агенту одним пакетом.

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

Автономный режим

Платформа поддерживает callback-модель: навык регистрирует обработчик на событие (входящие данные из сети, таймер, сообщение от другого навыка, сигнал от оборудования), и платформа вызывает его когда событие наступает.

Это позволяет строить автономных агентов, которые:

• Следят за состоянием оборудования и инфраструктуры в реальном времени

• Реагируют на данные с датчиков и внешних устройств

• Обрабатывают входящие сообщения (WebSocket, TCP, serial, MQTT через навык)

• Запускают цепочки действий при наступлении условий

Навыки при этом остаются в песочнице — callback не даёт навыку больше прав, чем объявлено в его конфигурации.

Межнавыковое взаимодействие

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

Безопасность

Безопасность заложена на уровне архитектуры, а не добавлена поверх. Каждый навык работает в WebAssembly-песочнице и не может выйти за пределы объявленных разрешений — доступ к файлам, URL, shell-командам контролируется рантаймом, а не кодом навыка. Shell-команды проверяются на цепочки, пайпы и перенаправления — LLM не сможет собрать опасную конструкцию, даже если попытается. Сетевое взаимодействие поддерживает TLS и аутентификацию. В планах — подпись пакетов навыков для верификации автора при установке из магазина.

Текущее состояние и что дальше

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

Рантайм и инфраструктура — WebAssembly-песочница, 30+ системных функций (файлы, HTTP, TCP, WebSocket, shell, архивы, системная информация, LLM-контекст), MCP-сервер (Streamable HTTP, SSE, stdio), кластеризация через NATS, передача файлов между нодами, авторизация, сборка под Linux, Windows и macOS.

SDK — три языка с полной реализацией: Go, Rust, AssemblyScript. Все три опубликованы и доступны через стандартные менеджеры пакетов. C/C++ SDK — в планах.

Примеры навыков — 15+ навыков на трёх языках. От стандартных (файловая система, git, HTTP, архивирование) до продвинутых: Python Engine (встроенный RustPython), JavaScript Engine (встроенный Goja), Tree-sitter (AST-парсинг на 10+ языках), Intent Classifier (ONNX-модель для классификации намерений). Все доступны в skill-examples.

В разработке:

• Полноценный агентский цикл — батчевое выполнение, автономный режим, callback’и

• Мульти-LLM роутинг — автоматический выбор модели под задачу

• Магазин навыков — marketplace с подписью пакетов и версионированием

• Интеграция с IDE через Agent Client Protocol

• Мульти-агентный режим с профилями доступа

• C/C++ SDK

Попробовать

Мы подготовили demo-кластер, который запускается одной командой через Docker Compose. Два узла (master + slave), 10 навыков, готовое задание для AI-агента:

git clone https://github.com/LuminarysAI/mcp-demo-cluster.git
cd mcp-demo-cluster
docker compose up -d

После старта подключите MCP-клиент (Claude Code, Cursor, Qwen CLI — конфиги уже включены в репозиторий) и дайте агенту задание из task/task.md. Агент самостоятельно напишет Go-приложение на slave-ноде, соберёт, протестирует, проверит эндпоинты с master-ноды и доставит архив с результатом на хост-машину.

SDK, примеры навыков и demo-кластер — на GitHub, документация — на luminarys.ai.

Где мы это применяем

Сейчас мы используем платформу для задач, где LLM-агент работает с большими объёмами данных, не помещающимися в контекст. Типичный сценарий: парсинг корпоративной документации (docx, PDF), формирование структурированного технического задания для LLM, выполнение и тестирование этого задания в изолированном окружении (slave-нода в Docker-контейнере со своим стеком — Go, Node.js, Python — без необходимости устанавливать что-либо на хост), сборка результатов в архив и доставка на master. Каждый этап — отдельный навык в песочнице, каждый — на нужной ноде.

Но архитектура не привязана к этому сценарию. Те же механизмы работают для автоматизации разработки (агент пишет код, запускает тесты, управляет Git), IoT (кластер на edge-устройствах), мониторинга инфраструктуры (навыки для sysfs, SMART, температуры), CI/CD (сборка на разных платформах), enterprise-автоматизации (оффлайн, собственные LLM, контроль данных).

Если вы строите AI-агентов и вам важна изоляция, масштабирование или мультиязычность — попробуйте. SDK открыт, demo запускается за минуту.

Итого

Мы решаем проблемы, с которыми сталкиваются разработчики AI-агентов: изоляция навыков, мультиязычность, масштабирование на несколько машин — уже работают. Мульти-LLM роутинг, магазин навыков, агентский цикл — в активной разработке.

Проект на стадии разработки. SDK открыт, demo доступен. Будем рады обратной связи — пишите в комментариях или на contacts@luminarys.ai.