Reenviar Título Original: Veo el Marco de Agente de Próxima Generación en Project89

Para ir al grano, @project_89adopta un enfoque completamente nuevo para diseñar un Marco de Agente. Este es un Marco de Agente de alto rendimiento específicamente para el desarrollo de juegos. En comparación con los Marcos de Agente utilizados actualmente, es más modular y ofrece un mejor rendimiento.

Este artículo tomó mucho tiempo escribirlo, tratando de hacer que todos entiendan qué tipo de mejoras arquitectónicas ha realizado este marco en comparación con el marco tradicional del Agente. Ha sido revisado muchas veces antes de esta versión, pero todavía hay algunas partes en el artículo que son demasiado confusas. Debido a dificultades técnicas, no pude popularizarlo más. Si tienes alguna sugerencia para mejorar el artículo, por favor deja tus comentarios.

Antecedentes del desarrollador

Dado que se trata de un blog técnico, primero veamos la experiencia técnica del fundador.

Antes de trabajar en el Proyecto89, el fundador desarrolló este proyecto:https://github.com/Oneirocom/Magick, que también es un software de programación impulsado por IA. Además, Shaw ocupa el cuarto lugar como desarrollador principal de este proyecto. También puedes ver este proyecto en el portafolio de Shaw.

Superior izquierda: el fundador de project89; Inferior derecha: 'lalaune' es Shaw de ai16z

Hoy presentaremos principalmente el Framework de Agente de alto rendimiento en project89:

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

1. ¿Por qué usar ECS para diseñar un marco de agente?

Desde la perspectiva de la aplicación en el campo de juego

Los juegos que actualmente utilizan la arquitectura ECS incluyen:

Juegos de blockchain: Mud, Dojo

Juegos tradicionales: Overwatch, Star Citizen, etc.

Además, los motores de juego principales están evolucionando hacia la arquitectura ECS, como Unity.

¿Qué es ECS?

ECS (Entity-Component-System) es un patrón arquitectónico comúnmente utilizado en el desarrollo de juegos y sistemas de simulación. Separa por completo los datos y la lógica para gestionar eficientemente varias entidades y sus comportamientos en escenarios escalables a gran escala:

Entidad

• Solo un ID (número o cadena), sin contener datos ni lógica.

• Puede montar diferentes componentes para darle diversas propiedades o capacidades según sea necesario.

Componente

• Utilizado para almacenar datos específicos o el estado de una entidad.

Sistema

• Responsable de ejecutar la lógica relacionada con ciertos componentes.

Usemos un ejemplo específico de la acción del Agente para entender este sistema:

En ArgOS, cada Agente es considerado como una Entidad, la cual puede registrar diferentes componentes. Por ejemplo, en la imagen de abajo, nuestro Agente tiene los siguientes cuatro componentes:

Componente del Agente: almacena principalmente información básica como el nombre del Agente, el nombre del modelo, etc.

Componente de Percepción: Principalmente utilizado para almacenar datos externos percibidos

Componente de memoria: Principalmente utilizado para almacenar los datos de memoria de la Entidad Agente, cosas similares que se hayan hecho, etc.

Componente de Acción: Almacena principalmente los datos de Acción a ejecutar

Flujo de trabajo del sistema:

1. En este juego, por ejemplo, si percibes un arma frente a ti, se llamará a la función de ejecución del Sistema de Percepción para actualizar los datos en el Componente de Percepción de la Entidad del Agente.
2. Luego activa el Sistema de Memoria, llama al Componente de Percepción y al Componente de Memoria al mismo tiempo, y guarda los datos percibidos en la base de datos a través de la Memoria.
3. Luego, el Sistema de Acción llama al Componente de Memoria y al Componente de Acción para obtener información del entorno circundante de la memoria y, finalmente, ejecutar la acción correspondiente.

Entonces obtenemos una Entidad de Agente de Actualización en la que se actualizan los datos de cada componente.

4. Por lo tanto, podemos ver que el Sistema aquí es principalmente responsable de definir qué Componentes ejecutarán la lógica de procesamiento correspondiente.

Y es obvio que en el proyecto89 es un mundo lleno de varios tipos de Agentes. Por ejemplo, algunos Agentes no solo tienen las habilidades básicas mencionadas anteriormente, sino que también tienen la capacidad de hacer planes.

Luego se mostrará como se muestra en la imagen a continuación:

Flujo de Ejecución del Sistema

Sin embargo, a diferencia de los marcos tradicionales donde un sistema activa directamente a otro (por ejemplo, el Sistema de Percepción llamando al Sistema de Memoria), en Project89, los sistemas no se llaman directamente entre sí. En su lugar, cada sistema se ejecuta de forma independiente en intervalos de tiempo fijos. Por ejemplo:

• El sistema de percepción se ejecuta cada 2 segundos para actualizar el componente de percepción con los datos ambientales recién recibidos.
• El Sistema de Memoria se ejecuta cada 1 segundo, extrayendo datos del Componente de Percepción y almacenándolos en el Componente de Memoria.
• El sistema Plan se ejecuta cada 1000 segundos, analizando los datos recopilados para determinar si necesita optimizarse y crear un nuevo plan, que luego se registra en el componente Plan.
• El sistema de Acción se ejecuta cada 2 segundos, respondiendo a los cambios ambientales y modificando las acciones en función de las actualizaciones del Componente de Planificación.

Hasta ahora, este artículo ha simplificado significativamente la arquitectura de ArgOS para que sea más fácil de entender. Ahora, echemos un vistazo más de cerca al sistema real de ArgOS.

2. Arquitectura del sistema ArgOS

Para permitir que el Agente piense más profundamente y realice tareas más complejas, ArgOS ha diseñado muchos Componentes y muchos Sistemas.

Y ArgOS divide System en "tres niveles" (ConsciousnessLevel):

1) sistema CONSCIOUS

• Incluye RoomSystem, PerceptionSystem, ExperienceSystem, ThinkingSystem, ActionSystem, CleanupSystem)
• La frecuencia de actualización suele ser más alta (como cada 10 segundos).
• Procesamiento más cercano al nivel "en tiempo real" o "consciente", como la percepción ambiental, el pensamiento en tiempo real, la ejecución de acciones, etc.

2) Sistema subconsciente (SUBCONSCIENTE)

• Sistema de Planificación de Objetivos, Sistema de Planificación
• La frecuencia de actualización es relativamente baja (por ejemplo, cada 25 segundos).
• Maneja la lógica de "pensamiento", como verificar/generar periódicamente metas y planes.

3) Sistema inconsciente (UNCONSCIOUS)

• Todavía no habilitado
• La frecuencia de actualización es más lenta (como más de 50 segundos),

Por lo tanto, en ArgOS, los distintos Sistemas se dividen según el Nivel de Conciencia para estipular con qué frecuencia se ejecutará dicho Sistema.

¿Por qué está diseñado de esta manera?

Debido a que la relación entre varios sistemas en ArgOS es extremadamente compleja, como se muestra a continuación:

1. El sistema de percepción es responsable de recolectar 'estímulos' del mundo exterior u otras entidades y actualizarlos en el componente de percepción del Agente.

Determinar si el estímulo cambia significativamente y actualizarlo en consecuencia según la estabilidad, el modo de procesamiento (ACTIVO/REFLEXIVO/ESPERA), etc.

En última instancia, se proporcionan datos de "percepción actual" para el subsiguiente ExperienceSystem, ThinkingSystem, etc.

2. El Sistema de Experiencia convierte los Estímulos recopilados por el Sistema de Percepción en una experiencia más abstracta.

LLM o lógica de reglas (extractExperiences) se llama para identificar nuevas experiencias y almacenarlas en el componente de Memoria.

Deduplicar, filtrar y verificar experiencias, al tiempo que se activan eventos de "experiencia" en otros sistemas o escuchantes externos a través del eventBus.

3. ThinkingSystem representa el proceso de pensamiento interno del agente.

Extrae el estado actual de componentes como la Memoria y la Percepción, y genera "ThoughtResult" a través de generateThought(...) y lógica LLM/regla.

Basado en el resultado del pensamiento, puede:

• Actualizar pensamientos en la Memoria (historial de pensamiento).

• Activar una nueva acción (colocar en Action.pendingAction[eid]).

• Cambiar la Apariencia externa del agente (expresión, postura, etc.) y generar Estímulos relacionados para que otras entidades puedan "ver" el cambio.

4. El sistema de acciones ejecuta acciones si Action.pendingActionno está vacío, usandoruntime.getActionManager().executeAction(…).

Después de la ejecución, escriba el resultado en Action.lastActionResult y notifique a la sala u otras entidades.

Esto también produce un EstímuloCognitivo (estimulación cognitiva) para que los sistemas posteriores “sepan” que la acción se ha completado o se pueda incorporar a la memoria.

5. El sistema de planificación de metas evalúa periódicamente el progreso de las metas en la lista de metas actuales[eid], o verifica la memoria externa/propia en busca de cambios significativos (detectSignificantChanges).

Cuando se requiere una nueva meta o ajuste de meta, genere y escriba Goal.current[eid] a través de generateGoals(...)

Al mismo tiempo, el objetivo en progreso (in_progress) se actualiza. Si se cumplen las condiciones de finalización o fracaso, se cambia el estado y se envía una señal de finalización/fracaso al Plan correspondiente.

6. El sistema de planificación genera o actualiza el plan (plan de ejecución) para el "objetivo existente" (Goal.current[eid]).

Si se detecta que algunos objetivos no tienen planes activos correspondientes, genere un plan de ejecución que contenga varios pasos a través de generatePlan(...) y escríbalo en Plan.plans[eid].

Cuando se completa o falla el objetivo, también se actualizará el estado del Plan asociado a él y se generará la estimulación cognitiva correspondiente.

7.RoomSystem maneja actualizaciones relacionadas con la habitación:

• Obtener la lista de ocupantes en la habitación (ocupantes) y generar estímulos de “apariencia” para cada agente para permitir que otras entidades “vean” su apariencia o acciones.

• Crear y correlacionar el estímulo del entorno de la habitación (por ejemplo, información adecuada sobre la "ambiente de la habitación").

Asegúrate de que cuando el Agente esté en un entorno espacial específico, otras entidades que estén sintiendo el espacio puedan percibir cambios en su apariencia.

8.CleanupSystem encuentra y elimina periódicamente entidades marcadas con el componente de limpieza. Se utiliza para reciclar Estímulo u otros objetos que ya no son necesarios para evitar que un gran número de entidades inválidas queden en ECS.

• Ejemplo: un bucle desde 'ver el objeto' hasta 'realizar la acción'

El siguiente ejemplo de escena muestra cómo cada sistema coopera para completar un proceso completo en una ronda (o varios fotogramas).

Preparación de la escena: Hay un Agente (EID=1) en el Mundo, que está en estado 'Activo' y se encuentra en una Habitación (EID=100).

Una nueva prop “MagicSword” apareció en esta Sala, y se generó el Estímulo correspondiente.

1. PerceptionSystem detecta la aparición de "MagicSword", genera Stimulus (type="item_appearance") para Agent(1) y lo añade a Perception.currentStimuli[1]. En comparación con el último Hash de Estímulos, se determina que hay un "cambio significativo" y el Estado de Procesamiento del agente se "reactiva" (modo ACTIVO).
2. ExperienceSystem ve que Perception.currentStimuli del Agente(1) no está vacío, por lo que extrae información como “Sword appears” en una o más nuevas Experiencias (tipo: “observación”). Almacénalo en Memory.experiences[1] y emite el evento “experiencia”.
3. ThinkingSystem lee la memoria, percepción y otra información de estado y llama a generarPensamiento:

“Vi la MagicSword, tal vez la recoja y vea qué puede hacer…” El resultado del pensamiento contiene una Acción a ejecutar: { herramienta: “recogerObjeto”, parámetros: { nombreObjeto: “MagicSword” } }

ThinkingSystem escribe esta Acción en Action.pendingAction[1].

Si hay un cambio en la apariencia (por ejemplo, 'cara con expresión curiosa'), se actualiza la Apariencia y se genera estimulación visual.

4. El sistema de ActionSystem ve Action.pendingAction[1] = { tool: “pickUpItem”, parameters: … }。

Ejecute la lógica de la acción 'pickup' a través de runtime.getActionManager().executeAction('pickUpItem', 1, { itemName: 'MagicSword' }, runtime). Obtenga el resultado: { success: true, message: 'Has recogido la espada mágica' }, actualice a Action.lastActionResult[1] y active el evento 'action' para que se transmita a la habitación (100).

Al mismo tiempo, se genera un estímulo cognitivo (type=”action_result”), se escribe en la Memoria o se captura por el ThinkingSystem en el siguiente turno.

5. El Sistema de Planificación de Objetivos (si el agente tiene objetivos) evalúa periódicamente los objetivos del agente. Si uno de los objetivos del agente en este momento es "obtener un arma poderosa" y detecta que se ha obtenido la Espada Mágica, el objetivo puede ser marcado como completado. Si ocurren cambios nuevos (por ejemplo, "aparece un nuevo objeto en la habitación") que afecten al objetivo perseguido por el agente, generar un nuevo objetivo o abandonar el objetivo antiguo según detecte cambios significativos.
6.PlanningSystem (si hay un objetivo relacionado) verifica si se requiere un nuevo Plan o se actualiza un Plan existente para objetivos completados o recién generados como "Obtener armas poderosas".

Si se completa, establezca el Plan asociado [status] en "completado", o genere más pasos si el objetivo es expandir el proceso posterior ("Investigar la Espada Mágica").

7. RoomSystem actualiza la lista de ocupantes y entidades visibles en la habitación (100) (en cada fotograma o ronda).

Si la apariencia del agente (1) cambia (por ejemplo, Appearance.currentAction = “holding sword”), crea un nuevo estímulo visual de “apariencia” para que otros Agent2 y Agent3 en la misma habitación sepan que “el agente1 recogió la espada”.

8. CleanupSystem elimina entidades o estímulos que han sido marcados (Limpieza). Si ya no necesitas mantener el Estímulo "MagicSword" después de recogerlo, puedes eliminar la entidad de Estímulo correspondiente en CleanupSystem.

1. A través de la conexión de estos sistemas, AI Agent logra:

• Percibir cambios en el entorno (Percepción) → Registrar o transformar en experiencia interna (Experiencia) → Auto-pensamiento y toma de decisiones (Pensamiento) → Ponerlo en acción (Acción) → Ajustar dinámicamente objetivos y planes (Planificación de Objetivos + Planificación) → Sincronizar el entorno (Puerta) → Reciclar a tiempo entidades inútiles (Limpieza)

3. Análisis de la arquitectura general de ArgOS

1. Capas de arquitectura central

2. Clasificación de componentes

En ECS, cada entidad puede tener varios componentes. Según su naturaleza y ciclo de vida en el sistema, los componentes se pueden dividir aproximadamente en las siguientes categorías:

1. Clases de Identidad Central (Componentes a Nivel de Identidad)

• Agente / Perfil de jugador / Perfil de NPC, etc.

• Utilizado para identificar de manera única entidades, almacenar roles principales o información de unidades, y generalmente deben persistir en la base de datos.

2.Componentes de Comportamiento y Estado

• Acción, Objetivo, Plan, Estado de Procesamiento, etc.

• Representa lo que la entidad está intentando hacer o cuáles son sus objetivos actuales, así como su estado de respuesta a los comandos externos y el pensamiento interno.

• Contiene pendingAction, goalsInProgress, planes y pensamientos o tareas en la cola, etc.

• Normalmente estados a medio/corto plazo, muchos cambian dinámicamente a lo largo de las rondas del juego o ciclos comerciales.

• Si es necesario hacer inventario depende de la situación. Si desea continuar ejecutando después de un punto de interrupción, puede escribir en la base de datos periódicamente.

3. Componentes de Percepción y Memoria

• Percepción, Memoria, Estímulo, Experiencia, etc.

• Registra la información externa (Estímulos) percibida por la entidad y las experiencias refinadas en ella después de la percepción (Experiencias).

• La memoria a menudo puede acumular grandes cantidades de datos, como registros de conversaciones, historial de eventos, etc.; a menudo se requiere persistencia.

• La percepción puede ser información en tiempo real o temporal, en su mayoría válida a corto plazo. Puedes decidir si escribirla en la base de datos según tus necesidades (por ejemplo, solo se almacenan eventos de percepción importantes).

4. Clases de entorno y espacio (Room, OccupiesRoom, Spatial, Environment, Inventory, etc.)

• Representa información como habitaciones, entornos, ubicaciones, contenedores de objetos, etc.

•Room.id, Los campos de OcupaHabitación, Ambiente y otros a menudo necesitan ser persistidos, como la descripción de la página de inicio de la habitación, la estructura del mapa, etc.

• Cambiar componentes (como una Entidad que se mueve entre habitaciones) puede ser escrito evento a evento o periódicamente.

5. Clases de apariencia e interacción (Appearance, UIState, Relationship, etc.)

• Registrar las partes externas "visibles" o "interactivas" de la entidad, como Avatar, pose, expresión facial, red de relaciones sociales con otras entidades, etc.

• Algunas partes pueden ser procesadas solo en la memoria (representación en tiempo real), mientras que otras partes (como las relaciones sociales clave) pueden persistir.

6.Componentes de Utilidad y Mantenimiento (Limpieza, DebugInfo, Datos de Perfil, etc.)

• Se utiliza para marcar qué entidades deben ser recicladas (Cleanup), o para registrar información de depuración (DebugInfo) para su uso en monitoreo y análisis.

• Típicamente solo existe en memoria y rara vez se sincroniza con la base de datos a menos que sea necesario para el registro o la auditoría.

3. Arquitectura del sistema

Ya se ha introducido anteriormente

4. Manager Architecture

Además de los Componentes y Sistemas, se requiere una capa adicional de gestión de recursos. Esta capa se encarga del acceso a la base de datos, los conflictos de estado y otras operaciones esenciales.

Lado izquierdo: Sistemas (Sistema de percepción, Sistema de experiencia, Sistema de pensamiento, etc.):

• Cada sistema está programado para su ejecución por SimulationRuntime en el bucle ECS, consultando y procesando las entidades de las que se preocupa (a través de condiciones de componentes).

• Al ejecutar la lógica, necesitas interactuar con los Managers, por ejemplo:

• Llame a RoomManager (RM) para consultar/actualizar la información de la habitación.
• Usa StateManager (SM) para obtener o guardar el estado del mundo/agente, como la Memoria, la Meta, el Plan, etc.
• Transmita o escuche eventos externamente utilizando EventBus (EB).
• PromptManager (PM) se llama cuando se requiere procesamiento de lenguaje natural o sugerencias.

Lado derecho: Managers (EventBus, RoomManager, StateManager, EventManager, ActionManager, PromptManager, etc):

• Proporcionar funciones a nivel de sistema, que básicamente no "impulsan" activamente la lógica, sino que son llamadas por Systems o Runtime.

• Ejemplos típicos:

• ActionManager se especializa en gestionar el registro y la ejecución de acciones.
• EventManager / EventBus se utiliza para los mecanismos de publicación y suscripción de eventos.
• RoomManager gestiona habitaciones, diseños y ocupantes.
• StateManager es responsable de la sincronización entre ECS y la base de datos o el almacenamiento.
• PromptManager proporciona extensiones como plantillas de LLM Prompt y gestión de contexto.
• SimulaciónIntermediaRuntime (R):

• Es el “programador” de todos los Sistemas, iniciando o deteniendo ciclos del sistema en diferentes niveles (Consciente/Subconsciente, etc.);

• Los gerentes también se crean durante la fase de construcción y se pasan a cada Sistema para su uso.

• CleanupSystem:

• Tenga en cuenta en particular que también interactúa con ComponentSync (CS), que se utiliza para eliminar sincrónicamente componentes o suscripciones a eventos al reciclar entidades.

En conclusión:

Cada Sistema leerá y escribirá datos o llamará a los servicios a través del Manager correspondiente cuando sea necesario, y el Runtime programará uniformemente el ciclo de vida y el comportamiento de todos los Sistemas y Managers a un nivel superior.

5. Cómo interactúan los vectores y las bases de datos en ECS

En un sistema ECS, los sistemas manejan la ejecución real de la lógica, mientras que las operaciones de base de datos (lectura / escritura) son gestionadas a través de un Administrador de Persistencia (PersistenceManager / DatabaseManager) o un Administrador de Estado (StateManager). El proceso general es el siguiente:

1. Carga inicial (fase de inicio o carga)

• StateManager / PersistenceManager carga los datos de los componentes de persistencia principales como Agentes, Habitaciones, Metas, etc. desde la base de datos, crea entidades correspondientes (Entidades) e inicializa los campos de componentes relacionados.

• Por ejemplo, lea un lote de registros de agentes e insértelos en el mundo ECS, e inicialice el Agente, la Memoria, la Meta y otros componentes para ellos.

2. Tiempo de ejecución de ECS (Bucle de actualización de sistemas)

• El sistema hace cosas en cada fotograma (o ronda): PerceptionSystem recopila "percepciones" y las escribe en el componente Perception (principalmente a corto plazo fuera de la biblioteca).

ExperienceSystem escribe la nueva experiencia cognitiva en Memory.experiences. Si es una experiencia clave, también puede llamar a StateManager para su almacenamiento inmediato o marcarla con “needsPersistence” para su escritura en lotes posterior.

ThinkingSystem / ActionSystem / GoalPlanningSystem, etc. toman decisiones basadas en el contenido de los componentes y actualizan los campos en ECS.

Si algunos componentes (como Goal.current) experimentan cambios importantes y requieren persistencia (como un nuevo objetivo a largo plazo), notifique al StateManager para que escriba este campo en la base de datos a través de la escucha de componentes o eventos del sistema.

3. Persistencia periódica o basada en eventos

• Puede llamar a interfaces como PersistenceManager.storeComponentData(eid, “Goal”) para dejar la biblioteca en ciertos puntos clave del sistema (como cuando se actualiza el plan objetivo o cuando ocurre un evento importante en el Agente).

• También puede hacer que StateManager escanee componentes o entidades con la etiqueta “needsPersistence” en CleanupSystem o temporizador, y escribirlos de una sola vez en la base de datos.

• Además, los datos de registro o auditoría (como el historial de acciones, el registro de pensamientos) también se pueden archivar y almacenar aquí.

4. Manual o Guardado de Apagado (Checkpointing y Persistencia al Salir)

• Cuando el servidor o el proceso se van a apagar, use StateManager.saveAll() para escribir los datos no escritos en la base de datos de manera uniforme, asegurando que el estado del ECS pueda ser restaurado la próxima vez que se cargue.

• Para algunos escenarios independientes/desconectados, los archivos también se pueden activar manualmente.

• Proceso de muestra completo

A continuación se presenta un escenario simple para demostrar las posibles formas en que los componentes y las bases de datos interactúan:

1. Fase de inicio: StateManager.queryDB("SELECT * FROM agents") → Obtenga un lote de registros de agentes, cree una entidad (EID=x) para cada registro a su turno, e inicialice los campos del agente, memoria, objetivo y otros componentes.

Al mismo tiempo, cargar información de la habitación desde la tabla "rooms" y crear una entidad de Room.

2. Operaciones en tiempo de ejecución: PerceptionSystem detecta el evento 'aparición de MagicSword' en una cierta habitación y escribe Perception.currentStimuli[eid]. ExperienceSystem convierte los estímulos en Experiencia y los asigna a Memory.experiences[eid]. ThinkingSystem determina la próxima acción basada en Memory, Goal y otra información y genera Action.pendingAction[eid]. Después de que ActionSystem ejecuta la acción, escribe el resultado en Memory o Action.lastActionResult. Si este es un evento principal de la trama, la última parte de Memory.experiences[eid] se marcará como needsPersistence. Después de un tiempo, StateManager encuentra que Memory.experiences[eid] tiene 'needsPersistence' y lo escribe en la base de datos (INSERT INTO memory_experiences...).

3. Detener o guardar el punto de control: Basado en la programación de ECS o del sistema, se llama a StateManager.saveAll() cuando se "apaga el servidor" para escribir el estado más reciente de los campos de los componentes clave (Agente, Memoria, Objetivo, etc.) todavía en memoria en la base de datos. La próxima vez que se reinicie, el estado del mundo ECS se puede cargar y restaurar desde la base de datos.

• La categorización de componentes no solo facilita la gestión clara de los datos de la entidad en el proyecto, sino que también nos ayuda a controlar los límites de los datos entre "requiere persistencia" y "solo existe en memoria".

• La interacción con la base de datos generalmente la maneja un Manager especializado (como StateManager), y los Sistemas operan a través de él cuando necesitan leer y escribir en la base de datos, evitando escribir directamente SQL u otras declaraciones de bajo nivel en el Sistema.

• De esta manera, puedes disfrutar simultáneamente de la eficiencia lógica y la flexibilidad de ECS, así como de las ventajas de la persistencia, la reanudación de puntos de interrupción y el análisis estadístico de datos que ofrece la base de datos.

4. Innovaciones arquitectónicas

Los aspectos más destacados de toda la arquitectura son:

• Cada sistema funciona de forma independiente y no tiene ninguna relación de llamada con otros sistemas. Por lo tanto, incluso si queremos implementar las capacidades del Agente para "percibir cambios en el entorno (Percepción) → Registrar o transformar en experiencia interna (Experiencia) → Pensar y tomar decisiones por sí mismo (Pensamiento) → Ponerlo en acción (Acción) → Ajustar dinámicamente metas y planes (Planificación de objetivos + Planificación) → Sincronizar el entorno (Habitación) → Reciclar entidades inútiles a tiempo (Limpieza)" , cada sistema tendrá muchas interdependencias en función, pero aún podemos usar la arquitectura ECS para estructurar el conjunto en sistemas independientes. Cada sistema aún puede funcionar de forma independiente y no interactuará con otros sistemas. Hay personas y relaciones de acoplamiento.
• Creo que esta es también la razón principal por la que Unity ha migrado cada vez más a la arquitectura ECS en los últimos años.
• Y por ejemplo, solo quiero que un Agente tenga algunas capacidades básicas. Solo necesito reducir el registro de algunos Componentes y el registro del Sistema al definir la Entidad, lo cual se puede lograr fácilmente sin cambiar unas pocas líneas de código.

Como se muestra a continuación:

Al mismo tiempo, si desea agregar nuevas funciones durante el proceso de desarrollo, no tendrá ningún impacto en otros sistemas y podrá cargar fácilmente las funciones que desee.

• Además, el rendimiento de la arquitectura actual es en realidad mucho mejor que el de la arquitectura orientada a objetos tradicional. Esto es un hecho reconocido en el círculo de los juegos, porque el diseño de ECS es más adecuado para la concurrencia, por lo que cuando usamos ECS en escenarios complejos de Defai, la arquitectura también puede tener más ventajas, especialmente en escenarios donde se espera que se utilicen agentes para transacciones cuantitativas, ECS también será útil (no solo en escenarios de juegos de agentes).
• Dividir el sistema en consciente, subconsciente e inconsciente para distinguir con qué frecuencia se deben ejecutar diferentes tipos de sistemas es un diseño extremadamente inteligente y ya es una habilidad humana muy concreta.

Desde mi punto de vista personal, este es un marco extremadamente modular con un excelente rendimiento. La calidad del código también es muy alta y contiene buenos documentos de diseño. Desafortunadamente, Project89 ha carecido de visibilidad y promoción para este marco, por lo que pasé cuatro días escribiendo este artículo para resaltar sus fortalezas. Creo que las grandes tecnologías merecen reconocimiento y mañana planeo lanzar una versión en inglés de este artículo para aumentar la conciencia entre los equipos de juegos y los desarrolladores de DeFi (Finanzas Descentralizadas). ¡Ojalá más equipos exploren este marco como una posible elección arquitectónica para sus proyectos!

Descargo de responsabilidad:

1. Este artículo es reproducido de [0xhhh]. Reenvíe el título original: Veo el marco de agente de próxima generación en Project89. Los derechos de autor pertenecen al autor original [0xhhh]. Si tiene alguna objeción a la reimpresión, por favor póngase en contacto Gate Learnequipo, el equipo lo manejará lo antes posible de acuerdo con los procedimientos relevantes.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo representan únicamente las opiniones personales del autor y no constituyen consejos de inversión.
3. Otras versiones en otros idiomas del artículo son traducidas por el equipo de Aprender de Gate. A menos que se indique lo contrario, el artículo traducido no puede ser copiado, distribuido o plagiado.