O que foi anunciado

A AWS anunciou que o Amazon Bedrock agora oferece suporte aos modelos OpenAI GPT-5.6 — nas variantes Terra e Luna — para clientes na Índia, com inferência entre regiões dentro da geografia indiana (India Geo cross-Region inference). Isso significa que organizações com requisitos regulatórios de processamento de dados dentro do país podem usar esses modelos em escala, com a garantia de que as inferências são executadas exclusivamente dentro da Índia.

Como funciona a inferência entre regiões na Índia

A inferência entre regiões (cross-Region inference) roteia automaticamente as requisições de inferência entre múltiplas regiões da AWS para oferecer maior capacidade de processamento, sem que o cliente precise gerenciar manualmente a capacidade em cada região.

No caso dos novos perfis de inferência da geografia indiana, as requisições trafegam apenas entre regiões dentro da Índia — especificamente Ásia-Pacífico (Mumbai) e Ásia-Pacífico (Hyderabad). Isso permite escalar conforme a demanda sem abrir mão dos requisitos de residência de dados.

Os perfis de inferência disponíveis são:

• in.openai.gpt-5.6-terra — para o modelo Terra
• in.openai.gpt-5.6-luna — para o modelo Luna

Integração com o ecossistema do Bedrock

Os modelos funcionam no endpoint bedrock-runtime e são compatíveis com as APIs Responses, Chat Completions e Converse. Além disso, operam com os mesmos controles já existentes no Bedrock para outros modelos, incluindo:

• Registro de invocações de modelos (entregável ao Amazon S3 ou Amazon CloudWatch Logs)
• Métricas via Amazon CloudWatch
• Detalhamento de custos no AWS Cost Explorer e no Relatório de Custo e Uso (AWS Cost and Usage Report)

Ou seja, quem já usa o Bedrock não precisa aprender uma nova forma de operar — a experiência é consistente com o restante da plataforma.

Disponibilidade

Os modelos OpenAI com inferência entre regiões na Índia já estão disponíveis nas regiões Ásia-Pacífico (Mumbai) e Ásia-Pacífico (Hyderabad). Para começar, a AWS recomenda revisar os cartões de modelo do GPT-5.6 (Terra e Luna) e a seção de inferência entre regiões no Guia do Usuário do Amazon Bedrock.

Fonte

Amazon Bedrock now supports OpenAI models in India (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-bedrock-openai-india-v1/)

O que mudou

A AWS anunciou uma melhoria relevante no Amazon EC2 Auto Scaling: agora é possível encerrar instâncias em lote com uma única chamada de API. Até então, cada instância precisava ser encerrada individualmente, o que tornava o processo de redução de escala mais lento e custoso em termos de chamadas de API.

Como funciona o encerramento em lote

Com a nova funcionalidade, é possível passar até 100 IDs de instâncias de uma só vez para a API TerminateInstanceInAutoScalingGroup, encerrando todas elas como um único lote. Isso reduz significativamente a quantidade de chamadas de API necessárias para escalar para baixo um grupo de Auto Scaling.

Um ponto importante de confiabilidade: todas as instâncias do lote são validadas atomicamente antes que o encerramento comece. Ou seja, a AWS verifica o conjunto inteiro antes de agir, o que traz mais previsibilidade ao processo.

Além disso, os comportamentos já existentes do Auto Scaling são preservados para cada instância do lote individualmente, incluindo:

• Lifecycle hooks — ganchos de ciclo de vida que permitem executar ações personalizadas antes do encerramento
• Connection draining do load balancer — drenagem de conexões ativas antes de remover a instância do balanceador de carga

Ou seja, a novidade não sacrifica nenhum controle operacional já existente — ela apenas torna o processo muito mais eficiente em escala.

Para quais cargas de trabalho isso é mais relevante

A AWS projetou esse recurso especialmente para workloads que precisam reduzir escala rapidamente. Os casos de uso destacados são:

• Jobs de treinamento de IA/ML que sobem frotas grandes temporariamente e precisam encerrá-las ao fim do processamento
• Orquestradores de containers que gerenciam grande quantidade de nós de forma dinâmica
• Arquiteturas orientadas a eventos que provisionam instâncias em resposta a picos e precisam desligá-las em massa logo em seguida

Para esses cenários, a diferença prática é expressiva: em vez de disparar dezenas ou centenas de chamadas de API individuais, uma única chamada resolve o trabalho.

Disponibilidade e custo

O recurso já está disponível em todas as regiões da AWS e sem custo adicional.

Para se aprofundar, a AWS disponibiliza a documentação do Amazon EC2 Auto Scaling e o guia de referência da API do Amazon EC2 Auto Scaling.

Fonte

Amazon EC2 Auto Scaling now supports batch instance termination (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-ec2-auto-scaling-batch-termination)

O que é o NVIDIA Nemotron 3.5 Lightning

A NVIDIA disponibilizou o Nemotron 3.5 Lightning no Amazon SageMaker JumpStart, tornando mais acessível o deploy de um modelo de fundação aberto voltado para cargas de trabalho agênticas de alto volume. O modelo pode ser implantado sem que o time precise configurar manualmente a infraestrutura de serving — o JumpStart cuida disso.

Segundo a NVIDIA, o Lightning é o modelo aberto mais rápido de sua categoria para alimentar agentes sempre ativos (always-on agents). A empresa reporta até 4x mais throughput e até 30% mais velocidade na conclusão de tarefas em cargas agênticas de alto volume.

O modelo conta com 30 bilhões de parâmetros totais, mas apenas 3 bilhões ativos por inferência, o que permite que ele rode em uma única GPU compatível. Isso significa que etapas repetitivas e especializadas de fluxos agênticos podem ser executadas sem precisar de infraestrutura de escala frontier.

Arquitetura e características técnicas

O Nemotron 3.5 Lightning é um modelo de fundação publicamente disponível, destilado a partir do Nemotron 3 Ultra da NVIDIA e desenvolvido em colaboração com o Nemotron Coalition. Ele usa uma arquitetura híbrida de Mistura de Especialistas (MoE — Mixture-of-Experts) e foi treinado especificamente para uso de ferramentas agênticas em frameworks populares de agentes.

Por ser treinado em datasets abertos e lançado como modelo aberto, é possível personalizá-lo, manter os pesos resultantes e implantá-lo onde os agentes rodam.

A tabela abaixo resume as principais especificações do modelo:

• Arquitetura: Híbrida MoE (Mistura de Especialistas)
• Parâmetros: 30B totais / 3B ativos
• Tamanho de contexto: Até 1 milhão de tokens
• Entrada / Saída: Texto para texto
• Decodificação especulativa: DFlash
• Throughput: Até 4x maior para cargas agênticas de alto volume
• Conclusão de tarefas: Até 30% mais rápida
• Destilado de: NVIDIA Nemotron 3 Ultra

Nem toda etapa agêntica precisa de um modelo frontier

Agentes sempre ativos trabalham de forma contínua: coletam contexto, observam o ambiente, raciocinam sobre o que sabem e agem. Muitas dessas etapas envolvem chamadas a modelos, mas nem todas exigem o mesmo nível de capacidade.

Planejar um fluxo de trabalho em múltiplos estágios ou orquestrar sub-agentes pode exigir raciocínio de nível frontier. Já classificar um alerta, extrair campos de um formulário ou verificar um registro contra uma política geralmente pode ser tratado por um modelo menor e especializado — e essas tarefas podem representar uma grande parcela do volume de chamadas.

Executar todas as etapas suportadas por modelos através de um único modelo grande pode adicionar custo e latência de modelo frontier a trabalhos que um modelo menor e especializado consegue resolver. Uma abordagem de sistema de modelos pode, em vez disso, rotear cada etapa para o modelo mais adequado à tarefa.

O Nemotron 3.5 Lightning foi construído para o extremo de alto volume desse sistema. Sua arquitetura MoE ativa 3B dos 30B parâmetros por passagem forward, ajudando a manter alto throughput em sessões longas e com múltiplos turnos. A decodificação especulativa DFlash pode reduzir ainda mais a latência por token. A janela de contexto de 1 milhão de tokens permite que um agente carregue estado acumulado ao longo de uma sessão de longa duração sem precisar de re-ancoragem repetida.

Se o NVIDIA NeMo Switchyard fizer parte do seu stack, ele pode rotear etapas individuais do fluxo de trabalho entre o pool de modelos escolhido. O Lightning pode ser selecionado para etapas especializadas de alto volume onde sua velocidade e precisão por domínio são um bom encaixe.

Precisão em benchmarks de raciocínio e agênticos

A NVIDIA reporta que os resultados de avaliação foram medidos sob um harness consistente e podem diferir dos números reportados pelos próprios fornecedores. As receitas e comandos de avaliação usados para produzir esses resultados estão publicados no NeMo Gym.

A tabela a seguir compara as variantes BF16 e NVFP4 do Nemotron 3.5 Lightning nos principais benchmarks de raciocínio e agênticos:

• MMLU Pro: BF16 → 81,94 | NVFP4 → 81,62
• GPQA Diamond: BF16 → 75,44 | NVFP4 → 75,57
• SWE-bench Verified: BF16 → 51,56 | NVFP4 → 52,80
• PinchBench: BF16 → 85,37 | NVFP4 → 83,43
• IFBench: BF16 → 71,88 | NVFP4 → 72,88
• AA-LCR: BF16 → 52,00 | NVFP4 → 49,19

De modo geral, a variante NVFP4 permanece próxima à BF16 na maioria das tarefas avaliadas.

Personalização para precisão por domínio

Organizações podem fazer pós-treinamento do modelo com o NVIDIA NeMo para ferramentas, fluxos de trabalho e políticas específicas do domínio, e depois implantar o modelo resultante no ambiente de sua escolha. Vale notar que o model card do SageMaker JumpStart para este lançamento não expõe a funcionalidade de customização nativa do JumpStart.

Casos de uso empresariais

O Lightning foi construído para o trabalho especializado e de alta frequência dentro de fluxos agênticos. A NVIDIA destaca os seguintes casos de uso:

• Agentes pessoais: Assistentes de longa duração que lidam com e-mail, calendário, projetos e reservas, com a opção de rodar localmente para dados contextuais.
• Serviços financeiros: Extração de dados de documentos, verificação de regras de política, monitoramento de sinais de risco e preparação de resumos estruturados.
• Operações de segurança cibernética: Enriquecimento de alertas, classificação de incidentes, consulta a logs, validação de controles, correlação de indicadores e preparação de achados para analistas.
• Telecomunicações: Triagem de alarmes de rede, otimização de configurações de rede e atendimento a perguntas de faturamento.
• Varejo: Enriquecimento de catálogos de produtos, resolução de exceções de inventário e fulfillment, auxílio na descoberta de produtos e atendimento a perguntas sobre pedidos, devoluções e fidelidade.

Como fazer o deploy pelo SageMaker JumpStart

O Nemotron 3.5 Lightning pode ser implantado pelo Amazon SageMaker JumpStart sem necessidade de configurar manualmente o framework de serving. Antes de começar, é necessário ter:

• Uma conta AWS ativa.
• Permissões adequadas para o SageMaker JumpStart.
• Cota de serviço suficiente para instâncias GPU (por exemplo, ml.g6e.12xlarge, ml.p4d.24xlarge ou ml.p5.48xlarge).

Atenção: O deploy deste modelo cria um endpoint no SageMaker AI que gera cobranças enquanto estiver ativo. Consulte a página de preços do Amazon SageMaker AI para mais detalhes. Exclua o endpoint ao terminar para evitar cobranças contínuas.

Deploy pelo SageMaker Studio

Para fazer o deploy pelo SageMaker Studio, abra o Amazon SageMaker Studio, acesse o SageMaker JumpStart pelo painel de navegação e busque por Nemotron 3.5 Lightning. Selecione o model card correspondente — o ID do modelo NVFP4 é huggingface-reasoning-nemotron-3-5-lightning-30b-a3b-nvfp4; para BF16, use huggingface-reasoning-nemotron-3-5-lightning-30b-a3b-bf16. Escolha Deploy, selecione o tipo de instância (por exemplo, ml.g6e.24xlarge), revise as configurações de deploy — os padrões são suficientes para a maioria dos casos de uso — e confirme o deploy para criar o endpoint. Aguarde o status do endpoint mostrar InService antes de executar inferências.

Deploy a partir do Hugging Face

Também é possível fazer o deploy do NVIDIA Nemotron 3.5 Lightning para o Amazon SageMaker AI diretamente pela página do modelo no Hugging Face. Na página do modelo, basta escolher Deploy, selecionar Amazon SageMaker AI e clicar em Deploy on SageMaker AI. Isso abre o fluxo de deploy do SageMaker AI, onde é possível configurar e implantar o modelo.

Deploy via SageMaker Python SDK

Com o SageMaker JumpStart, é possível acessar as variantes NVFP4 e BF16 via SDK. O exemplo abaixo usa o ID do modelo NVFP4. Para BF16, substitua pelo ID huggingface-reasoning-nemotron-3-5-lightning-30b-a3b-bf16:

from sagemaker.jumpstart.model import JumpStartModel

model_id = "huggingface-reasoning-nemotron-3-5-lightning-30b-a3b-nvfp4"
model_version = "*"

model = JumpStartModel(model_id=model_id, model_version=model_version)
predictor = model.deploy()

Limpeza de recursos

Para evitar cobranças desnecessárias, exclua o endpoint do SageMaker AI ao terminar:

predictor.delete_endpoint()

Conclusão

O NVIDIA Nemotron 3.5 Lightning representa uma opção relevante para equipes que trabalham com fluxos agênticos de alto volume e precisam de velocidade sem abrir mão de precisão. Sua arquitetura MoE com apenas 3B de parâmetros ativos, a decodificação especulativa DFlash e a janela de contexto de 1 milhão de tokens fazem dele um modelo pensado para o trabalho especializado e repetitivo dentro de sistemas de agentes.

Por ser um modelo aberto e customizável, as organizações mantêm controle sobre os pesos resultantes do pós-treinamento. A disponibilidade no Amazon SageMaker JumpStart simplifica o processo de deploy, eliminando a necessidade de configurar a infraestrutura de serving manualmente. Para orientações detalhadas sobre implantação, a AWS disponibiliza a documentação de uso de modelos de fundação no JumpStart no guia do desenvolvedor do SageMaker AI.

Fonte

NVIDIA Nemotron 3.5 Lightning now available in Amazon SageMaker JumpStart (https://aws.amazon.com/blogs/machine-learning/nvidia-nemotron-3-5-lightning-now-available-in-amazon-sagemaker-jumpstart/)

O que foi anunciado

A AWS anunciou uma expansão significativa no suporte do Amazon Bedrock aos modelos OpenAI. A partir desta atualização, os modelos GPT-5.6 — nas variantes Sol, Terra e Luna — passam a estar disponíveis no endpoint bedrock-runtime, com suporte às APIs Responses, Converse e Chat Completions. Além disso, a AWS introduz a Inferência entre Regiões (Cross-Region Inference) para esses modelos, trazendo mais flexibilidade operacional para quem utiliza IA generativa no Bedrock.

Como funciona a Inferência entre Regiões

A Inferência entre Regiões roteia automaticamente as requisições de inferência entre múltiplas regiões da AWS, sem que o time de engenharia precise gerenciar capacidade manualmente em cada região. O recurso é oferecido em duas modalidades:

• Geo Cross-Region Inference (Inferência Geo entre Regiões): roteia as requisições dentro de uma geografia predefinida, mantendo os dados processados naquela área geográfica. Esta modalidade inclui suporte ao novo US Geo (US CRIS), lançado junto com este anúncio.
• Global Cross-Region Inference (Inferência Global entre Regiões): roteia as requisições a partir de qualquer região comercial da AWS onde o modelo esteja disponível, oferecendo o maior acesso à capacidade do Bedrock e o maior throughput em momentos de pico de demanda. Essa modalidade também tem um custo por token menor do que a inferência regional ou Geo para os modelos OpenAI.

Expansão do suporte a APIs

Com esta atualização, os modelos GPT da OpenAI no Bedrock passam a ser compatíveis com três APIs diretamente no endpoint bedrock-runtime:

• Responses API
• Chat Completions API
• Converse API

Por rodarem nativamente no bedrock-runtime, esses modelos se beneficiam dos mesmos controles que já existem para outros modelos no Bedrock, sem necessidade de configurações adicionais.

Governança, observabilidade e custos

Um ponto relevante desta integração é que os modelos OpenAI no Bedrock passam a se comportar como qualquer outro modelo da plataforma do ponto de vista de governança e visibilidade financeira:

• O uso aparece no Bedrock model invocation logging, com entrega para o Amazon S3 ou Amazon CloudWatch Logs.
• As métricas do Amazon CloudWatch cobrem contagem de invocações, contagem de tokens, latência, throttles e erros.
• Os custos são detalhados no AWS Cost Explorer e no AWS Cost and Usage Report (CUR), permitindo atribuir gastos por modelo.

Disponibilidade

A Inferência entre Regiões para modelos OpenAI está disponível em todas as regiões da AWS onde os modelos OpenAI no Amazon Bedrock já são oferecidos. Para começar, a AWS recomenda consultar os cartões de modelo para o GPT-5.6 (Sol, Terra e Luna) no Guia do Usuário do Amazon Bedrock.

Fonte

Amazon Bedrock expands API support and introduces Cross Region Inferencing for OpenAI models (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-bedrock-cross-region-openai-v2/)

Agentes autônomos que precisam pagar por serviços

Um dos desafios práticos de agentes de IA autônomos é que, ao navegar pela web, chamar APIs ou consultar servidores MCP (Protocolo de Contexto de Modelo), eles frequentemente encontram serviços que exigem pagamento antes de liberar o acesso. O problema: pausar para aguardar aprovação humana a cada transação destrói a proposta de valor de um agente autônomo.

Para resolver isso, a AWS anunciou uma integração entre o OpenClaw e o AgentCore Payments, uma capacidade do Amazon Bedrock AgentCore. A solução permite que agentes realizem pagamentos programáticos dentro de limites previamente aprovados por um operador humano, sem expor credenciais de carteira ao runtime do modelo.

Por que agentes precisam de uma camada de pagamento

Agentes de longa duração — como os que executam pesquisas ou pipelines de trabalho automatizados — podem se deparar com APIs pagas ou endpoints de conteúdo sem que nenhum operador esteja presente. Uma camada de pagamento delimitada permite que o agente continue operando dentro de limites definidos antecipadamente: destinatário aprovado, ativo, rede, valor por pagamento, orçamento acumulado e prazo de expiração.

Muitas APIs, serviços de dados e ferramentas MCP usam precificação por uso. Transações individuais podem custar menos de um dólar ou frações de centavo. As taxas mínimas de processamento de cartão tornam transações nessa escala economicamente inviáveis, enquanto pagamentos em stablecoin suportam valores pequenos com liquidação quase em tempo real. Isso torna protocolos nativos de HTTP como o x402 adequados para pagamentos programáticos iniciados por agentes.

Implementar isso diretamente exigiria integração com provedores de carteira, proteção de credenciais, autorização de pagamentos, limites determinísticos e observabilidade. Além disso, é preciso considerar que o modelo pode ser manipulado por entradas não confiáveis. O design não previne injeção de prompt — em vez disso, ele assume que entradas não confiáveis podem manipular o modelo e limita a autoridade do runtime por destinatário, ativo, rede, valor por pagamento, orçamento da sessão e prazo de expiração.

Visão geral da solução

O AgentCore Payments oferece uma camada de pagamento consistente à medida que os protocolos de pagamento para agentes evoluem. A integração com o OpenClaw demonstra o padrão usando x402 v2: processa o desafio HTTP 402 de um comerciante por meio de um provedor de carteira configurado e retorna uma autorização assinada que o cliente usa para repetir a requisição.

Outras capacidades do Amazon Bedrock AgentCore também entram em cena:

• AgentCore Identity armazena as credenciais do provedor de carteira com segurança.
• AgentCore Observability pode fornecer logs, métricas e rastreamentos via Amazon CloudWatch e AWS X-Ray quando a entrega de telemetria está configurada.

O AgentCore Payments suporta carteira Coinbase ou carteira Stripe Privy como conexão de pagamento. Ambas fornecem uma carteira de stablecoin embutida. Sujeito à disponibilidade do provedor e geográfica, é possível financiar a carteira por stablecoin ou moeda fiduciária usando cartão de débito. Ambos os provedores usam armazenamento de credenciais do AgentCore Identity e limites de gastos por sessão.

O OpenClaw é um assistente de IA que roda nos seus dispositivos e conecta modelos, ferramentas e canais de mensagens por meio de um Gateway local. A OpenClaw Foundation mantém o projeto, e plugins estendem o que o assistente pode fazer.

O design separa claramente a administração de pagamentos (executada por humanos) do runtime voltado ao modelo. Um humano provisiona a carteira, cria a sessão de pagamento, aprova destinatários e define o orçamento em um terminal confiável. O plugin aws-agents-pay expõe apenas duas ferramentas visíveis ao modelo:

• get_payment_session_status: verifica o status da sessão de pagamento configurada.
• get_paid_content: requisita uma URL paga aprovada e conclui o pagamento dentro da política configurada.

O runtime pode iniciar um pagamento dentro da sessão aprovada, mas não pode criar, estender ou substituir uma sessão.

Fluxo típico de pagamento

Um fluxo de pagamento típico funciona assim:

• O agente chama get_payment_session_status para confirmar que a sessão provisionada pelo operador está disponível.
• O agente chama get_paid_content para uma URL aprovada.
• O plugin realiza uma sondagem de rede delimitada e recebe uma resposta HTTP 402 contendo um desafio x402 v2.
• Após receber o desafio, o plugin verifica se o recurso do desafio tem a mesma origem e caminho da URL requisitada, e valida rede, ativo, destinatário e valor contra a política do operador antes de chamar ProcessPayment.
• Para uma nova tentativa da mesma requisição de pagamento, o plugin reutiliza o mesmo token de idempotência em vez de criar um segundo pagamento.
• O plugin aguarda até o horário validAfter da autorização assinada e, então, repete a requisição original com a assinatura de pagamento.
• Com returnBody habilitado, o plugin retorna o corpo da resposta paga, com limite de 10 KiB, marcado como untrusted: true. O plugin não retorna a prova de pagamento assinada ao modelo.

Pré-requisitos

Para seguir o guia, são necessários:

• OpenClaw versão 2026.3.24 ou posterior: npm install -g openclaw
• Node.js e npm
• Uma conta AWS com acesso ao AgentCore Payments
• Funções de Gerenciamento de Identidade e Acesso (IAM) separadas para administração e runtime, seguindo o guia de funções IAM do AgentCore Payments. A função de runtime do OpenClaw precisa apenas das operações de leitura necessárias para status e ProcessPayment — não deve ter permissões de escrita de sessão.
• Credenciais Coinbase CDP ou Stripe com Privy, inseridas apenas na CLI interativa do AgentCore.
• Um endpoint x402 v2 na Base Sepolia que você controla ou aprovou de forma independente. É possível usar o Coinbase x402 Bazaar para descobrir serviços candidatos, mas verifique o endpoint, destinatário, rede, ativo e preço antes de adicioná-los à política de pagamento.

Aviso de segurança: a segurança desta solução segue o modelo de responsabilidade compartilhada da AWS. A AWS é responsável pela segurança da nuvem, enquanto você é responsável pela segurança dentro da nuvem. Suas responsabilidades incluem configurar permissões IAM, proteger credenciais do provedor de carteira e definir políticas de pagamento.

Passos de implementação

1. Instalar o plugin pelo ClawHub

Confirme que o pacote @aws/aws-agents-pay está disponível no ClawHub e instale-o:

openclaw plugins install clawhub:@aws/aws-agents-pay

O nome do pacote é @aws/aws-agents-pay, o ID do plugin instalado é aws-agents-pay e o nome da skill embutida é agents-pay. Para inspecionar o guia de configuração embutido:

openclaw skills info agents-pay

Para inspecionar o plugin instalado:

openclaw plugins inspect aws-agents-pay

O runtime visível ao modelo deve expor apenas get_payment_session_status e get_paid_content. Se aparecer qualquer outra ferramenta de configuração, criação de sessão, shell ou outro tipo visível ao modelo, pare — isso pode indicar um pacote diferente, desatualizado ou modificado.

2. Configuração supervisionada por humano

Instalar o plugin não cria o gerenciador de pagamentos, conector, instrumento ou sessão de pagamento. Existem duas opções de provisionamento:

• Opção A – Configuração assistida pelo OpenClaw: peça ao OpenClaw: “Help me set up the agents-pay skill.” O OpenClaw pode explicar cada etapa, mas você deve executar os comandos administrativos e aprovar a criação da sessão por conta própria.
• Opção B – Configuração totalmente manual: siga o guia de configuração do OpenClaw diretamente, sem envolver o OpenClaw.

Em qualquer caso, siga o guia de configuração do OpenClaw em um terminal confiável supervisionado por humano. O guia cobre a criação do projeto AgentCore, provisionamento de recursos de pagamento, execução do assistente de configuração e adição da configuração gerada ao OpenClaw. Você deve inserir credenciais e digitar approve manualmente.

3. Configurar o plugin com uma política explícita

Revise a configuração gerada antes de habilitar o plugin. Ela deve incluir o ARN do gerenciador de pagamentos, ID do instrumento, ID da sessão, ID do usuário, rede, contrato exato do ativo, destinatários aprovados e um teto positivo por pagamento.

Para o walkthrough em sandbox, use a política de pagamento no Passo 3 do código de exemplo. Ela contém a rede Base Sepolia, origem, destinatário, ativo USDC, limite de pagamento e configuração de returnBody compatíveis com o endpoint de teste.

Para um conjunto fixo de comerciantes, verifique cada endereço em allowedRecipients fora de banda usando documentação do comerciante ou outra fonte confiável — não aprove um destinatário apenas porque ele apareceu em uma resposta HTTP 402. Para cenários de descoberta mais amplos, defina allowAnyRecipient: true para permitir que o publicador selecione o beneficiário; os controles de origem, rede, ativo, valor por pagamento e orçamento da sessão ainda se aplicam.

maxPaymentAmountAtomic limita um pagamento na menor unidade do ativo. Para um ativo USDC de seis decimais, 100000 representa 0,10 USDC. O orçamento da sessão de pagamento limita separadamente o gasto acumulado até a sessão expirar ou ser esgotada.

Segredos do provedor de carteira não pertencem à configuração do OpenClaw. Trate o ID da sessão de pagamento, identificadores de recursos, política de destinatários e outros valores de configuração como dados operacionais sensíveis.

Reinicie o gateway após salvar ~/.openclaw/openclaw.json:

openclaw gateway restart

4. Verificar status da sessão e pagar por conteúdo

Peça ao agente OpenClaw para verificar se a sessão configurada está disponível:

What's the status of my payment session?

Se a sessão estiver indisponível, expirada ou esgotada, pare. Use o caminho administrativo confiável para revisar a situação e criar uma sessão substituta — o runtime voltado ao modelo não pode criar nem expandir seu próprio orçamento.

Em seguida, peça ao agente para buscar o endpoint de teste:

Fetch https://sandbox.node4all.com/v1/x402-test

O plugin realiza uma sondagem delimitada, valida o desafio retornado contra a política do operador, chama o AgentCore Payments, aguarda até que a autorização assinada seja válida e repete a requisição. Com returnBody habilitado, a ferramenta retorna o corpo da resposta paga com content_returned: true, limitado a 10 KiB e marcado como untrusted: true. A prova de pagamento assinada não é retornada ao modelo.

Trate respostas de comerciantes e todo conteúdo recuperado como não confiável. O design não previne injeção de prompt — ele assume que o modelo pode ser manipulado e limita a autoridade de pagamento por separação de IAM, destinatários e ativos aprovados, teto por pagamento, orçamento acumulado da sessão e prazo de expiração. Habilite returnBody apenas quando o agente precisar da resposta paga, e trate essa resposta como dados, não como instruções.

Verifique o status da sessão novamente para confirmar que o orçamento restante reflete o pagamento realizado.

Limpeza

Para remover o plugin do OpenClaw e reiniciar o gateway:

openclaw plugins uninstall aws-agents-pay
openclaw gateway restart

Use o mesmo caminho administrativo confiável para remover os recursos de pagamento na AWS. Não exponha exclusão de infraestrutura ou criação de sessão ao runtime voltado ao modelo, e mantenha a função IAM do runtime sem essas permissões.

Colaboração com a OpenClaw Foundation

A AWS tem colaborado com a OpenClaw Foundation nessa integração, incluindo suporte a eventos da comunidade como o ClawCon, e trabalhou diretamente com a equipe de engenharia da Fundação para trazer o AgentCore Payments para o framework de plugins. Na visão da Fundação, pagamentos são uma extensão natural do que os plugins já fazem no OpenClaw: oferecer ao agente uma nova capacidade por meio de uma ferramenta bem definida.

Conclusão

Com o AgentCore Payments, um agente pode acessar APIs pagas, feeds de dados por uso e ferramentas MCP metered dentro de limites definidos antecipadamente por um humano. O AgentCore Payments cuida da integração com carteiras, limites de gastos e orquestração de pagamentos.

Nesse padrão com OpenClaw, o humano mantém as credenciais do provedor de carteira e a autoridade sobre destinatários, ativos, limites por pagamento, orçamento acumulado da sessão e prazo de expiração fora do runtime voltado ao modelo. O agente pode iniciar pagamentos apenas dentro dos limites aprovados.

Recursos

• Plugin no ClawHub: aws-agents-pay
• Código de exemplo: agente OpenClaw com AgentCore Payments
• Guia do desenvolvedor do Amazon Bedrock AgentCore Payments
• Especificação do protocolo x402
• Modelo de responsabilidade compartilhada da AWS
• Guia de funções IAM do AgentCore Payments
• Código de exemplo: OpenClaw na AWS

Fonte

Build OpenClaw agents that transact with Amazon Bedrock AgentCore payments (https://aws.amazon.com/blogs/machine-learning/build-openclaw-agents-that-transact-with-amazon-bedrock-agentcore-payments/)

O problema real de misturar modelos gerenciados e próprios

Quem já tentou montar um workflow agêntico em produção sabe que um dos maiores desafios é combinar Modelos Fundamentais (FM) gerenciados com modelos próprios — seja por custo, domínio específico ou requisitos de residência de dados — sem ter que reescrever toda a lógica do agente cada vez que algo muda.

A AWS publicou um guia técnico abordando exatamente esse problema. A solução combina endpoints com suporte à API compatível com OpenAI no Amazon SageMaker AI com o runtime do Amazon Bedrock AgentCore, entregando uma arquitetura pronta para produção que cobre otimização de custos, controle de residência de dados e flexibilidade de modelos em um único stack.

O exemplo prático usa o modelo Qwen 3.5 9B implantado no SageMaker AI, integrado a um sistema multi-agente com o Strands Agents, rodando ao lado de modelos do Amazon Bedrock. O workflow completo é então publicado no Amazon Bedrock AgentCore runtime.

Como a arquitetura está organizada

A solução conecta três caminhos distintos de hospedagem de modelos dentro de um único contêiner do Amazon Bedrock AgentCore:

• Agente orquestrador (Claude Haiku 4.5 no Bedrock) — classifica a intenção do usuário e roteia as tarefas usando inferência cross-region global.
• Agente de orçamento (Claude Sonnet 4.6 no Bedrock) — executa análises de orçamento com divisão 50/30/20 e saída estruturada via Pydantic.
• Agente de análise financeira (Qwen 3.5 9B no SageMaker AI) — realiza análise de ações e construção de portfólios usando chamadas de ferramentas (tool-calling).

O fluxo de execução é o seguinte: a requisição do usuário chega ao agente orquestrador, que opera dentro do Amazon Bedrock AgentCore runtime. Usando o padrão agents as tools do Strands Agents, o orquestrador decide se encaminha a tarefa para o agente de orçamento ou para o agente de análise financeira. Cada agente especializado invoca seu modelo correspondente — o de orçamento chama o Claude Sonnet 4.6 via Bedrock, e o de análise financeira chama o Qwen 3.5 9B via endpoint real-time do SageMaker usando a API compatível com OpenAI. Os resultados retornam pelo orquestrador até o usuário.

Vale lembrar que a disponibilidade dos modelos do Bedrock varia por Região AWS. Consulte os modelos suportados por Região no Amazon Bedrock antes de começar. O código-fonte completo está disponível no repositório GitHub de acompanhamento.

Pré-requisitos

• Conta AWS com permissões para Amazon SageMaker AI, Amazon Bedrock e AgentCore.
• Instalação dos pacotes: pip install sagemaker-core openai httpx strands-agents[otel] yfinance pydantic bedrock-agentcore
• Papel IAM com sagemaker:InvokeEndpoint e sagemaker:CallWithBearerToken.
• Acesso aos modelos Claude Haiku 4.5 e Claude Sonnet 4.6 no Bedrock.
• Python 3.12 ou superior.

Passo 1: Implantar o Qwen 3.5 9B no SageMaker AI

O primeiro passo é implantar o Qwen 3.5 9B usando o contêiner de aprendizado profundo (DLC) vLLM, na imagem vllm:0.22.1-gpu-py312-cu130, em uma instância ml.g6e.2xlarge:

region = "us-west-2"
model_id = "Qwen/Qwen3.5-9B"
instance_type = "ml.g6e.2xlarge" # 1x L40S (48GB VRAM)
num_gpu = 1

# vLLM 0.22.1, Python 3.12, CUDA 13.0, Ubuntu 22.04
inference_image = f"763104351884.dkr.ecr.{region}.amazonaws.com/vllm:0.22.1-gpu-py312-cu130-ubuntu22.04-sagemaker"

env = {
    "SM_VLLM_MODEL": model_id,
    "SM_VLLM_TENSOR_PARALLEL_SIZE": "1",
    "SM_VLLM_MAX_MODEL_LEN": "32768",
}

# Create Model
sm.create_model(
    ModelName=model_name,
    ExecutionRoleArn=role,
    PrimaryContainer={"Image": inference_image, "Environment": env},
)

# Create Endpoint Config + Endpoint
sm.create_endpoint_config(
    EndpointConfigName=endpoint_config_name,
    ProductionVariants=[{
        "VariantName": "v1",
        "ModelName": model_name,
        "InstanceType": instance_type,
        "InitialInstanceCount": 1,
        "ContainerStartupHealthCheckTimeoutInSeconds": 1200,
        "InferenceAmiVersion": inference_ami_version,
    }],
)

sm.create_endpoint(EndpointName=endpoint_name, EndpointConfigName=endpoint_config_name)

Passo 2: Construir o sistema multi-agente

A API compatível com OpenAI do SageMaker AI exige um token bearer para autenticação. Como esses tokens expiram, é necessário renová-los automaticamente a cada requisição em sessões longas. A solução usa uma subclasse de httpx.Auth para fazer essa renovação automática:

import httpx
from openai import AsyncOpenAI
from sagemaker.core.token_generator import generate_token

class SageMakerAuth(httpx.Auth):
    def __init__(self, region):
        self.region = region

    def auth_flow(self, request):
        request.headers["Authorization"] = f"Bearer {generate_token(region=self.region)}"
        yield request

strands_client = AsyncOpenAI(
    base_url=f"https://runtime.sagemaker.{REGION}.amazonaws.com/endpoints/{ENDPOINT_NAME}/openai/v1",
    api_key="sagemaker",
    http_client=httpx.AsyncClient(auth=SageMakerAuth(region=REGION)),
)

Em seguida, o sistema multi-agente é montado usando o padrão agents as tools do Strands Agents, com instâncias frescas de agente por invocação:

from strands import Agent, tool
from strands.models.openai import OpenAIModel

qwen_model = OpenAIModel(
    client=strands_client,
    model_id="",
    params={"temperature": 0.7, "max_tokens": 4096, "stream_options": {"include_usage": True}},
)

@tool
def financial_analysis_agent_tool(query: str) -> str:
    fresh = Agent(model=qwen_model, tools=[...], callback_handler=None)
    return str(fresh(query))

orchestrator = Agent(
    model=BedrockModel(model_id="global.anthropic.claude-haiku-4-5-20251001-v1:0"),
    tools=[budget_agent_tool, financial_analysis_agent_tool],
)

Passo 3: Publicar no Amazon Bedrock AgentCore runtime

A publicação usa o bedrock-agentcore-starter-toolkit. O notebook completo de implantação está disponível em deploy_agentcore.ipynb:

from bedrock_agentcore_starter_toolkit import Runtime

agentcore_runtime = Runtime()
agentcore_runtime.configure(
    entrypoint="main.py",
    auto_create_execution_role=True,
    auto_create_ecr=True,
    requirements_file="requirements.txt",
    region="ap-south-1",
    agent_name="personal_finance_agent",
)

launch_result = agentcore_runtime.launch(
    env_vars={
        "SAGEMAKER_ENDPOINT_NAME": "qwen35-9b-260612-082732",
        "SAGEMAKER_REGION": "ap-south-1",
        "AGENT_OBSERVABILITY_ENABLED": "true",
    }
)

O ponto crítico: observabilidade nos endpoints do SageMaker

Este é o aspecto mais importante de todo o guia. O Amazon Bedrock AgentCore runtime instrumenta os agentes automaticamente com OpenTelemetry (OTel), mas essa instrumentação não se aplica igualmente a todos os provedores de modelos.

O problema: tokens invisíveis

Chamadas a modelos do Bedrock recebem spans completos de IA generativa com contagem de tokens automaticamente — sem nenhum trabalho extra. Já os endpoints compatíveis com OpenAI do SageMaker (via OpenAIModel do Strands) não recebem telemetria automática de tokens. A instrumentação simplesmente não os reconhece como chamadas de IA generativa.

Na prática, todos os tokens consumidos pelo agente de análise financeira ao chamar o Qwen 3.5 9B no SageMaker ficam completamente invisíveis nos traces. Sem essa visibilidade, monitorar custos, detectar regressões ou depurar latência se torna impossível.

A causa raiz está no fato de que a integração OpenTelemetry do Strands emite spans para chamadas de ferramentas e eventos do ciclo de vida do agente, mas não emite spans gen_ai.chat com atributos de token para o provedor OpenAIModel. A auto-instrumentação do AgentCore só reconhece chamadas de inferência do Bedrock (feitas via boto3) como operações de IA generativa.

A solução: spans OpenTelemetry customizados

A saída é emitir manualmente um span gen_ai.chat que envolva a invocação do agente no SageMaker e extraia o uso de tokens a partir do AgentResult.metrics.accumulated_usage do Strands:

from opentelemetry import trace

tracer = trace.get_tracer("financial_analysis_agent")

@tool
def financial_analysis_agent_tool(query: str) -> str:
    """Route investment queries to Qwen on SageMaker with observability."""
    with tracer.start_as_current_span("gen_ai.chat", attributes={
        "gen_ai.system": "openai",
        "gen_ai.request.model": f"qwen3.5-9b ({SAGEMAKER_ENDPOINT_NAME})",
        "gen_ai.operation.name": "chat",
    }) as span:
        fa_agent = Agent(
            model=OpenAIModel(
                client=strands_client,
                model_id="",
                params={"temperature": 0.7, "max_tokens": 4096, "stream_options": {"include_usage": True}},
            ),
            system_prompt=FINANCIAL_ANALYSIS_PROMPT,
            tools=[get_stock_analysis, create_diversified_portfolio, compare_stock_performance],
            callback_handler=None,
        )
        result = fa_agent(query)

        # Extract token usage from Strands agent metrics
        usage = result.metrics.accumulated_usage
        span.set_attribute("gen_ai.usage.input_tokens", usage.get("inputTokens", 0))
        span.set_attribute("gen_ai.usage.output_tokens", usage.get("outputTokens", 0))
        span.set_attribute("gen_ai.usage.total_tokens", usage.get("totalTokens", 0))

        return str(result)

Um detalhe importante: o Strands rastreia o uso de tokens internamente com as chaves inputTokens, outputTokens e totalTokens. Esse dicionário só é populado se o provedor do modelo retornar dados de uso.

Por que o stream_options é obrigatório no vLLM

Por padrão, o vLLM não inclui um chunk de uso nas respostas em streaming. O Strands recebe os chunks de texto, mas nunca recebe o objeto de uso final — o que faz o accumulated_usage ficar zerado. Adicionar stream_options: {"include_usage": True} instrui o vLLM a enviar um chunk final extra com a contagem de tokens. Sem esse parâmetro, os spans gen_ai.chat reportarão 0 tokens, tornando toda a instrumentação inútil.

Configuração passo a passo da observabilidade

Para ativar a observabilidade completa, é necessário:

• Ativar o Amazon CloudWatch Transaction Search (uma vez por conta ou Região): aws xray update-trace-segment-destination --region ap-south-1 --destination CloudWatchLogs e aws xray update-indexing-rule --region ap-south-1 --name "Default" --rule '{"Probabilistic": {"DesiredSamplingPercentage": 100}}'
• Instalar o Strands com extras OTel: strands-agents[otel]>=1.0.0
• Definir AGENT_OBSERVABILITY_ENABLED=true nas variáveis de ambiente
• Usar opentelemetry-instrument como CMD do contêiner
• Adicionar stream_options: {"include_usage": True} nos parâmetros do OpenAIModel
• Criar o span gen_ai.chat customizado envolvendo a chamada do agente SageMaker

Com essa configuração, o trace de saída fica assim:

{
  "name": "gen_ai.chat",
  "attributes": {
    "gen_ai.system": "openai",
    "gen_ai.request.model": "qwen3.5-9b (qwen35-9b-260612-082732)",
    "gen_ai.operation.name": "chat",
    "gen_ai.usage.input_tokens": 1391,
    "gen_ai.usage.output_tokens": 1432,
    "gen_ai.usage.total_tokens": 2823
  },
  "durationNano": 37237386894
}

Esse trace exibe o span gen_ai.chat do modelo Qwen hospedado no SageMaker AI ao lado dos spans automaticamente instrumentados do Bedrock AgentCore, com contagem de tokens visível para ambos. A referência completa de convenções semânticas está nas convenções semânticas de IA generativa do OpenTelemetry.

Principais aprendizados

• Bedrock AgentCore auto-instrumenta chamadas Bedrock — nenhum trabalho extra é necessário para Claude ou Amazon Nova.
• Endpoints OpenAI do SageMaker precisam de spans manuais — o Strands não emite spans gen_ai.chat para o OpenAIModel.
• Uso de tokens exige stream_options — o vLLM não envia uso em streaming por padrão.
• Use result.metrics.accumulated_usage — chaves: inputTokens, outputTokens, totalTokens.
• Taxa de amostragem do AWS X-Ray importa — o padrão de 1% descarta a maioria dos traces. Use 100% durante o desenvolvimento.
• Instâncias frescas de agente por requisição — singletons causam erros em invocações concorrentes.

Como expandir essa arquitetura

Essa arquitetura é composável e pode ser estendida em várias direções:

• Trocar por modelos fine-tuned: basta apontar SM_VLLM_MODEL para o checkpoint fine-tuned no Amazon S3. A camada de autenticação, os spans OTel e a implantação no AgentCore permanecem inalterados.
• Testes A/B com componentes de inferência: implante variantes base e fine-tuned no mesmo endpoint do SageMaker e adicione um atributo de variante ao span OTel para comparar qualidade nos traces.
• Roteamento por custo: verifique a complexidade da consulta antes do despacho. Roteie consultas simples para o Haiku no Bedrock e reserve o endpoint de GPU do SageMaker para tarefas de raciocínio em múltiplos passos.

Limpeza dos recursos

Para evitar cobranças futuras, os recursos devem ser removidos:

agentcore_control = boto3.client("bedrock-agentcore-control", region_name=region)
agentcore_control.delete_agent_runtime(agentRuntimeId=launch_result.agent_id)

sagemaker_client.delete_endpoint(EndpointName=ENDPOINT_NAME)
sagemaker_client.delete_endpoint_config(EndpointConfigName=f"qwen35-9b-epc-{TIMESTAMP}")
sagemaker_client.delete_model(ModelName=f"qwen35-9b-{TIMESTAMP}")

Conclusão

O guia publicado pela AWS demonstra como conectar um modelo auto-hospedado no Amazon SageMaker AI ao Amazon Bedrock AgentCore runtime e, principalmente, como obter observabilidade completa em nível de tokens para endpoints do SageMaker que o Strands Agents não instrumenta por padrão. Os três pilares centrais da solução são:

• httpx.Auth + generate_token() + AsyncOpenAI — autenticação SageMaker pronta para produção dentro do AgentCore.
• Span OTel gen_ai.chat customizado + stream_options: {"include_usage": True} — visibilidade total de tokens para endpoints SageMaker.
• result.metrics.accumulated_usage — a API do Strands para extrair contagens de tokens.

Para começar, clone o repositório de acompanhamento e consulte o OBSERVABILITY.md para a referência completa. Recursos adicionais: documentação de observabilidade do Amazon Bedrock AgentCore.

Fonte

Building agentic workflows with SageMaker AI and Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/building-agentic-workflows-with-sagemaker-ai-and-bedrock-agentcore/)

O coração do treinamento por reforço: a função de recompensa

No treinamento de modelos de linguagem com aprendizado por reforço (RL), a função de recompensa é o mecanismo que define o que o modelo aprende. Uma recompensa sutilmente errada pode ensinar o comportamento errado enquanto todas as métricas de treinamento parecem saudáveis. Projetar uma recompensa robusta para tarefas agênticas multi-turno é um dos desafios mais complexos ao personalizar os modelos Amazon Nova.

A AWS publicou um guia técnico aprofundado sobre esse tema, focando especificamente no Amazon Nova Forge e na capacidade Bring Your Own Orchestration (BYOO) — que permite executar a lógica de recompensa no próprio ambiente do cliente. O post explora como desenhar uma recompensa composta, como executar código gerado pelo modelo com segurança e como instrumentar os componentes para que o time possa confiar no que o treinamento está aprendendo de fato.

RFT vs. SFT: por que o ajuste fino por reforço se destaca

O Amazon Nova oferece múltiplas abordagens de personalização. Entre elas, o ajuste fino por reforço (RFT) se destaca por ensinar comportamentos desejados por meio de feedback iterativo — sem exigir exemplos curados com raciocínios anotados, como ocorre no ajuste fino supervisionado (SFT).

O RFT multi-turno vai além: ele otimiza a recompensa acumulada ao longo de uma sequência de passos, como chamar ferramentas, executar código ou se recuperar de erros. O modelo aprende a partir de sinais de avaliação sobre suas próprias saídas.

O algoritmo utilizado pelo Nova Forge é o Otimização de Política Relativa de Grupo (GRPO). Para cada conversa, o GRPO usa a função de recompensa para ranquear K execuções do modelo e atualiza os pesos com base na vantagem normalizada do lote. Um ponto crítico: um sinal de recompensa só influencia o aprendizado se criar variação dentro do grupo. Se um componente retorna o mesmo valor para todas as execuções, ele não contribui nada para o gradiente.

Como o Nova Forge executa recompensas multi-turno

Para tarefas de turno único, o Nova Forge aceita a função de recompensa como uma função AWS Lambda. Já para tarefas multi-turno — que ultrapassam o limite de 15 minutos de invocação do Lambda — o caminho é o BYOO. O time configura rollout.delegate: true e executa a lógica de recompensa em um container próprio, por exemplo no Amazon ECS.

O container gerencia toda a interação multi-turno: executa o simulador de usuário, roda o código gerado e chama o verificador. Ao final, retorna uma recompensa agregada por amostra (aggregate_reward_score) e, opcionalmente, pontuações por componente (metrics_list). O Parte 1 desta série cobre a infraestrutura com Amazon SageMaker HyperPod e o deployment via AWS CDK.

Estruturando uma recompensa multi-turno

Recompensas escalares simples são fáceis de burlar, e uma única recompensa terminal costuma ser esparsa demais para o modelo aprender em tarefas multi-turno. A abordagem recomendada combina três tipos de sinal:

• Recompensas de resultado (nível de episódio): capturam se o artefato final atingiu o objetivo — por exemplo, se os testes unitários passaram. São esparsas no início do treinamento.
• Recompensas comportamentais (nível de turno): capturam se o modelo exibiu o comportamento intermediário desejado, como perguntar antes de agir ou chamar a ferramenta correta. São úteis para moldar comportamentos que a recompensa de resultado é esparsa demais para ensinar.
• Penalidades: desencorajam explicitamente modos de falha como adivinhar, repetir ou travar. Separam estratégias boas e ruins para que o otimizador enxergue um gradiente.

Exemplo prático: ensinando o Nova Lite 2.0 a perguntar antes de codificar

A AWS construiu uma tarefa de codificação colaborativa multi-turno com 500 problemas de programação únicos. O Amazon Nova Lite 2.0 foi treinado nessa tarefa com RFT multi-turno, usando GRPO com Adaptação de Baixo Rank (LoRA), no Amazon SageMaker HyperPod, com a recompensa implementada dentro de um container de ambiente gerenciado pelo cliente (o caminho BYOO do Nova Forge).

A mecânica é a seguinte: o modelo recebe uma solicitação de código vaga e subespecificada. Um simulador de usuário guarda a especificação completa em privado e revela um detalhe apenas quando o modelo pergunta. Em cada turno, o modelo pode fazer uma pergunta de esclarecimento ou submeter código. Se perguntar, o simulador responde e a conversa continua. Se submeter código, o rollout termina e o handler de recompensa executa esse código contra testes unitários ocultos.

A recompensa é uma soma ponderada de quatro componentes:

• correctness (peso 1.0): fração dos testes unitários ocultos que passam no código final.
• asked_before_coding (peso 0.6): 1.0 se perguntou no turno 1 e depois submeteu; 0.6 se perguntou depois e submeteu; 0 caso contrário.
• guessed_immediately (peso 0.4): penalidade de -1.0 se o primeiro turno foi código sem nenhuma pergunta.
• loop_penalty (peso 0.2): -0.5 se os dois últimos turnos forem mais de 80% similares.

Dois princípios guiam o design: primeiro, não condicionar o comportamento desejado a outro componente — asked_before_coding é creditado por conta própria, não condicionado à correção do código. Segundo, penalizar explicitamente o modo de falha — guessed_immediately torna adivinhar estritamente pior do que perguntar, o que preserva a variação entre estratégias dentro de um grupo GRPO.

def asked_before_coding(completion, answer, **kw) -> float:
    msgs = _messages(completion, kw)
    first_q = _first_question_turn(msgs, parser)
    final = _final_code(completion, parser)
    committed = bool(final) and not _is_question(final)
    if first_q == 1 and committed:
        return 1.0  # asked first, then committed (ideal)
    if first_q is not None and committed:
        return 0.6  # asked later, then committed
    return 0.0  # never asked, or asked but never committed

def guessed_immediately(completion, answer, **kw) -> float:
    for m in _assistant_turns(completion, kw):
        code = _code_of(parser.parse(m["content"]))
        return -1.0 if (code and not _is_question(code)) else 0.0
    return 0.0

Executando código gerado pelo modelo com segurança

O componente de correção executa código gerado pelo modelo contra testes unitários. Sob RL, esse código é produto de exploração — trate-o como não validado. O container deve rodar em ambiente de execução isolado, sem expor credenciais ou rede ao código gerado, com limites de recursos e em diretório temporário. Um sentinel aleatório por execução impede que o modelo forje o resultado escrevendo o marcador esperado na saída de erro.

import resource, secrets, subprocess, sys, tempfile
from pathlib import Path

def run_tests(code: str, test: str, timeout_s: int = 30) -> float:
    nonce = secrets.token_hex(8)  # unforgeable per-run marker
    harness = (
        "import sys, unittest, json\n"
        f"{code}\n\n{test}\n\n"
        'if __name__ == "__main__":\n'
        "    r = unittest.TextTestRunner(stream=sys.stderr, verbosity=0).run(\n"
        "        unittest.TestLoader().loadTestsFromModule(sys.modules[__name__]))\n"
        f"    sys.stderr.write('__{nonce}__' + json.dumps("
        "{'total': r.testsRun, 'passed': r.testsRun - len(r.failures) - len(r.errors)}) + '__"
        f"{nonce}__')\n"
    )

    def _limit():
        resource.setrlimit(resource.RLIMIT_CPU, (timeout_s, timeout_s))
        resource.setrlimit(resource.RLIMIT_AS, (2 * 1024**3, 2 * 1024**3))  # 2 GB
        resource.setrlimit(resource.RLIMIT_NPROC, (64, 64))

    with tempfile.TemporaryDirectory() as cwd:
        path = Path(cwd) / "h.py"
        path.write_text(harness)
        try:
            proc = subprocess.run(
                [sys.executable, str(path)],
                capture_output=True,
                text=True,
                timeout=timeout_s,
                cwd=cwd,
                env={"PATH": "/usr/bin"},  # no creds, no network env
                preexec_fn=_limit,
            )
        except Exception:
            return 0.0
        # parse the nonce-delimited summary and validate the test count before scoring
        ...

Também é importante validar o número de testes efetivamente executados contra o número esperado, para impedir que o modelo dilua a pontuação com testes trivialmente aprovados que ele mesmo escreveu.

Armadilhas que colapsam uma recompensa — e como detectá-las

O design de recompensas multi-turno tem um conjunto bem conhecido de modos de falha. O mais perigoso é o colapso silencioso: a recompensa agregada, a perda e as curvas de comprimento de resposta podem parecer saudáveis enquanto um componente que você conta não contribui nada para o aprendizado.

Quando a recompensa colapsa para uma única estratégia

Uma versão anterior da recompensa condicionava o bônus de “perguntar” à correção do código — você só ganhava o bônus se o código final também passasse nos testes. Também havia um termo de eficiência que recompensava conversas mais curtas. O treinamento colapsou: o modelo convergiu para adivinhar no primeiro turno. A vantagem GRPO foi a zero e o aprendizado parou.

Dois erros de design causaram isso. Primeiro, o gate estava atrás de uma condição inalcançável — a correção era próxima de zero nas tarefas difíceis, então o bônus de perguntar quase nunca disparava. Segundo, o termo de eficiência tinha um ótimo degenerado — menos turnos o maximizava, então a política colapsou para um único turno não-comprometido. A correção é o design descrito acima: descondicionar o comportamento desejado e penalizar o modo de falha explicitamente.

Componente silenciosamente morto

Quando um componente de recompensa retorna o mesmo valor para todas as execuções de um grupo GRPO, sua variância intra-grupo é zero. Ele não contribui nada para a vantagem nem para o gradiente — mesmo com peso máximo. Os componentes que ainda variam mantêm a recompensa agregada, a perda e o comprimento de resposta parecendo saudáveis, então as curvas nunca revelam o problema.

Na execução descrita no artigo original, isso aconteceu exatamente assim: a taxa de perguntas de esclarecimento do modelo subiu de cerca de 34% para 96%, mas a correção do código mal se moveu — porque o scorer de correção retornava o mesmo valor em cada rollout. A causa raiz era que o harness nunca executava de fato o código do modelo.

Como instrumentar para pegar esses problemas cedo

• Acompanhe o desvio padrão intra-grupo de cada componente, não apenas a recompensa agregada. Qualquer componente com variância intra-grupo próxima de zero não está treinando, independentemente do seu peso.
• Leia transcrições ordenadas pelo componente que está testando, não pela recompensa total. Ordenar por recompensa total esconde um componente morto atrás dos vivos.
• Faça ablação de cada componente que você afirma estar funcionando. Se remover um componente não muda nada, ele não estava contribuindo.
• Projete para variância intra-grupo. Gates inalcançáveis, ótimos degenerados e termos saturados colapsam essa variação e param o aprendizado mesmo quando a recompensa parece boa.
• Fique atento a um componente denso sufocando outro. Quando o sinal comportamental satura, o sinal de resultado pode nunca receber gradiente. Considere reduzir o peso do componente de molde quando ele saturar.

Pré-requisitos para seguir o exemplo

Para reproduzir o ambiente descrito, são necessários: uma assinatura do Amazon Nova Forge (que fornece o Nova Customization SDK e as APIs de RFT multi-turno); a infraestrutura de RFT multi-turno da Parte 1 (cluster Amazon SageMaker HyperPod, ambiente gerenciado no Amazon ECS, bucket Amazon S3 para dados de rollout e checkpoints); e o código de exemplo do repositório aws-samples/sample-nova-multi-turn-rl-infra.

O ambiente de recompensa personalizado é opt-in: no arquivo cdk.json, defina use_custom_env como "true" e custom_env_id com o ID do seu ambiente antes de fazer o deploy. Por padrão, o stack usa o ambiente built-in de wordle.

Conclusão

A função de recompensa é a parte do RFT que o time projeta — e é onde vivem as falhas sutis. O modelo pode aprender o comportamento treinado enquanto um componente que você considera importante não contribui nada para o aprendizado, sem que nenhuma métrica agregada revele isso. Melhor instrumentação, não um algoritmo melhor, é o que resolve esse problema.

Com uma função de recompensa personalizada no Amazon Nova Forge, o time tem controle total sobre a recompensa — o que significa que a responsabilidade de acertar é também do time. Para a infraestrutura e o deployment via AWS CDK que tornam essas execuções reproduzíveis, consulte a Parte 1 desta série.

Fonte

Custom reward functions for multi-turn reinforcement learning with Amazon Nova Forge (https://aws.amazon.com/blogs/machine-learning/custom-reward-functions-for-multi-turn-reinforcement-learning-with-amazon-nova-forge/)