Anthropic GitHub Corrige Duas Falhas Ocultas no LangChain 1.5.3

As integrações com Anthropic receberam duas correções direcionadas quando o LangChain lançou a versão 1.5.3 em 28 de julho de 2026. A atualização da Anthropic no GitHub resolve falhas que poderiam interromper loops de agentes Claude com erros HTTP 400. Nenhuma das mudanças adiciona uma capacidade visível ao modelo, mas ambas protegem o histórico de mensagens do qual os agentes dependem.

Uma correção preserva um campo thinking vazio quando o LangChain processa dados de assinatura em streaming. Sem esse campo, uma resposta válida do Claude poderia se tornar uma mensagem inválida quando reproduzida na chamada seguinte ao modelo. A segunda correção remove identificadores exclusivos do LangChain dos blocos de conteúdo de mensagens de sistema antes de enviá-los à Anthropic.

Essa combinação torna a atualização mais do que um patch rotineiro. A versão expõe um conflito recorrente na infraestrutura de agentes: os frameworks buscam um formato de mensagem portável, enquanto os provedores de modelos impõem esquemas de API mais restritos. OpenAI, Google, Anthropic e outros provedores aplicam regras diferentes no limite final da solicitação.

O LangChain fica entre esses formatos. Suas abstrações ajudam desenvolvedores a trocar modelos e combinar ferramentas, mas cada conversão cria outro ponto em que um estado válido pode se perder. A versão 1.5.3 mostra como uma única string vazia ausente ou um identificador extra pode desativar um agente que, de outra forma, funcionaria corretamente.

O Que Mudou no LangChain Anthropic 1.5.3

O LangChain Anthropic 1.5.3 corrige dois caminhos de conversão de mensagens que produziam solicitações rejeitadas pela API do Claude.

As notas oficiais de lançamento da Anthropic listam duas correções desde a versão 1.5.2. Uma abrange blocos de pensamento transmitidos por streaming. A outra sanitiza o conteúdo de mensagens de sistema antes da transmissão.

A correção de streaming mira uma sequência específica de eventos que envolve pensamento adaptativo. O pensamento adaptativo permite que o Claude determine quanto raciocínio interno aplicar dentro dos limites configurados pelo provedor. A API pode retornar conteúdo estruturado de pensamento e uma assinatura criptográfica junto à resposta visível.

Durante o streaming, esses resultados não chegam necessariamente como um único objeto completo. O LangChain recebe múltiplos eventos e os combina em uma AIMessage, sua representação normalizada de uma resposta do modelo. Essa mensagem montada pode posteriormente se tornar parte de outra solicitação.

A falha relatada aparecia quando um bloco de pensamento continha uma string vazia, mas ainda recebia um signature_delta. Um delta de assinatura é um fragmento transmitido por streaming que carrega dados de assinatura para o bloco de pensamento. Nenhum thinking_delta era enviado em seguida porque não havia texto de raciocínio a acrescentar.

Inicialmente, o LangChain descartava o estado do bloco vazio. Mais tarde, ele reconstruía o bloco a partir do evento de assinatura, produzindo um objeto com os campos type e signature. No entanto, a chave obrigatória thinking ficava ausente.

A mensagem podia parecer inofensiva enquanto era armazenada dentro de uma aplicação. Ela falhava apenas quando o agente reproduzia esse histórico para o Claude. A Anthropic então rejeitava a solicitação porque o bloco de pensamento não tinha seu campo obrigatório.

A correção de streaming usa setdefault("thinking", "") ao lidar com deltas de assinatura. Essa operação mantém um valor existente ou insere uma string vazia quando a chave está ausente. Assim, ela preserva a estrutura de objeto esperada pelo provedor sem inventar texto de raciocínio.

A correção de mensagens de sistema trata do problema oposto. Em vez de perder um campo obrigatório, o LangChain encaminhava um campo não suportado.

Os blocos de conteúdo do LangChain v1 podem incluir um id interno. Esse identificador ajuda o framework a representar e rastrear conteúdo de forma consistente. O esquema de mensagens de sistema da Anthropic não aceita o mesmo campo nessa posição.

Antes da versão 1.5.3, _format_messages podia encaminhar conteúdo de SystemMessage baseado em listas sem restringir cada bloco de texto. Um bloco criado por meio de create_text_block() podia, portanto, levar seu identificador interno à carga útil enviada.

A Anthropic rejeitava essa solicitação com um erro informando que entradas extras não eram permitidas. O mesmo caminho de formatação também afetava a contagem de tokens por meio de get_num_tokens_from_messages. Uma aplicação poderia falhar antes da geração apenas ao estimar o tamanho da solicitação.

A correção dos blocos de sistema aplica um auxiliar de formatação compartilhado aos blocos de texto do sistema. Ele preserva propriedades aceitas, como type, text, cache_control e citações, enquanto remove metadados não suportados.

Essas mudanças são pequenas em volume de código. Seu efeito operacional é maior porque ambas ocorrem em limites usados repetidamente por aplicações de agentes. Uma protege o estado da resposta durante o streaming, enquanto a outra limpa o estado da aplicação antes da transmissão.

Por Que a Correção da Anthropic no GitHub É Importante para Loops de Agentes

A falha importante era tardia: o LangChain podia aceitar a resposta do Claude, salvá-la e descobrir a corrupção apenas no turno seguinte.

Um chatbot básico pode enviar um prompt e exibir uma resposta. Um loop de agente executa uma sequência mais longa. O modelo escolhe uma ferramenta, a aplicação a executa, e o modelo recebe tanto sua mensagem anterior quanto o resultado da ferramenta.

Esse requisito de reprodução torna a fidelidade das mensagens essencial. A aplicação não pode manter com segurança apenas o texto visível. Ela pode precisar de chamadas de ferramentas estruturadas, blocos de pensamento, assinaturas e metadados específicos do provedor para continuar corretamente a conversa.

As orientações sobre pensamento estendido da Anthropic explicam que blocos de pensamento podem conter assinaturas. Quando esses blocos entram em solicitações posteriores, as aplicações precisam preservar sua estrutura relevante. Portanto, o framework atua como um serializador de estado, não apenas como um encapsulador de texto.

O relatório de bug original incluía uma reprodução determinística que não exigia nenhuma chamada de API ativa. Ele simulava o início de um bloco de pensamento com conteúdo vazio, seguido por um delta de assinatura. O resultado agregado não tinha a chave thinking.

Essa omissão não necessariamente quebrava a primeira resposta transmitida por streaming. O usuário podia receber uma resposta normal, e o agente podia executar a ferramenta selecionada. A falha aparecia quando a próxima solicitação incluía a mensagem anterior malformada.

Esse momento torna o bug mais difícil de diagnosticar. Um desenvolvedor poderia culpar a saída da ferramenta, o segundo prompt ou uma restauração de checkpoint. O defeito real entrava na conversa um turno antes, enquanto o LangChain montava a mensagem transmitida por streaming.

Checkpoints persistentes aumentavam ainda mais a gravidade. Um checkpointer salva o estado do agente para que um fluxo de trabalho possa ser retomado após uma interrupção ou continuar entre processos. Se ele armazena o bloco malformado, reiniciar o worker não repara a conversa.

O agente pode encontrar repetidamente a mesma rejeição porque o objeto inválido permanece em seu histórico. A recuperação pode exigir excluir ou transformar o estado salvo, e não simplesmente repetir a solicitação que falhou.

Considere um agente de programação que pede ao Claude para inspecionar um repositório. O Claude seleciona uma ferramenta de busca, e o framework armazena a mensagem transmitida por streaming do assistente. A ferramenta retorna arquivos correspondentes, mas a chamada de acompanhamento falha antes que o Claude possa analisá-los.

Não há nada errado com a operação de busca. Em vez disso, o agente falha porque o bloco de pensamento reproduzido tem uma assinatura sem o campo thinking vazio. A versão 1.5.3 reconstrói a estrutura exigida para essa segunda chamada.

Um agente de suporte apresenta o mesmo padrão. Ele pode recuperar com sucesso o registro de um cliente e então falhar ao pedir ao Claude que interprete o resultado. O defeito se manifesta como um fluxo de trabalho de negócio instável, embora o modelo e a fonte de dados permaneçam disponíveis.

O problema da mensagem de sistema pode surgir mais cedo. Muitas aplicações constroem instruções de sistema a partir de blocos de conteúdo reutilizáveis. Esses blocos podem carregar identificadores do framework após passarem por APIs comuns do LangChain.

Se a Anthropic rejeitar esses metadados, o modelo nem chega a iniciar a geração. A estimativa de tokens também pode falhar porque usa a mesma lógica de formatação. Assim, o código de planejamento pode parar antes que a aplicação envie sua solicitação de conclusão pretendida.

A correção de streaming da Anthropic e a mudança de sanitização do sistema tratam de direções diferentes de tráfego. O streaming converte eventos do provedor em objetos do LangChain. A formatação de mensagens converte objetos do LangChain de volta em solicitações para o provedor.

Juntas, elas protegem uma viagem de ida e volta. O Claude produz estado estruturado, o LangChain o armazena e a aplicação o devolve posteriormente. A confiabilidade do agente depende de esse ciclo permanecer sem perda quando necessário e restritivo quando exigido.

Um Esquema de Framework Encontra um Limite de Provedor Mais Rigoroso

O LangChain precisa preservar o estado significativo do provedor enquanto remove metadados do framework, e esses objetivos podem conflitar dentro da mesma conversa.

A tensão principal não é entre LangChain e Anthropic. É entre portabilidade e conformidade exata com o esquema. O LangChain oferece abstrações compartilhadas de mensagens, enquanto a Anthropic valida o formato de solicitação esperado por sua API.

Um bloco de conteúdo normalizado pode incluir informações úteis em todo o framework. Desenvolvedores podem anexar identificadores, citações, informações sobre ferramentas ou controles de cache. Os adaptadores de provedores então traduzem essa representação geral para um formato de transmissão mais restrito.

Esse design ajuda aplicações a alternar entre integrações. Uma equipe pode usar padrões de orquestração semelhantes com Claude, modelos da OpenAI ou modelos do Google. Ainda assim, a carga útil final precisa obedecer ao contrato distinto de cada provedor.

A versão 1.5.3 ilustra os dois possíveis erros de adaptadores.

O primeiro erro é filtrar em excesso ou reconstruir de forma incompleta. O LangChain perdeu a presença de um campo vazio porque strings vazias frequentemente parecem equivalentes a valores ausentes na lógica comum de aplicações. O esquema da Anthropic tratava esses estados de maneira diferente.

Um valor thinking vazio comunica que o campo existe e não contém texto. Uma chave ausente comunica que o objeto não atende à estrutura esperada. O conteúdo semântico está vazio, mas a distinção estrutural continua importante.

O segundo erro é filtrar de menos. O LangChain permitiu que um id interno saísse do framework por meio de um bloco de texto do sistema. Esse identificador podia ser válido dentro do LangChain e ainda assim ser inválido no limite da Anthropic.

Portanto, o comportamento correto do adaptador parece assimétrico. Ele precisa manter um campo do provedor aparentemente vazio enquanto exclui um campo do framework aparentemente útil. Uma regra genérica como “remover valores vazios” ou “preservar todos os metadados” falharia em um dos lados.

É por isso que os adaptadores de provedores continuam sendo componentes relevantes de engenharia. Eles fazem mais do que renomear propriedades. Eles conciliam diferentes pressupostos sobre identidade, estado, streaming, validação, ferramentas e reprodução de conversas.

Usuários de SDKs diretos enfrentam menos camadas de tradução porque constroem solicitações com base nos tipos nativos de um único provedor. Essa abordagem mais restrita pode reduzir ambiguidades. Ela também vincula mais lógica da aplicação à representação de uma única API.

Usuários de frameworks ganham composição e portabilidade, mas herdam o risco dos adaptadores. O framework precisa ser atualizado à medida que cada provedor altera modelos, eventos de streaming, tipos de conteúdo e comportamentos de validação.

As integrações da OpenAI e do Google enfrentam pressões relacionadas, mesmo quando os campos exatos diferem. Cada provedor define seus próprios blocos de conteúdo aceitos e regras para mensagens de ferramentas. Uma abstração compartilhada não pode eliminar essas diferenças no limite da rede.

Esta versão não prova que SDKs diretos sejam universalmente mais seguros. Aplicações diretas também podem corromper o histórico ou enviar campos não compatíveis. Ela mostra, porém, que a abstração transfere responsabilidade em vez de eliminá-la.

O LangChain passa a ser responsável por determinar quais detalhes são portáveis e quais são específicos de cada provedor. As aplicações continuam responsáveis por atualizações, testes de regressão, compatibilidade com estados armazenados e observabilidade.

A versão do LangChain para Anthropic também destaca por que erros de schema merecem atenção em produção. Respostas HTTP 400 frequentemente parecem indicar uso incorreto por parte do desenvolvedor. Nesses casos, a aplicação pode usar objetos documentados do framework e ainda assim produzir um payload rejeitado.

Essa distinção afeta a resposta a incidentes. Repetir uma solicitação inválida sem alterar sua estrutura desperdiça tempo e pode ampliar os acúmulos nas filas. O monitoramento deve reter a mensagem de validação do provedor e identificar o índice do bloco de conteúdo afetado.

As equipes também devem distinguir falhas na chamada inicial de falhas de reprodução. Um erro na primeira solicitação aponta para a construção do prompt ou a formatação da mensagem de sistema. Um erro após a execução de uma ferramenta sugere estado armazenado do assistente ou sequenciamento dos resultados de ferramentas.

Essa classificação não substitui a depuração. Ela reduz a área de busca. A versão 1.5.3 oferece aos desenvolvedores dois caminhos concretos de conversão para inspecionar quando solicitações ao Anthropic falharem em torno de mensagens estruturadas.

O Patch É Pontual, e o Estado Existente Continua Sendo o Risco

A atualização evita as transformações documentadas, mas não comprova automaticamente que toda conversa salva seja válida ou que todo caminho de implantação use o novo pacote.

A correção de streaming visa uma sequência específica: um bloco vazio de pensamento adaptativo seguido por dados de assinatura sem um delta de pensamento. Aplicações que nunca ativam o comportamento de pensamento relevante talvez não encontrem esse problema.

A correção da mensagem de sistema também tem um escopo definido. Ela sanitiza blocos de texto dentro de mensagens de sistema e preserva propriedades compatíveis. Blocos de sistema que não são texto passam sem alteração, de acordo com a mudança incorporada.

Esse escopo limitado é adequado para uma versão de patch. Reescritas amplas de mensagens poderiam alterar aplicações funcionais ou remover metadados exigidos por outro caminho. Correções focadas reduzem esse risco de compatibilidade.

No entanto, mudanças de código focadas exigem validação focada. As equipes devem reproduzir seus próprios padrões de mensagem em vez de tratar uma instalação bem-sucedida do pacote como evidência suficiente.

O primeiro teste deve transmitir uma resposta do Claude por streaming em um loop real de agente. O fluxo deve executar pelo menos uma ferramenta e continuar para outra chamada ao modelo. Isso verifica o caminho de reprodução que expôs o defeito no campo de pensamento.

Os desenvolvedores devem inspecionar o conteúdo do assistente montado antes da próxima solicitação. Um bloco de pensamento com uma assinatura deve reter a chave thinking mesmo quando seu valor estiver vazio. Os logs devem evitar expor raciocínio sensível ou dados de usuários.

O segundo teste deve construir uma mensagem de sistema baseada em lista usando os mesmos auxiliares da produção. Ela deve incluir um identificador interno e uma propriedade compatível, como controle de cache. O payload Anthropic enviado deve remover o identificador enquanto retém os dados compatíveis.

A contagem de tokens precisa de sua própria asserção. O relatório sobre mensagens de sistema constatou que get_num_tokens_from_messages compartilhava o formatador defeituoso. Um teste de geração isolado poderia deixar passar falhas em orçamento, roteamento ou validação prévia.

Checkpoints salvos apresentam uma incerteza separada. O pull request incorporado altera como novos eventos de streaming são montados. Ele não afirma migrar todo AIMessage malformado já armazenado por uma aplicação.

Equipes que usam estado persistente de agentes devem amostrar conversas criadas antes da atualização. Elas podem identificar blocos de pensamento que contêm assinaturas, mas omitem thinking. Esses registros podem exigir um reparo controlado ou uma nova conversa.

Qualquer migração deve permanecer conservadora. Adicionar um valor vazio corresponde à correção de bug documentada, mas dados de produção podem conter outras formas de bloco. As equipes devem validar com suas versões exatas de pacote e configurações do provedor.

A resolução de dependências também pode ocultar a atualização. Uma aplicação pode declarar uma faixa ampla de versões enquanto um lockfile mantém a 1.5.2. Outro serviço pode compilar a partir de um lockfile diferente ou de uma camada de contêiner em cache.

A telemetria de execução deve registrar a versão instalada de langchain-anthropic. Essa evidência é mais confiável do que verificar apenas o manifesto de origem. Trabalhadores distribuídos devem informar a mesma versão resolvida antes que os operadores encerrem um incidente.

A página de lançamento informa que a versão 1.5.3 sucedeu a 1.5.2 e incluiu as duas correções listadas. Ela não apresenta benchmarks de desempenho, melhorias de latência ou novas alegações de qualidade do modelo. Os desenvolvedores não devem inferir esses resultados.

Também não há evidência de que essas correções eliminem todos os casos extremos de streaming do Claude. Elas cobrem falhas relatadas com caminhos reproduzíveis. Outras combinações de eventos, tipos de conteúdo ou alterações do provedor ainda exigem testes.

A evidência de teste do patch é encorajadora, mas limitada. O pull request da mensagem de sistema relatou 241 testes unitários aprovados em sua descrição enviada. Posteriormente, o GitHub exibiu um estado de verificação mais amplo durante o processo de merge, o que não deve ser interpretado como validação universal em produção.

A mudança de streaming inclui, de forma semelhante, cobertura de regressão para o campo ausente. Um teste determinístico é valioso porque isola o comportamento do framework sem depender da disponibilidade do provedor. Ainda assim, ele não consegue representar todas as configurações reais de agentes.

A interpretação cética é, portanto, direta. A versão 1.5.3 corrige dois defeitos confirmados, mas a confiabilidade depende de todo o ciclo de vida da mensagem. Camadas de armazenamento, serializadores personalizados, middleware e checkpoints antigos podem reintroduzir estado malformado.

O Que os Desenvolvedores Devem Mudar Após a Correção de Streaming do Anthropic

A resposta mais segura é uma atualização criteriosa seguida de testes de reprodução, mensagem de sistema e checkpoint que correspondam ao tráfego real de produção.

Comece confirmando a versão instalada do pacote em todos os processos que enviam solicitações ao Claude. Verifique o desenvolvimento local, a integração contínua, os workers em segundo plano e os contêineres implantados. Versões mistas podem produzir históricos de conversa inconsistentes.

Em seguida, adicione um caso de regressão para um delta de pensamento que contenha apenas assinatura. O bloco agregado esperado deve incluir thinking: "". Em seguida, o teste deve reproduzir essa mensagem e verificar que a construção do payload seja bem-sucedida.

Esse caso importa mesmo que os modelos atuais raramente emitam essa sequência. Eventos estruturais raros podem dominar a confiabilidade quando agentes são executados continuamente. Um defeito de baixa frequência se torna visível ao longo de milhares de chamadas de ferramentas.

Adicione um segundo teste para blocos de texto de sistema criados pelos auxiliares v1 do LangChain. Inclua um identificador interno de bloco, texto compatível e quaisquer campos de controle de cache usados pela aplicação. Faça asserções sobre o payload final do provedor.

Não pare nos testes unitários. Execute uma conversa de staging por todo o grafo do agente. Inclua streaming, uma chamada de ferramenta, persistência de checkpoint, retomada do processo e outra solicitação ao Claude.

Essa sequência exercita fronteiras em que os dados mudam de responsável. O cliente Anthropic emite eventos, o LangChain os agrega, o checkpoint os salva e um worker posterior os formata novamente.

A observabilidade deve capturar informações estruturais sem registrar conteúdo sensível. Campos úteis incluem tipo de bloco, presença de campos, posição da mensagem, versão do pacote e categoria de erro do provedor. O texto completo de pensamento não deve se tornar parte da rotina de logs da aplicação.

Para respostas HTTP 400, retenha o caminho do campo indicado pelo provedor quando possível. Uma localização como messages.1.content.0 aponta para estado do assistente reproduzido. Uma localização em system.0 aponta para formatação de conteúdo do sistema.

As aplicações devem evitar novas tentativas cegas em falhas de validação de schema. O mesmo payload inválido normalmente falhará outra vez. Uma política de tentativas deve separar erros transitórios de transporte de erros determinísticos de solicitação.

Os responsáveis por checkpoints devem definir uma estratégia de recuperação. Uma opção é invalidar conversas afetadas e recomeçar. Outra é uma migração revisada que restaure o campo vazio ausente em blocos de pensamento identificados com precisão.

A escolha correta depende das necessidades de retenção e dos requisitos de auditoria. Um fluxo de suporte pode precisar preservar seu histórico de conversa. Uma sessão curta de programação pode reiniciar com segurança usando um contexto resumido.

Equipes que avaliam frameworks também devem ajustar seus critérios. O suporte a modelos não é apenas uma lista de classes disponíveis. Ele inclui fidelidade em streaming, ferramentas, reprodução de mensagens, contagem de tokens, cache e persistência.

A integração direta com SDK continua sendo um ponto de comparação útil. Se uma aplicação usa apenas Claude e precisa de controle rigoroso sobre tipos de mensagem nativos, menos traduções podem simplificar a depuração. Essa escolha sacrifica parte da portabilidade e da orquestração oferecidas pelo framework.

Uma integração com LangChain faz mais sentido quando a aplicação se beneficia de interfaces compartilhadas, roteamento de modelos, execução de grafos ou componentes existentes do framework. A versão 1.5.3 não resolve essa decisão. Ela esclarece as obrigações do adaptador que a acompanham.

Três sinais merecem atenção nos próximos meses.

Primeiro, observe novos relatos envolvendo blocos de pensamento, assinaturas ou conversas de ferramentas reproduzidas. Um rastreador de issues silencioso reforçaria a confiança de que a correção de streaming do Anthropic cobre a sequência observada. Falhas relacionadas indicariam problemas mais amplos de reconstrução.

Segundo, observe alterações na normalização de blocos de conteúdo entre provedores do LangChain. O defeito da mensagem de sistema surgiu de uma incompatibilidade entre identificadores internos e schemas do provedor. Mais trabalho compartilhado de sanitização sugeriria que os mantenedores estão tratando o padrão em todas as integrações.

Terceiro, acompanhe a documentação de schema e streaming do Anthropic em busca de alterações no pensamento aceito ou no conteúdo de sistema. A evolução no lado do provedor pode invalidar pressupostos mesmo quando o código do framework permanece inalterado.

Para desenvolvedores que usam hoje a integração Anthropic do GitHub, a medida prática é clara: atualize, verifique a versão resolvida e reproduza um fluxo real de chamadas de ferramentas. Em seguida, inspecione checkpoints antigos antes de presumir que o patch reparou o estado armazenado. Se seus agentes dependem de conversas longas, faça de testes de regressão da forma das mensagens parte de cada atualização de provedor.