Se lanza DeepSeek Harness, situando el tiempo de ejecución de agentes por encima del modelo
DeepSeek lanzó DeepSeek Harness v0.1 el 13 de agosto de 2026, abriendo un nuevo frente que va más allá del rendimiento de los modelos. La vista previa para desarrolladores ofrece a los programadores un tiempo de ejecución de código abierto para ensamblar agentes a partir de modelos, herramientas, habilidades, sesiones, entornos aislados e interfaces intercambiables. Con este movimiento, DeepSeek entra en competencia directa con las capas de software que convierten los modelos de lenguaje en productos funcionales.
No se trata de otro checkpoint de modelo. DeepSeek Harness, también llamado dsh, determina cómo un modelo recibe contexto, invoca herramientas, gestiona archivos, conserva sesiones y completa trabajos de varios pasos. Estas decisiones pueden importar tanto como el modelo subyacente durante tareas reales.
El lanzamiento también modifica la posición de DeepSeek en el mercado de desarrolladores. Hasta ahora, muchos equipos utilizaban modelos de DeepSeek dentro de productos de agentes controlados por otros proveedores o proyectos independientes. DeepSeek ahora puede influir tanto en el motor de razonamiento como en el tiempo de ejecución que lo rodea.
Por tanto, la competencia central no enfrenta simplemente a DeepSeek con otro proveedor de modelos. Enfrenta un tiempo de ejecución abierto y componible con agentes integrados verticalmente como Claude Code y OpenAI Codex. DeepSeek promete más componentes intercambiables, pero el carácter preliminar de la versión desplaza una mayor responsabilidad de integración y seguridad hacia los desarrolladores.
DeepSeek Harness es un tiempo de ejecución, no otro lanzamiento de modelo
El cambio importante es que DeepSeek ahora distribuye software que controla lo que ocurre antes, durante y después de cada llamada al modelo.
Un arnés de agentes es la capa de tiempo de ejecución que conecta un modelo con herramientas, memoria, archivos, permisos, interfaces y ciclos de ejecución. Decide qué puede observar el modelo, qué acciones puede solicitar y cómo gestiona el sistema esas solicitudes.
DeepSeek describe su nuevo proyecto como un arnés de agentes de código abierto construido alrededor de un principio: “Everything is a plugin.” El repositorio del proyecto enumera modelos, herramientas, habilidades, sesiones, entornos aislados, sistemas de archivos, ciclos, orquestación e interfaces de usuario como componentes intercambiables.
Esa lista revela el alcance del lanzamiento. DeepSeek no ofrece únicamente una ventana de chat para programación con un flujo de trabajo fijo. Está publicando una capa de ensamblaje desde la que los desarrolladores pueden construir distintos productos de agentes.
La vista previa inicial para desarrolladores incluye una interfaz web que se ejecuta localmente. Los desarrolladores con Node.js pueden iniciarla mediante el paquete @deepseek-ai/dsh, y la interfaz se sirve de forma predeterminada en una dirección local.
El repositorio también incluye un perfil sin interfaz gráfica para tareas que no requieren una interfaz visual. Un ejemplo documentado pide al agente que resuma un espacio de trabajo desde la línea de comandos. Otro expone sesiones de agentes mediante un protocolo de automatización que utiliza JSON-RPC sobre la entrada y salida estándar.
Estos puntos de entrada otorgan a DeepSeek Harness varios roles posibles. Un desarrollador individual puede ejecutarlo como una interfaz local de agente. Un equipo puede utilizar sus paquetes como base para un agente interno. Una empresa de producto puede integrar servicios seleccionados sin adoptar la interfaz completa.
DeepSeek publicó el proyecto bajo la licencia MIT. Esta licencia permite un uso, modificación y redistribución amplios, siempre que se conserven los avisos de copyright y licencia exigidos.
La decisión de licenciamiento importa porque un arnés opera excepcionalmente cerca del entorno operativo de una organización. Puede interactuar con repositorios, líneas de comandos, documentación interna, credenciales y servicios externos. Las empresas a menudo necesitan inspeccionar o modificar esta capa antes de aprobarla.
El repositorio presenta v0.1 como una vista previa para desarrolladores, no como un producto empresarial terminado. DeepSeek advierte explícitamente que habrá cambios incompatibles con versiones anteriores. Los desarrolladores deberían interpretar el lanzamiento como una invitación a experimentar y contribuir, no como una promesa de interfaces estables.
Esta advertencia no resta importancia al lanzamiento. Aclara qué cambió el 13 de agosto. DeepSeek pasó de suministrar inteligencia mediante modelos y API a proporcionar la estructura operativa que convierte la inteligencia en acción.
Por qué DeepSeek asciende en la pila de agentes
El acceso a modelos se está volviendo intercambiable, mientras que el arnés determina cada vez más si un agente es útil, controlable y difícil de sustituir.
Un modelo sin más puede generar código, analizar una solicitud o sugerir un comando. No puede inspeccionar por sí solo un repositorio ni modificar un archivo, a menos que otro sistema le proporcione esas capacidades. El arnés proporciona ese sistema.
Esta diferencia se hace visible durante tareas largas. Un agente de programación debe decidir qué archivos inspeccionar, qué información conservar y cuándo invocar una herramienta. Debe detectar comandos fallidos, revisar su plan y mantener una sesión coherente.
Dos productos que utilizan el mismo modelo pueden rendir de manera distinta porque sus arneses toman decisiones diferentes. Uno puede ofrecer descripciones de herramientas más claras. Otro puede resumir el contexto de forma más eficaz. Un tercero puede aislar los comandos en un entorno aislado más sólido.
Esta realidad genera presión sobre los proveedores de modelos. Si un agente externo controla la interfaz, el flujo de trabajo, las integraciones de herramientas y el historial del usuario, el modelo subyacente puede convertirse en una entrada intercambiable. El proveedor del arnés conserva la relación con el cliente y decide qué modelos reciben tráfico.
DeepSeek Harness aborda ese riesgo directamente. Ofrece a DeepSeek una capa de software en la que sus modelos pueden convertirse en la opción predeterminada, mientras mantiene el componente de modelo intercambiable. La empresa intenta ganar influencia sobre el tiempo de ejecución sin abandonar una arquitectura abierta.
El momento del lanzamiento también sigue el cambio de la industria desde asistentes conversacionales hacia agentes que completan trabajos de varios pasos. Los desarrolladores ahora evalúan más que la calidad de las respuestas. Les importan la fiabilidad de las herramientas, la gestión del contexto, la seguridad de ejecución, la observabilidad y la recuperación ante errores.
La propia documentación de DeepSeek refleja esas preocupaciones operativas. Su guía de desarrollo separa los sistemas de host y cliente, documenta comprobaciones automatizadas y describe pruebas tanto simuladas como con API reales. También proporciona interfaces para uso web, sin interfaz gráfica y de automatización.
Se trata de una superficie de producto distinta a la de un endpoint de API. Una API puede mantenerse estable mientras desarrolladores externos inventan los flujos de trabajo que la rodean. Un arnés debe coordinar muchos servicios cuyo comportamiento cambia a medida que los plugins entran y salen de una sesión en ejecución.
DeepSeek también obtiene una vía para aprender de los desarrolladores. Un sistema público de plugins puede revelar qué herramientas, flujos de trabajo y patrones de agentes atraen adopción. Esa retroalimentación puede influir en el entrenamiento futuro de modelos, el comportamiento de uso de herramientas y el diseño de API.
La estrategia se parece a un patrón de plataforma conocido. Primero, una empresa proporciona un componente técnico central. Después se introduce en la capa de orquestación donde los desarrolladores combinan ese componente con datos, herramientas y experiencias de usuario.
Sin embargo, DeepSeek no está simplemente cerrando la pila en torno a sus propios servicios. El diseño de su plugin de modelos permite que otros proveedores o modelos locales ocupen la misma posición. Esa apertura crea la tensión más interesante del lanzamiento.
Si la arquitectura funciona, DeepSeek puede convertirse en una plataforma de agentes influyente incluso cuando los desarrolladores mezclen varios modelos. Si no funciona, el proyecto podría servir principalmente como otra interfaz para la API de DeepSeek.
La diferencia dependerá de la adopción fuera de la base de usuarios existente de DeepSeek. Los desarrolladores deben considerar que los contratos de plugins son más fáciles de ampliar que los de los marcos competidores. Los equipos también deben confiar en el tiempo de ejecución que rodea a herramientas y archivos sensibles.
La apuesta de DeepSeek Harness es que todo debería ser intercambiable
DeepSeek apuesta a que los desarrolladores de agentes valoran más la componibilidad que la comodidad de un producto estrechamente controlado.
La arquitectura del proyecto se basa en Cordis, al que DeepSeek denomina un metamarco para la componibilidad espaciotemporal. En términos prácticos, Cordis gestiona servicios cuya disponibilidad y relaciones pueden cambiar con el tiempo y según los contextos de ejecución.
Una aplicación tradicional suele inicializar dependencias una vez y tratarlas como fijas. Un entorno de agentes se comporta de otro modo. Una sesión puede activar una herramienta para una tarea, crear un contexto de ejecución acotado y después desechar ambos cuando termina la tarea.
La base Cordis de DeepSeek está diseñada para ese entorno cambiante. Los plugins pueden proporcionar servicios, consumir otros servicios y responder a cambios en su contexto circundante. El propio marco sigue en desarrollo activo y su API no es estable.
DeepSeek Harness aplica este enfoque en toda la pila de agentes. Un adaptador de modelo se convierte en un plugin. Lo mismo ocurre con una colección de herramientas, un sistema de archivos, un entorno aislado, un gestor de sesiones, una interfaz de usuario o un ciclo de orquestación.
Esta estructura ofrece a los desarrolladores varias formas de control. Pueden sustituir un modelo sin reconstruir la interfaz. Pueden cambiar un entorno aislado sin reescribir el ciclo del agente. Pueden introducir una herramienta específica de la empresa mientras preservan el resto del tiempo de ejecución.
El mismo diseño puede admitir distintos modos de operación. Un cliente web necesita componentes orientados al navegador y un proceso host. Una implementación sin interfaz gráfica necesita una superficie de automatización sin la misma capa visual. Los plugins acotados permiten que ambas configuraciones compartan servicios sin convertirse en aplicaciones idénticas.
Este es el mecanismo detrás del mensaje “everything is a plugin”. No es solo un eslogan de marketplace. El repositorio está organizado como un gran espacio de trabajo de TypeScript que contiene paquetes de host, paquetes de cliente, aplicaciones, ejemplos, documentación y dependencias integradas.
La arquitectura de DeepSeek también distingue entre el host, donde operan los servicios privilegiados, y el cliente, donde se ejecutan los componentes de interfaz. Ese límite es importante porque un agente no debería conceder a un componente de navegador acceso sin restricciones a las capacidades del sistema.
El proyecto genera interfaces remotas entre esos dos lados. Los servicios de host pueden declarar métodos invocables, mientras que los componentes de cliente consumen contratos generados. Este enfoque busca mantener la interfaz sincronizada con las definiciones de servicio subyacentes.
Para los desarrolladores, el atractivo es la personalización sin mantener un fork completo. Una empresa podría crear una herramienta de repositorio de solo lectura, un almacén de documentos restringido o un ciclo de revisión especializado. Después podría empaquetar ese comportamiento como plugins.
Un caso de uso real podría involucrar a un equipo de ingeniería que revisa un repositorio desconocido. El agente podría cargar un plugin de búsqueda de código, un sistema de archivos de solo lectura y un modelo seleccionado para análisis. No necesitaría acceso a credenciales de despliegue ni a comandos de escritura.
Otro equipo podría crear un agente interno de investigación. Podría combinar fuentes web aprobadas, documentos locales, almacenamiento de sesiones y un modelo independiente para la síntesis final. La interfaz de usuario podría cambiar sin sustituir esos servicios subyacentes.
Esta modularidad también facilita la experimentación. Los equipos pueden comparar dos modelos con las mismas herramientas y lógica de sesión. Pueden probar distintos ciclos de orquestación sin cambiar el modelo. Esta separación puede revelar qué componente mejora realmente una tarea.
La posición independiente del modelo otorga a DeepSeek una ventaja estratégica y un riesgo estratégico. Admitir otros modelos puede ampliar la audiencia del proyecto. También puede ayudar a los desarrolladores a descubrir que otro modelo funciona mejor dentro del propio tiempo de ejecución de DeepSeek.
DeepSeek parece dispuesto a aceptar esa disyuntiva. La empresa compite por ocupar un lugar en la arquitectura de los agentes, no exige un control exclusivo sobre cada componente.
Una arquitectura abierta presiona a los agentes de programación integrados
DeepSeek Harness cuestiona la idea de que el modelo, la interfaz, las herramientas y el bucle de orquestación deban llegar como un único producto inseparable.
Claude Code y OpenAI Codex han acostumbrado a los desarrolladores a esperar un agente capaz de inspeccionar proyectos, ejecutar comandos, editar archivos e informar resultados. Sus diseños integrados reducen la configuración y dan a cada proveedor un control más estrecho sobre la experiencia completa.
Esa integración ofrece beneficios reales. El proveedor puede ajustar las descripciones de herramientas para su modelo, adaptar la gestión del contexto y coordinar actualizaciones de producto. Los usuarios reciben un límite de soporte más claro cuando algo falla.
El enfoque de DeepSeek parte de una prioridad diferente. En lugar de tomar todas las decisiones por el desarrollador, expone esas decisiones como componentes reemplazables. Los equipos pueden decidir qué modelo, sistema de archivos, sandbox y bucle deben participar en un despliegue.
El contraste tiene menos que ver con listas de funcionalidades que con la propiedad. En un agente integrado, el proveedor es dueño del entorno de ejecución y permite a los usuarios configurar partes seleccionadas. En DeepSeek Harness, los desarrolladores pueden ser dueños del entorno de ejecución y ensamblarlo a partir de paquetes.
Esa diferencia importa para organizaciones con requisitos inusuales de seguridad o infraestructura. Una empresa puede necesitar que los comandos se ejecuten dentro de un sistema de contenedores específico. Puede exigir que los registros permanezcan en una red interna. Puede querer proveedores de modelos distintos para diferentes clasificaciones de datos.
Una arquitectura de plugins puede adaptarse a esas restricciones de forma más directa. Sin embargo, cada personalización también crea otro componente que revisar, probar, actualizar y mantener.
Los productos integrados pueden avanzar más rápido en flujos de trabajo comunes porque sus equipos optimizan una ruta definida. Un harness abierto puede avanzar más rápido en los márgenes porque quienes están fuera no necesitan permiso para crear nuevas integraciones.
Por tanto, la competencia dependerá del esfuerzo de los desarrolladores. DeepSeek Harness tendrá éxito si la personalización ahorra más trabajo del que crea el framework. Tendrá dificultades si los equipos dedican su tiempo a resolver la compatibilidad de plugins y a seguir contratos inestables.
La documentación actual de DeepSeek muestra una ambición de ingeniería considerable. El repositorio admite múltiples generaciones de Node.js en integración continua, separa las compilaciones para navegador y host, e incluye amplias validaciones automatizadas. Esos detalles indican que DeepSeek pretende que el proyecto funcione como una plataforma reutilizable.
La guía de usuario también trata la interfaz web como un punto de entrada, no como el producto completo. Esto respalda la idea de que dsh es infraestructura para agentes, no simplemente una aplicación de chat con marca propia.
Aun así, la documentación y la arquitectura no demuestran fiabilidad en producción. Las comparaciones independientes deben probar combinaciones completas de harness y modelo bajo tareas idénticas. Las puntuaciones de benchmarks centrados solo en el modelo no pueden responder si el entorno de ejecución se recupera de herramientas fallidas o protege correctamente los archivos.
Esta comparación también debería evitar una falsa disyuntiva. Los desarrolladores no tienen que utilizar un solo agente. Un equipo puede adoptar un producto integrado para la programación rutinaria mientras prueba DeepSeek Harness para flujos de trabajo internos especializados.
El lanzamiento, en cambio, debilita la suposición de que el agente oficial de un proveedor de modelos debe ser un paquete cerrado. DeepSeek muestra que un entorno de ejecución oficial puede seguir siendo inspeccionable y extensible.
Esa decisión podría presionar a los competidores para que expongan más capas de su orquestación. También podría animar a proyectos independientes a adoptar convenciones de plugins compatibles. Ninguno de los dos resultados está garantizado por la vista previa inicial.
La primera prueba es si los desarrolladores externos crean plugins significativos en lugar de envoltorios superficiales. La segunda es si esos plugins siguen siendo compatibles a medida que DeepSeek cambia el framework. La tercera es si los equipos los despliegan para trabajo persistente.
La compatibilidad y la seguridad siguen siendo aspectos no probados
La vista previa ofrece a los desarrolladores control, pero también les transfiere la responsabilidad por interfaces inestables, la confianza en los plugins y los permisos de herramientas.
DeepSeek afirma claramente que se producirán cambios que romperán la compatibilidad. Esa advertencia debería orientar cada decisión de despliegue temprano. Un equipo puede evaluar el software hoy sin asumir que los contratos de plugins actuales sobrevivirán a la próxima versión.
Los cambios incompatibles son habituales durante una vista previa temprana. Permiten a los mantenedores corregir abstracciones débiles antes de que un ecosistema más amplio dependa de ellas. Sin embargo, los cambios frecuentes pueden desalentar a los desarrolladores de plugins, que deben actualizar integraciones repetidamente.
Cordis introduce otra capa inestable. Su propio repositorio indica que la API puede cambiar sin previo aviso. Por tanto, DeepSeek Harness depende de un meta-framework cuyos contratos públicos aún están en desarrollo.
El problema de seguridad es más importante. Un harness de agentes puede conectar la salida probabilística de un modelo con acciones deterministas del sistema. Una respuesta equivocada del modelo se vuelve más grave cuando el entorno de ejecución puede ejecutar comandos, modificar archivos o enviar datos a otros lugares.
La modularidad de los plugins no crea automáticamente un aislamiento seguro. Un plugin puede ampliar las capacidades del agente, pero también puede ampliar su superficie de ataque. Los equipos deben inspeccionar los permisos, el acceso a red, la gestión de credenciales y la retención de datos de cada componente.
Las instrucciones en prompts no constituyen un límite de seguridad suficiente. Un modelo al que se pide operar en modo de solo lectura sigue necesitando herramientas que impongan ese comportamiento. El entorno de ejecución debe impedir acciones prohibidas incluso cuando el modelo las solicite.
La separación entre host y cliente ofrece un límite arquitectónico útil, pero la calidad de la implementación importa. Los desarrolladores necesitan pruebas de que los servicios privilegiados validan las solicitudes y restringen correctamente los ámbitos. También necesitan un comportamiento claro cuando un plugin falla o deja de estar disponible.
Los plugins de terceros generan preocupaciones de cadena de suministro. Un paquete puede obtener acceso al código fuente, archivos locales o credenciales de API. Una actualización maliciosa podría explotar ese acceso sin cambiar la interfaz de usuario visible.
Por ello, las organizaciones deberían tratar la instalación de plugins como la aprobación de dependencias, no como la adición de una extensión cosmética. Deben fijar versiones, revisar el código fuente, limitar las credenciales y ejecutar herramientas en entornos restringidos.
La observabilidad es igual de importante. Los equipos necesitan registros que muestren qué modelo generó una solicitud, qué plugin actuó, qué argumentos recibió y qué cambió después. Sin ese rastro, la depuración y la revisión de incidentes se convierten en conjeturas.
Los materiales públicos de DeepSeek describen controles de desarrollo e infraestructura de pruebas. Aún no ofrecen pruebas independientes de que cada configuración compatible se comporte de forma segura ante entradas adversarias.
El proyecto incluye un documento de benchmark, pero los resultados de benchmarks requieren una interpretación cuidadosa. La puntuación de un agente refleja conjuntamente el modelo, los prompts, las herramientas, el entorno, la política de orquestación y las reglas de evaluación.
Esa dependencia dificulta las comparaciones. Una puntuación alta de DeepSeek Harness no aísla la contribución del harness salvo que otro sistema use el mismo modelo y entorno. Una puntuación de modelo obtenida con otro harness presenta el mismo problema.
Los desarrolladores también deberían resistirse a tratar la actividad del repositorio como adopción. Las estrellas, bifurcaciones y atención en línea muestran curiosidad. No demuestran retención, uso en producción ni menores costes operativos.
La evidencia temprana más creíble vendrá de tareas reproducibles. ¿Pueden distintos equipos instalar el mismo conjunto de plugins y obtener un comportamiento comparable? ¿Pueden actualizar sin reconstruir integraciones? ¿Pueden los administradores limitar las herramientas de un agente sin depender de prompts?
DeepSeek ha dado a los desarrolladores suficiente código para investigar esas preguntas. Aún no ha aportado suficiente historial de campo para resolverlas.
Tres señales mostrarán si DeepSeek Harness importa
La próxima fase depende de la adopción de plugins, la estabilidad de las interfaces y evidencia creíble de despliegues completos de agentes.
La primera señal es una comunidad útil de plugins de terceros. DeepSeek invita a los desarrolladores a etiquetar repositorios compatibles con el tema dsh-plugin, creando una vía de descubrimiento fuera del código base principal.
La calidad de esos plugins importa más que su número. Los adaptadores ligeros pueden generar impulso inicial sin demostrar que la arquitectura admite trabajo exigente. Los plugins para sandboxes seguros, autenticación empresarial, observabilidad y sistemas de archivos restringidos aportarían pruebas más sólidas.
Una comunidad sana también necesita mantenedores más allá de DeepSeek. Los desarrolladores independientes deben documentar la compatibilidad, responder a defectos y actualizar integraciones después de cambios en el framework. De lo contrario, el ecosistema seguirá dependiendo del equipo central pese a su licencia abierta.
Si los desarrolladores crean plugins sustanciales para distintos casos de uso, la tesis del entorno de ejecución abierto se refuerza. Si la mayor parte de la actividad permanece dentro del repositorio de DeepSeek, el proyecto se parecerá más a un cliente oficial configurable.
La segunda señal es el camino desde la v0.1 hacia contratos estables. Las incompatibilidades en fase de vista previa son aceptables, pero los desarrolladores necesitan ver qué interfaces se están volviendo fiables.
DeepSeek puede reforzar la confianza mediante APIs de plugins versionadas, guías de migración, períodos de deprecación y pruebas de compatibilidad. Un modelo de seguridad definido importaría tanto como una interfaz de programación estable.
La estabilidad no exige congelar todas las funciones. Exige hacer los cambios lo bastante predecibles para que los mantenedores externos puedan planificar en torno a ellos. La disciplina de pruebas existente del proyecto proporciona una base, pero las promesas públicas de compatibilidad serán la verdadera prueba.
Si las actualizaciones se vuelven rutinarias, DeepSeek Harness podrá respaldar productos duraderos. Si cada lanzamiento obliga a reescrituras importantes, los desarrolladores lo reservarán para experimentos.
La tercera señal es la evaluación independiente de flujos de trabajo completos. Las pruebas deberían comparar harnesses controlando el modelo, el entorno de tareas, las herramientas y las acciones permitidas.
Las evaluaciones útiles deberían medir más que la finalización de tareas. Deberían registrar acciones no autorizadas, recuperación ante herramientas fallidas, intervenciones humanas, tiempo de ejecución y la precisión de los artefactos entregados.
Las pruebas de seguridad merecen una línea independiente. Los investigadores deberían examinar la inyección de prompts, repositorios maliciosos, plugins comprometidos, exposición de credenciales e intentos de escapar de sandboxes.
Los estudios de caso en producción aportarían otra forma de evidencia. Un equipo que use DeepSeek Harness para trabajo repetido puede informar con qué frecuencia los agentes terminan correctamente y cuánta supervisión requieren. Esas observaciones revelan debilidades que las demostraciones puntuales no detectan.
Si los resultados independientes muestran que su modularidad preserva la fiabilidad, DeepSeek tendrá una respuesta convincente frente a los agentes integrados. Si la personalización produce un comportamiento inconsistente, los productos estrechamente controlados conservarán una ventaja.
El lanzamiento ya establece un hecho: DeepSeek ya no quiere competir solo en el endpoint del modelo. Quiere que los desarrolladores construyan la capa operativa alrededor de los agentes sobre bases controladas por DeepSeek.
Para los desarrolladores, la respuesta sensata es una experimentación enfocada. Elijan un flujo de trabajo acotado, restrinjan las herramientas disponibles y registren cada acción. Comparen ese despliegue con un agente existente bajo la misma tarea y proceso de revisión.
Los equipos que documenten esas pruebas pueden preservar decisiones y hallazgos en una base de conocimiento de ingeniería. Ese registro se vuelve esencial cuando cambian los plugins, las versiones de los modelos y las políticas de seguridad.
DeepSeek Harness merece atención porque convierte el tiempo de ejecución de los agentes en un terreno competitivo explícito. Su arquitectura abierta ofrece a los desarrolladores un control inusual, mientras que su condición de vista previa deja sin resolver cuestiones de fiabilidad y gobernanza.
La pregunta para los próximos meses es concreta: ¿convertirán los desarrolladores los plugins reemplazables en sistemas fiables, o los costes de integración los empujarán de nuevo hacia agentes integrados? DeepSeek ha expuesto su postura. Ahora los despliegues reales deben ponerla a prueba.
