Выжимка из книги Ли Боцзе «Глубокое понимание AI Agent: принципы проектирования и инженерная практика» (Pine AI, v2.0, 2026).

10. Мультиагентное взаимодействие

Общий контекст (без потерь, но растёт) vs раздельный (параллелизм, нужна синхронизация: параметры вызова / общая ФС / шина сообщений — аналоги IPC).

Критерий: вносит ли взаимодействие НОВУЮ информацию, недоступную одному агенту (тесты/рендер — да; «агенты обсуждают текст» — нет). Бюджет шагов не гарантирует улучшения без «осознания бюджета». Мультиагентность стоит на порядок дороже — считай реалистично.

Виртуальная ФС — 4 зоны: приватный scratchpad / общее пространство (блокировка) / внешние ресурсы / встроенные read-only. Передавай путь к файлу, не содержимое.

Плоскость управления: create/cancel/list (fork/kill/ps); статус — через сообщения/файл прогресса, НЕ опрос; мягкое прерывание лучше принудительного; идемпотентная фиксация при гонке успехов; каскадная отмена по дереву.

Равноправное: разнообразие ПРОЕКТИРУЙ — однородные агенты дают одинаковую ошибку. «Готово» — заявление, не доказательство без верификатора. Reviewer читает независимые свидетельства, не меняет тесты. Самопроверка без внешней обратной связи не улучшает результат. Дебаты при равном бюджете часто не превосходят одного агента.

Оркестрация: >5 подзадач — сильнейшую модель планировщику, контекст менеджера компактный, фиксация по первому проверенному успеху. Децентрализация — для устойчивости к единой точке отказа. A2A — для межорганизационного (карточка возможностей + жизненный цикл + непрозрачность).

Отказы: агент византийский (лжёт правдоподобно) — нужна независимая проверка по конструкции, не точечные фиксы. Конфликт файла простой (блокировка версий) vs семантический (изолируй копии). Ошибка усиливается при передаче — кросс-проверка рвёт цепь. Однородные агенты совпадают в ошибке — разные модели.

Примеры задач для мультиагентных систем

Критерий применимости: мультиагентность оправдана, если взаимодействие вносит новую информацию, недоступную одному агенту за один проход (результат теста, рендер, внешний факт) — а не когда несколько агентов просто обсуждают один и тот же текст.

1. Ревью кода с исполнением тестов (Proposer-Reviewer). Ревьюер видит результат прогона тестов/линтера, а не рассуждения автора. 2. Генерация презентации/видео с визуальной проверкой. Reviewer смотрит скриншот рендера (смена модальности), автор своей ошибки в коде рендера не видит. 3. Поиск уязвимостей в открытом пространстве (равноправное/децентрализованное). Разный фокус агентов расширяет покрытие, а не повторяет одно и то же. 4. Проект с >5 разнородных подзадач (оркестрация). Бэкенд/фронтенд/миграции — специализированное знание у каждого агента. 5. Техподдержка с двусторонним управлением состоянием. Проверяет, перечитывает ли агент состояние после изменений другой стороной. 6. Обновление базы знаний через PR-модель. Независимый Reviewer сверяет правку с первоисточником, а не доверяет автору. 7. A2A между организациями (напр. турагентство—авиакомпания). Разные зоны доверия требуют протокола, не общего контекста. 8. Делегирование широкого поиска суб-агенту с изолированным контекстом. В основной контекст возвращается резюме, а не весь шум. 9. Параллельная генерация кандидатов с settle-once. Финализируется первый, прошедший скрытую проверку, не первый заявивший «готово». 10. Робототехнический контур с разделением масштабов времени. Планировщик (минуты) / навык (секунды) / safety-слой (50-1000Гц) физически не могут жить в одном контексте.

Антипаттерн: агенты по очереди редактируют один текст или дебатируют на одних и тех же вводных без доступа к новым фактам — самопроверка без внешней обратной связи не улучшает результат, а дебаты при равном бюджете токенов часто не превосходят одного агента.

Сквозное резюме всей книги: модель постепенно поглощает функции Harness (медленнее интуиции — обучение месяцы, бизнес ждать не может). Harness-инженерия — практическое воплощение «горького урока» в масштабе инженерного времени: то, что модель делает нестабильно, временно компенсирует Harness.