DeepDive
DeepSeek Harness y Cordis: cómo funciona "everything is a plugin"
El CLI dsh de DeepSeek Harness monta modelos, tools, skills, sandboxes, filesystems y loops sobre Cordis. Qué es Cordis y por qué "everything is a plugin" cambia las reglas.
El problema que resuelve "everything is a plugin"
Los harness de IA que usas a diario, Claude Code u OpenAI Codex, son cajas cerradas. El modelo entra por una vía, las tools por otra y la UI está soldada al core. Si quieres cambiar el sandbox, tocar la orquestación o meter un filesystem propio, tienes que hacerte un fork y mantenerlo tú. Tan firme es el lock-in.
DeepSeek Harness v0.1, lanzado el 13 de agosto de 2026, de código abierto, parte de la idea contraria: everything is a plugin. Modelos, tools, skills, sessions, sandboxes, filesystems, loops de trabajo, orquestación y la propia UI son plugins intercambiables. Pero para que esa frase no quede en eslogan hace falta un framework que gestione el ciclo de vida de esos módulos. Ahí entra Cordis.
No es una API de plugins casera. DeepSeek no reinventa nada: usa Cordis, un meta-framework que ya resolvía el alta y la baja de plugins, la resolución de dependencias y la colaboración por servicios y eventos. El CLI se llama dsh y se lanza con el comando de tu package manager. DeepSeek Harness es Developer Preview y corre sobre Node.js.
Esto cambia tu modelo mental. En un harness tradicional añades algo dentro de un sistema fijo. En DeepSeek Harness declaras un plugin y el framework lo arranca, comprueba sus dependencias, lo conecta con el resto y lo libra cuando toca. Ese contraste es lo que voy a desgranar.
- Claude Code y Codex: cajas cerradas, cambiar algo implica fork.
- DeepSeek Harness: modelos, tools, skills, sesiones, sandboxes, filesystems, loops, orquestación y UI son plugins.
Qué es Cordis, el meta-framework de plugins
Cordis es un meta-framework de plugins. Meta, porque su trabajo no es darte funciones concretas, tipo hacer HTTP o leer un archivo, sino el andamiaje para que cualquier pieza se convierta en plugin. Tú defines módulos: modelos, tools, skills, lo que sea. Y Cordis se encarga de que vivan, se relacionen y se hagan desaparecer de forma ordenada.
Aquí conviene separar dos planos que solemos mezclar. El primero es el ciclo de vida: un plugin se monta con el hook load, se descarga con unload y el framework sabe en qué orden. El segundo es la colaboración: los plugins no se llaman entre sí con imports directos, sino que publican eventos y consumen servicios. Ahí vive el progenitor de los agentes compuestos. La UI puede reaccionar a un evento del modelo sin conocerlo.
Con Cordis puedes montar desde un bot simple hasta una familia de agentes. Los plugins no saben quién más existe en el sistema. Se registran, declaran dependencias, y Cordis resuelve el ensamblado. DeepSeek Harness es un consumidor de Cordis, potente, pero no el único: la base se reutiliza fuera del mundo DeepSeek.
Ciclo de vida: load, unload y dependencias
El corazón de Cordis son tres piezas: load, unload y las dependencias. Cuando el harness arranca, carga los plugins en el orden que piden sus requisitos. Si tu plugin de filesystem necesita un sandbox antes, Cordis lo detecta y inicia primero el sandbox. No tienes que ordenar la secuencia a mano.
El unload se ignora demasiado y es igual de importante. Cuando reinicias el agente, cambias de modelo o desconectas una tool, Cordis hace la desconexión en orden inverso: primero los que dependen de otros. Libera recursos limpio y evita estado colgado, hooks que apuntan a plugins muertos o suscripciones huérfanas.
Las dependencias se declaran de forma explícita y se resuelven antes de que el plugin empiece a funcionar. Es la diferencia entre un sistema que dice que funciona en tu máquina y otro que sabe, antes de ejecutar, si hay conflictos. Cada plugins declara lo que consume y lo que expone, y el framework hace el cableado.
Colaboración por servicios y eventos, no por imports
Si los plugins se conectaran con imports directos, tendrías acoplamiento fuerte: cambias una firma y rompes el sistema. Cordis lo separa en dos mecánicas que se usan juntas: los servicios y los eventos.
Un plugin expone un servicio y otros lo consumen. Piensa en un servicio de filesystem que devuelve un archivo, o un servicio de modelo que recibe un prompt. El cliente no importa la clase del productor: pide el servicio por nombre y tipo, y el framework se lo inyecta. Si mañana cambias la implementación del modelo manteniendo el contrato, nadie nota nada.
La segunda vía son los eventos. Un plugin emite lo que pasa: el modelo terminó, la tool respondió, el archivo cambió. Cualquier suscrito reacciona. Esto te da una interfaz receptiva que pinta en vivo lo que hace el agente, sin que el loop de orquestación notifique a cada pieza a mano. Por eso encaja tan bien con un harness.
Colaborar por servicios y no por imports es la diferencia entre un sistema congelado y otro donde sumarte una pieza no toca lo que ya está.
Cómo DeepSeek Harness monta el agente sobre Cordis
DeepSeek Harness define sus piezas como plugins Cordis, una capa por plano: el proveedor de modelos, las tools, las skills, las sessions que conservan contexto, los sandboxes, los filesystems y la interfaz de la web.
El resultado es que nada queda pegado al core. Quieres cambiar el proveedor del modelo, cambias ese plugin. Quieres otro sandbox, cambias el plugin de sandbox. Hasta el loop de orquestación y la UI web son piezas sustituibles y no el esqueleto fijo.
Piensa en la idea al revés. Cuando arrancas el harness, obtienes una instancia que ensambla modelo, tools, skills, sesión, sandbox, filesystem, loop y UI. Cada pieza arranca según el orden que resuelve Cordis, y no lo ordenas tú. Para el usuario es un CLI normal. Por dentro es un ecosistema de módulos declarados.
Recuerda que es una Developer Preview. Ten cautela en producción. Pero el diseño de la base, el framework de plugins, es lo que de verdad marca la diferencia, y es algo que puedes replicar en tu propio agente.
Los tipos de plugin que monta el harness
La idea everything is a plugin se hace concreta al ver lo que monta el stack. Cada tipo cubre un plano del agente y se intercambia sin tocar el resto. Cambias el modelo sin tocar las tools, o cambias el sandbox sin reescribir el loop.
En la tabla de abajo, cada fila es un plano Cordis y cómo lo expones en el día a día.
| Tipo de plugin | Qué cubre | Cómo lo notas tú |
|---|---|---|
| Modelos | El proveedor de LLM y los parámetros de la llamada. | Cambia de modelo sin tocar tools ni UI. |
| Tools | Llamadas concretas que ejecuta el agente. | Enciende o apaga capacidades por tarea. |
| Skills | Conocimiento y flujos de dominio reutilizables. | Añades un skillset sin tocar el motor. |
| Sessions | Estado y memoria de cada conversación. | Conservas o reseteas contexto aislado. |
| Sandboxes | Entorno aislado donde corre el código. | Ejecutas sin manchar el huésped. |
| Filesystem | Archivos y árbol de trabajo. | Cambias el almacén o los permisos que miras. |
| Loops | El bucle de razonamiento y acción. | Cambias la lógica agente por componentes. |
| Orquestación | Coordinación de tareas y agentes. | Montas pipelines multiagente sin tocar la base. |
| UI | La interfaz, incluyendo la pantalla web. | Adaptas el chat sin recomplir el motor. |
Cómo se cargan y descargan plugins en runtime
Cargar y descargar no ocurre solo en el arranque. Cordis lo permite en ejecución. Cuando declaras una pieza, el framework la registra, comprueba sus dependencias, monta los servicios y recién entonces la activa. Puedes añadir un proveedor de modelos o un nuevo filesystem sin reiniciar el agente.
Esa dinámica es la flexibilidad total. En un momento tienes tres tools y al siguiente activas una cuarta por config, y la próxima petición ya sale con la nueva. La descarga se ejecuta en el orden inverso al de la carga.
Todo suscriptor está atado al ciclo de vida del plugin. Cuando un plugin baja, se retiran sus eventos. No quedan eventos huérfanos ni manejadores flotando, y evitas ese clásico error de "handler muerto" que en frameworks sin ciclo de vida persigues hasta las tantas.
Declarar un plugin Cordis, cómo se ve
Vamos a ser concretos. Un plugin Cordis es al final una función que recibe un contexto y expone su ciclo de vida. El patrón se repite para todos los tipos de plugin que viste arriba, y es la base para entender la arquitectura del harness.
Sea cual sea el tipo, la forma es: definimos el plugin con un factory, exponemos su vida a través de los hooks, proveemos servicios con provide y emitimos eventos. El framework se encarga de las dependencias y del orden de carga.
El scaffold de un plugin Cordis
El código TypeScript de un plugin queda así: una función llamada con el contexto `ctx`, un load y un unload para el ciclo de vida, y la puerta de los servicios y eventos. Este es el plugin del filesystem de ejemplo.
- exports la función del plugin que recibe el contexto del framework.
- En el load inicializas los recursos, por ejemplo, montas el filesystem o abres la conexión.
- En el unload liberas: cierras la conexión y retiras las suscripciones.
- La función devuelve los hooks y las capacidades, y Cordis lo integra con el resto por nombre y tipo.
Ventajas: sin vendor lock-in y extensión real
Primera ventaja: puertas de entrada y salida. Como cada capa es un plugin con un contrato, puedes mover tu agrupación a otro producto sobre Cordis sin reescribir las acciones. No quedas a merced de un solo proveedor de modelo.
Segunda ventaja: capacidad en extensión real. Un plugin de scope o una herramienta tuya se declara con el esquema de arriba, y por eso entras a formar parte del agente. Cuanto más conoces los dominios de tu stack, más rápido construyes.
Y el punto a no esconder: esto trae complejidad. Es una Developer Preview, la API de Cordis tiene su curva, el modelo de servicios y eventos no es tan inmediato como una CLI clásica, y de un ecosistema tan joven no esperes cientos de plugins. Aun así es un diseño sólido, y queda validarlo en producción.
DeepSeek Harness contra Claude Code y Codex
Claude Code y OpenAI Codex son ejecutables cerrados y propietarios. Su extensibilidad pasa por sumar skills o tools a un core que no puedes cambiar de una manera directa. No hay capas que, desde afuera, quieras volar y reemplazar.
DeepSeek Harness sobre Cordis trata la extensión como un elemento de primera clase. Qué es y qué consumes se declara igual para todas las capas. No hay un core impenetrable, sino el andamiaje que une los plugins. Es una idea que pocos harnesses formalizan.
No digo que un estilo sea mejor que otro. La diferencia es de filosofía. Claude y Codex apuestan por el producto afinado y el CLI terminado. DeepSeek apuesta a que el valor aparece cuando cada plano, modelo, tool, skill, loop o UI, se vuelve una pieza que sustituyes por separado. Si tienes varios modelos y agentes propios, esto protege del bloqueo.
Elige según tu caso. Si quieres algo que funcione apenas destapa la caja, Claude y Codex están más pulidos. Si quieres total autonomía, cambiar el proveedor, meter tu sandbox o tu orquestación propia, una base Cordis es otra herramienta en el taller.
Preguntas frecuentes
Un repaso a las dudas más comunes antes de llevar esto a producción.
Preguntas frecuentes
¿Qué es Cordis en DeepSeek Harness?
Es el meta-framework de plugins sobre el que se construye el harness. Gestiona el ciclo de vida, load y unload, la resolución de dependencias y la colaboración por servicios y eventos. DeepSeek lo usa como base para que cada capacidad del agente sea un plugin reemplazable.
¿Qué implica everything is a plugin?
Que cada plano del agente, el modelo, las tools, las skills, las sesiones, los sandboxes, los filesystems, los loops, la orquestación y la interfaz, se declara como plugin. Cambiar de proveedor o de entorno es sustituir el plugin, no modificar un core cerrado.
¿Cuál es la diferencia entre services y events, y si se usan juntos?
Los servicios son llamadas directas por un contrato de tipo: un plugin provee uno y otro lo consume sin conocer la implementación. Los eventos son de publicación y suscripción: un plugin emite y quien está suscrito reacciona. Se combinan para dar una interfaz reactiva sin acoplar piezas.
¿Cómo se resuelven las dependencias antes de iniciar?
Cordis pide que cada plugin declara sus dependencias, y las monta antes, en el orden correcto, y las libera al final, en el inverso. Así, cuando el plugin arranca, ya tiene sus services y suscriptores; cuando se baja, se limpian sin dejar manejadores huérfanos.
¿Puedo activar un plugin sin reiniciar el harness?
Sí, Cordis permite montar y desmontar plugins en caliente. El framework registra la pieza, comprueba sus requisitos y la activa; luego, al descargarla, libera sus recursos y suscriptores sin afectar al resto del sistema.
¿Debo dominar Cordis para usar el dsh?
Para usarlo no, el CLI funciona de forma directa. Para extenderlo sí: la extensión pasa por declarar plugins con el patrón definePlugin y manejar los servicios y eventos. Conocer Cordis ahí deja la ventaja de quien acudir a tu propio agente.
¿Cómo comparar esto con Claude Code o Codex?
Difieren en la filosofía de extensión. Claude Code y Codex son productos cerrados: sumas tools, no reemplazas el motor. Una base Cordis formaliza que la extensión es un plugin de primera capa y permite cambiar de proveedor, sandbox u orquestación a voluntad.
¿Este harness es de producción y con qué modelos corre?
Es una Developer Preview, anunciada el 13 de agosto de 2026. Diseñada para correr con los modelos de DeepSeek (V4 Pro y V4 Flash) y con la base para cambiar de proveedor de modelos mediante un plugin, de modo que no quedas atado.
¿Por qué usa Cordis en lugar de una API de plugins propia?
Reutiliza una base probada: Cordis ya resuelve el ciclo de vida, la resolución de dependencias y la colaboración por eventos y servicios. DeepSeek se enfoca en declarar los plugins de su harness, y cualquiera que conozca Cordis de otro proyecto encuentra la mecánica familiar.
Entender la arquitectura everything is a plugin es un paso, pero llevarla a producción es otro. En HosTia.ia montamos agentes listos para producción en menos de 30 días, con dashboard de monitorización y SLA, incluidos stack basados en Cordis. Si quieres saber si este enfoque te conviene, pide una demo o la llamada de estrategia en hostia.solutions y decide con datos en la mano.
Agentes listos para producción en menos de 30 días, con uptime garantizado por SLA y un dashboard de monitorización en vivo. Agenda una llamada estratégica gratuita.
Agenda una llamada