Por qué los Agentes de Largo Plazo necesitan un Harness: cómo gestionan los Agentes Profundos el estado y el contexto.
Por qué los agentes de largo alcance necesitan un arnés: cómo LangChain Deep Agents combate la degradación del contexto con cuatro pilares, middleware, backends de sistema de archivos y subagentes aislados.
Fuentes: The Deep Agents Architecture, Part 1: Understanding the Agent Harness
El diseño más básico de un agente consiste en un bucle de llamadas a herramientas. El modelo lee la solicitud, elige una herramienta, la ejecuta, lee el resultado, elige nuevamente y continúa hasta que deja de llamar a herramientas. LangChain es franco respecto a los límites de este diseño: tales agentes son “superficiales”, incapaces de planificar y actuar en tareas largas e intrincadas. Eso no es un defecto propio de un solo marco de trabajo, sino el resultado de no interponer nada entre el modelo y un contexto que solo crece.
La mejor señal de que el techo es estructural proviene de tres equipos que nunca se coordinaron. Anthropic lo logró al desarrollar Claude Code, OpenAI lo logró con Deep Research, y Butterfly Effect lo logró con tanta fuerza que Manus tuvo que ser reconstruido cuatro veces. Cada uno se centró en los mismos cuatro componentes: una herramienta de planificación, delegación a subagentes, acceso al sistema de archivos y una instrucción detallada. Los esfuerzos independientes de empresas distintas que llegaron a la misma arquitectura sugieren que el problema lo dictó, y no los gustos personales de alguien.
La corrupción del contexto es el verdadero mecanismo
Es tentador decir que las ejecuciones prolongadas de los agentes fallan porque se llena la ventana de contexto. Ese no es el mecanismo real.
Un modelo inmerso en una conversación larga razona peor que el mismo modelo en una conversación corta, incluso cuando aún le queda espacio en su ventana de procesamiento. La atención disponible para cada token disminuye a medida que aumenta la cantidad de tokens circundantes, y la reducción de la relación señal-ruido afecta negativamente la calidad de la salida mucho antes de que la ventana se llene por completo. Este efecto está documentado, no es anecdótico: los modelos recuperan de manera fiable la información del medio de un contexto largo con menor eficacia, prefiriendo los tokens cercanos al inicio y al final.
Esto cambia la forma en que debería solucionarse el problema. Si la causa fuera la capacidad insuficiente, una ventana más grande resolvería el problema. En realidad, la causa es la dilución: el modelo sigue siendo capaz, pero lo que necesita queda enterrado bajo toda la información anterior. Se trata de un problema de organización, no de tamaño, y el espacio adicional en la ventana no ayuda en nada a mejorar esa organización.
La brecha que ni LangChain ni LangGraph fueron diseñados para cerrar
LangGraph se centra en una ejecución duradera: puntos de control, transmisión en tiempo real, revisión humana y persistencia entre hilos. Su equivalente real es Temporal, no otros marcos de trabajo para agentes. Asegura que un agente sobreviva a una caída, pero no dice nada sobre si el agente sigue pensando con claridad después de cuatro horas. LangChain se encuentra en un nivel superior y proporciona las abstracciones: el bucle de llamadas a herramientas, contenido estructurado y middleware de personalización. Sin embargo, el bucle predeterminado creado a partir de esas abstracciones es el superficial que acabamos de describir. La durabilidad y la abstracción son reales y necesarias, pero ninguna de las dos indica si el contexto de trabajo del modelo permanece limpio.
Esto se puede verificar por la forma en que están conectadas las piezas. Las dependencias declaradas de Deep Agents son langchain, langchain-core, langchain-anthropic, langchain-google-genai y langsmith. LangGraph no figura en la lista; solo aparece porque LangChain depende de él. La estructura es estrictamente anidada: Deep Agents sobre LangChain sobre LangGraph, y no tres componentes independientes combinados. En la capa de ejecución ni en la del framework nunca hubo control sobre la higiene del contexto, ya que la capa encargada de ello se encuentra por encima de ambas.
La tesis: un problema de estado, no un problema de razonamiento
El trabajo complejo, para una clase específica y bien definida de complejidad, es un problema de gestión de estado y no un problema de razonamiento.
Existe una forma sencilla de determinar qué tipo de problema representa una tarea. Imagine a un colega competente que pierde toda su memoria cada diez minutos. Si ese colega fracasa en la tarea, esta se refería al estado de cosas, y las notas, la delegación y una estructura diseñada para compensar la pérdida de memoria podrán solucionarla. Si una persona que mantuvo todo el problema en mente todo el tiempo sigue teniendo dificultades, las notas no servirán de nada, ya que la dificultad radicaba desde el principio en el razonamiento.
Cada mecanismo que añade un arnés, ya sea un sistema de archivos para la descarga de carga, subagentes para el aislamiento o una herramienta de planificación para seguir el progreso, aborda el caso de la amnesia. Ninguno de ellos hace que un paso de razonamiento en particular sea más inteligente. Por lo tanto, la gestión de estados no es una explicación rival de la razonamiento. Es la base que permite que el razonamiento se construya paso a paso y no se reinicie en cada uno de ellos. Un modelo que razona correctamente en cada paso aún puede fallar en una tarea de doscientos pasos si el paso 150 no puede ver lo que se decidió en el paso 12. El razonamiento no estaba equivocado; simplemente nunca tuvo continuidad con la que trabajar.
Esta base por sí sola no es suficiente, y fingir que lo es debilitaría el resto del argumento. Persistir con una estrategia fallida mientras la historia correcta y completa está a la vista constituye un fallo puramente lógico, y un manejo impecable del estado no lo corrige. De igual manera, un modelo cuya propia reseña de los eventos se desvía de lo que realmente ocurrió presenta un problema de razonamiento incluso cuando el registro verdadero está intacto y accesible. La versión adecuada de esta afirmación es la siguiente: para los fallos a los que se dirige un mecanismo de gestión, es decir, aquellas tareas que se degradan al sobrevivir más allá de un contexto limpio, el manejo del estado es el factor determinante, mientras que la calidad del razonamiento es el aspecto más difícil al que los marcos de apoyo no pueden intervenir. Las secciones siguientes explican qué construyeron tres equipos para aprovechar ese factor.
Cuatro pilares con muchas partes
Qué es Deep Agents
Deep Agents se distribuye como un paquete de Python de código abierto bajo la licencia MIT, se instala mediante pip y actualmente está en la versión 0.7.5. Existen también una versión en TypeScript, una CLI de terminal llamada deepagents-code y una edición gestionada y alojada que aún se encuentra en beta privada. No es un competidor de LangChain ni de LangGraph. Como se mostró anteriormente, depende directamente de LangChain y solo accede a LangGraph a través de esta vía. Al llamar a create_deep_agent() se accede a create_agent() de LangChain, lo que genera un grafo de LangGraph; por lo tanto, toda durabilidad que tenga el agente proviene de lo que LangChain le transmite.
Los cuatro pilares y la tecnología subyacente
Según LangChain, cuatro elementos hacen que un agente sea profundo: una herramienta de planificación, delegación de subagentes, acceso al sistema de archivos y una instrucción detallada. Harrison Chase propuso este enfoque al observar la misma estructura en Claude Code, Deep Research y Manus. Como modelo mental funciona bien, ya que esas cuatro categorías marcan realmente la diferencia entre un bucle superficial y un agente capaz de completar una tarea extensa.
“Cuatro” era una descripción inicial, no el plano final. create_deep_agent() reúne cada capacidad a partir de un conjunto más amplio y en constante crecimiento de middleware que puede combinarse libremente. La lista incluye archivos, subagentes, resumen de información, corrección de llamadas a herramientas, diversas variantes de almacenamiento en caché de instrucciones vinculadas a proveedores específicos, memoria, habilidades y aprobación humana, además de cualquier capa personalizada que escriba un desarrollador. Los pilares indican qué puede hacer el agente. La pila de middleware es la forma en que se generan realmente esas capacidades, y está en constante cambio.
Solo dos componentes de la pila son estrictamente necesarios desde el punto de vista estructural, y eso es más importante que cualquier cantidad. FilesystemMiddleware es necesario porque aplica las reglas de permisos que controlan el acceso a los archivos, algo que un comentario del código denomina garantía de seguridad. SubAgentMiddleware es necesario porque es lo que utiliza la herramienta task. Excluir cualquiera de ellos genera un error y no funciona de forma silenciosa. Todo lo demás es opcional y solo se integra a petición.
Cualquiera que esté desarrollando sobre esta base ahora debe saber que dos de las cuatro categorías originales se han convertido en opcionales. A partir de la versión v0.7.0, la herramienta de planificación (write_todos) ya no forma parte del conjunto por defecto, y el prompt del sistema base se entrega vacío, según la notificación de descontinuación. Cada uno de ellos requiere una línea de configuración para ser restaurado. Una simple llamada a create_deep_agent() brinda acceso a archivos y delegación de subagentes de forma inmediata, mientras que la planificación y un prompt detallado solo se proporcionan bajo solicitud.
Perfiles de aprovechamiento: la capa de ajuste que los modelos más recientes no cuentan
Bajo el middleware existe un mecanismo de ajuste separado llamado perfil de arnés. Un perfil agrega texto adicional de solicitud del sistema y elimina ciertas herramientas, seleccionadas según la cadena de modelo específica que se le pasa al agente. No lo confunda con ProviderProfile, que determina cómo se construye el objeto del modelo. Un HarnessProfile modifica el comportamiento después de la construcción.
La búsqueda requiere la clave provider:model registrada con exactitud, utilizando una entrada válida para todo el proveedor como solución de respaldo en caso de que no exista. De forma predeterminada, existen perfiles para la familia Codex de OpenAI y para tres generaciones de Claude: Haiku 4.5, Sonnet 4.6 y Opus 4.7. El perfil de Sonnet 4.6 va más allá de simples consejos generales sobre cómo formular solicitudes; sigue tan de cerca las guías publicadas por Anthropic que los comentarios en el código lo reflejan claramente, y omite deliberadamente las advertencias orientadas a Opus sobre la necesidad de ser proactivo y el uso excesivo de subagentes, ya que se consideraron irrelevantes para Sonnet.
Un modelo lanzado una generación después de los ya registrados no recibe nada. Al verificarlo con el resolvedor, claude-sonnet-5, anthropic:claude-sonnet-5 y anthropic por separado no devuelven ningún perfil. Al no haber coincidencia exacta y al no existir una entrada de Anthropic a nivel de proveedor a la que recurrir (solo existen perfiles vinculados a versiones específicas), nada coincide. La falta de resultados es completamente silenciosa. Según la propia documentación del resolvedor, la única línea de registro es una nota de depuración que se emite cuando se utiliza un recurso de respaldo a nivel de proveedor. Si ambas búsquedas fallan, no se escribe ningún registro.
Por lo tanto, un agente construido sobre el modelo más reciente de una familia en constante evolución recibe exactamente la misma configuración que un agente basado en un modelo del que el framework nunca ha oído hablar, es decir, ninguna, sin señal alguna de que eso sea lo que ocurrió.
Cómo funciona
Una abstracción bajo todo
Todo este middleware se basa en un único mecanismo que pertenece a LangChain y no a Deep Agents. LangChain 1.0 añadió puntos en los que el código puede ejecutarse al iniciar o finalizar una ejecución, antes y después de cada llamada al modelo, y alrededor de cada llamada a una herramienta, lo que permite que un único bucle de agente soporte diseños muy diferentes. Los hooks antes se activan en el orden en que se registraron, y los hooks después se activan en el orden inverso, lo cual refleja cómo los frameworks web anidan su middleware. Un hook de envoltura puede intentar nuevamente la llamada, servirla desde una caché o interceptarla por completo. Las configuraciones de supervisor, los enjambres, los bucles de reflexión y los agentes profundos resultan ser en realidad un único bucle con diferentes hooks conectados, y create_deep_agent() es simplemente una selección específica de ellos.
Archivos: dos backends, dos garantías
Los archivos pueden encontrarse en dos lugares, y el que esté activo determina qué significa realmente la escritura por parte de un agente.
StateBackend, que es el valor predeterminado, almacena los archivos en un canal del estado de LangGraph: datos de grafo con sus propias reglas de fusión, y no en el disco. Solo funciona durante la ejecución de un grafo en tiempo real. Que el contenido sobreviva a una sola llamada depende de contar tanto con un checkpointer como con un ID de hilo estable. Sin ellos, cada invocación comienza en blanco, lo que explica por qué una simplecreate_deep_agent()siempre muestra un directorio de trabajo vacío.FilesystemBackendrealiza lecturas y escrituras reales en el disco, lo que conlleva un almacenamiento duradero pero también un riesgo real. En su documentación se indica claramente que es adecuado para el desarrollo local y para procesos CI/CD, pero no para nada que esté expuesto a los usuarios, ya que el agente puede leer todo a lo que tenga acceso, incluidos los datos confidenciales, y sus modificaciones no pueden deshacerse. Con el valor predeterminadovirtual_mode=True, el acceso se mantiene dentro de un directorio raíz, se rechaza la navegación tanto en la ruta bruta como en la ruta resuelta, y las rutas absolutas reales se ocultan en la salida del agente para que no se revele la ubicación del directorio raíz.
Un único sistema de permisos cubre ambos casos. Una regla relaciona una operación con un patrón de ruta y uno de tres modos: permitir, denegar o interrumpir. La eliminación se evalúa con cuidado según las reglas de escritura. Se rechaza una eliminación recursiva si alguna regla de denegación coincide con elementos situados debajo del objetivo, y no solo con la primera regla que coincida; por lo tanto, un permiso amplio otorgado tempranamente no puede autorizar la eliminación de algo que esté protegido por una regla posterior y más específica.
Subagentes, aislados por diseño
Se accede a los subagentes de la misma manera que a cualquier herramienta. Cuando el modelo llama a task, se inicia un agente completamente separado, equipado con su propio modelo, herramientas y middleware. La configuración de su modelo acepta ya sea una cadena provider:model o un objeto de modelo ya creado; así, colocar un subagente en un proveedor diferente al del agente padre solo requiere una línea de configuración, sin necesidad de esfuerzos técnicos adicionales.
La memoria no se transfiere automáticamente. La especificación del subagente no cuenta con un campo de memoria, y la lógica que asigna permisos no tiene un equivalente para la memoria. El contexto aislado y limpio es intencional, lo que significa que cualquier cosa guardada a través de la memoria del agente padre es invisible para un subagente a menos que se le proporcione su propio middleware de memoria.
La memoria es revisable, no autoritativa
Un archivo de memoria, una vez cargado, no va directamente al prompt del sistema. Llega envuelto en un bloque claramente marcado, con instrucciones añadidas por el framework que indican al modelo que el contenido es material de referencia que podría estar desactualizado o haber sido creado por otra persona, y no una orden que debe seguirse sin cuestionamientos. Eso representa un nivel de confianza menor que el prompt del sistema, y se ajusta al papel previsto: algo que el agente lee y modifica mientras trabaja, y no un manual de reglas que un desarrollador escribe una vez y espera que tenga autoridad total.
Un detalle de escalado
El estado de la conversación depende de un reductor personalizado llamado DeltaChannel, diseñado para que el almacenamiento de los puntos de control crezca de forma lineal, O(N), a medida que la conversación se alarga, en lugar de de forma cuadrática, O(N²).
Comportamiento en los extremos
Hay dos condiciones que deben entenderse antes de decidir hasta qué punto recurrir a subagentes en entornos de producción, ambas verificadas en el repositorio actual.
Un fallo, muchas consecuencias (problema #694). Si varios subagentes se ejecutan simultáneamente y uno genera una excepción, el resto también se cancelan junto con él. El lote tiene éxito o falla como unidad, sin aislamiento entre sus componentes. El informe data de enero de 2026 y corresponde a una versión preliminar; desde entonces el problema ha sido resuelto, aunque el cambio en el código que lo solucionó no puede localizarse ni en el código de los subagentes ni en la capa de ejecución de herramientas de LangChain. Aun así, planifique teniendo en cuenta esto: considere que cualquier distribución de subtareas independientes puede fallar parcialmente hasta que se confirme lo contrario en la versión realmente desplegada.
Errores que llegan al lector incorrecto (#947). Después de que una herramienta genera un error, el modelo normalmente debería intentarlo de nuevo o ajustarse. Sin embargo, en algunas ejecuciones observadas, se dirigió directamente al usuario final con un texto destinado a una corrección interna, por lo que alguna persona vio un mensaje de error que nunca estaba destinado a ella. El problema seguía sin resolverse al momento de la verificación. Un informe separado indica que, tras una actualización posterior del framework, ciertas excepciones de las herramientas detienen por completo al agente en lugar de enviar el mensaje al modelo para que lo intente de nuevo, algo que ocurría en las versiones anteriores.
Se han cerrado dos informes anteriores en la misma área: los subagentes que ignoran el límite de recursión del agente principal (#1698) y la interrupción en la reanudación de tareas debido a decisiones de edición y rechazo (#554). La solución para el límite de recursión también se verificó con el código fuente instalado. Estos informes demuestran lo rápido que suelen resolverse los problemas en esta área, por lo que no constituyen motivo para modificar el diseño.
Alternativas prácticas
Actualmente existen tres opciones prácticas para crear un agente a largo plazo: Deep Agents, el Claude Agent SDK y el OpenAI Agents SDK. Cada una refleja una elección diferente respecto a qué controla su equipo y qué ofrece a otros, y ninguna es una versión incompleta de las demás.
Una distinción que se confunde más que ninguna otra es la diferencia entre un handoff y un subagente. Dos de las tres opciones utilizan el mismo patrón subyacente, al que llegan de forma independiente dos equipos. La tercera es un mecanismo verdaderamente diferente.
Elegir entre ellas se reduce a dos preguntas y no a una clasificación, y ninguna de ellas tiene una respuesta universal. Cada una solo puede responderse teniendo en cuenta las restricciones reales de un sistema específico.
Qué llevarse como aprendizaje
Los agentes de largo horizonte necesitan un andamiaje porque el contexto acumulado diluye la señal mucho antes de que se llene el período de tiempo establecido. Los agentes profundos construyen dicho andamiaje bajo un marco basado en cuatro pilares, respaldado por una pila dinámica de middleware, además de un sistema de archivos, subagentes y memoria, cada uno de los cuales ofrece garantías y carencias específicas. Conocer esas carencias, como las omisiones en los perfiles silenciosos en los modelos más recientes, la memoria invisible para los subagentes, los fallos paralelos de tipo todo-o-nada y los errores de las herramientas que afectan a los usuarios, es lo que diferencia el uso deliberado del marco del simple hecho de confiar en sus valores predeterminados.
Leer más
- Construyendo un Harness para DeepAgents: Permisos, subagentes y aprobación humana — Una guía práctica para crear un planificador de diseño de sistemas con DeepAgents: servidores de archivos, reglas de permisos, subagentes, puntos de aprobación, habilidades y MCP, además de los casos en que el juicio del modelo sigue fallando.
- Flujos de trabajo multiagente de LangGraph: Comparación entre enjambre y supervisor — Dividir un flujo de trabajo de LangGraph en subagentes con sistema de puntos de control, luego crear un asistente financiero tanto como enjambre como supervisor, y observar dónde falla cada modelo.