Військова доктрина: Надійні багатоагентні системи кодування

Замість традиційного підходу до оркестрації агентів, що часто призводить до непередбачуваних результатів, було запропоновано використовувати принципи, запозичені з військових польових посібників. Ці посібники, хоч і здаються нудними, містять уроки, виплачені досвідом, і пропонують структурований підхід до складних операцій.

Переосмислення ролей агентів

Традиційні багатоагентні системи часто використовують ролі на кшталт «планувальник», «кодувальник» та «рецензент». Однак, застосовуючи військову доктрину, автор переосмислив ці ролі, надавши їм чіткіші функції та ієрархію:

Користувач (CDR — Commander): Єдиний, хто приймає рішення та затверджує. Визначає намір.
Оркестратор (XO): Керує ритмом, синхронізує, але не приймає рішень.
Планувальник (S-5): Аналізує місію, розробляє варіанти та оперативні накази (специфікації та плани).
Дослідник (S-2): Проводить розвідку кодової бази, перевіряє припущення фактами.
Кодувальник (Maneuver): Єдиний, хто пише код.
OPFOR (Opposition Force): Атакує план до його виконання, виявляючи слабкі місця та припущення. Це найважливіша відсутня ланка в більшості систем.
Рецензент (Red Cell): Атакує реалізацію вже після її створення.
Зберігач стану (Battle Captain): Підтримує спільну оперативну картину, відстежує стан.

Важливість OPFOR та розділення ролей

Одним з ключових висновків є необхідність розділення функцій OPFOR та Red Cell. OPFOR «воює» з планом, виявляючи ризики та вимагаючи їх усунення або реєстрації, тоді як Red Cell перевіряє готовий код. Об'єднання цих ролей в одного «рецензента» призводить до виконання структурно несправних планів.

План Б як структура даних

Замість розпливчастого поняття «План Б», його було перетворено на чітку структуру даних з такими елементами:

Статус: DORMANT (сплячий), ARMED (активований), EXECUTED (виконаний) або RETIRED (відхилений).
Тригер: Чітка умова, яка активує План Б.
Точка прийняття рішення (DP): Останній момент, коли можна перейти на План Б.

Це дозволяє системі автоматично відстежувати та повідомляти про активацію резервних планів, а не виявляти їх необхідність постфактум.

Протокол для виправлень (FRAGO)

Для внесення змін до поточного плану використовується концепція FRAGO (фрагментарного наказу). Це дозволяє вносити точкові зміни, гарантуючи, що решта плану залишається незмінною. Кожне виправлення отримує номер, запис у графі рішень та класифікацію за обсягом (тактичне або структурне), що забезпечує відстежуваність та запобігає «мовчазним мутаціям намірів».

Переформулювання місії (WARNO)

Перед початком планування обов'язковим є етап WARNO (попереджувальний наказ), де сирий опис завдання переформульовується у чіткий параграф місії, намір, ключові завдання, кінцевий стан, обмеження та припущення. Це дозволяє виявити потенційні проблеми та нерозуміння ще до того, як будуть витрачені ресурси на планування.

Роль ментора

Система включає роль MENTOR — сильнішої моделі, яка може надавати поради в критичні моменти (наприклад, перед фіналізацією плану, після кількох невдач або перед затвердженням високого ризику). Ментор інформує, але не командує, зберігаючи ланцюг командування.

Надійні захисні механізми

Для забезпечення безпеки та дотримання ролей (наприклад, заборона на запис для read-only агентів) використовуються надійні «guard hooks», написані на Node.js, що забезпечують ідентичну поведінку на різних платформах і можуть бути протестовані юніт-тестами.

Самооновлення системи

Кульмінацією стало завдання для старої системи: побудувати власного наступника, використовуючи нову доктрину. Це дозволило перевірити ефективність нових принципів на практиці, оскільки стара система, яка не мала механізмів MDMP, виконувала наказ, що призведе до її заміни системою, яка їх має. Це стало найчеснішим інтеграційним тестом архітектури.

П'ять ключових висновків

Розділіть червону команду: OPFOR перевіряє план до затвердження, RED CELL — реалізацію після. Рецензент, який бачить лише готовий код, — це звіт про інцидент, а не запобіжник.
Зробіть План Б структурою даних: З чітким тригером та точкою неповернення. Невизначеність — це не план, а надія.
Впровадьте протокол для виправлень: З номером, записом у графі рішень та класифікацією. Ніколи не застосовуйте мовчазно виправлення, що скасовує вже прийняте рішення.
Переформулюйте місію перед плануванням (WARNO): Двадцять секунд WARNO — найдешевша страховка в агентній інженерії.
Запускайте самооновлення без сорому: Ваша поточна система достатньо хороша, щоб побудувати власну заміну, і цей запуск є найчеснішим інтеграційним тестом для архітектури.

Що це означає для розробників

Розробники багатоагентних систем можуть значно підвищити надійність та керованість своїх рішень, впровадивши структуровані ролі, протоколи для планування та виправлень, а також механізми попередньої перевірки планів. Це дозволить уникнути типових проблем «оркестрації за відчуттями» та забезпечити чітке розуміння стану системи.

Ключові факти

Автор переосмислив архітектуру своїх агентів кодування, застосувавши принципи Військового процесу прийняття рішень (MDMP).
Були переосмислені ролі агентів: Командир, XO, Планувальник (S-5), Дослідник (S-2), Кодувальник (Maneuver), OPFOR, Рецензент (Red Cell), Зберігач стану (Battle Captain).
Введено роль OPFOR (Opposition Force), яка атакує план до його виконання, що є критично важливим і часто відсутнім елементом.
План Б перетворено на структуру даних з чітким тригером та точкою прийняття рішення.
Для виправлень використовується протокол FRAGO (фрагментарний наказ), що забезпечує відстежуваність змін.