Anthropic GitHub corrige dos fallos ocultos en LangChain 1.5.3

Las integraciones de Anthropic incorporaron dos correcciones específicas cuando LangChain lanzó la versión 1.5.3 el 28 de julio de 2026. La actualización de Anthropic GitHub aborda fallos que podían detener bucles de agentes Claude con errores HTTP 400. Ninguno de los cambios añade una capacidad visible al modelo, pero ambos protegen el historial de mensajes del que dependen los agentes.

Una corrección conserva un campo thinking vacío cuando LangChain procesa datos de firma transmitidos por streaming. Sin ese campo, una respuesta válida de Claude podía convertirse en un mensaje no válido al reproducirse durante la siguiente llamada al modelo. La segunda corrección elimina identificadores exclusivos de LangChain de los bloques de contenido de mensajes del sistema antes de enviarlos a Anthropic.

Esta combinación hace que sea más que un parche rutinario. La versión pone de manifiesto un conflicto recurrente en la infraestructura de agentes: los frameworks buscan un formato de mensaje portable, mientras que los proveedores de modelos imponen esquemas de API más restringidos. OpenAI, Google, Anthropic y otros proveedores aplican reglas diferentes en el límite final de la solicitud.

LangChain se sitúa entre esos formatos. Sus abstracciones ayudan a los desarrolladores a cambiar de modelo y componer herramientas, pero cada conversión crea otro punto donde puede perderse un estado válido. La versión 1.5.3 demuestra cómo una cadena vacía ausente o un identificador adicional pueden deshabilitar un agente que, por lo demás, funciona.

Qué cambió en LangChain Anthropic 1.5.3

LangChain Anthropic 1.5.3 repara dos rutas de conversión de mensajes que generaban solicitudes rechazadas por la API de Claude.

Las notas oficiales de la versión de Anthropic enumeran dos correcciones desde la versión 1.5.2. Una cubre los bloques de pensamiento transmitidos por streaming. La otra sanea el contenido de los mensajes del sistema antes de enviarlo.

La corrección de streaming se dirige a una secuencia de eventos específica relacionada con el pensamiento adaptativo. El pensamiento adaptativo permite a Claude determinar cuánto razonamiento interno aplicar dentro de los límites configurados por el proveedor. La API puede devolver contenido de pensamiento estructurado y una firma criptográfica junto con la respuesta visible.

Durante el streaming, esos resultados no llegan necesariamente como un único objeto completo. LangChain recibe varios eventos y los combina en un AIMessage, su representación normalizada de la respuesta de un modelo. Ese mensaje ensamblado puede formar parte posteriormente de otra solicitud.

El fallo reportado aparecía cuando un bloque de pensamiento contenía una cadena vacía, pero aun así recibía un signature_delta. Un delta de firma es un fragmento transmitido por streaming que contiene datos de firma para el bloque de pensamiento. No seguía ningún thinking_delta porque no había texto de razonamiento que añadir.

Inicialmente, LangChain descartaba el estado del bloque vacío. Más tarde reconstruía el bloque a partir del evento de firma, produciendo un objeto con los campos type y signature. Sin embargo, faltaba la clave obligatoria thinking.

El mensaje podía parecer inofensivo mientras se almacenaba dentro de una aplicación. Solo fallaba cuando el agente reproducía ese historial para Claude. Anthropic rechazaba entonces la solicitud porque al bloque de pensamiento le faltaba su campo obligatorio.

La corrección de streaming utiliza setdefault("thinking", "") al gestionar los deltas de firma. Esa operación conserva un valor existente o inserta una cadena vacía cuando falta la clave. Por tanto, preserva la forma de objeto esperada por el proveedor sin inventar texto de razonamiento.

La corrección del mensaje del sistema aborda el problema opuesto. En lugar de perder un campo obligatorio, LangChain estaba reenviando uno no admitido.

Los bloques de contenido de LangChain v1 pueden incluir un id interno. Ese identificador ayuda al framework a representar y rastrear el contenido de forma consistente. El esquema de mensajes del sistema de Anthropic no acepta el mismo campo en esa ubicación.

Antes de la versión 1.5.3, _format_messages podía reenviar contenido de SystemMessage basado en listas sin restringir cada bloque de texto. Por ello, un bloque creado mediante create_text_block() podía llevar su identificador interno a la carga útil saliente.

Anthropic rechazaba esa solicitud con un error que indicaba que no se permitían entradas adicionales. La misma ruta de formato también afectaba al recuento de tokens mediante get_num_tokens_from_messages. Una aplicación podía fallar antes de la generación mientras simplemente estimaba el tamaño de la solicitud.

La corrección de bloques del sistema aplica un asistente de formato compartido a los bloques de texto del sistema. Conserva propiedades compatibles como type, text, cache_control y las citas, al tiempo que elimina metadatos no admitidos.

Estos cambios son pequeños en volumen de código. Su efecto operativo es mayor porque ambos se producen en límites utilizados repetidamente por las aplicaciones de agentes. Uno protege el estado de la respuesta durante el streaming, mientras que el otro limpia el estado de la aplicación antes de la transmisión.

Por qué la corrección de Anthropic GitHub es importante para los bucles de agentes

El fallo importante se producía con retraso: LangChain podía aceptar la respuesta de Claude, guardarla y descubrir la corrupción solo durante el siguiente turno.

Un chatbot básico puede enviar un prompt y mostrar una respuesta. Un bucle de agente realiza una secuencia más larga. El modelo elige una herramienta, la aplicación la ejecuta y el modelo recibe tanto su mensaje anterior como el resultado de la herramienta.

Ese requisito de reproducción hace que la fidelidad de los mensajes sea crucial. La aplicación no puede conservar de forma segura solo la prosa visible. Puede necesitar llamadas a herramientas estructuradas, bloques de pensamiento, firmas y metadatos específicos del proveedor para continuar correctamente la conversación.

La guía de pensamiento extendido de Anthropic explica que los bloques de pensamiento pueden contener firmas. Cuando esos bloques entran en solicitudes posteriores, las aplicaciones deben conservar su estructura pertinente. Por ello, el framework actúa como un serializador de estado, no solo como un envoltorio de texto.

El informe de error original incluía una reproducción determinista que no requería ninguna llamada activa a la API. Simulaba el inicio de un bloque de pensamiento con contenido vacío, seguido de un delta de firma. Al resultado agregado le faltaba la clave thinking.

Esta omisión no rompía necesariamente la primera respuesta transmitida por streaming. El usuario podía recibir una respuesta normal y el agente podía ejecutar la herramienta seleccionada. El fallo aparecía cuando la siguiente solicitud incluía el mensaje previo malformado.

Este momento hace que el error sea más difícil de diagnosticar. Un desarrollador podría culpar a la salida de la herramienta, al segundo prompt o a la restauración de un punto de control. El defecto real entró en la conversación un turno antes, mientras LangChain ensamblaba el mensaje transmitido por streaming.

Los puntos de control persistentes elevaban aún más el riesgo. Un mecanismo de checkpoint guarda el estado del agente para que un flujo de trabajo pueda reanudarse tras una interrupción o continuar entre procesos. Si almacena el bloque malformado, reiniciar el worker no repara la conversación.

El agente puede encontrar repetidamente el mismo rechazo porque el objeto no válido permanece en su historial. La recuperación puede requerir eliminar o transformar el estado guardado, no simplemente reintentar la solicitud fallida.

Pensemos en un agente de programación que pide a Claude inspeccionar un repositorio. Claude selecciona una herramienta de búsqueda y el framework almacena el mensaje del asistente transmitido por streaming. La herramienta devuelve archivos coincidentes, pero la llamada de seguimiento falla antes de que Claude pueda analizarlos.

No hay ningún problema con la operación de búsqueda. En cambio, el agente falla porque el bloque de pensamiento reproducido tiene una firma sin el campo thinking vacío. La versión 1.5.3 reconstruye la forma requerida para esa segunda llamada.

Un agente de soporte presenta el mismo patrón. Puede recuperar correctamente el registro de un cliente y luego fallar al pedir a Claude que interprete el resultado. El defecto aparece como un flujo de trabajo empresarial inestable, aunque el modelo y la fuente de datos sigan disponibles.

El problema del mensaje del sistema puede aflorar antes. Muchas aplicaciones construyen instrucciones del sistema a partir de bloques de contenido reutilizables. Esos bloques pueden llevar identificadores del framework tras pasar por APIs comunes de LangChain.

Si Anthropic rechaza esos metadatos, el modelo nunca inicia la generación. La estimación de tokens también puede fallar porque utiliza la misma lógica de formato. Por tanto, el código de planificación puede detenerse antes de que la aplicación envíe su solicitud de finalización prevista.

La corrección de streaming de Anthropic y el cambio de saneamiento del sistema abordan direcciones de viaje distintas. El streaming convierte eventos del proveedor en objetos de LangChain. El formato de mensajes convierte objetos de LangChain de nuevo en solicitudes del proveedor.

Juntos, protegen un ciclo completo. Claude produce estado estructurado, LangChain lo almacena y la aplicación lo devuelve posteriormente. La fiabilidad de los agentes depende de que ese ciclo permanezca sin pérdidas cuando sea necesario y sea restrictivo cuando corresponda.

Un esquema de framework se encuentra con un límite de proveedor más estricto

LangChain debe preservar el estado significativo del proveedor mientras elimina metadatos del framework, y esos objetivos pueden entrar en conflicto dentro de la misma conversación.

La tensión principal no es LangChain contra Anthropic. Es la portabilidad frente al cumplimiento exacto del esquema. LangChain ofrece abstracciones de mensajes compartidas, mientras que Anthropic valida la forma de solicitud que espera su API.

Un bloque de contenido normalizado puede incluir información útil en todo el framework. Los desarrolladores pueden adjuntar identificadores, citas, información de herramientas o controles de caché. Los adaptadores del proveedor traducen después esa representación general a un formato de transmisión más limitado.

Ese diseño ayuda a las aplicaciones a alternar entre integraciones. Un equipo puede utilizar patrones de orquestación similares con Claude, modelos de OpenAI o modelos de Google. Sin embargo, la carga útil final debe seguir cumpliendo el contrato particular de cada proveedor.

La versión 1.5.3 ilustra ambos posibles errores de los adaptadores.

El primer error es el filtrado excesivo o la reconstrucción incompleta. LangChain perdió la presencia de un campo vacío porque las cadenas vacías suelen parecer equivalentes a valores ausentes en la lógica habitual de una aplicación. El esquema de Anthropic trataba esos estados de forma distinta.

Un valor thinking vacío comunica que el campo existe y no contiene texto. Una clave ausente comunica que el objeto no cumple la estructura esperada. El contenido semántico está vacío, pero la distinción estructural sigue siendo importante.

El segundo error es el filtrado insuficiente. LangChain permitió que un id interno saliera del framework a través de un bloque de texto del sistema. Ese identificador podía ser válido dentro de LangChain y, aun así, no ser válido en el límite de Anthropic.

Por tanto, el comportamiento correcto del adaptador parece asimétrico. Debe conservar un campo del proveedor aparentemente vacío mientras elimina un campo del framework aparentemente útil. Una regla genérica como «eliminar valores vacíos» o «conservar todos los metadatos» fallaría en uno de los dos casos.

Por eso los adaptadores de proveedores siguen siendo componentes de ingeniería sustanciales. Hacen más que renombrar propiedades. Conciliar diferentes supuestos sobre identidad, estado, streaming, validación, herramientas y reproducción de conversaciones.

Los usuarios de SDK directos afrontan menos capas de traducción porque construyen solicitudes con los tipos nativos de un único proveedor. Ese enfoque más limitado puede reducir la ambigüedad. También vincula más lógica de la aplicación a una sola representación de API.

Los usuarios de frameworks obtienen composición y portabilidad, pero heredan el riesgo de los adaptadores. El framework debe actualizarse a medida que cada proveedor cambia modelos, eventos de streaming, tipos de contenido y comportamiento de validación.

Las integraciones de OpenAI y Google enfrentan presiones similares, incluso cuando los campos exactos difieren. Cada proveedor define sus propios bloques de contenido aceptados y reglas para mensajes de herramientas. Una abstracción compartida no puede eliminar esas diferencias en el límite de red.

Este lanzamiento no demuestra que los SDK directos sean universalmente más seguros. Las aplicaciones directas también pueden corromper el historial o enviar campos no compatibles. Sí demuestra que la abstracción desplaza la responsabilidad en lugar de eliminarla.

LangChain pasa a ser responsable de determinar qué detalles son portables y cuáles son específicos de cada proveedor. Las aplicaciones siguen siendo responsables de las actualizaciones, las pruebas de regresión, la compatibilidad con el estado almacenado y la observabilidad.

El lanzamiento de LangChain para Anthropic también destaca por qué los errores de esquema merecen atención en producción. Las respuestas HTTP 400 suelen parecer indicativas de un uso incorrecto por parte del desarrollador. En estos casos, la aplicación podía utilizar objetos documentados del framework y aun así generar una carga útil rechazada.

Esta distinción afecta la respuesta ante incidentes. Reintentar una solicitud no válida sin cambiar su estructura desperdicia tiempo y puede ampliar los retrasos en las colas. La monitorización debe conservar el mensaje de validación del proveedor e identificar el índice del bloque de contenido afectado.

Los equipos también deben distinguir entre fallos de llamada inicial y fallos de repetición. Un error en la primera solicitud apunta a la construcción del prompt o al formato del mensaje del sistema. Un error después de ejecutar una herramienta sugiere un estado almacenado del asistente o una secuenciación de resultados de herramientas.

Esta clasificación no sustituye la depuración. Reduce el área de búsqueda. La versión 1.5.3 ofrece a los desarrolladores dos rutas concretas de conversión que inspeccionar cuando las solicitudes a Anthropic fallan en torno a mensajes estructurados.

El parche es limitado y el estado existente sigue siendo el riesgo

La actualización evita las transformaciones documentadas, pero no demuestra automáticamente que todas las conversaciones guardadas sean válidas ni que cada ruta de despliegue use el nuevo paquete.

La corrección del streaming se dirige a una secuencia específica: un bloque vacío de pensamiento adaptativo seguido de datos de firma sin un delta de pensamiento. Las aplicaciones que nunca habiliten el comportamiento de pensamiento pertinente pueden no encontrarla.

La corrección de los mensajes del sistema también tiene un alcance definido. Sanea los bloques de texto dentro de los mensajes del sistema y conserva las propiedades compatibles. Los bloques no textuales del sistema se transfieren sin cambios, según el cambio integrado.

Ese alcance limitado es apropiado para una versión de parche. Las reescrituras amplias de mensajes podrían alterar aplicaciones que funcionan o eliminar metadatos que otra ruta necesita. Las correcciones focalizadas reducen ese riesgo de compatibilidad.

Sin embargo, los cambios de código focalizados requieren validación focalizada. Los equipos deberían reproducir sus propios patrones de mensajes en lugar de considerar que una instalación correcta del paquete es evidencia suficiente.

La primera prueba debería transmitir una respuesta de Claude mediante un bucle real de agente. El flujo de trabajo debería ejecutar al menos una herramienta y continuar con otra llamada al modelo. Esto verifica la ruta de repetición que expuso el defecto del campo de pensamiento.

Los desarrolladores deberían inspeccionar el contenido ensamblado del asistente antes de la siguiente solicitud. Un bloque de pensamiento con una firma debería conservar la clave thinking incluso cuando su valor esté vacío. Los registros deben evitar exponer razonamiento sensible o datos de usuarios.

La segunda prueba debería construir un mensaje de sistema basado en listas utilizando los mismos helpers que producción. Debería incluir un identificador interno y una propiedad compatible, como el control de caché. La carga útil saliente de Anthropic debería eliminar el identificador y conservar los datos compatibles.

El conteo de tokens necesita su propia aserción. El informe sobre mensajes del sistema detectó que get_num_tokens_from_messages compartía el formateador defectuoso. Una prueba de generación por sí sola podría pasar por alto fallos de presupuestación, enrutamiento o validación previa.

Los checkpoints guardados presentan una incertidumbre aparte. La solicitud de extracción integrada cambia cómo se ensamblan los nuevos eventos de streaming. No afirma migrar cada AIMessage malformado que ya esté almacenado por una aplicación.

Los equipos que usan estado persistente de agentes deberían muestrear conversaciones creadas antes de la actualización. Pueden identificar bloques de pensamiento que contienen firmas pero omiten thinking. Esos registros podrían requerir una reparación controlada o una conversación nueva.

Cualquier migración debería mantenerse conservadora. Añadir un valor vacío coincide con la corrección documentada del error, pero los datos de producción pueden contener otras formas de bloque. Los equipos deberían validar con sus versiones exactas del paquete y configuraciones del proveedor.

La resolución de dependencias también puede ocultar la actualización. Una aplicación puede declarar un rango amplio de versiones mientras un lockfile conserva la 1.5.2. Otro servicio puede compilar desde un lockfile diferente o una capa de contenedor en caché.

La telemetría de ejecución debería registrar la versión instalada de langchain-anthropic. Esa evidencia es más fiable que comprobar únicamente el manifiesto de origen. Los trabajadores distribuidos deberían informar de la misma versión resuelta antes de que los operadores cierren un incidente.

La página de lanzamiento indica que la versión 1.5.3 siguió a la 1.5.2 e incluyó las dos correcciones enumeradas. No presenta benchmarks de rendimiento, mejoras de latencia ni nuevas afirmaciones sobre la calidad del modelo. Los desarrolladores no deberían inferir esos resultados.

Tampoco hay evidencia de que estas correcciones eliminen todos los casos límite de streaming de Claude. Cubren fallos reportados con rutas reproducibles. Otras combinaciones de eventos, tipos de contenido o cambios del proveedor aún requieren pruebas.

La evidencia de pruebas del parche es alentadora, pero limitada. La solicitud de extracción sobre mensajes del sistema informó de 241 pruebas unitarias aprobadas en su descripción enviada. GitHub mostró posteriormente un estado de comprobaciones más amplio durante el proceso de integración, lo que no debe interpretarse como validación universal en producción.

El cambio de streaming incluye de manera similar cobertura de regresión para el campo ausente. Una prueba determinista es valiosa porque aísla el comportamiento del framework sin depender de la disponibilidad del proveedor. Aun así, no puede representar todas las configuraciones de agentes en producción.

Por tanto, la lectura escéptica es sencilla. La versión 1.5.3 corrige dos defectos confirmados, pero la fiabilidad depende de todo el ciclo de vida de los mensajes. Las capas de almacenamiento, los serializadores personalizados, el middleware y los checkpoints antiguos pueden reintroducir estado malformado.

Qué deben cambiar los desarrolladores después de la corrección de streaming de Anthropic

La respuesta más segura es una actualización medida seguida de pruebas de repetición, mensajes del sistema y checkpoints que reflejen el tráfico real de producción.

Comience por confirmar la versión del paquete instalada en cada proceso que envía solicitudes a Claude. Compruebe el desarrollo local, la integración continua, los trabajadores en segundo plano y los contenedores desplegados. Las versiones mixtas pueden generar historiales de conversación inconsistentes.

A continuación, añada un caso de regresión para un delta de pensamiento con solo firma. El bloque agregado esperado debe incluir thinking: "". La prueba debería después repetir ese mensaje y verificar que la construcción de la carga útil se realiza correctamente.

Este caso importa incluso si los modelos actuales rara vez emiten la secuencia. Los eventos estructurales poco frecuentes pueden dominar la fiabilidad cuando los agentes se ejecutan continuamente. Un defecto de baja frecuencia se vuelve visible a través de miles de llamadas a herramientas.

Añada una segunda prueba para bloques de texto del sistema creados mediante los helpers v1 de LangChain. Incluya un identificador de bloque interno, texto compatible y cualquier campo de control de caché utilizado por la aplicación. Realice la aserción sobre la carga útil final del proveedor.

No se detenga en las pruebas unitarias. Ejecute una conversación de staging a través del grafo completo del agente. Incluya streaming, una llamada a herramienta, persistencia de checkpoints, reanudación del proceso y otra solicitud a Claude.

Esa secuencia ejercita los límites donde los datos cambian de propiedad. El cliente de Anthropic emite eventos, LangChain los agrega, el checkpoint los guarda y un trabajador posterior los vuelve a formatear.

La observabilidad debería capturar información estructural sin registrar contenido sensible. Los campos útiles incluyen el tipo de bloque, la presencia de campos, la posición del mensaje, la versión del paquete y la categoría de error del proveedor. El texto completo de pensamiento no debería convertirse en un registro rutinario de la aplicación.

Para las respuestas HTTP 400, conserve la ruta del campo del proveedor cuando sea posible. Una ubicación como messages.1.content.0 apunta hacia estado repetido del asistente. Una ubicación bajo system.0 apunta hacia el formato del contenido del sistema.

Las aplicaciones deberían evitar reintentos ciegos ante fallos de validación de esquema. La misma carga útil no válida normalmente volverá a fallar. Una política de reintentos debería separar los errores transitorios de transporte de los errores deterministas de solicitud.

Los responsables de los checkpoints deberían definir una estrategia de recuperación. Una opción es invalidar las conversaciones afectadas y empezar de nuevo. Otra es una migración revisada que restaure el campo vacío ausente en bloques de pensamiento identificados con precisión.

La elección correcta depende de las necesidades de retención y los requisitos de auditoría. Un flujo de trabajo de soporte puede necesitar preservar su historial de conversación. Una sesión breve de programación puede reiniciarse de forma segura con un contexto resumido.

Los equipos que evalúan frameworks también deberían ajustar sus criterios. El soporte de modelos no es solo una lista de clases disponibles. Incluye fidelidad en streaming, herramientas, repetición de mensajes, conteo de tokens, caché y persistencia.

La integración directa con SDK sigue siendo un punto de comparación útil. Si una aplicación utiliza solo Claude y necesita un control estricto sobre los tipos de mensajes nativos, menos traducciones pueden simplificar la depuración. Esa elección sacrifica cierta portabilidad y orquestación a nivel de framework.

Una integración con LangChain tiene más sentido cuando la aplicación se beneficia de interfaces compartidas, enrutamiento de modelos, ejecución de grafos o componentes existentes del framework. La versión 1.5.3 no resuelve esa decisión. Aclara las obligaciones del adaptador que la acompañan.

Tres señales merecen atención durante los próximos meses.

Primero, observe nuevos informes relacionados con bloques de pensamiento, firmas o conversaciones de herramientas repetidas. Un rastreador de incidencias silencioso reforzaría la confianza en que la corrección de streaming de anthropic cubre la secuencia observada. Fallos relacionados indicarían problemas más amplios de reconstrucción.

Segundo, observe los cambios en la normalización de bloques de contenido entre proveedores de LangChain. El defecto de los mensajes del sistema surgió de una discrepancia entre identificadores internos y esquemas de proveedores. Más trabajo compartido de saneamiento sugeriría que los mantenedores están abordando el patrón en todas las integraciones.

Tercero, observe la documentación de esquema y streaming de Anthropic en busca de cambios en el contenido de pensamiento o del sistema aceptado. La evolución del proveedor puede invalidar supuestos incluso cuando el código del framework no cambia.

Para los desarrolladores que usan hoy la integración de Anthropic en GitHub, la medida práctica es clara: actualicen, verifiquen la versión resuelta y repitan un flujo de trabajo real de llamada a herramientas. Después, inspeccionen los checkpoints antiguos antes de asumir que el parche reparó el estado almacenado. Si sus agentes dependen de conversaciones largas, conviertan las pruebas de regresión de la forma de los mensajes en parte de cada actualización del proveedor.