Encaminhar o Título Original: Vejo o Framework de Agente da Próxima Geração no Projeto89

Para ir direto ao ponto,@project_89adota uma abordagem totalmente nova para projetar um Framework de Agente. Este é um Framework de Agente de alto desempenho especificamente para o desenvolvimento de jogos. Comparado aos Frameworks de Agente atualmente utilizados, é mais modular e oferece melhor desempenho.

Este artigo demorou muito tempo para ser escrito, tentando fazer com que todos entendam que tipo de atualizações arquiteturais este framework fez em comparação com o framework tradicional do Agente. Ele foi revisado muitas vezes antes desta versão, mas ainda há algumas partes no artigo que são muito confusas. Devido a dificuldades técnicas, não pude popularizá-lo ainda mais. Se você tiver alguma sugestão para melhorar o artigo, por favor deixe seus comentários.

Antecedentes do Desenvolvedor

Uma vez que este é um blog técnico, vamos primeiro dar uma olhada na expertise técnica do fundador.

Antes de trabalhar no Projeto89, o fundador desenvolveu este projeto:https://github.com/Oneirocom/Magick, que também é um software de programação alimentado por IA. Além disso, Shaw é classificado como o quarto principal desenvolvedor deste projeto. Você também pode ver este projeto no portfólio de Shaw.

Superior esquerdo: o fundador do project89; Inferior direito: 'lalaune' é Shaw da ai16z

Hoje iremos apresentar principalmente o Framework de Agente de alta performance no projeto89:

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

1. Por que usar ECS para projetar um framework de agente?

Do ponto de vista da aplicação no campo do jogo

Jogos atualmente usando arquitetura ECS incluem:

Jogos blockchain: Mud, Dojo

Jogos tradicionais: Overwatch, Star Citizen, etc.

Além disso, os motores de jogos mainstream estão evoluindo em direção à arquitetura ECS, como Unity.

O que é ECS?

ECS (Entity-Component-System) é um padrão arquitetônico comumente usado no desenvolvimento de jogos e sistemas de simulação. Ele separa completamente os dados e a lógica para gerenciar eficientemente várias entidades e seus comportamentos em cenários escaláveis em grande escala:

Entidade

• Apenas um ID (número ou string), sem dados ou lógica.

• Você pode montar diferentes componentes para atribuir a ele várias propriedades ou capacidades conforme necessário.

Componente

• Usado para armazenar dados específicos ou estado de uma entidade.

Sistema

• Responsável por executar a lógica relacionada a certos componentes.

Vamos usar um exemplo específico de ação do Agente para entender esse sistema:

Em ArgOS, cada Agente é considerado uma Entidade, que pode registrar diferentes componentes. Por exemplo, na imagem abaixo, nosso Agente tem os seguintes quatro componentes:

Componente do Agente: armazena principalmente informações básicas como nome do Agente, nome do modelo, etc.

Componente de Percepção: Principalmente usado para armazenar dados externos percebidos

Componente de Memória: Principalmente usado para armazenar os dados de Memória da Entidade do Agente, coisas semelhantes que foram feitas, etc.

Componente de Ação: Armazena principalmente dados de Ação a serem executados

Fluxo do sistema:

1. Neste jogo, por exemplo, se você perceber uma arma na sua frente, então a função de execução do Sistema de Percepção será chamada para atualizar os dados no Componente de Percepção da Entidade do Agente.
2. Em seguida, acione o Sistema de Memória, chame o Componente de Percepção e o Componente de Memória ao mesmo tempo e persista os dados percebidos no banco de dados através da Memória.
3. Então, o Sistema de Ação chama o Componente de Memória e o Componente de Ação para obter informações sobre o ambiente circundante da memória e, finalmente, executa a ação correspondente.

Em seguida, obtemos uma Entidade de Agente de Atualização na qual os dados de cada Componente são atualizados.

4.Portanto, podemos ver que o Sistema aqui é principalmente responsável por definir quais Componentes executar a lógica de processamento correspondente.

E é óbvio que no projeto89 é um mundo cheio de vários tipos de Agentes. Por exemplo, alguns Agentes não só têm as habilidades básicas mencionadas acima, mas também têm a capacidade de fazer planos.

Então ficará como mostrado na imagem abaixo:

Fluxo de Execução do Sistema

No entanto, ao contrário dos frameworks tradicionais em que um sistema aciona diretamente outro (por exemplo, o Sistema de Percepção chamando o Sistema de Memória), no Project89, os sistemas não se chamam diretamente. Em vez disso, cada sistema é executado independentemente em intervalos de tempo fixos. Por exemplo:

• O Sistema de Percepção é executado a cada 2 segundos para atualizar o Componente de Percepção com os dados ambientais recém-recebidos.
• O Sistema de Memória é executado a cada 1 segundo, extraindo dados do Componente de Percepção e armazenando-os no Componente de Memória.
• O Sistema de Planejamento é executado a cada 1000 segundos, analisando os dados coletados para determinar se é necessário otimizar e criar um novo plano, que é então registrado no Componente de Planejamento.
• O Sistema de Ação é executado a cada 2 segundos, respondendo a mudanças ambientais e modificando ações com base em atualizações do Componente de Plano.

Até agora, este artigo simplificou significativamente a arquitetura do ArgOS para torná-la mais fácil de entender. Agora, vamos dar uma olhada mais de perto no verdadeiro sistema ArgOS.

2. Arquitetura do Sistema ArgOS

Para permitir que o Agente pense mais profundamente e realize tarefas mais complexas, a ArgOS projetou muitos Componentes e muitos Sistemas.

E o ArgOS divide o Sistema em "três níveis" (ConsciousnessLevel):

1) sistema CONSCIENTE

• Incluindo RoomSystem, PerceptionSystem, ExperienceSystem, ThinkingSystem, ActionSystem, CleanupSystem
• A frequência de atualização geralmente é mais alta (como a cada 10 segundos).
• Processamento mais próximo do nível "em tempo real" ou "consciente", como percepção ambiental, pensamento em tempo real, execução de ações, etc.

2) Sistema Subconsciente (SUBCONSCIENTE)

• GoalPlanningSystem, PlanningSystem
• A frequência de atualização é relativamente baixa (por exemplo, a cada 25 segundos).
• Lida com a lógica de "pensamento" como verificar/gerar periodicamente metas e planos.

3) Sistema inconsciente (INCONSCIENTE)

• Ainda não habilitado
• A frequência de atualização é mais lenta (como mais de 50 segundos),

Portanto, no ArgOS, diferentes Sistemas são divididos de acordo com o Nível de Consciência para estipular com que frequência este Sistema será executado.

Por que foi projetado desta forma?

Porque a relação entre vários sistemas no ArgOS é extremamente complexa, como mostrado abaixo:

1. O PerceptionSystem é responsável por coletar 'estímulos' do mundo exterior ou de outras entidades e atualizá-los para o componente de Percepção do Agente.

Determinar se o estímulo muda significativamente e atualizar de acordo com a estabilidade, modo de processamento (ATIVO/REFLEXIVO/AGUARDANDO), etc.

No final, os dados de "percepção atual" são fornecidos para o subsequente ExperienceSystem, ThinkingSystem, etc.

2.ExperienceSystem converte os estímulos coletados pelo PerceptionSystem em uma "experiência" mais abstrata.

LLM ou lógica de regra (extractExperiences) é chamado para identificar novas experiências e armazenado no componente de Memória.

Deduplicar, filtrar e verificar experiências, enquanto aciona eventos de "experiência" para outros sistemas ou ouvintes externos por meio do eventBus.

3. ThinkingSystem representa o processo de pensamento interno do agente.

Extrair o status atual de componentes como Memória e Percepção e gerar “ThoughtResult” através de generateThought(…) e lógica LLM/regra.

Com base no resultado do pensamento, pode:

• Atualizar pensamentos na Memória (histórico de pensamentos).

• Acionar uma nova ação (colocar em Action.pendingAction[eid]).

• Alterar a Aparência externa do agente (expressão, postura, etc.) e gerar Estímulos relacionados para que outras entidades “vejam” a mudança.

4. O ActionSystem executa ações seAção.pendingAction não está vazio, usando runtime.getActionManager().executeAction(…).

Após a execução, escreva o resultado de volta para Action.lastActionResult e notifique a sala ou outras entidades.

Isso também produz um Estímulo Cognitivo (estimulação cognitiva) para que os sistemas subsequentes “saibam” que a ação foi concluída, ou possa ser incorporada à memória.

5. O Sistema de Planejamento de Metas avalia periodicamente o progresso das metas na lista Goal.current[eid], ou verifica a memória externa/própria em busca de mudanças significativas (detectSignificantChanges).

Quando um novo objetivo ou ajuste de objetivo é necessário, gere e escreva Goal.current[eid] via generateGoals(...).

Ao mesmo tempo, o objetivo em andamento (in_progress) é atualizado. Se as condições de conclusão ou falha forem atendidas, o status é alterado e um sinal de conclusão/falha é enviado para o Plano correspondente.

6. O PlanningSystem gera ou atualiza o Plano (plano de execução) para o 'objetivo existente' (Goal.current[eid]).

Se for detectado que alguns objetivos não têm planos ativos correspondentes, gere um roteiro de execução contendo várias etapas através do generatePlan(...) e escreva-o em Plan.plans[eid].

Quando o objetivo for concluído ou falhar, o status do Plano associado a ele também será atualizado e será gerada a estimulação cognitiva correspondente.

7. O sistema de sala lida com atualizações relacionadas à sala:

• Obter a lista de ocupantes na sala (ocupantes) e gerar estímulos de 'aparência' para cada agente para que outras entidades 'vejam' sua aparência ou ações.

• Criar e correlacionar estímulo do ambiente da sala (por exemplo, informações apropriadas sobre "ambiente da sala").

Garantir que quando o Agente está em um ambiente espacial específico, outras entidades que estão sentindo o espaço consigam perceber mudanças em sua aparência.

8. O CleanupSystem encontra periodicamente e remove entidades marcadas com o componente Cleanup. Usado para reciclar estímulos ou outros objetos que não são mais necessários, a fim de evitar que um grande número de entidades inválidas fiquem na ECS.

• Exemplo: um loop de “ver o objeto” para “realizar a ação”

O exemplo de cena a seguir mostra como cada Sistema coopera para concluir um processo completo em uma rodada (ou vários quadros).

Preparação da cena: Há um Agente (EID=1) no Mundo, que está no estado "Ativo" e está em um Quarto (EID=100).

Uma nova propriedade "MagicSword" apareceu nesta Sala, e o Estímulo correspondente foi gerado.

1. PerceptionSystem detecta o aparecimento de “MagicSword”, gera um Estímulo (tipo=”item_appearance”) para o Agente(1) e adiciona-o a Perception.currentStimuli[1].Comparado com o último Hash de Estímulos, determina-se que há uma “mudança significativa” e o Estado de Processamento do agente é “reativado” (modo ATIVO).
2. ExperienceSystem vê que a Perception.currentStimuli do Agente(1) não está vazia, então extrai informações como 'Espada aparece' em uma ou mais novas Experiências (tipo: 'observação'). Armazena em Memory.experiences[1] e emite o evento 'experiência'.
3. ThinkingSystem lê informações de Memória, Percepção e outros estados e chama generateThought:

“Eu vi a MagicSword, talvez pegue e veja o que ela pode fazer…”O resultado do pensamento contém uma Ação a ser executada: { ferramenta: “pegarItem”, parâmetros: { nomeDoItem: “MagicSword” } }

ThinkingSystem escreve esta ação em Action.pendingAction[1].

Se houver uma mudança na aparência (por exemplo, "rosto com expressão curiosa"), a Aparência é atualizada e é gerada estimulação visual.

4. O ActionSystem vê Action.pendingAction[1] = { ferramenta: “pickUpItem”, parâmetros: … }。

Execute a lógica da ação 'pickup' através de runtime.getActionManager().executeAction('pickUpItem', 1, { itemName: 'MagicSword' }, runtime). Obtenha o resultado: { success: true, message: 'Você pegou a espada mágica' }, atualize para Action.lastActionResult[1] e acione o evento 'action' para ser transmitido para a sala (100).

Ao mesmo tempo, um estímulo cognitivo (tipo="action_result") é gerado, escrito na Memória ou capturado pelo ThinkingSystem na próxima jogada.

5. O Sistema de Planejamento de Objetivos (se o agente tiver objetivos) avalia periodicamente os objetivos do agente. Se um dos objetivos do agente neste momento for "obter uma arma poderosa" e detectar que a Espada Mágica foi obtida, o objetivo pode ser marcado como concluído. Se ocorrerem novas mudanças (por exemplo, "um novo objeto aparece na sala" afeta o objetivo perseguido pelo agente?), gere um novo objetivo ou abandone o antigo com base na detecção de mudanças significativas.
6. O sistema de planejamento (se houver um objetivo relacionado) verifica se é necessário um novo Plano ou se um Plano existente será atualizado para metas concluídas ou recém-geradas, como “Obter armas poderosas”.

Se concluído, defina o Plano associado [status] como "concluído", ou gere mais etapas se o objetivo for expandir o processo subsequente ("Pesquisar a Espada Mágica").

7. O RoomSystem atualiza a lista de Ocupantes e entidades visíveis na sala (100) (a cada quadro ou rodada).

Se a aparência do agente (1) mudar (por exemplo, Appearance.currentAction = 'segurando espada'), crie um novo estímulo visual 'aparência' para que o Agente2 e o Agente3 na mesma sala saibam que 'o agente1 pegou a espada'.

8. O CleanupSystem remove entidades ou estímulos que foram marcados (Limpeza). Se você não precisa mais manter o estímulo "MagicSword" após pegá-lo, você pode excluir a entidade de estímulo correspondente no CleanupSystem.

1. Através da conexão desses sistemas, o Agente de IA alcança:

• Perceber mudanças no ambiente (Percepção) → Registrar ou transformar em experiência interna (Experiência) → Auto-reflexão e tomada de decisão (Pensamento) → Colocar em ação (Ação) → Ajustar dinamicamente metas e planos (Definição de Objetivos + Planejamento) → Sincronizar o ambiente (Ambiente) → Reciclar entidades inúteis a tempo (Limpeza)

3. Análise da arquitetura geral do ArgOS

1. Camadas da Arquitetura Principal

2. Classificação de Componentes

Em ECS, cada entidade pode ter vários componentes. De acordo com sua natureza e ciclo de vida no sistema, os componentes podem ser divididos grosseiramente nas seguintes categorias:

1. Classes de Identidade Principais (Componentes de Nível de Identidade)

• Agente / Perfil do Jogador / Perfil do NPC, etc.

• Usado para identificar exclusivamente entidades, armazenar papéis centrais ou informações de unidades, e geralmente precisam ser persistidos no banco de dados.

2. Componentes de Comportamento e Estado

• Ação, Objetivo, Plano, Estado de Processamento, etc.

• Representa o que a entidade está atualmente tentando fazer ou quais são seus objetivos, bem como seu status de resposta a comandos externos e pensamentos internos.

• Contém pendingAction, goalsInProgress, plans e pensamentos ou tarefas na fila, etc.

• Estados tipicamente de médio/curto prazo, muitos mudando dinamicamente ao longo de rodadas de jogo ou ciclos de negócios.

• Se for necessário armazenar depende da situação. Se você deseja continuar a execução após uma interrupção, pode gravar periodicamente no banco de dados.

3. Componentes de Percepção e Memória

• Percepção, Memória, Estímulo, Experiência, etc.

• Registra as informações externas (Estímulos) percebidas pela entidade e as experiências refinadas nela após a percepção (Experiências).

• A memória muitas vezes pode acumular grandes quantidades de dados, como registros de conversas, histórico de eventos, etc.; a persistência muitas vezes é necessária.

• A percepção pode ser informação em tempo real ou temporária, na maioria das vezes válida a curto prazo. Você pode decidir se deve gravá-la no banco de dados de acordo com suas necessidades (por exemplo, apenas eventos de percepção importantes são armazenados).

4. Classes de ambiente e espaço (Room, OccupiesRoom, Spatial, Environment, Inventory, etc.)

• Representa informações como quartos, ambientes, localizações, recipientes de objetos, etc.

•Room.id, OcupaQuarto, Ambiente e outros campos precisam ser persistidos com frequência, como descrição da página inicial do quarto, estrutura de mapa, etc.

• A alteração de componentes (como uma Entidade se movendo entre salas) pode ser escrita de forma event-wise ou periodicamente.

5. Classes de aparência e interação (Aparência, EstadoUI, Relacionamento, etc.)

• Registre as partes externas "visíveis" ou "interativas" da entidade, como Avatar, pose, expressão facial, rede de relacionamento social com outras entidades, etc.

• Algumas partes podem ser processadas apenas em memória (representação em tempo real), enquanto outras partes (como relacionamentos sociais-chave) podem ser persistidas.

6. Componentes de utilidade e manutenção (Limpeza, DebugInfo, ProfilingData, etc.)

• Usado para marcar quais entidades precisam ser recicladas (Limpeza), ou registrar informações de depuração (Informações de Depuração) para uso em monitoramento e análise.

• Normalmente só existe na memória e raramente é sincronizado com o banco de dados, a menos que seja necessário para registro ou auditoria.

3. Arquitetura do Sistema

Já introduzido acima

4. Arquitetura do Gerente

Além dos Componentes e Sistemas, é necessária uma camada adicional de gestão de recursos. Esta camada lida com acesso ao banco de dados, conflitos de estado e outras operações essenciais.

Lado esquerdo: Sistemas (Sistema de Percepção, Sistema de Experiência, Sistema de Pensamento, etc.):

• Cada sistema é agendado para execução pelo SimulationRuntime no loop do ECS, consultando e processando as entidades que lhe interessam (por meio de condições de componente).

• Ao executar a lógica, você precisa interagir com os Gerentes, por exemplo:

• Chame o Gerenciador de Salas (RM) para consultar/atualizar informações da sala.
• Use StateManager (SM) para obter ou salvar o estado do mundo/agente, como Memória, Objetivo, Plano, etc.
• Transmita ou ouça eventos externamente usando o EventBus (EB).
• O PromptManager (PM) é chamado quando é necessário processamento de linguagem natural ou prompts.

Lado Direito: Gerentes (EventBus, RoomManager, StateManager, EventManager, ActionManager, PromptManager, etc):

• Fornecer funções de nível de sistema, que basicamente não “acionam” a lógica ativamente, mas são chamadas por Sistemas ou Runtime.

• Exemplos típicos:

• ActionManager especializa-se na gestão do registo e execução de ações.
• EventManager / EventBus é usado para mecanismos de publicação e inscrição de eventos.
• RoomManager gerencia quartos, layouts e ocupantes.
• O StateManager é responsável pela sincronização entre ECS e o banco de dados ou armazenamento.
• PromptManager fornece extensões como modelos de prompt LLM e gerenciamento de contexto.
• Simulação Intermediária do Tempo de Execução (R):

• É o "agendador" de todos os Sistemas, iniciando ou interrompendo ciclos do sistema em diferentes níveis (Consciente/Subconsciente, etc.);

• Os gerentes também são criados durante a fase de construção e passados para cada Sistema para uso.

• CleanupSystem:

• Note em particular que também interage com ComponentSync (CS), que é usado para remover componentes ou inscrições de eventos de forma síncrona ao reciclar entidades.

Em conclusão:

Cada sistema lerá e escreverá dados ou chamará serviços através do Gerenciador correspondente quando necessário, e o Tempo de Execução uniformemente agendará o ciclo de vida e o comportamento de todos os Sistemas e Gerenciadores em um nível superior.

5. Como vetores e bancos de dados interagem no ECS

Em um sistema ECS, os sistemas lidam com a execução lógica real, enquanto as operações do banco de dados (leitura/escrita) são gerenciadas por meio de um Gerenciador de Persistência (PersistenceManager / DatabaseManager) ou um Gerenciador de Estado (StateManager). O processo geral é o seguinte:

1. Carga Inicial (Fase de Inicialização ou Carregamento)

• StateManager / PersistenceManager carrega os dados dos componentes de persistência principais, como Agents, Rooms, Goals e assim por diante, do banco de dados, cria entidades correspondentes (Entidades) e inicializa os campos de componente relacionados.

• Por exemplo, leia um lote de registros de agentes e insira-os no mundo do ECS e inicialize Agente, Memória, Objetivo e outros componentes para eles.

2.ECS Runtime (Loop de Atualização de Sistemas)

• O sistema faz coisas em cada quadro (ou rodada): o PerceptionSystem coleta 'percepções' e as escreve no componente Percepção (na maioria das vezes, de curto prazo, fora da biblioteca).

O ExperienceSystem escreve a nova "experiência cognitiva" na Memory.experiences. Se for uma experiência-chave, também pode chamar o StateManager para armazenamento imediato ou marcá-lo com "needsPersistence" para escrita em lote subsequente.

ThinkingSystem / ActionSystem / GoalPlanningSystem etc. tomam decisões com base no conteúdo do componente e atualizam os campos no ECS.

Se alguns componentes (como Goal.current) passarem por grandes mudanças e exigirem persistência (como uma nova meta de longo prazo), notifique o StateManager para gravar esse campo no banco de dados por meio de escuta de componentes ou eventos do sistema.

3. Persistência Periódica ou Event-Driven

• Você pode chamar interfaces como PersistenceManager.storeComponentData(eid, "Goal") para descartar a biblioteca em determinados pontos-chave do sistema (como quando o plano de destino é atualizado ou quando ocorre um evento importante no Agente).

• Você também pode fazer com que o StateManager escaneie componentes ou entidades com a tag “needsPersistence” no CleanupSystem ou timer e os grave no banco de dados de uma vez só.

• Além disso, dados de log ou auditoria (como histórico de ações, registro de pensamentos) também podem ser arquivados e armazenados aqui.

4.Manual or Shutdown Save (Checkpointing & Persistence on Exit)

• Quando o servidor ou processo for desligado, use StateManager.saveAll() para escrever os dados não escritos no banco de dados de forma uniforme para garantir que o estado do ECS possa ser restaurado na próxima vez que for carregado.

• Para alguns cenários autônomos/offline, os arquivos também podem ser acionados manualmente.

• Processo de amostragem completo

O seguinte é um cenário simples para demonstrar as possíveis maneiras pelas quais os componentes e bancos de dados interagem:

1. Fase de inicialização: StateManager.queryDB("SELECT * FROM agents") → Obter um lote de registros de agentes, criar Entidade (EID=x) para cada registro por vez e inicializar os campos do Agente, Memória, Objetivo e outros componentes.

Ao mesmo tempo, carregue as informações do quarto da tabela "rooms" e crie uma entidade de Quarto.

2. Operações em Tempo de Execução: O PerceptionSystem detecta o evento "MagicSword aparece" em uma determinada sala e escreve Perception.currentStimuli[eid]. O ExperienceSystem converte Estímulos em Experiência e a atribui a Memory.experiences[eid]. O ThinkingSystem determina a próxima ação com base na Memória, Objetivo e outras informações e gera Action.pendingAction[eid]. Após o ActionSystem executar a ação, ele escreve o resultado em Memory ou Action.lastActionResult. Se este for um evento importante da trama, a parte mais recente de Memory.experiences[eid] será marcada como needsPersistence. Depois de um tempo, o StateManager encontra que Memory.experiences[eid] tem "needsPersistence" e o escreve no banco de dados (INSERT INTO memory_experiences...).

3. Parar ou Salvar Ponto de Verificação: Com base no agendamento do ECS ou do sistema, o StateManager.saveAll() é chamado quando o 'servidor é desligado' para gravar o status mais recente dos campos de componentes-chave (Agente, Memória, Meta, etc.) ainda na memória no banco de dados. Na próxima vez que você reiniciar, o estado do mundo ECS pode ser carregado e restaurado a partir do banco de dados.

• A categorização de componentes não só facilita a gestão clara dos dados de entidade no projeto, mas também nos ajuda a controlar os limites de dados entre "requer persistência" e "existe apenas na memória".

• A interação com o banco de dados é normalmente tratada por um Gerenciador especializado (como o StateManager), e os Sistemas operam através dele quando precisam ler e escrever no banco de dados, evitando escrever diretamente instruções SQL ou similares de baixo nível no Sistema.

• Dessa forma, você pode desfrutar simultaneamente da eficiência lógica e flexibilidade do ECS, bem como das vantagens de persistência, retomada de ponto de interrupção e análise estatística de dados trazidas pelo banco de dados.

4. Inovações Arquitetônicas

Os destaques de toda a arquitetura são:

• Cada sistema é executado independentemente e não possui relação de chamada com outros sistemas. Portanto, mesmo que desejemos implementar as capacidades de 'Perceber mudanças no ambiente (Percepção) → Registrar ou transformar em experiência interna (Experiência) → Auto-reflexão e tomada de decisão (Pensamento) → Colocar em ação (Ação) → Ajustar dinamicamente metas e planos (Planejamento de Metas + Planejamento) → Sincronizar o ambiente (Sala) → Reciclar entidades inúteis em tempo hábil (Limpeza)', cada sistema terá muitas interdependências em função, mas ainda podemos usar a arquitetura ECS para estruturar o todo em sistemas independentes. Cada sistema ainda pode ser executado independentemente e não interagirá com outros sistemas. Existem pessoas e relacionamentos de acoplamento.
• Eu acredito que esta também é a principal razão pela qual o Unity tem migrado cada vez mais para a arquitetura ECS nos últimos anos.
• E por exemplo, eu só quero que um Agente tenha algumas capacidades básicas. Só preciso reduzir o registro de alguns Componentes e o registro do Sistema ao definir a Entidade, o que pode ser facilmente alcançado sem alterar algumas linhas de código.

Como mostrado abaixo:

Ao mesmo tempo, se você deseja adicionar novas funções durante o processo de desenvolvimento, não terá nenhum impacto em outros sistemas e você pode carregar facilmente as funções que deseja.

• Além disso, o desempenho da arquitetura atual é realmente muito melhor do que o da arquitetura orientada a objetos tradicional. Isso é um fato reconhecido no círculo de jogos, porque o design do ECS é mais adequado para concorrência, então quando usamos o ECS em cenários complexos de Defai, A arquitetura também pode ter mais vantagens, especialmente em cenários em que se espera que os agentes sejam usados para transações quantitativas, o ECS também será útil (não apenas em cenários de jogos de agentes).
• Dividir o sistema em consciente, subconsciente e inconsciente para distinguir com que frequência diferentes tipos de sistemas devem ser executados é um design extremamente inteligente e já é uma habilidade humana muito concreta.

Do meu ponto de vista pessoal, este é um framework extremamente modular com excelente desempenho. A qualidade do código também é muito alta e contém bons documentos de design. Infelizmente, o Projeto89 tem tido falta de visibilidade e promoção para este framework, por isso passei quatro dias escrevendo este artigo para destacar suas qualidades. Acredito que grandes tecnologias merecem reconhecimento e, amanhã, planejo lançar uma versão em inglês deste artigo para aumentar a conscientização entre as equipes de jogos e os desenvolvedores de DeFi (Finanças Descentralizadas). Espero que mais equipes explorem este framework como uma escolha arquitetônica potencial para seus projetos!

Aviso Legal:

1. Este artigo é reproduzido de [0xhhh]. Encaminhar o Título Original: Vejo o Quadro do Agente da Próxima Geração no Projeto89. Os direitos autorais pertencem ao autor original [0xhhh]. Se você tiver qualquer objeção à reprodução, por favor entre em contato com Gate Learnequipe, a equipe irá lidar com isso o mais rápido possível de acordo com os procedimentos relevantes.
2. Aviso Legal: As visões e opiniões expressas neste artigo representam apenas as visões pessoais do autor e não constituem nenhum conselho de investimento.
3. Outras versões do artigo em outros idiomas são traduzidas pela equipe Learn da gate. A menos que seja declarado o contrário, o artigo traduzido não pode ser copiado, distribuído ou plagiado.