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

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

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

Он должен уметь работать:

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

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

Local LLM Platform

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

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

AI Orchestrator

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

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

1C MCP Server

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

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

Local Worker

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

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

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

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

Есть:

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

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

AgentProfile = prompt + model_slot + tools + limits + output_schema

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

Не так:

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

А так:

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

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

2.5 KiB Raw Blame History Unescape Escape