DeepSeek Harness: un runtime de agentes donde todo puede componerse
DeepSeek Harness (dsh) es un harness de agentes de código abierto de DeepSeek AI. Su propuesta central no es solo ejecutar un modelo: es componer modelos, herramientas, sesiones, interfaces y políticas como plugins reemplazables.
La composición que describe el proyecto
- Perfilcomposición nombrada de bundles
- Bundlesconfiguración distribuible y parcheable
- Pluginsservicios · eventos · capacidades
- Sesiónlog durable · contexto reconstruible
- Agentemodelo · herramientas · pasos
- Políticasandbox · aprobación · telemetría
Qué es y qué no es DeepSeek Harness
dsh es una plataforma de ejecución y composición para agentes, con Web UI, modo headless, perfiles y un ecosistema de plugins. No es el modelo DeepSeek-R1 ni un paper de entrenamiento. Un modelo puede ser un adaptador dentro del harness; el harness organiza el trabajo que ocurre alrededor del modelo.
- El repositorio oficial lo presenta como open source y en developer preview.
- Se puede iniciar con `npx @deepseek-ai/dsh web` o desde el código fuente.
- El Web UI requiere configurar un proveedor/modelo y seleccionar un workspace.
- La compatibilidad no debe darse por estable: el propio proyecto anuncia cambios incompatibles.
“Everything is a plugin” es una frontera arquitectónica
La arquitectura oficial describe Cordis como el framework bajo dsh: los plugins aportan servicios, eventos tipados y efectos reversibles a un contexto compartido. El modelo, el registro de herramientas, el log de sesión y el loop del agente participan de esa composición.
- Un perfil apila bundles en un orden definido.
- Los parches pueden reemplazar filas de configuración o insertar nuevas.
- Las capacidades se conectan mediante seams: definición de servicio, proveedor y consumidor.
- Cambiar un proveedor puede cambiar una capacidad completa sin forkear cada consumidor.
El log de sesión es parte del contrato
La documentación de arquitectura trata el log append-only como la fuente del contexto que ve el modelo. Las sesiones, los turnos, los pasos, los mensajes, las llamadas a herramientas y sus resultados deben poder reconstruirse; lo que llega al modelo debe quedar representado en el log.
- Un turno puede contener cero o más pasos del modelo.
- Los eventos durables permiten replay, forks, transcripciones y telemetría.
- Las herramientas pasan por una tubería de pre-ejecución, ejecución y post-ejecución.
- Agregar contexto visible al modelo requiere una representación durable, no solo una variable temporal.
La velocidad necesita límites operativos
Un harness útil no elimina las decisiones humanas. Las mueve a límites explícitos: workspace, permisos, sandbox, aprobación, secretos, telemetría y publicación. Para ingeniería de software, la ventaja está en cambiar proveedores y capacidades sin perder trazabilidad.
- Configurar el API key y el workspace son pasos explícitos del Web UI.
- El agente puede leer, editar, ejecutar, delegar y mantener un plan bajo la política activa.
- Las operaciones que requieren aprobación deben seguir detrás de esa política.
- En developer preview, cada actualización debe tratarse como un cambio de compatibilidad que requiere verificación.
El harness y los papers: relacionados, no equivalentes
DeepSeek-R1 estudia cómo incentivar capacidades de razonamiento mediante reinforcement learning y describe patrones emergentes como reflexión, verificación y adaptación de estrategia. Ese trabajo ayuda a entender el modelo; no documenta la arquitectura de dsh. El paper más directamente conectado con el harness es el preprint de Cordis sobre composición espacio-temporal, efectos reversibles y coeffects reactivos.
- R1 responde a una pregunta de entrenamiento y capacidad de razonamiento.
- Cordis responde a una pregunta de composición dinámica de componentes.
- dsh aplica esa línea arquitectónica a un runtime de agentes y plugins.
- No conviene afirmar que el harness garantiza razonamiento, autonomía o resultados de negocio.