Veo este lanzamiento como algo que ofrece dos cosas: un agente de programación listo para usar y un framework meta-harness subyacente, de forma muy parecida a cómo Pi se relaciona con OpenClaw.
Esto también puede explicar parte de la controversia en torno al proyecto. No siempre se está hablando de lo mismo. Muchos críticos están evaluando lo primero, mientras que a mí me interesa más el diseño de lo segundo.
DeepSeek Harness hace que el propio agente de programación sea conectable. Las empresas y los desarrolladores pueden reemplazar componentes individuales y ensamblar un Harness que se ajuste a sus propias necesidades. También ofrece un modo de creación para la autoextensión en tiempo de ejecución y la mejora iterativa.
A alto nivel, el modelo se ve así:
- El Kernel proporciona los mecanismos de ejecución y extensión.
- Los Plugins proporcionan capacidades atómicas reemplazables y componibles.
- Las empresas seleccionan Plugins de la comunidad o crean los suyos propios, y luego empaquetan el Kernel y los Plugins en un Harness interno adaptado a sus necesidades.
Para entender por qué esto importa, primero debemos aclarar qué queremos decir con Harness.
¿Qué es un Harness?
Hace unos días, alguien de InfoQ me hizo una pregunta:
Desde la gestión del contexto y la planificación de tareas hasta las llamadas a herramientas MCP y la orquestación multiagente, las capacidades de los Harness son cada vez más similares. ¿Dónde queda espacio para una innovación significativa?
Todavía no existe una definición universalmente aceptada de Harness.
Mi opinión es que un modelo proporciona las capacidades fundamentales de razonamiento y cognición de un agente. El Harness determina cómo se organizan, se invocan y se aplican esas capacidades a tareas reales. Juntos, el modelo y el Harness definen las capacidades prácticas y el rendimiento del agente.
Divido los Harness en dos capas.
Un Harness en sentido estricto es el framework de ejecución que ayuda a un agente de programación a completar una tarea. Incluye la gestión del contexto, la memoria, las llamadas a herramientas, la planificación, las pruebas, la validación y la orquestación multiagente. Determina si el agente puede terminar una tarea de forma fiable.
Un Harness en sentido amplio es el sistema de bucle cerrado que permite a un agente recibir validación, retroalimentación y corrección dentro de un entorno empresarial real. Conecta al agente con los sistemas y procesos de una organización, ayudándole a seguir haciendo lo correcto con el tiempo.
La primera mitad del problema del Harness trata sobre cómo un agente completa una tarea. Las capacidades en esta área ciertamente están convergiendo.
Pero listas de características similares no producen resultados idénticos. Las diferencias en velocidad, precisión, estabilidad, coste y recuperación ante fallos a menudo quedan ocultas bajo la superficie.
La segunda mitad trata sobre cómo un agente entra en sistemas reales de ingeniería y negocio, recibe retroalimentación y sigue trabajando hacia un objetivo.
Aquí es donde surgirá cada vez más la diferenciación: validación específica del escenario, atribución de la retroalimentación y ejecución en bucle cerrado.
Las plataformas de desarrollo, los registros de producción, los sistemas de trazabilidad, las plataformas de automatización internas, el conocimiento propietario y las reglas organizativas deben conectarse. Un agente debe ver retroalimentación real, determinar si el resultado es correcto, localizar el origen del fallo y seguir haciendo correcciones.
Esta capa depende en gran medida del entorno específico. Un agente de programación de propósito general no puede resolverla directamente.
El mismo agente de programación puede parecer casi mágico en un equipo y completamente inútil en otro. La diferencia suele estar en el Harness que el equipo ha construido a su alrededor.
Por eso tantos proyectos están empaquetando Plugins. En esencia, estos Plugins convierten Skills, integraciones MCP, documentación y conectores antes dispersos en unidades instalables, componibles y distribuibles.
Visto desde esta perspectiva, la dirección de DeepSeek Harness se vuelve mucho más clara.
Mirando de nuevo a DeepSeek Harness
El mensaje central de DeepSeek Harness es «Todo es un Plugin».
Más importante aún, hace que el propio agente de programación sea conectable. Los modelos, las herramientas, los Skills, las sesiones, los sandboxes, el almacenamiento, los bucles, la planificación y la interfaz de usuario se ensamblan a partir de Plugins que pueden reemplazarse y recombinarse.
Esto significa que una empresa puede usar Plugins de la comunidad, desarrollar sus propios Plugins específicos para su escenario o reemplazar los componentes predeterminados del Harness incluidos con DeepSeek Harness.
En principio, esto aumenta la flexibilidad del desarrollo secundario y reduce la necesidad de hacer un Fork de todo el proyecto, lo que facilita seguir el desarrollo upstream.
El diseño me recuerda a lo que hicimos con Egg hace años.
Egg proporcionaba un Kernel de ejecución, un sistema de Plugins y un mecanismo de extensión para construir frameworks de nivel superior.
Se puede usar el mismo modelo para entender DeepSeek Harness:
- El Kernel proporciona los mecanismos de ejecución y extensión.
- Los Plugins proporcionan capacidades atómicas reemplazables y componibles.
- Las empresas combinan el Kernel con Plugins de la comunidad o desarrollados internamente para construir su propio Harness.
La idea es mantener un Kernel estable y dejar que el ecosistema explore el resto.
Si esta dirección tiene éxito, podríamos acabar con más de un oh-my-dsh. Podríamos ver innumerables variantes construidas para diferentes escenarios.
Cómo podría afectar a los agentes de programación existentes
Algunas personas de la comunidad han bromeado diciendo que equipos como MiniMax, Kimi y ZCode deben de estar sonriendo.
No estoy tan seguro.
Puede que DeepSeek Harness no cree una presión de producto inmediata para los agentes de programación existentes. Su impacto a nivel de ecosistema, sin embargo, podría volverse mucho más significativo.
La visión de AGI de Liang Wenfeng y los modelos de código abierto de DeepSeek ya proporcionan dos poderosos puntos de reunión. DeepSeek Harness ahora añade una propuesta arquitectónica interesante.
Si la arquitectura resiste el escrutinio del mundo real, podría atraer a desarrolladores de código abierto de todo el mundo. En ese caso, puede que los equipos de agentes de programación existentes no sean necesariamente los que rían al final.
Pi, que históricamente desempeñó un papel importante bajo OpenClaw, sigue siendo ampliamente discutido. OpenCode también sigue atrayendo a una comunidad leal de desarrolladores. Pero estos proyectos tienen Harnesses sin sus propios modelos fundacionales.
DeepSeek tiene tanto el LLM como el Harness. Esa combinación crea un potencial de ecosistema sustancial.
La comunidad ha estado discutiendo recientemente cómo el mismo modelo puede rendir de forma muy diferente bajo distintos Harnesses.
¿Y si DeepSeek Harness acabara formando parte de la infraestructura compartida para comparar modelos?
Si se convirtiera en una base de Harness preferida en la comunidad de código abierto, y los desarrolladores construyeran gradualmente un rico ecosistema de Plugins a su alrededor, DSH podría convertirse en un estándar de facto. Otros agentes de programación podrían entonces avanzar hacia la compatibilidad con sus interfaces y convenciones.
Estas posibilidades siguen siendo especulativas. Se basan en las ideas y la arquitectura visibles hoy, no en resultados de ecosistema probados.
El concepto es convincente y el potencial es real. Lo que ocurra a continuación depende de si la arquitectura sigue obteniendo el apoyo de la comunidad después de que los desarrolladores hayan examinado el código con lupa.