Пересылаю оригинальный заголовок: В проекте 89 вижу следующее поколение агентской платформы

Чтобы перейти к делу,@project_89принимает совершенно новый подход к проектированию агентской среды. Это высокопроизводительный агентский фреймворк, специально разработанный для разработки игр. По сравнению с текущими использованными агентскими фреймворками, он более модульный и обеспечивает лучшую производительность.

Эта статья была написана долгое время, пытаясь дать всем понять, какие архитектурные обновления были сделаны в этой раме по сравнению с традиционной агентской рамой. Она была пересмотрена много раз до этой версии, но все еще есть некоторые части в статье, которые слишком запутаны. Из-за технических трудностей мне не удалось дополнительно распространить ее. Если у вас есть предложения по улучшению статьи, пожалуйста, оставьте свои комментарии.

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

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

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

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

Сегодня мы в основном расскажем о высокопроизводительной среде Agent Framework в project89:

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

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

С точки зрения применения в игровой сфере

Игры, в настоящее время использующие архитектуру ECS, включают:

Игры на блокчейне: Mud, Dojo

Традиционные игры: Overwatch, Star Citizen и т. д.

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

Что такое ECS?

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

Сущность

• Просто идентификатор (число или строка), не содержащий данных или логики.

• Вы можете установить различные компоненты, чтобы дать ему различные свойства или возможности по мере необходимости.

Компонент

• Используется для хранения конкретных данных или состояния сущности.

Система

• Ответственный за выполнение логики, связанной с определенными компонентами.

Давайте воспользуемся конкретным примером действия агента, чтобы понять эту систему:

В ArgOS каждый агент рассматривается как сущность, которая может зарегистрировать различные компоненты. Например, на рисунке ниже наш агент имеет следующие четыре компонента:

Компонент Агента: в основном хранит базовую информацию, такую как имя агента, название модели и т.д.

Компонент восприятия: в основном используется для хранения воспринимаемых внешних данных

Компонент памяти: главным образом используется для хранения данных памяти агентской сущности, аналогичных вещей, которые были сделаны и т. д.

Компонент действия: в основном хранит данные действия для выполнения

Системный рабочий процесс:

1. В этой игре, например, если вы почувствуете оружие перед собой, то будет вызвана функция выполнения Системы Восприятия для обновления данных в Компоненте Восприятия Сущности Агента.
2. Затем запустите систему памяти, вызовите компонент восприятия и компонент памяти одновременно и сохраните воспринятые данные в базу данных через память.
3. Затем Система Действий вызывает Компонент памяти и Компонент действий, чтобы получить информацию об окружающей среде из памяти, а затем, наконец, выполняет соответствующее действие.

Затем мы получаем сущность агента обновления, в которой обновляются данные каждого компонента.

4. Таким образом, мы видим, что здесь система в основном отвечает за определение того, какие компоненты выполнять соответствующую логику обработки.

И очевидно, что в project89 это мир, наполненный различными типами Агентов. Например, некоторые Агенты не только обладают вышеупомянутыми базовыми способностями, но и имеют способность к составлению планов.

Затем это будет выглядеть как показано на картинке ниже:

Поток выполнения системы

Однако, в отличие от традиционных структур, где одна система напрямую вызывает другую (например, Система Восприятия вызывает Систему Памяти), в Project89 системы не вызывают друг друга напрямую. Вместо этого каждая система работает независимо через фиксированные временные интервалы. Например:

• Система восприятия запускается каждые 2 секунды для обновления компонента восприятия новыми полученными окружающими данными.
• Система памяти запускается каждую секунду, извлекает данные из компонента восприятия и сохраняет их в компоненте памяти.
• Система Plan выполняется каждые 1000 секунд, анализируя собранные данные, чтобы определить, требуется ли оптимизация и создание нового плана, который затем записывается в компонент плана.
• Система действий запускается каждые 2 секунды, реагируя на изменения окружающей среды и изменяя действия на основе обновлений от компонента плана.

До сих пор этот статья значительно упростил архитектуру ArgOS, чтобы сделать ее более понятной. Теперь давайте ближе рассмотрим реальная система ArgOS.

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

Для того, чтобы позволить Агенту думать более глубоко и выполнять более сложные задачи, ArgOS разработала множество компонентов и систем.

И ArgOS разделяет System на «три уровня» (ConsciousnessLevel):

1) СОЗНАТЕЛЬНАЯ система

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

2) Система подсознания (SUBCONSCIOUS)

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

3) Система бессознательного (БЕССОЗНАТЕЛЬНОЙ)

• Еще не включено
• Частота обновления медленнее (например, более 50 секунд),

Поэтому в ArgOS различные системы разделяются в соответствии с уровнем сознания, чтобы определить, как часто будет выполняться этот система.

Почему это сделано таким образом?

Поскольку взаимосвязь различных систем в ArgOS чрезвычайно сложна, как показано ниже:

1. Система восприятия отвечает за сбор «стимулов» из внешнего мира или других сущностей и их обновление в составляющей Восприятия Агента.

Определите, изменяется ли стимул значительно, и обновляйте соответственно на основе стабильности, режима обработки (АКТИВНЫЙ/РЕФЛЕКСИВНЫЙ/ОЖИДАНИЕ) и т. д.

В конечном итоге данные о "текущем восприятии" предоставляются для последующей системы опыта, системы мышления и т. д.

2. Система опыта преобразует стимулы, собранные Системой восприятия, в более абстрактный «опыт».

LLM или правила логики (extractExperiences) вызываются для определения новых опытов и сохраняются в компоненте Memory.

Удаление дубликатов, фильтрация и проверка опыта, с одновременной генерацией событий «опыт» в других системах или внешних слушателях через eventBus.

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

Извлеките текущий статус из компонентов, таких как Память и Восприятие, и сгенерируйте "РезультатМысли" через generateThought(…) и логику LLM/правило.

Исходя из результата мысли, это может:

• Обновить мысли в Памяти (история мыслей).

• Активируйте новое действие (поместите в Action.pendingAction[eid]).

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

4. ActionSystem выполняет действия, если Action.pendingAction не пусто, используя runtime.getActionManager().executeAction(...).

После выполнения записать результат обратно в Action.lastActionResult и уведомить комнату или другие сущности.

Это также порождает CognitiveStimulus (когнитивное стимулирование), чтобы последующие системы «знали», что действие было выполнено или может быть включено в память.

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», генерирует Stimulus (тип = «item_appearance») для Agent(1) и добавляет его в Perception.currentStimuli[1]. По сравнению с последним Hash Stimuli определяется, что произошло «существенное изменение», и ProcessingState агента переводится в «реактивирован» (режим АКТИВНЫЙ).
2. ExperienceSystem видит, что Perception.currentStimuli Агента(1) не пуст, поэтому он извлекает информацию, такую как «Появление меча», в одно или несколько новых опытов (тип: «наблюдение»). Сохраните его в Memory.experiences[1] и отправьте событие «опыт».
3. ThinkingSystem считывает информацию о памяти, восприятии и других состояниях и вызывает generateThought:

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

ThinkingSystem записывает это действие в Action.pendingAction[1].

Если происходит изменение внешности (например, "лицо с любопытным выражением"), то внешность обновляется, и генерируется визуальное воздействие.

4.ActionSystem видит Action.pendingAction[1] = { tool: "pickUpItem", параметры: ... }。

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

В то же время генерируется когнитивный стимул (тип="результат_действия"), записанный в Память или захваченный ThinkingSystem в следующем ходу.

5. Система планирования целей (если у агента есть цели) периодически оценивает цели агента. Если одна из целей агента в данный момент - «получить мощное оружие», и обнаруживает, что был получен Магический меч, цель может быть отмечена как выполненная. Если происходят новые изменения (например, «в комнате появляется новый объект» влияет на цель, преследуемую агентом?), генерируется новая цель или отказ от старой цели на основе обнаруженных значительных изменений.
6. PlanningSystem (если есть связанная цель) проверяет, требуется ли новый план или обновление существующего плана для завершенных или новых созданных целей, таких как «Получить мощное оружие».

Если завершена, установите связанный план [статус] на «завершено» или сгенерируйте больше шагов, если целью является расширение последующего процесса («Исследуйте магический меч»).

7.RoomSystem обновляет список жильцов и видимых сущностей в комнате (100) (каждый кадр или раунд).

Если внешний вид агента(1) изменяется (например, Appearance.currentAction = «держит меч»), создайте новый визуальный стимул «внешности», чтобы сообщить другим агентам2 и агентам3 в одной комнате, что «агент1 поднял меч».

8.CleanupSystem удаляет сущности или стимулы, которые были помечены (Cleanup). Если вам больше не нужно сохранять стимул "Магический меч" после его подбора, вы можете удалить соответствующую сущность стимула в CleanupSystem.

1. Через соединение этих систем, AI Agent достигает:

• Воспринимать изменения в окружающей среде (Perception) → Записывать или трансформировать во внутренний опыт (Experience) → Самостоятельное мышление и принятие решений (Thinking) → Претворять его в действие (Action) → Динамическая корректировка целей и планов (GoalPlanning + Planning) → Синхронизация окружения (Комната) → Своевременная утилизация бесполезных сущностей (Очистка)

3. Анализ общей архитектуры ArgOS

1. Основные слои архитектуры

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

В ECS у каждой сущности может быть несколько компонентов. В зависимости от их природы и жизненного цикла в системе, компоненты можно грубо разделить на следующие категории:

1. Классы основной идентичности (компоненты на уровне идентичности)

• Агент / Игрок / ПрофильNPC / ПрофильNPC и т. д.

• Используется для уникальной идентификации сущностей, хранения основных ролей или информации об единицах и, как правило, требует сохранения в базе данных.

2. Компоненты поведения и состояния

• Действие, Цель, План, Состояние обработки и т. д.

• Представляет, что сущность в данный момент пытается делать или какие у нее цели, а также ее статус ответа на внешние команды и внутреннее мышление.

• Содержит ожидающие действия, текущие цели, планы и мысли или задачи в очереди и т. д.

• Обычно среднесрочные/краткосрочные состояния, многие из которых динамически изменяются в течение раундов игры или бизнес-циклов.

• Необходимо ли запастись зависит от ситуации. Если вы хотите продолжить работу после остановки, вы можете периодически записывать данные в базу данных.

3. Компоненты восприятия и памяти

• Восприятие, Память, Стимул, Опыт и т.д.

• Записывает внешнюю информацию (стимулы), воспринятую субъектом, и переработанные в ней после восприятия опыты (опыт).

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

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

4. Классы окружения и пространства (Комната, ЗанимаетКомнату, Пространство, Окружение, Инвентарь и т.д.)

• Представляет информацию, такую как комнаты, окружение, местоположение, контейнеры объектов и т. д.

•Room.id, OccupiesRoom, Environment and other fields often need to be persisted, such as room homepage description, map structure, etc.

• Изменение компонентов (например, сущности, перемещающейся между комнатами) может быть записано событийно или периодически.

5. Классы внешнего вида и взаимодействия (Appearance, UIState, Relationship, и т. д.)

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

• Некоторые части могут быть обработаны только в памяти (в виде реального времени), в то время как другие части (например, ключевые социальные отношения) могут быть сохранены.

6. Компоненты утилиты и обслуживания (Очистка, DebugInfo, ProfilingData и т. д.)

• Используется для обозначения сущностей, которые требуется утилизировать (Cleanup), или записи отладочной информации (DebugInfo) для использования в мониторинге и анализе.

• Обычно существует только в памяти и редко синхронизируется с базой данных, если это необходимо для ведения журнала или аудита.

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

Уже введено выше

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

Помимо Компонентов и Систем, требуется дополнительный уровень управления ресурсами. Этот уровень обрабатывает доступ к базе данных, конфликты состояний и другие важные операции.

Левая сторона: Системы (PerceptionSystem, ExperienceSystem, ThinkingSystem и т. д.):

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

• При выполнении логики вам необходимо взаимодействовать с менеджерами, например:

• Вызовите RoomManager (RM), чтобы запросить/обновить информацию о комнате.
• Используйте StateManager (SM), чтобы получить или сохранить состояние мира/агента, такие как Память, Цель, План и т. д.
• Внешняя передача или прослушивание событий с использованием EventBus (EB).
• PromptManager (PM) вызывается, когда требуется обработка естественного языка или подсказки.

Right Side: Менеджеры (EventBus, RoomManager, StateManager, EventManager, ActionManager, PromptManager и т. д.):

• Предоставление функций на уровне системы, которые в основном не активно «управляют» логикой, но вызываются Системами или Runtime.

• Типичные примеры:

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

• Является «планировщиком» всех систем, запускающим или останавливающим циклы систем на разных уровнях (сознательном/подсознательном и т. д.).

• Менеджеры также создаются на этапе строительства и передаются каждой Системе для использования.

• CleanupSystem：

• Обратите внимание, что он также взаимодействует с ComponentSync (CS), который используется для синхронного удаления компонентов или подписок на события при переработке сущностей.

В заключение:

Каждая Система будет читать и записывать данные или вызывать сервисы через соответствующего Менеджера при необходимости, а Рантайм будет единообразно планировать жизненный цикл и поведение всех Систем и Менеджеров на более высоком уровне.

5. Как векторы и базы данных взаимодействуют в ECS

В системе ECS системы обрабатывают фактическое выполнение логики, в то время как операции с базой данных (чтение/запись) управляются через Менеджер постоянства (PersistenceManager / DatabaseManager) или Менеджер состояния (StateManager). Общий процесс выглядит следующим образом:

1. Загрузка (фаза запуска или загрузки)

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

• Например, прочитайте пакет записей агента и вставьте их в мир ECS, а также инициализируйте для них компоненты Agent, Memory, Goal и другие.

2. Время работы ECS (цикл обновления системы)

• Система выполняет действия в каждом кадре (или раунде): PerceptionSystem собирает «восприятия» и записывает их в компонент Perception (в основном краткосрочные из библиотеки).

ExperienceSystem записывает новый «когнитивный опыт» в Memory.experiences. Если это ключевой интерфейс, он также может вызвать StateManager для немедленного хранения или пометить его "needsPersistence" для последующей пакетной записи.

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) для каждой записи по очереди и инициализировать поля агента, памяти, цели и другие компоненты.

Load room information from the “rooms” table at the same time and create a Room entity.

2. Операции во время выполнения: PerceptionSystem обнаруживает событие «Появление Волшебного Меча» в определенной комнате и записывает 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 также будет полезен (не только в сценариях агентских игр).
• Разделение системы на сознательную, подсознательную и бессознательную для различения того, как часто должны выполняться разные типы систем, является чрезвычайно умным дизайном и уже является очень конкретной человеческой способностью.

С моей личной точки зрения, это крайне модульный фреймворк с отличной производительностью. Качество кода также очень высокое, и содержит хорошие документы дизайна. К сожалению, проект Project89 не получил достаточной видимости и продвижения для этого фреймворка, поэтому я потратил четыре дня на написание этой статьи, чтобы подчеркнуть его преимущества. Я считаю, что отличные технологии заслуживают признания, и завтра я планирую выпустить английскую версию этой статьи, чтобы повысить осведомленность среди команд игровых разработчиков и разработчиков DeFi (децентрализованная финансовая сфера). Надеюсь, что больше команд будут изучать этот фреймворк как потенциальный архитектурный выбор для своих проектов!

Отказ от ответственности:

1. Эта статья воспроизводится из [0xhhh]. Пересылайте оригинальное название: Я вижу следующее поколение агентской структуры в Project89. Авторские права принадлежат оригинальному автору [0xhhh]. Если у вас есть возражения по поводу перепечатки, пожалуйста, свяжитесь Gate Learnкоманда, команда обработает это как можно скорее в соответствии с соответствующими процедурами.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, представляют только личные взгляды автора и не являются инвестиционным советом.
3. Другие языковые версии статьи переведены командой Gate Learn. Если не указано иное, переведенная статья не может быть скопирована, распространена или использована в качестве источника.