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

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

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

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

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

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

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

Принцип 2. Shared State вместо свободного общения

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

Принцип 3. Task Alignment: строгие роли и права

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

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

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

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

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

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

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

Чек-лист проектирования

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