Crea un plugin pequeño con DeepSeek Harness Creator
DeepSeek-V4 Team · 8 de octubre de 2026 · 7 min read
Un primer plugin útil para Harness tiene una función bien delimitada y un resultado visible. Un panel que muestra una lista de verificación fija del proyecto es un mejor ejercicio de aprendizaje que una extensión que edita archivos, llama a servicios externos y gestiona credenciales al mismo tiempo. Cuando la versión pequeña funciona, tienes una base de comparación para cambios posteriores.
Harness dsh-v0.2.1-alpha.1, publicado el 3 de octubre de 2026, añade una entrada del administrador de plugins que abre el modo Creator con un borrador preparado. Este tutorial usa ese flujo de trabajo para diseñar e inspeccionar un plugin local. Los pasos siguen la documentación fijada por versión; el ejemplo es un ejercicio de validación, no una afirmación de que un paquete generado ya haya pasado una prueba en vivo de Harness.
Prepara un espacio de trabajo que puedas inspeccionar
Usa una instalación cuya versión hayas verificado, un proveedor de modelos configurado y un directorio vacío para este ejercicio. Si Harness es nuevo para ti, completa primero el inicio rápido local. Mantén el ejercicio separado de la única copia de un proyecto importante.
El resultado debería ser un directorio fuente del plugin más una breve explicación de cómo esa versión de Harness lo carga. Pide al agente que identifique la entrada del paquete, las dependencias y la configuración del bundle en lugar de asumir que un único archivo TypeScript es instalable a través del administrador de plugins.
Elige un objetivo de validación concreto: un panel titulado Lista de verificación del proyecto con tres filas fijas. La primera versión no debería descubrir archivos automáticamente ni guardar estado. Estas son características razonables para más adelante, pero cada una añade comportamiento que tiene que ser revisado y probado.
Abre Creator e inspecciona el borrador
En la barra lateral, abre Plugins. Usa la flecha junto a Add plugin, luego selecciona Let the agent create a plugin. La referencia del administrador de plugins documenta esta acción cuando el módulo de interfaz del preajuste correspondiente la proporciona.
La acción abre el modo Creator. No inicia la generación hasta que envías la solicitud. Verifica el espacio de trabajo seleccionado y cualquier referencia de archivo, carpeta o sesión arrastrada. Una referencia antigua puede cambiar silenciosamente el proyecto que el agente cree que debería modificar.
Usa una solicitud con un resultado que puedas contar e inspeccionar:
Crea un plugin local de Harness para este espacio de trabajo vacío. Apunta a la versión de Harness instalada aquí e inspecciona su documentación disponible antes de elegir APIs. Añade un panel de Lista de verificación del proyecto con exactamente tres filas estáticas: Revisar entradas, Inspeccionar salida, Registrar resultado. No uses solicitudes de red, credenciales, escrituras automáticas de archivos ni temporizadores en segundo plano. Antes de editar, identifica los archivos que crearás. Después, explica cómo cargar el bundle local y cómo desactivarlo. Informa de cualquier validación que no pudieras ejecutar.
Las restricciones mantienen el ejercicio pequeño. También hacen que las dependencias inesperadas sean más fáciles de detectar. Un paquete para un panel estático tiene poca razón para introducir un cliente HTTP o un servicio de programación.
Lee la estructura generada antes de instalarla
El tutorial oficial del primer plugin explica el modelo básico de Cordis: un plugin exporta una función apply, y el contexto pasado a ella es donde se registran las contribuciones. El contexto es por lo tanto un punto de partida útil al rastrear qué hará el código generado.
Ese ejemplo introductorio no es una receta completa para un paquete de UI distribuible. Para el panel generado, pide al agente que rastree el punto de entrada real hasta su código de registro y renderizado. Debería ser posible explicar por qué existe cada archivo fuente sin leer un tutorial de framework de aplicación no relacionado.
Inspecciona el manifiesto del paquete y los scripts de instalación también. Confirma que las dependencias pertenecen a la implementación prevista, que los archivos referenciados existen y que los comandos usan el directorio del proyecto real. Si el agente dice que una compilación terminó correctamente, conserva el comando y su resultado de salida. Una explicación plausible de una compilación no es la salida de la compilación.
| Elemento a inspeccionar | Evidencia a buscar |
|---|---|
| Punto de entrada | El manifiesto o la configuración del bundle resuelve a un archivo real |
| Registro del panel | Una llamada específica conecta el plugin a su UI visible |
| Dependencias | Cada paquete añadido tiene un propósito explicado |
| Ciclo de vida | Desactivar el plugin elimina su contribución limpiamente |
| Validación | Se indican comandos, resultados y comportamiento no probado restante |
Instala el bundle local y verifica la versión cargada
Vuelve a Plugins → Add plugin. El administrador acepta un directorio local absoluto así como paquetes de registro y fuentes Git. Usa el directorio que las instrucciones de instalación generadas identifican como la raíz del bundle, no cualquier subcarpeta que simplemente contenga un archivo fuente.
Lee la vista previa de instalación y el aviso de confianza, luego instala y habilita las filas relevantes del bundle o plugin. El administrador distingue los bundles instalados del inventario incorporado mostrado en Settings. Si el panel está ausente, verifica que la fila correspondiente esté habilitada antes de cambiar el código fuente.
Mantén la identidad del paquete y la versión mostrada con tus notas de prueba. La versión de octubre mejora la información de versiones y la visibilidad de la fuente del código. Un paquete instalado más antiguo puede hacer que una edición correcta parezca no tener efecto. La observación del directorio de desarrollo y la sustitución de una versión de paquete instalado son caminos diferentes; este último aún necesita un reinicio.
Prueba un ciclo completo de activación y desactivación
Primero activa el plugin e inspecciona el panel. Cuenta las filas, verifica su orden y comprueba que el texto coincide con la solicitud. Luego desactiva el plugin y confirma que el panel desaparece. Actívalo de nuevo y comprueba que aparece una vez, sin entrada duplicada ni elemento sobrante.
Luego cambia una fila de texto en la fuente, usando el flujo de trabajo de desarrollo documentado para el bundle generado. Comprueba si el panel visible refleja la edición. Si no lo hace, establece la ruta de la fuente cargada y los requisitos de reinicio antes de pedir al agente que reescriba el componente.
Finalmente vuelve a abrir la aplicación y repite las comprobaciones visibles. Registra qué pasos pasaron y cuáles necesitaron un reinicio. Estas observaciones te dicen más sobre el ciclo de vida real del plugin que una única captura de pantalla exitosa.
Diagnostica fallos en la capa correcta
Un panel faltante puede significar varias cosas: el paquete no se resolvió, el bundle no fue habilitado, el registro falló o el renderizado falló. Comprueba esas etapas en ese orden. La documentación introductoria de Cordis señala específicamente que un fallo de resolución puede ser menos obvio durante el arranque temprano, así que verifica la ortografía de la ruta cuando una nueva entrada parece no hacer nada.
Para ejemplos más antiguos, vigila las exportaciones invariant eliminadas y el cambio de la fila stats del cuadro de entrada de mensajes a activity y usage. Estos son problemas de migración específicos de la versión descritos en las notas de la versión 0.2.1. No son razones para desactivar las comprobaciones de compatibilidad ampliamente.
Una vez que el panel estático supere las pruebas, añade una capacidad a la vez. Leer un archivo local elegido es un siguiente paso manejable si la ruta y el comportamiento de fallo son explícitos. Deja la persistencia y las solicitudes externas para iteraciones separadas. Mantén la versión mínima funcionando para que un fallo posterior pueda compararse con algo que realmente observaste funcionando.
Para el contexto más amplio de la actualización, consulta la revisión de Harness 0.2.1. Si el plugin que quieres crear solo existe para activar un recordatorio, primero consulta el flujo de trabajo de automatización incorporado; la aplicación host ya podría proporcionar el comportamiento de programación que necesitas.