Що стається, коли ви плануєте великий проєкт без жодного керівника? Більшість програмних стеків передбачають наявність одного оркестратора. Один процес утримує стан, ставить завдання в чергу та розподіляє їх. Якщо цей координатор перезавантажується, увесь робочий процес спотикається. Новий проєкт повністю змінює це припущення. Він демонструє, як рій AI-агентів може розбити таку ціль, як «спланувати двотижневу подорож до Японії», на повноцінне дерево завдань так, що жоден окремий вузол не володіє повним планом у будь-який момент часу.
Чому варто будувати безлідерну систему?
Централізовані планувальники прості для розуміння. Ви надсилаєте запит на сервер, він розподіляє роботу, а виконавці звітують про результат. Проблема в тому, що сервер стає когнітивним та фізичним вузьким місцем. Він володіє істиною.
У розподіленій структурі істина перетворюється на спільну картину, до якої мережа приходить через gossip-протокол. Ця конкретна реалізація на Python поєднує дві різні концепції. Перша — це цикл ітеративного вдосконалення: один агент пише пропозицію, інший її оцінює, а третій шліфує. Друга — це рівень peer-to-peer мережі, побудований на libp2p, який дозволяє агентам автоматично знаходити один одного без реєстратора чи балансувальника навантаження. Результатом є кластер, де піри з'являються, пропонують, голосують і виконують завдання без жодного диригента оркестру.
Чотири ролі
Система призначає кожному учаснику одну з чотирьох ролей. Вам не потрібно чотири фізичні машини. Вони можуть співіснувати на одному ноутбуці або бути розподілені по домашній мережі. Ролі такі:
Декомпозитор (Decomposer). Цей агент отримує ціль верхнього рівня та пропонує її розбиття на підцілі. Оскільки система запускає кілька декомпозиторів паралельно, ви можете отримати три різні варіанти для тієї самої подорожі до Японії. Один може розбити подорож за географією: Токіо, Кіото, Осака. Інший може розділити за видами діяльності: транспорт, проживання, харчування, огляд визначних пам'яток. Третій може вибудувати послідовність за днями. Мережа розглядає всі ці варіанти.
Оцінювач (Scorer). Ці агенти діють як редакційна колегія. Вони перевіряють запропонований розподіл і виставляють йому оцінку. Оцінка відображає, чи є підцілі достатньо конкретними, чи не перекриваються вони та чи є вони вичерпними в сукупності. Що ще важливіше, оцінювач вирішує, чи є пропозиція достатньо хорошою для прийняття. Без його схвалення розподіл залишається в стані невизначеності.
Виконавець (Executor). Щойно дерево досягає листових вузлів, достатньо малих для виконання, виконавці змагаються за право їх отримати. Вони не чекають дозволу з центральної черги. Замість цього вони використовують протокол часових міток, щоб визначити, хто першим забере завдання. Переможець запускає завдання через локальний виклик LLM і транслює результат.
Спостерігач (Observer). Це той «тихий спостерігач», який потрібен будь-якій мережі. Він мовчки слухає gossip, реконструює дерево плану з потоку повідомлень і виводить зрозумілий знімок стану. Оскільки він ніколи не говорить, він доводить важливу річ: будь-хто, хто приєднається пізніше, може зрозуміти весь план, просто підслухавши розмову.
Gossip як джерело істини
Рівень libp2p відповідає за виявлення вузлів та обмін повідомленнями. Агенти знаходять один одного через вбудоване в протокол виявлення пірів, а потім транслюють повідомлення на спільну тему. Тут немає основної бази даних або кешу Redis, що зберігає канонічний план.
Кожен пір зберігає власну копію дерева плану та оновлює її на основі почутого gossip. Коли декомпозитор транслює пропозицію, кожен інший вузол отримує її, перевіряє формат і додає гілку до свого локального дерева. Коли оцінювачі голосують, підрахунок поширюється таким самим чином. Якщо два виконавці публікують суперечливі претензії на одне й те саме завдання, протокол часових міток вирішує конфлікт. Мережа приймає ранішу претензію та відкидає пізнішу.
З часом дерево росте вниз від початкової цілі через шари прийнятих підцілей, поки не досягне дрібних завдань. Цей процес нагадує досягнення консенсусу в блокчейні, з тією різницею, що корисне навантаження — це маршрут подорожі або специфікація ПЗ, а не реєстр монет.
Голосування та гонка за виконання
Демократія — річ дорога, і ця система платить за неї затримкою (latency). Розподіл перемагає лише тоді, коли достатня кількість оцінювачів погоджується з ним. Цей поріг може бути простою більшістю або суворішим кворумом, залежно від того, як ви налаштуєте кластер. Декомпозитори не припиняють пропонувати, тому мережа часто оцінює кілька конкуруючих дерев одночасно. Зрештою одне з них набирає необхідну кількість голосів, і його підцілі переходять зі статусу чернетки до статусу прийнятих.
Виконавці додають ще один рівень координації. Оскільки завдання є публічними в gossip-каналі, кілька виконавців можуть намагатися захопити один і той самий привабливий листовий вузол. Протокол часових міток виступає як механізм вирішення конфліктів. Кожна заявка містить монотонну часову мітку, і мережа надає пріоритет найпершій. Той, хто програв, просто переходить до наступного доступного завдання. Це грубий підхід, але він дозволяє уникнути необхідності використання централізованого планувальника, який блокував би рядки в базі даних.
Стійкість, закладена в архітектуру
Архітектура повністю виправдовує себе, коли щось ламається. Якщо декомпозитор виходить із ладу після пропозиції половини підцілей, декомпозитори, що залишилися, продовжують пропонувати розподіли. План не зупиняється в очікуванні перезапуску. Якщо скорер зникає з мережі, решта голосуючих все одно можуть досягти кворуму, якщо ви правильно масштабували кластер.
Справжня перевага полягає у пізніх підключеннях. Новому агенту, який запускається на середині процесу, не потрібен знімок стану або