¿Qué es DeepSeek Harness? El runtime de agentes donde todo es un plugin

¿Qué es DeepSeek Harness?

DeepSeek Harness, abreviado como dsh, es un runtime de agent harness de código abierto de DeepSeek AI bajo licencia MIT. Se sitúa entre un modelo de lenguaje y el mundo exterior, aportando herramientas, sesiones, sandboxing y el bucle que mantiene la tarea en marcha.

La propia formulación de DeepSeek es "Agente = Modelo + Harness". El modelo se encarga del razonamiento y la generación. El harness es todo lo que permite que ese razonamiento actúe sobre un sistema de archivos real y continúe sin que tengas que volver a explicar la tarea a cada paso.

Se ejecuta sobre Cordis, un framework de plugins anterior a DeepSeek Harness. Cordis permite sustituir estas piezas de forma independiente mediante la configuración. Volveré más adelante al coste de esa decisión.

Con ese marco, aquí van dos ideas equivocadas habituales.

DeepSeek Harness no es un modelo de IA

Como ya se ha dicho, el modelo y el runtime son capas separadas. Esa separación te permite cambiar de proveedor sin modificar las herramientas o la configuración de sesiones. El mismo runtime puede usar DeepSeek, Anthropic, OpenAI o un endpoint compatible con OpenAI.

DeepSeek Harness es más que un asistente de código

El modo Standard genera esa impresión, pero es solo una de las configuraciones. Como veremos, los modos Minimal y Creator cambian qué puede usar el agente. Crear una configuración nueva sigue requiriendo trabajo de ingeniería; los desarrolladores tienen acceso a las piezas.

Cómo organiza Cordis los plugins de DeepSeek Harness

Como se mencionó, Cordis es el framework de plugins bajo DeepSeek Harness. Permite que cada parte solicite un servicio sin quedar atada al código de un único proveedor.

Cordis proviene del ecosistema del chatbot Koishi y fue creado por un desarrollador conocido como Shigma; DeepSeek lo distribuye y amplía. Sus autores describen el diseño en el artículo A Programming Paradigm for Spatiotemporal Composability.

Esa base lleva al lema principal del proyecto y a dos términos de Cordis. Suenan académicos, pero el comportamiento es bastante sencillo.

"Todo es un plugin"

La documentación de arquitectura de DeepSeek dice que amplías dsh montando un plugin junto a los demás. Los adaptadores de modelo, herramientas, sesiones, sandboxes, almacenamiento, planificación, el bucle del agente y la IU son todos plugins.

Tomado al pie de la letra, el lema exagera. Cordis sigue estando debajo de los plugins. Los carga y elimina, comprueba qué necesitan y ejecuta los eventos que usan para comunicarse. Cordis es obligatorio, no una pieza opcional más.

La composabilidad espacial gestiona las dependencias de plugins

Un plugin declara los servicios que necesita sin exigir una secuencia de arranque escrita a mano. Se activa cuando esos servicios existen y se desactiva si desaparece alguno requerido. Sus dependencias deciden cuándo puede ejecutarse.

DeepSeek llama a esto composabilidad espacial. Las dependencias le dicen a Cordis dónde encaja un componente, así que los desarrolladores no tienen que ordenar el arranque a mano.

La composabilidad temporal revierte efectos de plugins

Cordis también rastrea registros como listeners de eventos, secciones de prompts y esquemas de herramientas. Al quitar un plugin, se eliminan esos efectos en vez de dejar listeners huérfanos. Esto no deshace acciones externas como un comando de shell; la reversibilidad solo aplica a efectos que Cordis rastrea.

Arquitectura de DeepSeek Harness: cómo encaja el runtime

Una instancia en ejecución es un árbol de plugins construido a partir de configuraciones cargadas en un orden concreto. Esas configuraciones determinan qué partes están activas.

Cordis conecta todos los plugins reemplazables del runtime. Imagen del autor.

Los servicios de Cordis permiten que los plugins se encuentren

Cordis ofrece un directorio compartido de servicios. Los plugins usan claves estables como ctx.tools, ctx.llm y ctx.sessions en lugar de importar el código de un proveedor concreto. Una herramienta que llama a ctx.llm no necesita saber qué adaptador de modelo hay detrás.

Los presets del agente y los perfiles del runtime controlan capas distintas

Si todo es reemplazable, alguien tiene que decidir qué se monta en cada ejecución, y DeepSeek Harness lo responde en dos capas fáciles de confundir.

Versión corta: un perfil controla cómo arranca el programa, mientras que un preset controla qué puede hacer el agente. Si solo usas la app web, puedes saltarte las dos subsecciones siguientes.

Perfiles de runtime

Un perfil de runtime (web, headless, sdk, sdk-minimal y acp se suministran como plantillas) decide cómo se lanza la aplicación y qué paquetes de plugins de Cordis se apilan al inicio. La mayoría solo tocará esta capa ejecutando dsh web o un comando similar.

Presets del agente

Un preset de agente (Standard, PTC, Minimal o Creator) decide qué puede usar una sesión activa. Un archivo de patch puede cambiar el preset sin tocar el código de Harness.

El bucle del agente coordina turnos, pasos y llamadas a herramientas

DeepSeek distingue un paso de un turno. Un paso es una solicitud al modelo más sus llamadas a herramientas. Un turno son cero o más pasos: se abre antes de que se reclame su primera entrada y se cierra cuando no queda nada pendiente. La mayoría de turnos ejecuta varios pasos antes de que el agente pueda responder, pero una entrada rechazada cierra un turno que no consumió pasos.

Un turno puede contener varios pasos. Imagen del autor.

Las sesiones usan un registro de eventos solo-append

Esto me parece lo más importante. Una sesión es un registro de eventos tipados solo-append, no un array de mensajes de chat. Harness construye el historial del modelo a partir de ese registro, y la documentación de sesiones exige que todo lo que se envía al modelo sea recuperable desde ahí.

Reanudar, bifurcar, buscar, reproducir y la vista Trajectory se construyen sobre ese flujo de eventos.

Re-derivar el historial no es una re-ejecución determinista. La salida del modelo y el estado externo pueden diferir, pero el registro sigue ofreciendo un relato inspeccionable de lo ocurrido.

El historial de la sesión es un registro solo-append. Imagen del autor.

Cómo controla DeepSeek Harness las herramientas y los sandboxes

Un modelo puede solicitar una herramienta por nombre, pero no puede ejecutarla directamente. Dos controles separados median entre la solicitud y un cambio en el sistema de archivos.

La tubería de ejecución de herramientas

La llamada pasa por una comprobación de políticas, la ejecución y el manejo del resultado. El modelo elige la herramienta; el runtime decide si y cómo se ejecuta.

El runtime decide cómo se ejecutan las herramientas. Imagen del autor.

Sandboxing frente a aprobaciones

• Aprobación pregunta si el usuario debe confirmar una acción. 
• Sandboxing limita dónde y cómo se ejecuta. 

DeepSeek los mantiene separados, aunque los presets de permisos agrupan ambos controles, del mismo modo que un runtime de contenedores separa permisos de proceso de límites de ejecución.

Conviene destacarlo ahora, porque volveré a ello en las limitaciones: decirle a un modelo en el prompt del sistema que "solo lea archivos" es una instrucción que puede seguir, no un límite impuesto como el de un sandbox a nivel de sistema operativo.

Modos de DeepSeek Harness: Standard, PTC, Minimal y Creator

DeepSeek Harness ofrece cuatro modos distintos. Ninguno está por encima de los demás. Son cuatro respuestas a "cuánto del runtime debe exponerse a esta sesión", y el adecuado depende de la tarea. Como vimos en la arquitectura, cada modo cambia el conjunto de herramientas disponibles para el agente.

Cuatro modos comparten una misma base de runtime. Imagen del autor.

Modo Standard

La base de uso general: 

• Edición de archivos
• Acceso a shell
• Búsqueda en archivos y web
• Skills
• Planificación
• Objetivos
• Subagentes
• Workflows

Para trabajo habitual con repositorios, aquí empezaría yo.

Modo PTC

El modo PTC mantiene casi todo el conjunto de herramientas de Standard pero cambia cómo llega el modelo a ellas. (Desde la versión 0.1.2, el modo Web PTC ya no expone por defecto la herramienta de propósito general workflow.) 

En lugar de pedir herramientas individuales en varios pasos del modelo, este escribe un programa contra un SDK generado. Ese programa puede llamar a varias herramientas mediante run_code. Cada llamada sigue pasando por las mismas comprobaciones de políticas, así que PTC cambia cómo el modelo expresa el plan, no lo que puede hacer.

La página de producto sigue usando la etiqueta "Code mode", pero una versión oficial más reciente lo renombró a modo PTC manteniendo legibles las conversaciones antiguas. Usaré modo PTC en todo el texto; el FAQ retoma qué podrían significar esas siglas.

Modo Minimal

El modo Minimal reduce el entorno a dos herramientas: un shell persistente y un editor de archivos por sustitución de cadenas. DeepSeek lo usa para benchmarks de modelos porque los resultados dependen en parte del harness del modelo, no solo de sus pesos.

Modo Creator

El modo Creator permite a los desarrolladores inspeccionar el runtime y probar plugins de Cordis en memoria. Sirve para crear presets, y no lo llamaría auto-mejorable en un sentido más profundo.

Qué hace diferente a DeepSeek Harness frente a otros frameworks de agentes

DeepSeek Harness se diferencia de muchos frameworks de agentes al hacer reemplazables las capas bajas del runtime. Casi lo incluyo en la sección de arquitectura, pero la distinción se pasa por alto con facilidad. Cordis gestiona esos cambios con un único sistema de plugins.

Puedes cambiar cómo opera el agente, no solo las herramientas que puede invocar. El registro de eventos también convierte la ejecución en algo inspeccionable por los desarrolladores, en lugar de leerlo solo como un chat. Los modos Minimal y Creator les permiten probar el runtime desde direcciones opuestas.

DeepSeek Harness vs. Claude Code, Codex y OpenCode

Una checklist de funciones pasaría por alto lo esencial. Cada competidor admite extensiones; la pregunta útil es qué partes pueden cambiar los desarrolladores. Parece una diferencia menor, pero no lo es. Nuestra comparativa dedicada de Harness frente a Claude Code usa el mismo modelo en ambos y cubre configuración, logs y costes.

DeepSeek Harness vs. Claude Code

Claude Code admite instrucciones de proyecto, skills, hooks, MCP, subagentes y un Agent SDK, y mantiene fijo su bucle integrado. DeepSeek Harness permite sustituir el bucle, el adaptador del modelo y la capa de almacenamiento mediante la configuración.

DeepSeek Harness vs. Codex

Codex requiere una comparación más cuidadosa porque su CLI y App Server también son de código abierto. Proporciona un agent harness que los desarrolladores amplían mediante puntos de entrada documentados. DeepSeek Harness está pensado para cambiar el propio runtime. Ofrecen niveles de control distintos.

DeepSeek Harness vs. OpenCode

OpenCode ya es de código abierto, funciona con varios proveedores de modelos y usa una arquitectura cliente-servidor. Puedes configurar sus herramientas, permisos, sesiones y proveedores. Sus plugins amplían un núcleo de servidor fijo, mientras que DeepSeek también hace reemplazables el bucle y el almacén de sesiones.

Cuándo usar DeepSeek Harness

Sustituir partes del runtime no es útil por sí mismo. Ese control extra solo importa cuando resuelve un problema que ya tienes.

• Cuando el propio runtime forma parte del proyecto. Si estás modificando adaptadores de modelo, el bucle del agente, el almacenamiento o el comportamiento de sesiones, y no solo construyendo encima de un agente, este encaja mejor.
• Cuando comparas modelos en un entorno controlado. Usar el mismo runtime mantiene más constantes las pruebas al intercambiar el modelo, aunque puedan diferir en uso de herramientas y estilo de razonamiento.
• Cuando importa depurar una ejecución compleja. El registro de eventos de la sesión y la vista Trajectory facilitan reconstruir qué vio el modelo y qué herramientas se ejecutaron.
• Cuando pruebas los internos de un agente. El modo Creator y Cordis están pensados para desarrolladores que estudian cómo se ensamblan los agentes, más que para quien solo necesita código de aplicación.

Puede ser innecesario para llamadas simples a modelos o para equipos que quieren un agente de código listo para usar sin tocar sus entrañas. Sustituir más piezas solo compensa cuando ese control resuelve un problema real.

Limitaciones de DeepSeek Harness: estado de vista previa y riesgos de seguridad

Nada de lo anterior importa sin explicar claramente en qué se queda corto hoy.

Sigue en vista previa para desarrolladores

El repositorio de DeepSeek deja claro que habrá cambios incompatibles. Ya ha ocurrido: el cambio de Code a PTC vino con cambios en las APIs de sesión y la eliminación de una opción opcional de almacenamiento en SQLite. Fija tus versiones. Omitir ese paso y confiar en que todo siga estable no es un plan.

Más control también implica más complejidad

Hacer reemplazable más parte del runtime también obliga a aprender más: dependencias de plugins, configuración, diferencias entre proveedores y compatibilidad de versiones. Es el intercambio habitual entre comodidad y control.

¿DeepSeek Harness es local?

DeepSeek Harness almacena por defecto el contenido de las sesiones, los registros de herramientas y la configuración de forma local, según su declaración de tratamiento de datos. Puedes desactivar sus informes anónimos sobre configuraciones y listas de proyectos. 

Pero un proveedor de modelo externo, una herramienta web, un servidor MCP o un plugin pueden seguir enviando datos fuera de tu máquina bajo su propia política. "Local-first" no cubre todos los servicios que conectes.

Ejecutar agentes conlleva riesgos de seguridad

Un runtime que puede editar archivos, ejecutar comandos y cargar plugins de terceros puede causar daños reales. El aviso de seguridad de DeepSeek indica que el proyecto no ha pasado una auditoría. El sandboxing, las aprobaciones y los controles de permisos reducen el riesgo, pero no garantizan aislamiento.

Ejecutarlo en tu propia máquina no elimina ese riesgo. Usa permisos limitados y un entorno desechable para trabajos no confiables, y ten cuidado con contenido que pueda contener instrucciones ocultas.

Por qué el comportamiento de un agente depende de algo más que del modelo

El comportamiento de un agente depende del runtime además del modelo. Volvemos a "Agente = Modelo + Harness", y la misma separación aplica a los agentes con LLM más allá de DeepSeek.

Lo que un modelo puede producir depende de sus pesos. Lo que hace un agente también depende de qué contexto llega al modelo, qué acciones puede tomar y cuán rígidas son las restricciones de ejecución. Nada de eso vive en los pesos.

DeepSeek Harness muestra esa capa circundante al dividirla en piezas con nombre que se pueden sustituir. El modo Minimal demuestra por qué esto importa más allá de DeepSeek: una puntuación de benchmark refleja en parte el harness usado en la prueba, no solo el modelo. El harness no hace más listo a un modelo. Cambia el entorno en el que trabaja.

Conclusión

La idea inicial es la que conviene recordar: el modelo razona, pero el runtime decide a qué puede llegar ese razonamiento y qué puede hacer. DeepSeek Harness hace editable ese runtime, desde el adaptador del modelo y las herramientas hasta el almacén de sesiones y el bucle del agente.

Ese control tiene un coste. Sustituir más partes del runtime implica responsabilizarse de su configuración, cambios de versión y límites de seguridad. Una vista previa para desarrolladores con acceso a shell no es algo que instales y te olvides.

Mi opinión es simple: usa DeepSeek Harness cuando el propio runtime forma parte del trabajo. Si solo necesitas ediciones en el repositorio, un agente de código listo te exigirá menos.

Nuestro tutorial de DeepSeek Harness cubre la configuración. La guía de alternativas a Claude Code compara más agentes de código, mientras que Introduction to AI Agents repasa las bases que este artículo da por sentadas.