# Sistema de Evolução Inteligente EvoX e Práticas de Pesquisa AI Native — Material Didático do Curso

Duração da aula: 1 · Páginas do material: 16

## Navegação de Leitura

- [Aula 6｜Tema: Evolução Contínua em Nível de Sistema: Genesis e a Sedimentação do Mundo de Software](#lecture-lesson-1)

---

<a id="lecture-lesson-1"></a>

## Aula 6｜Tema: Evolução Contínua em Nível de Sistema: Genesis e a Sedimentação do Mundo de Software

<a id="lecture-page-1"></a>

### Evolução Contínua em Nível de Sistema: Genesis e a Sedimentação do Mundo de Software

*Página 1*

> **Objetivo da página:** Aprender como o Genesis, por meio da colaboração multi-Agente e de mecanismos rigorosos de verificação, permite que o código de um projeto se acumule e evolua continuamente ao longo de seu ciclo de vida.

> **Objetivo da página**
>
> Como um projeto não apenas completa uma codificação, mas faz com que o código se acumule e evolua continuamente ao longo de todo o ciclo de vida. Há duas linhas centrais: primeiro, o padrão de engenharia constituído pela colaboração multi-Agente e pela decomposição recursiva de tarefas; segundo, o mecanismo pelo qual compilação, testes e aceitação sedimentam modificações válidas no histórico do projeto.

**Pontos-chave de ensino**

- 1. Comece destacando o significado de "evolução contínua". Software não é um produto que se define ao ser escrito, mas uma entidade constantemente modificada, complementada e refatorada ao longo do tempo. A posição do Genesis é justamente fornecer uma forma organizacional executável para essa evolução de longo prazo, e não uma técnica de geração única de código. 2. A colaboração multi-Agente resolve "quem divide o trabalho". Diante de um projeto real, a escala da tarefa frequentemente excede a capacidade de processamento de uma única vez, portanto são necessários divisão de papéis e fluxo de colaboração, tornando as responsabilidades de cada etapa claras e rastreáveis. 3. A decomposição recursiva de tarefas resolve "como começar". Um objetivo maior é decomposto camada por camada em pequenas tarefas executáveis, até que cada subtarefa seja suficientemente específica para ser concluída e verificada independentemente. Isso reduz a dificuldade de cada passo e permite que o resultado de cada etapa seja avaliado separadamente. 4. A verificação rigorosa resolve "por que conta como válido". Compilação aprovada, testes aprovados e aceitação aprovada são três portões que se estreitam progressivamente. Somente modificações que cruzam esses portões têm qualificação para serem escritas no histórico do projeto
- modificações não aprovadas são descartadas ou retrabalhadas. A colaboração e a decomposição produzem um grande número de modificações candidatas, a verificação é responsável pela triagem, e os resultados filtrados sedimentam-se no histórico do projeto, que por sua vez se torna o ponto de partida da próxima rodada de evolução. Este é o circuito completo da "evolução contínua em nível de sistema".

**Verificação de compreensão**

Peça aos alunos que expliquem com suas próprias palavras a relação de ordem entre "decomposição—verificação—sedimentação" e respondam: se uma modificação passou na compilação mas não passou nos testes, em que estado ela se encontraria no mecanismo descrito nesta página? O professor confirma com isso se o aluno realmente entendeu o papel dos portões de verificação, e não apenas memorizou os termos.

> **Dica de transição**
>
> Esta página estabelece o quadro geral; o conteúdo subsequente entrará em práticas e exemplos mais específicos. Após confirmar que os alunos conseguem recontar esse circuito, prossiga para os detalhes específicos.

<a id="lecture-page-2"></a>

### Limites de Capacidade dos Grandes Modelos e a Necessidade de Evolução em Nível de Sistema

*Página 2*

> **Objetivo da página:** Compreender os limites de capacidade dos grandes modelos atuais no desenvolvimento de sistemas complexos e a necessidade de construir sistemas em evolução contínua.

> **Objetivo da página**
>
> Compreender os limites de capacidade dos grandes modelos no desenvolvimento de sistemas complexos e por que é necessário incorporar componentes inteligentes em um ciclo de sistema que possa evoluir continuamente ao longo do ciclo de vida.

> **Sequência de exposição**
>
> Grandes modelos são componentes inteligentes poderosos, mas não são sistemas capazes de se autossustentar. Eles já possuem capacidades utilizáveis em compreensão, geração, raciocínio e chamada de ferramentas, podendo atuar como proponentes de hipóteses de alta qualidade e produtores de código; no entanto, carecem de estado, objetivos e mecanismos de feedback necessários para a evolução contínua ao longo do ciclo de vida.
>
> Compreensão, geração, raciocínio, chamada de ferramentas, resultando em um instantâneo estático; ao final da sessão, o estado é zerado. À direita, o grande modelo é incorporado como um pequeno módulo no ciclo de evolução em nível de sistema: propor, avaliar, selecionar, sedimentar. O grande modelo é responsável por propor; modelos proxy são usados para reduzir o custo de avaliação; a etapa de seleção lida com trade-offs multiobjetivo; a sedimentação forma memória entre sessões; a inteligência de enxame mantém a diversidade de candidatos e retorna à próxima rodada de proposição.
>
> Limite de estado — janela de contexto limitada, falta de memória persistente entre sessões, projetos de longo prazo não conseguem se autossustentar; limite de objetivos — problemas reais frequentemente envolvem conflitos multiobjetivo e trade-offs de preferências, e o modelo dificilmente fornece critérios de escolha defensáveis de forma autônoma; limite de feedback — falta de mecanismos executáveis de avaliação, seleção e eliminação, as soluções geradas não podem ser objetivamente verificadas e iterativamente retidas.
>
> Melhoria na capacidade do modelo não equivale a melhoria na capacidade do sistema. Capacidade é um instantâneo, o ambiente é um processo. Somente incorporando o grande modelo no ciclo de evolução "geração—avaliação—seleção—sedimentação", mantendo a diversidade com inteligência de enxame, comprimindo o custo de avaliação com modelos proxy, e retendo experiências válidas com seleção e sedimentação, a inteligência pode manter-se adaptativa em ambientes dinâmicos. Este é também o ponto de ancoragem do EvoX.

**Pontos-chave de ensino**

- Grandes modelos possuem forte capacidade de compreensão e geração, mas não conseguem evoluir sistemas de forma independente. Sistemas complexos do mundo real requerem capacidade de evolução contínua ao longo do ciclo de vida; instantâneos estáticos são insuficientes para lidar com mudanças ambientais. Componentes inteligentes precisam de mecanismos de evolução para se adaptar a ambientes dinâmicos; os mecanismos-chave incluem ciclo de evolução, inteligência de enxame e modelos proxy. Limite de estado, limite de objetivos, limite de feedback.

**Tratamento dos exercícios**

A questão de conceito central deve escolher "compreender os limites de capacidade dos grandes modelos atuais no desenvolvimento de sistemas complexos e a necessidade de construir sistemas em evolução contínua".

As demais questões de julgamento devem priorizar a opção "capaz de explicar com evidências ou exemplos"; apenas por intuição, pulando a consulta de materiais, ou alterando todos os fatores simultaneamente para comparar, não atende aos requisitos desta página.

Quando a resposta estiver correta, pode-se afirmar que o aluno consegue conectar com os conceitos desta página e explicar a base; quando incorreta, oriente a retornar à exposição para encontrar evidências ou exemplos-chave, revisando com foco os três tipos de limites e o ciclo "propor—avaliar—selecionar—sedimentar".

Primeiro explique que a ideia central é "grandes modelos possuem forte capacidade de compreensão e geração, mas não conseguem evoluir sistemas de forma independente", depois dê exemplos de por que sistemas complexos precisam de capacidade de evolução contínua ao longo do ciclo de vida.

**Verificação de compreensão**

Peça aos alunos que expliquem com suas próprias palavras "por que a melhoria na capacidade do modelo não equivale à melhoria na capacidade do sistema" e identifiquem pelo menos dois dos três tipos de limites: estado, objetivos e feedback. Se o aluno conseguir explicar claramente a relação do monólito de capacidade para o ciclo de evolução, pode-se avançar para a próxima página; caso contrário, retorne ao diagrama comparativo e reveja as duas rotas à esquerda e à direita.

> **Dica de transição**
>
> Após confirmar que os alunos conseguem expressar a relação central de que "o grande modelo é um componente, o ciclo de evolução é o sistema", prossiga para o conteúdo subsequente sobre evolução contínua em nível de sistema, Genesis e sedimentação do mundo de software.

<a id="lecture-page-3"></a>

### Expansão das Fronteiras de Evolução: de Parâmetros Numéricos a Sistemas de Programas

*Página 3*

> **Objetivo da página:** Dominar como os grandes modelos expandem o objeto de evolução de parâmetros numéricos tradicionais para programas, estruturas de modelos e estados de sistema.

> **Objetivo da página**
>
> Dominar como os grandes modelos expandem o objeto de evolução de parâmetros numéricos tradicionais para programas, estruturas de modelos e estados de sistema, e compreender as condições impulsionadoras dessa expansão de fronteiras e as mudanças na avaliação.

> **Sequência de exposição**
>
> O objeto geralmente é um vetor de parâmetros numéricos de baixa dimensão e predefinido, como hiperparâmetros, pesos, variáveis contínuas; o espaço de busca é limitado por estruturas e codificações predefinidas manualmente.
>
> Com a expansão da escala computacional e da base de engenharia, a busca por objetos de alta dimensão, discretos e estruturados tornou-se viável, e as fronteiras de busca se expandem em sincronia com o poder computacional e a cadeia de ferramentas.
>
> Com capacidade de compreensão de código, raciocínio contextual e geração de candidatos, é possível construir, modificar e avaliar diretamente objetos em nível de programa, reduzindo a dependência de codificações e operadores de mutação projetados manualmente.
>
> Se o método de geração de candidatos ainda for fixado manualmente, o sistema apenas repetirá padrões estabelecidos; incorporar o próprio método de geração de candidatos como objeto de evolução, como as estratégias de mutação e configurações de parâmetros da evolução diferencial, é justamente a manifestação da expansão de fronteiras.
>
> De baixo para cima: parâmetros numéricos → estrutura do modelo → mecanismo do algoritmo → estado de programação e engenharia de software; para cima, a dimensionalidade do espaço de busca e a complexidade semântica aumentam; à direita está o suporte da capacidade do grande modelo; acima estão as restrições de verificação executável e custo de engenharia.
>
> Quanto mais alto o nível, mais fortes as restrições semânticas, mais longa a cadeia de avaliação, e os candidatos devem ser executáveis e verificáveis; a avaliação de aptidão passa de uma função escalar para um julgamento conjunto de resultados de execução e restrições de engenharia.
>
> Isso não substitui a otimização de parâmetros, mas incorpora a otimização de parâmetros em um ciclo maior de evolução de programas e sistemas, formando um espectro contínuo do ajuste local de parâmetros à melhoria em nível de sistema.

**Pontos-chave de ensino**

- A expansão da escala computacional traz fronteiras de busca mais amplas. Grandes modelos podem compreender código e contexto e construir candidatos complexos. O objeto de evolução se expande de parâmetros numéricos para programas e estados de engenharia de software, passando por estruturas de modelos e mecanismos de algoritmos. Primeiro, a expansão do poder computacional e da base de engenharia; segundo, a capacidade dos grandes modelos de compreensão de código, raciocínio contextual e geração de candidatos.

**Cobertura de palavras-chave**

- Parâmetros numéricos, estrutura do modelo, mecanismo do algoritmo, estado de programação e engenharia de software, fronteira de busca, compreensão de código, raciocínio contextual, construção de candidatos, verificação executável, custo de engenharia, avaliação de aptidão, espectro contínuo. Tratamento dos exercícios e feedback: Grandes modelos expandem o objeto de evolução de parâmetros numéricos tradicionais para programas, estruturas de modelos e estados de sistema. Se a resposta estiver desviada, oriente a retornar à frase conceitual e tentar novamente. Grandes modelos podem compreender código e contexto de execução, e com base nisso construir e modificar candidatos complexos em nível de programa
- opções incorretas frequentemente restringem grandes modelos a parâmetros numéricos codificados manualmente. A direção correta dos exercícios 3, 4 e 5 não é memorizar, seguir a intuição ou alterar todos os fatores simultaneamente, mas sim explicar conclusões relevantes com evidências ou exemplos. O feedback pode enfatizar: só se considera verdadeiramente dominado quando se consegue conectar com os conceitos desta página e explicar a base. A equipe primeiro ajusta apenas hiperparâmetros numéricos como taxa de aprendizado, tamanho do lote, número de camadas da rede
- em seguida, faz o grande modelo ler os scripts de treinamento e logs de execução, reescrever diretamente a implementação do otimizador, o pipeline de dados e o fluxo de controle do algoritmo, e então submeter os candidatos à execução em tempo de execução com retorno de métricas, para a próxima rodada de evolução em nível de programa. Pode-se perguntar: qual é a ideia central? Quais são as duas condições que impulsionam a expansão? Pontos-chave da resposta: a evolução tradicional tem como objeto vetores de parâmetros numéricos de baixa dimensão, com espaço de busca limitado por predefinições manuais
- a expansão do poder computacional e da base de engenharia torna tratável a busca de alta dimensão, discreta e estruturada
- grandes modelos podem construir e reescrever objetos em nível de programa, então o objeto de evolução se expande camada por camada para estruturas de modelos, mecanismos de algoritmos e estados de programação ou engenharia de software. Em seguida pergunte: como os grandes modelos participam da construção e avaliação de candidatos em nível de programa? Pontos-chave da resposta: ler scripts e contexto de execução, reescrever otimizadores ou fluxos de controle para gerar candidatos executáveis
- executar em tempo de execução e verificar se é executável, depois comparar com restrições de engenharia como recursos e orçamento de tempo, e o retorno de métricas impulsiona a próxima rodada de evolução.

**Verificação de compreensão**

Peça aos alunos que recontem com suas próprias palavras a cadeia de expansão de níveis e complementem com a capacidade do grande modelo à direita e as restrições de verificação e custo acima. Pode-se perguntar adicionalmente: "Por que quanto mais alto o nível, mais a avaliação de aptidão se assemelha a um julgamento conjunto de resultados de execução e restrições de engenharia?" Confirme se os alunos conseguem mencionar razões como executabilidade, verificabilidade e alongamento da cadeia de avaliação.

> **Dica de transição**
>
> Após confirmar que os alunos conseguem distinguir a relação entre otimização de parâmetros e evolução em nível de programa ou sistema, prossiga para a próxima página sobre colaboração multi-agente e sedimentação por verificação.

<a id="lecture-page-4"></a>

### Desafios Complexos do Mundo Real: Trade-offs Multiobjetivo e Manutenção de Diversidade

*Página 4*

> **Objetivo da página:** Compreender a complexidade de objetivos mutuamente restritivos em problemas do mundo real e a importância de preservar soluções candidatas diversificadas.

**Pontos-chave de ensino**

- Sob múltiplos objetivos não há ordem total natural. Ao ver um conjunto de candidatos, primeiro pergunte "sob quais preferências estamos comparando", depois discuta vantagens; caso contrário, é fácil confundir preferências pessoais com conclusões objetivas.
- Manter apenas o ótimo atual leva a população à convergência prematura e ao colapso de padrões. Pode-se usar mecanismos como distância de aglomeração, nichos e arquivamento externo para dispersar candidatos em diferentes regiões da fronteira, cobrindo mais intervalos de trade-off.
- O algoritmo é responsável por gerar opções viáveis diferenciadas; especialistas de domínio são responsáveis por completar a avaliação e a escolha com base em preferências e restrições. Não confunda "gerar candidatos" com "decidir pela pessoa".

Objetivo da página

Compreender a essência de objetivos mutuamente restritivos em problemas do mundo real e explicar por que o sistema deve preservar um conjunto de soluções candidatas diversificadas, em vez de convergir para uma única "resposta ótima".

Sequência de exposição

Problemas reais raramente têm solução ótima única. Múltiplos objetivos se restringem mutuamente, e a melhoria de um indicador geralmente tem como custo a degradação de outros. Portanto, o sistema deve preservar um conjunto de soluções candidatas não-dominadas diversificadas, tornando as relações de trade-off explicitamente visíveis e mantendo a decisão no julgamento humano.

Pontos cinza representam soluções possíveis, pontos coloridos representam candidatos mutuamente não-dominados, que juntos formam a fronteira. Na figura, A favorece resistência, B é equilibrado, C favorece eficiência, D tem resistência extremamente baixa. A fronteira de Pareto só pode ser aproximada, não eliminada.

3. Desenvolva quatro compreensões-chave. Primeiro, o conflito de objetivos é estrutural, não um problema de ajuste de parâmetros: entre objetivos como razão sustentação/arrasto, resistência estrutural, custo e manufaturabilidade não existe ótimo simultâneo. Segundo, sob múltiplos objetivos não há ordem total: quaisquer dois planos podem ser mutuamente não-dominados, e "melhor" só pode ser definido com uma direção de preferência anexada; ao ver um conjunto de candidatos, primeiro pergunte "sob quais preferências estamos comparando", depois discuta vantagens. Terceiro, feedback esparso é a norma: avaliações de engenharia reais dependem de simulações ou medições de alto custo, o feedback é escasso, ruidoso e sem gradiente disponível, e a busca do tipo escalada de ponto único dificilmente avança efetivamente; algoritmos evolutivos, mantendo populações, exploram múltiplas direções simultaneamente com poucas avaliações.

Buscar apenas o ótimo atual leva a população à convergência prematura e ao colapso de padrões, eventualmente perdendo todo um intervalo de trade-offs não explorado; pode-se usar mecanismos como distância de aglomeração, nichos e arquivamento externo para dispersar candidatos em diferentes regiões da fronteira.

O algoritmo é responsável por "gerar um conjunto de opções viáveis diferenciadas", e especialistas de domínio são responsáveis por "completar a avaliação e a escolha com base em preferências e restrições". O conjunto de soluções candidatas não decide pela pessoa, mas coloca opções comparáveis sobre a mesa.

No projeto de aerofólio supercrítico, eficiência aerodinâmica, características de divergência de arrasto, resistência estrutural e custo de fabricação se restringem mutuamente. O valor do EvoX não está em fornecer o único "aerofólio ótimo", mas em produzir uma família de aerofólios candidatos cobrindo diferentes intervalos de trade-off, para que engenheiros escolham de acordo com condições específicas de voo e restrições de processo.

Pontos-chave de ensino

Definir "melhor" com direção de preferência; manter ativamente a diversidade; distinguir geração de escolha. Sob múltiplos objetivos não há ordem total natural, manter apenas o ótimo atual leva ao colapso da população; o algoritmo gera candidatos diferenciados, e especialistas completam o julgamento final com base em preferências e restrições. As duas pequenas figuras à direita já mostram intuitivamente a diferença entre convergência em ponto único e distribuição diversificada: a primeira colapsa em um aglomerado, a segunda se espalha em fronteira.

Tratamento dos exercícios

Sem ordem total significa que a direção de preferência deve participar da definição; feedback esparso dificulta o avanço da busca de ponto único porque a avaliação é cara, ruidosa e sem gradiente disponível; o valor de dispersar candidatos é deixar o poder de escolha e o conhecimento de domínio para os especialistas; perseguir apenas o ótimo atual leva à convergência prematura e ao colapso de padrões; no projeto de aerofólio supercrítico, a posição do EvoX é produzir uma família de aerofólios candidatos cobrindo diferentes intervalos de trade-off. No feedback, se o aluno errar, pode-se orientá-lo a retornar às três palavras-chave "direção de preferência", "feedback esparso" e "diversidade é um ativo".

Orientação do estudo de caso

No cenário de táxi aéreo urbano, podem-se identificar conflitos entre alcance e carga útil, entre ruído e eficiência aerodinâmica, entre redundância de segurança e custo de fabricação. Esses objetivos se restringem mutuamente, portanto não existe um projeto único simultaneamente ótimo, apenas uma fronteira de Pareto de soluções mutuamente não-dominadas. O EvoX pode tratar alcance, carga útil, ruído, redundância de segurança e custo como múltiplos objetivos, executar busca populacional e produzir soluções candidatas distribuídas em diferentes regiões da fronteira, mutuamente não-dominadas; especialistas de domínio então, com base em cenários operacionais, restrições regulatórias e condições de processo, realizam simulações de alta fidelidade ou medições reais sobre as soluções candidatas, completando a avaliação e a escolha final com base na direção de preferência.

Verificação de compreensão

Peça aos alunos que deem um exemplo cotidiano de múltiplos objetivos, como o trade-off entre desempenho, preço, peso e autonomia ao comprar um notebook, e respondam "sob quais preferências estamos comparando". Se o aluno conseguir explicar que o mesmo conjunto de candidatos sob diferentes preferências resultará em escolhas razoáveis diferentes, isso indica que compreendeu o núcleo desta página.

Dica de transição

Após confirmar que os alunos conseguem distinguir "gerar candidatos" de "decidir pela pessoa", prossiga para a próxima página sobre melhoria no método de computação ou melhoria metodológica. Esta página responde "por que são necessários trade-offs multiobjetivo e candidatos diversificados"; o conteúdo subsequente responderá respectivamente "como calcular mais rápido" e "como melhorar o próprio método".

<a id="lecture-page-5"></a>

### Suporte à Exploração Paralela por meio de Computação Tensorizada e Arquitetura Unificada

*Página 5*

> **Objetivo da página:** Compreender como o EvoX utiliza computação tensorial em lote para sustentar exploração evolutiva paralela de alta intensidade.

> **Objetivo da página**
>
> Compreender como o EvoX utiliza computação tensorial em lote para sustentar exploração evolutiva paralela de alta intensidade, e apreender as duas linhas principais mutuamente sustentadas: o grafo computacional tensorizado e a arquitetura unificada aberta e desacoplada.
>
> Sequência sugerida de exposição:
>
> Quando a população se expande de dezenas para milhares ou dezenas de milhares, o problema central da computação evolutiva deixa de ser "é possível encontrar boas soluções" e passa a ser "é possível avaliar candidatos suficientes em tempo limitado". A diversidade depende da taxa de processamento; manter a diversidade é essencialmente uma questão de poder computacional.
>
> A computação tensorizada é responsável por "executar rápido", e a arquitetura unificada por "poder trocar".
>
> O loop serial tradicional em CPU executa "avaliação—registro—atualização" por indivíduo, gerando três tipos de custo: alto overhead de agendamento, fragmentação de operadores e subutilização da GPU; a abordagem tensorizada organiza a manutenção da população, a avaliação em lote e a atualização de estado como operações tensoriais em lote, permitindo que candidatos da mesma geração ou até de várias gerações sejam calculados em paralelo. Por exemplo, com N soluções candidatas, o serial é um loop individual, e a tensorização organiza a população como um tensor, completando de uma vez a avaliação em lote e a atualização paralela de estado, reduzindo o overhead de agendamento e aumentando a ocupação da GPU.
>
> Apenas reescrever o loop não é suficiente; se o algoritmo, o problema e a lógica de agendamento estiverem acoplados, trocar de algoritmo ou de tarefa exigirá reescrita. A arquitetura unificada desacopla algoritmo, problema, fluxo de trabalho e agendamento do Runtime, e com o agendamento de poder computacional heterogêneo faz o gerenciamento em nível de tarefas em lote para CPU/GPU, permitindo que o mesmo mecanismo paralelo seja reutilizado em cenários de evolução de métodos como MetaDE e AutoPSO.
>
> À esquerda está o loop serial tradicional em CPU, serial por indivíduo, com baixa ocupação da GPU; à direita está a computação tensorial em lote na GPU, tensor de população → avaliação em lote → atualização paralela de estado; na base está a base unificada aberta e desacoplada, contendo algoritmo, problema, fluxo de trabalho e agendamento do Runtime.

**Pontos-chave de ensino**

- O EvoX não apenas resolve problemas, mas também incorpora o próprio método de geração de soluções candidatas como objeto de evolução. No MetaDE, o algoritmo externo evolui as configurações e estratégias do algoritmo interno; AutoPSO e EvoGO combinam ainda mais componentes e utilizam feedback histórico para aprender formas de geração de candidatos, passando de "mudar parâmetros" para "mudar a estrutura do algoritmo". Esse tipo de evolução de dupla camada interna-externa naturalmente exige que um grande número de tarefas internas seja avaliado em lote e tenha estado atualizado. O que ele muda é a forma de organização da computação, transformando todo o caminho "população—avaliação—atualização" em operações tensoriais em lote, e não substituindo um operador ou alterando a forma de codificação. Se a análise de desempenho mostrar "excesso de pequenos operadores, baixa ocupação da GPU, alta proporção de agendamento na CPU", isso geralmente indica que o sistema ainda está em loop serial por indivíduo, o que é o sinal de entrada para introduzir o grafo computacional tensorizado. Apenas fazer tensorização, trocar de algoritmo ou de tarefa exigirá reescrita
- apenas fazer arquitetura unificada, sem paralelismo em lote, ainda não ficará rápido.

**Tratamento dos exercícios**

A transformação central da tensorização é reescrever a manutenção da população, a avaliação em lote e a atualização de estado como operações tensoriais em lote; os principais custos do loop serial tradicional em CPU são alto overhead de agendamento, fragmentação de operadores e subutilização da GPU; a arquitetura unificada aberta e desacoplada serve para que o mecanismo paralelo seja reutilizável em diferentes algoritmos e tarefas; com N soluções candidatas na mesma geração, o benefício-chave é completar de uma vez a avaliação em lote e a atualização paralela de estado; a base trazida pela GPU e pelos grandes modelos eleva a computação em lote de otimização local a capacidade fundamental de exploração evolutiva em nível de sistema. O feedback das respostas deve orientar os alunos a retornar às duas palavras-chave "paralelismo em lote" e "reutilização desacoplada", evitando escolher distratores como "comprimir população", "avaliação aproximada" e "fluxo de trabalho fixo".

A questão de caso exige migrar a evolução diferencial de serial em máquina única para uma base paralela em lote. Pontos-chave da resposta da questão 1: a serialização por indivíduo traz alto overhead de agendamento, fragmentação de operadores e subutilização da GPU; a tensorização mitiga isso organizando a população como tensor e mesclando avaliação em lote e atualização de estado, mantendo inalteradas as semânticas de mutação, cruzamento e seleção. Pontos-chave da resposta da questão 2: a arquitetura unificada se decompõe e desacopla em camada de algoritmo, camada de problema, camada de fluxo de trabalho e camada de agendamento do Runtime;
a camada de algoritmo descreve apenas as semânticas de geração e atualização de candidatos, a camada de problema encapsula interfaces de avaliação em lote, a camada de fluxo de trabalho orquestra tarefas internas e externas, e a camada de agendamento do Runtime é responsável pelo agendamento de poder computacional heterogêneo e pelo gerenciamento em nível de tarefas em lote, permitindo que a mesma base seja reutilizada em cenários de evolução de métodos como MetaDE e AutoPSO.

**Verificação de compreensão**

Pode-se pedir aos alunos que expliquem com suas próprias palavras "o que o grafo computacional tensorizado resolve e o que a arquitetura unificada resolve", e deem exemplos de por que os dois devem atuar em conjunto.

> **Dica de transição**
>
> Após confirmar que os alunos conseguem distinguir "executar rápido" de "poder trocar", prossiga para a próxima página sobre casos específicos ou mecanismos de engenharia da evolução contínua em nível de sistema.

<a id="lecture-page-6"></a>

### A Evolução do Próprio Algoritmo: de Resolver Respostas a Melhorar Métodos

*Página 6*

> **Objetivo da página:** Compreender o princípio básico de incorporar o próprio método de geração de candidatos como objeto de otimização para realizar a auto-evolução do algoritmo.

**Pontos-chave de ensino**

- A camada interna busca respostas, a camada externa muda métodos. Ver "estratégias, parâmetros, operadores, componentes colocados na busca" é evolução de método; ver "apenas soluções candidatas mudando, regras de geração sempre inalteradas" é algoritmo evolutivo tradicional.
- Sinais de preferência primeiro entram na avaliação de respostas, depois passam por agregação entre tarefas e verificação de estabilidade, e só então são permitidos na seleção de métodos. Pular essa etapa fará com que a camada externa persiga um resultado agradável mas não reproduzível.
- Quão grande é o espaço de métodos? Quantas vezes por rodada é necessário executar tarefas internas? Com que conjunto de tarefas independentes validar se a melhoria externa realmente generaliza? Se essas três contas não estiverem claras, a busca de dupla camada facilmente degenera em ajuste aleatório de parâmetros mais caro.

Objetivo da página

Algoritmos evolutivos tradicionais buscam sob um mecanismo de geração fixo, e o que é otimizado são sempre as soluções candidatas; a evolução de métodos incorpora o próprio método que gera soluções candidatas como objeto de busca, completando a evolução de "resolver respostas" para "melhorar métodos".

Sequência de exposição

1. Primeiro compare a diferença entre algoritmos evolutivos tradicionais e evolução de métodos, destacando que "o objeto sendo otimizado" sofreu um deslocamento.

2. Introduza a definição de evolução de métodos e explique que o EvoX avança nessa linha, incorporando o próprio método de geração de candidatos como objeto de evolução.

A camada interna busca respostas, a camada externa muda métodos.

4. Posicione em qual camada a otimização de preferências deve estar, enfatizando que os dois tipos de objetivos não podem ser confundidos.

5. Cite MetaDE, AutoPSO e EvoGO como formas típicas.

6. Feche com benefícios e custos, e trate exercícios e casos.

Pontos-chave de ensino

Regras como "como gerar respostas" — seleção, cruzamento, mutação — são previamente escritas por humanos, e a busca se move apenas no espaço de respostas. Com a expansão da escala computacional, o mecanismo de geração fixo torna-se justamente o teto.

O algoritmo não apenas produz respostas melhores, mas também melhora continuamente as estratégias, parâmetros e componentes que geram respostas por meio da busca externa. O EvoX é um trabalho nessa linha, por exemplo, incorporando as estratégias de mutação e configurações de parâmetros da evolução diferencial como objeto de evolução.

A camada interna resolve problemas específicos com o método atual, produzindo soluções candidatas; a camada externa, com base em feedback como qualidade da solução, sinais de preferência, estabilidade ou custo, compara, seleciona e atualiza o método a ser usado na próxima rodada. O objeto elevado ao espaço de busca não é uma solução, mas o próprio mecanismo de geração de candidatos, tornando-se um objeto avaliável, selecionável e atualizável.

A camada superior é "o método de evoluir a geração de soluções candidatas", contendo estratégias/parâmetros/componentes de operadores, busca evolutiva externa, método de geração melhorado; a camada inferior é "resolver problemas específicos", contendo método atual, soluções candidatas, avaliação de qualidade de solução. Dois circuitos representam respectivamente o retorno dos resultados externos para a camada interna e o feedback de qualidade de solução/preferência/custo impulsionando as duas camadas. No quadro, pode-se primeiro desenhar as duas camadas superior e inferior, depois marcar com setas "atualizar método de geração" e "sinal de feedback".

Pode participar do feedback da camada superior, mas deve separar "avaliar a resposta atual" de "melhorar o método que gera respostas". Ler "esta solução é mais agradável" diretamente como "esta estratégia é melhor" é usar preferência de resposta para se passar por superioridade de método, e a camada externa será arrastada pelo ruído de resultados únicos. Sinais de preferência primeiro entram na avaliação de respostas, depois passam por agregação entre tarefas e verificação de estabilidade, e só então são permitidos na seleção de métodos.

MetaDE faz a camada externa evoluir as estratégias de mutação e parâmetros da evolução diferencial, enquanto a camada interna resolve tarefas normalmente; AutoPSO e EvoGO combinam ainda mais componentes de enxame de partículas e utilizam feedback histórico para aprender formas de geração de candidatos, realizando o salto de "mudar parâmetros" para "mudar a estrutura do algoritmo".

O benefício é empurrar o design de algoritmos de ajuste manual único para adaptação contínua sustentável. Há três custos: expansão do espaço de busca, pois o espaço de métodos é muito maior que o espaço de soluções; aumento do custo de avaliação, pois cada conjunto de métodos candidatos precisa executar tarefas internas, geralmente dependendo de avaliação paralela em lote na GPU para diluir; aumento da complexidade de verificação, pois se a melhoria externa realmente generaliza requer um design de verificação independente.

Pistas de exercícios e orientação de respostas

1. Comparado a algoritmos evolutivos tradicionais, qual é a diferença mais essencial da evolução de métodos em relação ao "objeto sendo otimizado"? A direção correta é: colocar as estratégias, parâmetros e componentes de operadores de "como gerar respostas" no objeto de busca. Se o aluno escolher "população maior" ou "cancelar avaliação de aptidão", oriente-o a retornar ao deslocamento do objeto de otimização: o que é otimizado não são mais apenas respostas, mas o mecanismo que gera respostas.

Feedback vindo do desempenho das tarefas internas, como qualidade da solução, sinais de preferência, estabilidade ou custo. Se o aluno escolher erroneamente "ruído aleatório" ou "especificado manualmente pelo engenheiro", guie-o a perguntar: com base em que a camada externa julga que uma estratégia é melhor que outra? Esse "com base em que" é o sinal de feedback.

Deixe os sinais de preferência participar do feedback da camada superior, mas trate "avaliar a resposta atual" e "melhorar o método de geração" como dois tipos de objetivos separados. Se o aluno tratar preferência de resposta diretamente como superioridade de método, lembre-o: a preferência deve passar por agregação entre tarefas e verificação de estabilidade para ser promovida de "preferência de resposta" a "critério de método".

Expansão do espaço de métodos, custo de avaliação interna para cada método, e aumento da dificuldade de verificação. Pode ser resumido como tripla pressão: espaço, poder computacional e verificação; a evolução de métodos eleva o objeto de busca em um nível, e o custo sobe junto.

5. Sobre MetaDE e AutoPSO, qual item é preciso? A direção correta é: MetaDE usa a camada externa para evoluir as estratégias de mutação e parâmetros da evolução diferencial, enquanto a camada interna ainda é responsável pela resolução de candidatos de tarefas específicas. AutoPSO e EvoGO avançam mais em direção à combinação de componentes e melhoria em nível estrutural, na direção de mudar parâmetros para mudar estruturas.

Tratamento do caso

O cenário é uma equipe otimizando layout de chip em um cluster de GPU, já com um solucionador de evolução diferencial, mas cujas estratégias de mutação e parâmetros dependem de experiência manual, com flutuação de desempenho evidente, planejando introduzir otimização de dupla camada tipo MetaDE e usar preferências do usuário para guiar a busca.

A entrada da camada interna é o método atual (estratégias de mutação e configuração de parâmetros) e uma instância específica de problema de layout, e a saída são layouts candidatos e sua qualidade de solução. A entrada da camada externa são estatísticas agregadas do desempenho das tarefas internas, e a saída são as estratégias e configurações de parâmetros atualizadas. Os sinais de feedback devem ser agregados entre tarefas e entre execuções repetidas, como média multi-tarefa, quantis ou indicadores de estabilidade, não podendo vir de uma única execução. A razão é que a qualidade de uma solução única depende altamente da instância específica e da aleatoriedade; ela mede "se esta resposta é boa", não "se este método é bom"; se resultados únicos forem usados diretamente para impulsionar a camada externa, ela será dominada por diferenças de instância e ruído.

A camada interna pode usar uma função de avaliação ponderada por preferência para filtrar layouts candidatos; a camada externa deve primeiro transformá-la em critérios de comparação estáveis entre tarefas, como pontuação ponderada de comprimento de fio e métricas de congestionamento e sua variância, para então ser usada na seleção de configurações de método, evitando tratar a preferência de uma resposta como superioridade de método.

A expansão do espaço de busca pode ser controlada com agrupamento de parâmetros, busca hierárquica e abordagem grosso-fino; o aumento do custo de avaliação pode ser reduzido com avaliação paralela em lote na GPU, avaliação proxy com poucas amostras e mecanismos de parada antecipada; o aumento da complexidade de verificação exige manter conjuntos de tarefas de verificação independentes e executar repetidamente, verificando se a melhoria externa realmente generaliza.

Verificação de compreensão e transição

A camada interna busca respostas, a camada externa muda métodos. Ver "estratégias, parâmetros, operadores, componentes colocados na busca" é evolução de método; ver "apenas soluções candidatas mudando, regras de geração sempre inalteradas" é algoritmo evolutivo tradicional. Após confirmar que os alunos conseguem explicar "o objeto sendo otimizado mudou" e "preferência não pode se passar diretamente por superioridade de método", prossiga para a próxima página de exemplos, aplicações ou resumo.

<a id="lecture-page-7"></a>

### MetaDE e AutoPSO: Arquitetura de Dupla Camada para Evolução de Métodos

*Página 7*

> **Objetivo da página:** Dominar como MetaDE e AutoPSO realizam a evolução automática de variantes de algoritmos e parâmetros por meio de otimização de dupla camada interna e externa.

> **Objetivo da página**
>
> Compreender como MetaDE e AutoPSO realizam a evolução automática de configurações e estruturas de algoritmos por meio de arquitetura de otimização de dupla camada interna e externa, e dominar sua estrutura de custos e trade-offs de engenharia.

> **Sequência de exposição**
>
> O algoritmo não apenas busca soluções, mas também melhora "como ele mesmo busca soluções".
>
> 2. Mostre a abstração genérica da arquitetura de dupla camada interna e externa, enfatizando que a camada externa busca o espaço de algoritmos, a camada interna resolve a tarefa alvo, e o desempenho interno retorna como sinal de aptidão, formando um ciclo fechado.
>
> 3. Explique separadamente as duas rotas de implementação MetaDE e AutoPSO, indicando que a primeira gerencia a camada de configuração e a segunda a camada de estrutura/componentes.
>
> 4. Analise o efeito multiplicativo de custo da otimização de dupla camada, introduzindo trade-offs de engenharia como alocação de orçamento, avaliação aproximada, parada antecipada e paralelização.
>
> Passar do design manual de um único algoritmo para o design de um espaço de algoritmos evolutivos e mecanismos de avaliação.

**Pontos-chave de ensino**

- A evolução de métodos (Meta-Evolution) toma "o método que gera candidatos" como objeto de otimização. A camada externa busca configurações de algoritmo, combinações de componentes ou estratégias, e não soluções de tarefas. A camada externa é responsável por buscar o espaço de algoritmos (hiperparâmetros, estratégias, combinações de componentes e outras "definições de algoritmo")
- a camada interna usa o algoritmo candidato para realmente resolver a tarefa alvo, obtendo desempenho mensurável
- o desempenho interno é agregado como aptidão e retorna à camada externa, que elimina configurações de baixa qualidade e retém e muta configurações de alta qualidade, formando um ciclo de melhoria contínua. Mantém a evolução diferencial como solucionador interno, entregando a configuração do próprio DE à busca externa — estratégias de mutação, taxa de cruzamento, fator de escala etc. se ajustam adaptativamente conforme o problema e a fase de otimização. Ele responde "como esta configuração deve ser definida na fase atual da tarefa", pertencendo à evolução de métodos na camada de configuração. Trata os parâmetros centrais e mecanismos de aprendizado do PSO como componentes combináveis — peso de inércia, fatores de aprendizado e diferentes combinações de mecanismos de aprendizado individual e de grupo, automaticamente buscados e combinados pela camada externa para produzir variantes de PSO adaptadas a diferentes problemas. Ele transforma "escolher algoritmo" em "buscar estrutura de algoritmo", realizando o salto da adaptação de parâmetros para a autogeração de mecanismos. MetaDE tende ao ajuste automático na camada de configuração e hiperparâmetros, AutoPSO tende à combinação automática na camada de estrutura e componentes, cobrindo juntos o escopo evolutivo da adaptação de parâmetros à autogeração de mecanismos. O custo-chave da otimização de dupla camada está no efeito multiplicativo — cada avaliação de um algoritmo candidato pela camada externa frequentemente exige múltiplas execuções internas (avaliação repetida por aleatoriedade, validação conjunta multi-tarefa etc.), ampliando significativamente o orçamento computacional. O cálculo real é aproximadamente "número de algoritmos candidatos externos × número de execuções internas por candidato". Alocação de orçamento, avaliação aproximada, parada antecipada, paralelização. A execução eficiente depende de paralelismo tensorizado, agendamento do Runtime e composabilidade de algoritmos
- a paralelização pode aliviar o tempo de relógio, mas não reduz o cálculo total. O pesquisador não entrega mais um algoritmo fixo, mas um espaço de busca e regras de feedback que permitem ao algoritmo se auto-melhorar continuamente.

**Verificação de compreensão**

Pode-se perguntar sequencialmente e fornecer pontos-chave de resposta:

1. Qual é o objeto direto da busca externa?

Configurações, estruturas e combinações de componentes do próprio algoritmo. A essência da evolução de métodos é tomar o próprio algoritmo como objeto de otimização; a camada externa busca configurações e estruturas no espaço de algoritmos, e não busca diretamente soluções de tarefas. Note a distinção entre as duas camadas: a busca direta de soluções é a camada interna; a camada externa busca "qual algoritmo usar, como configurar o algoritmo".

2. No MetaDE, qual conjunto de objetos a camada externa principalmente evolui?

Estratégias de mutação, taxa de cruzamento e fator de escala da evolução diferencial. MetaDE faz a configuração do DE se ajustar adaptativamente conforme o problema e a fase, pertencendo à evolução de métodos na camada de configuração/hiperparâmetros, e não à estrutura de outros algoritmos.

3. Sobre a divisão de trabalho entre AutoPSO e MetaDE, qual descrição é mais precisa?

AutoPSO enfatiza a combinação automática de parâmetros e mecanismos de aprendizado, transformando "escolher algoritmo" em "buscar estrutura de algoritmo"; MetaDE enfatiza a evolução na camada de configuração. Os dois são complementares: MetaDE cobre a camada de configuração e hiperparâmetros, AutoPSO cobre a camada de estrutura e componentes, constituindo juntos o escopo evolutivo da adaptação de parâmetros à autogeração de mecanismos, e ambos devem passar por avaliação interna.

4. Sobre a estrutura de custos da otimização de dupla camada, qual item está correto?

Cada avaliação de um algoritmo candidato pela camada externa frequentemente exige múltiplas execuções internas, ampliando significativamente o orçamento, necessitando alocação de orçamento, avaliação aproximada ou parada antecipada. O principal custo da arquitetura de dupla camada é o efeito multiplicativo; a paralelização só pode aliviar, não eliminar o overhead total.

5. Após adotar a arquitetura de dupla camada de evolução de métodos, qual é a transformação cognitiva do papel do pesquisador?

Passar do design manual de um único algoritmo para o design do espaço em que o algoritmo pode ser evoluído e dos mecanismos de avaliação. O que se entrega não é mais um algoritmo fixo, mas "espaço de algoritmos evolutivos + regras de avaliação de aptidão", e a busca externa e a resolução interna formam assim um ciclo de melhoria contínua. Embora não se fixe mais manualmente um único algoritmo, o trabalho central torna-se projetar o espaço de busca e os mecanismos de avaliação, e a responsabilidade é ainda maior.

**Tratamento dos exercícios**

O caso "construir um serviço de evolução de dupla camada para tarefas em constante mudança" pode ser usado após explicar a arquitetura e os custos, permitindo que os alunos respondam primeiro individualmente e depois discutam coletivamente.

Explique o que cada uma das camadas interna e externa é responsável por fazer, e como os sinais fluem.

A camada externa busca algoritmos candidatos no espaço de algoritmos — pode evoluir as estratégias de mutação, taxa de cruzamento e fator de escala do DE (rota MetaDE), ou combinar automaticamente componentes como peso de inércia, fatores de aprendizado e mecanismos de aprendizado do PSO (rota AutoPSO). A camada interna executa e avalia cada algoritmo candidato na tarefa alvo do dia, produzindo desempenho comparável; o desempenho interno é agregado como aptidão e retorna à camada externa, que com base nisso elimina candidatos de baixa qualidade, retém e muta configurações de alta qualidade, iterando continuamente, formando o ciclo "camada externa busca espaço de algoritmos, camada interna resolve tarefa alvo, feedback de desempenho impulsiona melhorias".

Diante da pressão orçamentária de que "cada avaliação externa requer múltiplas execuções internas", apresente pelo menos duas medidas de trade-off e explique o custo ou risco.

①Alocação de orçamento — definir cotas computacionais separadas para as camadas externa e interna e limitar o número de repetições internas, com o custo de aumento da variância de avaliação e possível escolha errada; ②Avaliação aproximada — estimar a aptidão com subconjuntos de dados ou execuções curtas, com o custo de sinal ruidoso e possível subestimação do melhor candidato; ③Parada antecipada — encerrar antecipadamente execuções internas de candidatos claramente ruins, com o custo de possível eliminação prematura de configurações de maturação lenta que teriam bom desempenho posterior; ④Paralelismo tensorizado e agendamento do Runtime — execução interna concorrente em lote, que pode aliviar significativamente o tempo de relógio, mas não reduz o cálculo total, e está limitada pela memória de vídeo e overhead de agendamento. A resposta deve explicar a correspondência entre cada medida e seu custo ou risco, e refletir a estimativa multiplicativa "escala de busca externa × número de execuções internas por vez".

Linguagem de feedback:

Correto. Esta resposta consegue conectar com os conceitos desta página e explicar a base.

Retorne à exposição desta página, encontre evidências ou exemplos-chave e depois julgue.

Atenção à distinção entre "camadas" — a busca direta de soluções é a camada interna, a camada externa busca "qual algoritmo usar, como configurar o algoritmo"; o objeto do MetaDE é a configuração da própria evolução diferencial, não a estrutura de outros algoritmos; o principal custo da arquitetura de dupla camada é o efeito multiplicativo, a paralelização só pode aliviar, não eliminar o overhead total; embora não se fixe mais manualmente um único algoritmo, o trabalho central do pesquisador torna-se projetar o espaço de busca e os mecanismos de avaliação, e a responsabilidade é ainda maior.

> **Dica de transição**
>
> Após confirmar que os alunos conseguem distinguir com suas próprias palavras "evolução na camada de configuração" de "evolução na camada de estrutura/componentes", e conseguem expressar o circuito de sinais interno-externo e o efeito multiplicativo do orçamento, prossiga para a próxima página de exemplos, aplicações ou resumo.

<a id="lecture-page-8"></a>

### Caso Prático Multiobjetivo de Design de Aerofólio Supercrítico

*Página 8*

> **Objetivo da página:** Aprender como utilizar o EvoX para lidar com restrições complexas de engenharia e gerar soluções de trade-off diversificadas no design de aerofólios.

> **Objetivo da página**
>
> Compreender por que o design de aerofólio supercrítico é um problema multiobjetivo e dominar como utilizar o EvoX para gerar soluções de trade-off diversificadas sob restrições rigorosas de engenharia.

> **Sequência de exposição**
>
> O design de aerofólio supercrítico é uma prática multiobjetivo do EvoX em engenharia real. Parâmetros de forma como curvatura, espessura e bordo de fuga do aerofólio se acoplam mutuamente, e alterar a forma afeta simultaneamente múltiplos indicadores aerodinâmicos.
>
> Melhorar um indicador geralmente tem como custo outro indicador, portanto não pode ser tratado como otimização de objetivo único, exigindo trade-offs multiobjetivo.
>
> Requisitos de sustentação, ângulo de ataque, espessura etc. delimitam o domínio de design viável, e a busca deve se desenrolar sob a premissa de satisfazer as restrições, para garantir que as soluções candidatas sejam viáveis em engenharia.
>
> O EvoX gera um conjunto diversificado de soluções candidatas que considera todos os indicadores, e não a solução ótima única; o conjunto de candidatos permite que especialistas de domínio comparem diferentes benefícios e custos e façam escolhas.
>
> Este caso transforma um problema real complexo em um processo explorável e avaliável, buscando soluções de trade-off interpretáveis em meio a conflitos de restrições e objetivos.

**Pontos-chave de ensino**

- Mudanças na forma do aerofólio supercrítico afetam múltiplos indicadores aerodinâmicos, e os objetivos frequentemente entram em conflito, exigindo trade-offs multiobjetivo. O design deve satisfazer múltiplas restrições rigorosas como sustentação, ângulo de ataque e espessura, e a busca deve se desenrolar dentro do domínio de design viável. Gerar soluções candidatas diversificadas para ajudar especialistas a avaliar diferentes benefícios e custos e fazer escolhas. Primeiro explorar continuamente no espaço de parâmetros do aerofólio (curvatura, espessura, bordo de fuga), depois aproximar-se da fronteira de trade-off multiobjetivo (indicador A e indicador B), finalmente formando um conjunto de soluções candidatas. Aerofólio supercrítico, trade-off multiobjetivo, domínio de design viável, conjunto de soluções candidatas, EvoX.

> **Pistas de exercícios**
>
> - A raiz do problema multiobjetivo, o papel das restrições, a saída prática do EvoX, o significado de candidatos diversificados, o valor do método. A compreensão correta deve recair sobre: parâmetros de forma afetam simultaneamente múltiplos indicadores, causando conflito de objetivos
> - restrições delimitam o domínio de design viável
> - a saída é um conjunto diversificado de soluções candidatas
> - diferentes candidatos representam diferentes benefícios e custos
> - o valor do método está em transformar problemas reais complexos em processos exploráveis e avaliáveis.

**Tratamento dos exercícios**

Se o aluno escolher erroneamente "basta otimizar a sustentação" ou "buscar a solução ótima única", oriente a retornar ao acoplamento de parâmetros de forma e conflito de objetivos.

Se o aluno escolher erroneamente "restrições podem ser relaxadas à vontade" ou "irrelevante para viabilidade em engenharia", oriente que as restrições delimitam o domínio de design viável e não podem ser relaxadas arbitrariamente.

Se o aluno escolher erroneamente "aerofólio ótimo único" ou "forma aleatória", oriente que a saída deve ser um conjunto diversificado de soluções candidatas que considera todos os indicadores.

Correto, esta resposta consegue conectar com os conceitos desta página e explicar a base.

Retorne à exposição desta página, encontre evidências ou exemplos-chave e depois julgue.

**Atividade em sala**

Como mudanças nos parâmetros de forma afetam simultaneamente múltiplos indicadores aerodinâmicos, melhorar um geralmente tem como custo outro, exigindo trade-offs multiobjetivo; as restrições delimitam o domínio de design viável, garantindo que as soluções candidatas sejam viáveis em engenharia.

**Verificação de compreensão**

Como o EvoX, no design de aerofólio supercrítico, gera um conjunto diversificado de soluções candidatas sob restrições rigorosas, para que especialistas avaliem benefícios e custos. O professor complementa as palavras-chave omitidas com base na resposta: conflito de objetivos, domínio de design viável, conjunto de soluções candidatas, trade-off multiobjetivo.

> **Dica de transição**
>
> Após confirmar que os alunos conseguem distinguir otimização de objetivo único de trade-off multiobjetivo e explicar o uso do conjunto de soluções candidatas, prossiga para a próxima página de exemplos, aplicações ou resumo.

<a id="lecture-page-9"></a>

### Desafios ao Longo do Ciclo de Vida: Esgotamento de Contexto e Persistência em Nível de Projeto

*Página 9*

> **Objetivo da página:** Compreender a contradição entre as limitações de contexto dos grandes modelos e projetos reais de engenharia que duram meses ou anos.

**Pontos-chave de ensino**

- Um contexto único é uma bancada de trabalho; o repositório do projeto é a memória de longo prazo. Não deixe o estado da população, configurações falhas e justificativas de decisão apenas na janela de sessão; antes de fechar a sessão, deve-se escrever nos artefatos em nível de projeto, e a próxima sessão deve ler antes de continuar.
- A persistência herdável exige que os artefatos sejam versionáveis, pesquisáveis e explicáveis: código, testes, registros de experimentos, diários de decisão, métricas de avaliação e conclusões de aceitação devem poder responder por que foi escolhido assim, quais já falharam e quais conflitos ainda permanecem.
- Agentes superiores decompõem objetivos, agentes inferiores implementam e testam. Antes de cada sessão terminar, definir pontos de verificação: atualizar o diário de decisão e as métricas de avaliação; ao iniciar uma nova sessão, primeiro herdar os pontos de verificação, depois decidir ações locais, atravessando assim múltiplos ciclos de vida finitos.

> **Objetivo da página**
>
> Compreender a contradição entre as limitações de contexto de Agentes de grandes modelos e projetos reais de engenharia que duram meses ou até anos, e estabelecer a necessidade de persistência em nível de projeto. Julgamento central: a janela de contexto de uma única sessão C_máx é um recurso finito, o ciclo de vida do projeto T_projeto pode durar meses ou até anos, portanto T_projeto ≫ C_máx. A verdadeira dificuldade não é a insuficiência de capacidade de raciocínio em uma única vez, mas a impossibilidade de a experiência atravessar o ciclo de vida do Agente.
>
> Sequência de exposição
>
> O contexto de um único Agente só pode conter o objetivo atual, observações locais e raciocínio recente; após o fechamento da sessão, o estado é zerado, e conclusões temporárias e experiências não estão mais disponíveis. Sem persistência, sessões subsequentes só podem repetir a exploração.
>
> Persistência em nível de projeto. Externalizar configurações falhas, processos de trade-off, soluções candidatas e conclusões de aceitação em artefatos permanentes em nível de projeto, incluindo código, testes, registros de experimentos, diários de decisão, métricas de avaliação e conclusões de aceitação. Agentes subsequentes não precisam começar do zero, mas ler a experiência anterior, julgar quais direções já foram verificadas, quais conflitos não foram resolvidos e quais indicadores já foram atingidos.
>
> O objeto de evolução não é mais apenas parâmetros numéricos ou soluções candidatas de uma única vez, mas um mundo de software permanente, versionável e herdável. Cada sessão produz novos artefatos que alteram o estado desse mundo, e a próxima sessão continua a evoluir sobre o mundo atualizado, tornando o processo de otimização uma evolução contínua em nível de projeto.
>
> Múltiplos Agentes com ciclos de vida finitos podem trabalhar em colaboração; executores superiores compreendem objetivos e decompõem tarefas, executores inferiores completam implementação e testes locais, e quando necessário continuam a decomposição recursiva. Antes de fechar, escrever o estado-chave; após iniciar um novo Agente, primeiro ler a memória do projeto, depois decidir ações locais.
>
> Projetos de longo prazo frequentemente têm conflitos de objetivos, por exemplo, desempenho, custo e robustez dificilmente são simultaneamente ótimos; o feedback também pode ser esparso, com um experimento levando horas ou até dias. O diário de decisão persistente e as métricas de avaliação podem transformar feedback esparso em experiência herdável, evitando que Agentes subsequentes caiam repetidamente nas mesmas armadilhas.
>
> Pontos-chave de ensino
>
> Um contexto único é uma bancada de trabalho; o repositório do projeto é a memória de longo prazo. Não deixe o estado da população, configurações falhas e justificativas de decisão apenas na janela de sessão; antes de fechar a sessão, deve-se escrever nos artefatos em nível de projeto, e a próxima sessão deve ler antes de continuar.
>
> Persistência não é acúmulo de logs. A persistência herdável exige que os artefatos sejam versionáveis, pesquisáveis e explicáveis: código, testes, registros de experimentos, diários de decisão, métricas de avaliação e conclusões de aceitação devem poder responder por que foi escolhido assim, quais já falharam e quais conflitos ainda permanecem.
>
> Antes de cada sessão terminar, atualizar o diário de decisão e as métricas de avaliação; ao iniciar uma nova sessão, primeiro herdar os pontos de verificação, depois decidir ações locais, atravessando assim múltiplos ciclos de vida finitos.
>
> Evolução contínua em nível de projeto, ou seja, migrar o processo de gerar candidatos, avaliar candidatos, registrar trade-offs e conclusões de aceitação do contexto de um único Agente para artefatos persistentes em nível de projeto, fazendo o projeto iterar continuamente ao longo de múltiplos ciclos de vida de Agentes.
>
> Pistas de exercícios
>
> Deve-se escolher "a janela de contexto é limitada e, após o fechamento da sessão, o estado e a experiência não são confiáveis". No feedback, enfatizar: o limite rígido está no comprimento finito e no zeramento do estado após o fechamento da sessão, não na escala de parâmetros, grau de paralelismo ou função objetivo.
>
> Deve-se escolher "código, testes, registros de experimentos, diários de decisão, métricas de avaliação e conclusões de aceitação". No feedback, explicar que esses artefatos constituem juntos a memória do projeto.
>
> Deve-se escolher "expansão de parâmetros numéricos/soluções candidatas de uma única vez para um mundo de software permanente, versionável e herdável". No feedback, distinguir mudanças de paradigma de treinamento de mudanças na fronteira do objeto de evolução.
>
> Deve-se escolher "camada superior compreende objetivos e decompõe tarefas, camada inferior completa implementação e testes locais, e quando necessário decompõe recursivamente". No feedback, enfatizar que a continuidade ao longo do ciclo de vida é garantida pela persistência em nível de projeto.
>
> Deve-se escolher "após cada sessão, o estado da população, configurações falhas e justificativas de decisão são perdidos, e Agentes subsequentes repetem a exploração". No feedback, explicar que a falta de persistência não resolve automaticamente conflitos de objetivos nem amplia o contexto.
>
> Quando correto, pode-se afirmar "consegue conectar com os conceitos desta página e explicar a base"; quando incorreto, peça ao aluno que retorne à exposição desta página, encontre evidências ou exemplos-chave e depois julgue.
>
> Tratamento dos exercícios
>
> Os objetivos incluem eficiência aerodinâmica, resistência estrutural e custo de fabricação, os três entram em conflito, o feedback de simulação é esparso, e a equipe espera que múltiplos Agentes de ciclo de vida curto colaborem continuamente. A primeira questão exige explicar por que a memória do projeto não pode ficar apenas em um contexto único, e listar pelo menos três categorias de artefatos que devem ser persistidos. Pontos-chave da resposta: a janela de contexto de uma única vez é limitada e o estado é zerado após o fechamento da sessão, enquanto o projeto dura meses, T_projeto ≫ C_máx; depender apenas de um contexto único perderá estado da população, resultados de simulação, configurações falhas, conflitos de indicadores e justificativas de decisão; a persistência deve incluir pelo menos código e scripts de treinamento de modelos proxy, registros de testes e métricas de avaliação, registros de experimentos e configurações falhas, diários de decisão e justificativas de trade-off, soluções candidatas e conclusões de aceitação.
>
> O início da sessão lê primeiro diários de decisão, métricas de avaliação, registros de experimentos e soluções candidatas, restaurando o estado da população e conflitos não resolvidos; durante a sessão, escreve novos modelos proxy, resultados de simulação, avaliações de candidatos e análises de trade-off; antes de fechar, atualiza o diário de decisão, registrando configurações falhas da rodada, conflitos de indicadores, justificativas de descarte e sugestões para o próximo passo, e submete à versionamento; sessões subsequentes herdam configurações falhas e justificativas de decisão lendo esses artefatos, evitando exploração repetida.

**Verificação de compreensão**

Peça aos alunos que resumam com suas próprias palavras "por que a memória do projeto não pode ser guardada apenas no contexto de um único Agente", e mencionem pelo menos três categorias de objetos de persistência em nível de projeto. Dica de transição: após confirmar que os alunos conseguem expressar a relação central desta página — T_projeto ≫ C_máx, a persistência em nível de projeto externaliza a experiência em um mundo de software herdável — prossiga para a próxima página de exemplos, aplicações ou resumo.

<a id="lecture-page-10"></a>

### Arquitetura Genesis e o Paradigma de Sedimentação do Mundo de Software

*Página 10*

> **Objetivo da página:** Dominar como o Genesis permite que o código do projeto se acumule e evolua continuamente ao longo do ciclo de vida.

> **Objetivo da página**
>
> Ajudar os alunos a compreender como o Genesis reancora a inteligência do processo de sessão volátil para o mundo de software acumulável, permitindo que o código do projeto e os resultados de engenharia se acumulem, evoluam e sejam herdados continuamente ao longo de uma única janela de contexto e de um único ciclo de vida.

> **Sequência de exposição**
>
> Primeiro apresente o critério de julgamento "sessões são voláteis, o repositório é a memória de longo prazo", depois desenvolva sucessivamente as diferenças essenciais do paradigma de sedimentação, a divisão de trabalho das quatro categorias de ativos sedimentáveis, a premissa de interfaces estáveis, o ciclo de sedimentação e o guardião de aceitação, a herança entre ciclos de vida, e finalmente resuma em uma frase a fronteira de divisão entre EvoX e Genesis.

**Pontos-chave de ensino**

- 1. Para julgar se um trabalho tem valor de sedimentação, faça apenas uma pergunta — a próxima pessoa consegue reproduzi-lo sem vir lhe fazer nenhuma pergunta? Se não, ele ainda não se tornou um ativo. Fluxos de trabalho conversacionais evaporam com o fim do contexto, e a produção fica presa em "esta sessão"
- o mundo de software, tendo como meio repositórios, versões e artefatos, possui naturalmente acumulatividade. Genesis formaliza esse meio como a camada de memória de longo prazo do sistema evolutivo; o que ele lembra não é a conversa, mas resultados de engenharia verificados. Código gerencia "consegue rodar", método gerencia "como escolher", estado gerencia "onde está", evidência gerencia "por que confiar". Código carrega capacidade executável, é o processo de resolução diretamente executável e reproduzível
- método carrega decisões de algoritmos e estratégias, por exemplo as escolhas de configuração e formas de combinação de componentes da evolução de dupla camada
- estado carrega o contexto do projeto e a memória de execução, registrando o progresso atual, restrições e fronteiras conhecidas
- evidência carrega registros de experimentos e conclusões de aceitação, respondendo por que os resultados são confiáveis. Faltando qualquer um dos quatro, a sedimentação é irreproduzível ou não herdável: apenas código sem evidência, a conclusão não pode ser confiada
- apenas método sem estado, o herdeiro não sabe de onde continuar. Portanto as quatro categorias de ativos devem ser solidificadas em conjunto, não dispersas. 3. A premissa da sedimentação é a estabilidade das interfaces. Somente quando as fronteiras dos módulos e os contratos são relativamente estáveis é que a nova produção se torna um ativo
- caso contrário, cada alteração arrastará implementações ao redor, e a sedimentação rapidamente se transformará em dívida de manutenção. Isso é mutuamente condicionado com o design de base aberta e desacoplada do Genesis: interfaces estáveis permitem que a sedimentação seja herdada com segurança, e o desacoplamento permite que a herança não precise reescrever o histórico. Solidificar o contrato antes da sedimentação frequentemente vale mais do que escrever vários documentos a mais. Exploração → produção → aceitação rigorosa → solidificação como ativo → a próxima rodada de evolução herda diretamente. A aceitação é o guardião da sedimentação — produção não verificada não entra na camada de ativos, evitando solidificar ruído, fenômenos acidentais e conclusões errôneas como "experiência" do projeto. Sem guardião, o repositório se tornará cada vez mais longo e menos confiável. 5. A chave da herança entre ciclos de vida está no desacoplamento dos ativos de instâncias específicas de execução, permitindo que novas sessões, novos Agentes e novas tarefas recuperem a cognição em nível de projeto por meio de "ler o repositório", sem depender de reproduzir o histórico de conversas. O custo de herança cai de "recontar o projeto" para "fazer checkout e carregar", e a cognição do projeto não é mais limitada pela capacidade de uma janela de contexto. Genesis é responsável por "o que sedimentar, em que forma sedimentar, como ser herdado"
- a colaboração multi-Agente e a decomposição recursiva de tarefas são responsáveis por "como produzir"
- os mecanismos de aceitação e herança histórica são responsáveis por "como a produção é julgada confiável". A sobreposição dos três constitui a capacidade completa de evolução contínua em nível de projeto — faltando qualquer elo, o projeto apenas se repete no mesmo lugar.

**Cobertura de palavras-chave**

- Genesis, evolução contínua em nível de projeto, arquitetura do sistema EvoX, código／método／estado／evidência, guardião de aceitação, herança entre ciclos de vida. Esta página organiza o conteúdo com o "Diagrama da arquitetura de três camadas do Genesis e ciclo de sedimentação", à esquerda de cima para baixo estão a camada de ativos (código·método·estado·evidência), o mecanismo de sedimentação (versionamento·gateway de aceitação·recuperação e herança) e o EvoX Runtime (paralelismo tensorizado·poder computacional heterogêneo·módulos de algoritmo)
- à direita, o diagrama circular apresenta o ciclo de exploração, produção, aceitação, solidificação, reutilização e re-evolução, com a anotação "ativos se espessam com o aumento do ciclo de vida". A página também inclui três dicas: não trate a sessão como memória; as quatro categorias de ativos são indispensáveis; interfaces instáveis transformam a sedimentação em dívida. Na exposição, pode-se usar o diagrama para guiar os alunos a recontar o ciclo seguindo as setas, e depois indicar que a aceitação está após a produção e antes da solidificação.

> **Pistas de exercícios**
>
> - A página inclui cinco questões de múltipla escolha e um caso. A questão 1 aponta para o mundo de software acumulável (repositório, versões e artefatos); se o aluno escolher erroneamente a janela de contexto, oriente a retornar ao ponto de partida "ao final da sessão nada resta"
> - a questão 2 testa a correspondência de responsabilidades das quatro categorias de ativos, e o item correto é que o código carrega capacidade executável
> - a questão 3 testa a fronteira entre ativo e dívida de manutenção, e o item correto é "fronteiras de módulos e contratos relativamente estáveis", sendo necessário enfatizar que o ponto-chave não está em quanto se produz ou quão nova é a ferramenta
> - a questão 4 testa o guardião no ciclo, e o item correto é a aceitação rigorosa
> - a questão 5 testa a herança entre ciclos de vida, e o item correto é "ativos desacoplados de instâncias de execução, novas sessões podem recuperar a cognição do projeto lendo o repositório". Quando correto, afirmar que consegue conectar com os conceitos desta página e explicar a base; quando incorreto, pedir que retorne à exposição para encontrar evidências ou exemplos-chave e depois julgar. Após a exploração multiobjetivo do aerofólio supercrítico, a equipe deixa em mãos uma configuração de dupla camada MetaDE executável e scripts de treinamento de modelos proxy, definições de métricas de avaliação, estados intermediários cobrindo intervalos de parâmetros de aerofólio e restrições de condições geométricas, e conclusões de aceitação da rodada. A primeira questão exige organizar os ativos nas quatro categorias de código, método, estado e evidência, e explicar o papel de guardião da aceitação — somente produções que passaram por aceitação rigorosa podem entrar na camada de ativos, e as quatro categorias de ativos devem ser solidificadas em conjunto, faltando uma, são irreproduzíveis ou não herdáveis. A segunda questão exige comparar "reproduzir o histórico de conversas" com "ler o repositório": o primeiro depende da janela de contexto, o custo cresce linearmente com o projeto, e uma vez truncada a conversa, a cognição se perde
> - o segundo reduz o custo de herança para checkout e carregamento, com resultados versionáveis, reproduzíveis e auditáveis, e o custo de tentativa e erro da rodada atual sedimenta-se como ponto de partida de reutilização da próxima rodada.

**Atividade em sala**

Peça aos alunos que recontem o conteúdo desta página com um exemplo próximo de sua própria experiência, e expliquem a relação entre esse exemplo e o critério de julgamento "a próxima pessoa consegue reproduzi-lo sem vir lhe perguntar".

**Verificação de compreensão**

Peça aleatoriamente a um aluno que resuma com suas próprias palavras os pontos principais desta página, e o professor complementa as palavras-chave omitidas com base na resposta, confirmando com foco que o aluno consegue mencionar simultaneamente os dois pontos "a divisão de trabalho das quatro categorias de ativos" e "a aceitação é o guardião da sedimentação".

> **Dica de transição**
>
> Após confirmar que os alunos conseguem expressar a relação central desta página — a sedimentação ocorre sobre contratos estáveis, é supervisionada pela aceitação e, finalmente, é herdada pela leitura do repositório — prossiga para a próxima página de aplicação ou resumo.

<a id="lecture-page-11"></a>

### Padrão de Engenharia de Colaboração Multi-Agente e Decomposição Recursiva de Tarefas

*Página 11*

> **Objetivo da página:** Compreender como múltiplos Agentes com ciclos de vida finitos colaboram para completar o desenvolvimento de projetos complexos e a decomposição de tarefas.

**Pontos-chave de ensino**

- Ao decompor tarefas, priorize perguntar "o que esta camada deve entregar de verificável", em vez de primeiro pensar "para qual Agente entregar". Depois que as entregas (conjuntos de dados, interfaces, pontos de verificação, relatórios de avaliação) estiverem claras, as fronteiras de responsabilidade e a divisão de camadas surgirão naturalmente.
- O ponto de parada da decomposição recursiva não é "decompor até o mínimo", mas "decompor até ser executável, verificável e completável dentro de um único contexto de um Agente". Decompor muito superficialmente excederá a capacidade da camada inferior, e decompor muito profundamente trará coordenação e perdas de transferência adicionais.
- Sobreposição de responsabilidades fará com que múltiplos Agentes implementem a mesma coisa repetidamente e produzam resultados conflitantes. Use definições claras de interface e critérios de aceitação para solidificar as fronteiras, e ao mesmo tempo convencionar o que a camada inferior pode decidir por conta própria e o que deve ser reportado à tarefa pai para arbitragem.

Objetivo da página

Quando a capacidade de contexto e a capacidade de processamento de um único executor são insuficientes para carregar todo o objetivo de engenharia, como degradar um grande problema em um conjunto de pequenos problemas entregáveis, e fazer com que os resultados da colaboração de cada camada sejam verificáveis e recuperáveis.

Sequência de exposição

Primeiro apresente o tema com "degradar um grande problema em um conjunto de pequenos problemas entregáveis", depois desenvolva a estrutura de três camadas, em seguida explique a motivação e a condição de término da decomposição recursiva, e finalmente chegue à relação de transferência bidirecional da árvore de tarefas e às três dicas de engenharia. Na exposição, pode-se usar o diagrama para apontar os nós camada por camada, ajudando os alunos a corresponder a divisão abstrata de trabalho com a árvore de tarefas concreta.

Pontos-chave de ensino

1. Estrutura de três camadas e suas respectivas responsabilidades. O executor superior foca no objetivo geral, responde "o que fazer", produz subtarefas delegáveis, condições de restrição e critérios de aceitação; o executor intermediário assume subtarefas ainda demasiado grandes e continua a decomposição recursiva, convergindo grandes objetivos difusos em níveis de tarefas estáveis; o executor inferior completa implementação e testes locais dentro de fronteiras de responsabilidade, produz resultados verificáveis e entrega para cima, formando um ciclo fechado local. No diagrama, o Agente superior divide os módulos de tarefa A, B, C; o módulo B, ainda pesado demais, é continuamente decomposto em subtarefas B1, B2, e os quatro nós folha finalmente chegam à implementação e teste locais de Agentes inferiores.

A camada superior fica no nó raiz e produz tarefas delegáveis e critérios de aceitação, em vez de realizar a implementação pessoalmente.

2. Por que a decomposição recursiva é necessária. A janela de contexto do executor, as ferramentas chamáveis e a escala de tarefas processáveis em uma única vez são todos limitados. Se um único executor mantiver todo o contexto do projeto a longo prazo, o custo aumentará com a escala, e também surgirão facilmente desvio de objetivo, poluição de estado e diluição de informações-chave. A decomposição recursiva distribui essa pressão entre as camadas: cada executor só precisa compreender o objetivo e as restrições de sua própria camada, e objetivos complexos são degradados camada por camada em unidades de trabalho executáveis e entregáveis, com a consistência geral garantida pela hierarquia de tarefas.

Árvore de tarefas e transferência bidirecional. Tarefas pai e subtarefas formam uma árvore de tarefas recursiva. O que flui para baixo é a delegação de tarefas — objetivos, restrições de fronteira e critérios de aceitação; o que flui para cima é a recuperação de resultados — produtos, evidências de verificação e problemas ainda não resolvidos. Se a colaboração realmente se estabelece depende de três coisas: se a hierarquia de tarefas é clara, se as fronteiras de responsabilidade são mutuamente exclusivas, e se os produtos de transferência (definições de interface, conjuntos de dados, casos de teste, pontos de verificação) são explicitamente convencionados. Faltando qualquer uma delas, múltiplos executores degenerarão em trabalho repetido e resultados conflitantes.

A profundidade da decomposição, a granularidade da delegação e a estratégia de recuperação de resultados também podem ser continuamente avaliadas e ajustadas. Quando feedback como "uma subtarefa está sendo retrabalhada repetidamente" afeta a próxima decomposição, esse fluxo de colaboração entra em um ciclo de auto-melhoria.

5. Dicas de engenharia. A condição de parada da decomposição recursiva não é "decompor até o mínimo", mas "decompor até ser executável, verificável e completável dentro de um único contexto de um único executor". Decompor muito superficialmente excederá a capacidade de processamento da camada inferior, e decompor muito profundamente trará muito overhead de coordenação e perdas de transferência. Pode-se primeiro definir as entregas, depois decidir quem faz; fronteiras pouco claras frequentemente são o maior custo da colaboração.

Tratamento dos exercícios

Esta página inclui um conjunto de questões conceituais de julgamento; sugere-se que, após o aluno responder, peça que ele aponte a base, e não apenas diga a opção.

A resposta correta é "compreender o objetivo geral e decompô-lo em subtarefas delegáveis e critérios de aceitação". Se o aluno errar, oriente-o a retornar ao posicionamento do nó raiz — o que se produz são tarefas e critérios de aceitação, não o código em si.

A resposta correta é "quando a subtarefa ainda é demasiado complexa e excede o alcance de processamento de um único". Deve-se enfatizar que a recursão não é uma ação incondicional; a condição de disparo é a subtarefa ainda ser demasiado grande, incapaz de ser completada e verificada em um único processamento.

O que aconteceria se houvesse apenas envio de tarefas? E se houvesse apenas recuperação de resultados? Explique com isso que a colaboração deve ser bidirecional.

A resposta correta é "distribuir o contexto e a pressão de processamento entre as camadas, reduzindo a carga de contexto de ponto único e o risco de desvio de objetivo". A palavra-chave é "distribuir", e não "garantir sucesso em uma única vez".

A resposta correta é "fazer com que os nós folha retenham unidades de trabalho executáveis e entregáveis, e explicitar interfaces e produtos de teste". Pode-se revisar: fronteiras vagas ou eliminação de camadas levarão a implementação repetida e conflitos de resultados.

Atividade em sala

O estudo de caso "entrega colaborativa de sistema de inspeção de qualidade de atendimento inteligente" é adequado como atividade em grupo. Primeiro, peça aos alunos que desenhem a árvore de tarefas recursiva: o nó raiz é responsável pela compreensão do objetivo geral e produz as três subtarefas A, B, C e os critérios de aceitação; o módulo B é continuamente decomposto pela camada intermediária em B1, B2, com interfaces explicitadas; os nós folha são as quatro categorias de unidades de trabalho A, B1, B2, C. Depois, peça a cada grupo que liste os produtos de transferência nas duas direções, para baixo e para cima, por exemplo especificações de interface de dados e conjuntos de dados de diálogo limpos, dicionário de características e especificações de anotação, pontos de verificação de modelos e relatórios de verificação, métricas de avaliação e configurações de implantação, e explique por que os nós folha já satisfazem a condição de parada.

Para a pergunta adicional de que B1 descobriu conflito entre "especificações de anotação" e "métricas de avaliação", pode-se guiar os alunos a resumir princípios de tratamento: conflitos sobem para arbitragem, não modificar os critérios de aceitação por conta própria; interfaces e padrões mantêm fonte única, gerenciados uniformemente pela camada superior; antes da arbitragem, manter o ciclo fechado local verificável; o resultado da arbitragem atualiza reversamente a árvore de tarefas e as entradas das subtarefas relacionadas; todo o processo registra conflitos, bases de arbitragem e critérios finais para rastreabilidade.

Verificação de compreensão

O que a camada superior é responsável por fazer, sob que condições a recursão continua, que informações as duas direções, superior e inferior, transmitem. Se conseguir mencionar simultaneamente a condição de parada e "definir primeiro as entregas, depois a divisão de trabalho", considera-se que esta página foi dominada.

Dica de transição

Após confirmar que os alunos conseguem distinguir "decompor tarefas" de "implementar pessoalmente", e explicar claramente a transferência bidirecional da árvore de tarefas, prossiga para a próxima página sobre mecanismos de verificação e sedimentação, para conectar o padrão de divisão de trabalho desta página com as etapas subsequentes de compilação, testes e aceitação.

<a id="lecture-page-12"></a>

### Mecanismo Rigoroso de Aceitação e Herança Histórica

*Página 12*

> **Objetivo da página:** Dominar como sedimentar modificações válidas no histórico do projeto por meio de compilação, testes e gateway de aceitação.

> **Sequência de exposição**
>
> Primeiro, destaque em uma frase "ao ver qualquer sistema de 'geração automática e melhoria automática', faça três perguntas: qual é a identidade padrão dos produtos do Agente (candidato?), quais verificações devem ser passadas para serem adotados (aceitação?), e depois de adotados, tornam-se base de quem (linha de base?). Separando essas três coisas, a lógica geral do mecanismo não se confunde.", depois combine com exemplos, diagramas ou palavras-chave da página para explicar por que isso é importante.

**Pontos-chave de ensino**

- Qual é a identidade padrão dos produtos do Agente (candidato?), quais verificações devem ser passadas para serem adotados (aceitação?), e depois de adotados, tornam-se base de quem (linha de base?). Separando essas três coisas, a lógica geral do mecanismo não se confunde.
- Compilação → testes → verificação de comportamento → aceitação pela camada superior é uma "ladeira abaixo" de "custo do baixo para o alto": quanto mais barato, mais à frente; quanto mais caro, mais atrás. Lembrando "filtrar primeiro o barato, revisar depois o valioso", não se desperdiça a revisão da camada superior em uma avalanche de candidatos-lixo.
- Passar na aceitação não significa que é realmente melhor. Quando a cobertura de testes é insuficiente ou a verificação de comportamento está ausente, o portão libera modificações prejudiciais. Cultive dois hábitos: complementar casos de regressão e definições de tolerância para comportamentos-chave
- manter sempre métricas observáveis e amostragem manual, como última linha de defesa quando os padrões são incompletos.

Mecanismo rigoroso de aceitação e herança histórica

11

AI999

Genesis e a sedimentação do mundo de software

Modificações geradas automaticamente por Agentes, com base em que podem ser escritas no tronco do projeto? O mecanismo rigoroso de aceitação e herança histórica desacopla completamente geração e adoção — qualquer código submetido por um Agente é apenas uma modificação candidata (candidate patch), e deve primeiro passar por um conjunto de portões de verificação para ter qualificação de ser reconhecida como parte do histórico do projeto.

Modificação candidata → quatro camadas de portões de aceitação → tronco / rejeição 候选修改队列 Agente submete · padrão não confiável Candidato A pendente de verificação Candidato B pendente de verificação Candidato C pendente de verificação Candidato D pendente de verificação ① Portão de compilação Sintaxe e interface construíveis · custo mais baixo, eliminação mais rápida ② Portão de testes Testes unitários / de integração todos verdes · cobre contratos existentes ③ Portão de verificação de comportamento Consistência semântica · tolerância numérica e equivalência ④ Aceitação pela camada superior Desempenho · razão de aceleração · manutenibilidade Rejeição · Área de arquivo de falhas · Retido como amostras negativas e material de diagnóstico · Armazenado isoladamente, não contamina o tronco · A rejeição em si é filtragem de ruído · Evita re-explorar o mesmo beco sem saída Histórico de versões do tronco (acumulação monotônica) Linha de base v3 · herdável, rastreável Linha de base v2 Linha de base v1 Feedback de herança histórica: linhas de base aceitas tornam-se o ponto de partida de execução de Agentes subsequentes Princípio padrão de candidatura Produtos de Agentes são por padrão considerados entradas não confiáveis: em permissões, armazenamento e referências, são estritamente isolados de versões aceitas, e não podem ler nem escrever diretamente no tronco, nem ser usados como dependência estável por outros módulos.

O único propósito deste princípio é eliminar "gerar e já armazenar". Somente após passar por todos os portões é que a modificação candidata obtém status equivalente ao do tronco. Filtragem progressiva em quatro camadas: custo crescente, falha precoce Compilação: construível em nível de sintaxe e interface. Custo mais baixo, eliminação mais rápida, bloqueando primeiro modificações obviamente inválidas. Testes: testes unitários e de integração aprovados, cobrindo contratos existentes. Verificação de comportamento: consistência semântica e comportamental, incluindo tolerância numérica, equivalência e comparação de regressão, especialmente prevenindo "testes aprovados mas comportamento desviante". Aceitação pela camada superior: decisão final voltada para objetivos de tarefa e restrições de engenharia, incluindo julgamentos de desempenho, razão de aceleração, manutenibilidade etc.

Os portões são ordenados do custo baixo para o alto, fazendo com que a grande maioria das modificações inválidas seja truncada na fase barata, reservando a cara revisão da camada superior para poucos candidatos de alta qualidade — esta é a economia da "falha precoce". O valor da rejeição e a herança histórica Tentativas não aprovadas não entram no tronco, mas podem ser retidas como arquivo de falhas / amostras negativas, para diagnóstico, deduplicação e prevenção de exploração repetida — a rejeição em si é uma filtragem de ruído. E as modificações que passam na aceitação tornam-se novas versões de linha de base, sobre as quais os executores subsequentes continuam a evoluir, formando uma cadeia evolutiva de acumulação monotônica, em vez de recomeçar do zero a cada rodada. Como regra de fusão e contrato de qualidade da colaboração multi-Agente e da decomposição recursiva de tarefas, o gateway de aceitação define "quem pode escrever no histórico", determinando assim se os resultados da colaboração convergem ou aumentam a entropia.

Em cenários de restrição forte de correção, como refatoração de compiladores e atualização de software científico, esse mecanismo demonstra altíssima confiabilidade e traz ganhos consideráveis de aceleração de execução. Fronteira de falha A completude dos próprios critérios de aceitação se tornará o novo gargalo: quando a cobertura de testes é insuficiente ou a verificação de comportamento está ausente, o portão libera modificações que "passam na aceitação mas são realmente prejudiciais". Portanto, é necessário usar métricas observáveis e amostragem manual como rede de segurança, e continuamente reforçar casos de regressão e definições de tolerância.

No mecanismo de aceitação rigorosa, qual é o status padrão do código submetido por Agentes?

Produto acabado cuja disponibilidade é determinada pelo próprio submetedor

Versão oficial que pode ser mesclada diretamente ao tronco

Modificação candidata pendente de verificação, estritamente isolada de versões aceitas em permissões, armazenamento e referências

Subproduto usado apenas para registro de logs, que não participa de nenhum fluxo

A candidatura padrão trata produtos de Agentes como entradas não confiáveis, estritamente isolados do tronco, evitando institucionalmente "gerar e já armazenar".

Saídas não verificadas não devem ter o mesmo status que versões aceitas.

Correto. Esta resposta consegue conectar com os conceitos desta página e explicar a base.

Retorne à exposição desta página, encontre evidências ou exemplos-chave e depois julgue.

Em que ordem são organizados os quatro portões de aceitação, e qual é a intenção de design?

Do custo alto para o baixo, priorizando investir recursos na revisão mais cara da camada superior

Ordenados pelo tempo de submissão dos candidatos, primeiro a chegar primeiro a ser verificado

Em ordem aleatória, para aumentar a diversidade de verificação

Compilação → testes → verificação de comportamento → aceitação pela camada superior, fazendo com que a grande maioria das modificações inválidas seja truncada na fase barata

Portões baratos são responsáveis pela eliminação em massa, portões caros só enfrentam poucos candidatos de alta qualidade.

Pense em qual camada é mais cara e qual é mais rápida. A ordem dos portões deve fazer com que revisões caras encontrem o mínimo possível de candidatos-lixo.

A verificação de comportamento (terceiro portão) previne principalmente qual tipo de problema?

Número insuficiente de casos de teste unitário

"Testes aprovados mas comportamento desviante", ou seja, inconsistência semântica ou de saída numérica entre implementações nova e antiga

Erros de sintaxe no código que impedem completamente a compilação

Histórico de versões do tronco ocupando espaço de armazenamento excessivo

A verificação de comportamento usa tolerância numérica, equivalência e comparação de regressão para comparar consistência semântica, interceptando desvios de comportamento não cobertos pelos testes.

A camada de compilação gerencia "consegue construir", a camada de testes gerencia "o contrato é satisfeito", e a verificação de comportamento foca em desvios semânticos mais ocultos.

Como deve ser entendido o valor de uma modificação candidata rejeitada pelo portão?

Deve ser completamente excluída, para não ocupar armazenamento e interferir em julgamentos subsequentes

Deve ser escrita diretamente no tronco, como contraste negativo retido

Pode ser retida como arquivo de falhas / amostras negativas, para diagnóstico, deduplicação e prevenção de exploração repetida

Deve ser reenviada repetidamente sem modificação, até passar automaticamente

Tentativas falhas são isoladas da linha principal, mas ainda podem ser usadas como amostras negativas — a rejeição em si é uma filtragem de ruído.

A diferença-chave está em se ela é permitida contaminar o tronco e se pode ser transformada em informação de diagnóstico reutilizável.

Qual das seguintes situações tem maior probabilidade de fazer o gateway de aceitação liberar modificações que "passam na aceitação mas são realmente prejudiciais"?

Cobertura de testes insuficiente ou verificação de comportamento ausente, tornando os próprios critérios de aceitação incompletos

A aceitação pela camada superior avalia simultaneamente desempenho, razão de aceleração e manutenibilidade

Existem simultaneamente múltiplas submissões de Agentes diferentes na fila de modificações candidatas

O arquivo de falhas é mantido por longo prazo para diagnóstico

O portão só consegue bloquear problemas que consegue detectar; quando os critérios de aceitação são incompletos, é necessário usar métricas observáveis e amostragem manual como rede de segurança.

O risco frequentemente não vem do submetedor, mas dos pontos cegos de cobertura dos próprios critérios de aceitação.

Aceitação de patch de reescrita do kernel do compilador

Leia o cenário e responda às duas perguntas abaixo.

Uma equipe usa colaboração multi-Agente para refatorar um kernel de compilador. O Agente X submeteu um patch de reescrita do kernel, alegando que pode melhorar a velocidade de execução de um determinado benchmark em cerca de 1,4 vezes. O sistema processa o patch de acordo com o "mecanismo rigoroso de aceitação e herança histórica": o patch primeiro entra na fila de modificações candidatas, depois passa sucessivamente por compilação, testes, verificação de comportamento e aceitação pela camada superior; se aprovado, é escrito de volta no tronco e torna-se o ponto de partida da próxima geração de Agentes; se não aprovado, entra na área isolada de arquivo de falhas.

1. Explique em ordem por quais verificações o patch deve passar, e explique por que a aceitação pela camada superior é colocada por último.

Compilação → testes → verificação de comportamento → aceitação pela camada superior. A compilação verifica se é construível em nível de sintaxe e interface, com custo mais baixo e eliminação mais rápida; os testes verificam se os testes unitários/de integração estão todos verdes, cobrindo contratos existentes; a verificação de comportamento compara a consistência semântica das implementações nova e antiga, incluindo tolerância numérica, equivalência e comparação de regressão; a aceitação pela camada superior faz a decisão final voltada para objetivos de tarefa e restrições de engenharia, julgando desempenho, razão de aceleração e manutenibilidade. A aceitação pela camada superior é colocada por último porque é a mais cara e requer intervenção humana ou de revisão de alto nível; somente após os primeiros portões truncarem a grande maioria dos candidatos inválidos é que esse recurso caro pode ser concentrado em poucos candidatos de alta qualidade, realizando "custo crescente, falha precoce".

Em algumas entradas, as saídas numéricas das implementações nova e antiga excedem a tolerância acordada. Como o sistema deve tratá-lo? Ele ainda tem valor? O que aconteceria se a verificação de comportamento fosse removida?

O patch não deve ser escrito no tronco, deve ser rejeitado e transferido para a área isolada de arquivo de falhas; como passou nas fases de compilação e testes, isso justamente indica que pertence ao tipo perigoso de "testes aprovados mas comportamento desviante". Ele ainda tem valor: pode ser retido como amostra negativa, para diagnosticar a origem da diferença, evitar que Agentes subsequentes repitam o mesmo beco sem saída, e sugerir que a equipe complemente casos de regressão ou reveja a definição de tolerância. Se a verificação de comportamento fosse removida, esse tipo de patch entraria diretamente na aceitação pela camada superior ou até seria escrito de volta no tronco com todos os testes verdes, introduzindo desvio de comportamento na linha de base histórica, o que é justamente a fronteira de falha desse mecanismo — o portão só consegue bloquear problemas que consegue detectar, portanto são necessárias métricas observáveis e amostragem manual como rede de segurança.

Candidato, aceitação, linha de base

Qual é a identidade padrão dos produtos do Agente (candidato?), quais verificações devem ser passadas para serem adotados (aceitação?), e depois de adotados, tornam-se base de quem (linha de base?). Separando essas três coisas, a lógica geral do mecanismo não se confunde.

A ordem dos portões é memorizada como uma ladeira abaixo

Compilação → testes → verificação de comportamento → aceitação pela camada superior é uma "ladeira abaixo" de "custo do baixo para o alto": quanto mais barato, mais à frente; quanto mais caro, mais atrás. Lembrando "filtrar primeiro o barato, revisar depois o valioso", não se desperdiça a revisão da camada superior em uma avalanche de candidatos-lixo.

O portão só consegue bloquear problemas que consegue detectar

Passar na aceitação não significa que é realmente melhor. Quando a cobertura de testes é insuficiente ou a verificação de comportamento está ausente, o portão libera modificações prejudiciais. Cultive dois hábitos: complementar casos de regressão e definições de tolerância para comportamentos-chave; manter sempre métricas observáveis e amostragem manual, como última linha de defesa quando os padrões são incompletos.

step-1

Dominar como sedimentar modificações válidas no histórico do projeto por meio de compilação, testes e gateway de aceitação.

lesson_6

lesson_6_slide_11

Do rascunho do EvoClass

> **Objetivo da página**
>
> Dominar o mecanismo de sedimentar modificações válidas no histórico do projeto por meio de compilação, testes e aceitação

**Pontos-chave de ensino**

- Mecanismo rigoroso de aceitação e herança histórica
- Código submetido por Agentes é apenas uma modificação candidata; somente após passar por compilação, testes, verificação de comportamento e aceitação pela camada superior pode entrar na versão aceita do projeto. Tentativas falhas podem ser rejeitadas, e resultados que passam na verificação tornam-se a base histórica dos executores subsequentes. Na refatoração de compiladores e atualização de software científico, esse mecanismo demonstra altíssima confiabilidade e ganhos de aceleração de execução.

**Pontos-chave de ensino**

- Mecanismo rigoroso de aceitação e herança histórica
- Código submetido por Agentes é apenas uma modificação candidata; somente após passar por compilação, testes, verificação de comportamento e aceitação pela camada superior pode entrar na versão aceita do projeto. Tentativas falhas podem ser rejeitadas, e resultados que passam na verificação tornam-se a base histórica dos executores subsequentes. Na refatoração de compiladores e atualização de software científico, esse mecanismo demonstra altíssima confiabilidade e ganhos de aceleração de execução. Mecanismo rigoroso de aceitação e herança histórica
- Código submetido por Agentes é apenas uma modificação candidata; somente após passar por compilação, testes, verificação de comportamento e aceitação pela camada superior pode entrar na versão aceita do projeto. lesson_id_distribution 86818163433546df25555ab4cb1c2d59fc1effedc37a25c4e84b74b7d294e704

**Base de materiais**

Do rascunho do EvoClass

> **Pistas de materiais**
>
> - Dominar o mecanismo de sedimentar modificações válidas no histórico do projeto por meio de compilação, testes e aceitação
> - Mecanismo rigoroso de aceitação e herança histórica
> - Código submetido por Agentes é apenas uma modificação candidata; somente após passar por compilação, testes, verificação de comportamento e aceitação pela camada superior pode entrar na versão aceita do projeto. Tentativas falhas podem ser rejeitadas, e resultados que passam na verificação tornam-se a base histórica dos executores subsequentes. Na refatoração de compiladores e atualização de software científico, esse mecanismo demonstra altíssima confiabilidade e ganhos de aceleração de execução.
> - Código submetido por Agentes é apenas uma modificação candidata; somente após passar por compilação, testes, verificação de comportamento e aceitação pela camada superior pode entrar na versão aceita do projeto.

**Atividade em sala**

Peça aos alunos que recontem o conteúdo desta página com um exemplo próximo de sua experiência, e que expliquem a relação entre esse exemplo e "ao ver qualquer sistema de 'geração automática e melhoria automática', faça três perguntas: qual é a identidade padrão dos produtos do Agente (candidato?), quais verificações devem ser passadas para serem adotados (aceitação?), e depois de adotados, tornam-se base de quem (linha de base?). Separando essas três coisas, a lógica geral do mecanismo não se confunde."

> **Objetivos correspondentes**
>
> - Compreender o padrão de engenharia de colaboração multi-Agente e decomposição recursiva de tarefas
> - Dominar o mecanismo de sedimentar modificações válidas no histórico do projeto por meio de compilação, testes e aceitação

**Verificação de compreensão**

Peça aleatoriamente a um aluno que resuma com suas próprias palavras os pontos principais desta página, e o instrutor complementa as palavras-chave omitidas com base na resposta.

> **Dica de transição**
>
> Após confirmar que os alunos conseguem expressar a relação central desta página, prossiga para a próxima página de exemplos, aplicações ou resumo.

<a id="lecture-page-13"></a>

### Atividade em Sala: Simulação de Colaboração Multi-Agente e Gateway de Aceitação Automatizada

*Página 13*

> **Objetivo da página:** Aprofundar a compreensão do desenvolvimento colaborativo multi-Agente e dos mecanismos de aceitação automatizada por meio de exercício simulado.

> **Objetivo da página**
>
> Por meio de uma simulação em sala de aula, compreender a divisão de tarefas no desenvolvimento colaborativo multi-Agente, a convergência de modificações candidatas e como o gateway de aceitação automatizada intercepta modificações não qualificadas; o foco é percorrer o ciclo de engenharia "desenvolvimento colaborativo—aceitação automática—herança histórica", e não fazer com que Agentes discutam entre si até chegar ao correto.

> **Sequência de exposição**
>
> Divida os grupos da turma em Agente de planejamento/decomposição, Agente de implementação, Agente de geração de testes e Agente de revisão/coordenação. A mesma tarefa pode produzir múltiplas modificações candidatas, e o gateway de aceitação faz a decisão unificada.
>
> Decomposição de tarefas, implementação paralela, aceitação automática, herança histórica. A decomposição de tarefas deve dividir o objetivo em subtarefas verificáveis independentemente, por exemplo "verificação de interface—correção de algoritmo—teste de regressão"; na fase de implementação paralela, múltiplos Agentes de implementação submetem patches candidatos, e o Agente de testes gera casos de fronteira; na fase de aceitação automática, executam-se testes automatizados, verificações estáticas e verificações de contrato, e o gateway decide por critérios executáveis; na fase de herança histórica, modificações aprovadas são mescladas na linha de base histórica, e modificações rejeitadas retêm razões de falha e informações de reprodução para nova tentativa.
>
> À esquerda está a decomposição recursiva de tarefas, no meio as modificações candidatas multi-Agente, à direita os testes automatizados e o gateway de aceitação. Os candidatos convergem e entram no gateway; se aprovados, são mesclados na linha de base histórica; se rejeitados, são devolvidos com feedback reproduzível, que retorna aos elos de implementação e teste.
>
> Os critérios devem ser executáveis, não podendo permanecer em "parece correto". O foco é interceptar modificações que não satisfazem convenções de interface, introduzem regressões, não cobrem condições de fronteira ou violam restrições de qualidade. Um feedback utilizável deve conter pelo menos caso de falha, logs, passos de reprodução, comportamento esperado e restrições relacionadas.
>
> Modificações aprovadas entram na linha de base, e Agentes subsequentes não precisam começar do zero; modificações rejeitadas tornam-se exemplos negativos pesquisáveis, evitando repetir erros. Na avaliação, deve-se atentar se as regras de aceitação são reproduzíveis, se o feedback é acionável, e aos diferentes riscos de interceptação errada e não interceptação.

**Pontos-chave de ensino**

- Antes da aceitação, escrever primeiro testes executáveis, asserções de contrato e casos de fronteira
- uma regra que não pode ser reproduzida não pode interceptar de forma estável. Candidatos rejeitados devem vir acompanhados de logs de falha, comandos de reprodução, comportamento esperado e restrições relacionadas, para que o próximo Agente possa localizar e revisar diretamente. Granularidade de decomposição muito fina elevará o custo de fusão e aceitação, muito grossa fará com que modificações candidatas se sobreponham
- priorize decompor em subtarefas que possam ser testadas e aceitas separadamente.

> **Pistas de materiais**
>
> - Decomposição recursiva de tarefas, modificações candidatas multi-Agente, testes automatizados e gateway de aceitação. O diagrama também marca "convergência de candidatos", "retorno de feedback" e "aprovados entram na linha de base, rejeitados retornam com feedback reproduzível", adequado para apontar o diagrama enquanto se explica o ciclo. Pode-se pedir aos alunos que, em torno do caso "serviço de pagamento trava com entrada de números negativos ou strings muito longas", projetem um conjunto de regras executáveis de gateway de aceitação, cobrindo pelo menos interface, regressão, fronteira e restrições de qualidade. Direção de referência: a camada de interface exige que o campo de valor rejeite números negativos e strings muito longas, retornando código de erro unificado e fazendo asserções de contrato
> - a camada de regressão exige que todos os casos originais de pagamento bem-sucedido, reembolso e conciliação passem e não haja novas falhas
> - a camada de fronteira inclui casos de 0, números negativos, valor máximo permitido, string muito longa, string vazia e caracteres especiais, com asserção de não travar e erro explicável
> - as restrições de qualidade incluem verificações estáticas aprovadas, cobertura de caminhos críticos não inferior ao limiar acordado, e ausência de alertas de alto risco. Todas as regras devem ser expressas como testes ou scripts executáveis, e reproduzíveis em integração contínua.

> **Pistas de exercícios**
>
> - Interceptação errada desperdiça o trabalho de candidatos corretos e reduz a eficiência da colaboração, podendo também induzir a equipe a relaxar padrões
> - não interceptação faz com que defeitos entrem na linha de base histórica, e Agentes subsequentes continuem trabalhando com base em uma linha de base errada, amplificando o risco de regressão. Formas de redução incluem reter evidências de falha, fazer amostragem e revisão dos resultados de interceptação, sedimentar casos de falha novos como conjuntos de regressão, e combinar casos de fronteira, verificações de contrato e validação gradual para controlar riscos.

**Verificação de compreensão**

Peça aleatoriamente a um aluno que resuma com suas próprias palavras os pontos principais desta página, verificando se consegue mencionar os três pontos-chave "critérios executáveis", "feedback acionável" e "decompor por fronteiras verificáveis independentemente". Se conseguir exemplificar com o caso do serviço de pagamento, considera-se dominado; se responder apenas "deixar os Agentes discutirem automaticamente", oriente a retornar aos critérios do gateway de aceitação e ao fluxo do ciclo.

> **Dica de transição**
>
> Após confirmar que os alunos conseguem explicar claramente a relação entre colaboração multi-Agente, aceitação automática e herança histórica, prossiga para a próxima página de aplicação, exemplos ou resumo.

<a id="lecture-page-14"></a>

### Modo de Trabalho AI Native e Entrada Conveniente

*Página 14*

> **Objetivo da página:** Compreender como iniciar rapidamente experimentos com EvoX por meio de entradas e configurações concisas em ferramentas de IA.

**Pontos-chave de ensino**

- Lembre-se desta linha de divisão de trabalho: a entrada AI Native é responsável por instalação, configuração básica e verificação de ambiente; você é responsável pela definição do problema, escolha de direção e critérios de avaliação. Investir o tempo economizado neste último fará com que os benefícios realmente recaiam sobre a pesquisa; caso contrário, apenas se transfere a espera da configuração para o retrabalho.
- O valor de um comando de uma frase é permitir que você entre rapidamente no experimento, não pular a verificação. Após a instalação, confirme ativamente a versão, dependências e visibilidade da GPU, trate o estado reportado pela ferramenta como pista, não como conclusão, para que experimentos subsequentes tenham pontos de referência confiáveis.
- Antes de reproduzir em outra máquina, verifique item por item: se as listas de dependências e versões são consistentes, se o modelo de GPU e o número de dispositivos disponíveis são iguais, se as sementes aleatórias e hiperparâmetros-chave estão fixados. Após os três itens passarem, amplie a escala do experimento, evitando custos de investigação posteriores muito maiores que os de configuração inicial.

Objetivo da página**

O que exatamente o modo de trabalho AI Native mudou, e onde estão suas fronteiras. Após aprender, deve-se conseguir explicar três pontos: a entrada de interação migrou de consultar documentação manualmente, instalar dependências, configurar ambiente e escrever scaffolding para iniciar experimentos com um comando em ferramentas de IA; instalação, configuração básica e verificação de ambiente são assumidas pela ferramenta, que reporta o estado; definição do problema, escolha de direção e critérios de avaliação continuam sob responsabilidade do pesquisador.

Pontos-chave de ensino**

1. A migração da entrada é a característica definidora. O caminho tradicional é "consultar documentação → instalar dependências → configurar ambiente → escrever scaffolding → só então começar o primeiro experimento", e cada elo pode dar errado, além de que cada troca exige reconstruir o contexto. O caminho AI Native é "comando de uma frase → a ferramenta assume instalação e configuração → verificação de ambiente aprovada → entrar no experimento". O que muda é a forma como a pessoa começa a trabalhar, não o objeto sendo otimizado em si.

2. A natureza do atrito é transferência, não desaparecimento. O verdadeiro fardo frequentemente não vem da dificuldade de uma única operação, mas da troca frequente de contexto: o pesquisador deveria estar focado em modelagem do problema, design de experimentos e interpretação de resultados, mas é constantemente interrompido por conflitos de versão, dependências ausentes e caminhos de ambiente. A entrada conveniente transfere toda a cadeia de engenharia, devolvendo a atenção à pesquisa em si.

Completar a instalação e configuração básica do EvoX dentro de um comando de uma frase. Por exemplo, digitar "instalar EvoX e completar configuração básica", a ferramenta executa e retorna o resultado, e o pesquisador entra imediatamente no experimento. Note que este é apenas o ponto de partida, não o ponto final — o "configuração concluída" reportado pela ferramenta é um estado que precisa ser verificado, não uma conclusão que pode ser aceita diretamente.

4. Quanto mais curto o caminho, menor a distância da ideia ao experimento executável, a ideia pode ser verificada no mesmo dia, e hipóteses falhas podem ser rapidamente excluídas. Isso é especialmente evidente para temas de evolução de métodos que exigem montar repetidamente estruturas experimentais internas e externas: o tempo pode ser investido em design de estratégias, critérios de avaliação e atribuição de resultados, em vez de consertar o ambiente repetidamente.

A entrada conveniente reduz o custo de início e configuração, mas não substitui o julgamento do pesquisador sobre o valor do problema, a direção da pesquisa e as métricas de avaliação. Interpretar "economizar tempo" como "economizar julgamento" é o desvio mais comum desta página. O tempo economizado só produz benefícios reais na pesquisa se for investido no elo de julgamento; caso contrário, apenas se transfere a espera da configuração para o retrabalho.

Pistas de materiais**

A linha superior em cinza são os quatro passos do caminho tradicional, com a anotação "fricção concentrada" abaixo; a linha do meio em azul são os quatro passos do caminho AI Native, com "comando de uma frase" destacado, e a anotação "fricção transferida" abaixo; o bloco laranja na parte inferior é a "fronteira de posicionamento". Na exposição, pode-se perguntar diretamente: qual trecho foi removido no diagrama, e qual trecho permaneceu? Guie os alunos a descobrir — o que foi transferido é instalação, configuração básica e verificação de ambiente; o que foi mantido são problema, direção e critérios de avaliação.

Tratamento dos exercícios**

As cinco questões de múltipla escolha devem ser tratadas em conjunto após a exposição, com uma frase de base de julgamento para cada questão, facilitando a autoverificação dos alunos.

O julgamento correto é "a entrada de interação padrão muda de consultar documentação manualmente, configurar ambiente e escrever scaffolding para iniciar experimentos diretamente com comandos concisos em ferramentas de IA". Se escolher estratégias de busca, migração para nuvem ou substituição de estrutura de rede, isso indica confusão entre "mudança de entrada" e "mudança de algoritmo", sendo necessário retornar a esta página e enfatizar: este ponto descreve como a pessoa começa a trabalhar.

O julgamento correto é "a ferramenta completa instalação, configuração básica e verificação de ambiente dentro de um comando de uma frase e reporta o estado, e o pesquisador entra no experimento com base nisso". Se acreditar que a ferramenta garante que não é mais necessário verificar versão e visibilidade da GPU, ou que ela determinará automaticamente questões de pesquisa e métricas de avaliação, isso indica que se ampliou demais o alcance — ela cobre apenas o trecho de engenharia de instalação e configuração básica.

O julgamento correto é "reduz o custo de início e configuração, mas não substitui o julgamento do pesquisador sobre definição do problema, direção da pesquisa e critérios de avaliação". Ler "economizar tempo" como "economizar julgamento", ou acreditar que só tem valor para iniciantes, exige retornar à conclusão de fronteira para reposicionar.

O julgamento correto é "o valor vem da transferência da fricção de engenharia e do encurtamento do ciclo de iteração, e a condição de validade é que o pesquisador ainda consiga verificar os resultados de configuração e a reprodutibilidade dos experimentos". Aqui deve-se destacar a distinção entre "reduzir operações manuais" e "reduzir julgamento manual".

A questão 5 é uma projeção de consequências da não verificação, e o julgamento correto é "ambiente irreprodutível, diferenças entre experimentos difíceis de localizar, estabilidade dos resultados não pode ser garantida". No feedback, destacar: o problema não está no limite superior da capacidade da ferramenta, mas na ausência do elo de verificação; configurações não verificadas plantam riscos para reprodução e localização de falhas subsequentes.

Atividade em sala**

A discussão do caso pode ser desenvolvida em torno de "executar um experimento de evolução de métodos com EvoX em três dias". A primeira questão exige explicar o que foi reduzido em custo e o que foi mantido como responsabilidade: o que foi reduzido é o custo de fricção de engenharia, o que foi mantido são as decisões de modelagem do problema e da direção, a determinação dos critérios de avaliação e a verificação da configuração. A segunda questão foca na reprodução em múltiplas máquinas, e pode-se guiar os alunos a dar pelo menos dois procedimentos verificáveis: salvar as versões e listas de dependências realmente instaladas pela ferramenta e comparar item por item entre máquinas; verificar o modelo de GPU, memória de vídeo e número de dispositivos visíveis de cada máquina, fixando números de dispositivo quando necessário; fixar sementes aleatórias e configurações-chave como tamanho de lote, primeiro reexecutar tarefas de referência sob a mesma configuração, confirmar que os resultados ficam dentro da faixa esperada de variação, e só então ampliar a escala do experimento.

Verificação de compreensão**

"Se toda a instalação for entregue à ferramenta, o que você mais precisa confirmar manualmente no dia seguinte?" Conseguir mencionar a verificação de versão, dependências e visibilidade da GPU já conta como domínio.

Dica de transição**

Após confirmar que os alunos conseguem expressar a linha de divisão de trabalho "a ferramenta é responsável pela preparação de engenharia, o pesquisador pelo julgamento de pesquisa", prossiga para a próxima página de exemplos, aplicações ou resumo.

<a id="lecture-page-15"></a>

### O Gosto Central do Pesquisador: Divisão de Trabalho Humano-IA e Pensamento Crítico

*Página 15*

> **Objetivo da página:** Compreender o gosto científico insubstituível e o julgamento crítico do pesquisador no processo de evolução assistida por IA.

> **Objetivo da página**
>
> Compreender o gosto científico insubstituível e o julgamento crítico do pesquisador no processo de evolução assistida por IA. A questão central é: quando a IA reduz enormemente o custo de "implementar respostas", para onde se desloca o valor da pesquisa científica?

**Pontos-chave de ensino**

- IA / EvoX podem completar rapidamente implementação de código, execução em lote de experimentos, geração de candidatos, busca de parâmetros e registro de feedback; o custo de engenharia deixa de ser o gargalo central. O pesquisador decide quais problemas valem a pena ser estudados, quais resultados têm significado, quais evidências são suficientes para sustentar conclusões. A IA expande a implementação e o espaço de busca
- o pesquisador controla definição do problema, conflitos de objetivos, fronteiras de restrições e critérios de aceitação. Trate as saídas da IA como hipóteses a serem testadas, verifique se as hipóteses se sustentam, se as evidências são suficientes, se as condições de fronteira foram consideradas, se resultados negativos foram ignorados, evitando ser enganado por respostas fluentes mas não verificadas. Sob exploração aberta e feedback esparso, a escolha de direção não pode ser terceirizada para a IA
- o julgamento final e a responsabilidade científica ainda pertencem ao pesquisador. À esquerda está a IA / EvoX, correspondendo a gerar candidatos, executar experimentos, espaço de busca, registrar feedback
- à direita está o pesquisador, correspondendo a levantar problemas, avaliar evidências, pesar trade-offs, refletir sobre a direção
- no meio está "Code is cheap. Taste matters". Abaixo, "ciclo de feedback: pontos de verificação críticos" indica que este não é um fluxo unidirecional, mas um ciclo em que a produção da IA retorna para a pessoa, e a pessoa redefine problemas e padrões. Em tarefas de otimização multiobjetivo do EvoX, a IA gera rapidamente um grande número de soluções candidatas e código experimental. O pesquisador precisa julgar: a função objetivo reflete necessidades reais? A linha de base é justa? As métricas omitem restrições-chave? Se olhar apenas a pontuação, pode-se selecionar soluções aparentemente ótimas mas que não atendem às necessidades reais. Aqui, a forma como "Code is cheap. Taste matters" se manifesta é: a IA é responsável pela implementação rápida e busca, e o pesquisador examina a definição do problema e os padrões de evidência, julgando quais resultados realmente têm significado.

**Tratamento dos exercícios**

O gosto científico insubstituível e o julgamento crítico do pesquisador, e a divisão de trabalho em que a IA é responsável pela implementação e a pessoa pelo julgamento. A característica típica de opções erradas é pular conceitos, pular consulta de materiais, concluir apenas por intuição, ou alterar todos os fatores simultaneamente para comparar resultados. A resposta do caso em sala deve recair sobre: tratar as saídas da IA como hipóteses a serem testadas, verificar função objetivo, linha de base e métricas; ao mesmo tempo, deixar claro que a escolha de direção e a responsabilidade científica não podem ser terceirizadas.

**Verificação de compreensão**

Peça aos alunos que distingam com suas próprias palavras "custo de implementação" e "valor de julgamento", e deem um exemplo de elo que pode ser entregue à IA e um elo que deve ser de responsabilidade do pesquisador. Após conseguirem explicar a relação entre os dois, prossiga para a próxima página.

<a id="lecture-page-16"></a>

### Resumo do Curso: Construir Infraestrutura de Mundo de Software em Evolução Contínua

*Página 16*

> **Objetivo da página:** Resumir o conteúdo central de todo o curso e deixar clara a visão de construir uma infraestrutura inteligente aberta, evolutiva e em sedimentação contínua.

**Pontos-chave de ensino**

- Soluções candidatas, o método que gera candidatos (como as configurações interna e externa do MetaDE) e ativos em nível de projeto são três níveis diferentes. Antes de projetar ou responder, deixe claro "qual camada estou otimizando agora", o que evita confundir evolução de métodos com evolução contínua em nível de projeto.
- Somente produções que passaram por aceitação rigorosa podem entrar na biblioteca de experiências e ser herdadas. Uma vez que resultados não aceitos sejam herdados por tarefas subsequentes, o erro será amplificado ao longo da cadeia de herança, e será muito difícil localizar a origem.
- No início de cada nova tarefa, pergunte-se: quais produções e entradas de experiência já verificadas da rodada anterior eu reutilizei diretamente nesta rodada? Se a resposta for vazia, isso indica que o fluxo atual ainda permanece em tarefa única, e não em infraestrutura em evolução contínua.

Objetivo da página

Elevar a "evolução inteligente" de busca única e otimização única para infraestrutura de software voltada ao mundo real. O foco não é introduzir mais um novo algoritmo, mas fazer com que os alunos vejam como o sistema atravessa tarefas individuais e Agentes individuais, mantendo-se aberto, confiável e continuamente conectado a problemas reais por meio do ciclo "tarefa—exploração—aceitação—herança—re-evolução".

Pontos-chave de ensino

1. Atualização do objeto de evolução. Genesis expande o objeto de evolução de soluções candidatas de uma única tarefa para evolução contínua em nível de projeto, atravessando Agentes e ciclos de tarefas. O fim de uma execução não zera mais o estado; o fim da tarefa torna-se justamente o ponto de partida da próxima rodada.

2. Paradigma de sedimentação de engenharia. Aceitação rigorosa, herança histórica e sedimentação de experiência são indispensáveis: a aceitação é o portão, decidindo o que tem qualificação para permanecer; a herança é o caminho, decidindo se o sedimento pode realmente ser invocado na próxima rodada; a sedimentação de experiência permite que o sistema acumule estabilidade entre múltiplas tarefas. Apenas escrever documentos e relatórios semanais não é sedimentação de engenharia; ativos que podem ser executados, herdados e reutilizados é que são.

3. Posicionamento do EvoX. O EvoX está na camada inferior, fornecendo base de poder computacional, execução paralela e agendamento evolutivo, sustentando para cima a construção de sistemas abertos, combináveis e acumuláveis continuamente; não é um módulo que substitui decisões de Agentes, nem um componente de exibição de visualização de resultados.

4. Visão final. O mundo de software não é um produto fechado entregue de uma vez, mas uma infraestrutura inteligente que evolui continuamente, sedimenta continuamente e se conecta continuamente a problemas reais. As palavras-chave são evolução contínua, sedimentação contínua, conexão contínua.

Pistas de materiais

Produções de aceitação (resultados parciais que passaram por aceitação rigorosa), biblioteca de experiência (estratégias reutilizáveis e lições de falha estruturadas), herança histórica (ponto de partida direto da próxima rodada de tarefas). O diagrama em camadas à esquerda é lido de baixo para cima: EvoX Runtime até evolução contínua em nível de projeto, depois colaboração multi-Agente, e finalmente conexão com problemas do mundo real, formando um circuito de evolução contínua.

Formas organizacionais viáveis

Múltiplos Agentes são responsáveis respectivamente por busca de literatura, implementação de código e reprodução de experimentos; cada exploração é escrita em registros de experimentos; resultados parciais devem ser confirmados conjuntamente por verificação humana e automática para entrar na biblioteca compartilhada; a próxima rodada de tarefas parte diretamente de resultados já confirmados. Assim, o projeto não é uma coleção de documentos "arquivados após conclusão", mas uma linha de montagem de tarefas para exploração, aceitação, herança e re-evolução. Deve-se enfatizar: sem aceitação, a sedimentação será contaminada por erros; sem herança, a sedimentação não gera juros compostos, e o projeto degenera em trabalho repetido.

Equívocos comuns

Equiparar sedimentação de engenharia a escrever documentos e relatórios semanais. Os sedimentos que realmente podem ser invocados pela evolução subsequente são ativos executáveis: produções que passaram na aceitação, entradas estruturadas da biblioteca de experiência, estratégias e configurações herdáveis. Documentos são apenas a casca; "sedimentação" sem aceitação e canais de herança não gera juros compostos.

Tratamento dos exercícios

Expandir o objeto de evolução de uma única tarefa para evolução contínua em nível de projeto, atravessando Agentes e ciclos de tarefas. Pontos de feedback: esta questão pergunta sobre mudanças no nível do objeto de evolução, não sobre mudanças no modo de amostragem ou execução.

Aceitação rigorosa, herança histórica e sedimentação de experiência constituem juntas um paradigma de sedimentação estável e confiável. Pontos de feedback: reveja os três cartões "produções de aceitação, biblioteca de experiência, herança histórica"; faltando um elo, a sedimentação falha.

O EvoX é infraestrutura de evolução inteligente conectada ao mundo real, sustentando a construção de sistemas abertos, combináveis e acumuláveis continuamente. Pontos de feedback: o EvoX é o provedor de capacidade mais fundamental, não um componente de exibição nem um substituto de decisor.

A evolução de métodos faz com que "o método que gera candidatos" participe da iteração,