O modelo Claude da Anthropic enfrenta desafios técnicos na geração de código e na confiabilidade de agentes

A Anthropic enfrentou recentemente múltiplos desafios técnicos com os modelos Claude. A geração de código sofreu redução de liberdade devido a restrições de marca-d'água; o mecanismo de pensamento adaptativo do Sonnet 5 permite que o mesmo modelo ajuste diferentes níveis de esforço computacional, borrando os limites de capacidade da linha de produtos; embora o contexto de 1M pareça abundante, em sessões longas de Agent, o modelo efetivamente utiliza apenas cerca de 20%-30%, após o qual ocorre confusão de estado e omissões; durante a compressão do contexto, é difícil distinguir quais informações ainda são válidas, e suposições temporárias podem ser incorretamente transformadas em fatos; após o Agent modificar ativamente o ambiente, o modelo passa a analisar os novos erros que criou, em vez do problema original. O artigo destaca que a confiabilidade dos Agents longos depende cada vez mais da clareza do estado, da verificabilidade das ações e da capacidade de reversão de erros, e não apenas do desempenho individual do modelo.

Autor e fonte do artigo: Leiphone

O que é mais problemático do que a pontuação do modelo cair é o fato de que o modelo ainda está sendo atualizado, mas os usuários começam a achar que está ficando cada vez menos útil.

Anthropic recentemente teve um pouco desse sabor.

Nestes dias, um post no X reuniu várias insatisfações típicas de Claude neste período: textos e códigos começaram a ser inseridos com marcas legíveis por máquina, a experiência real do Sonnet 5 não acompanhou o entusiasmo gerado pelas atualizações do modelo, o Fable 5 foi vendido a um preço mais alto, mas é difícil perceber claramente em que ele é superior ao Opus 5; além disso, há um feedback ainda mais preocupante: o contexto do Fable 5 é utilizado apenas em cerca de 20%–30%, e após isso, seu desempenho começa a cair.

Esses quatro problemas parecem não ter relação aparente: um parece ser um problema de mecanismo de geração, outro um problema de capacidade do modelo, um terceiro um problema de precificação, e o quarto parece simplesmente ser um problema com contextos longos.

Mas, analisando sob a perspectiva da pilha tecnológica atual do Claude, eles estão realmente presos em cinco posições muito específicas: como o modelo gera saídas, quanto cálculo está disposto a gastar durante a inferência, por que diferentes modelos estão se tornando cada vez mais difíceis de hierarquizar, por que o contexto longo começa a falhar antes de ser totalmente preenchido, e por que as capacidades observadas nos experimentos frequentemente se reduzem em tarefas reais de Agentes.

Então, o problema recente da Anthropic pode não ser simplesmente um “declínio do modelo”. É mais como se, à medida que o Claude ficasse cada vez mais forte, a geração, o cálculo, o contexto e o tempo de execução do Agente começassem a se atrapalhar mutuamente.

01

Marcos legíveis por máquina são inseridos no texto comum; o desafio técnico é manter sinais estáveis sem alterar significativamente a qualidade da geração. No código, esse problema se torna claramente mais difícil, pois a distribuição de tokens em linguagem natural e em código não é a mesma.

Artigo: https://arxiv.org/pdf/2301.10226

A linguagem natural frequentemente apresenta múltiplos candidatos com significados semelhantes. O mesmo sentido pode ser expresso com palavras diferentes ou ordem alterada, e o modelo possui certa redundância de geração em muitas posições. Uma abordagem comum de watermarking de texto consiste em aproveitar essa redundância, alterando levemente as probabilidades de amostragem entre tokens aceitáveis, acumulando suficientemente para deixar padrões estatísticos.

O código possui muitas posições de baixa entropia. Após a declaração de variáveis, as referências subsequentes só podem usar o mesmo nome; os campos, aspas e parênteses do JSON são restritos por uma estrutura rígida; os parâmetros da função devem corresponder à interface; em caminhos, expressões regulares, SQL e comandos Shell, a alteração de um único token pode alterar diretamente o comportamento.

Do ponto de vista da distribuição de probabilidade, essas posições geralmente são muito afiadas. O token correto ocupa uma alta probabilidade, enquanto os outros candidatos não são apenas outra expressão, mas podem ser erros. Portanto, a limitação central enfrentada pela marca-d'água de código é, na verdade, a capacidade de codificação.

Se uma posição possui apenas uma saída razoável, ela tem quase nenhum espaço para承载 sinais adicionais; se o sistema inserir marcas apenas em posições de alta entropia, enfrentará problemas de códigos curtos, alta proporção de tokens estruturados e insuficiência de posições utilizáveis.

Assim, surge um compromisso direto entre detecção de intensidade, qualidade de geração e resistência à modificação: um sinal muito fraco é difícil de detectar, restrições muito fortes podem afetar a geração correta, e manter a capacidade de detecção após formatação ou reescrita local exige maior redundância de sinal.

A Anthropic não divulgou como exatamente os marcadores de texto do Claude alteram a amostragem, portanto não é possível atribuir diretamente as mudanças na qualidade do Claude Code a um determinado algoritmo de marca-d'água.

O que se pode determinar aqui é outra mudança: a geração de código está assumindo simultaneamente um número crescente de restrições. Além da corretude semântica e de execução, pode ser necessário obedecer a protocolos de ferramentas, formatos estruturados, regras de segurança e marcas de origem, enquanto a liberdade do próprio código para absorver essas restrições adicionais é muito menor do que a da linguagem natural.

02

As mudanças trazidas pelo pensamento adaptativo do Sonnet 5 não se limitam a fazer o modelo pensar por mais um pouco.

Anteriormente, ao falar sobre Sonnet, Opus e Fable, era fácil entendê-los como alguns pontos de capacidade fixos. Agora, com a adição do effort, o mesmo modelo pode cair em diferentes intervalos de compute no tempo de teste, e o próprio modelo já não representa completamente quanto de capacidade foi realmente investido em uma solicitação.

Link de referência: https://platform.claude.com/docs/en/build-with-claude/effort

Essa mudança é especialmente evidente no Coding Agent. Quando o Claude enfrenta um bug, precisa não apenas gerar uma solução de modificação, mas também decidir quais arquivos ler, qual cadeia de chamadas seguir, quantas hipóteses candidatas manter, se deve executar testes, se continua verificando dependências e quando considera que as evidências são suficientes.

Essas ações podem ser vistas como uma árvore de busca. Um menor investimento computacional significa cortar ramificações mais cedo e formar julgamentos mais rapidamente; um investimento maior permite que o modelo continue buscando e verificando, reduzindo a probabilidade de executar ações diretamente quando as evidências forem insuficientes.

Link de referência: https://platform.claude.com/docs/en/build-with-claude/effort

Portanto effort não regula apenas o comprimento do thinking, mas o alcance de busca permitido para uma tarefa do Agent. Isso alterará diretamente a hierarquia do modelo da Anthropic.

If a regular coding task is already easy for Opus, increasing effort will likely cause Opus to quickly enter the performance plateau. Even with a stronger base model, Fable has little remaining difficulty to convert into a noticeable experience difference.

O usuário deve pagar a diferença de preço entre os modelos desde o início da solicitação. Assim, o Fable é mais capaz de demonstrar valor não com explicações de código comum, refatorações em pequena escala ou debugging comum, mas sim com bibliotecas de código desconhecidas, planejamento em múltiplas etapas, operações entre ferramentas distintas, execução autônoma prolongada e tarefas que exigem recuperação após a ocorrência de erros.

Link de referência: https://www.anthropic.com/news/claude-opus-5

Isso significa que o que os modelos avançados estão vendendo está mudando. Eles não vendem mais apenas “a resposta mais forte desta rodada”, mas uma confiabilidade adicional dentro de uma trajetória mais complexa.

O problema é que essa vantagem exige tarefas suficientemente longas para se manifestar, e uma vez que as tarefas se prolongam, a capacidade do modelo deixa de ser o único fator determinante, e o estado do contexto passa a ocupar posição central.

03

Ver um contexto de 1M很容易被理解 como uma grande memória de trabalho, portanto, quando o Claude começa a perder, repetir ou apresentar confusão de estado usando apenas 200K ou 300K tokens, parece muito contra-intuitivo.

Mas a janela de contexto mede capacidade, não consistência de estado. Uma sessão longa do agente não é um documento estático, mas sim um histórico de execução em constante acréscimo.

Link de referência: https://platform.claude.com/docs/en/build-with-claude/context-windows

Um arquivo pode ser modificado várias vezes sequencialmente; um bug inicialmente identificado como um problema de cache foi posteriormente descoberto como proveniente de concorrência; um teste pode inicialmente falhar, depois passar, e voltar a falhar devido a novas alterações. O conteúdo antigo não é automaticamente excluído com as mudanças de estado; o novo conteúdo é simplesmente acrescentado após o anterior.

O problema aqui não é apenas recuperação. O modelo não só precisa encontrar informações relevantes para a tarefa atual, mas também avaliar se essas informações ainda são válidas.

As funções antigas e novas são altamente semelhantes, e os logs de teste antigos e novos contêm muitos mesmos tokens; análises já descartadas também podem ser semanticamente muito relevantes para o problema atual. O Attention não tem dificuldade em encontrar esse conteúdo, mas a dificuldade está em determinar as relações de cobertura entre eles.

O banco de dados pode manter o estado atual por meio de números de versão, horários de atualização, transações e campos explícitos; o contexto em linguagem natural geralmente não possui essa estrutura. Ele é mais semelhante a um log apenas de acréscimo, e o modelo precisa recuperar sozinho qual é o estado atual do mundo a partir da ordem dos eventos.

Link de referência: https://platform.claude.com/docs/en/build-with-claude/context-windows

Portanto, a complexidade de contextos longos não corresponde simplesmente à proporção de tokens ocupados. Um documento estático de 250K tokens pode ser muito mais fácil de processar do que 250K tokens de histórico de Agente, pois este último contém grande quantidade de objetos modificados, julgamentos parciais, resultados de ferramentas e estados já inválidos.

Thinking history ainda aumentará essa complexidade. A sessão não armazena apenas “o que aconteceu”, mas também pode conter “por que essa decisão foi tomada naquele momento”. Se o raciocínio inicial foi baseado em uma suposição posteriormente refutada, aquele raciocínio ainda pode participar de julgamentos subsequentes por ser altamente relevante para a questão atual.

Então, a verdadeira limitação de 1M de contexto não é apenas quantas informações cabem, mas se o modelo ainda consegue recuperar estávelmente a versão atual à medida que surgem mais versões históricas do mesmo objeto.

04

À medida que o contexto continua a crescer, a compactação parece uma abordagem natural: comprimir o histórico antigo e continuar a execução. No entanto, a compactação nos cenários de Agentes não é a mesma coisa que um resumo comum.

Ao resumir um artigo, omitir um exemplo afeta apenas a completude da informação; ao comprimir a trajetória do Agente, omitir uma restrição ainda válida pode alterar diretamente o caminho de execução subsequente.

Link de referência: https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools

Como a compactação precisa resolver não é “quais conteúdos são importantes”, mas sim “quais conteúdos ainda são válidos agora”. Um histórico pode conter simultaneamente tarefas concluídas, julgamentos posteriormente revogados, restrições de interface ainda válidas, resultados de teste expirados e soluções temporárias. O compactador precisa reorganizar esses estados temporais em uma representação que possa ser usada na próxima rodada.

Se " atualmente suspeita-se que o problema venha do cache " for reduzido a " o problema vem do cache ", a suposição temporária torna-se um fato; se uma solução já descartada ainda for incluída no resumo, os Agentes subsequentes podem reexecutar o caminho antigo; se alguma restrição crítica não for incluída no resumo, o modelo nem mesmo a verá novamente.

Portanto, o indicador-chave da compactação não é a taxa de compressão, mas a fidelidade do estado. É por isso que Git, testes, arquivos de tarefas, memória e handoff estruturado estão se tornando cada vez mais importantes em agentes de longo prazo.

Eles não apenas aumentam as informações que o modelo pode ver, mas transferem certos estados que precisam ser válidos a longo prazo, do histórico em linguagem natural para sistemas externos. O Git define a versão atual do código, os testes fornecem resultados verificáveis, os arquivos de tarefa registram o progresso e o estado estruturado distingue as conclusões atuais das tentativas anteriores.

O contexto pode manter histórico rico, mas não pode assumir permanentemente a responsabilidade total pelo gerenciamento de estado.

Link de referência: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

05

As perguntas anteriores ainda podem ser entendidas como como o modelo processa a entrada. O agente dá um passo adicional, pois ele ativamente modifica o ambiente.

Em bate-papos comuns, um erro do modelo geralmente permanece no texto de saída. O agente pode modificar código, executar comandos, instalar dependências, ajustar configurações e ler os novos resultados gerados por essas ações.

Então, o erro não é mais apenas um erro de julgamento, mas se torna uma mudança no ambiente. Suponha que o Claude tenha incorretamente classificado um bug como um problema de cache, modificando assim a lógica de cache, o mecanismo de nova tentativa e alguns pontos de chamada. Em seguida, uma série de novas exceções aparece nos testes.

Essas anomalias são reais, mas não surgiram naturalmente do bug original, e sim foram criadas pela modificação anterior. Isso faz com que o Agente entre em um modo de falha muito específico: o modelo começa a analisar a distribuição de dados que ele mesmo criou.

Link de referência: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

Se ele puder identificar “esses novos erros surgiram após a última modificação”, ainda poderá reverter e revalidar a hipótese original; sem estabelecer essa relação causal, pode continuar tratando os novos erros como problemas independentes, corrigindo-os um a um.

Neste momento, cada passo local pode ter uma justificativa, mas a trajetória completa da tarefa já se desviou do problema original. Portanto, a confiabilidade de um agente longo não pode ser avaliada apenas pela taxa de acerto em cada passo. O mais crucial é se o sistema consegue detectar, atribuir e recuperar após erros entrarem no ambiente.

O Git diff pode informar ao modelo quais alterações ocorreram recentemente, os testes podem verificar se algum comportamento foi comprometido, os checkpoint e rollback podem limitar a propagação de erros, e o evaluator independente pode fornecer verificação adicional além da explicação própria do modelo.

A função desses componentes, em essência, é fornecer ao Agente capacidade de correção em ciclo fechado.

Link de referência: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

06

Muitos benchmarks medem: dado um ambiente inicializado, o modelo consegue completar a tarefa? Agentes reais adicionam uma camada adicional de dificuldade: o ambiente muda continuamente com base nas ações próprias do modelo. Portanto, dois modelos com taxas de aprovação finais semelhantes podem oferecer experiências totalmente diferentes na prática.

Um modelo pode ter julgamentos muito precisos no início, mas, ao errar, continua a corrigir ao longo do caminho errado; outro modelo pode não ser claramente mais forte em cada passo, mas consegue identificar mais rapidamente quando uma modificação criou um novo problema e, em seguida, faz rollback para escolher outro caminho.

Olhar apenas o ponto final torna difícil distinguir esses dois comportamentos. Se a tarefa do Agente for prolongada, métricas mais significativas tornam-se a quantidade de estados críticos mantidos após a compactação, se é possível identificar os passos que introduziram erros após modificações incorretas, se o estado interno da tarefa continua alinhado com o ambiente real à medida que as chamadas de ferramentas aumentam, e qual o custo necessário para recuperar o curso após um desvio.

Esses indicadores não medem o quão inteligente é uma única resposta, mas sim se uma trajetória pode permanecer controlável.

Em resumo, os vários problemas recentemente expostos pela Anthropic ocorrem em níveis diferentes. Após a concentração desses problemas, os limites técnicos do Claude também começaram a mudar.

Antes, era mais sobre perguntar se o modelo conseguia resolver um determinado problema; agora, o desafio é ainda maior: após a tarefa rodar por várias horas, passar por dezenas de chamadas de ferramentas, várias compressões de estado e múltiplas alterações de código, o sistema ainda consegue manter uma versão confiável do estado atual?

A capacidade do modelo continua a crescer, apenas elevando o limite de julgamento em cada etapa. A estabilidade do agente longo depende cada vez mais de outro conjunto de capacidades: se o estado está claro, se as ações são verificáveis e se os erros são reversíveis.