# Мультиагентные системы: принципы

> Оркестратор решает, Shared State вместо свободного общения, heuristic-узлы для жёстких правил, HITL-точки

_Источник: https://sii.sergeivolchkov.ru/materials/architecture/multi-agent_





Продвинутая тема: когда один агент перестаёт справляться, появляется
соблазн «просто добавить агентов». Ниже — принципы, которые отличают
работающую мультиагентную систему от дорогого хаоса; все они проверены
боевыми системами, а не только статьями.

## Сначала: а нужна ли мультиагентность? [#сначала-а-нужна-ли-мультиагентность]

Один агент с хорошими инструментами закрывает большинство задач.
Мультиагентность оправдана, когда есть **разные задачи с разными
ролями** (генерация ≠ оценка ≠ маршрутизация) и **процесс с состоянием**,
который живёт дольше одного вызова. Если этого нет — не усложняй.

## Принцип 1. Качество определяет оркестратор [#принцип-1-качество-определяет-оркестратор]

Качество системы определяется оркестратором, а не качеством отдельных
агентов. Сильные агенты при слабой оркестрации дают слабую систему.
Оркестрационный слой — это граф (LangGraph или аналог) с разделяемым
состоянием: он решает, кто работает следующим и когда остановиться.

## Принцип 2. Shared State вместо свободного общения [#принцип-2-shared-state-вместо-свободного-общения]

<img alt="Мультиагентная система" src="__img0" />

Агенты **не общаются друг с другом напрямую**. Прямой обмен сообщениями
не используется вовсе: каждый компонент читает из Shared State и пишет
в него. Это даёт воспроизводимость (состояние — единственный источник
истины), отлаживаемость (видно, кто что записал) и заменяемость агентов.

## Принцип 3. Task Alignment: строгие роли и права [#принцип-3-task-alignment-строгие-роли-и-права]

Главное — точность соответствия каждого агента своей задаче. Каждый
компонент имеет строгую роль и **явное разграничение прав на чтение
и запись** в состоянии: агент-оценщик не может править данные генератора,
только выставлять оценку в свою секцию. Звучит бюрократично — спасает
от каши, в которой непонятно, кто испортил данные.

## Принцип 4. LLM не держит жёсткие ограничения [#принцип-4-llm-не-держит-жёсткие-ограничения]

Языковая модель склонна не справляться с жёсткими ограничениями:
«максимум 5 итераций» или «бюджет не больше X» нельзя доверять промпту.
Поэтому в графе два типа узлов:

* **LLM-агенты** — там, где нужно суждение: оценка качества, генерация
  инструкции;
* **Heuristic-узлы** — детерминированный код там, где правило жёсткое:
  проверка лимитов, маршрутизация потока, подсчёт итераций.

Правило простое: жёсткое ограничение — это `if`, а не абзац в промпте.

## Принцип 5. HITL-точки: человек в контуре [#принцип-5-hitl-точки-человек-в-контуре]

Решения с необратимыми последствиями проходят через точки подтверждения
человеком (human-in-the-loop): утверждение состава, публикация,
завершение процесса — а спорные оценки эскалируются человеку.
Проектирование HITL-точек — часть архитектуры, а не UI-мелочь:
их положение определяет, насколько системе можно доверять.

## Чек-лист проектирования [#чек-лист-проектирования]

Проектируя свою мультиагентную систему (или читая чужую), проверь её
пятью вопросами: кто оркестрирует и когда останавливает? где живёт
состояние и кто в него пишет? какие ограничения жёсткие — и вынесены ли
они из промптов в код? где человек подтверждает необратимое? виден ли
след каждого решения в трейсах?