spaceПрямой контроль эпизода
Сценарий + спецификация задачи + seed. Объявленные роли, каталог команд, длительность решений, бюджет эпизода и objective. Контроль ревизии и idempotency защищают от случайного повторного исполнения.
Среда, в которой
решения оставляют след.
Один физический исполнитель. Несколько интерфейсов управления. Наблюдения с границей доступного знания — и обучающие данные, которые можно проверить повторным исполнением.
От Python до multi-agent RL
Gymnasium
Числовые наблюдения с padding и presence masks. Фиксированный каталог действий для данной задачи, action masks и optional variable-duration decisions. Создаётся явно; не требует глобальной регистрации Gym.
PettingZoo / MARL
Каждая роль управляет своими аппаратами и станциями. Один joint step продвигает общие часы. Team reward общий: складывать его по агентам как разные награды нельзя. Требуется extra [marl].
Структурированные агенты и LLM
Role-bound инструменты наблюдения и шага. Центральному контроллеру доступно совместное управление. Интеграция конкретной LLM и её orchestration — задача вызывающего приложения; произвольный Python-доступ не является sandbox.
Политика видит то, что ей доступно
Наблюдение — разреженный граф entities/relations, доступные локальные ресурсы, опубликованные заявки, известные продукты и работы. У каждой роли независимый append-only registry: появление скрытого чужого объекта не переставляет локальные слоты.
Доступно политике
Текущее локальное состояние, возраст измеренной RF/weather-телеметрии, раскрытые команды, masks и очищенный feedback.
Остаётся у trainer
Seeds, нераскрытые заявки, расписание будущих отказов, privileged truth, полные сценарии и checkpoint.
Маска — не оракул выполнимости
Маски проверяют наблюдаемые single-action условия и статические claims. Они не запускают будущее и не подглядывают в backend admission. Два разрешённых по отдельности действия могут конфликтовать в joint batch; окончательный допуск остаётся за native executor.
Текущий sensor-профиль
Ideal current local telemetry. Не универсальный onboard estimator, не delayed TT&C и не полноценный belief-state filter. Multi-task trainer должен согласовать семантику каталогов: одинаковый индекс в разных задачах не гарантирует одинаковое действие.
Награда привязана к выполнению
Доступны objectives delivery, throughput, SLA, efficient, robust. Они используют объявленную семантику результатов и ресурсов. Reward-компоненты доступны для диагностики trainer, но не автоматически становятся policy features.
Дисконт за шаг зависит от прошедшего физического времени. На true termination continuation discount равен нулю; при budget truncation сохраняется. Это важно при разной длительности решений.
- Синхронное исполнение. Fork состояния → batch commands → одно продвижение физики → reward и наблюдения → commit.
- Отклонённое действие не даёт бесплатного retry. Native rejection откатывает zero-time edits и расходует реальный decision interval.
- Ошибки протокола отделены. Неверная схема, stale revision и idempotency conflict не двигают физическое время.
- Доставка не равна отправке. В lifecycle-профиле fulfilment требует соответствующего наземного подтверждения.
С чем сравнивать обученную политику
Пять baseline-политик работают с causal PlanningInput, а не с прямым доступом к состоянию симулятора. Их решения выполняются тем же TaskSession, что и решения обучаемого агента.
waitКонтрольный baseline без активной работыrandom_maskedОграниченная случайная политика с собственным RNGpriorityПриоритет доступных действийearliest_deadlineРанжирование по видимым дедлайнамroute_aware_rollingТекущие стадии pipeline, urgency и ограниченный поиск совместимых наборовRoute-aware rolling перепланирует на каждой эпохе, но не прогнозирует всю будущую траекторию и не доказывает глобальную оптимальность. Node/candidate budgets, pruning и assumptions фиксируются. Скрытые будущие контакты, погода и отказы не становятся знанием baseline.
Планирование и teacher gates ↗RL-переходы и SFT с происхождением
Сначала формируется control-plane episode: сценарий, команды, переходы и native checkpoint. При загрузке решения исполняются с холодного старта и сравниваются с сохранённым результатом. Только после этой проверки создаётся обучающий экспорт.
01EpisodePrivileged trainer artifact
→02Cold replayПереходы + native state
→03RL / SFTRole-filtered rows
VerifiedEpisode позволяет проверить эпизод один раз и затем потоково выгрузить форматы. export_bundle() публикует новый набор файлов атомарно. Receipt связывает данные с хешем эпизода и результатами проверок.
Что подтверждает replay
Совпадение исполнения внутри объявленных source/dependency guards, переходов, физического состояния и сохранённых решений.
Чего replay не подтверждает
Качество reasoning, оптимальность политики, экспертность человека, физическую калибровку и пригодность корпуса для любой LLM.
Происхождение политики сохраняется как scripted, random или external. SFT — поддерживаемый формат supervised-примеров, а не автоматическое обещание экспертного teacher. Конкретные шаблоны сообщений и качество целевой модели нужно оценивать отдельно.
Разнообразие без скрытого упрощения
Фабрика генерирует синтетические варианты native сценариев: ground delivery, EO/processing, relay, recovery, shared terminals и finite-resource workloads. Параметры изменяются типизированно: объём данных, память, батарея, rate cap, дедлайны, работа CPU/payload, outage, число терминалов и TTL.
Явный sampling
Seed и bounded distributions. Невалидные или трудные draws не подменяются более лёгкими до достижения успеха.
Geometry groups
Варианты одной геометрии не делятся между train и holdout в одном frozen manifest. Смена seed не создаёт независимую геометрию.
Контроль дубликатов
Сравниваются наблюдаемые траектории, действия, masks, feedback, время, discount и reward. В cross-bundle работе нужен соответствующий registry.
Графовые fingerprints консервативны: это не универсальное решение graph isomorphism и не доказательство статистической независимости всех примеров. OOD-оценка требует заранее зафиксированных семейств, splits и gates.
Фабрика, splits и качество корпуса ↗Оператор и агент — в одной миссии
Mission Control объединяет текущую телеметрию, 3D-глобус, 2D-пройденные трассы, команды, ресурсы и журнал. SQLite-сессии переживают рестарт; checkpoint, portable archive и connection-файл решают разные задачи.
ОПЕРАТОР↔CONTROL EPOCH + REVISION↔АГЕНТ
Передача управления меняет epoch, а не физическое время. Команды старого владельца отклоняются. Capabilities разделяют operator, agent, viewer, admin и локальные роли; база хранит их хеши. Training ZIP содержит отдельную историю controller provenance.
Локальная инженерная консоль
Запустить Mission Control ↗Это не публичная multi-tenant SaaS и не защищённый flight-control сервис. SSO/TLS, изоляция организаций, deployment quotas и независимая эксплуатационная квалификация остаются отдельными этапами.