DeepSeek Harness, todo es un plugin

¿Y si el harness fuese un sistema operativo?

Los móviles no traen cada app dentro del sistema: el sistema ofrece servicios y tú instalas apps. DeepSeek Harness aplica esa idea a los agentes. Su definición es Agente = Modelo + Entorno + Herramientas + Estado, y su lema, que todo es un plugin: el adaptador del modelo, el registro de herramientas, el log de sesión e incluso el bucle del agente. No hay un núcleo privilegiado al que parchear; amplías montando otro plugin al lado.

Se lanza con un comando (npx @deepseek-ai/dsh web) o como aplicación de escritorio. Está en vista previa pública y es de código abierto, basado en la arquitectura de plugins Cordis.

Lo que se ve desde fuera

La web oficial destaca estas ideas:

• Todo es un plugin: instalas plugins o los creas conversando en el modo «Creator» para ampliar herramientas, skills e interfaz.
• Tareas programadas: puedes lanzar trabajo en cualquier momento y repetirlo en un horario, vigilando el progreso.
• Modos de permisos y herramientas: la interfaz muestra el modo (por ejemplo «Workspace Write») y puedes inspeccionar los detalles de cada llamada a herramienta.
• Trazas de ejecución: herramientas de desarrollo para ver trazas e información detallada y depurar fallos.

Idea 1: capability seams

Una capacidad (archivos, shell, sandbox, web, subagentes) se declara con tres roles:

Definición del servicio  ->  Proveedor  ->  Consumidor
 (la interfaz)               (la implementa)  (p. ej. una herramienta del modelo)

Debajo del servicio de archivos puede haber un proveedor local, uno en un sandbox remoto y otro de red. El modelo sigue viendo las mismas herramientas de archivos aunque cambies todo el entorno por debajo. Es como un enchufe estándar: da igual qué central genera la electricidad.

Idea 2: cada paso del bucle es un evento

En vez de «modelo, herramienta, modelo», cada etapa de un turno emite un evento al que los plugins pueden engancharse:

turn/start -> assemble (prompt, contexto, herramientas)
 -> agent/pre-step -> llm request -> respuesta
 -> tool/call -> tools/pre-execute (permisos, guardas, políticas)
 -> tools/execute -> tools/post-execute -> tool/result -> siguiente turno

¿Quieres comprobar la seguridad antes de ejecutar? Escucha tools/pre-execute. ¿Memoria? Inyéctala en agent/pre-step. ¿Registro? Suscríbete a los eventos. Permisos, memoria y políticas entran como oyentes, sin tocar el bucle.

Idea 3: «Model-visible means logged»

Hay un log de sesión que solo añade líneas, y una regla firme: todo lo que llegue a una petición al modelo debe poder reconstruirse desde el log, y un invariante del programa lo comprueba. La observabilidad deja de ser un extra y pasa a ser una restricción de base. Conecta con ver lo que hace el agente.

El coste

Más libertad pide más configuración. Y como todo son plugins, no hay una convención integrada tipo CLAUDE.md: tus reglas las inyectas tú. Además está en vista previa, así que los mecanismos pueden cambiar.