Quick answer: DeepSeek Harness incluye un documento breve de patrones defensivos, cada uno escrito como regla general junto al bug concreto que lo motivó. Es el archivo más transferible del repositorio: nada de...

Siete patrones defensivos de la documentación de DeepSeek Harness

Updated August 16, 2026 · first published August 16, 2026

DeepSeek Harness incluye un documento breve de patrones defensivos, cada uno escrito como regla general junto al bug concreto que lo motivó. Es el archivo más transferible del repositorio: nada de ello exige adoptar el harness, y cada punto corresponde a un modo de fallo que aparece en runtimes de agentes caseros.

1. Reporte los resultados ortogonales por separado

Nunca anide el reporte de una bandera dentro del condicional de otra. Un proceso puede agotar el tiempo y salir con cero, porque atrapó la señal y se apagó limpiamente. Si el timeout solo se reporta dentro de la rama de salida distinta de cero, ese resultado desaparece. Timeout, señal y código de salida son hechos independientes y necesitan campos independientes.

Relevancia de coste: los timeouts tragados en silencio son cómo se forman los bucles de reintento. El llamador ve éxito, no obtiene nada útil y vuelve a intentarlo.

2. Honre los contratos públicos por ambos lados

Cuando un resultado tiene varias representaciones válidas, normalícelas antes de exponerlas. El ejemplo trabajado son los fallos de petición al modelo: las implementaciones pueden lanzar o emitir un chunk de finalización con error, y la frontera de la API lo normaliza todo a un chunk terminal. Sin eso, un llamador que captura una excepción no puede saber si vino del proveedor, del middleware, del logging o de su propio código.

3. El estado asíncrono no es estado síncrono

Las consultas de estado no están causalmente ligadas a operaciones asíncronas concretas. Esperar el estado idle de un agente como señal de finalización de un mensaje es un error, porque varias operaciones en cola comparten intervalos de ejecución: el idle puede llegar antes de que corriera el suyo, o después del de otro.

La corrección prescrita: un llamador de automatización dueño de una ejecución define su intervalo explícitamente, desde la recepción en la bandeja hasta el siguiente idle del agente completo, y atribuye salidas a ese intervalo en vez de a mensajes sueltos. Cubra también la rama de nada-que-esperar, o el llamador cuelga indefinidamente.

Un harness de automatización que se cuelga esperando la señal de idle equivocada mantiene residentes una sesión y sus hijos. La factura de eso no es el cuelgue: es todo lo que sigue vivo detrás.

4. Liberar debe alcanzar la quiescencia, no solo pedirla

Pedir la terminación no es lograrla. El dispose espera la terminación real de los hijos antes de retornar. Y los registros de escuchas se cierran antes de enviar las señales de kill, para que las finalizaciones tardías aterricen en silencio en vez de disparar callbacks contra un sistema a medio desmontar.

Este es el patrón con el filo financiero más claro. Un dispose que retorna pronto deja subprocesos huérfanos y sandboxes sin cerrar corriendo, y el cómputo medido no se detiene porque su padre se olvidara de él.

5. Contenga las excepciones de callback en el despachador

Envuelva los bucles de despacho en try/catch. Un suscriptor que falla no debe rechazar la promesa de despacho ni matar de hambre a las escuchas encoladas detrás. En un runtime de agentes, la escucha hambrienta suele ser justo la que hace la contabilidad, y así los registros de uso desaparecen sin que aflore ningún error.

6. Nunca dé a una salida no confiable el entorno ambiental ni rutas predecibles

La regla más fuerte del documento y la primera a adoptar. Limpie el entorno de los comandos lanzados: elimine variables que casen con key, secret, token y password antes de que arranque el subproceso. Use directorios privados creados con permisos solo para el dueño, nombres de archivo aleatorios y aperturas exclusivas en vez de rutas predecibles.

Dos amenazas distintas. La limpieza de entorno evita que las credenciales del harness se filtren en la salida del subproceso que luego lee el modelo, y una vez leída esa salida está en el registro de sesión y en la ventana de contexto. Los nombres aleatorios y la creación exclusiva cierran carreras de symlink en directorios temporales compartidos.

7. Desenlace las rutas con forma de enlace

Compruebe si una ruta es un enlace simbólico antes de borrarla, y borre el enlace en lugar de seguirlo. El borrado recursivo se reserva a directorios reales confirmados, porque puede atravesar symlinks hacia sus destinos y lanza sobre junctions. Código de limpieza que borra más de lo que creó es un modo de fallo sin techo de daño.

Cómo usar esta lista

  1. Lleve hoy los patrones 1 y 4 a su código de desmontaje de subprocesos y sandboxes. Ahí es donde se fuga el dinero.
  2. Lleve el patrón 6 a cualquier sitio donde lance un proceso cuya salida vaya a leer el modelo.
  3. Lleve el patrón 3 a su capa de automatización, sobre todo donde una espera se exprese como "hasta que el agente esté idle".
  4. Lleve el patrón 5 a su pipeline de telemetría y compruebe que una escucha que falla no puede matar de hambre a la de contabilidad.

Related


Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit →

Back to research