# Архитектура AI Orchestrator

## Почему отдельный проект

Оркестратор должен быть независимым от текущей Local LLM Platform.

Он должен уметь работать:
- с локальными моделями из Local LLM Platform;
- с внешними моделями;
- с любыми MCP-серверами;
- с local worker на компьютере пользователя;
- с будущими инструментами: файлы, браузер, 1С, SQL, desktop, image, audio, video.

## Разделение ответственности

### Local LLM Platform

Провайдер моделей:

```text
GET /models
POST /v1/chat/completions
POST /v1/embeddings
POST /v1/vision/analyze
```

### AI Orchestrator

Runtime управления задачами:

```text
POST /chat
POST /tasks
POST /confirmations/{id}/approve
POST /confirmations/{id}/reject
GET /tasks/{id}
GET /tasks/{id}/events
```

### 1C MCP Server

Источник инструментов:

```text
tools/list
tools/call
resources/list
resources/read
prompts/list
prompts/get
```

### Local Worker

Исполнитель на локальном компьютере:

```text
file.read
file.write
file.search
file.apply_patch
command.run
desktop.screenshot
browser.open
mcp.proxy
```

## Оркестратор и агент

В системе нет отдельной магической сущности “главный агент”.

Есть:

```text
Orchestrator = управляет выполнением
Execution Graph = план задачи
Planner = строит граф
Worker = выполняет конкретный узел графа
Reviewer = проверяет результат
Finalizer = формирует итог пользователю
```

Agent — это технический профиль выполнения:

```text
AgentProfile = prompt + model_slot + tools + limits + output_schema
```

## Правильная модель

Не так:

```text
agent запускает agent
  agent запускает agent
    agent запускает agent
```

А так:

```text
Orchestrator
   ↓
Planner
   ↓
Execution Graph
   ├─ worker: sql
   ├─ worker: 1c
   ├─ worker: file
   ├─ worker: vision
   └─ reviewer
```

Workers не создают других workers.
Они возвращают предложения или результаты orchestrator.
Только orchestrator запускает следующие узлы.