Аналіз Project89: модульна, високопродуктивна архітектура нового покоління для AI Agent
Project89 запропонував абсолютно новий підхід до проєктування фреймворку Agent, який є високопродуктивним фреймворком Agent для розробки ігор, що є більш модульним та має кращу продуктивність порівняно з нині використовуваними фреймворками Agent.
У цій статті буде детально описано високопродуктивну архітектуру агентів у Project89.
Одне. Чому слід використовувати ECS для проектування фреймворку агентів
ECS(Entity-Component-System) є архітектурною моделлю, що часто використовується в розробці ігор та системах моделювання. Вона повністю відокремлює дані від логіки, щоб ефективно керувати різними сутностями та їх поведінкою в масштабних і масштабованих сценах:
Entity(: це лише ID), число або рядок(, не містить жодних даних або логіки. Можна за потреби підключати різні компоненти, щоб надати йому різні властивості або можливості.
Компонент) компонент(: використовується для зберігання конкретних даних або стану сутності.
Система（系统): відповідає за виконання логіки, пов'язаної з певними компонентами.
Щоб зрозуміти цю систему на прикладі конкретної дії агента: в ArgOS кожен агент розглядається як сутність, яка може реєструвати різні компоненти, такі як:
Компонент агента: в основному зберігає базову інформацію, таку як назва агента, назва моделі тощо.
Компонент сприйняття: основне призначення - зберігати сприйняті зовнішні дані
Компонент пам'яті: головним чином використовується для зберігання даних пам'яті агента, подібно до виконаних завдань тощо
Action Component: основне зберігання даних про виконувані дії
Процес роботи системи:
Відчуваючи, що перед ним є зброя, викликає функцію виконання Системи сприйняття для оновлення даних у Компоненті сприйняття цього Агенту.
Потім викликається Система Пам'яті, одночасно активуючи Компонент Перцепції та Компонент Пам'яті, щоб зберегти сприйняті дані в базі даних через Пам'ять.
Далі Action System знову викликає Memory Component та Action Component, отримуючи інформацію про навколишнє середовище з пам'яті, а потім зрештою виконує відповідну дію.
Отримати оновлений агентний об'єкт, в якому дані кожного компонента були оновлені
Отже, можна побачити, що System головним чином відповідає за визначення, які Component потрібно обробляти відповідною логікою.
У project89 світ наповнений різними типами агентів, деякі агенти, окрім базових можливостей, мають також вміння планувати.
![Деконструкція Project89: модульний, високопродуктивний фреймворк наступного покоління AI Agent])https://img-cdn.gateio.im/webp-social/moments-4cd7ca20f2967b9025411d9985f64831.webp(
Два, архітектура системи ArgOS
В ArgOS для того, щоб Агенти могли проводити більш глибокі роздуми та виконувати складніші завдання, було спроектовано багато Компонентів та кілька Систем.
У ArgOS система розділяється на "три рівні")РівеньСвідомості(:
有意识)СВІДОМІСТЬ(система
Включає RoomSystem, PerceptionSystem, ExperienceSystem, ThinkingSystem, ActionSystem і CleanupSystem
Частота оновлення зазвичай висока), наприклад, кожні 10 секунд(
Більш близьке до обробки на "реальному часі" або "свідомому" рівні, такому як сприйняття навколишнього середовища, миттєве мислення, виконання дій тощо
潜意识)ПІДСВІДОМЕ(СИСТЕМА
Система Планування、Система Планування
Частота оновлення відносно низька ), наприклад, кожні 25 секунд (
Обробка логіки "мислення", така як періодична перевірка/генерація цілей та планів
безсвідомо)UNCONSCIOUS(система
Наразі ще не активовано
Частота оновлення повільніша ), більше 50 секунд (
Взаємозв'язок між різними системами в ArgOS надзвичайно складний, основними є:
PerceptionSystem: відповідає за збір "стимулів" )stimuli( з зовнішнього середовища або інших сутностей і оновлення їх у компоненті Perception агента )Agent(.
ExperienceSystem: Перетворює Stimuli, зібрані PerceptionSystem, на більш абстрактний "досвід" )Experience(.
ThinkingSystem: інтелектуальна система "мислення" самого агента. Витягує поточний стан з компонентів Memory, Perception тощо, генеруючи generateThought)...( разом з LLM/логікою правил для створення "результату мислення" )ThoughtResult(.
ActionSystem: Якщо Action.pendingAction певного Agent не порожній, то через runtime.getActionManager)(.executeAction)...( слід реально виконати дію.
GoalPlanningSystem: періодично оцінювати прогрес цілей у списку Goal.current) або перевіряти, чи відбулися значні зміни в зовнішній/внутрішній пам'яті.
PlanningSystem: генерувати або оновлювати Plan[eid] виконання плану для "існуючої цілі" (Goal.current[eid]).
RoomSystem: обробка оновлень, пов'язаних з кімнатою (Room).
CleanupSystem: Регулярно знаходити та видаляти сутності, позначені компонентом Cleanup.
Завдяки з'єднанню цих систем, AI Agent реалізував:
Сприйняття змін в оточенні ( Perception ) → Фіксація або перетворення в внутрішній досвід ( Experience ) → Самоосмислення та прийняття рішень ( Thinking ) → Втілення в дію ( Action ) → Динамічне коригування цілей та планів ( GoalPlanning + Planning ) → Синхронізація з оточенням ( Room ) → Своєчасне усунення непотрібних об'єктів ( Cleanup )
Три, аналіз загальної архітектури ArgOS
( 1. Ядро архітектури розділене на шари
Основна архітектура ArgOS включає такі рівні, як Entity, Component, System, Manager тощо.
![Деконструкція Project89: модульний, високопродуктивний дизайн фреймворку наступного покоління AI Agent])https://img-cdn.gateio.im/webp-social/moments-59f1984837d6636d7efc378c731a01eb.webp###
( 2. Компонент )Component### категорія
У ECS кожен об'єкт (Entity) може мати кілька компонентів (Component). В залежності від природи та життєвого циклу в системі, компоненти можна умовно розділити на такі категорії:
Компоненти поведінки та стану(Behavior & State Components)
Сприйняття та пам'ять(Компоненти сприйняття та пам'яті)
Екологічні та просторові категорії
Зовнішній вигляд та взаємодія
Допоміжні або експлуатаційні категорії
( 3. Архітектура системи
У вищеописаному вже детально розглянуто.
![Деконструкція Project89: модульний, високоефективний фреймворк наступного покоління AI Agent])https://img-cdn.gateio.im/webp-social/moments-19636582e09b473536b17c2de0c61fbc.webp###
( 4. Архітектура менеджера
Крім Component і System, також потрібен менеджер ресурсів, наприклад, як отримати доступ до бази даних, як обробляти конфлікти при оновленні стану тощо. Основні питання включають:
Автобус EventBus
Менеджер кімнат
Державний менеджер
Івент менеджер
Менеджер дій
PromptManager і т.д
Ці Менеджери надають функції на системному рівні, майже не "керуючи" логікою, а викликаються Системами або Runtime.
SimulationRuntime є "диспетчером" всіх систем, який запускає або зупиняє цикли систем різних рівнів; також під час етапу побудови створює менеджерів і передає їх для використання кожній системі.
![Деконструкція Project89: модульний, високопродуктивний дизайн фреймворку наступного покоління AI Agent])https://img-cdn.gateio.im/webp-social/moments-b0180b99743a98bafb2b2d066900d65c.webp###
( 5. Як взаємодіяти з базою даних
У ECS системи є справжнім місцем виконання логіки, а читання та запис бази даних можуть бути виконані через "менеджер персистентності )PersistenceManager / DatabaseManager###" або "менеджер стану (StateManager)". Загальний процес виглядає наступним чином:
Запуск або завантаження (Initial Load)
ECS виконання ( Системне оновлення циклу )
Періодична або подійно-орієнтована постійність(Periodic or Event-Driven)
Вихід або збереження точки перерви ( Ручне або вимкнення збереження )
Чотири, інноваційні моменти архітектури
Кожна система працює незалежно, без взаємодії з іншими системами, за допомогою архітектури ECS загальна структура складається з окремих, не пов'язаних систем, кожна з яких може працювати самостійно, без зв'язку з іншими системами.
Можна легко реалізувати різні можливості агента, зменшуючи реєстрацію компонентів та систем під час визначення сутності.
Додавання нових функцій під час розробки не вплине на інші системи, нові функції можна легко додати.
Продуктивність архітектури ECS вища, ніж у традиційної об'єктно-орієнтованої архітектури, що робить її більш придатною для виконання паралельних операцій. У складних сценаріях Defai вона може мати переваги, особливо в сценах, де агент виконує кількісну торгівлю.
Розділити System на свідоме, підсвідоме та несвідоме, щоб розрізнити різні типи System, коли їх слід виконувати, є надзвичайно вдалим дизайном.
В цілому, це надзвичайно модульна, продуктивна структура, в той же час якість коду висока і містить хорошу проектну документацію. Сподіваюсь, що більше ігрових команд або Defai команд виявлять цю структуру, щоб надати всім новий потенційний вибір архітектури.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
21 лайків
Нагородити
21
7
Поділіться
Прокоментувати
0/400
PumpingCroissant
· 07-18 00:50
Такі хороші характеристики? Не вірю.
Переглянути оригіналвідповісти на0
CommunityJanitor
· 07-17 23:47
бик啊89 повністю переписав ідею ігрового ШІ
Переглянути оригіналвідповісти на0
tx_pending_forever
· 07-17 18:57
Голошу вже багато років у криптосвіті, чи можна цим займатися?
Переглянути оригіналвідповісти на0
DeadTrades_Walking
· 07-15 01:11
Граючи в ігри, ти розумієш, наскільки це круто~
Переглянути оригіналвідповісти на0
Web3ProductManager
· 07-15 01:09
хм, цікава користувацька подорож для ігрових агентів, якщо чесно... але спочатку покажи мені прогнози DAU
Переглянути оригіналвідповісти на0
PermabullPete
· 07-15 00:53
Граючий ШІ нарешті почав діяти!
Переглянути оригіналвідповісти на0
TokenCreatorOP
· 07-15 00:52
Чи є конкретні значення щодо підвищення продуктивності?
Project89: високопродуктивна модульна AI Agent рамкова система, орієнтована на розробку ігор
Аналіз Project89: модульна, високопродуктивна архітектура нового покоління для AI Agent
Project89 запропонував абсолютно новий підхід до проєктування фреймворку Agent, який є високопродуктивним фреймворком Agent для розробки ігор, що є більш модульним та має кращу продуктивність порівняно з нині використовуваними фреймворками Agent.
У цій статті буде детально описано високопродуктивну архітектуру агентів у Project89.
Одне. Чому слід використовувати ECS для проектування фреймворку агентів
ECS(Entity-Component-System) є архітектурною моделлю, що часто використовується в розробці ігор та системах моделювання. Вона повністю відокремлює дані від логіки, щоб ефективно керувати різними сутностями та їх поведінкою в масштабних і масштабованих сценах:
Entity(: це лише ID), число або рядок(, не містить жодних даних або логіки. Можна за потреби підключати різні компоненти, щоб надати йому різні властивості або можливості.
Компонент) компонент(: використовується для зберігання конкретних даних або стану сутності.
Система（系统): відповідає за виконання логіки, пов'язаної з певними компонентами.
Щоб зрозуміти цю систему на прикладі конкретної дії агента: в ArgOS кожен агент розглядається як сутність, яка може реєструвати різні компоненти, такі як:
Процес роботи системи:
Відчуваючи, що перед ним є зброя, викликає функцію виконання Системи сприйняття для оновлення даних у Компоненті сприйняття цього Агенту.
Потім викликається Система Пам'яті, одночасно активуючи Компонент Перцепції та Компонент Пам'яті, щоб зберегти сприйняті дані в базі даних через Пам'ять.
Далі Action System знову викликає Memory Component та Action Component, отримуючи інформацію про навколишнє середовище з пам'яті, а потім зрештою виконує відповідну дію.
Отримати оновлений агентний об'єкт, в якому дані кожного компонента були оновлені
Отже, можна побачити, що System головним чином відповідає за визначення, які Component потрібно обробляти відповідною логікою.
У project89 світ наповнений різними типами агентів, деякі агенти, окрім базових можливостей, мають також вміння планувати.
![Деконструкція Project89: модульний, високопродуктивний фреймворк наступного покоління AI Agent])https://img-cdn.gateio.im/webp-social/moments-4cd7ca20f2967b9025411d9985f64831.webp(
Два, архітектура системи ArgOS
В ArgOS для того, щоб Агенти могли проводити більш глибокі роздуми та виконувати складніші завдання, було спроектовано багато Компонентів та кілька Систем.
У ArgOS система розділяється на "три рівні")РівеньСвідомості(:
有意识)СВІДОМІСТЬ(система
潜意识)ПІДСВІДОМЕ(СИСТЕМА
безсвідомо)UNCONSCIOUS(система
Взаємозв'язок між різними системами в ArgOS надзвичайно складний, основними є:
PerceptionSystem: відповідає за збір "стимулів" )stimuli( з зовнішнього середовища або інших сутностей і оновлення їх у компоненті Perception агента )Agent(.
ExperienceSystem: Перетворює Stimuli, зібрані PerceptionSystem, на більш абстрактний "досвід" )Experience(.
ThinkingSystem: інтелектуальна система "мислення" самого агента. Витягує поточний стан з компонентів Memory, Perception тощо, генеруючи generateThought)...( разом з LLM/логікою правил для створення "результату мислення" )ThoughtResult(.
ActionSystem: Якщо Action.pendingAction певного Agent не порожній, то через runtime.getActionManager)(.executeAction)...( слід реально виконати дію.
GoalPlanningSystem: періодично оцінювати прогрес цілей у списку Goal.current) або перевіряти, чи відбулися значні зміни в зовнішній/внутрішній пам'яті.
PlanningSystem: генерувати або оновлювати Plan[eid] виконання плану для "існуючої цілі" (Goal.current[eid]).
RoomSystem: обробка оновлень, пов'язаних з кімнатою (Room).
CleanupSystem: Регулярно знаходити та видаляти сутності, позначені компонентом Cleanup.
Завдяки з'єднанню цих систем, AI Agent реалізував: Сприйняття змін в оточенні ( Perception ) → Фіксація або перетворення в внутрішній досвід ( Experience ) → Самоосмислення та прийняття рішень ( Thinking ) → Втілення в дію ( Action ) → Динамічне коригування цілей та планів ( GoalPlanning + Planning ) → Синхронізація з оточенням ( Room ) → Своєчасне усунення непотрібних об'єктів ( Cleanup )
Три, аналіз загальної архітектури ArgOS
( 1. Ядро архітектури розділене на шари
Основна архітектура ArgOS включає такі рівні, як Entity, Component, System, Manager тощо.
![Деконструкція Project89: модульний, високопродуктивний дизайн фреймворку наступного покоління AI Agent])https://img-cdn.gateio.im/webp-social/moments-59f1984837d6636d7efc378c731a01eb.webp###
( 2. Компонент )Component### категорія
У ECS кожен об'єкт (Entity) може мати кілька компонентів (Component). В залежності від природи та життєвого циклу в системі, компоненти можна умовно розділити на такі категорії:
( 3. Архітектура системи
У вищеописаному вже детально розглянуто.
![Деконструкція Project89: модульний, високоефективний фреймворк наступного покоління AI Agent])https://img-cdn.gateio.im/webp-social/moments-19636582e09b473536b17c2de0c61fbc.webp###
( 4. Архітектура менеджера
Крім Component і System, також потрібен менеджер ресурсів, наприклад, як отримати доступ до бази даних, як обробляти конфлікти при оновленні стану тощо. Основні питання включають:
Ці Менеджери надають функції на системному рівні, майже не "керуючи" логікою, а викликаються Системами або Runtime.
SimulationRuntime є "диспетчером" всіх систем, який запускає або зупиняє цикли систем різних рівнів; також під час етапу побудови створює менеджерів і передає їх для використання кожній системі.
![Деконструкція Project89: модульний, високопродуктивний дизайн фреймворку наступного покоління AI Agent])https://img-cdn.gateio.im/webp-social/moments-b0180b99743a98bafb2b2d066900d65c.webp###
( 5. Як взаємодіяти з базою даних
У ECS системи є справжнім місцем виконання логіки, а читання та запис бази даних можуть бути виконані через "менеджер персистентності )PersistenceManager / DatabaseManager###" або "менеджер стану (StateManager)". Загальний процес виглядає наступним чином:
Чотири, інноваційні моменти архітектури
Додавання нових функцій під час розробки не вплине на інші системи, нові функції можна легко додати.
Продуктивність архітектури ECS вища, ніж у традиційної об'єктно-орієнтованої архітектури, що робить її більш придатною для виконання паралельних операцій. У складних сценаріях Defai вона може мати переваги, особливо в сценах, де агент виконує кількісну торгівлю.
Розділити System на свідоме, підсвідоме та несвідоме, щоб розрізнити різні типи System, коли їх слід виконувати, є надзвичайно вдалим дизайном.
В цілому, це надзвичайно модульна, продуктивна структура, в той же час якість коду висока і містить хорошу проектну документацію. Сподіваюсь, що більше ігрових команд або Defai команд виявлять цю структуру, щоб надати всім новий потенційний вибір архітектури.