Дослідження Anthropic: патерни збоїв та координація в мультиагентних системах
Anthropic опублікувала дослідження ефективності агентних груп у пошуку вразливостей та розробці коду. Якщо скоординований пошук багів показав високі результати, то взаємозалежний кодинг виявив системні проблеми зі злиттям PR.
Вплив: Середній
Чому це важливо
Розуміння обмежень мультиагентних систем допомагає уникати надмірно складних автономних пайплайнів там, де прості паралельні запити або контроль людини працюють надійніше.
TL;DR
- 01Координація агентів у рої збільшує ефективність аудиту коду більш ніж у 12 разів завдяки автономній спеціалізації.
- 02Автономна спільна розробка без контролю веде до конфліктів у Git; необхідна детермінована оркестрація або людина в ланцюжку.
- 03Покоління моделі критичне: Sonnet 5 значно краще справляється зі злиттям PR у порівнянні з попередніми версіями.
Ключові факти
- Знайдено роєм
- 266 вразливостей / 27M токенів
- Знайдено ізольовано
- 21 вразливість / 6.5M токенів
- Спільні знахідки
- 12 вразливостей
- Тривалість симуляції
- 12 годин (тест розробки гри)
Пошук вразливостей: координація проти паралелізму
У тестуванні на 15 open-source проєктах:
- Ізольовані агенти: Виявили 21 вразливість, витративши 6.5 млн токенів у заздалегідь визначених директоріях.
- Рій із 45 агентів: Виявив 266 вразливостей при витраті 27 млн токенів. Агенти використовували форум, проводили peer review та надсилали результати агенту-арбітру.
- Лише 12 вразливостей збіглися в обох підходах, що свідчить про високу ефективність автономного пошуку.
Проблеми інтеграції коду
Під час спільного написання складної кодової бази виникли архітектурні глухі кути:
- Колізії в Git: 18 із 30 агентів створили гілки з однаковою назвою
mvp-game-loop. - Неефективність ієрархій: Введення ролей або «агента-CEO» суттєво не покращило кінцеву якість продукту.
- Динаміка злиття PR: Моделі
Opus 4.6таSonnet 4.6майже не справлялися зі злиттям коду, тоді як Sonnet 5 показала високий рівень інтеграції змін.
Висновок для розробників
Мультиагентні структури відмінно підходять для пошукових завдань з агентом-валідатором, але погано замінюють структурований процес злиття гілок у великих спільних репозиторіях.
✓ Коли використовувати
- Використовуйте агентні групи для аудиту безпеки, фаззингу та паралельного дослідження кодових баз.
- Застосовуйте модель-арбітра для верифікації та дедуплікації результатів роботи воркерів.
✕ Коли НЕ варто
- Не використовуйте неконтрольовані групи агентів для автоматичного злиття коду в продакшн.
- Не покладайтеся лише на системні промпти розподілу ролей для вирішення конфліктів у коді.
Що зробити сьогодні
- Проєктуйте пайплайни тестування як групи агентів із виділеним агентом-арбітром для валідації.
- Уникайте систем, де кілька агентів одночасно вносять автономні зміни у спільні гілки репозиторію.
- Використовуйте моделі останнього покоління (класу Sonnet 5) для складних сценаріїв координації.
Що каже спільнота
“18 out of 30 agents decided to create a git branch with the exact same branch name, 'mvp-game-loop.' This seems trivially explainable by Github being full of 'my first game loop' type projects.”
“Agents cross comparing notes often surfaces some good improvements, finds interesting drifts. Ask them to reinterpret the prompt as they see it, have them describe the problem, then their findings.”
Джерела