Reprodução Científica Autônoma via Orquestração Hierárquica Multi-Agente: Uma Análise Profunda de Arquitetura de Sistemas

1.Taxonomia do Sistema e Invariantes Fundamentais

O sistema opera sob três invariantes arquiteturais não negociáveis:

1. Determinismo verificável: o veredicto final é emitido pelo pytest, um oráculo externo ao LLM, eliminando o viés de autoavaliação (sycophancy loop) que contamina pipelines onde o modelo julga seu próprio output.
2. Estado externalizável e durável: nenhum estado crítico reside exclusivamente na context window. Toda progressão é materializada em artefatos persistentes (SQLite DAG, Git commits, Vector Store), tornando o sistema restartable e resumable após falhas arbitrárias.
3. Observabilidade de primeira classe: Trace Tree e Budget Guard não são elementos secundários. São first-class citizens do design, posicionados arquiteturalmente no mesmo nível das camadas funcionais.

A classificação formal do sistema é: agentic workflow com topologia DAG, execução híbrida série/paralela e mecanismo de rollback determinístico.

2.Setup Phase: Contratos Formais como Specification Layer

2.1 Problem Classifier: Divergência Ontológica do Espaço de Soluções

O Problem Classifier resolve uma ambiguidade fundamental antes de qualquer alocação de recursos computacionais: o espaço de soluções é convexo ou multimodal?

Convergente: existe um atrator único no espaço de outputs, sendo uma métrica numérica, um threshold ou um resultado determinístico. A função de loss é unimodal e o critério de parada é objetivo.

Divergente: o espaço de soluções é multimodal, com múltiplas implementações igualmente válidas. Requer heurísticas de poda (Tree of Thoughts) e sampling estocástico (Best of N).

Essa bifurcação é crítica porque define qual subconjunto do Cognition Layer será ativado e com qual intensidade. Problemas convergentes são roteados para execução mais determinística, enquanto os divergentes ativam capacidades exploratórias.

2.2 Definition of Done: Formalização de Critérios como Contratos Verificáveis

Os cinco critérios contratuais do Definition of Done são, na prática, invariantes de pós-condição, análogos a assertions em Design by Contract (DbC). Cada critério possui a seguinte estrutura:

criterion := {
  id: UUID,
  metric: Callable[[Artifact], float],
  threshold: float,
  tolerance: float,  // margem para p75 matching
  weight: float      // para scoring parcial
}

Esses contratos são injetados downstream no Verifier como test fixtures e no Spec Layer Verdict como scoring rubric. A separação entre definição (Setup Phase) e avaliação (Verifier) implementa o princípio de separation of concerns entre especificação e execução.

3.Worker Components: Pipeline com Feedback Loops Explícitos

3.1 Paper Analyzer: Extração de Semântica Estruturada de Documentos Não Estruturados

O Paper Analyzer enfrenta o problema clássico de information extraction de documentos científicos semiestruturados. O PDF é um formato de renderização, não de semântica. Equações LaTeX são renderizadas como vetores, tabelas como bounding boxes e referências como texto plano.

O componente precisa resolver três desafios principais:

Mathematical AST extraction: converter equações renderizadas em representação simbólica manipulável, como uma SymPy tree.

Prior elicitation: identificar assunções implícitas do paper, incluindo distribuições assumidas, normalizações não documentadas e hiperparâmetros default.

Experimental protocol reconstruction: inferir o pipeline de ML a partir de descrições em linguagem natural, tolerando ambiguidade e underspecification.

O output é um structured experimental spec que serve como input formal para o Code Implementer.

3.2 Code Implementer: Architect/Editor Split como Separation of Abstraction Levels

O padrão Architect/Editor é uma instância de hierarchical task decomposition aplicada à geração de código:

Architect Agent:
  - Define interfaces, abstrações e contratos entre módulos
  - Produz scaffolding com type signatures e docstrings
  - Não implementa lógica de negócio, apenas estrutura

Editor Agent:
  - Recebe scaffolding como contexto fixo
  - Implementa corpos de função dentro das interfaces definidas
  - Context window focada, com menor risco de hallucination por context drift

O Architect opera com baixa entropia de decisão, priorizando estrutura sobre detalhes. O Editor opera com contexto altamente constraindo. Cada agente possui um espaço de decisão menor e bem definido, o que reduz a probabilidade de outputs incoerentes.

O loop fail → regenerate é um retry com backpressure: falhas no Verifier propagam um diff estruturado de volta ao Code Implementer, não uma instrução genérica de repetição. Isso implementa gradient-like feedback no espaço discreto de geração de código.

3.3 Experimenter: Sandboxed Execution com Subagent Parallelism

O Experimenter executa sobre o Sandbox REPL (Docker persistente) com cinco subagentes especializados em série. A topologia série, em vez de paralela, é uma escolha deliberada de design por três razões:

• Cada subagente consome o estado produzido pelo anterior
• Permite incremental validation, detectando falhas antes de computação cara
• Mantém linearidade do Task DAG para auditabilidade

O Docker persistente resolve o problema de environment reproducibility: o mesmo filesystem, dependências e variáveis de ambiente são garantidos entre execuções, eliminando a classe de bugs conhecida como "works on my machine".

3.4 Verifier: Pytest como Oráculo Externo e Anti-Hallucination Gate

O Verifier é o componente mais crítico do sistema do ponto de vista de correctness guarantees. O uso do pytest como mecanismo de avaliação produz três efeitos arquiteturais importantes:

1. Remove o LLM do critical path de avaliação: o modelo não pode racionalizar um output incorreto como correto
2. Garante idempotência: os mesmos artefatos sempre produzem o mesmo veredicto
3. Habilita regression testing: novas iterações são validadas contra o mesmo test suite

A integração com Definition of Done é acoplada: cada critério contratual é materializado como um test case com assertion explícita.

4.Cognition Layer: Capacidades como First-Class Callable Abstractions

O Cognition Layer implementa o padrão Strategy Pattern aplicado a capacidades de raciocínio. Cada capacidade é uma estratégia intercambiável, selecionada dinamicamente com base no tipo de problema.

4.1 Thinking Channel: Chain-of-Thought como Computation Graph Explícito

Força a geração de um reasoning trace antes do output final. Do ponto de vista de inferência, isso aloca tokens adicionais para computação intermediária, análogo a aumentar a profundidade de um grafo de computação. O trade-off é direto: maior latência e custo resultam em menor taxa de erro em raciocínio multi-step.

4.2 Compute Allocator: Adaptive Token Budgeting

Resolve o problema de alocação ótima de recursos computacionais sob constraint de budget. Implementa uma política de scheduling que estima a complexidade do subproblema e aloca max_tokens proporcionalmente. Conecta-se ao Budget Guard para enforcement de hard limits.

A propagação DOWNWARD significa que o budget alocado pelo Compute Allocator se torna um constraint injetado nos workers subsequentes, implementando backpressure de recursos.

4.3 Best of N Sampler: Ensemble Decoding com Verifier-in-the-Loop

Gera N candidatos com temperatura maior que zero (sampling estocástico) e usa o Verifier como discriminator para selecionar o melhor. Isso transforma o problema de geração em um problema de search no espaço de outputs, com função de fitness externa ao modelo gerador.

O custo é O(N) em tokens de geração. O benefício é redução substancial de variância no output final.

4.4 Tree of Thoughts: Beam Search no Espaço de Raciocínio

Implementa breadth-first exploration do espaço de raciocínio com três operações fundamentais:

expand(node) → List[ThoughtNode]   // gera ramificações
score(node)  → float               // avalia promissidade
prune(tree)  → Tree                // elimina ramos de baixo score

É essencialmente beam search aplicado a cadeias de raciocínio em vez de sequências de tokens. Útil para problemas onde o caminho de raciocínio ótimo não é greedy.

4.5 Step Back Reasoner: Abstraction Lifting antes de Grounding

Força o modelo a abstrair o princípio geral antes de atacar o caso específico, mitigando o problema de overfitting ao enunciado, onde o modelo trata o problema como pattern matching em vez de raciocínio por princípios fundamentais.

A propagação DOWNWARD injeta o princípio abstraído como contexto adicional nos workers, funcionando como um prior informativo para a geração subsequente.

5.Infraestrutura de Estado: Persistência Multi-Modal

5.1 Task DAG (SQLite): Workflow Engine com Estado Durável

O Task DAG é o sistema nervoso central de coordenação do pipeline. Armazena o grafo de tarefas com o seguinte schema:

CREATE TABLE tasks (
  id TEXT PRIMARY KEY,
  parent_id TEXT REFERENCES tasks(id),
  status TEXT CHECK(status IN ('pending','running','done','failed')),
  subgoal_index INTEGER,  -- 0..7 (8 subgoals)
  artifact_path TEXT,
  created_at TIMESTAMP,
  updated_at TIMESTAMP
);

A escolha de SQLite em vez de um message broker (Kafka, RabbitMQ) é deliberada. Prioriza simplicidade operacional e ACID guarantees sem overhead de infraestrutura distribuída. O estado sobrevive a reinicializações porque o SQLite é um arquivo em disco: reinicializações de container não apagam o progresso.

5.2 Bi-Temporal Memory: Event Sourcing com Dimensão Temporal Dupla

A memória bi-temporal armazena dois timestamps independentes por registro:

valid_from / valid_to: quando o fato era verdadeiro no mundo real, como o momento em que o paper reportou determinado valor.

recorded_at: quando o sistema registrou essa informação.

Isso habilita queries como: "O que o sistema acreditava sobre o resultado Y no momento T1, mesmo que tenha descoberto que estava errado em T2?" Essa capacidade é essencial para debugging retroativo de pipelines de longa duração.

É uma implementação parcial de Event Sourcing: o sistema nunca sobrescreve registros, apenas appenda novos com timestamps atualizados.

5.3 Vector Store (bge-m3): Semantic Retrieval para Reutilização de Conhecimento

O modelo bge-m3 (BGE Multilingual Large) produz embeddings densos de alta qualidade para recuperação semântica cross-lingual. O Vector Store habilita três casos de uso principais:

Few-shot retrieval: recuperar implementações similares de experimentos anteriores como exemplos in-context.

Prior code reuse: evitar regeneração de utilidades já implementadas.

Semantic deduplication: identificar subproblemas equivalentes com diferentes formulações textuais.

5.4 Git Checkpointer: Auditabilidade como First-Class Feature

Cada transição de estado no pipeline gera um commit atômico com mensagem estruturada:

[STEP:3/8] Code Implementer: generated regression module
  - Files changed: src/model.py, src/preprocessing.py
  - Verifier status: PENDING
  - Budget consumed: $0.0012

Isso transforma o histórico Git em um append-only audit log com granularidade por etapa, viabilizando rollback cirúrgico a qualquer ponto intermediário sem perder progresso anterior.

6.Hardening Layer: Defense in Depth para Qualidade de Output

6.1 Linter Gate: Static Analysis como Circuit Breaker

O Linter Gate implementa o padrão Circuit Breaker aplicado à qualidade de código:

state machine:
  CLOSED    → código passa no linter → continua pipeline
  OPEN      → código falha no linter → auto-revert via Git Checkpointer
  HALF-OPEN → após revert, Code Implementer recebe diff de violações

O auto-revert é o diferencial arquitetural: em vez de propagar código problemático downstream, onde seria mais caro detectar o erro, o gate interrompe imediatamente e restaura o último estado válido. Isso implementa o princípio de fail-fast com estado consistente.

6.2 Self Refine Loop: Iterative Self-Improvement com Critique-then-Improve

O padrão Self-Refinement opera em dois passos distintos:

critique_prompt = f"""
  Given this output: {artifact}
  Against these criteria: {definition_of_done}
  List specific, actionable deficiencies.
"""

refine_prompt = f"""
  Given this critique: {critique}
  Improve the output addressing each deficiency.
"""

A separação entre crítica e refinamento é fundamental. O modelo em modo crítico possui um objetivo diferente do modelo em modo geração, o que aumenta a probabilidade de identificar falhas que o gerador não detectaria sozinho.

7.Observabilidade: Watchers como Sidecar Pattern

7.1 Trace Tree: Distributed Tracing para Pipelines Agênticos

O Trace Tree implementa o equivalente de OpenTelemetry spans para chamadas de agente:

root_span: "Reproduce Paper X"
  ├── span: "Setup Phase" [200ms]
  │     ├── span: "Problem Classifier" [45ms]
  │     └── span: "Definition of Done" [155ms]
  ├── span: "Paper Analyzer" [1.2s]
  ├── span: "Code Implementer [attempt 1]" [3.4s] → FAILED
  ├── span: "Code Implementer [attempt 2]" [2.8s] → OK
  └── ...

Essa estrutura habilita root cause analysis de falhas em pipelines complexos e identificação precisa de gargalos de latência.

7.2 Budget Guard: Resource Governance com Hard Limits

Com $0.0036 / $2.00 utilizados no exemplo do diagrama, o Budget Guard implementa três níveis de controle:

Soft limits: alertas quando o consumo atinge determinado percentual do budget.

Hard limits: interrupção do pipeline antes de ultrapassar o teto definido.

Per-component attribution: rastreamento granular de custo por worker e por chamada ao Cognition Layer.

Isso transforma custo de inferência em uma primeira classe do sistema, não um elemento secundário de billing.

8.Análise de Trade-offs e Decisões de Design

9.Modos de Falha e Mitigações

10.Conclusão: O Sistema como Instância de Princípios de Engenharia Clássicos

A arquitetura analisada não inventa novos paradigmas. Ela aplica com rigor princípios clássicos de engenharia de sistemas ao domínio emergente de pipelines agênticos:

• Design by Contract: Definition of Done como pós-condições formais
• Circuit Breaker: Linter Gate com auto-revert
• Event Sourcing: Bi-Temporal Memory combinada com Git Checkpointer
• Sidecar Pattern: Trace Tree e Budget Guard como observabilidade transversal
• Strategy Pattern: Cognition Layer como capacidades de raciocínio intercambiáveis
• Fail-Fast: Verifier com feedback estruturado ao Code Implementer
• Separation of Concerns: Architect/Editor split e Critique/Refine split

O insight mais profundo do design é o seguinte: a confiabilidade do sistema não emerge da confiabilidade do LLM. Ela emerge da infraestrutura de verificação, persistência e rollback que o envolve. O LLM é tratado como um componente probabilístico dentro de um sistema determinístico, exatamente como se trata qualquer componente não confiável em engenharia de sistemas distribuídos.

Análise baseada no diagrama de arquitetura de sistema multi-agente para reprodução automática de papers científicos.