Anthropic abre código de referência para agentes de e-commerce

A Anthropic divulgou um guia de arquitetura para agentes de e-commerce e, ao mesmo tempo, abriu o código da implementação de referência anthropics/commerce-agents no GitHub, cobrindo agentes de compra, agentes para vendedores, além de frameworks e ferramentas de avaliação para quatro cenários: varejo, viagens, telecomunicações e emissão de ingressos. O texto foi escrito por Ali Shazal e Matthew Koen.

A recomendação inicial é quase simples demais, ao ponto de soar contraintuitiva: um modelo, um loop de agente padrão, capacidades de cauda longa delegadas a skills, e as ferramentas chamando diretamente os sistemas de backend já existentes.

Skills em vez de subagentes

O documento coloca "usar skills, não subagentes" como o primeiro princípio de arquitetura. A razão é que o processo de transferência em arquiteturas multiagente causa perda de estado, o que reduz a qualidade. Segundo a Anthropic, em suas comparações, a combinação de um único agente com skills supera de forma consistente duas alternativas — um prompt genérico que tenta resolver tudo, e a divisão em vários subagentes.

Para decidir o que vai no system prompt e o que vai em skills, a regra é de frequência: instruções usadas em mais de um terço das solicitações ficam no system prompt, o restante vai para skills. Em cenários de compras, a busca de produtos aparece em quase toda sessão, por isso permanece no prompt.

Componentes de interface também são tratados como ferramentas, em vez de deixar o modelo gerar tags customizadas. Essa segunda abordagem tem se mostrado pouco confiável em produção, já que o formato das tags geradas pelo modelo não tem uma restrição rígida.

A taxa de acerto do cache decide a conta da latência

A seção de performance concentra o conteúdo mais útil no cache. O documento afirma que, em produção, a taxa de acerto do cache pode chegar a entre 90% e 99%, e o custo de leitura do cache é apenas um décimo do preço de tokens novos. O método consiste em dividir a requisição em três segmentos, em ordem fixa: um segmento global com o system prompt e as definições de ferramentas, um segmento de sessão com o contexto do usuário, e um segmento volátil com o estado atual.

Uma armadilha é apontada de forma bem direta: colocar um timestamp ou a página atual no topo do system prompt invalida o cache a cada requisição. Esse erro é comum em e-commerce, porque desenvolvedores costumam colocar o "carrinho atual" logo no início. O documento também dá uma referência de escala: respostas em e-commerce costumam ficar entre 500 e 700 tokens de saída.

A metodologia de escolha de modelo consiste em rodar todo o conjunto de avaliação em todos os modelos candidatos e níveis de raciocínio, analisando as métricas de qualidade junto com o orçamento de custo e latência, sem separar os dois.

Segurança não pode depender só do prompt

A seção sobre implantação em produção assume uma posição firme: o prompt é o ponto de partida para o comportamento seguro, mas no e-commerce não pode ser o ponto de execução. Ações como pagamento, reembolso e alteração de preço precisam passar por retenção e aprovação no lado do servidor. O mecanismo descrito é chamado de controle de acesso por ID — o harness registra, para cada sessão, cada ID que o servidor entregou ao modelo, e apenas os IDs presentes nesse registro podem ser gravados ou renderizados. IDs de produto inventados pelo próprio modelo são bloqueados de imediato.

A memória também é mantida fora do modelo: a memória de longo prazo é armazenada em um banco de dados próprio, como registros tipados (chave, valor, categoria, sessão de origem), lidos de forma assíncrona por outra thread ou processo, que adiciona, remove ou altera fatos. A extração assíncrona elevou a taxa de recuperação de fatos em 13%.

A avaliação abandonou a simulação de diálogos com múltiplos turnos e adotou uma abordagem de snapshot: constrói-se um estado de teste, acrescenta-se uma mensagem do usuário e avalia-se o resultado. A escala inicial recomendada é de 50 a 100 casos por fluxo de usuário, com exemplos positivos e negativos pareados, cobrindo tanto solicitações dependentes de contexto quanto solicitações que atravessam múltiplas capacidades.

A Anthropic afirma que esses agentes já estão em produção, e clientes empresariais registraram tickets médios maiores. Nomes específicos de clientes não foram divulgados.

Fontes: blog oficial da Anthropic, CocoLoop, repositório GitHub anthropics/commerce-agents; os números sobre taxa de acerto do cache, o ganho de 13% na recuperação de fatos e os 500-700 tokens de saída vêm todos deste documento.