Cinco questões reais, inéditas, no estilo da prova CCA-F para o domínio de maior peso na prova: Arquitetura Agêntica e Orquestração (27% da prova). Tente responder você mesmo antes de revelar a explicação — é assim que você realmente encontra as lacunas no seu conhecimento.
Pratique o conjunto completo filtrado por domínio na AICert Study →
Questão 1
Uma equipe limita o agentic loop a 5 iterações como condição primária de parada do agente de suporte. Após uma disputa complexa multi-ferramenta, o agente para no meio da investigação sem retornar uma resposta final. O que isso revela sobre o design?
- A. O modelo está quebrado; mudar para um modelo mais capaz.
- B. Limites de iteração foram usados como mecanismo primário de parada em vez de stop_reason. Limites devem ser uma rede de segurança, não a lógica principal.
- C. O prompt do usuário é muito longo; truncar.
- D. Aumentar o limite para 50 e o problema desaparecerá.
Ver resposta e explicação
Resposta correta: B
Limites rígidos de iteração são uma rede de segurança contra custos descontrolados ou loops infinitos, não o sinal primário de que o trabalho terminou. Usá-los como mecanismo principal faz o agente abandonar trabalho legítimo multi-passos. O sinal primário correto é stop_reason='end_turn'; limites cobrem apenas casos patológicos.
- O modelo está quebrado... está incorreto. O modelo produz blocos tool_use corretamente; o harness mata o loop cedo. Trocar de modelo não corrige uma condição de parada errada.
- O prompt do usuário é muito longo... está incorreto. O tamanho do prompt não tem relação direta com o número de iterações necessárias e não explica a terminação antecipada.
- Aumentar o limite para 50... está incorreto. Aumentar esconde o sintoma mas a falha de design permanece: o sinal primário deve ser o stop_reason do modelo, não um contador arbitrário.
Compartilhar esta questão no LinkedIn →
Questão 2
Quando uma chamada de ferramenta dentro do agentic loop retorna um tool_result, o que deve ser verdadeiro sobre esse bloco para que a próxima chamada à API seja bem-sucedida?
- A. Deve ser enviado como mensagem com role de assistente.
- B. Seu tool_use_id deve corresponder ao bloco tool_use que o modelo produziu anteriormente, e deve ser enviado em uma mensagem com role de usuário.
- C. Deve ser envolvido em um system prompt para o próximo turno.
- D. Pode usar qualquer id único e é enviado dentro da mensagem do assistente.
Ver resposta e explicação
Resposta correta: B
Tool results são retornados em mensagem com role de usuário e seu campo tool_use_id deve corresponder ao id do bloco tool_use correspondente produzido pelo assistente. Essa correlação é como o Claude sabe qual resultado pertence a qual chamada.
- Deve ser enviado como mensagem com role de assistente... está incorreto. O role de assistente é reservado para a saída do próprio modelo; tool results vêm do seu código e convencionalmente são colocados em mensagens de usuário.
- Deve ser envolvido em um system prompt... está incorreto. O system prompt é definido uma vez para a conversa; blocos tool_result pertencem ao turno da mensagem.
- Pode usar qualquer id único... está incorreto. tool_use_id deve corresponder exatamente ao id de tool_use do assistente, caso contrário a API rejeita ou o modelo não consegue correlacionar.
Compartilhar esta questão no LinkedIn →
Questão 3
O primeiro turno do agente de suporte solicita três ferramentas em paralelo (get_customer, lookup_order, check_loyalty_status). Seu loop as executa e prepara a próxima chamada à API. Como os tool_results devem ser enviados de volta?
- A. Como três mensagens de usuário separadas, um tool_result cada, em ordem cronológica de execução.
- B. Os três blocos tool_result em uma única mensagem de usuário, cada um referenciando seu tool_use_id correspondente.
- C. Apenas o primeiro resultado; os outros dois serão re-solicitados na próxima iteração.
- D. Como mensagens com role de assistente para o modelo lê-las em sequência.
Ver resposta e explicação
Resposta correta: B
Quando o assistente solicita múltiplas ferramentas em paralelo em um único turno, todos os blocos tool_result pertencem a uma única mensagem com role de usuário, cada um referenciando o tool_use_id correspondente. O modelo espera todos os resultados paralelos no próximo turno para raciocinar sobre eles em conjunto.
- Como três mensagens de usuário separadas... está incorreto. Dividir resultados paralelos em turnos quebra a estrutura request/response; a API requer todos os tool_results de um turno do assistente no turno de usuário imediatamente seguinte.
- Apenas o primeiro resultado... está incorreto. A API rejeitará a requisição porque a conversa está faltando tool_results para os outros tool_use_ids do turno anterior.
- Como mensagens com role de assistente... está incorreto. Tool results não são produzidos pelo modelo; colocá-los sob role de assistente corrompe a estrutura.
Compartilhar esta questão no LinkedIn →
Questão 4
Um agente de desenvolvedor roda em produção com agentic loop. Engenheiros observam loops infinitos ocasionais onde o modelo chama Grep repetidamente com pequenas variações. Qual é a estratégia de mitigação em camadas mais apropriada?
- A. Remover Grep de allowedTools para que não possa ser invocado.
- B. Depender apenas de stop_reason e confiar que o modelo terminará.
- C. Usar stop_reason como terminação primária, adicionar limite de turnos/iteração como rede de segurança e melhorar prompts e descrições de ferramentas para reduzir o churn.
- D. Analisar o texto do assistente a cada turno e parar quando mencionar 'sem mais correspondências'.
Ver resposta e explicação
Resposta correta: C
A arquitetura correta trata stop_reason como o sinal autoritativo de terminação mas o combina com um limite maxTurns para que comportamento patológico não consuma orçamento ilimitado. Melhorar prompts e descrições de ferramentas trata a causa raiz do churn.
- Remover Grep de allowedTools... está incorreto. Desabilitar uma ferramenta útil degrada o agente em vez de corrigir a lógica do loop.
- Depender apenas de stop_reason... está incorreto. Confiar inteiramente no modelo sem rede de segurança deixa você exposto a bugs, regressões ou prompts patológicos.
- Analisar o texto do assistente... está incorreto. Terminação baseada em NL é o antipadrão que causa comportamento não confiável.
Compartilhar esta questão no LinkedIn →
Questão 5
O loop de agente de uma equipe verifica if 'thank you' in response.text: break. Em produção, o agente termina após cumprimentar o cliente e nunca chama ferramentas. O que há de errado simultaneamente com esse design?
- A. A temperature é alta demais e o tempo de espera é curto demais.
- B. Parsing de NL é usado como sinal de parada (antipadrão), e o loop ignora stop_reason='tool_use' que significa continuar.
- C. O system prompt está faltando e o modelo não está autenticado.
- D. O array de ferramentas está vazio e max_tokens está baixo demais.
Ver resposta e explicação
Resposta correta: B
Duas falhas combinadas: (1) analisar prosa do assistente ('thank you') para determinar terminação não é confiável porque o modelo pode cumprimentar conversacionalmente antes de chamar ferramentas; (2) o loop deveria olhar para stop_reason em vez de texto. Se o primeiro turno retorna stop_reason='tool_use' mas o harness encerra porque a saudação contém 'thank you', o trabalho é abandonado antes de começar.
- A temperature é alta demais... está incorreto. Temperature não elimina frases comuns de cortesia nem muda o problema estrutural.
- O system prompt está faltando... está incorreto. Comportamento de saudação mostra que o modelo está respondendo; isso não tem relação com autenticação ou presença do system prompt.
- O array de ferramentas está vazio... está incorreto. Se as ferramentas estivessem faltando a API não retornaria tool_use; o cenário implica que existem mas o loop termina antes de executá-las.
Compartilhar esta questão no LinkedIn →
Quer mais? Nosso banco grátis tem centenas de questões de Arquitetura Agêntica. Pratique todas →