Phase 16 - Lesson 08

Especialização de Papéis — Planejador, Crítico, Executor, Verificador

A decomposição multiagente mais comum em 2026: um agente planeja, um executa, um critica ou verifica. O MetaGPT (arXiv:2308.00352) formaliza isso como SOPs codificados em prompts de papel — Gerente de Produto, Arquiteto, Gerente de Projeto, Engenheiro, Engenheiro de QA — seguindo Code = SOP(Team). O ChatDev (arXiv:2307.07924) encadeia designer, programador, revisor, testador por meio de uma "cadeia de conversa" com "desalucinação comunicativa" (os agentes solicitam explicitamente detalhes ausentes). O verificador é essencial: Cemri et al. (MAST, arXiv:2503.13657) mostram que cada falha multiagente pode ser rastreada até uma verificação ausente ou com erro. A PwC relatou um ganho de precisão de 7× (10% → 70%) com loops de validação estruturados no CrewAI.

Tipo: Aprender + Construir Linguagens: Python (stdlib) Pré-requisitos: Fase 16 · 04 (Modelo Primitivo), Fase 16 · 05 (Supervisor) Tempo: ~60 minutos

Problema

Sistemas multiagentes genéricos produzem saídas genéricas. Três programadores em um chat em grupo escrevem três variantes do mesmo código medíocre. Você pode adicionar mais agentes, adicionar mais rodadas e ainda assim não ultrapassar o limiar de qualidade.

A solução não é ter mais agentes — é ter agentes diferentes. Atribua papéis distintos. Dê ao crítico ferramentas que o planejador não possui. Dê ao verificador uma suíte de testes objetiva. Agora, o sistema tem discordância interna com correção fundamentada, e não apenas suposições paralelas.

Conceito

Os quatro papéis canônicos

Planejador. Lê o objetivo, produz uma lista de etapas ou uma especificação. Ferramentas: recuperação de conhecimento, documentação. Saída: plano estruturado.

Executor. Lê uma etapa do plano de cada vez, produz o artefato. Ferramentas: as ferramentas de trabalho reais (compilador de código, shell, cliente de API). Saída: o artefato.

Crítico. Lê a saída do executor em relação à intenção do planejador. Ferramentas: acesso somente leitura ao artefato, análise estática. Saída: aceitação/rejeição com justificativas.

Verificador. Lê o artefato e executa uma verificação determinística. Ferramentas: executor de testes, verificador de tipo, validador de esquema. Saída: aprovado/reprovado com evidências.

O crítico é subjetivo, opinativo, frequentemente baseado em LLM. O verificador é objetivo, determinístico, frequentemente baseado em código. Eles não são o mesmo papel.

O padrão SOP do MetaGPT

O MetaGPT (arXiv:2308.00352) codifica SOPs de engenharia de software como prompts de papel:

• Gerente de Produto escreve o PRD.
• Arquiteto produz o design do sistema.
• Gerente de Projeto divide as tarefas.
• Engenheiro implementa.
• Engenheiro de QA executa testes.

Cada papel possui um esquema de entrada/saída estrito. O prompt do papel define o que o papel é e o que ele deve produzir. A formulação Code = SOP(Team) — SOPs determinísticos transformam uma equipe de LLMs em um pipeline previsível.

Desalucinação comunicativa do ChatDev

O ChatDev adiciona uma etapa fundamental: quando um executor precisa de um detalhe específico que não estava no plano, ele pergunta explicitamente ao designer antes de continuar. Isso evita a falha clássica de LLMs de inventar plausivelmente o detalhe.

Implementação: o prompt do papel inclui "quando você precisar de informações específicas que não lhe foram fornecidas, pergunte ao papel relevante pelo nome antes de produzir a saída."

Por que o verificador é o mais importante

Cemri et al. (MAST) rastrearam 1642 falhas de execução multiagente. 21,3% foram lacunas de verificação — o sistema enviou uma resposta que ninguém havia verificado. Os 79% restantes frequentemente remontam a "houve uma verificação que falhou silenciosamente ou que nunca foi executada". A verificação é o papel de sustentação.

A PwC relatou (implantações do CrewAI, 2025) que a adição de um loop de validação estruturado aumentou a precisão de 10% para 70%. Um ganho de 7× a partir de um único papel.

Crítico vs Verificador

• Um crítico é um LLM que revisa um artefato quanto à qualidade. Subjetivo. Pode ser enganado por uma prosa plausível.
• Um verificador é um programa determinístico executado no artefato. Objetivo. Fornece aprovado/reprovado com evidências.

Use ambos. O crítico captura problemas de estilo/gosto que o verificador não consegue articular. O verificador captura bugs que o crítico não consegue ver porque eles só aparecem em tempo de execução.

O antipadrão

Cada papel no seu sistema é um LLM e a saída de cada papel é "parece bom para mim". Modo de falha clássico do MAST. Adicione pelo menos um verificador cujo resultado aprovado/reprovado seja decidido por código, não por um LLM.

Mapeamentos de frameworks

• CrewAI — Agent(role, goal, backstory) é a superfície clássica de especialização.
• LangGraph — os nós podem ter prompts especializados; as arestas impõem o pipeline.
• AutoGen — ConversableAgents específicos de papel com nomes de uma única palavra em um GroupChat.
• OpenAI Agents SDK — ferramentas de transferência (handoff) entre Agents especializados em papéis.

Construa

code/main.py implementa um pipeline de 4 papéis construindo uma função Python simples:

• Planejador produz uma especificação.
• Executor gera uma string de código.
• Crítico (simulado por LLM) sinaliza problemas óbvios.
• Verificador executa o código gerado em uma sandbox (exec) contra um caso de teste.

A demonstração é executada duas vezes: uma vez em que o executor produz um código correto (tanto o crítico quanto o verificador são aprovados) e outra em que o executor produz um código fora da especificação (o crítico deixa passar o bug porque ele parece plausível, mas o verificador o captura porque o teste falha).

Execute:

python3 code/main.py

Use

outputs/skill-role-designer.md recebe uma tarefa e produz a lista de papéis (3 a 5 papéis), o esquema de entrada/saída por papel e a verificação do verificador. Use isso antes de integrar os agentes a um framework.

Envie (Ship It)

Checklist:

• Pelo menos um verificador determinístico. Nunca totalmente baseado em LLM.
• Esquema explícito de E/S por papel. O planejador retorna uma especificação, não prosa; o executor lê esse esquema.
• Desalucinação comunicativa. O executor deve perguntar ao planejador quando houver falta de informações; nunca invente-as.
• Ordenação crítico/verificador. Execute o crítico primeiro (barato, captura problemas de design), depois o verificador (lento, captura bugs).
• Orçamento de loop. No máximo 2 rodadas de revisão entre crítico e executor antes de escalar para um humano.

Exercícios

1. Execute code/main.py e observe como o verificador captura o bug que o crítico deixou passar. Adicione uma verificação de análise estática (contar ocorrências de return) como um verificador adicional. O que ela captura que o teste de tempo de execução deixa passar?
2. Adicione um 5º papel: "analista de requisitos" que traduz o desejo do usuário em uma especificação pronta para o planejador. Quais solicitações de desalucinação comunicativa devem ser direcionadas a ele?
3. Leia a Seção 3 do MetaGPT ("Agents"). Liste o esquema de entrada/saída de cada um dos 5 papéis do MetaGPT.
4. Leia o diagrama de chat-chain do ChatDev (arXiv:2307.07924 Figura 3). Identifique onde a desalucinação comunicativa quebra um loop que de outra forma seria infinito.
5. O ganho de precisão de 7× da PwC veio de loops de verificação. Formule hipóteses para três tarefas em que a adição de um verificador não ajudaria — onde a verificação determinística de correção seja impossível ou proibitivamente cara.

Termos-Chave

Leituras Adicionais

• Hong et al. — MetaGPT: Meta Programming for Multi-Agent Collaboration — o artigo de referência do padrão SOP como prompt de papel
• Qian et al. — Communicative Agents for Software Development (ChatDev) — cadeia de conversa + desalucinação comunicativa
• Cemri et al. — Why Do Multi-Agent LLM Systems Fail? — taxonomia MAST; lacunas de verificação representam 21,3% das falhas
• CrewAI docs — Agent roles — superfície de especificação de papel em produção