Transférer le titre original : Je vois le cadre d’agent de la prochaine génération dans le projet89

Pour aller droit au but, @project_89adopte une approche entièrement nouvelle pour concevoir un cadre d’agent. Il s’agit d’un cadre d’agent haute performance spécifiquement pour le développement de jeux. Par rapport aux cadres d’agent actuellement utilisés, il est plus modulaire et offre de meilleures performances.

Cet article a pris beaucoup de temps à rédiger, essayant de permettre à tous de comprendre quelles mises à niveau architecturales ce framework a apportées par rapport au framework Agent traditionnel. Il a été révisé plusieurs fois avant cette version, mais il y a encore des parties de l’article qui sont trop confuses. En raison de difficultés techniques, je n’ai pas pu le populariser davantage. Si vous avez des suggestions pour améliorer l’article, veuillez laisser vos commentaires.

Antécédents du développeur

Étant donné que c’est un blog technique, regardons d’abord l’expertise technique du fondateur.

Avant de travailler sur le Projet89, le fondateur a développé ce projet : https://github.com/Oneirocom/Magick, qui est également un logiciel de programmation alimenté par l’IA. De plus, Shaw est classé quatrième développeur de ce projet. Vous pouvez également voir ce projet dans le portefeuille de Shaw.

En haut à gauche: le fondateur de project89; En bas à droite: ‘lalaune’ est Shaw d’ai16z

Aujourd’hui, nous allons principalement présenter le Framework Agent haute performance dans le projet89 :

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

1. Pourquoi utiliser ECS pour concevoir un framework d’agent?

Du point de vue de l’application dans le domaine des jeux

Les jeux utilisant actuellement l’architecture ECS comprennent :

Jeux blockchain : Mud, Dojo

Jeux traditionnels : Overwatch, Star Citizen, etc.

De plus, les moteurs de jeu grand public évoluent vers une architecture ECS, tels que Unity.

Qu’est-ce que ECS?

ECS (Entity-Component-System) est un modèle architectural couramment utilisé dans le développement de jeux et les systèmes de simulation. Il sépare complètement les données et la logique pour gérer efficacement les différentes entités et leurs comportements dans des scénarios à grande échelle et évolutifs :

Entité

• Juste un identifiant (numéro ou chaîne de caractères), ne contenant aucune donnée ou logique.

• Vous pouvez monter différents composants pour lui donner différentes propriétés ou capacités selon les besoins.

Composant

• Utilisé pour stocker des données spécifiques ou l’état d’une entité.

Système

• Responsable de l’exécution de la logique liée à certains composants.

Utilisons un exemple spécifique d’action de l’Agent pour comprendre ce système :

Dans ArgOS, chaque Agent est considéré comme une Entité, qui peut enregistrer différents composants. Par exemple, dans l’image ci-dessous, notre Agent a les quatre composants suivants :

Composant Agent: stocke principalement des informations de base telles que le nom de l’Agent, le nom du modèle, etc.

Composant de perception : principalement utilisé pour stocker les données externes perçues

Composant de mémoire : principalement utilisé pour stocker les données de mémoire de l’entité agent, les choses similaires qui ont été réalisées, etc.

Composant d’action : Stocke principalement les données d’action à exécuter

Flux de travail du système :

1. Dans ce jeu, par exemple, si vous détectez une arme devant vous, alors la fonction d’exécution du Système de perception sera appelée pour mettre à jour les données dans le composant de perception de l’entité de l’agent.
2. Déclenchez ensuite le système de mémoire, appelez simultanément le composant Perception et le composant Mémoire, et persistez les données perçues dans la base de données via la Mémoire.
3. Ensuite, le système d’action appelle le composant de mémoire et le composant d’action pour obtenir les informations environnementales environnantes à partir de la mémoire, puis exécute finalement l’action correspondante.

Ensuite, nous obtenons une Entité d’Agent de Mise à Jour dans laquelle chaque donnée de Composant est mise à jour.

4. Donc, nous pouvons voir que le système ici est principalement responsable de définir quelles composantes exécutent la logique de traitement correspondante.

Et il est évident que dans project89, c’est un monde rempli de différents types d’Agents. Par exemple, certains Agents ont non seulement les capacités de base mentionnées ci-dessus, mais ont également la capacité de faire des plans.

Alors ce sera comme indiqué sur l’image ci-dessous :

Flux d’exécution du système

Cependant, contrairement aux frameworks traditionnels où un système déclenche directement un autre (par exemple, le système de perception appelant le système de mémoire), dans le Projet89, les systèmes ne s’appellent pas directement les uns les autres. Au lieu de cela, chaque système s’exécute indépendamment à des intervalles de temps fixes. Par exemple :

• Le système de perception s’exécute toutes les 2 secondes pour mettre à jour le composant de perception avec les données environnementales nouvellement reçues.
• Le système de mémoire s’exécute toutes les 1 seconde, extrayant des données du composant de perception et les stockant dans le composant de mémoire.
• Le système de planification s’exécute toutes les 1000 secondes, analyse les données collectées pour déterminer s’il doit optimiser et créer un nouveau plan, qui est ensuite enregistré dans le composant de planification.
• Le système d’action s’exécute toutes les 2 secondes, répondant aux changements environnementaux et modifiant les actions en fonction des mises à jour du composant de planification.

Jusqu’à présent, cet article a considérablement simplifié l’architecture d’ArgOS pour la rendre plus facile à comprendre. Maintenant, examinons de plus près le véritable système ArgOS.

2. Architecture du système ArgOS

Afin de permettre à l’Agent de réfléchir plus profondément et d’accomplir des tâches plus complexes, ArgOS a conçu de nombreux Composants et de nombreux Systèmes.

Et ArgOS divise le système en “trois niveaux” (Niveau de conscience):

1) système CONSCIENT

• Comprend RoomSystem, PerceptionSystem, ExperienceSystem, ThinkingSystem, ActionSystem, CleanupSystem)
• La fréquence de mise à jour est généralement plus élevée (comme toutes les 10 secondes).
• Traitement plus proche du niveau “temps réel” ou “conscient”, tel que la perception environnementale, la pensée en temps réel, l’exécution des actions, etc.

2) Système Subconscient (SUBCONSCIENT)

• Système de planification des objectifs, Système de planification
• La fréquence de mise à jour est relativement faible (par exemple toutes les 25 secondes).
• Gère la logique de “réflexion”, telle que la vérification/génération périodique des objectifs et des plans.

3) Système inconscient (INCONSCIOUS)

• Pas encore activé
• La fréquence de mise à jour est plus lente (par exemple plus de 50 secondes),

Par conséquent, dans ArgOS, différents systèmes sont divisés en fonction du niveau de conscience pour stipuler à quelle fréquence ce système sera exécuté.

Pourquoi est-il conçu de cette manière?

Parce que la relation entre les différents systèmes dans ArgOS est extrêmement complexe, comme le montre ci-dessous :

1. Le PerceptionSystem est responsable de collecter des « stimuli » du monde extérieur ou d’autres entités et de les mettre à jour dans le composant Perception de l’Agent.

Déterminer si le stimulus change de manière significative et mettre à jour en conséquence en fonction de la stabilité, du mode de traitement (ACTIF/RÉFLECTIF/EN ATTENTE), etc.

En fin de compte, des données de « perception actuelle » sont fournies pour les systèmes ultérieurs d’expérience, de réflexion, etc.

2.ExperienceSystem convertit les stimuli collectés par PerceptionSystem en une « expérience » plus abstraite.

La logique LLM ou règle (extractExperiences) est appelée pour identifier de nouvelles expériences et les stocker dans le composant Memory.

Dédoublonnez, filtrez et vérifiez les expériences, tout en déclenchant des événements «expérience» vers d’autres systèmes ou des écouteurs externes via eventBus.

3. ThinkingSystem représente le processus de réflexion interne de l’agent.

Extraire l’état actuel des composants tels que la Mémoire et la Perception, et générer le “ThoughtResult” grâce à la génération de la pensée (…) et à la logique LLM/règle.

En fonction du résultat de la réflexion, cela peut :

• Mettre à jour les pensées dans la mémoire (historique des réflexions).

• Déclencher une nouvelle action (mettre dans Action.pendingAction[eid]).

• Modifier l’apparence externe de l’agent (expression, posture, etc.) et générer des stimuli connexes pour permettre à d’autres entités de «voir» le changement.

4. Le système d’action exécute des actions siAction.pendingActionn’est pas vide, en utilisantruntime.getActionManager().executeAction(…).

Après l’exécution, écrivez le résultat dans Action.lastActionResult et notifiez la salle ou d’autres entités.

Cela produit également un CognitiveStimulus (stimulation cognitive) de sorte que les systèmes ultérieurs ‘sachent’ que l’action a été achevée, ou peut être incorporée dans la mémoire.

5.GoalPlanningSystem évalue périodiquement la progression des objectifs de la liste Goal.current[eid] ou vérifie la mémoire externe/propre pour détecter les changements significatifs (detectSignificant Changes).

Lorsqu’un nouvel objectif ou un ajustement d’objectif est requis, générer et écrire Goal.current[eid] via generateGoals(…).

En même temps, l’objectif en cours (in_progress) est mis à jour. Si les conditions de réussite ou d’échec sont remplies, le statut est modifié et un signal de réussite/échec est envoyé au Plan correspondant.

6.PlanningSystem génère ou met à jour le plan (plan d’exécution) pour le “but existant” (Goal.current[eid]).

S’il est détecté que certains objectifs n’ont pas de plans actifs correspondants, générer une feuille de route d’exécution contenant plusieurs étapes via generatePlan(…) et l’écrire dans Plan.plans[eid].

Lorsque l’objectif est atteint ou échoué, le statut du plan associé sera également mis à jour et une stimulation cognitive correspondante sera générée.

7. Le système de gestion des chambres gère les mises à jour liées aux chambres:

• Obtenir la liste des occupants de la chambre (occupants) et générer des stimuli “d’apparence” pour chaque agent afin de permettre à d’autres entités de “voir” son apparence ou ses actions.

• Créez et corrélez les stimuli de l’environnement de la pièce (par exemple, des informations appropriées sur l’« ambiance de la pièce »).

Veillez à ce que lorsque l’Agent se trouve dans un certain environnement spatial, d’autres entités qui perçoivent l’espace puissent percevoir des changements dans son apparence.

8.CleanupSystem trouve périodiquement et supprime les entités marquées avec le composant Cleanup. Utilisé pour recycler les Stimulus ou d’autres objets qui ne sont plus nécessaires afin d’éviter qu’un grand nombre d’entités invalides ne restent dans ECS.

• Exemple : une boucle de « voir l’objet » à « effectuer l’action »

L’exemple de scène suivant montre comment chaque système coopère pour compléter un processus complet en une seule ronde (ou plusieurs images).

Préparation de la scène : Il y a un Agent (EID=1) dans le Monde, qui est dans l’état “Actif” et est dans une Pièce (EID=100).

Une nouvelle propriété “MagicSword” est apparue dans cette pièce, et le stimulus correspondant a été généré.

1. PerceptionSystem détecte l’apparition de “MagicSword”, génère un Stimulus (type=”item_appearance”) pour l’Agent(1) et l’ajoute à Perception.currentStimuli[1]. Par rapport au dernier Stimuli Hash, il est déterminé qu’il y a un “changement significatif” et l’État de traitement de l’agent est “réactivé” (mode ACTIF).
2. Le système ExperienceSystem constate que Perception.currentStimuli de l’Agent(1) n’est pas vide, il extrait donc des informations telles que “L’épée apparaît” dans une ou plusieurs nouvelles expériences (type: “observation”). Les stocker dans Memory.experiences[1] et émettre l’événement “expérience”.
3. ThinkingSystem lit les informations d’état de la mémoire, de la perception et d’autres informations et appelle generateThought:

« J’ai vu la MagicSword, peut-être la prendre et voir ce qu’elle peut faire… » Le résultat de la réflexion contient une Action à exécuter: {outil: « pickUpItem », paramètres: {nom de l’article: « MagicSword »}}

ThinkingSystem écrit cette Action à Action.pendingAction[1].

Si il y a un changement d’apparence (par exemple, “visage avec une expression curieuse”), l’apparence est mise à jour et une stimulation visuelle est générée.

4. ActionSystem voit Action.pendingAction[1] = { outil : “pickUpItem”, paramètres : … }.

Exécutez la logique de l’action “pickup” via runtime.getActionManager().executeAction(“pickUpItem”, 1, { nomObjet: “MagicSword” }, runtime). Obtenez le résultat : { success: true, message: “Vous avez ramassé l’épée magique” }, mettez à jour Action.lastActionResult[1] et déclenchez l’événement “action” à diffuser dans la salle (100).

En même temps, un stimulus cognitif (type=”action_result”) est généré, écrit dans la mémoire ou capturé par ThinkingSystem au prochain tour.

5. Le système de planification des objectifs (si l’agent a des objectifs) évalue périodiquement les objectifs de l’agent. Si l’un des objectifs de l’agent à ce moment est “obtenir une arme puissante” et détecte que l’Épée Magique a été obtenue, l’objectif peut être marqué comme terminé. Si de nouveaux changements surviennent (par exemple, “un nouvel objet apparaît dans la pièce” affecte l’objectif poursuivi par l’agent?), générer un nouvel objectif ou abandonner l’ancien objectif en fonction de la détection des changements significatifs.
6. Le système de planification (s’il y a un objectif associé) vérifie s’il est nécessaire de créer un nouveau plan ou de mettre à jour un plan existant pour les objectifs terminés ou nouvellement générés tels que «Obtenir des armes puissantes».

Si terminé, définissez le Plan associé [status] sur “terminé”, ou générez plus d’étapes si le but est d’élargir le processus ultérieur (“Recherchez l’Épée Magique”).

7.RoomSystem met à jour la liste des occupants et des entités visibles dans la salle (100) (à chaque image ou tour).

Si l’apparence de l’agent(1) change (par exemple, Appearance.currentAction = “tenant une épée”), créez un nouveau stimulus visuel “apparence” pour permettre à l’agent2 et à l’agent3 dans la même pièce de savoir que “l’agent1 a ramassé l’épée”.

8.CleanupSystem supprime les entités ou stimuli qui ont été marqués (Nettoyage). Si vous n’avez plus besoin de conserver le stimulus “MagicSword” après l’avoir ramassé, vous pouvez supprimer l’entité de stimulus correspondante dans CleanupSystem.

1. Grâce à la connexion de ces systèmes, l’agent d’IA réalise :

• Percevoir les changements dans l’environnement (Perception) → Enregistrer ou transformer en expérience interne (Expérience) → Auto-réflexion et prise de décision (Réflexion) → Mettre en action (Action) → Ajuster dynamiquement les objectifs et les plans (Planification des objectifs + Planification) → Synchroniser l’environnement (Salle) → Recycler en temps opportun les entités inutiles (Nettoyage)

3. Analyse de l’architecture globale d’ArgOS

1. Couches d’architecture principale

2. Classification des composants

Dans ECS, chaque entité peut avoir plusieurs composants. Selon leur nature et leur cycle de vie dans le système, les composants peuvent être grossièrement divisés en les catégories suivantes:

1. Classes d’identité de base (composants au niveau de l’identité)

• Profil de l’Agent / du Joueur / du PNJ, etc.

• Utilisé pour identifier de manière unique des entités, stocker des rôles principaux ou des informations sur les unités, et généralement besoin d’être persisté dans la base de données.

2. Composants de comportement et d’état

• Action, Goal, Plan, État de traitement, etc.

• Représente ce que l’entité essaie actuellement de faire ou quels sont ses objectifs, ainsi que son statut de réponse aux commandes externes et à la réflexion interne.

• Contient pendingAction, goalsInProgress, plans et réflexions ou tâches en attente, etc.

• Typiquement des états à moyen/ court terme, nombreux changeant dynamiquement au fil des rounds de jeu ou des cycles d’affaires.

• Que la mise en stock soit nécessaire dépend de la situation. Si vous souhaitez continuer à exécuter après un point d’arrêt, vous pouvez écrire dans la base de données périodiquement.

3. Composants de perception & mémoire

• Perception, Memory, Stimulus, Experience, etc.

• Enregistre les informations externes (stimuli) perçues par l’entité et les expériences raffinées en elle après la perception (expériences).

• La mémoire peut souvent accumuler de grandes quantités de données, telles que des enregistrements de conversations, l’historique des événements, etc.; la persistance est souvent requise.

• La perception peut être une information en temps réel ou temporaire, principalement valable à court terme. Vous pouvez décider de l’écrire dans la base de données en fonction de vos besoins (par exemple, seuls les événements de perception importants sont stockés).

4. Classes d’environnement et d’espace (Salle, OccupiesRoom, Spatial, Environnement, Inventaire, etc.)

• Représente des informations telles que les chambres, les environnements, les emplacements, les conteneurs d’objets, etc.

•Room.id, Les champs OccupiesRoom, Environment et autres doivent souvent être persistés, tels que la description de la page d’accueil de la chambre, la structure de la carte, etc.

• Le changement de composants (comme le déplacement d’une entité entre les pièces) peut être écrit de manière événementielle ou périodique.

5. Classes d’apparence et d’interaction (Apparence, État de l’interface utilisateur, Relation, etc.)

• Enregistrer les parties externes «visibles» ou «interactives» de l’entité, telles que l’avatar, la pose, l’expression faciale, le réseau de relations sociales avec d’autres entités, etc.

• Certaines parties peuvent être traitées uniquement en mémoire (représentation en temps réel), tandis que d’autres parties (comme les relations sociales clés) peuvent être persistées.

6. Composants d’utilité et de maintenance (Nettoyage, DebugInfo, ProfilingData, etc.)

• Utilisé pour marquer les entités à recycler (Nettoyage), ou enregistrer les informations de débogage (InfosDebug) à utiliser dans la surveillance et l’analyse.

• Généralement, il n’existe qu’en mémoire et n’est que rarement synchronisé avec la base de données, sauf si cela est nécessaire pour l’enregistrement ou l’audit.

3. Architecture du système

Déjà présenté ci-dessus

4. Manager Architecture

Outre les composants et les systèmes, une couche de gestion des ressources supplémentaire est requise. Cette couche gère l’accès à la base de données, les conflits d’état et d’autres opérations essentielles.

Côté gauche : Systèmes (PerceptionSystem, ExperienceSystem, ThinkingSystem, etc.) :

• Chaque système est programmé pour être exécuté par SimulationRuntime dans la boucle ECS, interrogeant et traitant les entités qui l’intéressent (à travers des conditions de composants).

• Lors de l’exécution de la logique, vous devez interagir avec les gestionnaires, par exemple :

• Appelez RoomManager (RM) pour consulter/mettre à jour les informations sur la chambre.
• Utilisez StateManager (SM) pour obtenir ou sauvegarder l’état du monde/agent, tel que la mémoire, les objectifs, les plans, etc.
• Diffusez ou écoutez des événements de manière externe en utilisant EventBus (EB).
• PromptManager (PM) est appelé lorsque le traitement du langage naturel ou des invites est nécessaire.

Côté droit: Managers (EventBus, RoomManager, StateManager, EventManager, ActionManager, PromptManager, etc):

• Fournir des fonctions de niveau système, qui ne « pilotent » pas activement la logique, mais qui sont appelées par les systèmes ou l’exécution.

• Exemples typiques :

• ActionManager se spécialise dans la gestion de l’enregistrement et de l’exécution des actions.
• EventManager / EventBus est utilisé pour les mécanismes de publication et d’abonnement d’événements.
• RoomManager gère les chambres, les agencements et les occupants.
• Le StateManager est responsable de la synchronisation entre ECS et la base de données ou le stockage.
• PromptManager fournit des extensions telles que des modèles de prompt LLM et la gestion du contexte.
• SimulationRuntime intermédiaire (R):

• Est l’”ordonnanceur” de tous les systèmes, lançant ou arrêtant les cycles du système à différents niveaux (conscient/subconscient, etc.);

• Les gestionnaires sont également créés pendant la phase de construction et transmis à chaque système pour utilisation.

• CleanupSystem：

• Notez en particulier qu’il interagit également avec ComponentSync (CS), qui est utilisé pour supprimer de manière synchrone les composants ou les abonnements aux événements lors du recyclage des entités.

En conclusion:

Chaque système lira et écrira des données ou appellera des services via le gestionnaire correspondant lorsque cela est nécessaire, et le runtime planifiera uniformément le cycle de vie et le comportement de tous les systèmes et gestionnaires à un niveau supérieur.

5. Comment les vecteurs et les bases de données interagissent dans ECS

Dans un système ECS, les systèmes gèrent l’exécution logique réelle, tandis que les opérations de base de données (lecture/écriture) sont gérées via un gestionnaire de persistance (PersistenceManager / DatabaseManager) ou un gestionnaire d’état (StateManager). Le processus général est le suivant :

1. Chargement initial (phase de démarrage ou de chargement)

• StateManager / PersistenceManager charge les données des composants de persistance principaux tels que les Agents, les Salles, les Objectifs, etc. à partir de la base de données, crée les entités correspondantes (Entités) et initialise les champs de composants associés.

• Par exemple, lisez un lot d’enregistrements d’agents et insérez-les dans le monde ECS, et initialisez pour eux les composants Agent, Memory, Goal et autres.

2.Runtime ECS (Boucle de mise à jour des systèmes)

• Le système effectue des actions à chaque frame (ou tour) : PerceptionSystem collecte des « perceptions » et les écrit dans le composant Perception (principalement à court terme hors de la bibliothèque).

ExperienceSystem écrit la nouvelle « expérience cognitive » dans Memory.experiences. S’il s’agit d’une expérience clé, il peut également appeler StateManager pour un stockage immédiat, ou la marquer avec « needsPersistence » pour une écriture ultérieure en lot.

ThinkingSystem / ActionSystem / GoalPlanningSystem, etc., prennent des décisions basées sur le contenu des composants et mettent à jour les champs dans ECS.

Si certains composants (comme Goal.current) subissent des changements majeurs et nécessitent une persistance (comme un nouvel objectif à long terme), informez le StateManager d’écrire ce champ dans la base de données via l’écoute des composants ou des événements système.

3. Persistance périodique ou déclenchée par un événement

• Vous pouvez appeler des interfaces telles que PersistenceManager.storeComponentData(eid, “Goal”) pour supprimer la bibliothèque à certains points clés du système (comme lorsque le plan cible est mis à jour ou lorsqu’un événement important se produit sur l’Agent).

• Vous pouvez également demander à StateManager de scanner les composants ou entités avec l’étiquette “needsPersistence” dans CleanupSystem ou timer, et de les écrire une fois dans la base de données.

• De plus, les données de journalisation ou d’audit (telles que l’historique des actions, le journal des pensées) peuvent également être archivées et stockées ici.

4. Sauvegarde manuelle ou arrêt (Checkpointing et persistance à la sortie)

• Lorsque le serveur ou le processus doit être arrêté, utilisez StateManager.saveAll() pour écrire les données non écrites de manière uniforme dans la base de données afin de garantir que l’état de l’ECS peut être restauré la prochaine fois qu’il est chargé.

• Pour certains scénarios autonomes/hors ligne, les archives peuvent également être déclenchées manuellement.

• Processus d’échantillon complet

Ce qui suit est un scénario simple pour démontrer les façons possibles dont les composants et les bases de données interagissent :

1.Phase de démarrage: StateManager.queryDB(“SELECT * FROM agents”) → Obtenir un lot d’enregistrements d’agent, créer une entité (EID=x) pour chaque enregistrement à tour de rôle, et initialiser les champs de l’agent, de la mémoire, des objectifs et d’autres composants.

En même temps, chargez les informations de la chambre à partir de la table “rooms” et créez une entité Room.

2. Opérations d’exécution : PerceptionSystem détecte l’événement ‘MagicSword appears’ dans une certaine pièce et écrit Perception.currentStimuli[eid].ExperienceSystem convertit les Stimuli en Expérience et l’attribue à Memory.experiences[eid].ThinkingSystem détermine la prochaine action en se basant sur la mémoire, les objectifs et d’autres informations et génère Action.pendingAction[eid].Après l’exécution de l’action par ActionSystem, le résultat est écrit dans Memory ou dans Action.lastActionResult. Si c’est un événement important pour l’intrigue, la dernière partie de Memory.experiences[eid] sera marquée comme ayant besoin de Persistence.Après un certain temps, StateManager trouve que Memory.experiences[eid] a besoin de Persistence et l’écrit dans la base de données (INSERT INTO memory_experiences…).

3. Arrêt ou sauvegarde de la checkpoint : Basé sur l’ECS ou la planification système, StateManager.saveAll() est appelé lorsque le « serveur est arrêté » pour écrire le dernier état des champs de composants clés (Agent, Memory, Goal, etc.) encore en mémoire dans la base de données. La prochaine fois que vous redémarrez, l’état du monde ECS peut être chargé et restauré à partir de la base de données.

• La catégorisation des composants facilite non seulement la gestion claire des données d’entité dans le projet, mais nous aide également à contrôler les limites de données entre “nécessite une persistance” et “existe uniquement en mémoire”.

• L’interaction avec la base de données est généralement gérée par un gestionnaire spécialisé (tel que StateManager), et les systèmes opèrent à travers lui lorsqu’ils ont besoin de lire et d’écrire dans la base de données, évitant d’écrire directement des instructions SQL ou similaires de bas niveau dans le système.

• De cette manière, vous pouvez simultanément profiter de l’efficacité logique et de la flexibilité de ECS, ainsi que des avantages de la persistance, de la reprise après pause et de l’analyse statistique des données apportées par la base de données.

4. Innovations architecturales

Les points forts de l’ensemble de l’architecture sont:

• Chaque système fonctionne de manière indépendante et n’a aucune relation d’appel avec les autres systèmes. Par conséquent, même si nous voulons mettre en œuvre les capacités de l’agent « Percevoir les changements dans l’environnement (Perception) → Enregistrer ou transformer en expérience interne (Expérience) → Auto-réflexion et prise de décision (Réflexion) → Mettre en action (Action) → Ajuster dynamiquement les objectifs et les plans (Planification des objectifs + Planification) → Synchroniser l’environnement (Chambre) → Recycler en temps opportun les entités inutiles (Nettoyage) », chaque système aura de nombreuses interdépendances en termes de fonctionnalités, mais nous pouvons toujours utiliser l’architecture ECS pour structurer le tout en systèmes indépendants. Chaque système peut toujours fonctionner de manière indépendante et n’interagira pas avec les autres systèmes. Il y a des personnes et des relations de couplage.
• Je pense que c’est aussi la raison principale pour laquelle Unity a de plus en plus migré vers l’architecture ECS ces dernières années.
• Et par exemple, je veux juste qu’un Agent ait quelques capacités de base. J’ai seulement besoin de réduire l’enregistrement de quelques Composants et l’enregistrement du Système lors de la définition de l’Entité, ce qui peut être facilement réalisé sans modifier quelques lignes de code.

Comme indiqué ci-dessous :

En même temps, si vous souhaitez ajouter de nouvelles fonctions pendant le processus de développement, cela n’aura aucun impact sur les autres systèmes et vous pourrez facilement charger les fonctions souhaitées.

• De plus, les performances de l’architecture actuelle sont en réalité beaucoup meilleures que celles de l’architecture orientée objet traditionnelle. C’est un fait reconnu dans le cercle du jeu, car la conception ECS est plus adaptée à la concurrence. Ainsi, lorsque nous utilisons ECS dans des scénarios Defai complexes, l’architecture peut également avoir plus d’avantages, notamment dans les scénarios où l’on s’attend à ce que les agents soient utilisés pour des transactions quantitatives, ECS sera également utile (pas seulement dans les scénarios de jeu d’agents).
• Diviser le système en conscient, subconscient et inconscient pour distinguer à quelle fréquence les différents types de systèmes doivent être exécutés est une conception extrêmement intelligente et constitue déjà une capacité humaine très concrète.

De mon point de vue personnel, il s’agit d’un cadre extrêmement modulaire avec d’excellentes performances. La qualité du code est également très élevée et contient de bons documents de conception. Malheureusement, Project89 a manqué de visibilité et de promotion pour ce cadre, c’est pourquoi j’ai passé quatre jours à écrire cet article pour mettre en évidence ses points forts. Je crois que les grandes technologies méritent une reconnaissance, et demain, je prévois de publier une version anglaise de cet article pour sensibiliser les équipes de jeu et les développeurs de DeFi (finance décentralisée). Espérons que plus d’équipes exploreront ce cadre comme choix d’architecture potentiel pour leurs projets!

Avertissement :

1. Cet article est reproduit à partir de [[](https://x.com/hhh69251498/status/1883442254528078274)[0xhhh](https://x.com/hhh69251498)\]. Transférez le titre original: Je vois le cadre de l’agent de la prochaine génération dans le projet89. Les droits d’auteur appartiennent à l’auteur original [0xhhh]. Si vous avez des objections à la reproduction, veuillez contacter Porte Apprendreéquipe, l’équipe s’en chargera dès que possible selon les procédures pertinentes.
2. Avis de non-responsabilité : Les points de vue et opinions exprimés dans cet article ne représentent que les opinions personnelles de l’auteur et ne constituent aucun conseil en investissement.
3. Les autres versions linguistiques de l’article sont traduites par l’équipe Gate Learn. Sauf indication contraire, l’article traduit ne peut être copié, distribué ou plagié.