Encaminhar o Título Original: Vejo a Estrutura de Agente da Próxima Geração no Project89

Para ir direto ao ponto, @project_89adota uma abordagem completamente nova ao 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, ele é mais modular e oferece melhor desempenho.

Este artigo levou muito tempo para ser escrito, tentando fazer com que todos entendam que tipo de atualizações arquitetônicas este framework fez em comparação ao tradicional framework 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 consegui 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 experiência técnica do fundador.

Antes de trabalhar no Project89, o fundador desenvolveu este projeto:https://github.com/Oneirocom/Magick, que também é um software de programação com inteligência artificial. Além disso, Shaw está 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 principalmente apresentar o Framework de Agente de alto desempenho 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 de jogo

Os jogos que atualmente usam a arquitetura ECS incluem:

Jogos de 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 arquitetural comummente utilizado no desenvolvimento de jogos e sistemas de simulação. Separa completamente os dados e a lógica para gerir 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 dar-lhe várias propriedades ou capacidades conforme necessário.

Componente

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

Sistema

• Responsável pela execução da lógica relacionada a certos componentes.

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

No ArgOS, cada Agente é considerado uma Entidade, que pode registar diferentes componentes. Por exemplo, na imagem abaixo, o 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 utilizado para armazenar dados externos percebidos

Componente de Memória: Usado principalmente para armazenar os dados de memória da Entidade Agente, coisas semelhantes que já 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 sentir uma arma à sua frente, então a função de execução do Sistema de Perceção será chamada para atualizar os dados no Componente de Perceção da Entidade 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 por meio da Memória.
3. Em seguida, o Sistema de Ação chama o Componente de Memória e o Componente de Ação para obter informações do ambiente circundante da memória e, finalmente, executar a ação correspondente.

Em seguida, obtemos uma Entidade de Agente de Atualização na qual cada dado do Componente é atualizado.

4.Assim, 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 Agents. Por exemplo, alguns Agents não só têm as habilidades básicas 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 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 Planeamento é executado a cada 1000 segundos, analisando os dados recolhidos para determinar se é necessário otimizar e criar um novo plano, que é então registado no Componente de Planeamento.
• 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 Planejamento.

Até agora, este artigo simplificou significativamente a arquitetura do ArgOS para torná-lo mais fácil de entender. Agora, vamos dar uma olhada mais de perto no sistema real do 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 CONSCIOUS

• Incluindo RoomSystem, PerceptionSystem, ExperienceSystem, ThinkingSystem, ActionSystem, CleanupSystem)
• A frequência de atualização é geralmente maior (como a cada 10 segundos).
• Processamento mais próximo do nível "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 lógica de "pensamento" como verificar/gerar periodicamente metas e planos.

3) Sistema inconsciente (INCONSCIENTE)

• Ainda não está 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 esse Sistema será executado.

Por que foi projetado dessa maneira?

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

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

Determine se o estímulo muda significativamente e atualize-o de acordo com a estabilidade, modo de processamento (ATIVO/REFLEXIVO/ESPERANDO), etc.

Em última análise, os dados de "percepção atual" são fornecidos para o subsequente ExperienceSystem, ThinkingSystem, etc.

2. O sistema de experiência converte os estímulos coletados pelo sistema de percepção em uma "experiência" mais abstrata.

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

Deduplicar, filtrar e verificar experiências, ao mesmo tempo que aciona eventos de “experiência” para outros sistemas ou ouvintes externos através do eventBus.

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

Extrair o estado 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 pensamento).

• Desencadear 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 permitir que outras entidades "vejam" a mudança.

4. O sistema de ação executa ações seAção.pendentenão está vazio, usandoruntime.getActionManager().executeAction(…).

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

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

5. O Sistema de Planeamento de Objetivos avalia periodicamente o progresso dos objetivos na lista Goal.current[eid], ou verifica a memória externa/própria por alterações significativas (detectarAlteraçõesSignificativas).

Quando um novo objetivo ou ajuste de objetivo é necessário, gerar e escrever Goal.current[eid] através de generateGoals(…).

Ao mesmo tempo, o objetivo em progresso (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 sistema de planeamento gera ou atualiza o Plano (plano de execução) para o "objetivo existente" (Goal.current[eid]).

Se for detetado que alguns objetivos não têm planos ativos correspondentes, gerar uma rota de execução contendo vários passos através de generatePlan(…) e escrevê-la em Plan.plans[eid].

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

7. O RoomSystem lida com atualizações relacionadas ao quarto:

• Obter a lista de ocupantes no quarto (ocupantes) e gerar estímulos de “aparência” para cada agente para que outras entidades possam “ver” a sua aparência ou ações.

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

Certifique-se de que, quando o Agente estiver em um ambiente espacial específico, outras entidades que estão sentido o espaço possam perceber mudanças em sua aparência.

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

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

O exemplo de cena a seguir mostra como cada sistema coopera para completar 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á numa Sala (EID=100).

Uma nova prop "MagicSword" apareceu nesta sala e foi gerado o estímulo correspondente.

1. PerceptionSystem deteta a aparência de 'MagicSword', gera Estímulo (tipo='item_appearance') para Agente(1) e adiciona-o a Perception.currentStimuli[1]. Comparado com o último estímulo Hash, é determinado que há uma 'mudança significativa' e o estado de processamento do agente é 'reativado' (modo ATIVO).
2. O ExperienceSystem verifica que o Perception.currentStimuli do Agente(1) não está vazio, por isso extrai informações como “Espada aparece” em uma ou mais novas Experiências (tipo: “observação”). Armazena-o em Memory.experiences[1] e emite o evento “experiência”.
3. ThinkingSystem lê Memória, Percepção e outras informações de estado e chama generateThought:

“Vi a MagicSword, talvez pegá-la e ver 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 para 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 de 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 ative o evento “action” para ser transmitido para a sala (100).

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

5. O Sistema de Planeamento 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 detetar que a Espada Mágica foi obtida, o objetivo pode ser marcado como concluído. Se ocorrerem novas mudanças (por exemplo, "novo objeto aparece na sala") que afetem o objetivo perseguido pelo agente, gera-se um novo objetivo ou abandona-se o objetivo antigo com base na deteção de mudanças significativas.
6.PlanningSystem (se houver um objetivo relacionado) verifica se é necessário um novo Plano ou se um Plano existente é atualizado para objetivos concluídos ou recém-gerados, como "Obter armas poderosas".

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

7. O sistema do quarto atualiza a lista de ocupantes e entidades visíveis no quarto (100) (a cada quadro ou rodada).

Se a aparência do agente(1) mudar (por exemplo, Appearance.currentAction = “segurando a espada”), crie um novo estímulo visual de “aparência” para que os Agentes 2 e 3 na mesma sala saibam que “o agente 1 pegou a espada”.

8.CleanupSystem remove entidades ou estímulos que foram marcados (Limpeza). Se já não precisar de manter o Estímulo “MagicSword” depois de o apanhar, pode eliminar a entidade de Estímulo correspondente em CleanupSystem.

1. Através da conexão destes 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 (Planejamento de Metas + Planejamento) → Sincronizar o ambiente (Sala) → Reciclar entidades inúteis de forma oportuna (Limpeza)

3. Análise da arquitetura geral do ArgOS

1. Camadas de Arquitetura Principal

2. Classificação do Componente

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

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

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

• Usado para identificar exclusivamente entidades, armazenar funções principais 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.

• Normalmente estados de médio/curto prazo, muitos mudando dinamicamente ao longo das rodadas do jogo ou ciclos de negócios.

• Se é necessário repor depende da situação. Se quiser continuar a executar após um ponto de interrupção, pode escrever periodicamente na base de dados.

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

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

• Regista a informação externa (Estímulos) percebida pela entidade, e as experiências refinadas nela após a perceçã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 é frequentemente necessária.

• A percepção pode ser informações em tempo real ou temporárias, principalmente válidas a curto prazo. Você pode decidir se deseja gravá-la no banco de dados de acordo com suas necessidades (por exemplo, armazenar apenas eventos de percepção importantes).

4. Classes de ambiente e espaço (Sala, OcupaSala, Espacial, Ambiente, Inventário, etc.)

• Representa informações como quartos, ambientes, locais, contêineres de objetos, etc.

•Room.id, Ocupa quarto, 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 a mover-se entre salas) pode ser escrita por eventos ou periodicamente.

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

• Registar as partes externas "visíveis" ou "interativas" da entidade, tais como Avatar, pose, facialExpression, rede de relacionamento social com outras entidades, etc.

• Algumas partes podem ser processadas apenas na 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, Dados de Perfis, etc.)

• Usado para marcar quais entidades precisam ser recicladas (Limpeza), ou registrar informações de depuração (DebugInfo) 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 registo ou auditoria.

3. Arquitetura do Sistema

Já apresentado acima

4. Arquitetura do Gerente

Além de Componentes e Sistemas, é necessária uma camada adicional de gestão de recursos. Esta camada trata do acesso à base de dados, conflitos de estado e outras operações essenciais.

Lado esquerdo: Sistemas (PerceptionSystem, ExperienceSystem, ThinkingSystem, etc.):

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

• Ao executar lógica, precisa de interagir com Gestores, por exemplo:

• Chame o RoomManager (RM) para consultar/atualizar informações do quarto.
• Utilize o StateManager (SM) para obter ou salvar o estado do mundo/agente, como Memória, Objetivo, Plano, etc.
• Transmitir ou ouvir eventos externamente usando EventBus (EB).
• PromptManager (PM) é chamado quando é necessária a processamento de linguagem natural ou prompts.

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

• Fornecer funções no nível do sistema, que basicamente não "conduzem" ativamente a lógica, mas são chamadas por Sistemas ou Tempo de Execução.

• Exemplos típicos:

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

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

• Os gestores 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 em eventos de forma síncrona ao reciclar entidades.

Em conclusão:

Cada Sistema lerá e escreverá dados ou chamará serviços através do Gestor correspondente quando necessário, e o Tempo de Execução agendará uniformemente o ciclo de vida e o comportamento de todos os Sistemas e Gestores a um nível mais elevado.

5. Como os Vetores e Bancos de Dados Interagem no ECS

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

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

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

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

2. Tempo de Execução do ECS (Loop de Atualização de Sistemas)

• O sistema realiza ações em cada quadro (ou rodada): o PerceptionSystem coleta 'percepções' e as escreve no componente de Percepção (principalmente de curto prazo fora da biblioteca).

ExperienceSystem escreve a nova "experiência cognitiva" em Memory.experiences. Se for uma experiência chave, também pode chamar StateManager para armazenamento imediato, ou marcá-la 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 o Goal.current) sofrerem grandes alterações e exigirem persistência (como um novo objetivo de longo prazo), notifique o StateManager para escrever esse campo no banco de dados por meio de escuta de componentes ou eventos do sistema.

3. Persistência Periódica ou Orientada por Eventos

• Você pode chamar interfaces como PersistenceManager.storeComponentData(eid, 'Goal') para descartar a biblioteca em certos 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 verifique componentes ou entidades com a marca 'needsPersistence' no CleanupSystem ou no temporizador e as escreva de volta no banco de dados de uma vez.

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

4. Salvar manualmente ou desligar (Checkpointing & Persistência na saída)

• Quando o servidor ou processo deve ser 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 amostra completo

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

1. Fase de arranque: StateManager.queryDB("SELECT * FROM agents") → Obter um lote de registos de agentes, criar Entidade (EID=x) para cada registo sequencialmente e inicializar os campos do Agente, Memória, Objetivo e outros componentes.

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

2. Operações em Tempo de Execução: O PerceptionSystem detecta o evento 'aparecimento de MagicSword' em um determinado quarto e escreve Perception.currentStimuli[eid]. O ExperienceSystem converte os estímulos em Experiências e os 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 a execução da ação pelo ActionSystem, o resultado é gravado 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. Após algum tempo, o StateManager verifica que Memory.experiences[eid] tem 'needsPersistence' e o grava no banco de dados (INSERT INTO memory_experiences...).

3.Parar ou Verificar Ponto de Controlo: Com base no agendamento do ECS ou do sistema, o StateManager.saveAll() é chamado quando o “servidor é desligado” para escrever o estado mais recente dos campos de componentes-chave (Agente, Memória, Objetivo, etc.) ainda em memória para a base de dados. Da próxima vez que reiniciar, o estado do mundo ECS pode ser carregado e restaurado a partir da base de dados.

• A categorização de componentes não só facilita a gestão clara de dados de entidades 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 geralmente é tratada por um Gerenciador especializado (como o StateManager), e os Sistemas operam por meio 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 proporcionadas pelo banco de dados.

4. Inovações Arquitetônicas

Os destaques de toda a arquitetura são:

• Cada Sistema funciona de forma independente e não tem relação de chamada com outros Sistemas. Portanto, mesmo que queiramos implementar as capacidades do Agente "Perceber mudanças no ambiente (Percepção) → Registrar ou transformar em experiência interna (Experiência) → Auto-pensamento e tomada de decisão (Pensamento) → Colocá-lo em ação (Ação) → Ajustar dinamicamente metas e planos (Planeamento de Objetivos + Planeamento) → Sincronizar o ambiente (Ambiente) → Reciclar entidades inúteis a tempo (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 funcionar de forma independente e não interagirá com outros sistemas. Existem pessoas e relações de acoplamento.
• Penso que esta é também a principal razão pela qual a 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 desejar adicionar novas funções durante o processo de desenvolvimento, isso não terá qualquer impacto sobre outros sistemas e poderá facilmente carregar as funções que deseja.

• Além disso, o desempenho da arquitetura atual é na verdade muito melhor do que o da arquitetura tradicional orientada a objetos. Este é um fato reconhecido no círculo de jogos, porque o design do ECS é mais adequado para a concorrência, então quando usamos o ECS em cenários Defai complexos, a arquitetura também pode ter mais vantagens, especialmente em cenários onde 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 capacidade 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 Project89 tem faltado visibilidade e promoção para este framework, razão pela qual passei quatro dias escrevendo este artigo para destacar os seus pontos fortes. Acredito que grandes tecnologias merecem reconhecimento e, amanhã, pretendo lançar uma versão em inglês deste artigo para aumentar a conscientização entre as equipes de jogos e 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 Framework do Agente da Próxima Geração no Projeto89. Os direitos de autor pertencem ao autor original [gate0xhhh]. Se tiver alguma objeção à reprodução, por favor entre em contato Gate Learnequipa, a equipa irá tratar disso o mais breve possível de acordo com os procedimentos relevantes.
2. Aviso: As opiniões expressas neste artigo representam apenas as opiniões pessoais do autor e não constituem qualquer conselho de investimento.
3. Outras versões do artigo são traduzidas pela equipe de Aprendizagem da Gate. Salvo indicação em contrário, o artigo traduzido não pode ser copiado, distribuído ou plagiado.