Estudando Arquitetura e Orquestração de Agentes: o Maior Domínio do Exame CCA

Arquitetura e Orquestração de Agentes vale 27% do exame CCA Foundations, mais do que qualquer outro domínio.

Ele abrange como você projeta sistemas onde Claude não apenas responde a uma pergunta, mas planeja, chama ferramentas, delega trabalho para outros agentes e decide quando terminou.

Este artigo aborda os padrões de orquestração que aparecem com mais frequência em cenários de exame, com ilustrações Python executáveis construídas sobre o SDK anthropic.

Resumo

Sistemas multiagente trocam simplicidade por capacidade, e o exame testa se você sabe quando essa troca vale a pena.

Um único agente bem definido com boas ferramentas supera um sistema multiagente mal decomposto quase todas as vezes.

Os padrões principais que valem a pena conhecer são pipelines sequenciais, topologias supervisor-trabalhador e fan-out paralelo com uma etapa de merge.

Todo padrão precisa de uma condição de término explícita, ou corre o risco de entrar em loop além do ponto de ser útil.

Questões de orquestração no exame geralmente se concentram em escolher a menor arquitetura que resolve o problema, não a mais sofisticada.

Receita

Cartão de receita de referência rápida - a forma mínima de um loop supervisor-trabalhador.

from anthropic import Anthropic
 
client = Anthropic()
 
def run_worker(task: str, model: str = "claude-sonnet-5") -> str:
    """Um agente trabalhador de propósito único que faz um trabalho e retorna."""
    response = client.messages.create(
        model=model,
        max_tokens=1024,
        system="Você é um agente trabalhador focado. Faça exatamente a tarefa dada. Retorne apenas o resultado.",
        messages=[{"role": "user", "content": task}],
    )
    return response.content[0].text
 
def run_supervisor(goal: str, max_steps: int = 5) -> str:
    """Um supervisor que decompõe um objetivo em tarefas de trabalhador e para na conclusão."""
    completed_work = []
    for step in range(max_steps):
        plan_prompt = f"Objetivo: {goal}\nConcluído até agora: {completed_work}\nPróxima subtarefa única, ou DONE se concluído:"
        plan = run_worker(plan_prompt, model="claude-sonnet-5")
        if plan.strip().upper().startswith("DONE"):
            break
        result = run_worker(plan)
        completed_work.append({"task": plan, "result": result})
    return "\n".join(w["result"] for w in completed_work)

Quando usar isso:

• O objetivo se decompõe naturalmente em um número pequeno e limitado de subtarefas independentes.
• Cada subtarefa se beneficia de um prompt de sistema mais restrito do que o objetivo geral exigiria.
• Você precisa de uma condição de parada explícita em vez de uma conversa aberta.
• Você está disposto a arcar com a latência e o custo de múltiplas chamadas de modelo para um melhor isolamento de tarefas.

Exemplo de Trabalho

from anthropic import Anthropic
from dataclasses import dataclass
 
client = Anthropic()
 
@dataclass
class AgentResult:
    agent_name: str
    output: str
 
def draft_agent(topic: str) -> AgentResult:
    response = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=512,
        system="Você elabora um breve esboço técnico. Retorne apenas o esboço, sem preâmbulo.",
        messages=[{"role": "user", "content": f"Esboço: {topic}"}],
    )
    return AgentResult("draft", response.content[0].text)
 
def critic_agent(draft: str) -> AgentResult:
    response = client.messages.create(
        model="claude-opus-4-8",
        max_tokens=512,
        system="Você critica um esboço técnico em busca de lacunas e riscos factuais. Seja conciso. Retorne apenas a crítica.",
        messages=[{"role": "user", "content": draft}],
    )
    return AgentResult("critic", response.content[0].text)
 
def reviser_agent(draft: str, critique: str) -> AgentResult:
    response = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=768,
        system="Você revisa um esboço de rascunho dada uma crítica. Retorne apenas o esboço revisado.",
        messages=[{"role": "user", "content": f"Rascunho:\n{draft}\n\nCrítica:\n{critique}"}],
    )
    return AgentResult("reviser", response.content[0].text)
 
def orchestrate_draft_critique_revise(topic: str) -> str:
    """Um pipeline sequencial de três agentes: rascunho -> crítico -> revisor.
 
    Cada agente tem um trabalho e um prompt de sistema restrito, que é o
    padrão que o exame chama de 'design de agente de responsabilidade única'.
    """
    draft = draft_agent(topic)
    critique = critic_agent(draft.output)
    final = reviser_agent(draft.output, critique.output)
    return final.output
 
if __name__ == "__main__":
    result = orchestrate_draft_critique_revise("Estratégia de migração de banco de dados sem tempo de inatividade")
    print(result)

O que isso demonstra:

• Um pipeline sequencial onde a saída de cada agente se torna a entrada do próximo agente, sem estado mutável compartilhado.
• Mistura deliberada de modelos: um modelo mais forte (Opus 4.8) para a etapa de crítica, onde a qualidade do julgamento é mais importante, e um modelo mais rápido (Sonnet 5) para rascunho e revisão.
• Prompts de sistema de responsabilidade única por agente, que o exame testa como um princípio de design distinto da engenharia de prompt em si.
• Nenhuma lógica de loop ou término necessária aqui, porque o pipeline tem um comprimento fixo e conhecido, que é em si uma escolha de design que vale a pena reconhecer.

Mergulho Profundo

Como Funciona

• Um pipeline sequencial passa a saída para frente através de uma cadeia fixa de agentes; é a forma correta quando o número de etapas é conhecido com antecedência.
• Uma topologia supervisor-trabalhador tem um agente que planeja e despacha, e um ou mais agentes trabalhadores que executam; é a forma correta quando o número de etapas não é conhecido até o tempo de execução.
• Um fan-out paralelo despacha subtarefas idênticas ou relacionadas para vários agentes simultaneamente, e depois mescla os resultados; é a forma correta quando as subtarefas são independentes e a latência é mais importante que o sequenciamento.
• Toda orquestração não trivial precisa de uma condição de término explícita: um orçamento de etapas, um sinal "DONE" que o supervisor pode emitir, ou uma verificação de validação que confirma que o objetivo foi atingido.
• A passagem de contexto entre agentes é uma decisão de design, não um dado adquirido: passe apenas o que o próximo agente precisa, não todo o histórico da conversa, ou você infla o custo de token de cada chamada downstream.

Padrões de Orquestração em Resumo

Término e Segurança de Loop

MAX_STEPS = 8
 
def safe_supervisor_loop(goal: str) -> str:
    step = 0
    history = []
    while step < MAX_STEPS:
        step += 1
        next_action = run_worker(f"Objetivo: {goal}\nHistórico: {history}\nPróxima etapa ou DONE:")
        if "DONE" in next_action.upper():
            break
        history.append(next_action)
    else:
        # Loop esgotou MAX_STEPS sem um sinal DONE - trate como uma falha, não um sucesso.
        raise RuntimeError(f"Supervisor não terminou dentro de {MAX_STEPS} etapas para o objetivo: {goal}")
    return "\n".join(history)

Um orçamento de etapas fixo combinado com um caminho de falha explícito (em vez de retornar silenciosamente um resultado parcial) é o padrão que o exame recompensa: um agente que não pode dizer que falhou é pior do que um que levanta um erro.

Notas Python

# Prefira dataclasses tipadas ou TypedDicts para cargas úteis inter-agentes em vez de dicts brutos,
# para que uma incompatibilidade de esquema entre agentes falhe rapidamente em vez de surgir como um
# bug confuso de formatação de prompt downstream.
from typing import TypedDict
 
class SubtaskResult(TypedDict):
    agent: str
    task: str
    output: str

Armadilhas

• Adicionar um segundo agente quando uma ferramenta maior faria o trabalho. Um único agente com uma ferramenta bem projetada frequentemente substitui um "agente auxiliar" inteiro. Correção: tente expandir a superfície da ferramenta antes de recorrer à orquestração.
• Nenhuma condição de término em um loop de supervisor. Deixado sem limites, um loop de planejamento pode rodar até esgotar o orçamento ou o contexto. Correção: sempre defina um limite máximo de etapas e trate excedê-lo como um erro levantado, não truncamento silencioso.
• Passar o histórico completo da conversa para cada trabalhador. Isso multiplica o custo de tokens linearmente com a profundidade do pipeline sem benefício. Correção: passe apenas os campos específicos que o próximo agente realmente precisa.
• Usar o mesmo modelo e prompt de sistema para cada agente no pipeline. Isso desperdiça a chance de igualar a força do modelo à dificuldade da tarefa. Correção: reserve um modelo mais forte para etapas de julgamento pesado, como crítica ou síntese.
• Tratar fan-out paralelo como gratuito. Chamadas concorrentes ainda consomem limites de taxa e custam o mesmo preço por chamada; fan-out reduz a latência, não o custo. Correção: dimensionar o fan-out para a contagem real de subtarefas independentes, não por si só.
• Nenhuma estratégia de merge definida antes do início do fan-out. Se você não sabe como reconciliar saídas conflitantes de trabalhadores, improvisará mal sob pressão. Correção: projete o merge (por exemplo, "supervisor arbitra", "voto majoritário", "concatenar") antes de despachar.

Alternativas

FAQs

Relacionados

• O que o Exame Claude Certified Architect Realmente Testa - o modelo mental geral do exame em que este domínio se encaixa.
• Domínios do Exame CCA Foundations em Resumo - onde este domínio de 27% se situa em relação aos outros quatro.
• Design de Ferramentas, Integração MCP e Gerenciamento de Contexto: Checklist do Domínio CCA - as decisões de design de ferramentas que frequentemente determinam se a orquestração é mesmo necessária.
• Estudo de Caso: Construindo um Agente de Suporte ao Cliente de Produção de Ponta a Ponta - esses padrões de orquestração aplicados a uma construção de produção completa.
• Melhores Práticas do Exame CCA Foundations - orientação prática para aplicar padrões de orquestração a construções reais.

Versões da Stack: Escrito contra a linha de modelos Claude atual em ~junho de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (o padrão) e Claude Haiku 4.5 - e o SDK oficial anthropic para Python (última versão 0.x). Nomes de modelos, preços, formato do exame e versões do SDK mudam rapidamente - verifique os detalhes atuais em platform.claude.com/docs e o guia oficial do exame CCA antes de confiar neles.