Ein leistungsstarkes ECS-basiertes Agentenframework

Weiterleiten des Originaltitels: Ich sehe das Next Generation Agent Framework in Project89

Um es auf den Punkt zu bringen, @project_89übernimmt einen völlig neuen Ansatz bei der Gestaltung eines Agent Frameworks. Dies ist ein leistungsstarkes Agent Framework, das speziell für die Spieleentwicklung entwickelt wurde. Im Vergleich zu den derzeit verwendeten Agent Frameworks ist es modularer und bietet eine bessere Leistung.

Dieser Artikel hat lange gedauert, um zu schreiben, und versucht, jedem zu erklären, welche Art von architektonischen Upgrades dieses Framework im Vergleich zum traditionellen Agenten-Framework vorgenommen hat. Es wurde vor dieser Version mehrmals überarbeitet, aber es gibt immer noch einige Teile in dem Artikel, die zu verwirrend sind. Aufgrund technischer Schwierigkeiten konnte ich es nicht weiter verbreiten. Wenn Sie Vorschläge zur Verbesserung des Artikels haben, hinterlassen Sie bitte Ihre Kommentare.

Entwicklerhintergrund

Da dies ein technischer Blog ist, werfen wir zunächst einen Blick auf die technische Expertise des Gründers.

Bevor sie an Project89 arbeiteten, hat der Gründer an diesem Projekt gearbeitet:https://github.com/Oneirocom/Magick, das auch eine KI-gesteuerte Programmiersoftware ist. Darüber hinaus wird Shaw als der viertbeste Entwickler dieses Projekts eingestuft. Sie können dieses Projekt auch in Shaws Portfolio sehen.

Oben links: der Gründer von project89; Unten rechts: 'lalaune' ist Shaw von ai16z

Heute werden wir hauptsächlich das leistungsstarke Agenten-Framework in Projekt89 vorstellen:

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

1. Warum ein ECS zur Gestaltung eines Agenten-Frameworks verwenden?

Aus der Perspektive der Anwendung im Spielbereich

Spiele, die derzeit die ECS-Architektur verwenden, sind unter anderem:

Blockchain-Spiele: Mud, Dojo

Traditionelle Spiele: Overwatch, Star Citizen, etc.

Darüber hinaus entwickeln sich Mainstream-Spiel-Engines hin zur ECS-Architektur, wie Unity.

Was ist ECS?

ECS (Entity-Component-System) ist ein architektonisches Muster, das häufig in der Spieleentwicklung und Simulationssystemen verwendet wird. Es trennt Daten und Logik vollständig voneinander, um verschiedene Entitäten und ihr Verhalten in groß angelegten skalierbaren Szenarien effizient zu verwalten:

Entität

• Nur eine ID (Nummer oder Zeichenfolge), die keine Daten oder Logik enthält.

• Sie können verschiedene Komponenten montieren, um ihm je nach Bedarf verschiedene Eigenschaften oder Fähigkeiten zu verleihen.

Komponente

• Wird verwendet, um spezifische Daten oder den Zustand einer Entität zu speichern.

System

• Verantwortlich für die Ausführung der Logik im Zusammenhang mit bestimmten Komponenten.

Lassen Sie uns ein spezifisches Beispiel für die Aktion eines Agenten verwenden, um dieses System zu verstehen:

In ArgOS wird jeder Agent als Entität betrachtet, die verschiedene Komponenten registrieren kann. Zum Beispiel hat unser Agent auf dem untenstehenden Bild die folgenden vier Komponenten:

Agentenkomponente: speichert hauptsächlich grundlegende Informationen wie Agentenname, Modellname usw.

Wahrnehmungskomponente: Hauptsächlich zur Speicherung wahrgenommener externer Daten verwendet

Speicherbaustein: Wird hauptsächlich zur Speicherung von Speicherdaten der Agent-Entität, ähnlichen Dingen, die erledigt wurden, usw. verwendet.

Aktionskomponente: Speichert hauptsächlich die auszuführenden Aktionsdaten

Systemablauf:

1. In diesem Spiel wird zum Beispiel bei der Wahrnehmung einer Waffe vor Ihnen die Ausführungsfunktion des Wahrnehmungssystems aufgerufen, um die Daten im Wahrnehmungskomponente der Agent-Entität zu aktualisieren.
2. Dann löse das Memory System aus, rufe gleichzeitig den Perception Component und Memory Component auf und speichere die wahrgenommenen Daten über Memory in der Datenbank.
3. Dann ruft das Aktivitätssystem das Memory Component und Action Component auf, um die Informationen zur Umgebung aus dem Speicher abzurufen, und führt schließlich die entsprechende Aktion aus.

Dann erhalten wir eine Update-Agent-Entity, in der die Daten jedes Komponenten aktualisiert werden.

4. So können wir sehen, dass das System hier hauptsächlich dafür verantwortlich ist, zu definieren, welche Komponenten die entsprechende Verarbeitungslogik ausführen sollen.

Und es ist offensichtlich, dass in Projekt89 eine Welt voller verschiedener Arten von Agents ist. Zum Beispiel haben einige Agents nicht nur die oben genannten Grundfähigkeiten, sondern auch die Fähigkeit, Pläne zu schmieden.

Dann wird es wie im Bild unten gezeigt sein:

Systemausführungsfluss

Im Gegensatz zu herkömmlichen Frameworks, bei denen ein System direkt ein anderes auslöst (z.B. das Perception-System, das das Memory-System aufruft), rufen sich die Systeme in Project89 nicht direkt auf. Stattdessen laufen sie unabhängig voneinander in festen Zeitintervallen. Zum Beispiel:

• Das Perception System wird alle 2 Sekunden ausgeführt, um das Perception Component mit neu erhaltenen Umweltdaten zu aktualisieren.
• Das Memory System läuft jede 1 Sekunde und extrahiert Daten aus dem Perception Component und speichert sie im Memory Component.
• Das System 'Plan' wird alle 1000 Sekunden ausgeführt, analysiert die gesammelten Daten, um festzustellen, ob eine Optimierung erforderlich ist, und erstellt einen neuen Plan, der dann im Plan-Komponenten aufgezeichnet wird.
• Das Aktionssystem wird alle 2 Sekunden ausgeführt, reagiert auf Umweltveränderungen und passt Aktionen basierend auf Updates von der Planungskomponente an.

Bisher hat dieser Artikel die Architektur von ArgOS erheblich vereinfacht, um sie verständlicher zu machen. Werfen wir nun einen genaueren Blick auf das echte ArgOS-System.

2. ArgOS Systemarchitektur

Um dem Agenten zu ermöglichen, tiefer zu denken und komplexere Aufgaben auszuführen, hat ArgOS viele Komponenten und viele Systeme entworfen.

Und ArgOS teilt System in „drei Ebenen“ (ConsciousnessLevel) auf:

1) BEWUSSTES System

• Enthält RoomSystem, PerceptionSystem, ExperienceSystem, ThinkingSystem, ActionSystem, CleanupSystem)
• Die Aktualisierungsfrequenz ist in der Regel höher (zum Beispiel alle 10 Sekunden).
• Verarbeitung näher am "Echtzeit"- oder "bewussten" Niveau, wie z.B. Umweltwahrnehmung, Echtzeitdenken, Ausführung von Handlungen usw.

2) Unterbewusstsein (SUBCONSCIOUS) System

• GoalPlanningSystem, PlanningSystem
• Die Aktualisierungsfrequenz ist relativ niedrig (z.B. alle 25 Sekunden).
• Verarbeitet "Denk"-Logik wie periodische Überprüfung/Generierung von Zielen und Plänen.

3) Unbewusstes (UNCONSCIOUS) System

• Noch nicht aktiviert
• Die Aktualisierungsfrequenz ist langsamer (z.B. mehr als 50 Sekunden),

Daher werden in ArgOS verschiedene Systeme gemäß dem Bewusstseinslevel unterteilt, um festzulegen, wie oft dieses System ausgeführt wird.

Warum ist es so konzipiert?

Da die Beziehung zwischen verschiedenen Systemen in ArgOS äußerst komplex ist, wie unten dargestellt:

1. Das PerceptionSystem ist dafür verantwortlich, "Reize" aus der Außenwelt oder anderen Entitäten zu sammeln und sie an das Wahrnehmungskomponente des Agenten zu aktualisieren.

Bestimmen Sie, ob der Stimulus sich signifikant ändert und aktualisieren Sie ihn entsprechend basierend auf Stabilität, Verarbeitungsmodus (AKTIV/REFLEKTIEREND/WARTEND), usw.

Letztendlich werden „aktuelle Wahrnehmungsdaten“ für das nachfolgende ExperienceSystem, ThinkingSystem, usw. bereitgestellt.

2. Das ExperienceSystem wandelt die von PerceptionSystem gesammelten Reize in eine abstraktere "Erfahrung" um.

LLM oder Regellogik (extractExperiences) wird aufgerufen, um neue Erfahrungen zu identifizieren und im Speicherbaustein zu speichern.

Erfahrungen deduplizieren, filtern und überprüfen, während durch den Eventbus "Experience"-Events an andere Systeme oder externe Zuhörer weitergeleitet werden.

3. ThinkingSystem repräsentiert den internen Gedankenprozess des Agenten.

Extrahieren Sie den aktuellen Status aus Komponenten wie dem Speicher und der Wahrnehmung und generieren Sie durch generateThought(...) und LLM/Regellogik einen „ThoughtResult“.

Basierend auf dem Gedankenergebnis kann es sein:

• Aktualisieren Sie Gedanken im Gedächtnis (Denkgeschichte).

• Eine neue Aktion auslösen (in Action.pendingAction[eid] einfügen).

• Ändern Sie das äußere Erscheinungsbild des Agenten (Ausdruck, Haltung usw.) und erzeugen Sie entsprechende Reize, damit andere Entitäten die Veränderung "sehen" können.

4. ActionSystem führt Aktionen aus, wenn Aktion.ausstehendeAktionist nicht leer, verwendenLaufzeit.getActionManager().executeAction(…).

Nach der Ausführung schreiben Sie das Ergebnis zurück in Action.lastActionResult und benachrichtigen Sie den Raum oder andere Entitäten.

Dies erzeugt auch einen CognitiveStimulus (kognitive Stimulation), damit nachfolgende Systeme wissen, dass die Aktion abgeschlossen wurde oder in das Gedächtnis aufgenommen werden kann.

5.GoalPlanningSystem wertet in regelmäßigen Abständen den Fortschritt von Zielen in der Liste Goal.current[eid] aus oder überprüft den externen/eigenen Speicher auf signifikante Änderungen (detectSignificantChanges).

Wenn ein neues Ziel oder eine Zielanpassung erforderlich ist, generiere und schreibe Goal.current[eid] über generateGoals(...).

Gleichzeitig wird das Ziel im Fortschritt (in_progress) aktualisiert. Wenn die Abschluss- oder Fehlerbedingungen erfüllt sind, wird der Status geändert und ein Abschluss-/Fehlersignal an den entsprechenden Plan gesendet.

6.PlanningSystem generiert oder aktualisiert den Plan (Ausführungsplan) für das „bestehende Ziel“ (Goal.current[eid]).

Wenn festgestellt wird, dass einige Ziele keine entsprechenden aktiven Pläne haben, generieren Sie einen Ausführungsplan, der mehrere Schritte durch generatePlan(…) enthält, und schreiben Sie ihn in Plan.plans[eid].

Wenn das Ziel abgeschlossen oder gescheitert ist, wird auch der damit verbundene Planstatus aktualisiert und es wird eine entsprechende kognitive Stimulation erzeugt.

7. Das RaumSystem behandelt raumbezogene Updates:

• Besorgen Sie sich die Liste der Insassen im Raum (Insassen) und generieren Sie "Erscheinungs"-Stimuli für jeden Agenten, damit andere Entitäten sein Erscheinungsbild oder seine Handlungen "sehen" können.

• Erstellen und korrelieren Sie Reizumgebung im Raum (z. B. passende "Raumambiente"-Informationen).

Stellen Sie sicher, dass, wenn sich der Agent in einer bestimmten räumlichen Umgebung befindet, andere Entitäten, die den Raum wahrnehmen, Veränderungen in seinem Aussehen wahrnehmen können.

8.CleanupSystem findet und entfernt regelmäßig Entitäten, die mit dem Cleanup-Komponenten markiert sind. Wird verwendet, um Stimulus oder andere Objekte zu recyclen, die nicht mehr benötigt werden, um zu verhindern, dass eine große Anzahl ungültiger Entitäten im ECS verbleiben.

• Beispiel: Eine Schleife von "Das Objekt sehen" bis "Die Aktion ausführen"

Das folgende Szenenbeispiel zeigt, wie jedes System zusammenarbeitet, um einen vollständigen Prozess in einer Runde (oder mehreren Frames) abzuschließen.

Szenenvorbereitung: Es gibt einen Agenten (EID=1) in der Welt, der sich im Status "Aktiv" befindet und sich in einem Raum (EID=100) befindet.

In diesem Raum erschien eine neue Requisite "MagicSword" und der entsprechende Stimulus wurde erzeugt.

1. PerceptionSystem erkennt das Erscheinen von "MagicSword", generiert einen Reiz (Typ="item_appearance") für Agent(1) und fügt ihn zu Perception.currentStimuli[1] hinzu. Im Vergleich zum letzten Reiz-Hash wird festgestellt, dass es eine "signifikante Veränderung" gibt, und der Verarbeitungszustand des Agenten ist "reaktiviert" (AKTIV-Modus).
2. ExperienceSystem stellt fest, dass die Perception.currentStimuli von Agent(1) nicht leer ist. Daher extrahiert es Informationen wie "Schwert erscheint" in ein oder mehrere neue Erfahrungen (Typ: "Beobachtung"). Speichern Sie es in Memory.experiences[1] und geben Sie das Ereignis "Erfahrung" aus.
3. ThinkingSystem liest Speicher-, Wahrnehmungs- und andere Statusinformationen und ruft generateThought auf:

„Ich sah das gateSchwert, vielleicht nehme es auf und sehe, was es kann tun…“ Das Denkergebnis enthält eine auszuführende Aktion: { tool: „pickUpItem“, parameters: { itemName: „gateSword“ } }

ThinkingSystem schreibt diese Aktion in Action.pendingAction[1].

Wenn es eine Veränderung im Aussehen gibt (z.B. „Gesicht mit neugierigem Ausdruck“), wird das Aussehen aktualisiert und eine visuelle Stimulation erzeugt.

4. ActionSystem sieht Action.pendingAction[1] = { tool: "pickUpItem", parameters: ... }.

Führen Sie die Logik der Aktion „Abholen“ über runtime.getActionManager().executeAction(„AbholenItem“, 1, { itemName: „ZauberSchwert“ }, runtime) aus. Erhalten Sie das Ergebnis: { success: true, message: „Sie haben das Zauberschwert aufgehoben“ }. Aktualisieren Sie Action.lastActionResult[1] und lösen Sie das Ereignis „Aktion“ aus, um es an den Raum (100) zu übertragen.

Gleichzeitig wird ein kognitiver Reiz (Typ="action_result") erzeugt, der im nächsten Zug in den Speicher geschrieben oder von ThinkingSystem erfasst wird.

5. Das GoalPlanningSystem (falls der Agent Ziele hat) überprüft regelmäßig die Ziele des Agenten. Wenn eines der Ziele des Agenten zu diesem Zeitpunkt "eine mächtige Waffe zu erhalten" ist und feststellt, dass das MagicSword erhalten wurde, kann das Ziel als abgeschlossen markiert werden. Wenn neue Änderungen (zum Beispiel "neues Objekt erscheint im Raum" beeinflusst das vom Agenten verfolgte Ziel?), generieren Sie ein neues Ziel oder verwerfen Sie das alte Ziel basierend auf detectSignificantChanges.
6. Planningssystem (wenn ein entsprechendes Ziel vorhanden ist) überprüft, ob ein neuer Plan erforderlich ist oder ein bestehender Plan für abgeschlossene oder neu generierte Ziele wie "Leistungsstarke Waffen beschaffen" aktualisiert werden muss.

Wenn abgeschlossen, setzen Sie den zugehörigen Plan [status] auf "abgeschlossen" oder generieren Sie weitere Schritte, wenn das Ziel darin besteht, den nachfolgenden Prozess zu erweitern ("Forschung des magischen Schwertes").

7. RoomSystem aktualisiert die Liste der Bewohner und sichtbaren Entitäten im Raum (100) (jeder Frame oder Runde).

Wenn sich das Erscheinungsbild des Agenten (1) ändert (zum Beispiel, Appearance.currentAction = "Schwert halten"), erstellen Sie einen neuen visuellen Reiz "Erscheinungsbild", um den anderen Agenten 2 und Agent3 im selben Raum mitzuteilen, dass "Agent1 das Schwert aufgehoben hat".

8. Das CleanupSystem entfernt Entitäten oder Reize, die markiert wurden (Cleanup). Wenn Sie den Stimulus 'MagicSword' nach dem Aufnehmen nicht mehr benötigen, können Sie die entsprechende Stimulus-Entität im CleanupSystem löschen.

1. Durch die Verbindung dieser Systeme erreicht AI Agent:

• Veränderungen in der Umgebung wahrnehmen (Wahrnehmung) -> Aufzeichnen oder in innere Erfahrung umwandeln (Erleben) -> Selbstständiges Denken und Entscheidungsfindung (Denken) -> In die Tat umsetzen (Handeln) -> Ziele und Pläne dynamisch anpassen (Zielplanung + Planung) -> Umgebung synchronisieren (Raum) -> Nutzlose Entitäten rechtzeitig recyclen (Bereinigung)

3. Analyse der Gesamtarchitektur von ArgOS

1. Kernarchitekturschichten

2. Komponentenklassifikation

In ECS kann jede Entität mehrere Komponenten haben. Je nach ihrer Natur und ihrem Lebenszyklus im System können Komponenten grob in folgende Kategorien unterteilt werden:

1. Kernidentitätsklassen (Identitätskomponenten auf Identitätsebene)

• Agent / Spielerprofil / NPC-Profil usw.

• Wird verwendet, um Entitäten eindeutig zu identifizieren, Kernrollen oder Einheitsinformationen zu speichern und im Allgemeinen in der Datenbank gespeichert werden müssen.

2. Verhaltens- und Zustandskomponenten

• Aktion, Ziel, Plan, Bearbeitungsstatus, etc.

• Stellt dar, was die Entität derzeit zu tun versucht oder welche Ziele sie verfolgt, sowie ihren Reaktionsstatus auf externe Befehle und internes Denken.

• Enthält ausstehende Aktionen, laufende Ziele, Pläne und Gedanken oder Aufgaben in der Warteschlange, etc.

• Typischerweise mittel- bis kurzfristige Zustände, die sich im Laufe von Spielrunden oder Wirtschaftszyklen dynamisch verändern.

• Ob eine Aktienaufstockung erforderlich ist, hängt von der Situation ab. Wenn Sie nach einem Breakpoint weiterhin ausgeführt werden möchten, können Sie regelmäßig in die Datenbank schreiben.

3. Wahrnehmungs- & Gedächtniskomponenten

• Wahrnehmung, Gedächtnis, Reiz, Erfahrung usw.

• Zeichnet die von der Entität wahrgenommenen externen Informationen (Reize) und die nach der Wahrnehmung darin verfeinerten Erfahrungen (Erlebnisse) auf.

• Der Speicher kann oft große Datenmengen wie Gesprächsprotokolle, Ereignisverlauf usw. ansammeln; oft ist Persistenz erforderlich.

• Die Wahrnehmung kann Echtzeit- oder vorübergehende Informationen sein, die meist kurzfristig gültig sind. Sie können entscheiden, ob Sie sie gemäß Ihren Bedürfnissen in die Datenbank schreiben möchten (zum Beispiel werden nur wichtige Wahrnehmungsereignisse gespeichert).

4. Klassen für Umgebung und Raum (Room, OccupiesRoom, Spatial, Environment, Inventory usw.)

• Stellt Informationen wie Räume, Umgebungen, Standorte, Objektbehälter usw. dar.

•Raum.id, Besetzt Zimmer, Umgebung und andere Felder müssen oft gespeichert werden, wie z.B. Zimmer-Homepage-Beschreibung, Kartentruktur usw.

• Das Ändern von Komponenten (wie das Verschieben einer Entität zwischen Räumen) kann ereignisbasiert oder periodisch geschrieben werden.

5. Erscheinungsbild- und Interaktionsklassen (Erscheinungsbild, UI-Zustand, Beziehung usw.)

• Erfassen Sie die externen "sichtbaren" oder "interaktiven" Teile der Entität, wie Avatar, Pose, Gesichtsausdruck, soziales Beziehungsnetzwerk mit anderen Entitäten usw.

• Einige Teile können nur im Arbeitsspeicher verarbeitet werden (Echtzeitdarstellung), während andere Teile (wie wichtige soziale Beziehungen) persistiert werden können.

6. Hilfs- und Wartungskomponenten (Cleanup, DebugInfo, ProfilingData usw.)

• Wird verwendet, um zu kennzeichnen, welche Entitäten recycelt werden müssen (Cleanup) oder Debugging-Informationen (DebugInfo) zur Verwendung bei Überwachung und Analyse aufzuzeichnen.

• Typischerweise existiert nur im Arbeitsspeicher und wird nur selten mit der Datenbank synchronisiert, es sei denn, dies ist für die Protokollierung oder Überprüfung erforderlich.

3. Systemarchitektur

Bereits oben eingeführt

4. Manager Architektur

Neben Komponenten und Systemen ist eine zusätzliche Ressourcenverwaltungsebene erforderlich. Diese Ebene verwaltet den Datenbankzugriff, Zustandskonflikte und andere wesentliche Operationen.

Linke Seite: Systeme (PerceptionSystem, ExperienceSystem, ThinkingSystem, usw.):

• Jedes System ist im ECS-Loop für die Ausführung durch SimulationRuntime geplant. Es werden die Entitäten abgefragt und verarbeitet, die für das System relevant sind (über Komponentenbedingungen).

• Bei der Ausführung der Logik müssen Sie mit Managern interagieren, zum Beispiel:

• Rufen Sie RoomManager (RM) an, um Rauminformationen abzufragen/aktualisieren.
• Verwenden Sie StateManager (SM), um den Zustand der Welt/Agenten wie Memory, Goal, Plan usw. abzurufen oder zu speichern.
• Senden oder Empfangen von Ereignissen extern über EventBus (EB).
• PromptManager (PM) wird aufgerufen, wenn natürliche Sprachverarbeitung oder Aufforderungen erforderlich sind.

Rechte Seite: Manager (EventBus, RoomManager, StateManager, EventManager, ActionManager, PromptManager, etc):

• Bieten Sie systemweite Funktionen, die im Wesentlichen die Logik nicht aktiv "steuern", sondern von Systemen oder der Laufzeit aufgerufen werden.

• Typische Beispiele:

• ActionManager ist spezialisiert auf die Verwaltung der Registrierung und Ausführung von Aktionen.
• EventManager / EventBus wird für Ereignisveröffentlichungs- und Abonnementmechanismen verwendet.
• RoomManager verwaltet Räume, Layouts und Bewohner.
• StateManager ist für die Synchronisierung zwischen ECS und Datenbank oder Speicher verantwortlich.
• PromptManager bietet Erweiterungen wie LLM-Prompt-Vorlagen und Kontextverwaltung.
• Zwischen SimulationRuntime (R):

• Ist der „Scheduler“ aller Systeme, der Systemzyklen auf verschiedenen Ebenen (bewusst/unbewusst usw.) startet oder stoppt;

• Manager werden auch während der Bauphase erstellt und an jedes System zur Verwendung übergeben.

• CleanupSystem:

• Beachten Sie insbesondere, dass es auch mit ComponentSync (CS) interagiert, das verwendet wird, um Komponenten oder Ereignisabonnements synchron zu entfernen, wenn Entitäten recycelt werden.

Zusammenfassend:

Jedes System liest und schreibt bei Bedarf Daten oder ruft Dienste über den entsprechenden Manager ab, und der Laufzeitumgebung plant einheitlich den Lebenszyklus und das Verhalten aller Systeme und Manager auf einer höheren Ebene.

5. Wie Vektoren und Datenbanken in ECS interagieren

In einem ECS-System verwalten Systeme die tatsächliche Ausführung der Logik, während Datenbankoperationen (Lesen/Schreiben) über einen Persistence Manager (PersistenceManager / DatabaseManager) oder einen State Manager (StateManager) verwaltet werden. Der allgemeine Prozess ist wie folgt:

1. Initiale Ladung (Start- oder Ladephase)

• StateManager / PersistenceManager lädt die Daten der Kernbestandteile der Persistenz wie Agents, Räume, Ziele usw. aus der Datenbank, erstellt entsprechende Entitäten (Entities) und initialisiert die zugehörigen Komponentenfelder.

• Zum Beispiel lesen Sie eine Reihe von Agentenprotokollen und fügen Sie sie in die ECS-Welt ein und initialisieren Sie Agent, Memory, Goal und andere Komponenten für sie.

2. ECS-Laufzeit (System-Update-Schleife)

• Das System führt in jedem Frame (oder Runde) Aktionen durch: Das PerceptionSystem sammelt „Wahrnehmungen“ und schreibt sie in die Perception-Komponente (meist kurzfristig aus der Bibliothek).

ExperienceSystem schreibt das neue "kognitive Erlebnis" in Memory.experiences. Wenn es sich um ein Schlüsselerlebnis handelt, kann es auch den StateManager zur sofortigen Speicherung aufrufen oder es mit "needsPersistence" markieren, um es später im Batch zu schreiben.

ThinkingSystem / ActionSystem / GoalPlanningSystem usw. treffen Entscheidungen basierend auf dem Komponenteninhalt und aktualisieren Felder in ECS.

Wenn einige Komponenten (wie Goal.current) wesentliche Änderungen durchlaufen und Persistenz erfordern (wie ein neues Langzeitziel), benachrichtigen Sie den StateManager durch Komponenten-Listening oder Systemereignisse, um dieses Feld in die Datenbank zu schreiben.

3. Periodische oder ereignisgesteuerte Persistenz

• Sie können Schnittstellen wie PersistenceManager.storeComponentData(eid, "Goal") aufrufen, um die Bibliothek an bestimmten Schlüsselpunkten im System abzulegen (z. B. wenn der Zielplan aktualisiert wird oder wenn ein wichtiger Ereignis im Agenten auftritt).

• Sie können auch den StateManager Komponenten oder Entitäten mit dem Tag "needsPersistence" in CleanupSystem oder Timer scannen und sie auf einmal in die Datenbank schreiben.

• Darüber hinaus können auch Protokoll- oder Prüfdaten (wie z. B. Aktionshistorie, Gedankenprotokoll) archiviert und hier gespeichert werden.

4. Manuell oder Shutdown speichern (Checkpointing & Persistenz beim Beenden)

• Wenn der Server oder der Prozess heruntergefahren werden soll, verwenden Sie StateManager.saveAll(), um die nicht geschriebenen Daten einheitlich in die Datenbank zu schreiben, um sicherzustellen, dass der ECS-Zustand beim nächsten Laden wiederhergestellt werden kann.

• Für einige eigenständige/offline-Szenarien können Archive auch manuell ausgelöst werden.

• Vollständiger Beispielprozess

Im Folgenden wird ein einfaches Szenario vorgestellt, um die möglichen Wege zu demonstrieren, in denen Komponenten und Datenbanken interagieren können:

1. Startup-Phase: StateManager.queryDB("SELECT * FROM agents") → Ein Batch von Agenten-Datensätzen abrufen, für jeden Datensatz eine Entität (EID=x) erstellen und die Felder Agent, Memory, Goal und andere Komponenten initialisieren.

Gleichzeitig Rauminformationen aus der Tabelle "Räume" laden und eine Raum-Entität erstellen.

2. Laufzeitoperationen: Das PerceptionSystem erkennt das Ereignis "MagicSword erscheint" in einem bestimmten Raum und schreibt Perception.currentStimuli[eid]. Das ExperienceSystem wandelt Reize in Erfahrungen um und weist sie Memory.experiences[eid] zu. Das ThinkingSystem bestimmt die nächste Aktion basierend auf Memory, Ziel und anderen Informationen und generiert Action.pendingAction[eid]. Nachdem das ActionSystem die Aktion ausgeführt hat, schreibt es das Ergebnis in Memory oder Action.lastActionResult. Wenn es sich um ein wichtiges Handlungselement handelt, wird der neueste Teil von Memory.experiences[eid] als needsPersistence markiert. Nach einer Weile findet der StateManager heraus, dass Memory.experiences[eid] "needsPersistence" hat, und schreibt es in die Datenbank (INSERT INTO memory_experiences...).

3. Stoppen oder Überprüfen Sie den Speicherpunkt: Basierend auf der ECS- oder Systemplanung wird StateManager.saveAll() aufgerufen, wenn der "Server heruntergefahren wird", um den neuesten Status der Schlüsselkomponentenfelder (Agent, Speicher, Ziel usw.), die sich noch im Speicher befinden, in die Datenbank zu schreiben. Beim nächsten Neustart kann der Weltzustand des ECS aus der Datenbank geladen und wiederhergestellt werden.

• Das Kategorisieren von Komponenten erleichtert nicht nur das klare Management von Entitätsdaten im Projekt, sondern hilft uns auch, die Datenbegrenzung zwischen „erfordert Persistenz“ und „existiert nur im Speicher“ zu kontrollieren.

• Die Interaktion mit der Datenbank wird in der Regel von einem spezialisierten Manager (wie dem StateManager) behandelt, und Systeme arbeiten über ihn, wenn sie auf die Datenbank lesen und schreiben müssen, um das direkte Schreiben von SQL oder ähnlichen Low-Level-Anweisungen zu vermeiden.

• Auf diese Weise können Sie gleichzeitig die logische Effizienz und Flexibilität von ECS genießen sowie die Vorteile der Persistenz, der Wiederaufnahme an der Unterbrechungsstelle und der Datenstatistikanalyse, die von der Datenbank gebracht werden.

4. Architektonische Innovationen

Die Höhepunkte der gesamten Architektur sind:

• Jedes System läuft unabhängig und hat keine Aufrufbeziehung zu anderen Systemen. Daher, selbst wenn wir die Funktionen des Agenten "Wahrnehmung von Veränderungen in der Umgebung (Wahrnehmung) → Aufzeichnen oder Umwandeln in innere Erfahrung (Erfahrung) → Selbständiges Denken und Entscheidungsfindung (Denken) → Umsetzung in Aktion (Aktion) → Dynamische Anpassung von Zielen und Plänen (Zielplanung + Planung) → Synchronisierung der Umgebung (Raum) → Zeitnahe Entsorgung unnötiger Entitäten (Aufräumen)" implementieren möchten, wird jedes System viele Abhängigkeiten in der Funktion haben, aber wir können immer noch die ECS-Architektur verwenden, um das Ganze in unabhängige Systeme zu strukturieren. Jedes System kann immer noch unabhängig ausgeführt werden und wird nicht mit anderen Systemen interagieren. Es gibt Menschen und Kopplungsbeziehungen.
• Ich glaube, das ist auch der Hauptgrund, warum Unity in den letzten Jahren zunehmend zur ECS-Architektur gewechselt ist.
• Und zum Beispiel möchte ich einfach, dass ein Agent einige grundlegende Fähigkeiten hat. Ich muss nur die Registrierung einiger Komponenten und die Registrierung des Systems reduzieren, wenn ich die Entität definiere, was ohne Änderung weniger Zeilen Code problemlos erreicht werden kann.

Wie unten gezeigt:

Gleichzeitig, wenn Sie während des Entwicklungsprozesses neue Funktionen hinzufügen möchten, hat dies keinerlei Auswirkungen auf andere Systeme und Sie können die gewünschten Funktionen problemlos laden.

• Darüber hinaus ist die Leistung der aktuellen Architektur tatsächlich viel besser als die der traditionellen objektorientierten Architektur. Dies ist eine anerkannte Tatsache im Gaming-Bereich, da das Design von ECS besser für Nebenläufigkeit geeignet ist. So kann die Architektur auch in komplexen Defai-Szenarien mehr Vorteile haben, insbesondere in Szenarien, in denen Agenten für quantitative Transaktionen verwendet werden sollen, ist ECS ebenfalls nützlich (nicht nur in Agentenspiel-Szenarien).
• Die Aufteilung des Systems in bewusstes, unterbewusstes und unbewusstes, um zu unterscheiden, wie oft verschiedene Arten von Systemen ausgeführt werden sollten, ist ein äußerst cleveres Design und bereits eine sehr konkrete menschliche Fähigkeit.

Aus meiner persönlichen Sicht handelt es sich hier um ein äußerst modulares Framework mit ausgezeichneter Leistung. Die Code-Qualität ist ebenfalls sehr hoch und enthält gute Design-Dokumente. Leider hat Project89 die Sichtbarkeit und Förderung dieses Frameworks vernachlässigt, weshalb ich vier Tage damit verbracht habe, diesen Artikel zu verfassen, um seine Stärken hervorzuheben. Ich glaube, großartige Technologien verdienen Anerkennung, und morgen plane ich, eine englische Version dieses Artikels zu veröffentlichen, um das Bewusstsein unter Gaming-Teams und DeFi (dezentralisierte Finanzen)-Entwicklern zu erhöhen. Hoffentlich werden mehr Teams dieses Framework als potenzielle architektonische Wahl für ihre Projekte erkunden!

Haftungsausschluss:

1. Dieser Artikel stammt aus [0xhhh]. Weiterleiten des Originaltitels: Ich sehe das Agentenframework der nächsten Generation in Project89. Das Urheberrecht liegt beim Originalautor [.0xhhh]. Wenn Sie Einwände gegen den Nachdruck haben, kontaktieren Sie uns bitte.Gate LearnTeam, das Team wird es gemäß den entsprechenden Verfahren so schnell wie möglich bearbeiten.
2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel zum Ausdruck gebracht werden, repräsentieren nur die persönlichen Ansichten des Autors und stellen keine Anlageberatung dar.
3. Andere Sprachversionen des Artikels werden vom Gate Learn-Team übersetzt. Sofern nicht anders angegeben, darf der übersetzte Artikel nicht kopiert, verteilt oder plagiiert werden.