LangChain langchain==1.4.3 corregge i percorsi di errore che gli agenti non possono ignorare

LangChain ha rilasciato langchain==1.4.3 con sette modifiche, incluse correzioni per il fallback dei modelli, l'output strutturato e le chiamate agli strumenti malformate. La patch aggiunge inoltre il supporto per Bedrock Mantle all'inizializzatore dei modelli del framework. Questa combinazione rende la release più rilevante di quanto suggerisca il suo numero di patch.

Il conflitto centrale è tra affidabilità e astrazione. LangChain consente agli sviluppatori di collocare un'unica interfaccia per agenti sopra modelli e provider diversi. Tuttavia, impostazioni specifiche dei provider, formati di risposta e regole sui messaggi continuano a emergere attraverso quell'interfaccia.

La versione 1.4.3 affronta diversi punti in cui tali differenze potevano bloccare un agente dopo il deployment. La release ufficiale è arrivata il 28 settembre 2026, un giorno dopo che due resoconti successivi avevano messo in dubbio una precedente correzione delle chiamate agli strumenti.

L'aggiornamento non introduce una nuova architettura per gli agenti. Rafforza il livello di traduzione tra il codice degli agenti e il comportamento mutevole dei provider. Per i team che gestiscono agenti su endpoint compatibili con OpenAI, Amazon Bedrock, Anthropic, Fireworks o Azure OpenAI, questo livello determina spesso se il fallback funziona davvero.

Cosa cambia in langchain==1.4.3

La release si concentra sui guasti che emergono quando gli agenti attraversano i confini tra provider o riproducono una cronologia di conversazione imperfetta.

Le note di rilascio di LangChain elencano sette pull request dalla versione 1.4.2. Quattro incidono direttamente sul comportamento dei modelli o degli agenti. Le modifiche rimanenti aggiornano la documentazione, rimuovono codice commentato e aggiornano una dipendenza bloccata.

La prima correzione di comportamento ripulisce le impostazioni del modello relative alla cache durante il fallback. Un fallback si verifica quando un agente passa dal modello preferito a un altro modello dopo un errore o un problema di disponibilità.

Prima di questa correzione, le impostazioni destinate al primo provider potevano accompagnare la richiesta. Il provider di fallback poteva rifiutare quelle impostazioni sconosciute invece di completare la richiesta. Ciò trasforma una funzionalità di resilienza in un ulteriore punto di errore.

La seconda modifica principale registra due provider Amazon Bedrock Mantle con init_chat_model. Questa funzione offre alle applicazioni un punto di ingresso comune per creare integrazioni con modelli di chat.

Gli sviluppatori possono ora identificare bedrock_mantle_openai o bedrock_mantle_anthropic come provider. LangChain connette quindi la richiesta alle classi corrispondenti fornite da langchain-aws.

La terza modifica adegua il modo in cui gli agenti selezionano l'output strutturato per GPT-6 Sol, Luna e Astra. Per output strutturato si intende che il modello restituisce dati conformi a uno schema atteso anziché testo libero senza vincoli.

Quando i profili dei modelli non erano disponibili, LangChain poteva in precedenza instradare questi modelli attraverso una strategia basata sugli strumenti. Questo percorso poteva entrare in un ciclo o fallire su Bedrock. La versione 1.4.3 riconosce i nomi dei modelli e seleziona per impostazione predefinita l'output strutturato nativo del provider.

La quarta modifica di comportamento corregge le chiamate agli strumenti malformate conservate nella cronologia dell'agente. Le chiamate agli strumenti sono richieste generate dal modello affinché un'applicazione esegua una funzione, recuperi dati o intraprenda un'altra azione definita.

Alcuni provider richiedono che ogni chiamata agli strumenti identificabile abbia un messaggio di risultato corrispondente. Una chiamata malformata senza quel risultato può rendere non valida una riproduzione successiva, anche quando il turno originale è già terminato.

LangChain ora aggiunge un risultato di errore per le chiamate non valide identificabili, preservando al contempo i risultati validi associati tramite ID della chiamata allo strumento. La correzione si applica ai messaggi correnti e storici e non chiede al modello di ripetere la chiamata.

La release modifica inoltre la versione bloccata di AnyIO dalla 4.11.0 alla 4.14.2. AnyIO fornisce compatibilità asincrona tra implementazioni Python del ciclo di eventi. Le note di rilascio descrivono questa modifica come un aggiornamento di dipendenza, non come una nuova capacità di runtime.

Una correzione alla documentazione aggiorna le indicazioni per la configurazione del repository e i dettagli dei pacchetti. Un'altra modifica di manutenzione rimuove un extra Cohere commentato. Nessuna delle due dovrebbe alterare il comportamento dell'applicazione.

Nel complesso, queste modifiche rendono la versione 1.4.3 una release di compatibilità. Espande un percorso per provider rafforzando al contempo tre percorsi di errore che incidono sulla continuità degli agenti.

Il fallback dei modelli ora rimuove le impostazioni di cache incompatibili

Il fallback migliora la disponibilità soltanto quando il secondo modello riceve una richiesta che può comprendere.

A livello di policy, il fallback dei modelli sembra semplice. Un'applicazione sceglie un modello primario, identifica una o più alternative e procede lungo quell'elenco quando una richiesta fallisce.

La richiesta effettiva contiene più dei messaggi. Può includere chiavi della cache, intestazioni personalizzate, istruzioni sul formato di risposta, definizioni degli strumenti, timeout e opzioni specifiche del provider.

Tali impostazioni creano un problema nascosto di compatibilità. Un parametro di cache accettato da un provider può risultare privo di significato o non valido per un altro. Trasmetterlo senza modifiche può far fallire la richiesta di fallback prima che il modello alternativo produca un token.

La correzione della cache nel fallback riguarda due impostazioni. Rimuove x-session-affinity quando il fallback non utilizza Fireworks. Rimuove inoltre prompt_cache_key al di fuori di Fireworks, OpenAI e Azure OpenAI.

L'affinità di sessione indirizza richieste correlate verso la stessa posizione di servizio, il che può migliorare il riutilizzo della cache. Questo comportamento dipende dall'infrastruttura del provider e non può essere dato per scontato tra endpoint diversi.

Allo stesso modo, una chiave di cache del prompt aiuta i provider supportati ad associare le richieste a materiale del prompt memorizzato nella cache. Non è un campo universale in tutte le API dei modelli.

Il middleware conserva tali impostazioni quando il fallback selezionato le supporta. Mantiene inoltre intatte le configurazioni e le intestazioni non correlate, inclusa la gestione esistente dei marcatori di cache Anthropic.

Questa distinzione conta. Rimuovere ogni impostazione opzionale eviterebbe alcuni errori di compatibilità, ma eliminerebbe anche comportamenti utili sui provider che supportano tali impostazioni.

L'implementazione utilizza invece _llm_type del modello di fallback per decidere cosa debba rimanere. Crea impostazioni ripulite per la chiamata di fallback senza modificare la richiesta originale.

Questo design protegge l'elaborazione successiva. Se un oggetto richiesta è condiviso tra middleware o viene ritentato attraverso un altro percorso, un tentativo di fallback non dovrebbe cancellarne permanentemente la configurazione.

La pull request include copertura sincrona e asincrona. I test verificano la pulizia delle intestazioni, la rimozione delle chiavi di cache non supportate e la conservazione delle impostazioni quando il provider di fallback le accetta.

Si tratta di una correzione circoscritta con un'ampia lezione operativa. Il fallback tra provider diversi non è semplicemente un elenco di nomi di modelli. È un problema di traduzione che coinvolge ogni campo allegato alla richiesta.

I team dovrebbero comunque testare ogni coppia ordinata di provider che distribuiscono. Un percorso riuscito da OpenAI ad Azure non convalida il comportamento da OpenAI ad Anthropic o da Fireworks a Bedrock.

La patch ripulisce soltanto le impostazioni affrontate dalla pull request. Altri parametri specifici dei provider possono ancora creare incompatibilità con l'evolversi delle API dei modelli.

I team applicativi dovrebbero quindi monitorare il completamento del fallback separatamente dal successo del modello primario. Una dashboard che combina entrambi i percorsi può nascondere un sistema di fallback che non raggiunge mai una risposta utilizzabile.

Dovrebbero inoltre registrare quale modello ha infine servito ciascuna richiesta. Senza questo segnale, un team non può collegare cambiamenti nell'output o una latenza elevata a una transizione di provider.

Il test più rivelatore non è se il middleware intercetta un'eccezione forzata. È se l'intera richiesta a valle riesce con le impostazioni esatte utilizzate in produzione.

Ciò include output strutturato, strumenti, caching e cronologia dei messaggi. La versione 1.4.3 rimuove due trappole note, ma non rende tutti i provider intercambiabili.

Bedrock Mantle entra nel punto di ingresso comune dei modelli di LangChain

LangChain ora espone Bedrock Mantle tramite il suo inizializzatore condiviso, ma le applicazioni devono identificare esplicitamente il provider.

La nuova integrazione aggiunge bedrock_mantle_openai e bedrock_mantle_anthropic ai provider riconosciuti da init_chat_model. Questi nomi si collegano a ChatOpenAIMantle e ChatAnthropicMantle.

Entrambe le classi risiedono in langchain-aws, non nel pacchetto LangChain principale. L'integrazione Mantle richiede langchain-aws versione 1.7.9 o successiva in fase di runtime.

Secondo la pull request integrata, le classi risolvono autonomamente l'endpoint Mantle regionale. Possono inoltre gestire una chiave API Bedrock, la variabile d'ambiente AWS_BEARER_TOKEN_BEDROCK o credenziali temporanee derivate dalle credenziali AWS standard.

Questo mantiene le funzioni factory personalizzate fuori dalla configurazione normale. Gli sviluppatori possono utilizzare lo stesso inizializzatore di alto livello che instrada già gli altri provider.

Tuttavia, l'inferenza basata sul nome rimane deliberatamente limitata. LangChain continua ad associare gli identificatori dei modelli che iniziano con anthropic.* al provider Bedrock esistente.

Gli identificatori OpenAI ospitati su Bedrock che iniziano con openai.* non selezionano automaticamente Mantle. Gli sviluppatori devono fornire il nome del provider Mantle o un prefisso di provider esplicito.

I manutentori hanno evitato di modificare l'inferenza esistente perché ciò avrebbe reindirizzato silenziosamente le applicazioni verso un endpoint diverso. Preservare il comportamento attuale riduce il rischio di aggiornamento per i team che già utilizzano integrazioni Bedrock.

Questo crea un compromesso ragionevole. La configurazione esplicita aggiunge un piccolo requisito di configurazione, ma impedisce che una patch release cambi la destinazione delle richieste per carichi di lavoro consolidati.

Anche l'installazione delle dipendenze merita un'attenzione analoga. La discussione della pull request ha stabilito l'uso di extra combinati per la famiglia di modelli impiegata.

Le combinazioni documentate sono langchain[aws,openai] per i modelli Mantle compatibili con OpenAI e langchain[aws,anthropic] per i modelli compatibili con Anthropic. Questo approccio mantiene più leggero l'extra AWS generale.

La discussione registra inoltre una preoccupazione residua sulle dipendenze in langchain-aws. Le chiavi temporanee derivate dalle credenziali possono importare in modo lazy un pacchetto aggiuntivo per la generazione di token durante il rinnovo.

Ciò significa che un test di importazione o avvio riuscito potrebbe non coprire ogni percorso di autenticazione. I team che utilizzano credenziali temporanee dovrebbero esercitare il comportamento di rinnovo durante lo staging, non soltanto la prima richiesta.

La pressione più ampia ricade sui manutentori dei framework piuttosto che su una singola azienda concorrente. Le piattaforme cloud espongono sempre più spesso i modelli attraverso diverse famiglie di API, sistemi di credenziali ed endpoint regionali.

Un inizializzatore comune deve nascondere abbastanza variabilità da ridurre il codice applicativo. Deve anche esporre abbastanza variabilità da evitare scelte automatiche fuorvianti.

La decisione di LangChain favorisce l'instradamento esplicito al confine del provider. È più sicuro che indovinare quando prefissi identici di famiglie di modelli possono raggiungere servizi Bedrock distinti.

Per gli sviluppatori, il vantaggio pratico è una costruzione coerente. Un'applicazione può selezionare un modello supportato da Mantle tramite configurazione senza creare una funzione factory separata.

Il limite è altrettanto importante. Una costruzione comune non garantisce un comportamento identico tra provider. Autenticazione, parametri supportati, eventi di streaming, chiamate agli strumenti e output strutturato possono ancora differire.

I team che adottano il nuovo percorso dovrebbero testare il loro effettivo carico di lavoro degli agenti. Un prompt di base conferma la connettività, ma non convalida l'esecuzione degli strumenti, l'applicazione dello schema, il fallback o il rinnovo delle credenziali.

Questa release rende più semplice adottare Mantle. La preparazione alla produzione dipende ancora dalla verifica del ciclo di vita completo della richiesta.

L'output strutturato di GPT-6 si allontana dall'emulazione tramite strumenti

La correzione per GPT-6 sceglie la gestione nativa dello schema quando mancano i metadati del profilo del modello, riducendo la dipendenza da chiamate strumento sintetiche.

I framework per agenti necessitano di una strategia per convertire l'output del modello in dati applicativi tipizzati. Un approccio chiede al provider un output strutturato nativo. Un altro rappresenta lo schema desiderato come uno strumento richiamabile.

La strategia basata sugli strumenti può funzionare su modelli privi di controlli nativi dello schema. Aggiunge però un ulteriore livello di protocollo, inclusi selezione dello strumento, generazione degli argomenti, gestione dei risultati e riproduzione della conversazione.

LangChain usa generalmente i profili dei modelli per determinare quale strategia supporti un modello. Un profilo del modello è costituito da metadati che descrivono capacità quali l'output strutturato nativo.

Il problema si presenta quando tali metadati mancano. LangChain deve prendere una decisione di fallback basandosi sull'identificatore del modello o su altre informazioni disponibili.

Per GPT-6 Sol, Luna e Astra, il fallback precedente selezionava l'output strutturato basato su strumenti. La correzione GPT-6 afferma che questo percorso poteva entrare in un ciclo o fallire su Bedrock.

La versione 1.4.3 aggiunge questi identificatori di modello all'elenco di fallback per l'output nativo. Secondo i test associati, riconosce sia i nomi senza prefisso sia le forme con prefisso Bedrock.

L'effetto è specifico. Gli agenti che usano queste varianti GPT-6 senza profili ora scelgono per impostazione predefinita l'output strutturato nativo del provider.

Questo non significa che ogni modello riceva lo stesso trattamento. Si tratta di una regola di compatibilità per modelli identificati la cui capacità prevista è già nota.

La modifica mostra anche perché i metadati delle capacità siano diventati un'infrastruttura critica. I soli nomi dei modelli spesso forniscono una descrizione incompleta del comportamento dell'endpoint.

Un provider può ospitare un modello attraverso più interfacce. Queste interfacce possono esporre funzionalità di schema, campi accettati o semantiche degli errori differenti.

Un sistema basato sui profili offre ai framework un punto centrale per descrivere tale variazione. Tuttavia, le applicazioni hanno comunque bisogno di un comportamento ragionevole quando i profili sono assenti, ritardati o non disponibili.

L'elenco di fallback di LangChain colma questa lacuna. Il punto debole è la manutenzione: ogni nuova famiglia di modelli supportata deve essere riconosciuta con precisione e aggiornata al variare del comportamento del provider.

I falsi negativi indirizzano un modello capace verso un'emulazione degli strumenti non necessaria. I falsi positivi possono richiedere output nativo a un endpoint che non lo implementa correttamente.

La correzione attuale dà priorità a un caso di errore noto. Rimuove un percorso problematico per i modelli GPT-6 indicati senza ridefinire la selezione dell'output strutturato nell'intero framework.

Gli sviluppatori dovrebbero comunque convalidare schemi simili ai propri contratti di produzione. Oggetti annidati, unioni, campi facoltativi ed enumerazioni lunghe possono rivelare differenze che un piccolo esempio non evidenzia.

Dovrebbero inoltre esaminare separatamente gli errori di convalida e quelli del provider. Una richiesta di output strutturato accettata può comunque restituire dati che non superano lo schema dell'applicazione.

I retry necessitano di limiti accurati. Un errore di schema che attiva un'altra richiesta identica può produrre un ciclo costoso, soprattutto quando il framework classifica erroneamente le capacità dell'endpoint.

L'implementazione più sicura confronta tre risultati: accettazione da parte del provider, convalida dello schema e uso a valle. Il superamento del solo primo passaggio non dimostra un output strutturato affidabile.

Questa release riduce l'emulazione non necessaria degli strumenti per modelli specifici. Rafforza inoltre il valore di profili accurati mentre i cataloghi di modelli continuano ad ampliarsi.

Le chiamate strumento non valide espongono il problema più difficile dello stato degli agenti

La riparazione di LangChain preserva una cronologia riproducibile, ma le segnalazioni successive mostrano che la normalizzazione dei messaggi resta sensibile alle regole dei provider.

Una conversazione di un agente è più di una trascrizione. È una macchina a stati in cui le richieste di strumenti dell'assistente e i risultati degli strumenti devono formare coppie valide.

Una chiamata strumento malformata può interrompere quella sequenza. Il modello potrebbe produrre argomenti non validi, omettere identificatori obbligatori o restituire una struttura che il framework non riesce ad analizzare.

Se il framework memorizza quella chiamata senza un risultato corrispondente, le richieste successive possono fallire quando il provider convalida la cronologia riprodotta. L'errore può comparire diversi turni dopo il difetto originale.

La riparazione delle chiamate strumento di LangChain aggiunge un ToolMessage di errore per ogni chiamata strumento non valida identificabile. Controlla inoltre le chiamate storiche durante la ricostruzione dello stato dei messaggi.

La riparazione conserva i risultati esistenti associandoli ai rispettivi ID delle chiamate strumento. Non ritenta la richiesta malformata, evitando di chiedere al modello di ripetere automaticamente un'azione.

Questo comportamento supporta un importante obiettivo di recupero. La conversazione può registrare che l'azione dello strumento richiesta non è riuscita, mantenendo al contempo utilizzabile la cronologia circostante.

Senza tale registrazione, potrebbe diventare impossibile riprendere un agente. Le applicazioni dovrebbero scartare la cronologia, riscrivere manualmente i messaggi o avviare una nuova conversazione.

La difficoltà è che i provider non interpretano in modo identico le relazioni tra messaggi degli strumenti. Una riparazione valida secondo un protocollo di messaggistica può violare le regole di ordinamento più rigide di un altro provider.

La cronologia della pull request rende visibile questa incertezza. Il 27 settembre, gli utenti hanno aperto segnalazioni successive riguardanti thread Anthropic e risultati degli strumenti riparati.

Una segnalazione sosteneva che un tool_result generato mancasse di un tool_use corrispondente, causando un errore del provider dopo una chiamata non valida. Un'altra proponeva di mantenere le chiamate riparate con un elemento padre in ogni payload.

Tali segnalazioni sono state chiuse prima della pubblicazione della versione 1.4.3 e la riparazione è rimasta nella release. Tuttavia, la loro presenza costituisce un utile avvertimento a non considerare risolta la normalizzazione dei messaggi.

La pull request ha ricevuto anche un avviso sulle prestazioni durante lo sviluppo. Un benchmark registrato mostrava che il tempo di istanziazione dell'agente passava da 4,5 millisecondi a 5,4 millisecondi, una regressione del 16,62 percento.

Questa cifra proveniva da un confronto intermedio e non dovrebbe essere considerata un benchmark indipendente della release finale. Identifica un'area che vale la pena testare, non un impatto di produzione confermato.

Per la maggior parte degli agenti distribuiti, la latenza del provider sarà molto superiore a una differenza di un millisecondo nella costruzione. I servizi ad alta velocità che costruiscono ripetutamente agenti possono avere un profilo di costo diverso.

I team dovrebbero misurare il pacchetto finale all'interno del proprio processo. Il risultato dipende dai modelli di inizializzazione, dal middleware, dagli strumenti, dalla configurazione del modello e dal riuso degli oggetti.

La correttezza resta il problema principale. Una cronologia riparata deve soddisfare il provider rappresentando accuratamente ciò che è accaduto.

Un risultato di errore non dovrebbe implicare che sia stata eseguita un'azione esterna. Dovrebbe inoltre evitare di indurre l'agente a presumere il successo durante il ragionamento successivo.

Le applicazioni con strumenti dalle conseguenze rilevanti dovrebbero conservare registri di esecuzione separati, esterni all'elenco dei messaggi conversazionali. La cronologia rivolta al modello non è una pista di audit sufficiente.

Tali registri dovrebbero includere lo strumento richiesto, gli argomenti convalidati, lo stato di esecuzione, i dati restituiti e gli eventuali effetti collaterali. Aiutano inoltre i team a ricostruire i guasti senza fare affidamento su testo generato.

I team di ingegneria possono sostenere questo lavoro con una raccolta ricercabile di documenti tecnici locali. Runbook, schemi e note sugli incidenti diventano particolarmente preziosi quando gli errori del provider emergono dopo una riproduzione ritardata.

La lezione più profonda è che la durabilità degli agenti dipende dalla riparazione dello stato. Modelli migliori non eliminano la necessità di normalizzare messaggi malformati, preservare la causalità e distinguere le azioni tentate da quelle completate.

La versione 1.4.3 migliora questo percorso di riparazione. La discussione successiva mostra perché gli sviluppatori dovrebbero testarlo con ogni provider rispetto al quale intendono riprodurre le conversazioni.

Cosa dovrebbero monitorare gli sviluppatori dopo la release

Le prossime evidenze dovrebbero provenire da carichi di lavoro cross-provider, profili dei modelli aggiornati e test di riproduzione costruiti attorno a errori reali.

Il primo segnale è il completamento del fallback tra provider misti. I team dovrebbero testare modelli primari e di fallback con impostazioni di cache, strumenti, streaming e output strutturato abilitati contemporaneamente.

Se queste richieste vengono completate senza pulizia manuale per provider, la nuova logica di sanitizzazione sta svolgendo il proprio lavoro. Nuovi parametri rifiutati indebolirebbero l'ipotesi che il filtro attuale sia sufficientemente ampio.

Il secondo segnale è il comportamento di Bedrock Mantle con autenticazione prolungata. Un test di avvio non può esercitare l'aggiornamento delle credenziali temporanee, i worker di lunga durata o i cambiamenti degli endpoint regionali.

Un aggiornamento riuscito con entrambe le famiglie di modelli supportate rafforzerebbe il caso d'integrazione. Errori di dipendenza durante l'aggiornamento rivelerebbero che le istruzioni di installazione necessitano ancora di lavoro.

Il terzo segnale è la portabilità della cronologia riparata. Gli sviluppatori dovrebbero riprodurre cronologie di chiamate strumento malformate e parzialmente riparate attraverso ogni provider usato in produzione.

Un risultato positivo significa che l'agente riprende senza scartare il contesto né inventare il successo dello strumento. Errori di convalida specifici del provider mostrerebbero che una strategia di riparazione condivisa necessita di ulteriore specializzazione.

I team che aggiornano dalla versione 1.4.2 dovrebbero iniziare con test di regressione anziché con un'ampia distribuzione in produzione. I casi più preziosi sono le cronologie e le configurazioni delle richieste che in precedenza fallivano.

Fissate langchain-aws a una versione compatibile quando usate Mantle, quindi verificate gli extra necessari in un ambiente pulito. Le macchine di sviluppo esistenti possono nascondere dipendenze mancanti tramite installazioni non correlate.

Per l'output strutturato GPT-6, ispezionate la strategia selezionata e convalidate schemi realistici. Non presumete che un semplice oggetto completato con successo copra risposte di produzione annidate.

Per il fallback del modello, registrate il modello selezionato e le categorie di richieste sanitizzate. Evitate di registrare segreti, credenziali grezze o contenuti riservati dei prompt.

Per la riparazione delle chiamate strumento, acquisite le chiamate malformate come fixture di test dopo aver rimosso i dati sensibili. Queste fixture possono proteggere dalle regressioni quando cambiano provider o versioni del framework.

Nessuna di queste modifiche elimina la necessità di controlli a livello applicativo. Timeout, retry limitati, chiavi di idempotenza, registri di esecuzione e revisione umana restano necessari per le azioni dalle conseguenze rilevanti.

La release migliora invece il comportamento del framework quando le differenze tra provider raggiungono il livello dell'agente. Questo è prezioso perché tali differenze stanno diventando più comuni, non meno.

langchain==1.4.3 va quindi interpretato soprattutto come una patch di affidabilità con una significativa aggiunta di integrazione. La sua importanza risiede nelle situazioni che cerca di preservare: fallback, generazione di schemi, riproduzione della conversazione e routing del provider.

Se i vostri agenti usano questi percorsi, riproducete i guasti prima dell'aggiornamento e rieseguiteli successivamente. Poi testate il flusso di lavoro combinato, perché i guasti in produzione raramente rispettano i confini tra le singole correzioni.