Durante buena parte de la carrera de la inteligencia artificial, la pregunta dominante fue casi siempre la misma:

¿qué modelo es mejor?

Más parámetros, mejores benchmarks, mayor ventana de contexto, menor coste por token.

Pero cuando una IA deja de responder preguntas y empieza a trabajar, el modelo es solo una parte del sistema.

Un agente necesita entender el entorno, acceder a archivos, ejecutar herramientas, mantener estado, recuperarse de errores, aplicar permisos, conservar un historial y decidir qué hacer después de cada resultado.

Esa capa de software es el agent harness.

Y DeepSeek acaba de convertirla en protagonista.

La compañía lanzó DeepSeek Harness (dsh), un harness abierto bajo licencia MIT cuya tesis arquitectónica cabe en una frase:

Everything is a plugin.

No solo las herramientas.

También los modelos, las skills, las sesiones, los sandboxes, el almacenamiento, los loops del agente, el scheduling y hasta la interfaz de usuario pueden componerse como plugins.

Eso convierte el anuncio en algo bastante más interesante que “DeepSeek lanzó otro agente de código”.

La apuesta real es otra:

separar el cerebro del agente de la infraestructura que lo convierte en un trabajador operativo.

Agent = Model + Harness

La página oficial de DeepSeek lo expresa de forma directa:

Agent = Model + Harness

El modelo aporta razonamiento y generación.

El harness aporta el entorno operativo.

Una versión simplificada sería:

Usuario
   ↓
Harness
   ├── contexto
   ├── herramientas
   ├── filesystem
   ├── sandbox
   ├── sesiones
   ├── memoria / almacenamiento
   ├── permisos
   ├── scheduling
   ├── subagentes
   └── agent loop
          ↓
        Modelo

Este cambio de perspectiva es importante.

Si dos productos utilizan exactamente el mismo modelo pero uno administra mejor el contexto, las herramientas, el estado y la recuperación ante errores, no necesariamente producirán el mismo agente.

El rendimiento real emerge del sistema completo.

Es la misma dirección que hemos analizado anteriormente en Capital de Tokens con Codex como plataforma y agent harness: el valor competitivo empieza a desplazarse desde el modelo aislado hacia la infraestructura que lo rodea.

DeepSeek está entrando en esa batalla desde una posición diferente: abre el harness y diseña sus capacidades alrededor de un sistema de plugins.

Qué mostró la demo práctica

Un video reciente sobre DeepSeek Harness sirve para ver esta arquitectura desde el punto de vista del usuario.

La demostración instala el harness localmente, abre su dashboard en el navegador, selecciona una carpeta de trabajo y asigna permisos sobre ese workspace.

Después conecta un modelo mediante API y comienza a usar el agente sobre archivos reales.

Entre los ejemplos mostrados aparecen tareas como:

  • inspeccionar una carpeta y clasificar sus documentos;
  • detectar archivos duplicados;
  • crear nuevas carpetas y reorganizar contenido;
  • construir una aplicación funcional a partir de un prompt;
  • analizar la web de una empresa y producir oportunidades de automatización;
  • crear un plugin nuevo describiéndolo en lenguaje natural;
  • generar un agente personalizado para auditoría de código.

Lo interesante no son esas demos por separado. Muchas herramientas agénticas pueden realizar tareas parecidas.

Lo interesante es cómo DeepSeek intenta representar esas capacidades dentro del runtime.

En lugar de codificar una gran aplicación monolítica con todas las funciones posibles, el harness trata las capacidades como componentes intercambiables.

“Todo es un plugin” significa bastante más que instalar extensiones

Cuando escuchamos la palabra plugin, es fácil pensar en una extensión del navegador o en un complemento opcional.

DeepSeek utiliza el concepto de forma mucho más profunda.

Según su documentación oficial, pueden representarse mediante plugins:

  • modelos;
  • herramientas;
  • skills;
  • sesiones;
  • sandboxes;
  • almacenamiento;
  • loops del agente;
  • scheduling;
  • interfaz de usuario.

Eso significa que el plugin no está únicamente en los bordes del producto.

El propio producto está compuesto por plugins.

Podemos imaginarlo así:

DeepSeek Harness
│
├── plugin: modelo
├── plugin: filesystem
├── plugin: shell
├── plugin: sandbox
├── plugin: sesión
├── plugin: almacenamiento
├── plugin: agent loop
├── plugin: scheduler
└── plugin: UI

Un “modo” del agente puede entonces ser simplemente una composición distinta de esas piezas.

DeepSeek ya utiliza este enfoque para ofrecer varios modos de runtime.

Standard mode

Incluye un conjunto amplio de capacidades para programación: edición de archivos, shell, búsqueda, planificación, objetivos, subagentes y workflows.

Code mode

Expone herramientas al modelo mediante un SDK para que pueda combinar múltiples operaciones dentro de un programa TypeScript.

En vez de encadenar manualmente decenas de tool calls, el modelo puede programar una pequeña secuencia de ejecución.

Minimal mode

Reduce el entorno a herramientas básicas —principalmente shell persistente y edición— para disponer de un harness mucho más pequeño y útil, entre otras cosas, para evaluar modelos sin tantas capas alrededor.

Creator mode

Está pensado precisamente para construir nuevas composiciones del agente: inspeccionar el runtime, experimentar con plugins y generar presets personalizados.

Esta última modalidad refleja una idea especialmente poderosa:

el agente puede ayudar a modificar el propio entorno en el que opera.

Cordis: la pieza que hace posible la composición

Aquí aparece la parte más interesante de la arquitectura.

DeepSeek Harness está construido sobre Cordis, un meta-framework diseñado para manejar sistemas que cambian dinámicamente mientras están ejecutándose.

El 26 de agosto se publicó en arXiv el paper “A Programming Paradigm for Spatiotemporal Composability”, firmado por Yifan Shi, Wei Zhang y Tianyi Cui.

El trabajo intenta formalizar dos problemas que aparecen cuando un sistema está compuesto por componentes que pueden entrar y salir dinámicamente.

1. Composabilidad temporal

Supongamos que instalamos un plugin.

Ese plugin puede:

  • registrar herramientas;
  • modificar configuración;
  • añadir listeners;
  • abrir recursos;
  • registrar servicios;
  • alterar el contexto del runtime.

Ahora queremos quitarlo.

No basta con borrar una referencia.

Necesitamos revertir correctamente todos los efectos que introdujo.

El paper denomina a esto composabilidad temporal y propone el concepto de revertible effects: las transformaciones introducidas por un componente conservan la información necesaria para deshacerse cuando el componente desaparece.

Conceptualmente:

plugin entra
   ↓
registra efectos
   ↓
runtime conserva cómo revertirlos
   ↓
plugin sale
   ↓
los efectos se revierten

Para un sistema de agentes extensible esto es muy relevante.

Un sandbox, una herramienta o un proveedor de modelo debería poder reemplazarse sin dejar al runtime en un estado parcialmente roto.

2. Composabilidad espacial

El segundo problema son las dependencias.

Supongamos que un plugin necesita otro servicio para funcionar.

Plugin B
   ↓ depende de
Plugin A

Si A desaparece, B ya no debería seguir operando como si nada hubiera ocurrido.

Cordis introduce reactive coeffects, un mecanismo para declarar dependencias y reaccionar cuando esas dependencias aparecen, desaparecen o cambian.

En términos prácticos, los componentes pueden activarse o desactivarse siguiendo la topología real del runtime.

Esto permite construir software donde la composición no queda fijada únicamente durante el arranque.

Puede cambiar en caliente.

Un harness que puede reconfigurarse mientras vive

La combinación de esos dos conceptos es lo que el paper denomina spatiotemporal composability.

Dicho sin formalismo matemático:

un componente debería poder entrar, salir o ser reemplazado sin dejar efectos huérfanos y sin romper silenciosamente a los componentes que dependían de él.

Eso resulta especialmente atractivo para agentes de larga duración.

Imaginemos un agente que permanece ejecutándose durante horas o días.

Durante su vida podríamos querer:

  • cambiar el modelo;
  • montar una nueva herramienta;
  • retirar una integración insegura;
  • cambiar el sandbox;
  • activar una skill solo para determinada tarea;
  • sustituir el sistema de almacenamiento;
  • añadir un subagente;
  • modificar la UI;
  • cargar un workflow temporal.

Una arquitectura tradicional puede resolver todo eso, por supuesto.

La diferencia es que DeepSeek intenta hacer de la composición dinámica una propiedad central del framework.

Una explicación independiente publicada por Helmcode sobre el paper de Cordis señala precisamente esta conexión entre la teoría y la implementación: los efectos reversibles y las dependencias reactivas del paper tienen contrapartidas concretas en el ciclo de vida de los plugins que ejecuta Cordis.

Cada ejecución también intenta ser reconstruible

La segunda gran tesis de DeepSeek Harness es menos vistosa, pero probablemente igual de importante:

every run is traceable.

La documentación indica que lo que observa el modelo queda registrado en un log de sesión append-only, incluyendo elementos como prompts del sistema, tool calls, resultados, scheduling de subagentes e inyecciones de contexto.

Sobre ese mismo stream pueden implementarse operaciones como:

  • reanudar;
  • buscar;
  • hacer fork de una ejecución;
  • reproducirla;
  • inspeccionar su trayectoria.

Esto acerca el harness a una idea que será cada vez más importante en sistemas autónomos: la ejecución del agente debe convertirse en un objeto inspeccionable.

Cuando un agente modifica código, archivos o infraestructura, no basta con saber cuál fue la respuesta final.

Necesitamos entender:

qué vio
→ qué decidió
→ qué herramienta llamó
→ qué devolvió la herramienta
→ cómo cambió su contexto
→ qué hizo después

En otras palabras, la observabilidad deja de ser un extra y empieza a formar parte del diseño del agente.

El ecosistema ya está empezando a aparecer

La estrategia de plugins solo funciona si existe un ecosistema alrededor.

DeepSeek recomienda utilizar el topic dsh-plugin en GitHub para descubrir extensiones y ya han aparecido directorios comunitarios que intentan catalogar y verificar plugins reales.

Un ejemplo es Awesome DeepSeek Harness Plugins, un índice independiente que además introduce una advertencia sensata: el hecho de que un repositorio se anuncie como plugin no significa que sea seguro, mantenido o compatible.

Esto puede convertirse en uno de los puntos fuertes del proyecto, pero también en uno de sus principales riesgos.

Un agente con acceso a filesystem, shell, red y credenciales ejecuta componentes con capacidades considerablemente más sensibles que una extensión visual convencional.

La seguridad de la cadena de suministro de plugins será, por tanto, crítica.

El equivalente agéntico de “instala esta extensión” puede significar literalmente:

instala código
que tendrá acceso
al entorno donde trabaja tu agente

Eso exige firmas, provenance, políticas de permisos, aislamiento y mecanismos claros de confianza.

No es todavía una plataforma estable

Aquí conviene frenar el entusiasmo.

DeepSeek describe explícitamente el proyecto como developer preview y advierte que habrá cambios incompatibles.

El repositorio está evolucionando rápidamente y las APIs principales todavía no deben tratarse como una base congelada para producción.

Eso cambia la forma correcta de evaluarlo.

Hoy DeepSeek Harness es especialmente interesante para:

  • estudiar arquitectura de agentes;
  • experimentar con harnesses propios;
  • construir plugins;
  • comparar modelos bajo distintos runtimes;
  • investigar sistemas de agentes reconfigurables;
  • crear prototipos locales;
  • observar cómo evoluciona un ecosistema abierto alrededor del agent runtime.

No necesariamente para asumir que cualquier integración escrita esta semana será compatible sin cambios dentro de varios meses.

DeepSeek vs. Codex: dos maneras de convertir el harness en plataforma

Aquí aparece una comparación inevitable.

OpenAI está abriendo piezas de Codex como plataforma mediante mecanismos como codex exec, SDK y app-server.

DeepSeek está proponiendo un harness abierto cuya arquitectura interna también puede recomponerse mediante plugins.

No son exactamente la misma estrategia.

Una forma simplificada de verlo sería:

Codex
modelo + harness integrado
        ↓
APIs / SDK / app-server
        ↓
tu producto

frente a:

DeepSeek Harness
        ↓
modelo = plugin
herramientas = plugins
sandbox = plugin
loop = plugin
storage = plugin
UI = plugin
        ↓
tu composición

La diferencia estratégica es importante.

Codex intenta convertirse en un motor agéntico integrable.

DeepSeek Harness intenta convertirse además en un substrato configurable para construir distintos motores agénticos.

Eso no significa automáticamente que uno sea mejor que el otro.

Significa que están atacando capas ligeramente diferentes del mismo problema.

El precio del modelo deja de ser toda la historia

El video que motivó esta investigación enfatiza repetidamente el bajo coste de utilizar modelos de DeepSeek.

Esa ventaja económica es relevante, pero conviene separar dos ideas.

Una cosa es el coste del modelo.

Otra es el coste total del agente.

Un sistema real también consume:

  • cómputo del sandbox;
  • almacenamiento;
  • búsquedas;
  • APIs externas;
  • infraestructura;
  • observabilidad;
  • validación humana;
  • recuperación ante errores;
  • mantenimiento de herramientas y plugins.

Por eso la pregunta más interesante no será únicamente:

¿cuánto cuesta este modelo por millón de tokens?

Será:

¿cuánto cuesta completar correctamente una tarea mediante este modelo + este harness?

Ese cambio de unidad —de token a tarea terminada— probablemente será uno de los grandes cambios de la economía de los agentes.

La guerra de los agentes puede convertirse en la guerra de los harnesses

Durante años hemos comparado modelos como si fueran productos completos.

Pero los agentes están obligando a la industria a separar varias capas:

Modelo
↓
Harness
↓
Tools / Skills
↓
Sandbox
↓
Memoria / estado
↓
Observabilidad
↓
Producto

Cada capa puede convertirse en un espacio competitivo independiente.

DeepSeek Harness es interesante precisamente porque hace explícita esa separación y lleva la modularidad hasta el extremo.

Si el enfoque funciona, un equipo podría conservar su producto y cambiar partes enteras de su stack agéntico sin reconstruir el sistema completo.

Podría utilizar un modelo hoy y otro mañana.

Un sandbox local para desarrollo y otro aislado en producción.

Un loop minimalista para benchmarks y uno complejo para tareas autónomas.

Una UI propia sin modificar el núcleo.

La frase “todo es un plugin” parece sencilla.

Pero llevada hasta sus últimas consecuencias propone algo ambicioso:

que el agente no sea una aplicación fija, sino una composición dinámica de capacidades.

Y si esa idea gana tracción, la próxima gran batalla de la IA quizá no se decida únicamente por quién tenga el modelo más inteligente.

También puede decidirse por quién construya el mejor sistema para convertir inteligencia en trabajo.

Fuentes