Как навести порядок в зоопарке AI-агентов с помощью Nasiko

Когда вы запускаете одного агента на Python для тестов, всё работает предсказуемо. Добавили второго на TypeScript, третьего на Go, и тут начинается головная боль. Агенты начинают дергать друг друга напрямую, API-ключи от моделей разлетаются по конфигам и логам, а при зацикливании диалога токены улетают тысячами за пару минут.

Nasiko Banner

Команда Nasiko-Labs решила подойти к этой проблеме так, как сетевые инженеры подходят к микросервисам. Проект Nasiko представляет собой единый control-plane для агентов, который берет на себя маршрутизацию, авторизацию, защиту от бесконечных циклов и сбор телеметрии. При этом сами агенты изолированы от внешнего мира и общаются строго через спецификацию A2A (Agent-to-Agent v1.0).

Nasiko Dashboard

Что умеет эта платформа

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

Умная маршрутизация вызовов

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

Безопасная работа с ключами и LLM Router

Вместо того чтобы прописывать OPENAI_API_KEY в переменные окружения каждого контейнера, агентам выдается внутренний адрес OPENAI_BASE_URL и короткоживущий токен. Внутренний прокси-роутер сам подставляет нужный ключ провайдера на лету. В логи и код контейнера секреты никогда не попадают.

Защита от бесконечных циклов и каскадов

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

Шлюз для инструментов по протоколу MCP

Для подключения внешних инструментов есть встроенный MCP Gateway. Он агрегирует коннекторы (например, Composio или кастомные MCP-серверы) и дает агентам единый URL для вызова функций с разграничением прав доступа на уровне конкретных агентов.

Архитектура и стек

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

PostgreSQL хранит пользователей, конфигурации агентов и зашифрованные секреты (AES-256-GCM).
Redis отвечает за счетчики вызовов и защиту от циклов.
Встроенный OCI-реестр сохраняет образы контейнеров в S3-совместимое хранилище.
Стек OpenTelemetry, Tempo и Loki собирает распределенные трейсы и логи каждого шага.

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

Быстрый старт через Docker

Чтобы поднять весь стек, знание Rust не требуется. Нужен только Docker Engine с плагином Compose V2.

Сначала клонируем репозиторий и создаем файл с переменными:

git clone https://github.com/Nasiko-Labs/nasiko.git
cd nasiko
cp .env.example .env

В .env нужно обязательно указать ваш ключ OpenAI и пароль администратора:

OPENAI_API_KEY=sk-...
ADMIN_PASSWORD=strong_password_here

После этого поднимаем инфраструктуру:

docker compose up -d

Первый запуск займет несколько минут, так как Rust-сервер скомпилируется внутри контейнера. Панель управления станет доступна по адресу http://localhost:8080.

Работа через CLI

Для разработчиков есть консольная утилита nasiko. Она ставится через Cargo:

cargo install --path cli/

Создание и запуск нового агента занимает четыре команды:

# Подключаемся к локальному кластеру
nasiko connect http://localhost:8080
nasiko auth login

# Создаем проект из шаблона
nasiko new openai assistant-bot
cd assistant-bot

# Собираем и деплоим
nasiko deploy .

# Проверяем работу в чате
nasiko chat --agent assistant-bot "Привет, чем ты можешь помочь?"

Команда deploy автоматически собирает контейнер, пушит его во встроенный реестр Nasiko и регистрирует агента в маршрутизаторе.

Где это пригодится

Проект ориентирован на команды, которые переросли простые скрипты на LangChain и строят продакшен-системы из десятков специализированных агентов.

Вот типичные сценарии, где Nasiko экономит время:

Мультиагентные пайплайны, где агенты написаны разными командами на разных языках (Python, Node.js, Go).
Системы со строгими требованиями к безопасности, где нельзя отдавать боевые API-ключи во внешние среды выполнения.
Мониторинг затрат на LLM в разрезе конкретных задач и пользователей без ручного парсинга логов.

Что в итоге

Nasiko выглядит как зрелая попытка упаковать сетевой уровень и наблюдаемость мультиагентных систем в один компактный инструмент. Здесь нет попыток навязать свой DSL для написания промптов: вы вольны писать логику на любом фреймворке, главное поддерживать спецификацию A2A v1.0.

Если вы устали вручную связывать микросервисы агентов и считать токены по разрозненным дашбордам OpenAI и Anthropic, проект определенно стоит запустить локально и пощупать. Для продакшена пока стоит помнить о жесткой привязке к Docker runtime в open-source версии, но для локальной разработки и внутренних стендов это уже рабочий вариант.