Я спроектировал архитектуру команды из 9 ИИ-агентов, где каждый агент — это отдельная open-source модель, подобранная под конкретную роль по бенчмаркам. Цель — полный цикл генерации агентов: от пользовательского запроса до кода с тестами и security review.
Дисклеймер: это исследование и проектирование архитектуры, а не готовый продукт. Дашборд — визуализация на статических данных. Playground с живым инференсом на кластере — следующий этап. Статья отвечает на вопрос «какую модель на какую роль и почему» — не на вопрос «вот оно работает в проде».
Ниже — конкретика: какие модели, на какие роли, почему именно эти, как они шарят GPU, сколько стоят в гигабайтах и какие бенчмарки реально определяют выбор. С конфигурациями развёртывания от одной RTX 4090 до кластера A100.
TL;DR: 9 логических агентов = 3-4 физических модели. Минимальный сетап — 24 GB VRAM (одна RTX 4090). Полный продакшен — 211 GB (четыре A100). Интерактивный дашборд для визуализации маппинга роль→модель→GPU.
Зачем 9 агентов вместо одного GPT-5
Первый вопрос, который задают: зачем 9 моделей, когда можно одну большую?
Ответ в бенчмарках. У каждой модели есть суперсила — и слабое место:
Модель | Active | Суперсила | Score | Слабость |
|---|---|---|---|---|
Kimi K2.5 | 32B | Кодогенерация (HumanEval) | 99.0 | Тяжёлая (1T total, ~125 GB), SWE-bench только 76.8 |
MiniMax M2.5 | 10B | Real-world баги (SWE-bench) | 80.2 | Нет данных по reasoning и instruction following |
Qwen3.5-397B | 17B | Reasoning + инструкции (GPQA / IFEval) | 88.4 / 92.6 | SWE-bench 76.4 — хорош, но не лучший кодер |
DeepSeek V3.2 | 37B | Универсал (MMLU-Pro + LiveCodeBench + Aider) | 85.0 / 83.3 / 74.2 | Нет лидерства ни в одном бенчмарке — но топ-5 везде |
GLM-4.7 | 32B | Tool use (tau-bench) | 87.4 | Заточена под оценку, а не генерацию кода |
Qwen2.5-Coder-32B | 32B | Локальный кодинг (HumanEval + Aider) | 92.7 / 73.7 | Dense-модель — нет MoE-экономии, только код |
Devstral Small 2 | 24B | Agenting в реальных кодовых базах | SWE 68.0 | 24B — слабее на abstract reasoning |
Ни одна модель не покрывает всё. Kimi K2.5 — бог HumanEval, но весит 125 GB и посредственно чинит реальные баги. Qwen3.5-397B — лучший reasoning, но не лучший кодер. GLM-4.7 — единственная модель с по-настоящему хорошим tool use — и она вообще не про кодогенерацию. DeepSeek V3.2 — везде в топ-5, но нигде не первый.
Не бывает «лучшей модели». Бывает лучшая модель для конкретной роли. Классическая софтверная команда — это специализация: аналитик не пишет код, тестировщик не проектирует архитектуру. С LLM — то же самое.
Архитектура: от запроса до деплоя
Вот как устроен пайплайн. Пользователь говорит: «Сделай мне агента поддержки, который интегрируется с Jira», и дальше:
User Request │ ▼ [1. Оркестратор] ─── декомпозиция задачи, маршрутизация │ ├──► [2. Аналитик] ─── ARD (Agent Requirement Document) │ │ │ ▼ ├──► [3. Исследователь] ─── Context Package (API, доки, паттерны) │ │ │ ▼ ├──► [4. Архитектор] ─── TDD (Technical Design Document) │ │ │ ▼ ├──► [5. Промпт-инженер] ─── Prompt Package (системный промпт, guardrails, tool configs) │ │ │ ▼ ├──► [6. Билдер] ─── код агента + конфигурации │ │ │ ▼ │ [7. Тестировщик] ─── тесты провалены? │ │ │ │ │ да │ нет │ ▼ ▼ │ [6. Билдер] [8. Критик] ─── «это хорошо сделано?» │ (fix & retry) │ │ ▼ └──────────────► [9. Безопасник] ─── Security Audit │ ▼ Production-ready Agent
Каждый агент коммуницирует через структурированные артефакты (ARD, TDD, Prompt Package), а не через свободный текст. Это критично: передача контекста через free-form текст между агентами — это «испорченный телефон» в квадрате. Артефакты со строгой схемой решают эту проблему.
Два обязательных feedback loop:
Builder ↔ Tester: код не считается готовым, пока тесты не пройдены
Builder ↔ Critic: тесты могут пройти, но код при этом быть плохим — Критик ловит именно это
9 ролей: детальный маппинг модель → задача
Теперь — самое интересное. Для каждой роли я выбрал модель по принципу: какой бенчмарк критичен для этой роли, и кто в нём лидер.
1. Оркестратор — Qwen3.5-397B (17B active)
Мозг системы. Принимает запрос, декомпозирует на подзадачи, маршрутизирует между агентами, собирает результат.
Критические бенчмарки: GPQA (глубокое рассуждение) и IFEval (точность следования инструкциям).
Почему Qwen3.5-397B: лучший GPQA 88.4% среди всех open-source + лучший IFEval 92.6%. Оркестратор должен точно понимать, что хочет пользователь, и умно решать, кому делегировать. Любая ошибка оркестратора ломает весь пайплайн по цепочке.
397 миллиардов параметров, но благодаря MoE активны только 17B на каждый токен. ~50 GB VRAM в INT4.
Бюджет: QwQ-32B (16 GB) — сильный reasoning при 32B dense.
2. Аналитик требований — Qwen3-8B
Превращает расплывчатый запрос пользователя в структурированный ARD.
Для этой роли не нужен deep reasoning или кодогенерация — нужно хорошо понимать intent и формировать structured output. Qwen3-8B с его thinking/non-thinking mode — оптимальный баланс: достаточно умный для анализа требований, достаточно лёгкий (4 GB), чтобы не отъедать GPU у более требовательных ролей.
3. Исследователь — Qwen3.5-397B (shared с Оркестратором)
Собирает контекст до проектирования: существующие решения, API-документация, reference implementations.
Шарит инстанс с Оркестратором — они никогда не работают одновременно. Оркестратор делегирует и ждёт, пока Исследователь закончит. Ноль дополнительных GPU.
Альтернатива, когда нужен огромный контекст: Llama 4 Scout с окном 10M токенов.
4. Архитектор — DeepSeek V3.2 (37B active, 685B total)
Проектирует систему: компоненты, API, data flow, error handling, выбор фреймворка.
Критические бенчмарки: нужен одновременно и хороший reasoning, и понимание кода.
Почему V3.2: MMLU-Pro 85.0 (широкая эрудиция) + SWE-bench 73.1% (понимает реальные кодовые базы) + LiveCodeBench 83.3. Это единственная модель в топ-5 одновременно по reasoning И coding бенчмаркам. ~85 GB в INT4.
Бюджет: DeepSeek-R1-Distill-Qwen-32B (16 GB) — MATH-500 94.3, CodeForces 1691.
5. Промпт-инженер — Qwen3.5-397B (shared с Оркестратором)
Создаёт системные промпты, guardrails, few-shot examples, tool configurations.
Логика выбора: модель с лучшим IFEval (92.6%) лучше всех понимает, что делает инструкции эффективными. Она знает, как LLM реагируют на формулировки — потому что сама лучше всех им следует. Шарит инстанс с Оркестратором.
6. Билдер — Qwen2.5-Coder-32B (dense)
Пишет код. Много кода. Быстро.
Специализированная coding-модель. HumanEval 92.7% (уровень GPT-4o), Aider 73.7 (polyglot — работает с разными языками и фреймворками). Dense-модель — предсказуемое качество, нет MoE-джиттера.
При INT4 — всего 16 GB. Влезает на одну consumer-карточку.
Бюджет: Qwen2.5-Coder-7B (4 GB) — HumanEval 88.4, бьёт CodeStral-22B.
Перспектива: Qwen3-Coder-Next (3B active, 80B total) — SWE-bench 70.6% при 10 GB.
7. Тестировщик — Devstral Small 2 (24B dense)
Генерирует тесты, ищет edge cases, валидирует acceptance criteria из ARD.
Ключевое: SWE-bench 68.0%. Эта модель обучена на real-world software engineering задачах. Она понимает не изолированные функции, а целые кодовые базы — контексты, зависимости, интеграции. 12 GB в INT4.
Бюджет: Falcon H1R-7B (4 GB) — AIME 83.1% reasoning при 7B. Маленькая, но думает как большая.
8. Критик — GLM-4.7 (32B active, 355B total)
Оценивает результат не по принципу «тесты прошли», а «это хорошо сделано»: качество кода, ясность промптов, надёжность guardrails, соответствие архитектуре.
Критический бенчмарк: tau-bench — оценка качества tool use в реальных сценариях. GLM-4.7: 87.4% — лучший показатель среди всех open-source моделей. Критик должен понимать, как агенты используют инструменты, и оценивать качество этого использования.
44 GB в INT4.
Бюджет: Ministral 14B Reasoning (7 GB) — AIME ~85%, GPQA 71.2.
9. Безопасник — DeepSeek V3.2 (shared с Архитектором)
Prompt injection, утечки данных, избыточные permissions, API key management, adversarial тестирование.
Шарит инстанс с Архитектором — они работают в разных фазах пайплайна (Архитектор до кода, Безопасник после). Широкая база знаний (MMLU-Pro 85.0) + понимание кода = adversarial thinking.
Бюджет: DeepSeek-R1-Qwen3-8B (4 GB) — AIME 87.5% reasoning. Adversarial thinking за 4 гигабайта.
Шаринг инстансов: 9 агентов ≠ 9 GPU
Это, пожалуй, главный архитектурный трюк. Агенты работают последовательно в пайплайне: пока Билдер пишет код, Оркестратор ждёт. Пока Тестировщик проверяет — Билдер свободен.
Модели, которые никогда не работают одновременно, разделяют один инстанс:
Shared-инстанс | Роли | Почему вместе | VRAM |
|---|---|---|---|
Qwen3.5-397B | Оркестратор, Аналитик, Исследователь, Промпт-инженер | Последовательный пайплайн — оркестратор делегирует и ждёт | 50 GB |
DeepSeek V3.2 | Архитектор, Безопасник | Архитектор работает до кода, Безопасник — после | 85 GB |
Qwen2.5-Coder-32B | Билдер, запасной Тестировщик | Билдер заканчивает до начала тестирования | 16 GB |
GLM-4.7 | Критик | Единственная модель с хорошим tau-bench | 44 GB |
Devstral Small 2 | Тестировщик | Специализация на реальных кодовых базах | 12 GB |
Итого: 9 логических агентов → 5 физических инстансов → 207 GB VRAM.
Для бюджетного варианта (3 модели, 5 агентов) — 24 GB. Одна RTX 4090.
Бенчмарки, которые реально определяют выбор
Забудьте про MMLU и HellaSwag — они давно упёрлись в потолок, лидерборды стоят на месте. В 2026 году для агентных систем критичны совсем другие метрики:
Бенчмарк | Что измеряет | Для каких ролей | Почему важен |
|---|---|---|---|
SWE-bench Verified | Починка реальных багов в реальных GitHub-репозиториях | Builder, Tester, Architect | Единственный бенчмарк, где модель работает с реальным кодом, а не toy-примерами |
IFEval | Точность следования сложным инструкциям | Orchestrator, Prompt Engineer | Оркестратор живёт на инструкциях. IFEval < 90% = агент не понимает, что от него хотят |
GPQA Diamond | Graduate-level reasoning (физика, химия, биология) | Orchestrator, Architect | Показатель глубины рассуждений. Если модель решает задачи PhD-уровня, она справится с декомпозицией |
tau-bench | Качество tool use в реальных (не синтетических) сценариях | Critic, любой агент с tools | Единственный бенчмарк, тестирующий реальное использование инструментов, а не только парсинг JSON |
Aider Polyglot | Кодогенерация на разных языках с реальным edit-test циклом | Builder | Измеряет способность модифицировать существующий код, а не писать с нуля |
LiveCodeBench | Competitive programming (свежие задачи, без утечки в training data) | Architect, Builder | Чистый тест на reasoning + код, исключает memorization |
BFCL v4 | Function calling accuracy | Любой агент с API-интеграциями | Стандартный бенчмарк для вызова функций. Лучший open-source: Qwen3.5-122B-A10B (72.2%) |
Источники: SWE-bench Verified, LiveBench, Berkeley Function Calling Leaderboard V4, Aider LLM Leaderboards, LMSYS Arena.
MoE: почему frontier-качество стало доступным
Mixture-of-Experts — главное архитектурное изменение, сделавшее этот проект возможным. Объясню на конкретных числах:
Модель | Всего параметров | Активных за токен | Качество | VRAM (INT4) |
|---|---|---|---|---|
Qwen3.5-397B | 397B | 17B | ≈ Claude 3.5 Sonnet | 50 GB |
MiniMax M2.5 | 230B | 10B | SWE-bench 80.2% (лучший open-source) | 29 GB |
Qwen3-Coder-Next | 80B | 3B | SWE-bench 70.6% | 10 GB |
DeepSeek V3.2 | 685B | 37B | MMLU-Pro 85.0, LiveCodeBench 83.3 | 85 GB |
Как это работает: Все 397B параметров загружены в VRAM, но на каждый токен работает маленькая часть — 17B. Это как офис на 400 человек, где над каждой задачей работают 17, но каждый раз — другие 17 специалистов.
Для VRAM это значит: вы платите за хранение всех параметров (VRAM = total params). Но при вычислениях платите за инференс только активных (скорость ≈ dense-модель размера active params).
Для агентной фабрики, где агенты работают последовательно, MoE идеален:
VRAM заняты, но один инстанс обслуживает 4 роли
Compute на токен — как у 17B-модели, а не 397B
Качество — frontier-уровня
Именно MoE позволяет запустить 9 агентов frontier-качества на нескольких GPU.
Self-hosted vs. API: честное сравнение
Реальные цены API (март 2026)
Сначала — факты. Open-source модели доступны через API-провайдеров по ценам, которые делают self-hosting экономически невыгодным при малых объёмах:
Модель | Input ($/M) | Output ($/M) | Источник |
|---|---|---|---|
DeepSeek V3.2 | $0.26 | $0.38 | OpenRouter |
Qwen3.5-397B | $0.39 | $2.34 | OpenRouter |
Kimi K2.5 | $0.45 | $2.20 | OpenRouter |
MiniMax M2.5 | $0.27 | $0.95 | OpenRouter |
GLM-4.7 | $0.38 | $1.98 | OpenRouter |
Mistral Small 24B | $0.06 | $0.18 | OpenRouter |
Один агентный запрос (9 агентов, ~100K input + ~30K output суммарно) обходится в $0.03-0.15 через API — не $0.50-2.00, как было бы на проприетарных моделях (Claude Opus / GPT-5). При 10-50 запросах в день — это $0.30-7.50/день. OpenRouter даёт 1000 бесплатных запросов в день при балансе от $10.
Вывод: для MVP и прототипирования API дешевле self-hosting. Покупать GPU ради экономии на API — нерентабельно при малых объёмах.
Когда self-hosting оправдан
Self-hosting начинает иметь смысл при:
1. Latency. Оркестратор на критическом пути каждого запроса. Каждый вызов API — сетевой roundtrip (50-200ms). При 5-10 внутренних вызовах на запрос задержки складываются в 0.5-2 секунды только на сеть. На локальном железе — UNIX socket или shared memory.
2. Приватность данных. Если агенты работают с внутренней документацией, кодом, credentials — отправлять это через сторонний API может быть неприемлемо. Self-hosting = данные не покидают периметр.
3. Независимость от rate limits. API-провайдеры ставят ограничения на запросы в секунду. Агентный пайплайн из 9 агентов генерирует пачки запросов — на бесплатных тирах это проблема. Своё железо = нет лимитов.
4. Объём. При 500+ запросах в день self-hosting на существующем кластере (если GPU уже есть и простаивают) становится дешевле API.
Слон в комнате: скорость инференса
Честно о throughput. Qwen3.5-397B на одной A100 в INT4 выдаёт ~7-15 tok/s. Один агентный запрос через пайплайн из 9 агентов генерирует суммарно ~100-200K токенов. При 10 tok/s это 3-6 часов на один запрос.
Для сравнения: тот же Qwen3.5-397B через API (OpenRouter) отвечает за секунды, потому что провайдер раскидывает модель на десятки GPU с tensor parallelism.
Что это значит на практике:
Конфигурация | Throughput | Один агентный запрос | Реалистичный сценарий |
|---|---|---|---|
1x A100 (Qwen 397B INT4) | ~10 tok/s | 3-6 часов | Ночной batch-процессинг, не интерактив |
4x A100 (tensor parallel) | ~40-60 tok/s | 45-90 мин | Фоновая генерация, допустимо для внутренних задач |
MVP: QwQ-32B на RTX 4090 | ~30-50 tok/s | 30-60 мин | Быстрее, потому что модель в 12x меньше |
API (OpenRouter) | 100+ tok/s | 5-15 мин | Интерактивное использование |
Вывод: self-hosting на MoE-гигантах — это batch-режим, не интерактивный. Для «ввёл запрос — получил агента через 10 минут» нужен либо API, либо 8+ GPU с tensor parallelism, либо компромисс на качестве (QwQ-32B вместо 397B). Статья описывает архитектуру, а не «запустил и всё летает» — и throughput это главная причина, по которой практическая валидация ещё впереди.
Паритет качества
Open-source модели в марте 2026 достигли паритета с проприетарными:
Метрика | Лучший open-source | Лучший проприетарный | Разрыв |
|---|---|---|---|
SWE-bench | MiniMax M2.5 80.2% | Claude Opus 4.5 80.9% | 0.7% |
HumanEval | Kimi K2.5 99.0% | GPT-5.2 98.5% | OS лидирует |
GPQA Diamond | Qwen3.5-397B 88.4% | Gemini-3-Pro 89.1% | 0.7% |
AIME 2025 | Kimi K2.5 96.1% | Claude Opus 4.5 97.0% | 0.9% |
Все модели — MIT или Apache 2.0. Зависимость от проприетарных API больше не оправдана разницей в качестве — но может быть оправдана удобством и стоимостью инфраструктуры при малых объёмах.
Развёртывание: от домашнего GPU до продакшена
Конфигурация A: MVP на одной карточке
5 агентов, 3 модели, 24 GB VRAM. Влезает на RTX 4090 (24 GB) или RTX 5090 (32 GB):
Модель | VRAM (INT4) | Роли |
|---|---|---|
QwQ-32B (32B dense) | 16 GB | Оркестратор, Аналитик, Архитектор (shared) |
Qwen2.5-Coder-7B | 4 GB | Билдер |
Falcon H1R-7B | 4 GB | Тестировщик |
Итого | 24 GB | 5 агентов |
На A100 (80 GB) те же модели оставляют ~56 GB свободных под KV cache — можно обрабатывать длинные контексты без свопа.
Ограничения MVP: QwQ-32B вместо Qwen3.5-397B — заметно слабее reasoning (нет frontier-уровня GPQA/IFEval). Coder-7B вместо Coder-32B — проще код, меньше языков. Это proof-of-concept, не продакшен.
Конфигурация B: Quality Team (2x A100 80GB)
7 агентов, 4 модели, 73 GB VRAM:
┌──────────────────────────┐ ┌──────────────────────────┐ │ GPU 1 (80 GB) │ │ GPU 2 (80 GB) │ │ │ │ │ │ Qwen3.5-397B (~50 GB) │ │ Qwen2.5-Coder-32B │ │ → Оркестратор │ │ (16 GB) │ │ → Аналитик │ │ → Билдер │ │ → Промпт-инженер │ │ → Тестировщик (shared) │ │ → Исследователь │ │ → Безопасник (shared) │ │ │ │ │ │ Ministral 14B (~7 GB) │ │ Свободно: ~64 GB │ │ → Критик │ │ │ └──────────────────────────┘ └──────────────────────────┘
Появляется frontier-качество Оркестратора (Qwen3.5-397B вместо QwQ-32B), отдельный Критик и Промпт-инженер.
Конфигурация C: Full Production (4x A100 80GB)
9 агентов, 6 моделей, все «best picks», 211 GB VRAM:
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ GPU 1 (80GB) │ │ GPU 2 (80GB) │ │ GPU 3 (80GB) │ │ GPU 4 (80GB) │ │ │ │ │ │ │ │ │ │ Qwen3.5-397B │ │ DeepSeek V3.2 │ │ Qwen2.5-Coder │ │ GLM-4.7 │ │ ~50 GB │ │ ~85 GB │ │ -32B ~16 GB │ │ ~44 GB │ │ │ │ │ │ │ │ │ │ Оркестратор │ │ Архитектор │ │ Билдер │ │ Критик │ │ Аналитик │ │ Безопасник │ │ │ │ │ │ Исследователь │ │ │ │ Devstral 24B │ │ Falcon H1R-7B │ │ Промпт-инженер │ │ │ │ ~12 GB │ │ ~4 GB │ │ │ │ │ │ │ │ │ │ │ │ │ │ Тестировщик │ │ Router/Eval │ └──────────────────┘ └──────────────────┘ └──────────────────┘ └──────────────────┘
Каждая роль получает оптимальную модель. Все feedback loops работают с лучшими пиками.
Квантизация: что, чем и зачем
A100 не поддерживает FP8 нативно (в отличие от H100/B200), поэтому INT4 — основной формат.
Целевое железо | Модели | Метод | Ядро | Качество vs FP16 |
|---|---|---|---|---|
A100 / H100 | Оркестратор, Критик (quality-critical) | AWQ INT4 | Marlin | ~95% |
A100 / H100 | Билдер, Тестировщик (throughput-critical) | GPTQ INT4 | Marlin | ~93% |
A100 / H100 | Малые модели (7-14B) | AWQ INT4 | — | ~95% |
RTX 4090/5090 | Все модели через Ollama | GGUF Q4_K_M | llama.cpp | ~92% |
Marlin kernels — ключевая оптимизация для A100: 10.9x ускорение INT4 инференса. Без Marlin INT4 на A100 работает медленнее, чем FP16 — потому что A100 нативно не оптимизирована под INT4.
Правило: Q5_K_M для Оркестратора/Архитектора/Критика (quality-critical), Q4_K_M для Билдера/Тестировщика (throughput-critical).
Инфраструктура инференса
Движок | Для чего | Рекомендация |
|---|---|---|
SGLang | Агентные нагрузки | RadixAttention переиспользует KV cache между multi-turn вызовами агентов. Лучший выбор для agent factory |
vLLM | Общий продакшен | Шире экосистема, стабильнее. Fallback, если SGLang вызывает проблемы |
llama.cpp / Ollama | Consumer GPU | GGUF-квантизация. Лучший вариант для разработки и прототипирования на RTX |
SGLang особенно важен для агентных систем: его RadixAttention хранит KV cache между multi-turn вызовами агентов. Когда Оркестратор многократно обращается к модели в рамках одной задачи, каждый вызов переиспользует кеш предыдущих — экономия compute до 40-60% на повторных обращениях.
Архитектура деплоя: одна модель на GPU (или MIG-партицию). Не пытайтесь запускать несколько моделей на одном GPU одновременно — тулинг для этого ещё незрел. Неактивные модели — на CPU offload.
Tier S: ландшафт open-source моделей (март 2026)
Для контекста — вот полная картина лидеров, из которых я выбирал:
Модель | Total / Active | Архитектура | Главное достижение | Лицензия |
|---|---|---|---|---|
Kimi K2.5 | 1T / 32B | MoE | HumanEval 99.0, AIME 96.1, MATH 98.0 | MIT |
MiniMax M2.5 | 230B / 10B | MoE | SWE-bench 80.2 (лучший open-source) | Open |
GLM-5 | 744B / 40B | MoE | Arena Elo 1451 (топ среди open-source) | MIT |
DeepSeek V3.2 | 685B / 37B | MoE | MMLU-Pro 85.0, LiveCodeBench 83.3, Aider 74.2 | MIT |
Qwen3.5-397B | 397B / 17B | MoE | GPQA 88.4, IFEval 92.6 | Apache 2.0 |
GLM-4.7 | 355B / 32B | MoE | tau-bench 87.4 (лучший tool use) | Open |
DeepSeek-R1 | 671B / 37B | MoE | MATH-500 97.3, AIME 87.5 | MIT |
Qwen3-235B | 235B / 22B | MoE | AIME 81.5, MMLU-Pro 84.4 | Apache 2.0 |
Все Tier S модели — из китайских лабораторий: Alibaba (Qwen), DeepSeek, Zhipu (GLM), Moonshot (Kimi), MiniMax. Все — MIT или Apache 2.0. Это новая реальность open-source AI.
Принципы проектирования агентной фабрики
Шесть правил, выведенных из исследований Anthropic, MetaGPT, metaswarm и собственных экспериментов:
1. Точное делегирование вместо «разбирайся сам». Каждый агент получает: цель, формат вывода, доступные инструменты, границы задачи. Исследование Anthropic показало, что размытое делегирование — главная причина провала multi-agent систем.
2. Spec-driven, не code-driven. ARD и TDD — первичные артефакты. Код — производный. Если спецификация правильная, код генерируется надёжно. Если спецификация плохая, никакой билдер не спасёт.
3. Обязательные feedback loops. Builder ↔ Tester и Builder ↔ Critic — неотключаемые циклы. «Я написал код, тесты пройдены» — это необходимое, но не достаточное условие качества.
4. Минимальный доступ. Сгенерированные агенты получают только необходимые permissions. Security Auditor — не опциональная роль. Агент с доступом к API и credentials — это высокорисковый артефакт.
5. Fail fast. Если агент не может выполнить задачу — он немедленно сообщает об этом Оркестратору. Никакого «сделаю плохо, но сделаю». Низкокачественный артефакт хуже, чем отсутствие артефакта — он портит всё дальше по цепочке.
6. Сохранение артефактов. Все промежуточные артефакты сохраняются. Это не опция — это обязательное условие. Без этого нет debugging, нет rollback, нет обучения из ошибок.
Интерактивный дашборд
Всё это визуализировано в интерактивном дашборде:
RolePanel — 9 ролей, клик для выбора
NeuralTopology — визуальная карта связей между агентами
ModelMatrix — сортируемая таблица 14+ моделей с бенчмарками, подсветкой рекомендаций
ComputePlan — конфигуратор GPU (A100 / H100 / B200): VRAM, bandwidth, стоимость, tokens/sec
Это единственный инструмент, который соединяет все три слоя:
Роль агента → Лучшая open-source модель → Конфигурация GPU
HuggingFace Leaderboard даёт бенчмарки, но не маппинг на роли. CrewAI/LangGraph даёт фреймворки, но не выбор моделей. Этот дашборд отвечает на вопрос, который задаёт каждая команда, строящая агентов: «Какую модель на какую роль? Сколько GPU нужно?»
Слабое место: tool calling
Честно — tool use остаётся самым слабым звеном open-source моделей. Лучший tau-bench: GLM-4.7 с 87.4%. Лучший BFCL v4: Qwen3.5-122B-A10B с 72.2%.
Для продакшена рекомендация: fine-tune на своих tool schemas. Общий function calling — это «знание языка», но ваши конкретные API — это «знание жаргона». Модели быстро учатся на десятках примеров ваших реальных инструментов.
Что из этого следует
Компоненты для сборки multi-agent систем на open-source моделях есть:
Модели — frontier-уровня, MIT-лицензия, все на HuggingFace
Инфра — SGLang/vLLM/Ollama, от consumer GPU до серверных кластеров
Паттерны — orchestrator-worker, artifact-based communication, feedback loops
Экономика — MoE дал frontier-качество при доступных вычислительных затратах
Ключевой вывод из исследования: специализация моделей по ролям даёт лучший результат, чем одна универсальная модель на все задачи — точно так же, как в софтверной команде аналитик, архитектор и тестировщик работают лучше, чем один «фуллстек на все руки».
Что осталось — валидировать это на практике. Следующий шаг — playground на кластере с реальными прогонами и метриками: сколько времени занимает полный цикл, какое качество генерируемого кода, где пайплайн ломается. Когда будут результаты — напишу отдельный пост.
Все модели доступны на HuggingFace. Бенчмарки взяты с SWE-bench Verified, LiveBench, BFCL v4, Aider Leaderboards, LMSYS Arena (февраль–март 2026). Интерактивный дашборд: agent-factory-design.
Исследования: Anthropic Multi-Agent Systems, MetaGPT (ICLR 2024), metaswarm.
