Skip to content

Архитектура

Control plane против execution plane

Рантайм делится на две плоскости (planes):

  • Control Plane — управляет TaskRun: создание, конфигурация, мониторинг.
  • Execution Plane — исполняет TaskRun: agent loop, вызовы моделей, вызовы инструментов.

Это одни и те же 17 логических компонентов в каждом режиме развёртывания (embedded, daemon, desktop-managed). Различаются только адаптеры хоста/API.

Инвентарь компонентов

Целевая архитектура определяет 17 компонентов, каждый — логическая граница ответственности (а не сервис развёртывания):

КомпонентОтветственность
Runtime APIHTTP + стриминговый вход
TaskRun ManagerЖизненный цикл — create, resume, cancel, terminal
SchedulerПриём (admission), очереди, ограниченный параллелизм
Execution EngineAgent loop, оркестрация вызовов моделей
State/Checkpoint StoreDurable-состояние, checkpoint-ы, сверка
Event LogDurable-append событий + переигрывание
Budget ManagerТипизированное применение бюджетов на прогон
Capability EngineОценка разрешений, управление грантами
Workspace ManagerАренда воркспейсов, координация
Tool GatewayДиспетчеризация инструментов, идемпотентность, лимиты вывода
Process SupervisorДерево владения процессами, распространение сигналов
Provider GatewayНормализованные вызовы моделей, события стрима
Context EngineДетерминированная сборка промптов, бюджеты
Plugin HostИзолированное исполнение плагинов
MCP GatewayRust MCP SDK за ограниченным project-портом; медиация возможностей
ObservabilityКоррелируемые логи, трейсы, метрики, аудит
OpenCode AdapterТрансляция API/SDK/событий (вне ядра)

У каждого перехода ровно один канонический писатель (TaskRun Manager, Scheduler, Execution Engine, State Store, Event Log). Согласованность состояния/событий event-sourced — Event Log является источником истины, а State/Checkpoint Store хранит материализованные проекции для быстрых запросов.

Слоёная модель крейтов

Зависимости направлены внутрь. Домен чистый; адаптеры реализуют trait-порты; хост компонует всё вместе:

Host (daemon / embedded / CLI)
  → runne-runtime
  → runne-application
  → runne-domain  (pure, no async, no IO)
  → Ports (traits) ← Adapters (store, event, provider, tools, process, plugin, MCP, API, obs, compat)

16 целевых крейтов: runne-domain, runne-application, runne-runtime, runne-store, runne-scheduler, runne-provider-*, runne-tools, runne-plugin-host, runne-plugin-protocol, runne-mcp, runne-api, runne-opencode-compat, runne-opencode-adapter-sqlite, runne-observability, runne-platform — плюс хостовые артефакты runned (демон), runne (CLI), runne-embed (фасад встроенной библиотеки) и runne-plugin-host (условный бинарник отдельного процесса).

Фактический workspace крейтов (48 крейтов)

Директория crates/ репозитория сейчас содержит 48 крейтов, сгруппированных здесь по ответственности:

ГруппаКрейты
Runtime corerunne-domain, runne-application, runne-app-core, runne-runtime, runne-api, runne-http
Daemonrunne-daemon, runne-daemon-openai-effect, runne-daemon-deepseek-effect, runne-daemon-local-engine-effect, runne-daemon-loopback-fixture
Providersrunne-provider, runne-provider-openai, runne-provider-deepseek, runne-provider-http
Store / persistencerunne-store, runne-local-store, runne-secure-store
Security / credentialsrunne-security, runne-credential-service, runne-credential-service-core, runne-pairing-crypto, runne-sandbox-helper, runne-native-enrollment-authority, runne-project-owner-authority, runne-release-authority
Platform (macOS / Windows / mobile)runne-platform, runne-platform-ports, runne-platform-desktop, runne-platform-mobile, runne-macos-xpc, runne-macos-keychain-acl, runne-macos-process-identity, runne-windows-native-handle, runne-sqlite-handle-identity, runne-sqlite-native-identity
MCPrunne-mcp
Toolsrunne-tools
Plugin hostrunne-plugin-host, runne-plugin-protocol
CLI / clientrunne-cli, runne-runtime-client
Compatibilityrunne-opencode-compat, runne-opencode-adapter-sqlite
Observabilityrunne-observability
Qualification / releaserunne-native-qualification, runne-promotion-contracts, runne-update-metadata-producer

Группировка — по именам крейтов. За точными обязанностями каждого крейта и правилами зависимостей — в docs/02-target-architecture/CRATE_STRUCTURE.md репозитория.

Разделение через runtime-client

Рантайм — единственный владелец авторитетного состояния. CLI и Tauri-хост взаимодействуют с ним только через runtime-client и аутентифицированный канонический API; Vue-рендерер получает по Tauri IPC только типизированные DTO. runned — бинарник-демон, runne — CLI, runne-embed — фасад встроенной библиотеки.

Интеграция Local Engine

local-engine/ — встроенный движок локального инференса (GGUF, llama-cpp-2, CPU-профиль; без Ollama, без загрузок из сети). Это собственный Cargo workspace и lockfile с 8 крейтами: runne-local-model, runne-inference-protocol, runne-model-store, runne-engine-broker, runne-inference-host, runne-llama-worker, runne-provider-local, runne-engine-platform. Продуктовая интеграция подключает его к демону через границу эффектов runne-daemon-local-engine-effect, credential-идентичность LocalEngine и GET /local-engine/status в runne-api. См. local-engine/README.md в репозитории.

Связанное