◆ Технический документ · v1.0 · май 2026

Техническая архитектура.

Как устроены агенты и их хостинг, нужны ли MCP-серверы, транспорт между агентами, Python vs Golang, векторные vs графовые БД и декомпозиция на сервисы.

9 доменов Go + Python NATS + Kafka vector → graph

Фундамент

6 принципов, из которых выводятся все решения

Принцип	Техническое следствие
Граница процесса = граница доверия	Каждый агент — отдельный процесс в отдельном namespace. Никакого in-process шаринга между задачами разных заказчиков.
Stateless compute, stateful storage	Воркеры не хранят состояние локально. Всё — в Postgres/Redis/MinIO/Qdrant. Воркер можно убить и пересоздать в любой момент.
Язык под нагрузку, не под моду	Python — LLM-экосистема и скорость разработки. Go — конкурентность, латентность, демоны. Rust — точечно для hot-path.
Один протокол наружу, много внутри	Наружу — gRPC + REST + MCP (для IDE). Внутри — NATS/gRPC. Не плодим зоопарк.
Событие — источник истины	Жизненный цикл задачи — лог событий (event sourcing для критичного пути). Состояние — проекция.
Деградация, а не отказ	Нет Qdrant → работаем без reuse; нет fine-tuned модели → fallback на base. Любой сервис умеет degraded-режим.

Декомпозиция · уровень 1

9 доменов (bounded contexts)

Каждый домен владеет своими данными (database-per-context). Кросс-доменное чтение — только через API/события, не через чужую БД.

Intent

Discovery, SDD-builder, pattern-retriever

Orchestration

Планирование, DAG-движок, dispatcher

Agent Execution

Воркеры, sandbox, tool-broker

Inference

vLLM, model-router, embeddings, registry

Knowledge

Корпус, reuse-engine, fine-tune

Fleet

Provisioner, scheduler, autoscaler

Quality

Mockarty, evals, review, security

Delivery

CI/CD, deploy, domain, SSL, CRM

Platform

Auth, billing, metrics, audit, tenant

Декомпозиция · уровни 2 и 3

Наборы сервисов → сервисы → язык

Домен	Набор сервисов	Сервисы (процессы)	Язык
D1 Intent	intent-suite	discovery-api · sdd-builder · pattern-retriever	Python
D2 Orchestration	orchestrator	task-planner · dag-engine · session-manager · dispatcher	Go
D3 Agent Exec	agent-runtime	supervisor · worker · tool-broker · sandbox-controller	Go+Py
D4 Inference	inference-plane	model-router · vllm-server · embedding-server · kv-cache	Go+vLLM
D5 Knowledge	knowledge-suite	corpus-api · embedding-pipeline · reuse-engine · finetune	Go+Py
D6 Fleet	fleet-control	provisioner · scheduler · health-monitor · cost-optimizer	Go
D7 Quality	quality-suite	Mockarty · eval-runner · review-agent · security-gate	Go+Py
D8 Delivery	delivery-suite	ci-orchestrator · deployer · domain-ssl-mgr · crm-connector	Go+Py
D9 Platform	platform-core	api-gateway · billing · metrics · audit · tenant · auth	Go

Вместе деплоится → один набор. Масштабируется независимо → отдельный сервис. Граница языка = граница сервиса (не смешиваем Go и Python в одном процессе).

Агенты · модель исполнения

Агент — это эфемерный процесс, а не сервис

Мы не держим 1000 живых агентов. Мы держим пул warm-слотов на GPU и запускаем в них агентов под задачи.

Назначение

Получает SDD-фрагмент + контекст от оркестратора

Подъём

Стартует в изолированном sandbox на GPU-ноде

Reasoning

Петля LLM + tool-вызовы до завершения подзадачи

Результат

Отдаёт артефакт + Evidence, пишет в стор

Уничтожение

Либо warm-reuse в пуле для следующей задачи

Warm-старт воркера

<100мс

vs 2–4 сек холодный

Изоляция

gVisor

syscall-перехват, не трогает ядро

Модель в VRAM

1×

грузится один раз на ноду

Агенты · хостинг

Двухуровневая модель: Supervisor + Worker

┌──────────────────────────────────────────────────────────────┐ │ GPU-НОДА │ │ │ │ ┌────────────────────┐ ┌──────────────────────────┐ │ │ │ agent-supervisor │ gRPC │ vllm-server (на этой │ │ │ │ (Go, 1 на ноду) │◄───────►│ же ноде, локальный) │ │ │ │ • lifecycle воркеров │ │ модель в VRAM │ │ │ │ • health/heartbeat │ └──────────────────────────┘ │ │ │ • resource limits │ ▲ локальный сокет │ │ │ • crash recovery │ │ (минимум latency) │ │ └─────────┬───────────┘ │ │ │ │ fork/exec в sandbox │ │ │ ┌────────▼────────┐ ┌────────────────┐ │ │ │ │ agent-worker #1 │ │ agent-worker #2 │─┘ │ │ │ (Python, gVisor) │ │ (Python, gVisor)│ │ │ │ reasoning loop │ │ reasoning loop │ │ │ └─────────────────┘ └────────────────┘ │ └──────────────────────────────────────────────────────────────┘

Supervisor · Go

Долгоживущий демон, один на ноду. Высокая конкурентность (десятки воркеров), низкий overhead, отличный supervision-паттерн.

Worker · Python

Эфемерный, под одну подзадачу. Reasoning I/O-bound (ждёт LLM) — GIL не мешает. Вся LLM-экосистема на Python.

Агенты · изоляция

6 слоёв sandbox-изоляции

Слой	Технология	Что изолирует
Процесс	Отдельный PID/namespace	Память, FD между воркерами
Syscall	gVisor (runsc)	Нет прямого доступа к ядру ноды
FS	OverlayFS + ephemeral layer	Чистый workspace, уничтожается после задачи
Сеть	Net namespace + egress-firewall	Только tool-broker и vllm; наружу — по allowlist (R-уровень)
Ресурсы	cgroups v2	CPU/RAM/PID limits per worker
Tenant	K8s namespace + sandbox	Задачи разных заказчиков физически не пересекаются

K8s управляет supervisor'ами и долгоживущими сервисами. Эфемерные воркеры — кастомный lightweight gVisor-spawner, а не pod-per-task: холодный старт пода — секунды, наш warm-старт — десятки мс.

Агенты · размещение

Affinity: какие агенты где живут

Роль агента	Модель	Где живёт
Orchestrator-планировщик	Qwen 3.6 35B MoE	Отдельная нода 2×A100, не делит с воркерами
Coder + Tester (одна задача)	Qwen 3.6 27B	Одна нода — общий warm KV-cache по проекту
Reviewer	Qwen 3 Coder 480B	Изолированная нода 4×A100 (независимая валидация)
Security	Qwen 3 Coder 480B	Изолирован от Coder (нет доступа к его workspace)
Docs / лёгкие	Qwen 3.5 9B	Дешёвые ноды A10, высокая плотность воркеров

🔥

Warm KV-cache

Coder и Tester одной задачи делят префикс контекста — экономия инференса.

🛡️

Изоляция ролей

Reviewer и Security физически отделены от Coder — независимая оценка без доступа к его окружению.

Ключевое решение

MCP — да, но только на границе. Внутри — нет

✓ MCP нужен — внешняя граница

IDE-интеграция (Cursor, Claude Desktop, Windsurf) — де-факто стандарт. Mockarty уже отдаёт MCP.
Tool-источники заказчика — его CRM/API он отдаёт как MCP-сервер, мы подключаем как tool-source.

✗ MCP не нужен — внутри

JSON-RPC поверх stdio/SSE — медленно для высокого RPS.
Слабая типизация контрактов, нет стриминга бинарей.
Внутри tool-вызовы идут через наш gRPC tool-broker — типизированно, быстро, с Policy enforcement.

MCP — протокол внешней границы (IDE + интеграции заказчика). Внутренняя tool-шина — собственный gRPC tool-broker с мандатным Policy enforcement. Совместимость снаружи + производительность и контроль внутри.

Tool-шина

tool-broker — единая точка enforcement

agent-worker (Python) │ tool_call(name, args) — gRPC ▼ tool-broker (Go) │ ├─► Policy Hook check (R0–R5, guardrails, квоты) ◄── мандатно ├─► FS-tool (запись в sandbox workspace) ├─► Shell-tool (выполнение в gVisor) ├─► HTTP-tool (egress через allowlist доменов) ├─► Browser-tool (headless, отдельный pool) ├─► Mockarty-tool (мок внешних API) └─► MCP-adapter ───► внешние MCP-серверы (CRM заказчика и т.п.)

Агент физически не может вызвать tool в обход брокера — egress-firewall sandbox это гарантирует. Внешние MCP-серверы подключаются как один из бэкендов брокера через MCP-adapter, а не напрямую к агенту.

Транспорт

Два класса коммуникации, правильный инструмент под каждый

Класс	Паттерн	Технология
Команды/запросы (нужен ответ)	request-response	gRPC
События/факты (fan-out)	pub-sub	NATS JetStream
Тяжёлые задачи (durable, retry)	work queue	NATS JetStream / RabbitMQ
Поток high-volume (логи, метрики)	stream	Kafka

NATS — нервная система

Control-plane: распределение задач, события жизненного цикла, heartbeat. Лёгкий, низколатентный, request-reply + work-queue + pub-sub в одном.

Kafka — кровеносная система

Data-plane high-throughput: лог reasoning-петель, per-task метрики, датасеты для Корпуса и fine-tune. Долгий retention, реплей.

Распределение задач

Путь одной задачи — через DAG, не A2A

1. SDD готов → task-planner (Go) строит DAG подзадач (Coder→Test→Review→Security→Docs) 2. dag-engine публикует готовые узлы → NATS "tasks.ready.<model>" 3. dispatcher (Go) спрашивает fleet-scheduler: "дай слот Qwen-27B с warm cache" 4. fleet-scheduler: bin-packing + affinity → node_id + worker_slot 5. dispatcher → gRPC к agent-supervisor: "spawn worker, вот контекст" 6. supervisor поднимает worker в sandbox, отдаёт задачу 7. worker гоняет reasoning-loop (LLM локально + tools через broker) 8. worker завершает → результат в стор + событие "tasks.done" 9. dag-engine разблокирует зависимые узлы → goto 2 10. все узлы done → Outcome Check → артефакты в Корпус Знаний

Прямого «агент звонит агенту» нет — это анти-паттерн (циклы, гонки). Вся координация через оркестратор и DAG. Нужен результат Reviewer? Это ребро в DAG, а не прямой вызов. At-least-once + идемпотентность по task_id+node_id.

Карта языков

Язык под нагрузку: Python · Go · Rust

LLM/ML-логика, быстро меняется, I/O-bound → Python Control-plane, демоны, hot-path, конкурентность, инфра-SDK → Go Доказанный профайлингом сверх-hot-path → Rust (после H2)

Карта языков · Python

Python — где доминирует LLM-экосистема

Сервис	Почему Python
agent-worker	LLM-экосистема, structured output, парсеры tool-calls, скорость итерации reasoning
embedding-pipeline	sentence-transformers, чанкинг, нормализация — Python-нативно
finetune-orchestrator	LLaMA-Factory / axolotl / PEFT — только Python
eval-runner	Eval-фреймворки, property-based генерация, анализ
review / security-agent	LLM-логика + AST-анализаторы
discovery / sdd-builder	LLM-heavy, быстрая эволюция промптов и шаблонов
crm-connector	Интеграции, SDK CRM-систем, не latency-критично

Python только там, где (а) доминирует LLM/ML-экосистема, или (б) логика быстро меняется и не hot-path. Эти сервисы I/O-bound — GIL не мешает.

Карта языков · Go

Go — демоны, hot-path, конкурентность, инфра

Сервис	Почему Go
orchestrator	Тысячи параллельных DAG, goroutines
agent-supervisor	Долгоживущий демон, supervision десятков воркеров, низкий overhead
tool-broker	Hot-path (каждый tool-call), латентность + строгие контракты
model-router	Высокий RPS, маршрутизация по моделям, latency-критично
fleet-control	Конкурентное управление сотнями нод
platform-core	Gateway, billing, metrics, audit — предсказуемая латентность
corpus-api / reuse-engine	Hot-path семантического поиска (обёртка над Qdrant)
delivery-suite	Docker/K8s SDK — first-class в Go

Карта языков · Rust

Rust — точечно, не на старте

Кандидат	Когда переходить
kv-cache-mgr / proxy перед vLLM	Если профайлинг покажет Go-прокси как bottleneck на пиках
egress-firewall / sandbox hot-path	Если нужен ультра-низкий overhead на перехват syscall
tokenizer-service	Высокочастотная токенизация (HF tokenizers имеют Rust-ядро)

Rust не на старте. Вводим точечно после H2, когда профайлинг укажет конкретные hot-path. Преждевременный Rust убьёт скорость разработки.

Хранилища данных

Каждому типу данных — своё хранилище

Тип	Технология	Что хранит
Реляционная	PostgreSQL 17 + Patroni	Задачи, биллинг, DAG-состояние, tenant, audit, метаданные. Источник истины.
Векторная	Qdrant	Эмбеддинги Корпуса Знаний → семантический reuse
Графовая	Apache AGE → Neo4j (H2+)	Граф зависимостей, задача→артефакт→модель→outcome
KV / cache	Redis / Valkey	Сессии, кэш инференса, rate-limit, warm-pool registry
Object	MinIO / Ceph	Evidence, артефакты, бэкапы, fine-tune датасеты, веса
Time-series	Prometheus + VictoriaMetrics	GPU/per-task/бизнес-метрики на лету
Event log	Kafka	Лог reasoning-петель → fine-tune и аудит

Ключевое решение

Векторные vs графовые: не «или-или»

Вектор (Qdrant) · с H1

Закрывает 80% reuse-кейсов сразу и дёшево:

«Найди похожую задачу по смыслу» → cosine по эмбеддингу SDD
«Найди похожий код по функциональности»

Граф · с H2+

Когда reuse выходит на структурный уровень:

«Какие артефакты породила модель и дали успешный outcome?»
«Меняем компонент X — что отвалится?» (dependency graph)
Транзитивные цепочки переиспользования и импакт-анализ

H1Не нужна. Qdrant + Postgres (рекурсивные CTE для простых связей) хватает

H2Apache AGE — граф прямо в нашем Postgres. Не плодим новый сторадж

H3Выделенный Neo4j — только если AGE упрётся в производительность

Inference Layer

vLLM локально на ноде + Go-роутер

agent-worker ──gRPC──► model-router (Go) ──► vllm-server (нужная нода/модель) │ ├─ выбор модели по роли + сложности ├─ load-balance между репликами ├─ fallback: fine-tuned → base при ошибке └─ continuous batching awareness

Вопрос	Решение	Обоснование
Движок	vLLM	PagedAttention, continuous batching
Расположение	Локально на GPU-ноде	Локальный сокет vs сеть — минимум latency
Структурный вывод	grammar-constrained (Outlines)	Валидный JSON для tool-calls без re-prompt
KV-cache	Префиксный + warm-pool по проекту	Coder+Tester делят префикс — экономия
Fine-tuned	Через Model Registry, A/B на 10%	Контролируемый canary-rollout

Состояние

Stateless compute, stateful storage

Состояние	Где	Почему
Состояние DAG задачи	Postgres	Транзакционность, источник истины
Лог событий задачи	Kafka + проекция в Postgres	Event sourcing для L4 multi-day, реплей
Сессионный контекст агента	Redis + чекпоинт в MinIO	Быстрый доступ + durable снапшот
Warm-pool / slot registry	Redis	Атомарный захват слота
Очередь готовых узлов	NATS JetStream	Work-queue с ack, at-least-once
Кэш инференса	Redis (хэш→результат, TTL)	Снижение стоимости

Задачи L4 (multi-day) не держат живой процесс сутками. Состояние — лог событий + structured memory. Воркер при возобновлении реконструирует контекст из чекпоинта → устойчивость к рестартам нод и spot-eviction.

Безопасность

Изоляция на уровне реализации

gVisor — перехват syscall, воркер не трогает ядро ноды
Egress-firewall — исходящий только в allowlist (broker, vllm); интернет — через R-уровень + HTTP-tool с allowlist доменов
Tenant-namespace — задачи заказчиков в разных K8s-namespace, нет shared-памяти

Secrets — HashiCorp Vault, воркер получает short-lived токены под конкретную задачу
Policy Hook enforcement — в tool-broker, мандатно, до любого действия (R0–R5)

Black Box (on-prem): та же архитектура в air-gapped режиме. NATS/Kafka/Postgres/Qdrant/MinIO/Vault/Keycloak — всё self-hosted в комплекте, ноль внешних подключений. Работает из коробки именно потому, что мы изначально не зависим ни от одного SaaS.

Observability + Деплой

Сквозной trace_id + node-pools

Observability-стек

Метрики	Prometheus + Grafana + VictoriaMetrics
Логи	Loki (+ PII-маскирование)
Трейсы	Tempo + OpenTelemetry
Бизнес	Metrics-engine → Grafana
GPU	DCGM exporter → Prometheus

Node-pools (k3s bare-metal)

control-plane	orchestrator, platform, NATS, PG, Redis
gpu-inference	vllm + supervisor + warm-pool
gpu-finetune	тренировочные джобы (ночь)
data	Qdrant, MinIO, Kafka, VM
edge	gateway, Mockarty, browser-pool

Каждая задача имеет сквозной trace_id: gateway → orchestrator → dispatcher → supervisor → worker → tool-broker → vllm. Полная трассируемость пути и стоимости. GitOps (Argo CD) + Helm на каждый набор + canary для router/worker.

Шпаргалка

Сводные инженерные решения

Агенты	Эфемерные процессы-воркеры (Python) в gVisor; supervisor (Go) на каждой ноде; warm-pool
Хостинг	K8s для демонов; кастомный gVisor-spawner для воркеров; vLLM локально на ноде
MCP	Да — внешняя граница (IDE, tools заказчика). Нет — внутри (свой gRPC tool-broker)
Транспорт	A2A нет → DAG. Control-plane NATS + gRPC, data-plane Kafka
Распределение	planner → DAG → dispatcher → fleet-scheduler (bin-pack + affinity + warm-cache)
Python	worker, embedding, finetune, eval, review/security, discovery/SDD
Golang	orchestrator, supervisor, tool-broker, router, fleet, platform, corpus, delivery
Rust	Точечно после H2: kv-cache proxy, tokenizer, sandbox hot-path
Графовые БД	H1 — нет. H2 — Apache AGE (в Postgres). H3 — Neo4j при необходимости
Векторные БД	Qdrant с H1 — семантический reuse (80% кейсов)

◆ Техническая архитектура · v1.0 · май 2026

Решения приняты.
Профайлинг уточнит детали.

Каждый выбор — под нагрузку, а не под моду. Граница процесса = граница доверия. Stateless compute, stateful storage.

⚙️ 9 доменов 🤖 Эфемерные агенты 🔌 MCP на границе 🚌 NATS + Kafka 🐍 Python для LLM 🦫 Go для демонов 🦀 Rust точечно 🧭 Vector → Graph 🛡️ gVisor sandbox 🔭 Сквозной trace_id

Дополняет «Архитектуру стартапа v2.1». ESC — оглавление

Техническая архитектура.

6 принципов, из которых выводятся все решения

9 доменов (bounded contexts)

Intent

Orchestration

Agent Execution

Inference

Knowledge

Fleet

Quality

Delivery

Platform

Наборы сервисов → сервисы → язык

Агент — это эфемерный процесс, а не сервис

Назначение

Подъём

Reasoning

Результат

Уничтожение

Двухуровневая модель: Supervisor + Worker

6 слоёв sandbox-изоляции

Affinity: какие агенты где живут

Warm KV-cache

Изоляция ролей

MCP — да, но только на границе. Внутри — нет

tool-broker — единая точка enforcement

Два класса коммуникации, правильный инструмент под каждый

Путь одной задачи — через DAG, не A2A

Язык под нагрузку: Python · Go · Rust

Python — где доминирует LLM-экосистема

Go — демоны, hot-path, конкурентность, инфра

Rust — точечно, не на старте

Каждому типу данных — своё хранилище

Векторные vs графовые: не «или-или»

vLLM локально на ноде + Go-роутер

Stateless compute, stateful storage

Изоляция на уровне реализации

Сквозной trace_id + node-pools

Observability-стек

Node-pools (k3s bare-metal)

Сводные инженерные решения

Решения приняты.Профайлинг уточнит детали.

Оглавление

Решения приняты.
Профайлинг уточнит детали.