Leer logs Trajectory de DeepSeek Harness

Leed la cabecera de sesión antes que la burbuja del chat

Para leer un log Trajectory de DeepSeek Harness después de un fallo, saltad la última burbuja y abrid el log de sesión durable. Las notas de persistencia JSONL describen un log lógico solo-append por sesión, guardado como .jsonl.zstd por defecto, o .jsonl en crudo si la compresión está apagada. La primera línea lógica es la cabecera: type: session, más version, id, cwd opcional, createdAt, parentSession opcional y un delegationDepth obligatorio. agentPreset se guarda porque decide qué herramientas y qué prompt puede usar una reanudación.

En una sesión de nivel superior, delegationDepth es 0. Si falta o es inválido, el log se rechaza. Si el número no es cero, estáis dentro de una sesión delegada: un nombre de herramienta que no pertenece al preset que pulsasteis puede ser del hijo. parentSession apunta hacia arriba. cwd es la raíz del workspace que quedó ligada — la primera pregunta de la introducción al log de sesión. Esta página es el orden de lectura cuando esa pregunta ya es sobre una ejecución fallida.

El catálogo de persistencia en la rama por defecto fija SESSION_FORMAT_VERSION en 0 y dice que un formato de preview no promete compatibilidad. Las notas del RC 0.1.5 de este sitio describen una subida de datos de sesión que no se puede leer como el formato viejo. No son el mismo entero. Leed el campo version de la cabecera que decodificasteis. Si un lector propio se escribió para otra generación, arreglad el lector.

Cada línea posterior es un registro de almacenamiento. Tras decodificar, los números de secuencia quedan contiguos: el evento en el índice i tiene seq === i. Un hueco significa que el lector soltó una fila — a menudo una línea de chunk empaquetada, o un tipo de evento de plugin que no conocía — no que el modelo borró el historial. Un plugin aguas abajo puede fusionar tipos que el catálogo de persistencia no lista.

Emparejad cada tool/call con un tool/result

El catálogo parte los eventos en superficie y solo-log. Los de superficie se vuelven mensajes para el LLM. En esta lectura importan user/message, assistant/message y tool/result. tool/call es solo-log. Una exportación del chat puede mostrar el texto del resultado y seguir ocultando los argumentos en crudo que emitió el modelo.

Un tool/call lleva turn, step, callId, name y arguments. arguments es la cadena JSON en crudo, sin parsear, tal como la produjo el modelo. callId lo empareja con tool/result. El resultado lleva turn, step, un mensaje de resultado, un error opcional con name y code, y un meta opcional. meta tiene que ser JSON. La herramienta de archivos dsh-tool-fs puede dejar ahí un diff del momento del resultado; que otras herramientas no traigan meta es normal.

Recorred las llamadas desde el final. El fallo suele ser el último callId sin resultado, o un resultado con error. No abráis tres plugins a la vez. Si name es una herramienta que no pensabais cargar, parad y usad la checklist de seguridad de plugins antes de volver a preguntar.

TOOL_NOT_STARTED o TOOL_OUTCOME_UNKNOWN

Las notas del núcleo de sesión dan dos frases de recuperación. No son sinónimos.

• TOOL_NOT_STARTED — hay una petición de herramienta del asistente, pero no se grabó un tool/call durable. La redacción de aguas arriba: la llamada se interrumpió antes de que el Harness la registrara como iniciada, y se puede reintentar si sigue haciendo falta. No tenéis evidencia de que la herramienta corriera.
• TOOL_OUTCOME_UNKNOWN — existe un tool/call durable y no se grabó resultado. El desenlace es desconocido. Reintentad solo si la operación es de solo lectura o idempotente. Si puede tener efectos secundarios, verificad el estado externo o preguntad. No reintentéis a ciegas.

Un shell sigue la misma forma con otros tipos: command/run se empareja con command/done por commandId, y command/run es solo-log. Un run sin done es la versión de shell de una llamada sin resultado. Mirad el workspace antes de enviar «inténtalo otra vez».

llm/retry también es solo-log: un reintento del proveedor tras una petición fallida. Una petición de modelo fallida no tiene assistant/message. Si el chat parece que el modelo se calló, buscad llm/retry o un mensaje de asistente ausente antes de culpar a una herramienta. Las filas de uso, cuando existen, son assistant/chunk de tipo usage; assistant/message.usage solo es el respaldo cuando no hay chunk de uso.

Filas solo-log que el chat no enseña

Las aprobaciones son una auditoría, no una burbuja. approval/asked y approval/decided comparten un id y ambas son solo-log. Si alguien dice que el agente lanzó un shell sin preguntar, encontrad esas dos filas antes de discutir el texto de la interfaz. La etiqueta del botón en una preview se mueve; los tipos de evento son lo que el catálogo nombra hoy.

Tres o más deltas seguidos de assistant/chunk del mismo bloque pueden guardarse como una fila empaquetada: text-chunks, reasoning-chunks o tool-call-chunks. Esas etiquetas no llevan barra, así que no son tipos de evento. La carga las decodifica. Un archivo con menos líneas que el seq más alto no es historial truncado si esas filas empaquetadas están.

Un evento de log no es un evento Cordis. El catálogo dice que el bus en vivo es una emisión aparte, session/event. Hacer grep de un hook Cordis en el código del plugin no os enseña la línea durable.

Un pase de diez minutos

1. Decodificad el log (respetad .jsonl.zstd). Leed cwd, agentPreset, delegationDepth y version de la cabecera.
2. Confirmad que seq queda contiguo tras decodificar. Si no, arreglad el lector antes de interpretar un hueco.
3. Encontrad el último tool/call sin tool/result, o un resultado con error.
4. Clasificad el hueco como TOOL_NOT_STARTED o TOOL_OUTCOME_UNKNOWN antes de reintentar.
5. Si el nombre no se esperaba, descargad el último plugin. No añadáis otro.
6. Citad callId, name y el version de la cabecera en el bug. Una captura de la disculpa final no es una plantilla.

Lo que este orden no decide

Esto no es el ensayo de por qué existe una caja negra. Eso sigue en la introducción al log de sesión. El camino lento es el tutorial de observabilidad. Los nombres de agentPreset siguen significando lo que dice la página de modos; este artículo no elige Standard frente a PTC. «La UI está arriba y todas las tools están ciegas» sigue siendo solución de problemas, no un tool/result que falta.

Si el version de la cabecera o un nombre de tipo en vuestra etiqueta no coincide con el catálogo enlazado arriba, gana la etiqueta. La compatibilidad de la preview se rompe a propósito. Fijad la versión de DSH junto a los SHA de los plugins, y no abráis un bug con un log que el lector solo decodificó a medias.