Аналіз Project89: модульний, високопродуктивний каркас нового покоління AI Agent

Project89 впроваджує абсолютно новий підхід до проектування Agent Framework, який є високопродуктивним Agent Framework для розробки ігор, більш модульним і з кращою продуктивністю порівняно з нинішніми Agent Framework.

Ця стаття детально розгляне оновлення цієї архітектури у порівнянні з традиційною архітектурою агентів.

Фон розробника

Засновник Project89 раніше брав участь у розробці проєкту Magick, це програмне забезпечення для програмування за допомогою ШІ. Він займав четверте місце серед розробників у цьому проєкті.

Чому слід використовувати ECS для розробки Agent Framework

З точки зору застосування в ігровій сфері, наразі ігри, що використовують архітектуру ECS, включають:

• Блокчейн-ігри: Mud, Dojo
• Традиційні ігри: Overwatch, Star Citizen тощо
• Провідні ігрові рушії також розвиваються у напрямку ECS, такі як Unity

Вступ до ECS

ECS(Entity-Component-System) є звичайним архітектурним шаблоном у розробці ігор та моделюванні систем, який повністю відокремлює дані від логіки, щоб ефективно управляти різними сутностями та їх поведінкою в масштабованих сценах:

1. Entity( сутність ): це лише ідентифікатор і не містить жодних даних чи логіки.

2. Компонент( компонент): використовується для зберігання конкретних даних або стану сутності.

3. Система（系统): відповідає за виконання логіки, пов'язаної з певними компонентами.

Як приклад дії конкретного агенту: у ArgOS кожен агент розглядається як сутність, він може реєструвати різні компоненти, такі як:

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

Процес роботи системи:

1. Відчуття зброї, система сприйняття оновлює компонент сприйняття агента.

2. Система пам'яті викликає компонент сприйняття та компонент пам'яті, що зберігає дані сприйняття у базі даних.

3. Action System викликає Memory Component та Action Component, отримуючи інформацію про середовище з пам'яті, виконує відповідні дії.

4. Отримати агент-об'єкт, в якому дані кожного компонента були оновлені

Процес роботи системи

Фактичний процес виконання системи не є послідовним викликом, як ми уявляли, а між системами немає викликів, кожна система виконується один раз у встановлений період, наприклад:

• Система сприйняття виконується кожні 2 секунди, оновлюючи зовнішнє сприйняття до компонента сприйняття.
• Система пам'яті виконується кожну 1 с, витягаючи дані з Компонента сприйняття до Компонента пам'яті
• Plan System виконується кожні 1000 секунд, складає план і оновлює компонент плану.
• Система дій виконується кожні 2 секунди, реагуючи на зовнішню інформацію, а також оновлюючи дії на основі компонентів плану.

Архітектура системи ArgOS

ArgOS розробив кілька компонентів і систем, щоб агент міг здійснювати більш глибокі роздуми та виконувати складні завдання.

ArgOS розділяє систему на три рівні (РівеньСвідомості):

1. Свідомий(CONSCIOUS)система

   • Включає RoomSystem, PerceptionSystem і т.д
   • Частота оновлення досить висока (, наприклад, кожні 10 секунд )
   • Більш близько до "реального часу" або "свідомого" рівня обробки

2. Підсвідомість(SUBCONSCIOUS)система

   • Включає в себе GoalPlanningSystem і PlanningSystem
   • Частота оновлення низька (, наприклад, кожні 25 секунд )
   • Обробка логіки "мислення"

3. Без свідомості(UNCONSCIOUS)система

   • Наразі не активовано
   • Частота оновлення повільніша(50 секунд і більше)

Системи в ArgOS мають складні взаємовідносини, а багаторівневе проєктування допомагає визначити частоту виконання різних систем.

Огляд функцій системи

1. PerceptionSystem: збирає зовнішні "стимули", оновлює компонент Perception агента

2. ExperienceSystem: Перетворити Stimuli на "досвід", зберегти в компоненті Memory

3. ThinkingSystem: Агент "мислення" система, генерує ThoughtResult

4. ActionSystem: Виконання pendingAction агента

5. GoalPlanningSystem: оцінка прогресу цілей, генерація нових цілей

6. PlanningSystem: Генерація або оновлення виконавчого плану для цілей

7. RoomSystem: обробка оновлень, пов'язаних із кімнатами, таких як список мешканців

8. CleanupSystem: видалити більше не потрібні сутності

Аналіз загальної архітектури ArgOS

Ярусна архітектура ядра

включаючи компоненти, системи, менеджери та інші рівні

Класифікація компонентів (Component)

1. Основні ідентичності: Agent, PlayerProfile тощо
2. Класи дій та станів: Action, Goal, Plan тощо
3. Спостереження та пам'ять: Perception, Memory тощо
4. Середовище та просторові категорії: Room, OccupiesRoom тощо
5. Зовнішній вигляд та взаємодія: Appearance, UIState тощо
6. Допоміжні або експлуатаційні: Cleanup, DebugInfo тощо

Архітектура Менеджера

Окрім Component і System, також потрібен менеджер ресурсів Manager:

• RoomManager: управління інформацією про кімнати
• StateManager: отримати збережений стан світу/агента
• EventBus: прослуховування подій
• PromptManager: надає шаблони запитів LLM
• ActionManager: управління реєстрацією та виконанням дій
• SimulationRuntime: планування систем, створення менеджерів

взаємодія з базою даних

Взаємодія з базою даних через StateManager/PersistenceManager:

1. Завантаження основних даних під час запуску
2. Оновлення даних компонентів Systems під час виконання
3. Регулярна або подієва персистенція
4. Зберегти всі дані перед виходом

Інновації в архітектурі

• Кожна система працює незалежно, без викликів один до одного
• Модульний дизайн, легко додавати та видаляти функції
• Продуктивність архітектури ECS перевищує традиційну об'єктно-орієнтовану
• Розділіть систему на різні рівні свідомості, розробіть витончено.
• Надзвичайно модульний, відмінна продуктивність, висока якість коду

Це модульна, високо продуктивна структура, що надає нові архітектурні можливості для команд ігор та DeepAI.