Ejecutar DeepSeek Harness headless con --json

DeepSeek Harness headless no es la UI Web

DeepSeek Harness headless responde a otra pregunta que npx @deepseek-ai/dsh web. La vía Web arranca una UI local — suele ser http://127.0.0.1:3080/ — y permanece hasta que la paréis. Headless ejecuta una tarea, imprime la respuesta y sale. No abre puerto de escucha ni deja nada detrás. Es la superficie para scripts y CI, no para evaluar a golpe de clic el primer día.

Aguas arriba documentan el perfil como dsh --profile headless. Desde el paquete publicado la misma forma es npx @deepseek-ai/dsh --profile headless "run the tests". Fijad la versión que hayáis verificado — el 28 de septiembre de 2026, npm latest seguía siendo Pre-release RC — y tened a mano la lista de instalación para Node y credenciales. La identidad del producto está en Qué es DeepSeek Harness. La primera hora en el navegador sigue en el inicio rápido npx.

Si el README del paquete headless discrepa de esta página, gana el README.

Una tarea, luego salir

sh
npx @deepseek-ai/dsh --profile headless "Lista los archivos de primer nivel y cita el primer encabezado del README"

El modo por defecto imprime la respuesta final en stdout. El razonamiento no vacío del proveedor va a stderr bajo un encabezado dsh: reasoning:. Salida 0 significa un turno final completado; 1 significa aborto, error o ningún turno usable. Un fallo fuera de turno también imprime una línea dsh: en stderr.

Podéis alimentar la tarea desde stdin si omitís el argumento posicional, o pasáis un - solo:

sh
{ echo "Summarize these changes:"; git diff --stat; } | npx @deepseek-ai/dsh --profile headless

Un argumento posicional en blanco es un error de uso aunque haya un pipe esperando: no consumirá stdin en silencio. Mezclar - con otras palabras de tarea también es un error de uso. dsh --profile headless --help imprime ayuda y no ejecuta nada.

Sigue siendo un disparo. No hay seguimiento interactivo en el mismo proceso. Partid el trabajo en varias ejecuciones, o continudad con --session-id más abajo.

--json es un canal máquina, no Trajectory

--json sustituye la línea de texto final en stdout por un flujo de eventos JSON delimitado por saltos de línea. Stderr conserva solo diagnósticos dsh:. El flujo abre con session (la identidad de esta ejecución) y cierra con final. En medio podéis ver status, text, thinking, tool_call y tool_result.

Tratad ese flujo como una proyección para supervisores, no como un log de sesión sin pérdidas. Las cadenas distintas del final terminal tienen tope (aguas arriba documentan unos 8 KiB por cadena, con flag truncated). El log durable que abrís tras un fallo del agente sigue siendo Trajectory — cómo leer logs Trajectory y la introducción a observabilidad.

Un flujo bien formado puede describir una ejecución fallida: un fallo dentro del turno puede terminar con final (a menudo vacío) y sin evento error. Confiad en el código de salida 1 y en la razón de fin de turno. Un fallo que el runner lanza fuera de un turno escribe error y termina sin final.

--session-id rechaza un historial vacío en silencio

Cada ejecución crea por defecto una identidad session-… nueva. Con --json, ese id aparece en el evento session de apertura — guardadlo junto al cwd desde el que lanzasteis. Pasad --session-id en una invocación posterior para continuar esa conversación.

Un id desconocido falla antes de ejecutar la tarea. No inventa un historial vacío. La adopción también rechaza una sesión registrada bajo otro directorio de trabajo, un subagente o fork, un cwd ausente, un agente vivo que ya sostiene ese id en este proceso, o un preset que este perfil headless no compone. Esas negativas son el punto: un job de CI no debe conducir en silencio la conversación de otra persona.

Reanudad desde la misma carpeta desechable de la primera ejecución. Si Node o npx no arrancan, seguid en npx y el puerto 3080 — headless no usa 3080, pero un Node roto es el mismo suelo.

Pase de operador de diez minutos

1. Confirmad credenciales y el modelo por defecto como en Web. Headless no inventa otra historia de autenticación.
2. Ejecutad una tarea aburrida sin --json. Esperad texto en stdout y salida 0.
3. Repetid con --json. Guardad el id session de apertura y el cwd de lanzamiento.
4. Continuad una vez con --session-id desde el mismo directorio. Si hacéis cd antes, esperad rechazo.
5. Canalizad una tarea corta por stdin. Confirmad que un posicional en blanco no se apropia de ese pipe.
6. En CI, aceptad solo si la salida es 0 y — si usasteis --json — el flujo cerró con final y sin error fuera de turno.
7. Mantened stderr fuera de logs compartidos si el razonamiento puede llevar rutas sensibles. Enrutadlo vosotros.

Lo que este artículo no es

• No es un segundo inicio rápido Web — eso sigue en inicio rápido npx.
• No es el volcado de novedades del RC 0.1.7 — novedades de 0.1.7.
• No es una guía de Computer Use ni de espacios de trabajo remotos por SSH.
• No afirma que headless esté certificado para producción. Aguas arriba siguen avisando de roturas de compatibilidad en preview.

Dónde seguir

1. Contrato y flags: el README headless en la etiqueta que fijéis.
2. Primera hora en el navegador: instalación → inicio rápido npx.
3. Tras un fallo: cómo leer logs Trajectory.