¿El harness es lo mismo que el modelo?

No. El modelo convierte texto en más texto y no tiene memoria de ayer, ni acceso a archivos, ni capacidad de ejecutar nada. El harness es el programa que lo rodea y decide qué ve el modelo, ejecuta las herramientas que pide, le devuelve los resultados y detiene el bucle cuando el trabajo está hecho.

¿Un harness de agente es solo un envoltorio sobre una llamada a una API?

Una llamada suelta no es un harness. El rasgo definitorio es el bucle: el harness llama al modelo, ejecuta la herramienta que el modelo ha solicitado, añade el resultado a la conversación y vuelve a llamar, repitiendo hasta que se cumple una condición de parada. Todo lo difícil de los harnesses —gestión de contexto, permisos, persistencia de sesiones, recuperación de errores— existe por culpa de ese bucle.

¿En qué se diferencia un harness de un framework de agentes?

Un framework es una biblioteca con la que construyes una aplicación; un harness es un programa ejecutable que usas. Los frameworks te dan las piezas y te dejan a ti las decisiones, mientras que un harness ya ha tomado esas decisiones y las entrega como valores por defecto. La línea se difumina cuando un harness es inusualmente configurable, que es exactamente lo que es DeepSeek Harness.

¿Un harness de agente sustituye a MCP?

No, responden a preguntas distintas. MCP es un protocolo que describe cómo una herramienta o fuente de datos se expone a un agente, mientras que un harness es el programa que ejecuta el bucle y decide si esa herramienta llega a llamarse siquiera. Un harness puede actuar como cliente MCP, lo que los hace complementarios y no competidores.

¿Qué hace inusual a DeepSeek Harness entre los harnesses?

Su diseño en el que todo es un plugin. Modelos, herramientas, skills, sesiones, sandboxes, sistemas de archivos, el bucle, la orquestación y la interfaz son todos plugins cargados en un runtime compartido de Cordis y compuestos mediante un archivo cordis.yml, de modo que las partes que la mayoría de herramientas tratan como interioridades fijas aquí son paquetes reemplazables.

¿Qué es un harness de agente?

Un harness de agente es la capa de runtime que envuelve a un modelo de lenguaje y convierte un generador de texto en algo capaz de trabajar. Ejecuta el bucle, le pasa herramientas al modelo, decide qué entra en el contexto, guarda las sesiones en algún sitio duradero y hace cumplir lo que el agente tiene permitido tocar. El modelo aporta el criterio; el harness aporta todo lo demás.

Lo que hace realmente el harness

Si despojas a un agente de todo, quedan cinco responsabilidades, y ninguna de ellas puede asumirla el modelo por sí solo.

El bucle. Una llamada al modelo devuelve una vez y se detiene. Un agente sigue adelante: llama al modelo, ejecuta la herramienta que ha pedido, añade el resultado y vuelve a llamar, hasta que la tarea termina o se alcanza un límite. Ese ciclo es el trabajo central del harness, y casi todo lo que distingue a un harness de otro —cómo reintenta, cuándo se rinde, si puede ejecutar pasos en paralelo— es una decisión sobre el bucle.

Las herramientas. Leer un archivo, ejecutar un comando, buscar en la web. El harness anuncia qué hay disponible, valida los argumentos que ha producido el modelo, ejecuta la llamada y devuelve el resultado con un formato que el modelo pueda leer.

El contexto. Todo modelo tiene una ventana finita y una tarea real la desborda. Decidir qué se queda, qué se resume y qué se vuelve a recuperar bajo demanda es responsabilidad del harness, y es lo que los usuarios notan de forma más directa cuando un agente olvida lo que estaba haciendo.

Las sesiones. El trabajo que abarca horas o sobrevive a reinicios tiene que vivir en algún sitio: transcripciones, estado intermedio, la capacidad de reanudar. Sin persistencia tienes una ventana de chat, no un agente.

Los permisos. Un agente capaz de ejecutar comandos de shell es una superficie de seguridad. Las confirmaciones, las listas de permitidos, los sandboxes y los límites del sistema de archivos viven todos en el harness, porque no se puede confiar en que el modelo se vigile a sí mismo, y nunca se diseñó para ello.

Lo que no es un harness

No es el modelo. Cambiar de modelo altera lo bien que razona el agente; no altera si las sesiones se reanudan o si un comando necesita aprobación. Esas son propiedades del harness, y por eso un mismo modelo puede parecer capaz en una herramienta y desastroso en otra.

Tampoco es un plugin de IDE, aunque los dos se confunden con facilidad porque a menudo conoces el harness a través de un editor. Una extensión de editor es una superficie: recoge tu petición y muestra la salida. El harness es lo que posee el bucle, la ejecución de herramientas y el estado. Un harness bien construido puede gobernar varias superficies —una CLI, una interfaz web, un editor— sobre la misma sesión, lo cual es una buena prueba para saber si tienes delante un harness o una fachada.

Cómo lo implementa DeepSeek Harness

DeepSeek Harness —dsh— fue publicado por DeepSeek AI el 13 de agosto de 2026 bajo licencia MIT, y adopta una postura inusualmente literal sobre todo lo anterior: todo es un plugin. Modelos, herramientas, skills, sesiones, sandboxes, sistemas de archivos, el propio bucle, la orquestación y la interfaz de usuario son todos plugins cargados en un único runtime compartido.

Ese runtime es Cordis, un metaframework cuyo trabajo es cargar y cablear plugins; @deepseek-ai/cordis es una peer dependency de todos los paquetes del harness. La composición ocurre en una configuración de loader cordis.yml que enumera los plugins a arrancar y sus opciones, y una opción --profile elige entre conjuntos pensados para distintas situaciones: entre los perfiles incluidos está headless.

La consecuencia es que en dsh no hay una línea significativa entre la aplicación y sus extensiones. Reemplazar el sandbox es estructuralmente el mismo acto que añadir una herramienta. Por eso un directorio de plugins importa aquí más que en la mayoría de herramientas de agente: la capacidad vive en los paquetes, no en el núcleo. Ahora mismo indexamos 7900 repositorios con topics de dsh, de los cuales 3942 muestran cableado real de plugin; puedes verlos o recorrerlos por categoría. Una advertencia que conviene repetir: dsh es una vista previa para desarrolladores y su README avisa de que vienen cambios que rompen la compatibilidad, así que el formato de loader descrito aquí es una instantánea, no un contrato.

Harnesses frente a frameworks de agentes

Un framework de agentes es una biblioteca con la que construyes una aplicación. Te entrega primitivas de bucle, abstracciones de herramientas y ayudas de memoria, y te deja a ti las decisiones de producto: tú escribes el programa, y lo que entregas es tuyo.

Un harness ya ha tomado esas decisiones. Lo instalas y funciona: hay un bucle por defecto, un conjunto de herramientas por defecto, un modelo de permisos por defecto y una forma de reanudar la sesión de ayer. El intercambio es el habitual entre una biblioteca y un producto: menos control, muchísimo menos que construir.

dsh ocupa un lugar interesante en esa línea. Es un harness que puedes ejecutar de inmediato, pero como cada parte de él es un plugin sobre un framework de propósito general, un usuario suficientemente obstinado puede reemplazar las partes que la mayoría de harnesses tratan como fijas. La distinción sigue en pie —puedes usar dsh sin escribir una línea de código— pero la frontera es más blanda de lo habitual.

Harnesses frente a MCP

MCP, el Model Context Protocol, se menciona a menudo en la misma frase que los harnesses, pero resuelven problemas distintos. MCP es un protocolo: estandariza cómo una herramienta o fuente de datos se describe a sí misma y responde a las llamadas, de modo que un servidor escrito una vez pueda usarlo cualquier cliente que lo hable. Responde a «cómo llega el agente hasta esta cosa».

Un harness responde a «quién ejecuta el bucle y cuándo llega a llamarse esa herramienta». Gestiona contexto, permisos y sesiones, y MCP no tiene opinión sobre ninguna de esas cosas. Un harness puede ser un cliente MCP, en cuyo caso los servidores MCP pasan a ser una fuente más de herramientas junto a todo lo demás que ofrezca. Si quieres la versión concreta dentro del ecosistema de dsh, la categoría de MCP y herramientas del directorio reúne los plugins que se sitúan en esa frontera.

Preguntas frecuentes

¿El harness es lo mismo que el modelo?: No. El modelo convierte texto en más texto y no tiene memoria de ayer, ni acceso a archivos, ni capacidad de ejecutar nada. El harness es el programa que lo rodea y decide qué ve el modelo, ejecuta las herramientas que pide, le devuelve los resultados y detiene el bucle cuando el trabajo está hecho.
¿Un harness de agente es solo un envoltorio sobre una llamada a una API?: Una llamada suelta no es un harness. El rasgo definitorio es el bucle: el harness llama al modelo, ejecuta la herramienta que el modelo ha solicitado, añade el resultado a la conversación y vuelve a llamar, repitiendo hasta que se cumple una condición de parada. Todo lo difícil de los harnesses —gestión de contexto, permisos, persistencia de sesiones, recuperación de errores— existe por culpa de ese bucle.
¿En qué se diferencia un harness de un framework de agentes?: Un framework es una biblioteca con la que construyes una aplicación; un harness es un programa ejecutable que usas. Los frameworks te dan las piezas y te dejan a ti las decisiones, mientras que un harness ya ha tomado esas decisiones y las entrega como valores por defecto. La línea se difumina cuando un harness es inusualmente configurable, que es exactamente lo que es DeepSeek Harness.
¿Un harness de agente sustituye a MCP?: No, responden a preguntas distintas. MCP es un protocolo que describe cómo una herramienta o fuente de datos se expone a un agente, mientras que un harness es el programa que ejecuta el bucle y decide si esa herramienta llega a llamarse siquiera. Un harness puede actuar como cliente MCP, lo que los hace complementarios y no competidores.
¿Qué hace inusual a DeepSeek Harness entre los harnesses?: Su diseño en el que todo es un plugin. Modelos, herramientas, skills, sesiones, sandboxes, sistemas de archivos, el bucle, la orquestación y la interfaz son todos plugins cargados en un runtime compartido de Cordis y compuestos mediante un archivo cordis.yml, de modo que las partes que la mayoría de herramientas tratan como interioridades fijas aquí son paquetes reemplazables.

Sigue leyendo

Para ver las ideas anteriores como software en marcha, instala dsh: un solo comando npx te deja una interfaz web en http://127.0.0.1:3080. Para ver cómo se compara un harness donde todo es un plugin con un producto propietario consolidado, lee nuestra comparación temprana de dsh y Claude Code.