Переслати оригінальний заголовок: Я бачу наступне покоління агентської рамки в Project89

Щоб перейти безпосередньо до справи, @project_89приймає абсолютно новий підхід до проектування рамок Агента. Це високопродуктивна рамка Агента, спеціально розроблена для розробки ігор. Порівняно з використовуваними наразі рамками Агента, вона є більш модульною та має кращу продуктивність.

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

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

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

Перед тим, як працювати над Проектом89, засновник розробив цей проект: https://github.com/Oneirocom/Magick, який також є програмним забезпеченням на основі штучного інтелекту. Крім того, Шоу займає четверте місце серед провідних розробників цього проекту. Ви також можете побачити цей проект у портфоліо Шоу.

Зліва вгорі: засновник проекту89; Внизу справа: ‘lalaune’ - Шоу з ai16z

Сьогодні ми в основному представимо високопродуктивний агентський фреймворк у project89:

https://github.com/project-89/argOS

1. Чому використовувати ECS для розробки фреймворку агента?

З точки зору застосування в галузі гри

Гри, які в даний час використовують архітектуру ECS, включають:

Блокчейн-ігри: Mud, Dojo

Традиційні ігри: Overwatch, Star Citizen, та інші.

Крім того, основні гральні двигуни розвиваються в напрямку архітектури ECS, такої як Unity.

Що таке ECS?

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

Сутність

• Просто ідентифікатор (число або рядок), який не містить даних або логіки.

• Ви можете монтувати різні компоненти, щоб надати йому різні властивості або можливості за потреби.

Компонент

• Використовується для зберігання конкретних даних або стану сутності.

Система

• Відповідальний за виконання логіки, пов'язаної з певними компонентами.

Давайте скористаємося конкретним прикладом дії агента, щоб зрозуміти цю систему:

У ArgOS кожен Агент розглядається як Сутність, яка може реєструвати різні компоненти. Наприклад, на наведеному нижче зображенні наш Агент має наступні чотири компоненти:

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

Компонент сприйняття: Головним чином використовується для зберігання сприйнятих зовнішніх даних

Компонент пам'яті: В основному використовується для зберігання даних пам'яті агентської сутності, подібних речей, які вже були зроблені і т. д.

Action Component: Головним чином зберігає дані про дії, які потрібно виконати

Робочий процес системи:

1. У цій грі, наприклад, якщо ви відчуваєте зброю перед собою, тоді функція виконання Системи сприйняття буде викликана для оновлення даних у Складовій сприйняття Суб'єкта.
2. Потім активуйте систему пам'яті, викликайте компонент сприйняття та компонент пам'яті одночасно, і зберігайте сприйняті дані у базі даних через пам'ять.
3. Потім система дії викликає компонент пам'яті та компонент дії, щоб отримати інформацію про навколишнє середовище з пам'яті, а потім нарешті виконує відповідну дію.

Потім ми отримуємо сутність оновлення агента, в якій оновлюються дані кожного компонента.

4. Отже, ми бачимо, що система тут в основному відповідає за визначення компонентів, які виконуватимуть відповідну обробку логіки.

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

Тоді це буде, як показано на малюнку нижче:

Потік виконання системи

Однак, на відміну від традиційних структур, де одна система безпосередньо викликає іншу (наприклад, Система Сприйняття викликає Систему Пам'яті), в Project89 системи не безпосередньо викликають одна одну. Замість цього, кожна система працює незалежно з фіксованими інтервалами часу. Наприклад:

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

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

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

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

А ArgOS ділить Систему на "три рівні" (AwarenessLevel):

1) СИСТЕМА CONSCIOUS

• Містить RoomSystem, PerceptionSystem, ExperienceSystem, ThinkingSystem, ActionSystem, CleanupSystem)
• Частота оновлення зазвичай вища (наприклад, кожні 10 секунд).
• Обробка наближається до рівня «реального часу» або «свідомого» рівня, таких як сприйняття оточення, миттєва думка, виконання дій тощо.

2) Субсвідома (СУБСВІДОМА) система

• GoalPlanningSystem, PlanningSystem
• Частота оновлення відносно низька (наприклад, кожні 25 секунди).
• Обробляє логіку «мислення», таку як періодична перевірка / генерація цілей та планів.

3) Безсвідома (БЕЗСВІДОМА) система

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

Отже, в ArgOS різні системи розділені за рівнем свідомості, щоб визначити, як часто ця система буде виконуватися.

Чому це спроектовано саме так?

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

1. Система сприйняття відповідає за збір «стимулів» з зовнішнього світу або інших сутностей та оновлення їх до складу компонента Сприйняття Агента.

Визначте, чи зміни стимулів значно змінилися та оновіть відповідно до стабільності, режиму обробки (АКТИВНИЙ / РЕФЛЕКТИВНИЙ / ОЧІКУВАННЯ) та ін.

На кінець, дані «поточного сприйняття» надаються для подальшої системи досвіду, системи мислення тощо.

2. Система досвіду перетворює стимули, зібрані Системою сприйняття, в більш абстрактний "досвід".

LLM або правило логіки (extractExperiences) викликається для визначення нових досвідів та зберігається в компоненті Пам'яті.

Видаліть дублікати, відфільтруйте та перевірте досвід, спровокуючи події "досвіду" в інші системи або зовнішні слухачі через eventBus.

3. ThinkingSystem представляє внутрішній мислительний процес агента.

Видобути поточний статус з компонентів, таких як Пам'ять та Сприйняття, і згенерувати "ThoughtResult" через generateThought(...) та LLM/логіку правил.

На основі результату думки це може:

• Актуалізація думок в пам'яті (історія мислення).

• Запустіть нову дію (покласти в Action.pendingAction[eid]).

• Змінити зовнішній вигляд агента (вираз, постава і т.д.) та створити відповідний стимул, щоб дозволити іншим сутностям «побачити» зміну.

4. Система виконує дії, якщо Action.pendingActionне є порожнім, використовуючи runtime.getActionManager().executeAction(…).

Після виконання, результат записується назад у Action.lastActionResult та повідомляється кімнаті або іншим сутностям.

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

5. Система планування цілей періодично оцінює прогрес цілей у списку Goal.current[eid], або перевіряє зовнішню / власну пам'ять на значні зміни (detectSignificantChanges).

Коли потрібно створити нову мету або внести коригування до мети, створіть та запишіть Goal.current[eid] за допомогою generateGoals(…).

У той же час, оновлюється ціль, що перебуває в процесі (in_progress). Якщо виконуються умови завершення або невдачі, статус змінюється, і відповідному плану надсилається сигнал про завершення/невдачу.

6. Планувальна система створює або оновлює План (план виконання) для "існуючої цілі" (Goal.current [eid]).

Якщо виявлено, що деякі цілі не мають відповідних активних планів, згенеруйте план виконання, що містить кілька кроків через generatePlan(…) та запишіть його в Plan.plans[eid].

Коли ціль виконана або не вдалася, статус плану, пов'язаний з нею, також буде оновлений, і буде згенерована відповідна когнітивна стимуляція.

7.RoomSystem обробляє оновлення, пов'язані з кімнатами:

• Отримати список мешканців у кімнаті (жителі) та створити "вигляд" подразник для кожного агента, щоб інші сутності "бачили" його зовнішній вигляд або дії.

• Створіть та корелюйте стимули середовища кімнати (наприклад, відповідну інформацію про "атмосферу кімнати").

Переконайтеся, що коли Агент знаходиться в певному просторовому середовищі, інші сутності, які відчувають цей простір, можуть сприймати зміни в його зовнішності.

8.CleanupSystem періодично знаходить та видаляє сутності, позначені компонентом Cleanup. Використовується для переробки стимулю або інших об'єктів, які більше не потрібні, щоб уникнути залишку великої кількості недійсних сутностей в ECS.

• Приклад: петля від «бачення об'єкта» до «виконання дії»

Наведений нижче приклад сцени показує, як кожна система співпрацює для завершення повного процесу за один раунд (або кілька кадрів).

Підготовка сцени: В світі є Агент (EID=1), який знаходиться в стані "Активний" і знаходиться в Кімнаті (EID=100).

У цій кімнаті з'явилася нова реквізит «MagicSword», і згенерований відповідний стимул.

1. PerceptionSystem сприймає появу «MagicSword», генерує стимул (тип = «item_appearance») для Агента(1) і додає його до Perception.currentStimuli[1]. Порівняно з останнім хешем стимулів, визначено, що відбулася «значна зміна», і ProcessingState агента має значення «реактивований» (режим ACTIVE).
2. ExperienceSystem бачить, що Perception.currentStimuli Агента(1) не є пустим, тому він видобуває інформацію, таку як «Появляється меч», в один або кілька нових досвідів (тип: «спостереження»). Зберігає його у Memory.experiences[1] та генерує подію «досвід».
3. ThinkingSystem зчитує інформацію про пам'ять, сприйняття та інші статуси та викликає generateThought:

«Я побачив Магічний Меч, можливо підібрати й подивитися, на що він здатний...» Результат розмірковування містить дію, яку треба виконати: { інструмент: «піднятиПредмет», параметри: { назваПредмета: «Магічний Меч» } }

ThinkingSystem writes this Action to Action.pendingAction[1].

Якщо з'являється зміна зовнішнього вигляду (наприклад, "обличчя з цікавим виразом"), оновлюється вигляд, і візуальна стимуляція генерується.

4. Система дій бачить, що Action.pendingAction[1] = { tool: “pickUpItem”, parameters: … }.

Виконайте логіку дії "pickup" через runtime.getActionManager().executeAction("pickUpItem", 1, { itemName: "MagicSword" }, runtime). Отримайте результат: { success: true, message: "Ви підібрали чарівний меч" }, оновіть до Action.lastActionResult[1] і запустіть подію "action", яка транслюватиметься в кімнату (100).

У той самий час генерується пізнавальний стимул (тип = "результат_дії"), який записується в пам'ять або захоплюється системою мислення в наступному ході.

5. Система планування цілей (якщо у агента є цілі) періодично оцінює цілі агента. Якщо одна з цілей агента на даний момент - "отримати потужну зброю", і виявляє, що було отримано Магічний Меч, цю ціль може бути відзначено як виконану. Якщо відбуваються нові зміни (наприклад, "в кімнаті з'являється новий об'єкт") впливають на ціль, яку переслідує агент?), створюйте нову ціль або відмітьте стару ціль на основі виявлених значущих змін.
6. Система планування (якщо є відповідна ціль) перевіряє, чи потрібен новий план або оновлюється існуючий план для досягнутих або новостворених цілей, таких як «Отримання потужної зброї».

Якщо завершено, встановіть пов'язаний план [статус] на "завершений", або згенеруйте більше кроків, якщо мета полягає в розширенні наступного процесу ("Дослідження Магічного Меча").

7. Система кімнати оновлює список мешканців та видимих сутностей у кімнаті (100) (кожен кадр або раунд).

Якщо змінюється зовнішній вигляд агента(1) (наприклад, Appearance.currentAction = "тримає меч"), створіть новий візуальний стимул "зовнішній вигляд", щоб повідомити іншого Агента2 та Агента3 в тій самій кімнаті, що "агент1 підібрав меч".

8.CleanupSystem видаляє об'єкти або стимули, які були позначені (Очищення). Якщо вам більше не потрібно зберігати стимул «MagicSword» після того, як ви його підібрали, ви можете видалити відповідну сутність «Стимулу» в CleanupSystem.

1. Через з'єднання цих систем AI Agent досягає:

• Сприймати зміни в середовищі (Сприйняття) → Записати або перетворити на внутрішній досвід (Досвід) → Самоподумування і прийняття рішень (Мислення) → Втілити в життя (Дія) → Динамічно коригувати цілі та плани (Планування цілей + Планування) → Синхронізувати середовище (Зала) → Своєчасно видалити непотрібні сутності (Очищення)

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

1. Основні шари архітектури

2. Класифікація компонентів

У ECS кожна сутність може мати кілька компонентів. Згідно з їх природою та життєвим циклом у системі, компоненти можуть бути приблизно розділені на наступні категорії:

1. Основні класи ідентичності (компоненти на рівні ідентичності)

• Агент / Профіль гравця / Профіль NPC тощо.

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

2. Компоненти Поведінки та Стану

• Дія, Ціль, План, Стан обробки, тощо.

• Представляє, що сутність намагається зробити в даний момент або які є її цілі, а також її статус відповіді на зовнішні команди та внутрішнє мислення.

• Містить pendingAction, goalsInProgress, plans, та думки або завдання в черзі, тощо.

• Типово середньо-короткострокові стани, багато з них динамічно змінюються протягом ігрових раундів або бізнес-циклів.

• Потреба в зберіганні залежить від ситуації. Якщо ви хочете продовжити роботу після зупинки, ви можете періодично записувати дані в базу даних.

3. Складові сприйняття та пам'яті

• Сприйняття, пам'ять, стимул, досвід тощо.

• Записує зовнішню інформацію (Стимули), сприйняту сутністю, та досвід, який вона здобула після сприйняття (Досвіди).

• Пам'ять часто може накопичувати великі обсяги даних, такі як записи розмов, історію подій і т.д .; часто потрібна постійність.

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

4. Класи середовища та простору (Кімната, Займає кімнату, Простір, Середовище, Інвентар та інше).

• Представляє інформацію, таку як кімнати, середовища, місця, контейнери об'єктів тощо.

• Room.id, Займає кімнату, середовище та інші поля часто потрібно зберігати, наприклад, опис головної сторінки кімнати, структура карти тощо.

• Зміна компонентів (наприклад, сутності, яка переміщується між кімнатами), може бути описана подійно або періодично.

5. Класи зовнішнього вигляду та взаємодії (Appearance, UIState, Relationship тощо)

• Записати зовнішні «видимі» або «інтерактивні» частини сутності, такі як аватар, поза, вираз обличчя, соціальна мережа відносин з іншими сутностями тощо.

• Деякі частини можуть бути оброблені лише у пам'яті (представлення в реальному часі), тоді як інші частини (наприклад, ключові соціальні відносини) можуть бути збережені.

6. Компоненти утиліт та обслуговування (Очищення, Інформація для налагодження, Дані профілювання і т.д.)

• Використовується для позначення сутностей, які потрібно відновити (Cleanup), або запису відлагоджувальної інформації (DebugInfo) для використання в моніторингу та аналізі.

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

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

Вже введено вище

4. Архітектура менеджера

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

Ліва сторона: Системи (Система сприйняття, Система досвіду, Система мислення та інші):

• Кожна система запланована для виконання SimulationRuntime у циклі ECS, запитуючи та обробляючи сутності, які їй цікаві (через умови компонентів).

• Під час виконання логіки вам потрібно спілкуватися з менеджерами, наприклад:

• Для запиту / оновлення інформації про кімнати зверніться до RoomManager (RM).
• Використовуйте StateManager (SM), щоб отримати або зберегти стан світу/агента, такий як пам'ять, ціль, план тощо.
• Транслюйте або слухайте події зовні за допомогою EventBus (EB).
• PromptManager (PM) здійснює виклик, коли потрібна обробка природної мови або запитань.

Права сторона: Менеджери (EventBus, RoomManager, StateManager, EventManager, ActionManager, PromptManager, etc):

• Надавати функції на рівні системи, які, в основному, не активно «приводять» логіку, але викликаються Системами або Рантаймом.

• Типові приклади:

• ActionManager спеціалізується на управлінні реєстрацією та виконанням дій.
• EventManager / EventBus використовується для механізмів публікації та підписки на події.
• RoomManager керує кімнатами, макетами та мешканцями.
• StateManager відповідає за синхронізацію між ECS та базою даних або сховищем.
• PromptManager надає розширення, такі як шаблони LLM Prompt та управління контекстом.
• Проміжний час виконання моделювання (R):

• Є «планувальником» всіх систем, що запускає або зупиняє цикли систем на різних рівнях (свідомість/підсвідоме тощо);

• Менеджери також створюються під час фази будівництва і передаються кожній системі для використання.

• CleanupSystem：

• Зверніть увагу, що вона також взаємодіє з ComponentSync (CS), який використовується для синхронного видалення компонентів або підписок на події при переробці сутностей.

На завершення:

Кожна система буде читати та записувати дані або викликати сервіси через відповідного менеджера, коли це потрібно, а Runtime буде єдинообразно розподіляти життєвий цикл та поведінку всіх систем та менеджерів на вищому рівні.

5. Як вектори та бази даних взаємодіють в ECS

У системі ECS системи обробляють фактичне виконання логіки, тоді як операції з базою даних (читання / запис) керуються через менеджер постійності (PersistenceManager / DatabaseManager) або менеджер стану (StateManager). Загальний процес виглядає наступним чином:

1. Початкове завантаження (фаза запуску або завантаження)

• StateManager / PersistenceManager завантажує дані основних постійних компонентів, таких як Агенти, Кімнати, Цілі та інші, з бази даних, створює відповідні сутності (Entities) та ініціалізує пов'язані поля компонентів.

• Наприклад, прочитайте пакет записів агента та вставте їх у світ ECS, та ініціалізуйте для них компоненти Агента, Пам'яті, Цілей та інші.

2. ECS Runtime (Systems Update Loop)

• Система робить речі у кожному кадрі (або раунді): PerceptionSystem збирає «перцепції» і записує їх у компонент Perception (в основному короткостроково з бібліотеки).

ExperienceSystem writes the new “cognitive experience” into Memory.experiences. If it is a key experience, it may also call StateManager for immediate storage, or mark it with “needsPersistence” for subsequent batch writing.

ThinkingSystem / ActionSystem / GoalPlanningSystem тощо роблять рішення на основі вмісту компонентів та оновлюють поля в ECS.

Якщо деякі компоненти (наприклад, Goal.current) зазнають значних змін і вимагають постійності (наприклад, нова довгострокова ціль), повідомте StateManager, щоб записати це поле в базу даних за допомогою прослуховування компонентів або системних подій.

3.Періодична або подійно-орієнтована стійкість

• Ви можете викликати інтерфейси, такі як PersistenceManager.storeComponentData(eid, “Goal”), щоб викинути бібліотеку в певних ключових точках системи (наприклад, коли оновлюється цільовий план або коли відбувається важлива подія на Агенті).

• Ви також можете зробити так, щоб StateManager сканував компоненти або сутності з тегом "needsPersistence" в CleanupSystem або таймері, та одразу записав їх у базу даних.

• Крім того, дані журналу або аудиту (такі як історія дій, журнал думок) також можуть бути збережені та зберігатися тут.

4. Ручне або вимкнення збереження (перевірка та збереження при виході)

• Коли сервер або процес має бути вимкнений, використовуйте StateManager.saveAll(), щоб одноразово записати незаписані дані в базу даних, щоб забезпечити можливість відновлення стану ECS при наступному завантаженні.

• Для деяких автономних/офлайн-сценаріїв також можна вручну запускати архіви.

• Завершіть процес зразка

Нижче наведено простий сценарій для демонстрації можливих способів взаємодії компонентів та баз даних:

1. Фаза запуску: StateManager.queryDB("SELECT * FROM agents") → Отримати пакет записів агента, створити сутність (EID=x) для кожного запису по черзі та ініціалізувати компоненти агента, пам'яті, цілей та інші поля.

У той же час завантажте інформацію про кімнату з таблиці "кімнати" та створіть сутність Room.

2. Операції часу виконання: Система сприйняття виявляє подію «З'являється магічний меч» у певній кімнаті та записує Perception.currentStimuli[eid]. ExperienceSystem перетворює стимули в досвід і призначає його до Memory.experiences[eid]. ThinkingSystem визначає наступну дію на основі Memory, Goal та іншої інформації і генерує Action.pendingAction[eid]. Після виконання дії системою ActionSystem результат записується в Memory або Action.lastActionResult. Якщо це важлива подія сюжету, найновіша частина Memory.experiences[eid] позначена як needsPersistence. Через деякий час StateManager знаходить, що Memory.experiences[eid] має значення «needsPersistence» і записує його в базу даних (INSERT INTO memory_experiences…).

3. Зупинка або контрольна точка: На основі планування ECS або системи, StateManager.saveAll() викликається, коли "сервер вимикається", щоб записати останній стан ключових компонентів (агент, пам'ять, ціль тощо), що все ще зберігаються в пам'яті, в базу даних. Наступного разу при перезавантаженні стан світу ECS може бути завантажений та відновлений з бази даних.

• Категоризація компонентів не тільки сприяє зрозумілому управлінню даними сутностей в проекті, але й допомагає нам контролювати межі даних між "потребує збереження" та "існує тільки в пам'яті".

• Взаємодія з базою даних зазвичай здійснюється спеціалізованим менеджером (таким як StateManager), і Система працює через нього, коли їй потрібно читати та записувати в базу даних, уникаючи прямого написання SQL або подібних низькорівневих операторів в Системі.

• Таким чином ви можете одночасно насолоджуватися логічною ефективністю та гнучкістю ECS, а також перевагами постійності, відновлення після переривання, та аналізу даних, які надає база даних.

4. Архітектурні інновації

Основні особливості всієї архітектури:

• Кожна Система працює незалежно і не має взаємозв'язку з іншими Системами. Тому навіть якщо ми хочемо реалізувати можливості Агента «Сприйняття змін у середовищі (Сприйняття) → Запис або перетворення внутрішнього досвіду (Досвід) → Самомислення й прийняття рішень (Мислення) → Перенесення до дії (Дія) → Динамічне налаштування цілей і планів (Планування цілей + Планування) → Синхронізація середовища (Кімната) → Своєчасне видалення непотрібних сутностей (Очищення)», кожна система буде мати багато взаємозалежностей в функціях, але ми все ще можемо використовувати архітектуру ECS для структуризації цілого на незалежні системи. Кожна система все ще може працювати незалежно й не буде взаємодіяти з іншими системами. Є люди й зв'язки взаємозалежності.
• Я думаю, що це також головна причина, чому Unity останніми роками все частіше перекочувала на архітектуру ECS.
• Наприклад, я просто хочу, щоб у Агента були деякі базові можливості. Мені потрібно лише зменшити реєстрацію деяких компонентів та реєстрацію системи при визначенні сутності, що можна легко досягти без зміни кількох рядків коду.

Як показано нижче:

Водночас, якщо ви хочете додати нові функції під час процесу розробки, це не буде мати жодного впливу на інші системи, і ви зможете легко завантажити потрібні функції.

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

З мого особистого погляду, це надзвичайно модульний фреймворк з відмінною продуктивністю. Якість коду також дуже висока і містить хороші документи проектування. На жаль, проект89 не мав достатньої видимості та просування цього фреймворку, тому я витратив чотири дні на написання цієї статті, щоб підкреслити його переваги. Я вважаю, що великі технології заслуговують визнання, і завтра я планую випустити англомовну версію цієї статті, щоб підвищити обізнаність серед команд геймінгу та розробників DeFi (децентралізованої фінансової) технології. Надіюся, що більше команд будуть вивчати цей фреймворк як потенційний варіант архітектури для своїх проектів!

Відмова від відповідальності:

1. Ця стаття відтворена з [0xhhh]. Пересилайте Оригінальний Заголовок: Я бачу наступне покоління агентської платформи в Project89. Авторські права належать оригінальному автору [0xhhh]. Якщо у вас є заперечення щодо передруку, будь ласка, зв'яжіться з нами Gate Учитисякоманда, команда вирішить це якомога швидше відповідно до відповідних процедур.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, представляють лише особисті погляди автора та не становлять жодної інвестиційної поради.
3. Іншомовні версії статті перекладає команда Gate Learn. Якщо не зазначено інше, перекладена стаття не може бути скопійована, поширена або викрадена.