Я увидел фреймворк Agent следующего поколения в Project89.

Автор：0xhhh

Сначала вывод，@project_89 использует совершенно новый подход к проектированию Agent Framework, это высокопроизводительный Agent Framework для разработки игр, который более модулен и обладает лучшей производительностью по сравнению с используемыми в настоящее время Agent Framework.

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

背景 разработчика

Это технический блог, поэтому сначала посмотрим на технические способности этого founder:

До того как Founder занялся project89, он сделал этот проект：https://github.com/Oneirocom/Magick, это также программное обеспечение для программирования с использованием ИИ, одновременно shaw является четвертым разработчиком в рейтинге этого проекта, в резюме shaw также можно увидеть этот проект.

Слева вверху：founder project89, Справа внизу：lalaune, это shaw из ai16z

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

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

1. Почему для проектирования Agent Framework используется ECS

С точки зрения применения в игровой области, в настоящее время игры, использующие архитектуру ECS: Блокчейн игры：Mud、Dojo Традиционные игры: Overwatch, Star Citizen и т.д. И в настоящее время основные игровые двигатели также эволюционируют в направлении ECS, например Unity.

Что такое ECS?

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

1. Entity（Сущность） • Это просто ID（число или строка）, не содержит никаких данных или логики. • Может быть оснащена различными компонентами по мере необходимости, чтобы赋予 ей различные属性或能力.

2. Component（Компонент） • Используется для хранения конкретных данных или состояния сущности.

3. System（Система） • Отвечает за выполнение логики, связанной с определенными компонентами.

Чтобы понять эту систему на конкретном примере действия Agent: В ArgOS каждый Agent рассматривается как Entity, он может регистрировать различные компоненты, например, на рисунке ниже у нашего Agent есть следующие четыре компонента：Agent Component：В основном хранит базовую информацию, такую как имя Agent, имя модели и т.д. Perception Component：В основном используется для хранения данных о внешнем мире, воспринятых агентом. Memory Component：В основном используется для хранения данных Memory Agent Entity,类似 сделанных вещей и т.д. Action Component：В основном хранит данные Action, которые должны быть выполнены.

Рабочий процесс System:

1. В этой игре, например, восприняли, что перед собой есть оружие, тогда это вызовет функцию выполнения Perception System для обновления данных внутри Perception Component этого Agent Entity;

2. Затем触发 Memory System, одновременно вызывая Perception Component и Memory Component, после персистентности воспринятых данных в базу данных через Memory;

3. Затем Action System вызывает Memory Component и Action Component, получает информацию об окружающей среде из памяти, и наконец выполняет соответствующее действие;

4. Затем мы получаем Update Agent Entity, где данные каждого Component были обновлены, поэтому мы можем видеть, что здесь System в основном отвечает за определение того, какие Component должны выполнять соответствующую логику обработки.

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

Процесс выполнения System

Но фактический процесс выполнения system не такой, как мы представляем, традиционный подход, когда Perception System выполняет вызов Memory System после завершения, между разными System нет отношений вызова, каждый System будет выполняться один раз в规定的 цикле, например：

• Perception System может выполняться один раз в 2s для обновления полученных внешних восприятий и обновления их в Perception Component

• Memory System может выполняться один раз в 1s, извлекать данные из Perception Component и загружать их в Memory Component

• Plan System может выполняться один раз в 1000s, судить на основе полученной информации, нужно ли оптимизировать制定 разумный план в соответствии с соответствующей целью, и затем записать эту часть обновления в Plan Component

• Action System также может выполняться один раз в 2s, таким образом можно своевременно реагировать на внешнюю информацию, одновременно, если Plan Component имеет обновление, то необходимо обновить свой Action Component на основе этих данных,进而 влияя на最初做出的 Action.

Статья до этого момента основана на моем понимании ArgOS, сильно упрощена его архитектура для лучшего понимания всеми, далее посмотрим на реальный ArgOS.

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

В ArgOS, чтобы Agent мог выполнять более глубокое мышление и выполнять более сложные задачи, разработано много Component, а также много System.

И в ArgOS System разделены на“три уровня” (ConsciousnessLevel)：

1）Сознательная (CONSCIOUS) система

• Включает RoomSystem, PerceptionSystem, ExperienceSystem, ThinkingSystem, ActionSystem, CleanupSystem)

• Частота обновления обычно высокая (например, каждые 10 секунд).

• Более близко к“реальному времени”или“явному сознанию”уровню обработки, such as восприятие окружающей среды, мышление в реальном времени, выполнение действий и т.д.

2）Подсознательная (SUBCONSCIOUS) система

• GoalPlanningSystem, PlanningSystem

• Частота обновления относительно низкая (например, каждые 25 секунд).

• Обрабатывает логику“мышления”, such as периодическая проверка/генерация целей и планов.

3）Бессознательная (UNCONSCIOUS) система

• В настоящее время временно еще не включена

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

Поэтому в ArgOS различные System разделены согласно ConsciousnessLevel, чтобы规定, через сколько времени этот System должен выполниться один раз.

Почему так спроектировано? Потому что отношения между различными system в ArgOS чрезвычайно сложны, как на рисунке ниже：

1. PerceptionSystem отвечает за сбор“стимулов”(stimuli) из внешнего мира или других сущностей и обновление их в компоненте Perception агента (Agent). Судить, значительно ли изменился стимул, делать соответствующее обновление в соответствии со стабильностью, режимом обработки (ACTIVE/REFLECTIVE/WAITING) и т.д. В конечном итоге предоставлять информацию о“текущем восприятии”для последующих ExperienceSystem, ThinkingSystem и т.д.

2. ExperienceSystem преобразует Stimuli, собранные PerceptionSystem, в более абстрактный“опыт”(Experience). Будет вызывать LLM или логику правил (extractExperiences) для识别 новых опытов и хранения их в компоненте Memory. Удаление дубликатов, фильтрация, проверка опыта, одновременно через eventBus触发“experience”событие для других систем или внешних слушателей.

3. ThinkingSystem“Система мышления”самого агента. Извлекать текущее состояние из компонентов Memory, Perception и т.д., через generateThought(...) с LLM / логикой правил генерировать“результат мышления”(ThoughtResult). В соответствии с результатом мышления, возможно： • Обновлять thoughts (историю мышления) в Memory. • Trigger новое Action（поместить в Action.pendingAction[eid]）. • Изменять внешнее Appearance агента（выражение лица, поза и т.д.）, и генерировать соответствующий Stimulus, чтобы другие сущности“увидели”изменения.

4. ActionSystem Если Action.pendingAction определенного Agent не пуст, то через runtime.getActionManager().executeAction(...) действительно выполнять действие. После выполнения записать результат обратно в Action.lastActionResult и уведомить комнату или другие сущности. Также借此产生 CognitiveStimulus（когнитивный стимул）, чтобы последующие системы“знали”, что это действие завершено, или может быть включено в память.

5. GoalPlanningSystem Периодически оценивать прогресс целей в списке Goal.current[eid], или проверять, произошли ли значительные изменения во внешней/собственной памяти (detectSignificantChanges). Когда требуется новая цель или корректировка цели, через generateGoals(...) генерировать и записывать в Goal.current[eid]. Одновременно обновлять цели в прогрессе (in_progress), если соответствуют условия завершения или неудачи, изменять состояние и отправлять сигнал завершения/неудачи соответствующему Plan.

6. PlanningSystem Генерировать или обновлять Plan（план выполнения）для“существующих целей”(Goal.current[eid]). Если обнаружено, что для некоторых целей нет соответствующего активного (active) плана, то через generatePlan(...)产生包含若干 steps的执行路线图, и записать его в Plan.plans[eid]. Также обновлять состояние Plan, связанного с ним, при завершении или неудаче цели, и产生 соответствующий когнитивный стимул.

7. RoomSystem Обрабатывает обновления, связанные с комнатой (Room)： • Получать список occupants в комнате, генерировать“внешний вид（appearance）”стимул для каждого agent, чтобы другие сущности“увидели”его внешность или действия. • Создавать стимул окружающей среды комнаты (например, подходящую“атмосферу комнаты”информацию) и ассоциировать его. Убедиться, что когда Agent находится в определенной пространственной среде, другие сущности, воспринимающие это пространство, могут воспринимать изменения его внешности.

8. CleanupSystem Периодически находить и удалять сущности, помеченные компонентом Cleanup. Используется для утилизации Stimulus или других объектов, которые больше не нужны, предотвращая遗留大量无效的实体 в ECS.

• Пример：Один цикл от“увидеть объект”до“выполнить действие”

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

1. Подготовка сцены：В мире (World) существует Agent (EID=1), находится в“Active”состоянии, и находится в определенной Room (EID=100). В этой Room появился новый предмет“MagicSword”, сгенерирован соответствующий Stimulus.

2. PerceptionSystem обнаруживает появление“MagicSword”, генерирует Stimulus (type=“item_appearance”) для Agent(1) и добавляет в Perception.currentStimuli[1]. Сравнивая с предыдущим Stimuli Hash,认定“есть значительные изменения”, “реактивировать”ProcessingState агента (режим ACTIVE).

3. ExperienceSystem видит, что Perception.currentStimuli Agent(1) не пуст, поэтому извлекает информацию, такую как“Sword appears”, в 1 или несколько новых Experience (type：“observation”). Хранить в Memory.experiences[1], и发射「experience」событие.

4. ThinkingSystem считывает информацию о состоянии Memory, Perception и т.д., вызывает generateThought： “Я увидел MagicSword, может быть, могу подобрать и посмотреть, что он может делать...” Этот результат мышления содержит ожидающее выполнения Action：{ tool："pickUpItem"， parameters：{ itemName："MagicSword" } } ThinkingSystem записывает это Action в Action.pendingAction[1]. Если есть изменения appearance（например, “выражение лица с любопытством”）, то обновить Appearance и产生 визуальный стимул.

5. ActionSystem видит Action.pendingAction[1] = { tool："pickUpItem"， parameters：... }. Через runtime.getActionManager().executeAction("pickUpItem"， 1， { itemName："MagicSword" }， runtime) выполнять логику действия“подбор”. Получать результат：{ success：true， message："Вы подняли魔法剑" }, обновлять в Action.lastActionResult[1], и触发「action」событие广播给房间 (100). Одновременно产生 когнитивный стимул (type=“action_result”), записывать в Memory или позволять ThinkingSystem захватить в следующем раунде.

6. GoalPlanningSystem (если у этого agent есть цели) периодически оценивать цели agent, если в это время某项 цель agent“получить мощное оружие”, и обнаружено, что MagicSword уже в руках, может пометить эту цель как завершенную. Если产生/keySeatTr new changes (например, “новый объект появился в комнате”повлиял на цели, которые преследует agent？), то согласно detectSignificantChanges генерировать новые цели или отказаться от старых целей.

7. PlanningSystem (если есть соответствующие цели) для таких завершенных или только что сгенерированных целей, как“получить мощное оружие”, проверять, нужен ли новый Plan или обновить существующий Plan. Если завершено, то установить关联的 Plan [status] в “completed”；или если цель требует расширения последующего процесса (“изучить魔法剑”), то генерировать больше шагов.

8. RoomSystem (каждый кадр или каждый раунд) обновлять список Occupants и видимые сущности в комнате (100). Если внешность agent(1) изменилась（например, Appearance.currentAction = “holding sword”）, то создавать новый「appearance」визуальный стимул, чтобы другие Agent2, Agent3 в той же комнате знали“agent1 поднял меч”.

9. CleanupSystem удалять помеченные (Cleanup) сущности или стимулы. Если после подбора“MagicSword”этот Stimulus больше не нужно保留, можно удалить соответствующую сущность Stimulus в CleanupSystem.

Через соединение этих систем, AI Agent реализует： • Восприятие изменений окружающей среды (Perception) → Запись или преобразование во внутренний опыт (Experience) → Самостоятельное мышление и принятие решений (Thinking) → Воплощение в действие (Action) → Динамическая корректировка целей и планов (GoalPlanning + Planning) → Синхронизация окружающей среды (Room) → Своевременная утилизация бесполезных сущностей (Cleanup).

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

1. Уровни核心 архитектуры

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

В ECS каждая сущность (Entity) может иметь несколько компонентов (Component). Согласно性质 и жизненному циклу в системе,大致 можно разделить компоненты на следующие категории：

1. Класс核心 идентичности (Identity-Level Components) • Agent / PlayerProfile / NPCProfile и т.д. • Используется для уникальнойидентификации сущности, хранения核心角色或单位 информации, обычно требуется персистентность в базу данных.

2. Класс поведения и состояния (Behavior & State Components) • Action, Goal, Plan, ProcessingState и т.д. • Представляет то, что сущность должна делать сейчас或 цели, а также состояние реакции на внешние команды, внутреннее мышление. • Включает pendingAction, goalsInProgress, plans, а также мышление или задачи в очереди и т.д. • Обычно среднесрочное/краткосрочное состояние, многие будут динамически изменяться с игровыми раундами или бизнес-циклами. • Требуется ли сохранение в базу данных зависит от ситуации. Если希望断点续跑, возможно периодическая запись в базу данных.

3. Класс восприятия и памяти (Perception & Memory Components) • Perception, Memory, Stimulus, Experience и т.д. • Записывает внешнюю информацию (Stimuli), воспринятую сущностью, а также опыт (Experiences), извлеченный после восприятия. • Memory часто может накапливать大量 данных, например, записи对话, история событий и т.д.; часто требуется делать персистентность. • Perception может быть информацией реального времени или временной, в основном эффективна в краткосрочной перспективе, можно решать, записывать ли в базу данных в соответствии с потребностями（например, хранить только важные события восприятия）.

4. Класс окружающей среды и пространства (Room, OccupiesRoom, Spatial, Environment, Inventory и т.д.) • Представляет информацию о комнате, окружающей среде, позиции, контейнере предметов и т.д. •Room.id, OccupiesRoom, Environment и т.д. поля часто требуют персистентности, such as описание首页 комнаты, структура карты и т.д. • Постоянно изменяющиеся компоненты (например, Entity перемещается между разными комнатами) можно делать событийную или периодическую запись.

5. Класс внешности и взаимодействия (Appearance, UIState, Relationship и т.д.) • Записывает“видимую”или“взаимодействующую”часть сущности对外, such as Avatar, pose, facialExpression, сеть социальных отношений с другими сущностями и т.д. •一部分 можно обрабатывать только в памяти (表现 реального времени), другая часть（например, ключевые социальные отношения）может потребовать персистентности.

6. Класс вспомогательный или operasional (Cleanup, DebugInfo, ProfilingData и т.д.) • Используется для标记哪些 сущности需要 утилизации (Cleanup), или записи отладочной информации (DebugInfo) для использования при мониторинге и анализе. • Обычно существует только в памяти, редко синхронизируется в базу данных unless日志或审计需要.

3. Архитектура System

Уже介绍 выше

4. Архитектура Manager

Помимо Component и System нам на самом деле не хватает менеджера ресурсов, например, как访问数据库, как обрабатывать конфликты при обновлении состояния и т.д.

Слева Systems (PerceptionSystem, ExperienceSystem, ThinkingSystem и т.д.)：

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

• При выполнении логики需要 взаимодействовать с Managers, например：

• Вызывать RoomManager (RM) для запроса/обновления информации о комнате.

• Использовать StateManager (SM) для получения или сохранения состояния мира/агента, such as Memory, Goal, Plan и т.д.

• Использовать EventBus (EB) для广播或监听 событий对外.

• В некоторых случаях, требующих обработки естественного языка或提示语, вызывать PromptManager (PM).

----------------

Справа Managers (EventBus, RoomManager, StateManager, EventManager, ActionManager, PromptManager и т.д.)：

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

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

• ActionManager специально управляет регистрацией и выполнением действий (Action).

• EventManager / EventBus используется для механизма публикации и подписки на события.

• RoomManager управляет rooms, макетом и occupant.

• StateManager отвечает за синхронизацию ECS с базой данных或存储.

• PromptManager предоставляет шаблоны LLM Prompt, управление контекстом и т.д. расширения.

• Посередине SimulationRuntime (R)：

• Является“планировщиком”всех Systems, запускать或停止 циклы системы разных уровней (Conscious/Subconscious и т.д.);

• Также создает Managers на этапе构造 и передает их каждому System для использования.

• CleanupSystem：

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

Вывод：Каждый System будет при необходимости через соответствующий Manager читать/записывать данные或 вызывать сервисы, а Runtime на более высоком уровне единообразно планирует жизненный цикл и поведение всех System и Manager.

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

В ECS Systems являются местом, где действительно выполняется логика, а чтение/запись базы данных может быть выполнено через“менеджер персистентности (PersistenceManager / DatabaseManager)”或“менеджер состояния (StateManager)”. Примерный процесс может быть следующим：

1. При запуске或 загрузке (Initial Load) • StateManager / PersistenceManager загружает данные核心 персистентных компонентов Agents, Rooms, Goals и т.д. из базы данных, создает соответствующие сущности (Entities) и инициализирует соответствующие поля компонентов. • Например, читать一批 agent записи вставлять в мир ECS, инициализировать для них компоненты Agent, Memory, Goal и т.д.

2. Время выполнения ECS (Systems Update Loop) • Система делает дела в каждом кадре (или раунде)：PerceptionSystem собирает“восприятие”и записывает в компонент Perception (в основном краткосрочное не сохраняется в базу). ExperienceSystem записывает новый“когнитивный опыт”в Memory.experiences, если это ключевой опыт, возможно одновременно вызывать StateManager для немедленного хранения, или поставить标记“needsPersistence”для последующей пакетной записи. ThinkingSystem / ActionSystem / GoalPlanningSystem и т.д. принимают решения на основе содержания компонентов и обновляют поля в ECS. Если некоторые компоненты (например, Goal.current) претерпевают значительные изменения и требуют персистентности (например, новые долгосрочные цели), через监听 компонентов或события системы, уведомлять StateManager записать это поле в базу данных.

3. Периодическая或 событийно-управляемая персистентность (Periodic or Event-Driven) • Можно в некоторых ключевых точках в системе（например, когда план цели происходит обновление或Agent происходит важное событие）, вызывать интерфейс типа PersistenceManager.storeComponentData(eid, "Goal") для сохранения в базу. • Также можно в CleanupSystem或таймере, позволять StateManager сканировать компоненты或 сущности с标记“needsPersistence”,一次性 записать обратно в базу данных. • Кроме того,日志或审计 данные（например, история действий,日志 мышления）также можно здесь архивировать для хранения.

4. Выход或 сохранение точки останова (Manual or Shutdown Save) • Когда сервер或进程 должен закрыться, через StateManager.saveAll() единообразно записывать еще не записанные данные в базу данных, чтобы обеспечить восстановление состояния ECS при следующей загрузке. • Для некоторых сценариев单机/офлайн, также можно вручную触发 архивацию.

• Полный пример процесса

Ниже приведен простой сценарий, демонстрирующий возможный способ взаимодействия компонентов и базы данных：

1. При запуске：StateManager.queryDB("SELECT * FROM agents") → получить一批 agent записи, последовательно для каждой записи создавать Entity (EID=x), и инициализировать для него поля компонентов Agent, Memory, Goal и т.д. Одновременно загружать информацию о комнате из таблицы “rooms”, создавать сущность Room.

2. Этап выполнения：PerceptionSystem обнаруживает событие“появление MagicSword”в определенной комнате, записывать в Perception.currentStimuli[eid]. ExperienceSystem преобразует Stimuli в Experience, присваивать в 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(), записывать последние состояния ключевых полей компонентов（Agent, Memory, Goal и т.д.）, которые все еще в памяти, в базу данных. При следующем перезапуске, можно загружать из базы данных и восстанавливать состояние мира ECS.

• Классификация компонентов, как удобно четко управлять данными сущности в проекте, также может помочь нам контролировать границы данных“требующих персистентности”и“существующих только в памяти”. • Взаимодействие с базой данных обычно обрабатывается специальным Manager（например, StateManager）, Systems при необходимости чтения/записи базы данных操作 через него, избегая прямого написания SQL或类似底层语句 в System. • Таким образом можно одновременно наслаждаться эффективностью и гибкостью ECS в логике, а также преимуществами персистентности, продолжения с точки останова и статистического анализа данных,带来的 базой данных.

5. Инновационные архитектурные решения

• Изюминка всей архитектуры заключается в：

• Каждый System работает независимо, не будет иметь отношений вызова с другими System, поэтому даже если мы хотим реализовать способности Agent“восприятие изменений окружающей среды (Perception) → запись或 преобразование во внутренний опыт (Experience) → самостоятельное мышление и принятие решений (Thinking) → воплощение в действие (Action) → динамическая корректировка целей и планов (GoalPlanning + Planning) → синхронизация окружающей среды (Room) → своевременная утилизация бесполезных сущностей (Cleanup) ”, между различными System в функциональности будет много точек взаимозависимости, но мы все еще можем через архитектуру ECS структурировать общую структуру в различные не связанные между собой System, каждый System все еще может работать независимо, не будет иметьлюбой耦合 связи с другими System. Я думаю, это также причина, почему Unity в последние годы все больше мигрирует на архитектуру ECS.

• И например, если я сейчас просто хочу, чтобы один Agent обладал некоторыми базовыми возможностями, мне нужно только при определении Entity уменьшить регистрацию некоторых Component и уменьшить регистрацию System, можно легко реализовать, даже не нужно изменять несколько строк кода.

Как на рисунке ниже：

• Одновременно, если вы в процессе разработки希望 увеличить новые функции, также не будет никакого влияния на другие System, можно очень легко загрузить функции, которые вы希望. Кроме того, производительность текущей архитектуры на самом деле будет намного сильнее производительности традиционной объектно-ориентированной архитектуры, это общепризнанный факт в игровом圈, потому что дизайн ECS более подходит для выполнения параллельно, тогда когда мы в сложных сценариях Defai, использование архитектуры ECS также может иметь больше преимуществ, особенно в сценариях, где希望 использовать Agent для количественной торговли, ECS также будет иметь применение（не только в сценариях Agent игр）.

• Разделение System на сознательные, подсознательные и бессознательные для различения不同类型的 System должны выполняться через сколько времени, это чрезвычайно гениальный дизайн, уже очень конкретная способность человека

С моей личной точки зрения, это чрезвычайно модульный, производительность чрезвычайно отличная фреймворк, одновременно качество кода также очень высокое и включает очень хорошую документацию дизайна, но к сожалению $project89 проект一直缺少对这个框架的宣传, поэтому я потратил много времени (4 дня) на написание этой статьи, я думаю, хорошие вещи все еще стоят того, чтобы быть обнаруженными, завтра应该 еще выпущу английскую версию,希望能有更多的游戏团队或者 Defai 团队开到这个框架,为大家提供一种新的潜在的架构选择!