Construindo agentes de longa duração com Grok 4.7 no Amazon Bedrock

Grok 4.7 chega ao Amazon Bedrock com foco em agentes complexos

O Grok 4.7, modelo desenvolvido pela xAI, está disponível no Amazon Bedrock — plataforma da AWS que reúne Modelos de Fundação (FM — Foundation Models) de diferentes provedores em um único ponto de acesso. Segundo a xAI, o Grok 4.7 foi treinado para trabalhar por mais tempo em tarefas difíceis e para saber quando revisar o próprio raciocínio antes de responder. Essas características fazem diferença especialmente em cenários de agentes, onde o modelo precisa executar muitos passos encadeados e verificar o que encontrou ao longo do caminho.

Um agente eficaz não apenas consulta dados — ele formula uma resposta candidata, confronta essa resposta com o que aprendeu e refina até que o resultado faça sentido. O Grok 4.7 expõe um parâmetro chamado reasoning effort (nível de esforço de raciocínio), que controla o quanto o modelo delibera antes de cada resposta. Para cargas de trabalho com agentes, escolher o nível certo é uma decisão prática com impacto direto no consumo de tokens.

O que a xAI reporta sobre o Grok 4.7

De acordo com a xAI, o Grok 4.7 usa um modelo base maior do que o Grok 4.6 e passou por um ciclo mais longo de Aprendizado por Reforço (RL — Reinforcement Learning) com um conjunto de tarefas mais desafiadoras — com ênfase em problemas que levam muitas horas para serem concluídos. A empresa também reporta melhorias na capacidade do modelo de verificar o próprio trabalho e de gerenciar contextos mais longos.

Os benchmarks publicados pela xAI mostram os maiores ganhos em categorias que exigem trabalho sustentado, não apenas respostas de turno único:

• Terminal-Bench 4.0 (trabalho em terminal por várias horas): de 20,3% para 37,6%
• EEBench (engenharia elétrica): de 53,0% para 64,0%
• Harvey Legal Agent Benchmark (trabalho jurídico): de 15,8% para 19,6%
• CursorBench 4.0 (codificação de longa duração): de 40,4% para 46,3%
• HealthBench (raciocínio clínico profissional): de 48,5% para 56,7%
• AA Briefcase v1.1 (trabalho de escritório por várias horas): de 1.546 para 1.657

Fonte dos dados: xAI, Introducing Grok 4.7. Pontuações publicadas pela xAI no lançamento do modelo.

Benchmarks mostram desempenho em tarefas padronizadas. Para sua própria carga de trabalho, o próximo passo útil é medir em tarefas com o mesmo formato das suas — e é exatamente isso que a publicação original da AWS demonstra.

A xAI informa uma janela de contexto de 500 mil tokens para o Grok 4.7, com suporte a entrada de texto e imagem, e saída em texto. No Amazon Bedrock, o modelo oferece esforço de raciocínio configurável, chamada de ferramentas (tool calling) e saída estruturada.

Como acessar o Grok 4.7 no Amazon Bedrock

O Grok 4.7 opera no endpoint bedrock-runtime e é acessado por meio de um perfil de inferência cross-region. Dois perfis estão disponíveis:

• us.xai.grok-4.7: roteamento dentro da geografia dos EUA — indicado quando há requisitos de residência de dados nos EUA.
• global.xai.grok-4.7: roteamento entre Regiões AWS comerciais — indicado quando não há restrições de residência e se deseja maior capacidade disponível.

A inferência cross-region distribui as requisições entre múltiplas Regiões AWS, oferecendo maior throughput sem que você precise gerenciar capacidade região a região. As requisições referenciam um dos perfis de inferência, não um ID de modelo diretamente.

O modelo suporta a API Chat Completions e Responses compatível com OpenAI, além da API Converse do Amazon Bedrock. Na API Converse, o raciocínio é retornado como um bloco reasoningContent ao lado do bloco de texto. Em inferenceConfig, defina apenas maxTokens; parâmetros específicos do modelo, como o nível de esforço de raciocínio, devem ir em additionalModelRequestFields.

Para a lista atualizada de Regiões suportadas, camadas de serviço e preços por token, consulte o model card do Grok 4.7 no Guia do Usuário do Amazon Bedrock e a página de preços do Amazon Bedrock.

Pré-requisitos e conexão com o modelo

Para reproduzir os exemplos, você precisa de:

• Uma conta AWS com acesso ao Amazon Bedrock e acesso ao modelo Grok 4.7 habilitado.
• Python 3.9 ou superior, com os pacotes openai, boto3 e aws-bedrock-token-generator instalados.
• Credenciais AWS configuradas no ambiente.
• Sua identidade do IAM (Gerenciamento de Identidade e Acesso — Identity and Access Management) precisa de permissão bedrock:InvokeModel tanto no perfil de inferência quanto no projeto padrão da sua conta.

Para uso em produção, a AWS recomenda gerar um token de curta duração a partir das suas credenciais IAM existentes, mantendo a autenticação vinculada à sua identidade IAM sem armazenar segredos de longa duração:

from aws_bedrock_token_generator import provide_token
from openai import OpenAI

REGION = "us-west-2"
MODEL_ID = "us.xai.grok-4.7"

client = OpenAI(
    api_key=provide_token(region=REGION),
    base_url=f"https://bedrock-runtime.{REGION}.amazonaws.com/openai/v1",
    timeout=360,
    max_retries=0,  # retries are handled explicitly, see "Build in retries" below
)

Um ponto de atenção importante: tokens de raciocínio contam como tokens de saída e consomem o limite de max_completion_tokens antes que o texto da resposta seja produzido. Se o limite for atingido durante o raciocínio, a resposta retorna sem texto de resposta. Os testes descritos no artigo original usaram um limite de 32.768 tokens, o que deixou margem suficiente em todos os níveis de esforço.

O Grok 4.7 suporta quatro níveis de esforço: low, medium, high e xhigh. Como esses níveis podem mudar entre versões do modelo, vale confirmar os suportados diretamente no serviço em vez de codificá-los fixamente:

def supported_effort_levels(candidates=("none", "low", "medium", "high", "xhigh", "max")):
    supported = []
    for level in candidates:
        try:
            client.responses.create(model=MODEL_ID, input="Say OK.", reasoning={"effort": level}, max_output_tokens=2048)
            supported.append(level)
        except Exception as exc:
            if "unsupported_value" not in str(exc) and "invalid_value" not in str(exc):
                raise
    return supported

print(supported_effort_levels())
# ['low', 'medium', 'high', 'xhigh']

Desenhando tarefas que exigem raciocínio real

Muitas avaliações de agentes testam apenas diligência: ler um registro, filtrar, somar. Essas tarefas têm valor, mas para enxergar o que o esforço de raciocínio realmente contribui, a tarefa precisa exigir busca: a resposta não pode ser lida diretamente dos dados, ela precisa ser proposta e verificada. Para o experimento descrito no artigo original, foram construídas três tarefas sobre um ambiente sintético com 20 serviços e sete ferramentas disponíveis. Cada tarefa tem exatamente uma resposta correta, verificada por força bruta.

• Diagnóstico de duas falhas (two_fault_diagnosis): dois serviços falharam silenciosamente às 03:00 e outros 12 geraram alertas. O agente precisa identificar os dois que falharam. Serviços com falha não geram alertas próprios, então a resposta não está entre os serviços que alertaram. São 190 pares possíveis; apenas um explica exatamente os alertas observados.
• Agendamento de manutenção (maintenance_schedule): agendar oito serviços em quatro noites, dois por noite, respeitando dez restrições e uma regra que impede dois serviços do mesmo time de compartilhar uma noite. São 2.520 agendamentos possíveis; apenas um é válido.
• Orçamento de migração (migration_budget): escolher candidatos para migração que maximizem a redução de risco dentro de um orçamento, incluindo pré-requisitos transitivos. São 53 conjuntos viáveis; apenas um é ótimo. Selecionar pelo melhor índice individual gera um conjunto nove pontos abaixo do ótimo.

Quatro práticas mantêm uma avaliação como essa confiável:

• Declarar cada regra que o avaliador usa explicitamente no prompt.
• Provar que cada tarefa tem uma única resposta (o ambiente é pequeno o suficiente para enumerar todos os candidatos).
• Avaliar apenas a linha final obrigatória da resposta, não o texto completo.
• Rastrear erros de formato separadamente dos erros de conteúdo.

O sistema de ferramentas usa enum para restringir parâmetros aos valores válidos conhecidos. O prompt de sistema do agente é deliberadamente curto e instrui o modelo a verificar a resposta antes de entregá-la:

AGENT_SYSTEM = (
    "You are an infrastructure analyst agent. Use the tools to gather facts and never guess "
    "a value you can look up. Before answering, check your answer against every rule in the "
    "task. End with the FINAL line exactly as the task specifies."
)

Resultados: 72 execuções, 67 corretas

O experimento rodou seis execuções de cada tarefa em cada nível de esforço, totalizando 72 execuções. O agente respondeu corretamente em 67 delas.

• two_fault_diagnosis: low 5/6 | medium 6/6 | high 6/6 | xhigh 6/6
• maintenance_schedule: low 5/6 | medium 5/6 | high 5/6 | xhigh 6/6
• migration_budget: low 5/6 | medium 6/6 | high 6/6 | xhigh 6/6
• Total: low 15/18 | medium 17/18 | high 17/18 | xhigh 18/18

Em termos de consumo de tokens por execução:

• low: média de 1.184 tokens de saída, mediana de 18 segundos
• medium: média de 6.430 tokens de saída, mediana de 98 segundos
• high: média de 6.778 tokens de saída, mediana de 89 segundos
• xhigh: média de 9.147 tokens de saída, mediana de 106 segundos

Três observações relevantes se destacam. Primeiro, o nível xhigh acertou todas as 18 execuções. Segundo, o esforço muda o quanto o agente raciocina, não o quanto ele explora: as chamadas de ferramentas ficaram praticamente estáveis entre 17,2 e 18,7 por execução em todos os níveis — o que variou foi o volume de raciocínio aplicado aos dados coletados. Terceiro, o nível low oferece uma ótima relação custo-qualidade: acertou 15 de 18 execuções usando cerca de um oitavo dos tokens de saída do xhigh, com mediana de apenas 18 segundos por execução.

Monitorando o raciocínio em produção

Em produção, você não tem uma resposta conhecida para comparar, mas tem o número de tokens de saída e chamadas de ferramentas por execução. Esses dados fornecem um sinal operacional útil. Todas as execuções corretas em medium ou acima usaram pelo menos 1.739 tokens de saída. Uma execução que não faz chamadas de ferramentas ou que produz muito menos saída do que o normal para aquele nível merece revisão:

def flag_for_review(run, baseline):
    """baseline: output tokens of graded, correct runs at the same effort level."""
    reasons = []
    if run["tool_calls"] == 0:
        reasons.append("made no tool calls")
    if run["output_tokens"] < 0.2 * min(baseline):
        reasons.append(f"used {run['output_tokens']} output tokens, "
                       f"under a fifth of the lowest correct run ({min(baseline)})")
    return reasons

Calibre o baseline a partir de execuções que você já avaliou, por tarefa e por nível de esforço, e aplique às execuções futuras. Em low, onde cada execução é breve, o volume de saída é um sinal mais fraco — combine com verificações pontuais.

Como escolher o nível de esforço adequado

Os resultados sugerem algumas regras práticas. Tarefas que envolvem busca, otimização ou teste de hipóteses se beneficiam mais de medium ou acima. Tarefas que seguem um caminho único ou cujas respostas são revisadas por downstream podem rodar eficientemente em low.

Vale destacar que o esforço é um parâmetro de requisição, não de agente. Isso significa que um mesmo agente pode rodar seus passos de planejamento e verificação em nível mais alto e seus passos mecânicos — como formatar um resultado de ferramenta — em low. Essa combinação une boa parte da confiabilidade dos níveis mais altos com um custo de tokens menor.

Controles operacionais para cargas de trabalho com agentes

O artigo original da AWS também aborda boas práticas de operação. Para agentes que emitem alto volume de chamadas, retentativas devem ser parte do design: defina um timeout de requisição, faça retry apenas em erros recuperáveis, use backoff exponencial com jitter e respeite o cabeçalho Retry-After quando retornado:

import random, time

RETRYABLE = {408, 429, 500, 502, 503, 504}

def call_with_backoff(fn, attempts=7, base=4.0, cap=180.0):
    for attempt in range(1, attempts + 1):
        try:
            return fn()
        except Exception as exc:
            status = getattr(exc, "status_code", None)
            retryable = status in RETRYABLE or "timed out" in str(exc).lower()
            if not retryable or attempt == attempts:
                raise
            time.sleep(random.uniform(base, min(cap, base * 2 ** attempt)))

Outras recomendações operacionais incluem:

• Auditoria de execuções: o model invocation logging do Bedrock grava dados de requisição e resposta no Amazon S3 ou Amazon CloudWatch Logs, permitindo revisar transcrições completas depois.
• Monitoramento de volume de raciocínio em escala: métricas do Amazon CloudWatch oferecem visão agregada do uso de tokens, onde os baselines por nível de esforço podem virar alarmes.
• Atribuição de gastos por agente: o AWS Cost Explorer e o Relatório de Custo e Uso (CUR — Cost and Usage Report) detalham o uso por modelo.
• Camadas de serviço por urgência: a camada de serviço é definida por requisição, então uma análise noturna pode usar a camada Flex enquanto uma requisição interativa usa a camada Priority.
• Perfil de roteamento: o perfil Global serve a partir de qualquer Região AWS comercial e geralmente tem preço menor por token do que o roteamento geográfico. O perfil US mantém o processamento dentro dos Estados Unidos.

Limitações da medição

É importante contextualizar os resultados. Com seis execuções por tarefa e nível de esforço, as diferenças entre níveis são indicativas, não estatisticamente conclusivas. O ambiente é sintético — ferramentas lendo dados gerados em código — o que permite provar que cada tarefa tem exatamente uma resposta e avaliar automaticamente, mas não testa latência, resultados parciais ou erros de ferramentas reais. Os tempos medianos variaram de 18 segundos em low a 106 segundos em xhigh, sendo um proxy reduzido para trabalho de longa duração. Além disso, os resultados são para uma versão de modelo, uma Região e um prompt por tarefa — diferentes formulações podem alterar os números.

Os experimentos relatam contagem de tokens, não valores em moeda. Para converter em custo, aplique as taxas atuais do seu perfil de inferência e camada de serviço na página de preços do Amazon Bedrock. Os perfis Global e US Geo têm preços diferentes, e as camadas Flex e Priority aplicam multiplicadores.

Leitura complementar

• Introdução ao Grok no Amazon Bedrock
• Grok 4.7 já disponível no Amazon Bedrock
• Roteamento de inferência cross-region no Amazon Bedrock
• Primeiros passos com o Amazon Bedrock
• API Chat Completions no Amazon Bedrock
• Introducing Grok 4.7 (xAI)

Fonte

Build long-horizon agents with Grok 4.7 on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/build-long-horizon-agents-with-grok-4-7-on-amazon-bedrock/)