2026-05-26 · Actualizado 2026-07-22

[!NOTE] Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

Agentes AI de ejecución prolongada Runtime en 2026: sesiones, Sandboxes, Checkpoints y plataformas de gestión

Parte 5 de la serie de ingeniería de la pila Agentic

Los cuatro artículos anteriores trataron sobre el diseño interno del agente: bucles de razonamiento, memoria, tool use, y seguridad. Este artículo trata sobre el runtime que garantiza el funcionamiento continuo de dichas partes a lo largo de sesiones prolongadas y ante fallos en los procesos.

Una ejecución de agente puede durar horas, mientras que su proceso trabajador puede reiniciarse en cualquier momento. El modelo sigue siendo el encargado de elegir la acción siguiente, pero el runtime debe conservar el estado, controlar la ejecución y recuperarse de una falla en medio de un tool call. Este artículo define los límites del runtime. En la parte 6 se analizará el harness que existe dentro de él: la lógica de retroalimentación, reintentos, transferencia y aceptación que determina si el agente continúa funcionando o se detiene.

¿Qué es un agente AI runtime?

Un AI agente runtime constituye la capa de infraestructura encargada de mantener un agente que utiliza herramientas activo, aislado, observable y capaz de reanudarse una vez finalizada la llamada al modelo. Este componente gestiona el estado de la sesión, la ejecución de las herramientas, checkpoints, las verificaciones de política, los datos confidenciales, los registros de trazabilidad, los límites de costo y la estructura de despliegue. El modelo selecciona la acción siguiente, mientras que el runtime determina dónde se ejecutará dicha acción, si está permitida, cómo se registrará y cómo se reanudará el proceso en caso de fallo.

Utilice el runtime como unidad de diseño para los agentes de ejecución prolongada. Si no es posible indicar con precisión dónde se encuentra cada primitiva, dicho agente seguirá siendo un prototipo.

Las ejecuciones prolongadas invalidan las suposiciones sobre procesos sin estado

Un endpoint de chat sin estado puede almacenar el estado de la solicitud en un único proceso y descartarlo una vez entregada la respuesta. Por el contrario, una ejecución prolongada de un agente implica reinicios de workers, despliegues, restablecimientos de contexto e interrupciones debidas a procesos de aprobación. En estos casos, el proceso worker ya no puede considerarse como la fuente de verdad del estado.

El equipo de OpenAI Codex informa sobre la longitud de ejecución en su harness engineering descripción detallada:

“Con frecuencia observamos que una sola ejecución de Codex es capaz de trabajar en una tarea durante más de seis horas seguidas (a menudo mientras los humanos duermen).”

El equipo de ingeniería de Anthropic describe el problema de estado correspondiente en Mecanismos eficaces para agentes de ejecución prolongada:

El desafío fundamental de los agentes de ejecución prolongada radica en que deben operar dentro de sesiones discretas, donde cada nueva sesión comienza sin conservar memoria alguna de lo que ocurrió anteriormente.

Ambas observaciones implican el mismo diseño runtime: persistir el estado fuera del worker y hacer que estos sean reemplazables.

La sesión debe existir fuera del proceso de trabajo. Un almacén duradero registra las llamadas al modelo, tool results, y las aprobaciones, de modo que otro proceso de trabajo pueda reanudarse en el último punto seguro tras una caída. Además, Checkpoints permite que el runtime inicie una nueva sesión del modelo cuando se llena la ventana de contexto, sin tener que reproducir toda la historia anterior. En La redacción de Anthropic, Las harness pasan a ser desechables y reencendibles; el estado duradero se almacena en otro lugar.

El modelo decide qué hacer a continuación. El runtime determina si el movimiento está permitido, dónde se ejecuta, cómo se registra y cómo se reanuda la ejecución tras una interrupción. El resto de este artículo trata sobre ese runtime.

Las cinco primitivas runtime que necesita todo agente AI de ejecución prolongada

Anthropic’s Escalar agentes gestionados El documento de descripción ofrece un vocabulario útil para las cinco responsabilidades de runtime. El harness impulsa al agente hacia adelante, mientras que los registros de sesión registran sus acciones y el sandbox ejecuta las órdenes. El checkpoint proporciona al siguiente trabajador un punto de reanudación; por su parte, el rastro conserva pruebas para la depuración posterior. Aunque una implementación puede combinar componentes, las responsabilidades y los límites de fallo siguen necesitando tener nombre.

Sesión. Un registro de solo escritura que contiene todo lo que ocurrió: llamadas al modelo, tool calls, resultados, errores y aprobaciones. La recuperación se realiza a partir de este registro. wake(sessionId) → getSession(id) → resume from last event. En LangGraph, esto se trata de un thread_id plus un controlador de punteros de Postgres (ver Persistencia de LangGraph). OpenAI Agents SDK incluye diez servidores backend de sesión integrados. SQLiteSession, RedisSession, SQLAlchemySession, MongoDBSession, y EncryptedSession (véase el Documentación de sesiones).

Harness. El bucle de orquestación. Este llama al modelo, analiza tool calls, los ejecuta, escribe los resultados de vuelta en la sesión y aplica las reglas de reintentos. Anthropic lo expresa de forma directa:

“Cada componente de un harness codifica una suposición sobre aquello que el modelo no puede realizar por sí mismo.”

El equipo Codex de OpenAI denomina a esta disciplina ingeniería de aprovechamiento: la creación de software sigue requiriendo disciplina, pero ahora se invierte más esfuerzo en las estructuras auxiliares que en el código en sí. LangGraph’s CompiledStateGraph, Agentes profundos’ create_deep_agent, En este sentido, tanto Claude Code como los demás entornos de desarrollo también constituyen herramientas de este tipo.

Sandbox. El entorno de ejecución aislado en el que realmente se ejecutan los comandos. Los SDK de OpenAI. sandbox conceptos page traza la línea de forma nítida:

“El runtime externo sigue siendo responsable de las aprobaciones, el seguimiento, las transferencias de control y la gestión de los estados de reinicio. La sesión de sandbox se encarga de los comandos, los cambios en los archivos y el aislamiento del entorno.”

Sandboxes difieren en cuanto a su duración de vida y a la información que retienen entre ejecuciones. La forma más sencilla es la de efímero fresco: se crea uno exclusivamente para una tarea específica, se destruye al finalizar dicha tarea, y se asume el costo de arranque en frío en cada ejecución.

Estado en pausa persistente sandboxes permite mantener el sistema de archivos y una instantánea en memoria entre ejecuciones. Esto evita que sea necesario realizar un arranque completo al reanudar el proceso. Las técnicas de instantánea o bifurcación crean una imagen de tipo “copy-on-write” a partir de un padre ya preparado, lo que permite que múltiples tareas compartan las dependencias instaladas y los cachés ya cargados, sin tener que compartir su estado escribible.

Per-worktree sandboxes proporciona a cada tarea su propio espacio de trabajo y conjunto de herramientas de observabilidad. Al separar los registros, las métricas y las trazas, es posible depurar una ejecución sin que el estado de esta afecte a otra. La tabla de proveedores que aparece más adelante en este artículo compara el comportamiento en casos de inicio en frío y persistencia.

Checkpoint. Estado resumible. De LangGraph PostgresSaver escribe un StateSnapshot en cada límite de super-paso, mediante escrituras por tarea checkpoint_writes Por lo tanto, los resultados de los nodos que funcionan correctamente no se vuelven a calcular cuando un nodo hermano falla. La instantánea es un diccionario JSON-serializable.v, ts, id, channel_values, channel_versions, versions_seen, pending_sends) documentado en el langgraph-checkpoint-postgres la página de PyPI y LangGraph checkpoints de referencia.

Rastro. La interfaz de reproducción y depuración. Cada llamada al modelo, tool call, y cada paso del subagente se convierten en un intervalo que incluye información sobre el tiempo de ejecución, las entradas, las salidas, los recuentos de tokens y el costo asociado. Cuando una ejecución de seis horas falla, es el rastro el que se analiza para determinar qué sucedió mal. Para entonces, la salida en la terminal de dicha ejecución ya ha desaparecido hace tiempo. De OpenTelemetry Convenciones semánticas de la GenAI estandarizar los nombres de los atributos (qué modelo, qué proveedor, cuántos tokens, qué conversación, qué flujo de trabajo), de modo que la misma traza se muestre de forma clara en Tempo, Jaeger, Honeycomb, o LangSmith sin volver a instrumentar el sistema.

La política y los secretos constituyen límites separados runtime

Dos límites atraviesan las cinco primitivas y resulta más sencillo abordarlos como consideraciones independientes. Se trata de la versión runtime del argumento de seguridad proveniente de Parte 4.

Motor de políticas

Un control de permisos se ejecuta antes de cada tool call y determina si la operación puede proceder. En entornos de producción son comunes dos patrones. Deep Agents permite que cada subagente declare qué rutas de archivo puede leer o escribir, y el middleware bloquea todo aquello que esté fuera de dicha declaración. Anthropic Managed Agents dirige cada tool call a través de un proxy MCP, de modo que es el proxy quien aplica los permisos en lugar del código del agente. Cuando una llamada sensible requiere aprobación humana, LangGraph’s interrupt() Además, el mecanismo de aprobación de los Agentes Profundos pausa el grafo hasta que una persona indique su consentimiento.

Corredor secreto

El modelo no debe tener acceso a secretos de larga duración, y el sandbox normalmente tampoco debería hacerlo. El patrón de Agentes Gestionados es el que se debe adoptar:

“En el caso de Git, utilizamos el token de acceso de cada repositorio para clonarlo durante la inicialización de sandbox y conectarlo al remoto local de Git.” Git push y pull Se puede trabajar desde el interior de sandbox sin que el agente tenga que manejar nunca el token en sí. Para herramientas personalizadas, admitimos MCP y almacenamos los tokens OAuth en un almacén seguro. Claude llama a las herramientas MCP a través de un proxy dedicado; este proxy recibe un token asociado a la sesión. … El harness nunca queda al tanto de ninguna credencial.”

En el market-analyst-agent pila de referencia: el sidecar MCP lee los tokens OAuth desde un secreto de Docker (en entornos de producción, HashiCorp Vault) Y solo expone la interfaz del herramienta al proceso de LangGraph. El proceso nunca llega a ver el token. git push Funciona. cat ~/.ssh/id_rsa No.

Postgres Podría abarcar la sesión y checkpoint. El contenedor de trabajo es el harness. Un servicio como Daytona, Modal, o E2B proporciona el sandbox, mientras que Tempo o LangSmith Almacena el rastro.

A continuación, inspeccionemos las fallos acoplados. Si dos primitivas operan dentro del mismo proceso, la caída de una hace que ambas dejen de funcionar. Si comparten una credencial, una fuga de datos puede trascender ambos límites de seguridad. Ejemplos habituales son un worker que también gestiona la durabilidad de los registros de seguimiento, o un token sidecar que, además, permite el acceso a la base de datos checkpoint.

Modos de fallo del agente runtime en producción AI

El runtime se encarga de gestionar las reintentos, restaurar el trabajo anterior, aislar los espacios de trabajo y hacer cumplir los presupuestos. Las cinco primitivas mencionadas anteriormente controlan el ciclo de vida de las ejecuciones, mientras que las políticas y los mecanismos de intercambio de secretos operan de forma transversal sobre ellas. A medida que las ejecuciones abarcan varios procesadores y ventanas de contexto, las fallas tienden a manifestarse como cambios en el estado, efectos secundarios duplicados, sandbox drift y incumplimientos en los presupuestos establecidos.

Las fallos se dividen en cuatro grupos:

• Fallos de calidad de la salida: el agente declara haber completado la tarea antes de que realmente se haya ejecutado, olvida lo que hizo al restablecerse la ventana de contexto, o confía en su propia autoevaluación y entrega una salida defectuosa.
• Fallos de control de costos: el agente queda atrapado en un bucle de intentos repetidos, o agota su presupuesto de tokens o llamadas a herramientas sin producir nada útil.
• Fallos relacionados con el estado y las caídas: los espacios de trabajo se desestabilizan porque una ejecución modifica archivos que pertenecen a otra ejecución, tool calls se disparan más de una vez debido a que los intentos de reintentar las acciones las ejecutan nuevamente, o se pierde el trabajo cuando un proceso falla entre eventos.
• Fallos de la ventana de contexto: el modelo realiza un resumen y termina prematuramente al pensar que se le está agotando el espacio, incluso cuando aún queda capacidad en la ventana.

La tabla relaciona cada fallo con una medida de mitigación, el gancho runtime que la hace efectiva, y los fundamentos en los que se basa la recomendación. Dado que el comportamiento específico de cada modelo puede variar, se deben considerar las observaciones del proveedor como prompts para volver a probar dichas suposiciones en lugar de tratarlas como reglas permanentes.

En cada fila aparecen dos conceptos. Anthropic, en relación con la antigüedad de harness Harness diseño para el desarrollo de aplicaciones de ejecución prolongada:

“Cada componente de un harness representa una suposición sobre aquello que el modelo no puede hacer por sí mismo, y esas suposiciones merecen ser sometidas a pruebas de estrés, tanto porque podrían ser erróneas como porque pueden volverse obsoletas con rapidez a medida que los modelos mejoran.”

Vercel, respecto al problema relacionado de que demasiadas herramientas incorporen un número excesivo de suposiciones, en Hemos eliminado el 80 % de las herramientas de nuestro agente.:

“Eliminamos la mayor parte del código y redujimos al agente a una única herramienta: ejecutar comandos Bash arbitrarios. A este tipo de agente lo denominamos agente de sistema de archivos”.

El resultado reportado por Vercel para una consulta representativa muestra que la tasa de éxito pasó del 80 % al 100 %, mientras que en el caso más crítico el tiempo de ejecución disminuyó de 724 s / 100 pasos / 145.463 tokens (fallido) a 141 s / 19 pasos / 67.483 tokens (exitoso). La lección a extraer no es “elimine sus herramientas”, sino que cada primitivo presente en su runtime, incluida la interfaz de herramientas, tiene un tiempo de vida limitado. Es necesario volver a evaluar estas suposiciones cuando el modelo experimenta cambios.

Cognition observó el mismo objetivo dinámico en cuanto a la duración de la sesión con Sonnet 4.5. En Reconstruyendo Devin para Claude Sonnet 4.5 Describen un modelo que escribe de forma proactiva. SUMMARY.md / CHANGELOG.md Dado que detecta un agotamiento del contexto, subestima la cantidad de tokens que le quedan. Su solución consiste en activar la versión beta de 1 M de tokens y limitar su uso a 200 k, de modo que el modelo siga creyendo que dispone de margen suficiente. Esa medida de mitigación, con el tiempo, también se convertirá en una carga innecesaria.

El equipo de harness en OpenAI resume esta disciplina en una sola frase: “Los humanos dirigen. Los agentes ejecutan”. Cuando algo falla, la pregunta no es “tratar con más esfuerzo”, sino “¿qué capacidad falta y cómo podemos hacer que sea comprensible y exigible para el agente?”

El ciclo de vida de una ejecución saludable

Un proceso que se ejecuta de forma predecible resulta aburrido. Se trata de una secuencia de pasos pequeños y recuperables, donde cada paso escribe su resultado en un almacenamiento duradero antes de que comience el siguiente.

Dicho límite contiene daños causados por una caída. En caso de fallo, solo se pierde el paso en curso durante el vuelo, y el siguiente trabajador reanuda desde el último paso completado en lugar de reiniciar toda la solicitud.

1. Iniciar el arranque ya sea desde una sesión nueva o desde una reanudada. Al reanudar, montar el espacio de trabajo desde su último estado conocido y leer los archivos de progreso que dejó la tentativa anterior (PROGRESS.md, feature-list.json), y se carga el último checkpoint del banco de datos. Es aquí donde el harness transfiere al agente toda la información que el trabajador anterior tenía en memoria antes de dejar de funcionar.
2. Planificar antes de iniciar cualquier tool calls. Es necesario definir qué significa que una tarea esté “completada”, cuánto tiempo se puede dedicar a su ejecución, qué herramientas puede utilizar el agente y qué factores deben detenerla de forma anticipada. Estos valores de planificación se convierten en las verificaciones runtime; sin ellas, la ejecución no cuenta con nada contra lo que poder medirse.
3. Ejecutar un tool call a la vez. La capa de políticas decide si se permite la llamada correspondiente. El harness la ejecuta, captura el resultado y registra un evento en el registro de sesión. Un paso, un evento. Una interrupción entre eventos es recuperable, ya que la fuente de verdad es el registro, y no la memoria del trabajador.
4. Realizar un Checkpoint en los límites de los superpasos, o después de cada evento en un harness más simple. Se debe persistir el estado del grafo, la diferencia del espacio de trabajo y las referencias a cualquier artefacto generado. Este checkpoint es lo que se lee en el paso 1 al reanudar la ejecución. Si el checkpoint está faltante o desactualizado, la recuperación se ve reducida a reproducir todo el registro de sesión desde cero, lo cual es mucho más lento.
5. Se realiza una evaluación contra los artefactos una vez que el agente considera que ha finalizado su tarea: pruebas, revisión con contexto actualizado, validación de esquemas y comprobaciones en el navegador. Si la verificación tiene éxito, la ejecución finaliza correctamente. En caso de fallo, la ejecución se reanuda a partir del último estado checkpoint sin errores, incorporando el mensaje de error al contexto para intentarlo nuevamente.

En esa lista no existe ningún paso que exija al agente recordar nada entre ejecuciones. El estado se mantiene dentro de la sesión y de checkpoint, y el agente lo vuelve a leer en cada reanudación.

Las herramientas que generan efectos secundarios requieren ser idempotentes. Cualquier herramienta con efectos secundarios debe contar con una clave de idempotencia derivada del ID de sesión y del ID de la llamada a la herramienta, la cual se almacena antes de que se produzca dicho efecto secundario. send_email(session_id, tool_call_id, message_hash). create_pr(session_id, tool_call_id, branch_name). charge_customer(session_id, tool_call_id, invoice_id). La ejecución al menos una vez es el valor predeterminado en las colas y los motores de flujo de trabajo. Si repetir un tool call puede causar daños reales, la herramienta aún no está preparada para ser utilizada con agentes.

La evaluación debe incluir evidencias provenientes de un contexto distinto al de generación. Un evaluador externo disminuye el sesgo por contexto compartido, mientras que las pruebas, los analizadores de estilo, las verificaciones en navegador y la validación de esquemas ofrecen evidencias deterministas. La comprobación puede devolver pass, fail, o bien needs_human. En el caso de los agentes basados en código, el revisor puede ser otra sesión de modelo equipada con herramientas de solo lectura. Para los agentes dedicados a datos e informes, es necesario combinar una validación determinística con un modelo revisor que siga requiriendo intervención humana para emitir un juicio.

Once patrones de despliegue de agentes AI y qué factores determinan su elección

Una vez que se han nombrado las cinco primitivas, surge la pregunta sobre qué forma de despliegue las ejecutará. Por “forma” me refiero a la disposición de dichas primitivas: dónde se encuentra el harness, dónde se mantiene el estado y qué tipo de sandbox se encarga de realizar el trabajo. No se trata simplemente de elegir un proveedor en particular. El gráfico que aparece a continuación muestra en qué rango del eje de longitud de ejecución es adecuada cada forma de despliegue. El texto posterior explica cuáles son los factores que determinan la elección entre ellas.

Si solo tiene que leer uno de los once esquemas, le recomiendo leer el esquema 2: cola + trabajador + checkpoint base de datos. Se trata de la configuración por defecto que sugiero para la mayoría de los equipos, del esquema utilizado en el repositorio de referencia, y del modelo básico del cual derivan casi todos los demás esquemas: cola → trabajador → estado duradero, con la sustitución de la fuente sandbox, el propietario harness o el motor de estado. Al leer primero el esquema 2, le resultará más sencillo revisar el resto.

1. SDK dentro de un servidor de aplicaciones (sincrónico, con alcance por solicitud)

La forma original. El agente SDK se ejecuta dentro de un manejador de solicitudes. Es adecuado para tareas que duran menos de 30 segundos, demostraciones y herramientas internas. No es viable para escenarios en los que un cliente HTTP pueda interrumpir la conexión. El tiempo de espera HTTP de Cloud Run Su tiempo de ejecución llega al límite máximo de 60 minutos, y cualquier error crítico en la capa web interrumpe inmediatamente el proceso. El SDK es el harness; además, el proceso web funciona como sandbox, y el estado generalmente se almacena en la memoria del proceso, a menos que se transfiera explícitamente a otro lugar. No debe utilizarse para tareas que duren varias horas.

2. Cola + trabajador + checkpoint de bases de datos

La configuración predeterminada que recomiendo para la mayoría de los equipos, y la forma de producción que se utiliza en market-analyst-agent: un proceso de Python con un checkpointer de PostgreSQL, Redis Streams (o) RabbitMQ) Para la cola de entrada, así como un MCP sidecar dedicado a las herramientas. Es adecuado para ejecuciones que duran desde 10 minutos hasta varias horas, siempre que los pasos a realizar sean idempotentes. El ejecutor local permite omitir la cola en entornos de desarrollo síncrono, pero la cola forma parte del diseño de producción cuando se requiere una submisión asíncrona y se necesita gestionar la contrapresión.

La aplicación recibe una solicitud, crea una fila de sesión, envía un trabajo y devuelve un ID de ejecución. El trabajador recupera el trabajo, ejecuta el harness, escribe los resultados en checkpoints, transmite el estado en tiempo real y almacena los artefactos generados a medida que avanza el proceso. Postgres sigue funcionando sin problemas; los trabajadores son, en esencia, recursos simples e intercambiables, y la profundidad de la cola proporciona mecanismos de retroalimentación ante sobrecargas. La computación de tipo Spot/Preemptible funciona siempre y cuando el checkpointer finalice de escribir en disco antes de informar sobre el éxito del proceso.

En esta arquitectura, el agente que realiza las tareas es el harness. Su contenedor y el espacio de trabajo por hilo establecen un límite de ejecución, pero el código no fiable sigue necesitando un entorno aislado como un sandbox reforzado o una máquina virtual. Postgres gestiona la sesión así como el estado de checkpoint. Las trazas pasan a través de OpenTelemetry hasta llegar a cualquier stack de observabilidad que se esté utilizando.

3. Motor de flujos de trabajo duradero (estilo Temporal)

El código de orquestación de agentes se ejecuta dentro de un Flujo de Trabajo Temporal; las llamadas a modelos y tool calls se realizan como Actividades. El estado del flujo de trabajo se almacena en un registro de historial de eventos respaldado por Cassandra, MySQL o Postgres, lo que permite reproducir dicho estado de forma fiable en diferentes despliegues. La versión de previsualización pública Integración de Temporal con OpenAI Agents SDK envía un OpenAIAgentsPlugin y un activity_as_tool helper, y el Descripción detallada de agentic y sandboxes Describe cómo se puede crear una bifurcación de un agente en ejecución hacia un proveedor diferente de sandbox durante una conversación en curso. Los flujos de trabajo inactivos no consumen recursos de cómputo alguno. Sin embargo, existen limitaciones reales: los agentes de transmisión en tiempo real y los agentes de voz no son compatibles con la integración actual. LocalShellTool y ComputerTool Están deshabilitados porque no se adaptan a un modelo distribuido.

Utiliza esta forma cuando la ejecución presenta puntos de espera reales: aprobaciones humanas, llamadas externas, períodos de inactividad prolongados, intentos de reintentar con reglas de negocio y ventanas de despliegue. Una aprobación humana se convierte en un estado de inactividad duradero que no consume recursos de cómputo, a diferencia de un bucle de consulta que sí lo hace.

El código del flujo de trabajo es el harness. El sandbox suele encontrarse fuera de Temporal y es llamado desde las actividades. El estado de la sesión y el checkpoint se integran en el registro de historial de eventos de Temporal, mientras que la visibilidad de los rastreos proviene de la interfaz de usuario de Temporal junto con los intervalos OpenTelemetry en cada actividad.

4. Proveedor Sandbox por sesión

Una forma más reciente. Cada ejecución de agente dispone de su propia microVM o contenedor proporcionado por un proveedor de sandbox como servicio. El harness se almacena en un lugar duradero; el sandbox es el entorno de ejecución desechable.

La tabla combina los Comparación entre E2B y Daytona, Daytona’s documentación de sandboxes y fork/registro de cambios de snapshots, Modal’s sandboxes y inicio en frío guías, el Lista en Runloop del AWS Marketplace, y Vercel Sandbox: precios.

Daytona registra un enlace padre-hijo para cada fork independiente, lo que permite conservar la línea de descendencia de los sandboxes derivados. El harness de OpenAI emplea una variante específica por worktree: “Codex funciona con una versión completamente aislada de esa aplicación, incluidos sus registros y métricas, los cuales se eliminan una vez finalizada dicha tarea”.

Se debe optar por esta configuración cuando el agente ejecuta código no fiable, automatización de navegadores, pruebas o instalaciones de paquetes. El compromiso que se debe asumir es el mayor costo y el mayor acoplamiento con el proveedor, en comparación con el uso de workers compartidos.

El proveedor es propietario de sandbox y de nada más. Harness, las sesiones, checkpoint y los registros de seguimiento permanecen en tu lado, generalmente organizados siguiendo la estructura de cola + trabajador que se muestra en el punto #2.

5. Agentes Gestionados por Anthropic (hosteados en harness)

Anthropic lanzó los Managed Agents en beta pública el 8 de abril de 2026, de forma reservada para un público limitado. managed-agents-2026-04-01 Encabezado beta. El servicio ofrece una sesión alojada, harness, sandbox, además de un proxy respaldado por bóveda de seguridad MCP. wake(sessionId) Se puede inicializar el harness en un nuevo trabajador sin perder el estado de sesión persistente.

Claude cobra a los Agentes Gestionados según las tarifas estándar por token, más 0,08 $ por hora-sesión. La facturación se realiza con precisión hasta el nivel de milisegundos y solo se aplica mientras el estado de la sesión sea “en ejecución”; el tiempo de inactividad no tiene costo alguno. Por lo tanto, un bucle de intentos descontrolado genera un costo adicional por hora-sesión, además del costo por token.

Lea las advertencias. El descuento por procesamiento por lotes API no se aplica (“Las sesiones son con estado e interactivas. No existe un modo por lotes”). Managed Agents no está disponible a través de AWS Bedrock o Google Vertex AI. La Multi-agent coordinación y la autoevaluación siguen estando en fase de prueba en la investigación. El riesgo de dependencia es elevado: se sacrifica la libertad de harness para no tener que ejecutar el ciclo manualmente.

Anthropic ofrece los cinco primitivos disponibles: sesión, harness, sandbox, checkpoint y trazado. Usted proporciona el runtime y recibe los resultados correspondientes.

6. Despliegue de Agentes Profundos con LangChain (gestionado de forma abierta harness)

deepagents deploy paquetes a deepagents.toml en una implementación de LangSmith que ofrece ejecución duradera, gestión de memoria, arquitectura multiusuario, human-in-the-loop, capacidades de observabilidad, ejecución de código en entorno aislado y ejecuciones programadas. Se admiten modos de implementación en la nube, híbridos y autohospedados. Los proveedores de Sandbox (LangSmith Sandboxes, Daytona, Modal, Runloop o soluciones personalizadas) se pueden cambiar mediante un único valor de configuración. El estado se almacena en un sistema de archivos virtual con backends intercambiables; la memoria está delimitada por usuario, asistente o ambos. El grado de dependencia es menor que en los Agentes Gestionados: el harness está licenciado bajo MIT, y las instrucciones utilizan estándares abiertos. AGENTS.md Estándar, y los agentes se exponen a través de MCP, A2A y el Agent Protocol. Consulte la documentación de LangChain para más detalles. runtime: agentes profundos en entornos detrás de la producción Informe técnico.

Los cinco primitivos se alojan de forma predeterminada, pero cada uno es intercambiable mediante configuración. El sandbox está oculto detrás de un valor de configuración específico. La sesión y el checkpoint se encuentran en un sistema de archivos virtual que admite backend intercambiables. El seguimiento de trazas se realiza a través de LangSmith.

7. Servicio o tarea de Google Cloud Run

Cloud Run dispone de dos modos distintos runtime, y la opción adecuada depende de cómo se invoque al agente. Los services están vinculados a HTTP y escalan a cero entre solicitudes; el harness funciona como un manejador de solicitudes que finaliza su ejecución una vez completada la tarea. Por su parte, los jobs se ejecutan hasta su finalización sin un punto de entrada HTTP; el harness actúa como un trabajador de uso único que cierra su proceso cuando la tarea termina. Ambos pueden alojar el harness, pero ninguno mantiene estado entre ejecuciones. Las sesiones y los checkpoints deben almacenarse en Postgres, Spanner o algún otro sistema de almacenamiento externo similar.

Los límites físicos son muy diferentes entre los dos. Tiempo de espera excesivo en la solicitud del servicio Cloud Run: El valor predeterminado es de 300 s, y el máximo es de 3,600 s (60 min). WebSockets Obtener el mismo tiempo de espera. Tareas de Cloud Run: El tiempo predeterminado es de 10 minutos por tarea, con un límite máximo de 168 horas (7 días); para las tareas que utilizan GPUs, el límite máximo es de 1 hora. Los servicios se escalan a cero a menos que se active el modo siempre activo CPU; los trabajos no disponen de interfaz HTTP ni se escalan automáticamente.

Utilice un servicio para ejecuciones síncronas de hasta 60 minutos. Empiece un trabajo para tareas puntuales más largas o de tipo asíncrono. Cloud Run Jobs permite que una tarea permanezca activa durante días, pero no garantiza la posibilidad de reproducirla de forma fiable tras nuevos despliegues, cambios de versión o sustitución de trabajadores. Para periodos superiores a 7 días, no utilice Cloud Run.

Cloud Run aloja el harness. El estado de las sesiones y de checkpoint se guarda en Postgres, Spanner u otro almacenamiento externo, y los registros de seguimiento pueden transmitirse a través de Cloud Logging y de OpenTelemetry. El contenedor del servicio constituye un entorno de ejecución; es necesario añadir un sandbox independiente cuando el agente ejecuta código no fiable.

8. AWS Lambda (por qué es la herramienta inadecuada)

El tiempo máximo de ejecución de una función Lambda Es de 900 s (15 minutos), lo cual es bastante difícil. Si el gateway API se encarga de ejecutar la función, el límite de integración depende del tipo de API. HTTP APIs permite 30 segundos; Las integraciones REST tienen como valor predeterminado 29 segundos, mientras que El REST regional y privado APIs permite configurar un tiempo de espera más prolongado.. Ninguno de esos enfoques convierte a Lambda en un proceso que funcione durante horas. Un proceso harness de ejecución prolongada sigue necesitando estado externo y una nueva invocación, lo que implica volver a crear la estructura de cola y trabajador. Utiliza Lambda para tareas tool calls con límites definidos, como la obtención de archivos o las subidas a S3, las cuales deben ser invocadas por un orquestador de ejecución más larga. No coloques el orquestador allí.

Como máximo, Lambda puede albergar un tool call dentro de su límite de 15 minutos. El harness, es decir, la sesión, así como el checkpoint y el sandbox, junto con el seguimiento, deben residir en otro lugar.

9. Tarea de AWS ECS / Fargate por ejecución

La documentación de Fargate no establece un límite máximo para las tareas runtime, a diferencia de Lambda. Cuotas de limitación de Fargate Permite un volumen inicial de lanzamiento de 100 unidades, con reabastecimiento a una tasa de 20 unidades por segundo, e incluye presupuestos independientes para solicitudes bajo demanda y operaciones spot. Cuotas de servicio ECS Capacitar los servicios mediante el descubrimiento con AWS Cloud Map a una tasa de 1,000 tareas por servicio, y los clústeres respaldados por EC2 a 5,000 instancias de contenedor.

Fargate exige awsvpc En este modo, cada tarea dispone de una interfaz de red y una IP privada. Esa estructura es adecuada para el acceso a datos dentro de la VPC. Fargate Spot conlleva un riesgo de interrupciones, y la durabilidad de los datos sigue siendo responsabilidad del desarrollador, ya que la plataforma no cuenta con mecanismos de reproducción similar al de Temporal.

Fargate aloja el harness y asigna una tarea distinta para cada ejecución. Esto permite separar los espacios de trabajo de las credenciales de las tareas, pero por sí solo no constituye una protección completa contra código malicioso según el sandbox. La gestión de sesiones, checkpoint, y el seguimiento de trazas se realizan mediante servicios externos como RDS o DynamoDB, además de CloudWatch/X-Ray.

10. Job de Kubernetes o espacio de nombres por sesión

Es útil cuando ya estás trabajando con ello. Kubernetes y se desea sandbox-por sesión junto con controles a nivel de clúster. Esto resulta problemático cuando se necesita un tiempo de inicio inferior a un segundo, ya que la descarga de la imagen del contenedor y la inicialización del pod tardan demasiado en un arranque desde cero. El patrón consiste en ejecutar un Job por cada agente. activeDeadlineSeconds, un PersistentVolumeClaim para el espacio de trabajo, y un sidecar para el servidor MCP. La recuperación ante fallos corresponde a que usted la implemente. Adoptar Kubernetes únicamente para alojar agentes conlleva costos elevados debido al sobrecargo en la configuración y a la carga operativa. Solo merece la pena si ya está utilizando K8s por otros motivos.

Kubernetes aloja el harness y el entorno de ejecución por ejecución, generalmente como un Job y, en ocasiones, con un espacio de nombres dedicado. Una fuerte isolación sigue dependiendo de la clase runtime, las políticas de red, la seguridad del pod, así como de los límites del contenedor o máquina virtual subyacentes. La sesión y el estado checkpoint se almacenan en una base de datos externa o en un PersistentVolumeClaim.

11. Docker Compose local (solo para entorno de desarrollo)

Referencia para la sección siguiente. La finalidad de esta estructura es reproducir de forma idéntica la topología de producción (mismas primitivas, misma configuración de red), aunque todo funcione dentro de un único servidor. Antes de desplegar cualquier solución similar, lea la lista de elementos “no seguros para entornos de producción” que aparece al final de la sección siguiente.

Se compone el esquema mirrors shape #2 en un único host. Postgres gestiona la sesión y el estado checkpoint, mientras que el contenedor worker actúa como harness. El montaje del espacio de trabajo compartido resulta práctico para el desarrollo, pero no aísla las ejecuciones no confiables. La pila opcional OpenTelemetry se encarga de registrar los rastros.

Stack de referencia: Docker Compose

La topología de referencia, utilizada en slavadubrov/market-analyst-agent, es un trabajador de LangGraph, un checkpointer de Postgres. Qdrant Para la recuperación de información, se utiliza un sidecar MCP, una cola de Redis para ejecuciones asíncronas similares a las en entorno de producción, y una opción adicional Prometheus / Grafana / Loki / Tempo / OTel stack de observabilidad. En Local Compose, Redis es opcional únicamente porque el ejecutor síncrono puede llamar directamente al trabajador. docker compose up Se carga toda la topología de forma local.

El único elemento que merece mostrarse de forma inline es el esquema de conexión canónico de LangGraph. Se trata del ejemplo concreto más sencillo de la primitiva checkpoint:

import os
from urllib.parse import quote

from langgraph.checkpoint.postgres import PostgresSaver

password = quote(os.environ["POSTGRES_PASSWORD"], safe="")
DB_URI = f"postgresql://agent:{password}@postgres:5432/agent"
with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()  # creates tables on first run
    graph = builder.compile(checkpointer=checkpointer)

Observabilidad que persiste durante la ejecución

Los manejadores de solicitudes de corta duración son fáciles de depurar: cuando algo falla, basta con leer la respuesta y el registro en tiempo real. Los agentes que ejecutan tareas durante largos periodos no cuentan con esa ventaja. Para cuando falla una ejecución de seis horas, el evento relevante ya ocurrió hace cinco horas, la salida del terminal en tiempo real ha desaparecido y el proceso que la generó ya ha sido reemplazado. Nadie va a poder reconstruir la ejecución basándose únicamente en su memoria. Por lo tanto, se realiza la depuración a partir de artefactos duraderos que se generaron mientras la ejecución aún estaba activa.

Las pilas de producción suelen abarcar cuatro tipos de artefactos, agrupados en dos categorías. Dos de ellos se consultan después de que finaliza la ejecución, con fines de análisis posterior y reproducción: un registro de eventos consultable que detalla cada paso, y rastros OpenTelemetry que indican cómo se han empleado el tiempo y los tokens. Los otros dos se consultan durante la ejecución, para seguir su desarrollo en tiempo real: un historial en vivo de lo que el agente genera en el espacio de trabajo, y una pila de observabilidad por worktree que el propio agente puede consultar mientras sigue en ejecución.

Registro estructurado de eventos (se consulta tras la ejecución)

Cada llamada al modelo, tool call, resultado, error y aprobación se escriben en un almacenamiento duradero, indexados mediante el ID de sesión y la marca de tiempo. Una vez finalizada la ejecución, se pueden consultar como en una tabla de base de datos habitual. Addy Osmani establece estándares claros al respecto. Agentes de ejecución prolongada: Si no es posible reconstruir lo que realizó el agente en las últimas 24 horas a partir de un almacenamiento duradero, lo que se tiene en realidad es un script shell de ejecución prolongada que, por casualidad, llama a un LLM, y no un agente en funcionamiento continuo.

OpenTelemetry Registros de GenAI (se leen tras la ejecución)

El mismo tipo de datos paso a paso, pero emitidos como spans mediante los atributos estándar del gen_ai.* convenciones semánticas: nombre del modelo, proveedor, cantidad de tokens de entrada y salida, ID de la conversación, nombre del flujo de trabajo (estado de desarrollo a fecha de v1.36.0). Los campos específicos del proveedor se encuentran en subespacios de nombres.anthropic.*, openai.*) desactivado mediante clave gen_ai.provider.nameLa razón para utilizar la norma es la portabilidad: el mismo rastro se muestra de forma nítida en Tempo, Jaeger, Honeycomb o LangSmith, sin necesidad de volver a instrumentar el código cada vez que se cambia de backend.

Cronología de las llamadas a herramientas más diferencias del espacio de trabajo (se leen durante la ejecución)

La forma más rápida de saber qué está haciendo un agente en este momento es seguir de cerca lo que genera en el espacio de trabajo, y no buscar entre los registros de sesión. Anthropic’s Harness Primitivas para agentes Claude de ejecución prolongada El paquete de inicio rápido incluye dos ganchos para ello: watch -n 5 'git log --oneline -8' Muestra los últimos commits que ha realizado el agente, y watch -n 5 'find screenshots -name "*.png" | tail -5' Muestra las capturas de pantalla más recientes que ha generado. Basta con observar los dos paneles de la terminal, que se actualizan cada cinco segundos, para determinar si una ejecución está avanzando realmente o simplemente está en estado de espera.

Pila efímera por worktree (leída por el propio agente durante su ejecución)

Por El artículo de OpenAI sobre harness: “Los registros, métricas y trazas se exponen en Codex a través de una pila de observabilidad local que es efímera para cada worktree concreto”. Cada agente worktree dispone de su propio conjunto temporal de herramientas Loki + Prometheus + Tempo, limitado únicamente al funcionamiento de esa instancia en particular. El agente consulta estos datos mientras está en ejecución. Gracias a esto, una prompt como “ningún span en estas cuatro rutas de usuario supera los dos segundos” puede convertirse en algo que el agente puede verificar directamente, en lugar de tener que estimarlo.

El evaluador de contexto fresco de la tabla de modos de fallo lee estos artefactos para determinar si se ha alcanzado el estado “listo”. Pertenece al ámbito de la evaluación, no a la observabilidad; véase § Ciclo de vida de ejecución saludable.

Una pila mínima de observabilidad autohospedada

Para algo similar a market-analyst-agent:

1. OpenTelemetry Collector, junto con el procesador GenAI y un filtro de atributos gen_ai.*.
2. Tempo (o Jaeger) para trazas, indexado por gen_ai.conversation.id / thread_id.
3. Loki para entradas estructuradas de registros de eventos.
4. Prometheus para gen_ai.client.token.usage, gen_ai.client.operation.duration, gen_ai.server.time_to_first_token (véase el Convenios de métricas en GenAI).
5. Paneles de Grafana basados en gen_ai.agent.name y gen_ai.request.model.

Alternativas alojadas (elija una, no tres):

• LangSmith: Integración nativa con LangGraph; también es el destino de despliegue para Deep Agents Deploy. Equipo de expertos: La opción más adecuada cuando las suites de regresión basadas en la evaluación previa son la prioridad.
• Arize Phoenix: OSS, nativo de OTLP, se combina con OpenInference Instrumentación.
• El panel de seguimiento de OpenAI: se activa automáticamente al utilizar los OpenAI Agents SDK o su integración Temporal.
• El seguimiento de Claude de Anthropic: para sesiones que se ejecutan dentro de los Managed Agents.

Instrumentar el nodo de LangGraph

# In the LangGraph node, around the model call:
span.set_attribute("gen_ai.operation.name", "chat")
span.set_attribute("gen_ai.provider.name", "anthropic")
span.set_attribute("gen_ai.request.model", "claude-sonnet-4-5")
span.set_attribute("gen_ai.response.model", "claude-sonnet-4-5")
span.set_attribute("gen_ai.conversation.id", thread_id)
span.set_attribute("gen_ai.agent.name", "market-analyst")
span.set_attribute("gen_ai.workflow.name", "research_then_write")
span.set_attribute("gen_ai.usage.input_tokens", usage.input_tokens)
span.set_attribute("gen_ai.usage.output_tokens", usage.output_tokens)

Los nombres de atributos tomados literalmente del OpenTelemetry Registro de convenciones semánticas de GenAI.

Consultas para tres fallos comunes

# Loki: token usage per agent over 1h
sum by (gen_ai_agent_name) (
    rate({service_name="market-analyst-agent"} | json | unwrap gen_ai_usage_output_tokens [1h])
)

# PromQL: p95 model latency per model
histogram_quantile(0.95,
    sum by (le, gen_ai_request_model) (
        rate(gen_ai_client_operation_duration_bucket[5m])
    )
)

# TraceQL: long-running tool calls
{ span.gen_ai.operation.name = "execute_tool" && duration > 30s }

El patrón de paquete de depuración

Cuando una ejecución falla, el worker debe interrumpirla. /workspaces/${THREAD_ID}/_debug/ que contiene los artefactos que se solicitarían en un postmortem:

• session.jsonl: descarga completa del registro de eventos desde PostgresSaver (checkpointer.list({"thread_id": ...})).
• last_state.json: StateSnapshot.values a partir del último super-paso exitoso. trace.json: Los spans exportados en OTLP correspondientes a la ejecución.
• tool_calls.csv: (ts, tool, input_hash, latency_ms, status, error).
• workspace.tar.zst: el directorio del espacio de trabajo más git diff en contra del commit de inicialización. screenshots/*.png: Lo que observó el agente.
• PROGRESS.md, feature-list.json, y cualquier otro archivo de progreso generado por el agente. env.txt: etiquetas de imagen, versión del modelo, SHA del commit harness.

Este paquete proporciona al agente humano o de revisión pruebas suficientes para reconstruir la causa del fallo. La expresión “El agente se atascó” es vaga. Un informe ilustrativo, en cambio, es concreto: sesión s_123 Pasó el 71 por ciento de sus tokens repitiendo tres comandos seguidos después de npm install ¡Falló!

Elegir la forma adecuada: una guía de decisión

La mayor parte de las comparaciones anteriores se reducen a un número limitado de decisiones a tomar.

Comience con la longitud de secuencia continua

Utilice la longitud de secuencia como el primer filtro:

• Menos de 30 segundos, idempotente: ciclo de vida de la solicitud SDK en un servidor de aplicaciones.
• De 30 s a 60 min, sin necesidad de recuperación ante caídas: cola + trabajador + base de datos checkpoint.
• De 60 min a 24 h: misma cola + trabajador, o un Cloud Run Job para tareas puntuales. Se recomienda utilizar un motor de flujos de trabajo duradero si también se requiere control de versiones y capacidad de reproducir los procesos.
• Más de 24 h, debe resistir los despliegues: motor de flujos de trabajo duradero (estilo Temporal). Los Cloud Run Jobs pueden almacenar trabajos prolongados hasta alcanzar su límite de tareas, pero no ofrecen funcionalidades de reproducibilidad.
• Bucles de entrenamiento por RL de varios días: K8s Job + volumen de almacenamiento + Temporal.

Tras aplicar ese filtro grosero, se deben analizar los efectos secundarios, la capacidad de recuperación, la posibilidad de reproducir los datos, el aislamiento del sistema, la ubicación de los datos, así como el equipo que será responsable de operar el sistema.

Adecuación de la plataforma según el caso de uso

La matriz es densa porque ninguna celda verde individual determina la arquitectura. Aunque es útil contar con una amplia cobertura de cargas de trabajo, esta no refleja la residencia de los datos, las semánticas de reproducción, la dependencia del proveedor, el nivel de madurez operativa, ni el costo asociado a mover el estado en etapas posteriores.

Deep Agents Deploy abarca todos los tipos de cargas de trabajo registrados en la matriz, lo que lo convierte en una opción adecuada cuando una sola plataforma debe gestionar ejecuciones breves, tareas que duran varias horas, agentes de código, agentes de investigación y trabajos programados. Dicha amplitud implica un historial de implementación en producción más corto en comparación con una arquitectura basada en colas, workers y Postgres. Considere las celdas verdes como afirmaciones de funcionalidad que deben validarse, y luego analice las restricciones operativas que la matriz no puede reflejar.

Los Agentes Gestionados de Anthropic se adaptan o bien a toda tu carga de trabajo o bien no se adaptan en absoluto. El producto presenta tres restricciones estrictas: está diseñado exclusivamente para entornos alojados, solo funciona con Claude, y las sesiones duran menos de 24 horas. Si tu carga de trabajo cumple con estos tres requisitos, por ejemplo un agente de programación interno que ejecuta sesiones de 2 a 6 horas y prefieres no gestionar tú mismo a harness, los Agentes Gestionados son una opción ideal, ya que eliminan una gran parte del trabajo relacionado con la plataforma de tu equipo. Sin embargo, si alguna de estas restricciones no se cumple —por ejemplo, porque necesitas un modelo distinto a Claude, un entorno autoalojado o sesiones de 48 horas—, los Agentes Gestionados no son adecuados. Ningún tipo de cambio en la configuración puede superar esas limitaciones.

Es recomendable modelar los costes antes de tomar una decisión, y no después. La tarifa por hora de sesión es de 0,08 $/hora, además de los costes estándar por tokens. Si una sola sesión se ejecutara de forma continua, el costo sería de aproximadamente 58$ al mes por sesión. Con 100 sesiones en ejecución continua, el coste asciende a unos 5.800 $al mes, _sin contar los tokens_. Multiplique 0,08$ por las horas estimadas de sesiones simultáneas, añádalo a la factura de tokens y compárelo con el coste que supondría utilizar una cola de tareas y un conjunto de workers en su propia infraestructura. Haga esto antes de comprometerse, ya que migrar posteriormente de los Agentes Gestionados implica un proceso de replataformación, y no solo un cambio de configuración.

Servicios alojados harness frente a soluciones propias harness

La distinción aquí es operativa y no está relacionada con quien escribió el código de harness. Hosted se refiere a que el proveedor ejecuta el bucle de harness en su propia infraestructura, y el usuario solo realiza una llamada a API. En cambio, Owned implica que el propio usuario ejecuta dicho bucle en su infraestructura, independientemente de que el código de harness provenga de un proveedor.

LangChain aparece en ambos lados de esta línea, lo que confunde a los usuarios. Ofrecen LangGraph, una biblioteca con licencia MIT que se instala y se gestiona localmente (es de propiedad del usuario), y Deep Agents Deploy, un producto gestionado que ejecuta agentes profundos. harness en el despliegue de LangSmith en su modo cloud predeterminado (hosted). La misma empresa, pero con dos modelos operativos distintos. Tú eliges el modelo, no el proveedor. (Deep Agents Deploy también dispone de un modo autohosted para equipos que lo deseen) harness ergonomía sin el componente en la nube; ese modo se almacena en el bucket propio.)

Elija un harness alojado cuando su soporte de modelo, sus límites de datos, su comportamiento de recuperación y sus puntos de extensión ya se ajusten a las necesidades. Opte por un harness propio cuando dichas restricciones sean requisitos que pretende modificar posteriormente. La migración entre uno u otro cambia los estados, la capacidad de observabilidad y los límites de ejecución, por lo que es necesario probar la ruta de salida antes de que los datos en producción dependan de ella.

Entorno sandbox alojado frente a un entorno de ejecución propio

Elija un sandbox alojado cuando la capacidad de aislamiento del proveedor, las funcionalidades de pausa/reanudación o las semánticas de fork se ajusten al modelo de amenazas y al presupuesto de puesta en marcha. Docker o Fargate son adecuados para cargas de trabajo internas de confianza que necesitan acceso a una VPC o una estricta residencia de datos, pero un contenedor estándar no constituye una barrera suficiente contra código hostil. Es necesario incorporar gVisor, Kata, una microVM u otro runtime reforzado cuando el agente instala paquetes no confiables o ejecuta programas generados.

Almacenes de estado: Git, bases de datos y almacenamiento de objetos lado a lado

Git almacena el estado del espacio de trabajo: el código, los documentos y los archivos de progreso que modifica el agente. Cada commit proporciona a harness un punto de recuperación estable y una historia compacta para la sesión siguiente.

La base de datos checkpoint almacena el estado del grafo: qué decisiones se tomaron, qué nodos se ejecutaron, qué resultados se devolvieron y qué debe ejecutarse a continuación. El repositorio de artefactos guarda los grandes resultados finales, como archivos PDF, archivos Parquet y capturas de pantalla. Dichos artefactos no deben encontrarse en Git ni en la base de datos checkpoint.

Cuándo utilizar git como estado

Utilice Git cuando la carga de trabajo tenga forma de código (ediciones en múltiples archivos, refactorizaciones, generación de aplicaciones) o sea lo suficientemente documental como para que el historial de archivos sea relevante. El patrón es sencillo: cree una rama de ejecución, realice un commit inicial y, a continuación, haga commits en puntos clave: tras la configuración, después de cada funcionalidad, una vez superadas las pruebas y al finalizar la limpieza. Almacene el SHA del último commit del espacio de trabajo junto a la fila checkpoint. Al reanudar, el siguiente trabajador descarga la rama y lee git log --oneline -8, inspecciona git status y la última diferencia, y a continuación la lee. PROGRESS.md o cualquier archivo de transferencia que haya escrito la sesión anterior.

Eso hace que git funcione como una superficie de recuperación para el artefacto que se está editando, y no como un sustituto de la checkpoint base de datos. Git puede responder a dos preguntas: qué ha cambiado y qué versión superó las pruebas. No puede indicarle al harness qué nodo del grafo debe ejecutarse a continuación, qué tool call está esperando aprobación, ni cuál de los intentos de reintentar ya utilizó su clave de idempotencia. El harness de Anthropic emplea commits iniciales además de commits por característica como fuente de verdad para la recuperación del espacio de trabajo; el modelo lee git log --oneline -8 Para recuperar el estado. Se debe omitir Git cuando el producto del trabajo es una única respuesta conversacional, ya que la sobrecarga generada no justifica el esfuerzo.

Cuándo utilizar los puntos de control de la BD

Utilizar PostgresSaverEl sistema de checkpoints por estilo se emplea cuando el agente cuenta con una estructura de grafo formada por múltiples nodos cuyo estado intermedio es crucial (planificador → investigador → redactor → verificador). El repositorio de referencia utiliza este enfoque precisamente por esa razón. No se deben almacenar los artefactos del espacio de trabajo a escala de terabytes en checkpoint; dichos archivos deben ir al almacenamiento de objetos.

Cuándo utilizar un almacén de artefactos (S3 / GCS)

Utilice el almacenamiento de objetos cuando:

• La salida es más grande de lo que la base de datos checkpoint debería poder almacenar;
• Los consumidores finales necesitan un artefacto accesible mediante URL sin tener que pasar por el agente; o
• El resultado final y el estado de ejecución tienen períodos de retención diferentes.

Por ejemplo, es posible eliminar el registro de sesión después de 30 días, pero conservar el informe final durante años. Defina la estructura según (thread_id, checkpoint_id, artifact_name) De este modo, la ejecución de generación se mantiene reconstruible.

Cuándo añadir pasos de aprobación humana

Añada compuertas de control cuando tool call sea destructivo e irreversible (escrituras en bases de datos, movimientos de dinero, envío de comunicaciones externas), cuando tool call salga del radio de influencia del agente (despliegues en entorno de producción, publicaciones dirigidas a clientes), o cuando las autoridades reguladoras exijan una revisión. LangGraph’s interrupt() Tanto el middleware de aprobación de los Agentes Profundos como las soluciones tradicionales cuentan con soporte integrado para estos controles de acceso. Parte 4 Se explica por qué estas compuertas representan un problema de permisos y no un problema relacionado con prompt.

Lista de verificación práctica para producción

Antes de lanzar un agente de ejecución prolongada, responda a estas preguntas utilizando términos concretos relacionados con la infraestructura.

1. ¿Qué almacén es responsable de los eventos de sesión y de checkpoints?
2. ¿Qué ocurre si el trabajador se detiene a mitad de un tool call?
3. ¿Es posible que una ejecución dañe el espacio de trabajo de otra ejecución?
4. ¿Qué acciones requieren aprobación?
5. ¿Puede el modelo o sandbox leer credenciales en bruto?
6. ¿Qué tool calls puede intentarse nuevamente de forma segura?
7. ¿Dónde se aplica el límite de costo por ejecución?
8. ¿Qué verificación de contexto fresco determina que una tarea está “completada”?
9. ¿Dónde se almacenan los resultados finales una vez que el sandbox ha finalizado?
10. ¿Podemos explicar una ejecución fallida al día siguiente sin tener que volver a ejecutarla?

Si la respuesta a alguna de estas preguntas es “el prompt indica al agente que debe tener cuidado”, entonces el sistema aún no se ha desplegado; sigue siendo una versión de demostración.

La siguiente capa es el bucle harness

Este runtime permite que un proceso permanezca activo y sea recuperable, pero la durabilidad no demuestra que el trabajo sea correcto. Parte 6, Harness Engineering para Agentes AI, Aborda el bucle asociado al modelo: cómo un seguimiento se convierte en un caso de prueba, dónde se definen las reglas de reintentos y detención, qué debe conservarse durante la transferencia de responsabilidades, y cómo una verificación externa de aceptación determina que una ejecución ha finalizado.

Referencias

Documentación de ingeniería

• OpenAI, Harness engineering: aprovechar Codex en un mundo orientado a los agentes.
• Ingeniería Anthropic, Mecanismos eficaces para agentes de ejecución prolongada.
• Ingeniería Anthropic, Harness diseño para el desarrollo de aplicaciones de ejecución prolongada.
• Ingeniería Anthropic, Escalar agentes gestionados: desacoplar el cerebro de las manos, 8 de abril de 2026.
• Cognición AI, Reconstruyendo Devin para Claude Sonnet 4.5: lecciones y desafíos.
• Vercel, Hemos eliminado el 80 % de las herramientas de nuestro agente..
• Addy Osmani, Agentes de ejecución prolongada.

LangGraph y agentes profundos

• Documentación de LangGraph, Persistencia.
• Referencia de LangGraph, Checkpoints.
• langgraph-checkpoint-postgres en PyPI.
• Documentación de LangChain, Visión general de los Agentes Profundos.
• Blog de LangChain, El runtime detrás de los Agentes Profesionales en producción.

Agentes de OpenAI SDK

• Agentes de OpenAI SDK, Sesiones.
• Agentes de OpenAI SDK, Sandbox conceptos.

Temporal

• Blog temporal, Presentamos Temporal y agentic sandboxes: los SDK de OpenAI para agentes..
• Blog temporal, Agentes listos para producción con OpenAI Agents SDK + temporal.
• Temporal × OpenAI Agents SDK contrib README (temporalio/sdk-python).

Plataforma Anthropic

• Anthropic, Precios de la plataforma Claude: Tarifas por hora de sesión de los agentes gestionados. anthropics/cwc-long-running-agents: Código para llevar a casa con Claude 2026, que incluye un subagente evaluador y patrones de archivo de progreso.

Proveedores Sandbox

• ZenML, E2B frente a Daytona: comparativa sandbox para ingenieros de plataforma.
• Documentación de Daytona, Sandboxes.
• Registro de cambios de Daytona, Sandbox fork y puntos de extremo para snapshots.
• Documentación modal. Sandboxes.
• Documentación modal. Guía de arranque en frío.
• Runloop en AWS Marketplace.
• Vercel Sandbox: precios y límites.

Tiempos de espera y cuotas de la plataforma en la nube

• Google Cloud, Configurar el tiempo de espera de solicitud para los servicios.
• Google Cloud, Uso de WebSockets.
• Google Cloud, Establecer el tiempo de espera de tarea para los trabajos.
• AWS, Configurar el tiempo de espera de la función Lambda.
• AWS, Cuotas de Lambda.
• AWS, Cuotas de limitación de Fargate.
• AWS, Cuotas de servicio ECS y límites de limitación de API.

Observabilidad

• OpenTelemetry, Convenciones semánticas para sistemas generativos AI.
• OpenTelemetry, Registro de atributos Gen AI.
• OpenTelemetry, Convenciones semánticas para los agentes de GenAI y los spanes de framework.
• OpenTelemetry, Convenciones semánticas para las métricas generativas de AI.

Series

• Parte 1: AI Bucles de razonamiento de agente en 2026: ReAct, ReWOO y Plan-and-Execute. Parte 2: AI Arquitectura de memoria de agente en 2026: checkpoints, almacenes vectoriales y memoria de documentos. Parte 3: AI Agente Tool Use en 2026: MCP, CLI, habilidades, ejecución de código y ACI.
• Parte 4: AI Seguridad de agentes en 2026: reglas de contención, permisos, sandboxes, HITL y delimitación de alcance con MCP.
• Parte 5: Agente AI de ejecución prolongada Runtime en 2026 (esta publicación) Sección 6: Harness Engineering para agentes AI: comprobaciones de aceptación, trazas, intentos de reintentado, transferencias y el bucle de iteración alrededor del modelo.

El código del agente de análisis de mercado (trabajador LangGraph, checkpointer de Postgres, memoria de Qdrant, sidecar MCP, y la topología de Docker Compose descrita anteriormente) se encuentra en GitHub._