MÓDULO 4.1 · Trilha 4 · Avançado & cross-ambiente

🛰️ Arquitetura multiagente em escala

Sair de "um subagente" para uma frota não é só pedir mais. É montar um sistema que busca até secar, refuta o que achou, olha por lentes diferentes e nunca corta nada em silêncio — para então sintetizar uma resposta em que você pode confiar.

7
Tópicos
~35
Minutos
Avançado
Nível
Arquitetura
Tipo

Até aqui você delegou tarefas isoladas. Agora imagine um pedido grande de verdade: "levante tudo o que existe sobre o tema X, confirme o que é mesmo verdade e me entregue um relatório fechado". Um único subagente não dá conta — e pior, se ele parar cedo demais ou acreditar no primeiro resultado, você recebe uma resposta bonita e errada. A arquitetura em escala resolve isso com três estágios encadeados: uma frota que busca até secar (find), um tribunal que refuta cada achado (verify) e um sintetizador que junta só o que sobreviveu (synthesize). Grave esse pipeline — ele é o esqueleto do módulo inteiro.

1 · FIND 2 · VERIFY 3 · SYNTHESIZE buscador buscador buscador buscador … repete até secar (K rodadas vazias) cético cético cético maioria refuta → descarta voto maioria sobreviventes Sintetizador relatório final, citado um critic de completude pergunta "o que ainda falta?" · tudo que foi cortado vai pro log (sem cap silencioso)

↑ O esqueleto do harness: find em laço → verify adversarial por maioria → synthesize só dos sobreviventes.

Conteúdo detalhado

1

🚢 A frota: de um subagente a muitos

Uma frota é um conjunto de subagentes do mesmo tipo trabalhando o mesmo problema ao mesmo tempo — não um, não dois, mas dez, quarenta, cem, cada um numa fatia. O maestro deixa de "delegar uma tarefa" e passa a comandar uma operação: dividir o espaço de busca, despachar a frota, recolher os pedaços e seguir para o próximo estágio. A unidade de raciocínio deixa de ser o subagente e vira o sistema inteiro.

A analogia da frota de exploração

Pense num oceano a mapear. Um único navio leva meses e ainda perde regiões inteiras. Uma frota divide o mar em setores, manda um navio para cada um, e a almirante (o maestro) consolida as cartas. Nenhum navio fala com o outro — todos reportam à almirante. Se uma região vier confusa, ela manda mais navios para lá. Escala não é tamanho do navio; é quantidade e coordenação.

  • Almirante = o maestro/harness, que particiona, despacha e consolida.
  • Navios = a frota de subagentes, cada um num setor do problema.
  • Cartas = os relatórios parciais que voltam para serem unidos.
O que é:

um padrão em que muitos subagentes do mesmo papel atacam fatias do mesmo problema em paralelo, coordenados por um único orquestrador.

Por que aprender:

problemas de cobertura ampla (varrer um repositório gigante, levantar literatura, auditar centenas de arquivos) só ficam tratáveis quando você pensa em frota, não em "um agente esforçado".

Conceitos-chave:

particionamento · paralelismo de larga escala · orquestrador como hub · o sistema como unidade de raciocínio.

🧭
Particiona
divide o espaço
🚀
Despacha
frota paralela
📥
Recolhe
relatórios parciais
🧩
Consolida
um resultado
2

🔁 Loop-until-dry: repetir até secar

O maior erro de uma busca em escala é parar cedo demais. Um subagente acha cinco coisas, acha que "deu", e devolve — mas existiam quinze. A correção é o loop-until-dry: rode a frota em rodadas, e só pare quando K rodadas seguidas voltarem vazias (nada de novo). "Seco" não é "uma rodada sem novidade"; é K rodadas sem novidade — um amortecedor contra parar no primeiro respiro.

1

Rodada: despacha a frota

Cada subagente busca na sua fatia.

A rodada produz um lote de achados novos. Tudo que já apareceu antes é deduplicado contra o acumulado.

2

Mede o "ganho" da rodada

Quantos achados inéditos entraram?

Se entrou achado novo, o contador de rodadas-vazias volta a zero e abre nova rodada. A busca ainda está "molhada".

3

Rodada vazia → conta para K

Nada novo nesta rodada.

Incrementa o contador. Só quando ele chega a K (ex.: 2 ou 3 vazias seguidas) a busca é declarada seca e o estágio termina.

💡 Por que K e não 1

Uma rodada vazia pode ser azar (a frota foi olhar nos cantos errados naquela vez). Exigir K vazias seguidas evita declarar vitória cedo demais. Em troca, defina um teto de rodadas (ex.: máximo 8) para o loop não correr para sempre num caso patológico.

O que é: um critério de parada por exaustão: repetir a busca até K rodadas seguidas não trazerem nada novo.
Por que aprender: é o antídoto contra cobertura rasa — o sistema só descansa quando provou que ficou sem mais o que achar.
Conceitos-chave: rodada · ganho inédito · contador de vazias · limiar K · teto de segurança.
3

⚖️ Verificação adversarial: N céticos refutam

Achar não é confirmar. Cada achado da frota entra num tribunal: você dispara N subagentes céticos, e a tarefa de cada um não é concordar — é tentar derrubar a afirmação ("ache uma evidência de que isto está errado"). Se a maioria conseguir refutar, o achado morre. Sobrevive só o que aguentou o ataque. É o oposto de pedir confirmação — pedir confirmação só reforça o viés.

achado "X é verdade" cético 1 cético 2 cético 3 cético 4 refuta ✗ refuta ✗ refuta ✗ mantém ✓ 3 de 4 refutam → maioria veredito: descarta o achado

✓ Verificação adversarial (faça)

  • Instruir o cético a procurar o erro, não a confirmar
  • Usar N céticos independentes e decidir por maioria
  • Exigir que cada refutação aponte evidência, não opinião
  • Deixar passar só o que sobreviveu ao ataque

✗ Verificação ingênua (evite)

  • Perguntar "isto está certo?" (puxa concordância)
  • Um único verificador (vira ponto único de viés)
  • O mesmo agente que achou ser quem valida
  • Aceitar tudo que "parece plausível"
O que é: um filtro de qualidade onde vários céticos tentam derrubar cada achado e a maioria decide se ele morre.
Por que aprender: é o que separa "uma busca confiante" de "uma resposta confiável" — refutar é mais honesto que confirmar.
Conceitos-chave: ônus da refutação · independência · voto de maioria · evidência sobre opinião.
4

🔭 Perspectivas diversas: lentes diferentes

Uma frota de subagentes idênticos comete os mesmos erros em coro — todos olham para o mesmo lugar e ignoram o mesmo ponto cego. A correção é dar a cada subagente uma lente diferente: o mesmo material, papéis distintos. Um caça contradições, outro caça o que está faltando, outro lê pela ótica de custo, outro pela de segurança. Diversidade de lente = diversidade de erro encontrado. É a mesma ideia das 5 personas da Trilha 1, agora como peça de arquitetura.

🧱

Lente da contradição

"Onde dois achados se contradizem? Qual deles tem que estar errado?"

🕳️

Lente da lacuna

"O que deveria existir e não apareceu? Que pergunta ninguém fez?"

💸

Lente do custo

"Quanto isto custa na prática? O que muda quando o orçamento aperta?"

🛡️

Lente do risco

"Onde isto quebra? Qual o pior caso? O que um adversário exploraria?"

📏

Lente da escala

"Funciona com 10? E com 10 milhões? Onde a abordagem deixa de servir?"

🌈

Soma das lentes

Cada lente acha um defeito que as outras não veem. Juntas, cobrem o que uma frota uniforme deixaria escapar.

📊 Diversidade > quantidade

Dez subagentes com a mesma lente acham, na prática, quase o que um acharia — só mais rápido. Cinco com lentes diferentes acham coisas que nenhum dos dez veria. Ao escalar, varie a lente antes de aumentar o número.

O que é: atribuir papéis/óticas distintas a subagentes que olham o mesmo material.
Por que aprender: elimina o ponto cego coletivo de uma frota homogênea — cada lente cobre uma falha das outras.
Conceitos-chave: lente/persona · ponto cego coletivo · diversidade antes de quantidade · cobertura complementar.
5

🧮 Completeness critic: o que ainda falta?

Loop-until-dry te diz quando a frota parou de achar. Mas "parou de achar" não é "achou tudo o que importa" — pode ter ficado um buraco inteiro inexplorado. Entra o completeness critic: um subagente cuja única missão é olhar o conjunto reunido e perguntar "o que ainda falta?". Ele não busca; ele aponta os buracos. Cada buraco que ele aponta vira uma nova rodada de busca direcionada — fechando o ciclo entre verificar e buscar de novo.

saída do completeness-critic lacunas → novas buscas
# Pergunta única do crítico: "o que ainda falta?"

COBERTO    ✓ definição do conceito
COBERTO    ✓ 3 casos de uso confirmados
COBERTO    ✓ limites conhecidos

LACUNA     ✗ nenhuma fonte sobre custo em produção
LACUNA     ✗ nada sobre o que muda fora do Claude Code
LACUNA     ✗ zero contra-exemplos (só casos de sucesso)

# → o harness abre 3 buscas direcionadas para
#   fechar exatamente estas lacunas e roda de novo.

💡 Buscar é diferente de criticar

Quem busca tende a parar satisfeito com o que achou. Por isso o crítico de completude é um subagente separado, com contexto fresco — ele chega sem o apego do buscador a "já achei bastante" e enxerga o vazio que o buscador normaliza. É o mesmo princípio do revisor imparcial, aplicado à cobertura.

O que é: um avaliador dedicado que mapeia lacunas no conjunto reunido em vez de buscar mais.
Por que aprender: "parou de achar" não é "está completo"; o crítico converte buracos em buscas direcionadas.
Conceitos-chave: cobertura × exaustão · lacuna como tarefa · contexto fresco · realimentação para o find.
6

📋 Sem cap silencioso: logar o que cortou

Todo sistema em escala tem limites — de tokens, de tempo, de número de itens. O problema não é cortar; é cortar em silêncio. Se a frota achou 500 itens e o sistema só processa 50 sem avisar, você recebe um relatório que parece completo e não é — e nunca vai saber. A regra de ouro: nenhum corte silencioso. Cortou? Loga: o que foi cortado, quanto, e por qual critério. O usuário precisa ver a borda do mapa.

✓ Corte honesto

  • "Processei 50 de 500 achados (top por relevância)"
  • Registra o critério do corte (relevância, data, escopo)
  • Guarda o que sobrou para uma rodada futura
  • Deixa o usuário decidir se quer ir além do teto

✗ Cap silencioso

  • Trunca em 50 e não avisa que havia mais
  • Relatório parece completo, mas é uma fatia
  • Descarta os outros 450 sem deixar rastro
  • Decisão de cobertura tomada por você sem você

⚠️ O erro mais perigoso da escala

É o único erro desta lista que não dá sinal. Uma busca rasa você percebe; um achado falso o tribunal mata; mas um cap silencioso entrega um relatório plausível e incompleto que ninguém questiona. Por isso a regra é dura: se cortou, apareça no log — sempre, mesmo quando o corte parece óbvio.

O que é: a disciplina de tornar todo truncamento visível — registrar o que, o quanto e o porquê do corte.
Por que aprender: cortes invisíveis produzem respostas falsamente completas; o log devolve a decisão de cobertura ao usuário.
Conceitos-chave: truncamento explícito · critério do corte · rastro auditável · "borda do mapa" visível.
7

🧬 Sintetizar: o relatório que fecha o pipeline

No fim, alguém tem que juntar tudo — mas juntar não é colar. O sintetizador recebe só os achados que sobreviveram ao tribunal, depois das lacunas fechadas, com o log de cortes em mãos, e produz uma narrativa coesa: dedup, agrupa por tema, resolve conflitos restantes, cita a origem de cada afirmação e declara o que ficou de fora. O relatório final é a única coisa que volta para você — limpo, como manda o modelo do subagente.

relatorio-final.md (forma sintetizada) só sobreviventes + log
# Síntese: <pergunta original>

## Conclusões (sobreviveram ao tribunal)
- <afirmação A>  [fonte: f1, f7 · 4/4 céticos mantiveram]
- <afirmação B>  [fonte: f3 · 3/4 mantiveram]

## Conflitos resolvidos
- A vs. C → C caiu (refutado por evidência em f9)

## O que ficou de fora (sem cap silencioso)
- 500 achados → 38 processados (top por relevância)
- lacuna ainda aberta: custo em produção (0 fontes)

## Confiança
- alta nos itens 4/4; média nos 3/4; baixa onde há 1 fonte

📊 Síntese carrega o rastro

Um bom relatório não esconde o processo: cada conclusão traz quantos céticos a mantiveram e de onde veio, e há uma seção honesta de "o que ficou de fora". É isso que transforma uma pilha de achados num documento em que dá para confiar — e auditar.

O que é: o estágio que funde os achados sobreviventes num relatório citado, com conflitos resolvidos e cortes declarados.
Por que aprender: é o ponto onde escala vira entrega — sem síntese, você só tem uma pilha de pedaços.
Conceitos-chave: dedup + agrupamento · citação de origem · resolução de conflito · grau de confiança · relatório limpo.
📄

Exemplo: o esqueleto de um harness

Um harness é o código (ou a skill) que orquestra a frota — o "almirante" feito programa. Você não precisa escrever isto em nenhuma linguagem específica agora; o que importa é reconhecer a forma. Abaixo, o esqueleto em pseudocódigo: os sete tópicos deste módulo aparecem como passos de uma função. Leia como uma receita, não como código pronto.

harness.pseudo — orquestração da frota pseudocódigo (ilustrativo)
função pesquisar_em_escala(pergunta, K=2, max_rodadas=8, N_ceticos=4):
    achados        = conjunto()      # dedup automático
    rodadas_vazias = 0
    log_cortes     = []

    # ── 1+2 · FIND em loop-until-dry ──────────────────────
    enquanto rodadas_vazias < K e rodada < max_rodadas:
        fatias = particionar(pergunta, achados)        # tópico 1: frota
        novos  = frota_paralela(BUSCADOR, fatias)      # cada um, uma lente (tópico 4)
        ineditos = novos - achados
        se ineditos vazio: rodadas_vazias += 1
        senão:           rodadas_vazias = 0; achados |= ineditos

    # ── 3 · VERIFY adversarial (mata por maioria) ─────────
    para cada a em achados:
        votos = frota_paralela(CETICO, repetir(a, N_ceticos))  # "ache o erro"
        se maioria(votos) == "refuta": achados.remove(a)

    # ── 5 · COMPLETENESS critic → realimenta o find ───────
    lacunas = subagente(CRITICO_COMPLETUDE, achados)    # "o que falta?"
    se lacunas: retornar pesquisar_em_escala(focar(pergunta, lacunas), K, ...)

    # ── 6 · SEM CAP SILENCIOSO ────────────────────────────
    se tamanho(achados) > TETO:
        log_cortes.append(f"processados {{TETO}} de {{tamanho(achados)}} (top relevância)")
        achados = top(achados, TETO)

    # ── 7 · SYNTHESIZE (única saída p/ o maestro) ─────────
    retornar subagente(SINTETIZADOR, achados, log_cortes)  # relatório citado

🧠 O que o harness garante

  • Profundidade — o loop só sai quando seca (K vazias).
  • Confiabilidade — todo achado passa pelo tribunal.
  • Completude — o crítico realimenta o find com as lacunas.
  • Honestidade — todo corte vira linha de log.

⚙️ Os parâmetros que você ajusta

  • K — quantas rodadas vazias até declarar seco.
  • max_rodadas — teto para o loop não correr para sempre.
  • N_céticos — quantos refutam cada achado.
  • TETO — limite explícito, sempre logado quando atingido.
⌨️

Prompts prontos (copie e cole)

Três prompts para impor a doutrina deste módulo a uma frota — mesmo sem escrever um harness. Repare no padrão: peça exaustão, peça refutação e proíba o corte silencioso.

Prompt 1 — buscar até secar loop-until-dry
Dispare uma frota de subagentes para levantar TUDO sobre
<tema>. Rode em rodadas e só pare quando 2 rodadas
seguidas não trouxerem nada novo. No fim, diga quantas
rodadas rodou e por que considerou a busca esgotada.
Prompt 2 — verificar adversarialmente N céticos, maioria
Para cada achado, abra 4 subagentes céticos cuja missão
é TENTAR REFUTÁ-LO com evidência (não confirmar). Se a
maioria refutar, descarte o achado. Me entregue só os
que sobreviveram, com a contagem de votos de cada um.
Prompt 3 — sintetizar sem cortar em silêncio completeness + log
Antes de fechar, rode um crítico que liste o que ainda
falta e abra buscas para as lacunas. Depois sintetize um
relatório citado. Se você cortar QUALQUER coisa por
limite, registre o que cortou, quanto e por qual critério.
🖥️

Tela simulada: o harness rodando uma frota

É assim que a operação aparece no terminal: o harness está na rodada 3 do find, com uma frota de buscadores e céticos em paralelo. Note o contador de rodadas vazias (1/2 — ainda não secou), os céticos derrubando achados e, na base, a linha de log do corte — visível, nunca silenciosa.

claude code · harness:pesquisa-em-escala · rodada 3 ⏱ 02:17
━━ FIND · frota de buscadores ━━━━━━━━━━━━━━━━━━━━━━━
● buscador · docsHaiku
+12 inéditos
● buscador · códigoHaiku
+3 inéditos
● buscador · webHaiku
+0 inéditos
rodadas vazias: 1/2 · ainda não secou → abre rodada 4
━━ VERIFY · tribunal adversarial ━━━━━━━━━━━━━━━━━━━
● 4 céticos · achado #18Sonnet
3/4 refuta ✗
● 4 céticos · achado #22Sonnet
4/4 mantém ✓
⚠ log: 214 achados → 50 processados (top por relevância) · 164 guardados
maestro · Opus
seu contexto
9%

↑ Recriação ilustrativa do terminal (não é screenshot real). A frota queima contexto nas janelas dela; a sua mal se move — e o corte de 214→50 está no log, à vista.

🎯

Exercício: desenhe um loop-until-dry

Escolha um problema real de cobertura ampla (ex.: "encontrar todos os lugares do meu código que tocam pagamentos" ou "levantar tudo o que sei sobre o concorrente X") e desenhe no papel o harness que o resolveria com a doutrina deste módulo. Não precisa rodar nada — o entregável é o desenho do laço e suas regras.

Como fazer

  1. Defina como particionar o problema entre a frota (por pasta? por fonte? por subtema?).
  2. Escolha o K (quantas rodadas vazias até secar) e um teto de rodadas.
  3. Escreva a regra de verificação adversarial: quantos céticos, e como a maioria decide.
  4. Defina o completeness critic: que pergunta ele faz e o que vira nova busca.
  5. Diga onde está o teto de corte e exatamente o que você vai logar quando cortar.

✅ Critério de verificação — como saber que acertou

Seu desenho está correto se um leitor consegue responder, só olhando para ele, às cinco perguntas:

  • Quando para? A condição de parada é "K rodadas vazias", não "uma rodada" nem "deu tempo".
  • Como confia? Há refutação por maioria, não "perguntar se está certo".
  • Como sabe que está completo? Existe um crítico de lacunas que realimenta a busca.
  • O que foi cortado? Há um ponto explícito de log — nenhum corte é silencioso.
  • O que volta? Uma síntese citada, não a pilha bruta de achados.

Se faltar qualquer um dos cinco, o desenho ainda não é uma arquitetura em escala — é só "vários subagentes soltos".

Exemplo resolvido (resumido)

Problema: achar tudo que toca pagamentos no repo. Partição: uma fatia por diretório de topo. K=2, teto 6 rodadas. Verify: 3 céticos por achado, maioria refuta → fora. Crítico: "que fluxo de pagamento não aparece em nenhum achado?" → vira busca dirigida. Corte: teto 80 trechos; se passar, log "processados 80 de N". Saída: lista citada por arquivo + seção "não coberto".

Resumo do módulo

Frota — muitos subagentes do mesmo papel em fatias do problema; o sistema é a unidade de raciocínio.
Loop-until-dry — repete até K rodadas seguidas voltarem vazias; "seco", não "uma rodada".
Verificação adversarial — N céticos tentam refutar; se a maioria derruba, o achado morre.
Perspectivas diversas — lentes diferentes cobrem o ponto cego de uma frota uniforme.
Completeness critic — pergunta "o que falta?" e converte lacunas em novas buscas.
Sem cap silencioso — todo corte vira log: o quê, quanto, por qual critério.
Sintetizar — junta só os sobreviventes num relatório citado, com conflitos resolvidos e cortes declarados.

Próximo módulo:

4.2 — Subagentes no Codex e outros ambientes. O mesmo conceito fora do Claude Code: equivalências, cross-runtime e o que muda.