Anthropic GitHub risolve due problemi nascosti in LangChain 1.5.3

Le integrazioni Anthropic hanno ricevuto due correzioni mirate quando LangChain ha rilasciato la versione 1.5.3 il 28 luglio 2026. L'aggiornamento Anthropic GitHub affronta errori che potevano interrompere i cicli degli agenti Claude con errori HTTP 400. Nessuna delle due modifiche aggiunge una capacità del modello visibile, ma entrambe proteggono la cronologia dei messaggi da cui dipendono gli agenti.

Una correzione conserva un campo thinking vuoto quando LangChain elabora dati di firma in streaming. Senza quel campo, una risposta Claude valida poteva trasformarsi in un messaggio non valido quando veniva riprodotta durante la chiamata successiva al modello. La seconda correzione rimuove gli identificatori specifici di LangChain dai blocchi di contenuto dei messaggi di sistema prima di inviarli ad Anthropic.

Questa combinazione rende l'intervento più di una patch ordinaria. La release evidenzia un conflitto ricorrente nell'infrastruttura degli agenti: i framework vogliono un formato di messaggio portabile, mentre i fornitori dei modelli applicano schemi API più restrittivi. OpenAI, Google, Anthropic e altri fornitori impongono ciascuno regole diverse al confine finale della richiesta.

LangChain si colloca tra questi formati. Le sue astrazioni aiutano gli sviluppatori a cambiare modelli e a comporre strumenti, ma ogni conversione crea un altro punto in cui uno stato valido può andare perso. La versione 1.5.3 mostra come una stringa vuota mancante o un identificatore in più possano disabilitare un agente altrimenti funzionante.

Cosa cambia in LangChain Anthropic 1.5.3

LangChain Anthropic 1.5.3 corregge due percorsi di conversione dei messaggi che producevano richieste rifiutate dall'API Claude.

Le note di rilascio di Anthropic elencano due correzioni rispetto alla versione 1.5.2. Una riguarda i blocchi di thinking in streaming. L'altra ripulisce il contenuto dei messaggi di sistema prima della trasmissione.

La correzione dello streaming riguarda una sequenza di eventi circoscritta che coinvolge l'adaptive thinking. L'adaptive thinking consente a Claude di determinare quanto ragionamento interno applicare entro i limiti configurati dal fornitore. L'API può restituire contenuto di thinking strutturato e una firma crittografica insieme alla risposta visibile.

Durante lo streaming, questi risultati non arrivano necessariamente come un unico oggetto completo. LangChain riceve più eventi e li combina in un AIMessage, la sua rappresentazione normalizzata di una risposta del modello. Il messaggio assemblato può in seguito diventare parte di un'altra richiesta.

L'errore segnalato si verificava quando un blocco di thinking conteneva una stringa vuota ma riceveva comunque un signature_delta. Un signature delta è un frammento in streaming che trasporta dati di firma per il blocco di thinking. Non seguiva alcun thinking_delta, perché non c'era testo di ragionamento da aggiungere.

LangChain inizialmente scartava lo stato del blocco vuoto. In seguito ricostruiva il blocco dall'evento di firma, producendo un oggetto con i campi type e signature. Tuttavia, mancava la chiave thinking obbligatoria.

Il messaggio poteva apparire innocuo mentre veniva archiviato in un'applicazione. Falliva soltanto quando l'agente riproduceva quella cronologia per Claude. Anthropic rifiutava quindi la richiesta perché il blocco di thinking non disponeva del campo obbligatorio.

La correzione dello streaming usa setdefault("thinking", "") durante la gestione dei signature delta. L'operazione conserva un valore esistente oppure inserisce una stringa vuota quando la chiave manca. In questo modo preserva la forma dell'oggetto attesa dal fornitore senza inventare testo di ragionamento.

La correzione del messaggio di sistema affronta il problema opposto. Invece di perdere un campo obbligatorio, LangChain ne inoltrava uno non supportato.

I blocchi di contenuto LangChain v1 possono includere un id interno. Tale identificatore aiuta il framework a rappresentare e tracciare il contenuto in modo coerente. Lo schema dei messaggi di sistema di Anthropic non accetta lo stesso campo in quella posizione.

Prima della versione 1.5.3, _format_messages poteva inoltrare contenuto SystemMessage basato su liste senza restringere ciascun blocco di testo. Un blocco creato tramite create_text_block() poteva quindi trasportare il proprio identificatore interno nel payload in uscita.

Anthropic rifiutava quella richiesta con un errore che indicava che input aggiuntivi non erano consentiti. Lo stesso percorso di formattazione influiva anche sul conteggio dei token tramite get_num_tokens_from_messages. Un'applicazione poteva fallire prima della generazione mentre stimava semplicemente la dimensione della richiesta.

La correzione dei blocchi di sistema applica un helper di formattazione condiviso ai blocchi di testo di sistema. Mantiene proprietà supportate come type, text, cache_control e le citazioni, rimuovendo al contempo i metadati non supportati.

Queste modifiche sono ridotte in termini di volume di codice. Il loro effetto operativo è maggiore perché entrambe avvengono ai confini usati ripetutamente dalle applicazioni agentiche. Una protegge lo stato della risposta durante lo streaming, mentre l'altra ripulisce lo stato dell'applicazione prima della trasmissione.

Perché la correzione Anthropic GitHub è importante per i cicli degli agenti

L'errore importante era ritardato: LangChain poteva accettare la risposta di Claude, salvarla e scoprire la corruzione soltanto durante il turno successivo.

Un chatbot di base può inviare un prompt e visualizzare una risposta. Un ciclo di agente esegue una sequenza più lunga. Il modello sceglie uno strumento, l'applicazione lo esegue e il modello riceve sia il proprio messaggio precedente sia il risultato dello strumento.

Questo requisito di riproduzione rende fondamentale la fedeltà dei messaggi. L'applicazione non può conservare in sicurezza soltanto la prosa visibile. Potrebbe aver bisogno di chiamate agli strumenti strutturate, blocchi di thinking, firme e metadati specifici del fornitore per continuare correttamente la conversazione.

La guida di Anthropic sull'extended thinking spiega che i blocchi di thinking possono contenere firme. Quando tali blocchi entrano in richieste successive, le applicazioni devono preservarne la struttura rilevante. Il framework agisce quindi come serializzatore dello stato, non soltanto come wrapper di testo.

L'segnalazione originale del bug includeva una riproduzione deterministica che non richiedeva alcuna chiamata API attiva. Simulava l'avvio di un blocco di thinking con contenuto vuoto, seguito da un signature delta. Il risultato aggregato non conteneva la chiave thinking.

Questa omissione non interrompeva necessariamente la prima risposta in streaming. L'utente poteva ricevere una risposta normale e l'agente poteva eseguire lo strumento selezionato. L'errore compariva quando la richiesta successiva includeva il messaggio precedente malformato.

Questa tempistica rende il bug più difficile da diagnosticare. Uno sviluppatore potrebbe attribuire la colpa all'output dello strumento, al secondo prompt o a un ripristino da checkpoint. Il difetto reale era entrato nella conversazione un turno prima, mentre LangChain assemblava il messaggio in streaming.

I checkpoint persistenti aumentavano ulteriormente la posta in gioco. Un checkpointer salva lo stato dell'agente affinché un flusso di lavoro possa riprendere dopo un'interruzione o continuare tra processi diversi. Se archivia il blocco malformato, il riavvio del worker non ripara la conversazione.

L'agente può incontrare ripetutamente lo stesso rifiuto perché l'oggetto non valido resta nella sua cronologia. Il recupero può richiedere l'eliminazione o la trasformazione dello stato salvato, non il semplice nuovo tentativo della richiesta fallita.

Si consideri un agente di coding che chiede a Claude di ispezionare un repository. Claude seleziona uno strumento di ricerca e il framework archivia il messaggio dell'assistente trasmesso in streaming. Lo strumento restituisce file corrispondenti, ma la chiamata successiva fallisce prima che Claude possa analizzarli.

Non c'è nulla di sbagliato nell'operazione di ricerca. L'agente fallisce invece perché il blocco di thinking riprodotto contiene una firma senza il campo thinking vuoto. La versione 1.5.3 ricostruisce la forma richiesta per quella seconda chiamata.

Un agente di assistenza presenta lo stesso schema. Può recuperare correttamente un record cliente, quindi fallire mentre chiede a Claude di interpretare il risultato. Il difetto appare come un flusso di lavoro aziendale instabile anche se il modello e la fonte dati restano disponibili.

Il problema del messaggio di sistema può emergere prima. Molte applicazioni costruiscono istruzioni di sistema da blocchi di contenuto riutilizzabili. Tali blocchi possono contenere identificatori del framework dopo essere passati attraverso comuni API LangChain.

Se Anthropic rifiuta quei metadati, il modello non avvia mai la generazione. Anche la stima dei token può fallire perché usa la stessa logica di formattazione. Il codice di pianificazione può quindi interrompersi prima che l'applicazione invii la richiesta di completamento prevista.

La correzione dello streaming Anthropic e la modifica di sanitizzazione del sistema affrontano direzioni di viaggio diverse. Lo streaming converte gli eventi del fornitore in oggetti LangChain. La formattazione dei messaggi converte gli oggetti LangChain di nuovo in richieste al fornitore.

Insieme, proteggono un viaggio di andata e ritorno. Claude produce uno stato strutturato, LangChain lo archivia e l'applicazione lo restituisce in seguito. L'affidabilità degli agenti dipende dal fatto che questo ciclo resti senza perdite dove necessario e restrittivo dove richiesto.

Uno schema di framework incontra un confine più restrittivo del fornitore

LangChain deve preservare lo stato significativo del fornitore rimuovendo al contempo i metadati del framework, e questi obiettivi possono entrare in conflitto nella stessa conversazione.

La tensione principale non è tra LangChain e Anthropic. È tra portabilità e conformità precisa allo schema. LangChain offre astrazioni di messaggi condivise, mentre Anthropic convalida la forma della richiesta attesa dalla propria API.

Un blocco di contenuto normalizzato può includere informazioni utili in tutto il framework. Gli sviluppatori possono allegare identificatori, citazioni, informazioni sugli strumenti o controlli della cache. Gli adattatori dei fornitori traducono quindi quella rappresentazione generale in un formato wire più ristretto.

Questa progettazione aiuta le applicazioni a passare da un'integrazione all'altra. Un team può usare schemi di orchestrazione simili con Claude, modelli OpenAI o modelli Google. Tuttavia, il payload finale deve comunque rispettare il contratto distinto di ciascun fornitore.

La versione 1.5.3 illustra entrambi i possibili errori dell'adattatore.

Il primo errore è un filtraggio eccessivo o una ricostruzione incompleta. LangChain ha perso la presenza di un campo vuoto perché le stringhe vuote spesso appaiono equivalenti ai valori mancanti nella logica applicativa ordinaria. Lo schema di Anthropic trattava questi stati in modo diverso.

Un valore thinking vuoto comunica che il campo esiste e non contiene testo. Una chiave mancante comunica che l'oggetto non soddisfa la struttura prevista. Il contenuto semantico è vuoto, ma la distinzione strutturale resta importante.

Il secondo errore è un filtraggio insufficiente. LangChain ha consentito a un id interno di uscire dal framework attraverso un blocco di testo di sistema. Quell'identificatore poteva essere valido all'interno di LangChain e restare comunque non valido al confine di Anthropic.

Il comportamento corretto dell'adattatore appare quindi asimmetrico. Deve mantenere un campo del fornitore apparentemente vuoto, eliminando al contempo un campo del framework apparentemente utile. Una regola generica come “rimuovere i valori vuoti” o “preservare tutti i metadati” farebbe fallire uno dei due lati.

Per questo gli adattatori dei fornitori restano componenti di ingegneria sostanziali. Non si limitano a rinominare proprietà. Riconciliano diverse ipotesi su identità, stato, streaming, convalida, strumenti e riproduzione delle conversazioni.

Gli utenti degli SDK diretti affrontano meno livelli di traduzione perché costruiscono le richieste sui tipi nativi di un singolo fornitore. Questo approccio più ristretto può ridurre l'ambiguità. Inoltre lega una maggiore quantità di logica applicativa a una singola rappresentazione API.

Gli utenti dei framework ottengono composizione e portabilità, ma ereditano il rischio degli adattatori. Il framework deve aggiornarsi man mano che ciascun fornitore modifica modelli, eventi di streaming, tipi di contenuto e comportamento di convalida.

Le integrazioni OpenAI e Google affrontano pressioni correlate, anche quando i campi esatti differiscono. Ogni fornitore definisce i propri blocchi di contenuto accettati e le proprie regole per i messaggi degli strumenti. Un'astrazione condivisa non può eliminare queste differenze al confine della rete.

Questa release non dimostra che gli SDK diretti siano universalmente più sicuri. Anche le applicazioni dirette possono corrompere la cronologia o inviare campi non supportati. Dimostra però che l’astrazione sposta la responsabilità invece di eliminarla.

LangChain diventa responsabile di stabilire quali dettagli siano portabili e quali specifici del provider. Le applicazioni restano comunque responsabili di aggiornamenti, test di regressione, compatibilità dello stato archiviato e osservabilità.

La release LangChain Anthropic evidenzia anche perché gli errori di schema meritino attenzione in produzione. Le risposte HTTP 400 spesso sembrano indicare un uso improprio da parte dello sviluppatore. In questi casi, l’applicazione poteva utilizzare oggetti del framework documentati e produrre comunque un payload rifiutato.

Questa distinzione influenza la risposta agli incidenti. Ritentare una richiesta non valida senza modificarne la struttura fa perdere tempo e può amplificare gli arretrati nelle code. Il monitoraggio dovrebbe conservare il messaggio di validazione del provider e identificare l’indice del blocco di contenuto interessato.

I team dovrebbero inoltre distinguere tra errori della chiamata iniziale e errori di replay. Un errore nella prima richiesta indica la costruzione del prompt o la formattazione del messaggio di sistema. Un errore dopo l’esecuzione di uno strumento suggerisce uno stato dell’assistente archiviato o il sequenziamento dei risultati degli strumenti.

Questa classificazione non sostituisce il debugging. Riduce l’area di ricerca. La versione 1.5.3 offre agli sviluppatori due percorsi concreti di conversione da ispezionare quando le richieste Anthropic falliscono in prossimità di messaggi strutturati.

La patch è circoscritta e lo stato esistente resta il rischio

L’aggiornamento previene le trasformazioni documentate, ma non dimostra automaticamente che ogni conversazione salvata sia valida o che ogni percorso di deployment utilizzi il nuovo pacchetto.

La correzione dello streaming riguarda una sequenza specifica: un blocco adaptive-thinking vuoto seguito da dati di firma senza un thinking delta. Le applicazioni che non abilitano il comportamento di thinking pertinente potrebbero non incontrarla.

Anche la correzione del messaggio di sistema ha un ambito definito. Sanifica i blocchi di testo all’interno dei messaggi di sistema e preserva le proprietà supportate. I blocchi di sistema non testuali passano invariati, secondo la modifica unita.

Questo ambito limitato è appropriato per una patch release. Riscritture estese dei messaggi potrebbero modificare applicazioni funzionanti o rimuovere metadati richiesti da un altro percorso. Le correzioni mirate riducono questo rischio di compatibilità.

Tuttavia, modifiche al codice mirate richiedono una validazione mirata. I team dovrebbero riprodurre i propri pattern di messaggio invece di considerare una corretta installazione del pacchetto come prova sufficiente.

Il primo test dovrebbe trasmettere in streaming una risposta Claude attraverso un vero ciclo agente. Il flusso di lavoro dovrebbe eseguire almeno uno strumento e proseguire con un’altra chiamata al modello. Questo verifica il percorso di replay che ha esposto il difetto del campo thinking.

Gli sviluppatori dovrebbero ispezionare il contenuto assemblato dell’assistente prima della richiesta successiva. Un blocco thinking con una firma dovrebbe mantenere la chiave thinking anche quando il suo valore è vuoto. I log devono evitare di esporre ragionamenti sensibili o dati degli utenti.

Il secondo test dovrebbe costruire un messaggio di sistema basato su elenco usando gli stessi helper della produzione. Dovrebbe includere un identificatore interno e una proprietà supportata, come il controllo della cache. Il payload Anthropic in uscita dovrebbe rimuovere l’identificatore mantenendo i dati supportati.

Il conteggio dei token richiede una propria asserzione. Il report sul messaggio di sistema ha rilevato che get_num_tokens_from_messages condivideva il formatter difettoso. Un test di generazione da solo potrebbe non rilevare errori nella definizione del budget, nel routing o nella validazione preliminare.

I checkpoint salvati rappresentano un’incertezza distinta. La pull request unita modifica il modo in cui vengono assemblati i nuovi eventi di streaming. Non afferma di migrare ogni AIMessage malformato già archiviato da un’applicazione.

I team che usano uno stato agente persistente dovrebbero campionare le conversazioni create prima dell’aggiornamento. Possono identificare blocchi thinking che contengono firme ma omettono thinking. Questi record potrebbero richiedere una riparazione controllata o una nuova conversazione.

Qualsiasi migrazione dovrebbe restare conservativa. L’aggiunta di un valore vuoto corrisponde alla correzione documentata del bug, ma i dati di produzione possono contenere altre forme di blocchi. I team dovrebbero validare rispetto alle proprie versioni esatte dei pacchetti e alle impostazioni del provider.

Anche la risoluzione delle dipendenze può occultare l’aggiornamento. Un’applicazione può dichiarare un intervallo di versioni ampio mentre un lockfile mantiene la 1.5.2. Un altro servizio può essere compilato da un lockfile diverso o da un livello di container memorizzato nella cache.

La telemetria di runtime dovrebbe registrare la versione installata di langchain-anthropic. Questa evidenza è più affidabile del controllo del solo manifest sorgente. I worker distribuiti dovrebbero segnalare la stessa versione risolta prima che gli operatori chiudano un incidente.

La pagina della release afferma che la versione 1.5.3 ha seguito la 1.5.2 e includeva le due correzioni elencate. Non presenta benchmark sulle prestazioni, miglioramenti della latenza o nuove dichiarazioni sulla qualità dei modelli. Gli sviluppatori non dovrebbero inferire tali risultati.

Non vi sono inoltre prove che queste correzioni eliminino ogni caso limite dello streaming Claude. Coprono errori segnalati con percorsi riproducibili. Altre combinazioni di eventi, tipi di contenuto o modifiche del provider richiedono comunque test.

Le evidenze dei test della patch sono incoraggianti ma limitate. La pull request sul messaggio di sistema ha riportato 241 test unitari superati nella descrizione inviata. GitHub ha successivamente mostrato uno stato dei controlli più ampio durante il processo di merge, che non dovrebbe essere interpretato come validazione universale in produzione.

La modifica dello streaming include analogamente una copertura di regressione per il campo mancante. Un test deterministico è prezioso perché isola il comportamento del framework senza dipendere dalla disponibilità del provider. Non può comunque rappresentare ogni configurazione di agente reale.

La lettura scettica è quindi semplice. La versione 1.5.3 corregge due difetti confermati, ma l’affidabilità dipende dall’intero ciclo di vita dei messaggi. Livelli di archiviazione, serializzatori personalizzati, middleware e checkpoint precedenti possono reintrodurre uno stato malformato.

Cosa dovrebbero modificare gli sviluppatori dopo la correzione dello streaming Anthropic

La risposta più sicura è un aggiornamento misurato, seguito da test di replay, messaggi di sistema e checkpoint che riflettano il traffico reale di produzione.

Iniziate confermando la versione del pacchetto installata in ogni processo che invia richieste Claude. Controllate lo sviluppo locale, l’integrazione continua, i worker in background e i container distribuiti. Versioni miste possono produrre cronologie delle conversazioni incoerenti.

Successivamente, aggiungete un caso di regressione per un thinking delta con sola firma. Il blocco aggregato previsto deve includere thinking: "". Il test dovrebbe quindi riprodurre quel messaggio e verificare che la costruzione del payload riesca.

Questo caso è importante anche se i modelli attuali emettono raramente la sequenza. Eventi strutturali rari possono dominare l’affidabilità quando gli agenti operano continuamente. Un difetto a bassa frequenza diventa visibile su migliaia di chiamate a strumenti.

Aggiungete un secondo test per i blocchi di testo di sistema creati tramite gli helper v1 di LangChain. Includete un identificatore interno del blocco, testo supportato ed eventuali campi di controllo della cache usati dall’applicazione. Verificate il payload finale del provider.

Non fermatevi ai test unitari. Eseguite una conversazione di staging attraverso l’intero grafo agente. Includete streaming, una chiamata a uno strumento, persistenza del checkpoint, ripresa del processo e un’altra richiesta Claude.

Questa sequenza esercita i confini in cui i dati cambiano proprietario. Il client Anthropic emette eventi, LangChain li aggrega, il checkpoint li salva e un worker successivo li formatta nuovamente.

L’osservabilità dovrebbe acquisire informazioni strutturali senza registrare contenuti sensibili. I campi utili includono tipo di blocco, presenza dei campi, posizione del messaggio, versione del pacchetto e categoria di errore del provider. Il testo thinking completo non dovrebbe diventare logging applicativo ordinario.

Per le risposte HTTP 400, conservate il percorso del campo del provider quando possibile. Una posizione come messages.1.content.0 indirizza verso lo stato dell’assistente riprodotto. Una posizione sotto system.0 indirizza verso la formattazione del contenuto di sistema.

Le applicazioni dovrebbero evitare tentativi ciechi per errori di validazione dello schema. Lo stesso payload non valido normalmente fallirà di nuovo. Una politica di retry dovrebbe separare gli errori transitori di trasporto dagli errori deterministici della richiesta.

I responsabili dei checkpoint dovrebbero definire una strategia di recupero. Un’opzione è invalidare le conversazioni interessate e ricominciare da zero. Un’altra è una migrazione esaminata che ripristini il campo vuoto assente in blocchi thinking identificati con precisione.

La scelta corretta dipende dalle esigenze di conservazione e dai requisiti di audit. Un flusso di supporto potrebbe dover preservare la traccia della conversazione. Una sessione di coding di breve durata può riavviarsi in sicurezza con un contesto riassunto.

I team che valutano framework dovrebbero inoltre adeguare i propri criteri. Il supporto dei modelli non è soltanto una checklist di classi disponibili. Include fedeltà attraverso streaming, strumenti, replay dei messaggi, conteggio dei token, caching e persistenza.

L’integrazione diretta tramite SDK resta un utile punto di confronto. Se un’applicazione usa solo Claude e necessita di un controllo rigoroso sui tipi di messaggio nativi, un numero inferiore di traduzioni può semplificare il debugging. Questa scelta sacrifica parte della portabilità e dell’orchestrazione a livello di framework.

Un’integrazione LangChain ha più senso quando l’applicazione beneficia di interfacce condivise, routing dei modelli, esecuzione di grafi o componenti del framework esistenti. La versione 1.5.3 non risolve questa decisione. Chiarisce gli obblighi dell’adattatore che ne derivano.

Tre segnali meritano attenzione nei prossimi mesi.

Primo, osservate nuove segnalazioni che coinvolgono blocchi thinking, firme o conversazioni con strumenti riprodotte. Un issue tracker silenzioso rafforzerebbe la fiducia che la correzione dello streaming anthropic copra la sequenza osservata. Errori correlati indicherebbero problemi più ampi di ricostruzione.

Secondo, osservate le modifiche alla normalizzazione cross-provider dei blocchi di contenuto di LangChain. Il difetto del messaggio di sistema derivava da una discrepanza tra identificatori interni e schemi del provider. Ulteriori interventi di sanificazione condivisa suggerirebbero che i manutentori stanno affrontando il problema in tutte le integrazioni.

Terzo, osservate la documentazione di Anthropic relativa a schema e streaming per modifiche al thinking o ai contenuti di sistema accettati. L’evoluzione lato provider può invalidare le supposizioni anche quando il codice del framework rimane invariato.

Per gli sviluppatori che usano oggi l’integrazione GitHub di Anthropic, la mossa pratica è chiara: aggiornare, verificare la versione risolta e riprodurre un vero flusso di lavoro con chiamate a strumenti. Quindi ispezionare i vecchi checkpoint prima di presumere che la patch abbia riparato lo stato archiviato. Se i vostri agenti dipendono da conversazioni lunghe, rendete i test di regressione sulla forma dei messaggi parte di ogni aggiornamento del provider.