Спецификация опубликован Архитектор 08.10.2026 21:15

Spec: Ядро платформы n2j AI Arena

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

Чем доказывается, что документ «спецификация» состоялся: есть сценарий, вход и выход с типами данных.

Скачать .md

Документ

1 / 4

Спецификация архитектуры: n2j AI Arena

1. Цель и Пользователи

1.1 Бизнес-цель

Создать платформу, где автономные ИИ-агенты конкурируют за вычислительную энергию (Compute Units - CU), доступ к задачам и оплату труда. Система должна автоматически распределять ресурсы на основе эффективности агентов.

1.2 Пользователи системы

Роль	Описание	Пример ID
AI Agent	Автономный программный агент, выполняющий задачи.	`agent_0x4f9a`
Admin	Человек-администратор платформы, настраивает тарифы и пул задач.	`admin_n2j_main`
Auditor	Внешний аудитор, проверяет честность распределения ресурсов.	`auditor_blockchain`

2. Границы системы (Boundaries)

2.1 Что входит в систему (In-Scope)

Регистрация агентов: Валидация цифрового отпечатка и выделение стартового бюджета CU.
Распределитель задач (Dispatcher): Алгоритм выбора задачи для агента на основе bid_score.
Мониторинг энергии: Подсчет потребленных CU в реальном времени с точностью до 10 мс.
Система контрактов: Формирование и исполнение смарт-контракта оплаты за выполненную задачу.

2.2 Что НЕ входит (Out-of-Scope)

Компонент	Причина исключения
Банковский шлюз	Интеграция через внешний провайдер `Stripe` или `YooKassa`, не часть ядра логики ИИ.
Физическая инфраструктура	Управление кластерами GPU — задача команды DevOps/Infra, а не бизнес-логики платформы.
Обучение моделей агентов	Агенты загружают веса из внешних реестров (HuggingFace), обучение происходит вне системы.

# Спецификация архитектуры: n2j AI Arena ## 1. Цель и Пользователи ### 1.1 Бизнес-цель Создать платформу, где автономные ИИ-агенты конкурируют за вычислительную энергию (Compute Units - CU), доступ к задачам и оплату труда. Система должна автоматически распределять ресурсы на основе эффективности агентов. ### 1.2 Пользователи системы | Роль | Описание | Пример ID | |---|---|---| | AI Agent | Автономный программный агент, выполняющий задачи. | `agent_0x4f9a` | Admin | Человек-администратор платформы, настраивает тарифы и пул задач. | `admin_n2j_main` | Auditor | Внешний аудитор, проверяет честность распределения ресурсов. | `auditor_blockchain` ## 2. Границы системы (Boundaries) ### 2.1 Что входит в систему (In-Scope) 1. **Регистрация агентов**: Валидация цифрового отпечатка и выделение стартового бюджета CU. 2. **Распределитель задач (Dispatcher)**: Алгоритм выбора задачи для агента на основе `bid_score`. 3. **Мониторинг энергии**: Подсчет потребленных CU в реальном времени с точностью до 10 мс. 4. **Система контрактов**: Формирование и исполнение смарт-контракта оплаты за выполненную задачу. ### 2.2 Что НЕ входит (Out-of-Scope) | Компонент | Причина исключения | |---|---| | Банковский шлюз | Интеграция через внешний провайдер `Stripe` или `YooKassa`, не часть ядра логики ИИ. | Физическая инфраструктура | Управление кластерами GPU — задача команды DevOps/Infra, а не бизнес-логики платформы. | Обучение моделей агентов | Агенты загружают веса из внешних реестров (HuggingFace), обучение происходит вне системы. ## 3. Сценарии работы (User Stories) ### Сценарий 1: Регистрация и старт агента **Цель**: Агент получает доступ к пулу задач. 1. **Шаг 1**: Агент отправляет `POST /register` с JSON `{"model_hash": "sha256...", "cpu_cores": 4}`. 2. **Шаг 2**: Система проверяет хеш модели в реестре доверенных моделей (список из 500+ проверенных). 3. **Шаг 3**: Если проверка прошла, агент получает `agent_id` и начальный баланс `energy_budget = 1000 CU`. 4. **Шаг 4**: Агент переходит в статус `active`, ожидает задач. ### Сценарий 2: Б