DeepSeek abre su arnés de agentes para que cada componente pueda sustituirse

DeepSeek lanzó la primera vista previa para desarrolladores de Harness, y el conflicto detrás del titular de Google News es inusualmente concreto. La empresa no se limita a añadir plugins a otro agente de programación. Ha convertido en componentes sustituibles el adaptador de modelos, el registro de herramientas, el registro de sesiones, el sandbox, el bucle del agente y la interfaz de usuario.

Ese diseño sitúa a DeepSeek Harness por debajo de productos como Claude Code, Codex y otros agentes de programación listos para usar. Esos productos ofrecen a los desarrolladores un agente ensamblado con puntos de extensión definidos. DeepSeek ofrece un sustrato configurable que puede producir muchos agentes, incluido uno que se parezca a un asistente de programación.

La distinción también revela la mayor incertidumbre del proyecto. DeepSeek afirma que cada parte puede combinarse, sustituirse o ampliarse, pero el software sigue siendo una vista previa para desarrolladores. Su documentación advierte explícitamente que habrá cambios incompatibles con versiones anteriores. Por tanto, el lanzamiento es a la vez una propuesta arquitectónica y una prueba aún inconclusa de si una modularidad extrema puede sobrevivir al uso en producción.

Lo que realmente anunció el titular de Google News

DeepSeek ha abierto la maquinaria que rodea a un modelo de IA, no ha lanzado otro modelo con una nueva interfaz de chat.

DeepSeek Harness, también llamado dsh, es un arnés de agentes de código abierto publicado bajo la licencia MIT. Un arnés de agentes es el software que rodea a un modelo y gestiona prompts, herramientas, archivos, estado, permisos y llamadas repetidas al modelo.

El repositorio oficial del proyecto describe una idea rectora: “Everything is a Plugin”. Esto incluye modelos, habilidades, herramientas, sesiones, sandboxes, sistemas de archivos, bucles, orquestación y la interfaz presentada a los usuarios.

DeepSeek indica que la versión actual es una vista previa para desarrolladores. Los usuarios pueden iniciar su interfaz de navegador mediante un comando npm, que sirve la aplicación localmente de forma predeterminada. Los desarrolladores también pueden compilar el repositorio desde el código fuente.

El lanzamiento público siguió a señales de que DeepSeek estaba creando un equipo dedicado a Harness. Sin embargo, el código importa más que la señal previa de contratación. Ofrece a los desarrolladores un sistema concreto que pueden inspeccionar, modificar y ejecutar sin depender de una demostración de producto.

Esto explica por qué la historia circuló en Google News como algo más que el lanzamiento de otro repositorio. DeepSeek se hizo ampliamente conocida por sus modelos competitivos, pero Harness desplaza la atención hacia el software que determina cómo un modelo realiza trabajo real.

Un modelo de lenguaje en bruto recibe una entrada y genera una salida. Un agente operativo también debe decidir cuándo llamar a una herramienta, qué historial conservar, dónde pueden ejecutarse los comandos y cuándo se requiere aprobación humana.

Esas decisiones suelen explicar por qué dos productos que usan modelos similares se comportan de manera distinta. El sistema circundante puede recuperarse de un comando fallido, mantener un plan, comprimir el contexto o impedir una operación de archivos insegura. También puede gestionar mal cualquiera de esas responsabilidades.

DeepSeek está convirtiendo ese sistema circundante en el producto. Su aplicación web distribuida es una posible composición de los componentes subyacentes, no una implementación privilegiada que todos los usuarios deban aceptar.

El marco se basa en Cordis, que DeepSeek describe como un metamarco para software compuesto dinámicamente. Cordis permite que los plugins aporten servicios, eventos tipados y efectos reversibles a un contexto compartido.

Un efecto reversible es un cambio registrado que puede deshacerse cuando se descarga el componente que lo aportó. Esto proporciona al entorno de ejecución una forma estructurada de añadir o eliminar capacidades sin dejar estado desconocido.

Esa base respalda la promesa más amplia de DeepSeek. Los desarrolladores deberían poder sustituir un proveedor de sistema de archivos local por una implementación remota, cambiar el adaptador de modelos o introducir otro bucle de agentes mediante configuración.

El lanzamiento no demuestra que todas las combinaciones funcionarán de forma fiable. Sí demuestra que DeepSeek ha trazado límites de plugins alrededor de componentes que otros productos de agentes suelen tratar como fijos.

Esa diferencia crea la tensión central. Una maquinaria más sustituible proporciona a los desarrolladores mayor control, pero también crea más interfaces, relaciones de dependencia y modos de fallo que gestionar.

Por qué DeepSeek Harness presiona a los agentes de programación acabados

DeepSeek desafía la suposición de que los desarrolladores solo deberían personalizar un agente en los márgenes.

La mayoría de los asistentes de programación exponen mecanismos de extensión mientras preservan un centro con una opinión definida. Los desarrolladores pueden añadir herramientas, conectar servicios externos, instalar habilidades o cambiar instrucciones. El producto sigue controlando su bucle principal, su modelo de sesión y su interfaz.

DeepSeek Harness desplaza hacia dentro el límite de lo sustituible. Su documentación de arquitectura afirma que no existe un núcleo privilegiado que los desarrolladores deban parchear.

Incluso el bucle predeterminado del agente se registra mediante el mismo contexto compartido que las demás capacidades. Ese bucle controla cómo la entrada del usuario se convierte en solicitudes al modelo, llamadas a herramientas, resultados y pasos posteriores.

Esto no vuelve obsoletos a Claude Code, Codex o productos similares. Los agentes de programación maduros integran instalación, actualizaciones, autenticación, acceso a modelos, reglas de seguridad y decisiones de interfaz en una experiencia coherente.

Ese empaquetado tiene valor real. Un desarrollador que necesita corregir una prueba hoy podría preferir una herramienta con valores predeterminados sensatos a un marco que exige decisiones arquitectónicas.

DeepSeek, en cambio, presiona a equipos de investigación, ingenieros de plataforma y organizaciones que necesitan valores predeterminados distintos. Estos usuarios podrían requerir un sandbox personalizado, una pasarela interna de modelos, almacenamiento controlado o una ruta de ejecución auditable.

Un adaptador de modelos sustituible es especialmente importante. Separa el comportamiento del agente de la dependencia exclusiva de un único proveedor de modelos.

La propia documentación de la API de DeepSeek ya aborda arneses de terceros, incluido el extensible agente de programación Pi. La guía de integración de Pi también incluye una advertencia de que DeepSeek no garantiza la eficacia ni la seguridad de terceros.

Harness ofrece otra respuesta. En lugar de pedir a los desarrolladores que adapten los modelos de DeepSeek a un agente externo, DeepSeek puede suministrar la arquitectura circundante y, al mismo tiempo, permitir otros proveedores de modelos.

Eso hace que la competencia principal tenga menos que ver con DeepSeek frente a una empresa concreta. Es una competencia entre un sustrato profundamente configurable y un producto de agentes acabado y con una opinión definida.

La vía del sustrato permite a una organización definir cómo funciona su sistema. Un equipo podría usar un modelo para la planificación, otro para la generación de código y un modelo local para clasificaciones sensibles. Los proveedores pueden situarse detrás de un límite compartido de adaptadores.

El mismo equipo podría asignar diferentes herramientas a distintos agentes. Un especialista en bases de datos podría recibir acceso de solo lectura, mientras que un agente de despliegue recibe controles de lanzamiento delimitados de forma estricta.

Estas restricciones pueden residir en capacidades registradas y políticas de ejecución. No necesitan depender únicamente de una frase en un prompt de sistema.

La vía del producto con una opinión definida adopta concesiones distintas. Limita el número de decisiones que los usuarios deben entender, concentra las pruebas en rutas compatibles y crea un objetivo de soporte coherente.

Por tanto, DeepSeek Harness presiona a los productos establecidos en la capa de arquitectura, no necesariamente en la capa del usuario cotidiano. Los competidores deben decidir qué parte de su maquinaria interna deberían poder sustituir los desarrolladores.

Pueden mantener el centro controlado y ampliar las extensiones compatibles. Pueden exponer SDK y servicios de nivel inferior. También pueden argumentar que la sustitución total crea complejidad operativa sin suficiente beneficio práctico.

La respuesta inmediata obligada quizá no sea un marco equivalente. La señal más fuerte será si los proveedores de agentes aclaran sus límites arquitectónicos y hacen más comportamiento inspeccionable.

Para los compradores empresariales, esta no es una distinción abstracta. Un sistema de sesiones fijo puede entrar en conflicto con requisitos de retención. Un sandbox fijo podría no ser compatible con la infraestructura de una organización. Un flujo de herramientas fijo podría carecer de las puertas de aprobación necesarias.

Por tanto, los desarrolladores que sigan el lanzamiento a través de Google News deberían centrarse en la propiedad. DeepSeek propone que los equipos deben poseer una parte mayor de la pila de agentes, incluso cuando esa propiedad implique trabajo adicional.

Todo es un plugin, incluido el bucle del agente

El mecanismo destacable no es el número de plugins, sino la ausencia de un centro protegido que los plugins no puedan sustituir.

Una instancia en ejecución de DeepSeek Harness se ensambla como un árbol de plugins. Los perfiles definen composiciones con nombre, mientras que los bundles empaquetan filas de configuración y el código que esas filas montan.

DeepSeek proporciona plantillas web y sin interfaz. El bundle base suministra adaptadores de modelos, herramientas, persistencia, controles de sandbox, políticas de aprobación, credenciales, configuración y telemetría.

Los bundles adicionales pueden añadir una aplicación de navegador o un ejecutor de una sola ejecución. Las capas de configuración se aplican en orden, y los parches posteriores pueden sustituir filas o introducir otras nuevas.

Esta disposición permite que dos agentes compartan gran parte del mismo código mientras exponen capacidades diferentes. Un perfil podría incluir una interfaz de navegador y una shell local. Otro podría ejecutarse sin servidor dentro de un flujo de trabajo automatizado.

El proyecto divide el comportamiento central en paquetes. Las sesiones poseen un registro de eventos de solo anexado, lo que significa que los eventos registrados se añaden en lugar de sobrescribirse silenciosamente. Las herramientas tienen un registro con ámbito limitado y un flujo de ejecución protegido.

El paquete de prompts de sistema ensambla secciones de prompt y esquemas de herramientas. El paquete de modelos de lenguaje proporciona el vocabulario de mensajes y el límite de adaptadores de proveedores. El paquete de agentes expone agentes activos y eventos relacionados.

Un turno puede contener varios pasos. Cada paso consta de una solicitud al modelo y las herramientas llamadas desde esa solicitud.

Antes de la ejecución, los plugins pueden inspeccionar o rechazar trabajo mediante eventos definidos. La salida del modelo se transmite a la sesión, las llamadas a herramientas pasan por etapas previas y posteriores a la ejecución, y los resultados pueden desencadenar otra solicitud al modelo.

Esta estructura de eventos es importante porque la extensibilidad por sí sola no garantiza un comportamiento coherente. Los plugins necesitan puntos acordados donde puedan observar, modificar o detener el proceso.

DeepSeek usa eventos de sesión duraderos para hechos que deben sobrevivir a una recarga. Usa eventos de agentes activos para el trabajo que está actualmente en curso. Los eventos de capacidades permiten que políticas y adaptadores se conecten a subsistemas sin importar el bucle completo.

El registro de sesiones actúa como la fuente de verdad para el contexto visible por el modelo. DeepSeek afirma que cualquier elemento que alcance una solicitud al modelo debe poder reconstruirse a partir de ese registro.

Esa elección conecta varias funciones que a menudo se implementan de manera independiente. La reanudación, bifurcación, transcripciones, persistencia, reproducción y telemetría pueden derivarse de la misma secuencia de eventos.

La alternativa consiste en mantener representaciones separadas para la interfaz, el contexto del modelo, el historial guardado y el sistema de observabilidad. Esas copias pueden divergir tras errores, cancelaciones o compresión de contexto.

El diseño de DeepSeek no puede eliminar automáticamente esa divergencia. Las implementaciones de plugins aún pueden contener errores. Sin embargo, una fuente común de eventos ofrece a los desarrolladores un lugar definido para inspeccionar lo sucedido.

Las uniones de capacidades añaden otra capa. DeepSeek define una unión mediante una interfaz de servicio, un proveedor que implementa esa interfaz y un consumidor que utiliza el servicio.

Considera el acceso al sistema de archivos. Una herramienta orientada al modelo puede solicitar una operación de archivos, mientras que un proveedor del sistema de archivos decide dónde y cómo se lleva a cabo.

Sustituir el proveedor puede redirigir esa capacidad desde un espacio de trabajo local a un entorno aislado remoto. Las operaciones relacionadas de shell, terminal y servidor de lenguaje pueden compartir entonces ese entorno de ejecución.

Esta es una forma de modularidad más profunda que añadir un comando a un asistente existente. Cambia la ubicación y la política del trabajo del asistente sin reescribir cada consumidor.

Los subagentes utilizan un límite similar. Un proveedor podría crear un agente hijo dentro de Harness. Otro podría delegar la tarea a un producto independiente mientras preserva la interfaz del padre.

Cordis proporciona el modelo de composición subyacente. Su correspondiente documento del framework describe la composabilidad temporal como retirar un componente y revertir por completo sus efectos.

El documento define la composabilidad espacial como declarar dependencias y reaccionar cuando cambia el contexto compartido. Cordis combina estos conceptos mediante efectos rastreados, resolución de dependencias, reconciliación de configuración y reemplazo de módulos en caliente.

El documento se publicó como borrador con fecha del 13 de agosto de 2026. Sus autores advierten que se trata de una prepublicación en revisión activa y que su contenido puede cambiar de forma sustancial.

Esa advertencia importa. Un vocabulario formal puede facilitar la discusión sobre una arquitectura, pero no valida por sí mismo el rendimiento, la fiabilidad ni la seguridad.

El mecanismo de DeepSeek sigue siendo convincente porque alinea la teoría con una estructura de repositorio observable. El documento de arquitectura nombra servicios, paquetes, eventos, capas de configuración y puntos de reemplazo.

El resultado se parece más a un entorno operativo para agentes que a un único asistente. Los modelos y las herramientas son aplicaciones de ese entorno, mientras que el sistema de contexto y eventos los coordina.

Para los desarrolladores, el beneficio es una recomposición controlada. Para DeepSeek, el beneficio es alcance estratégico. Sus modelos pueden participar, pero Harness no exige que todo el ecosistema dependa de una sola familia de modelos.

La advertencia de vista previa para desarrolladores es el riesgo real

La afirmación de flexibilidad de DeepSeek es visible en el código, pero la preparación para producción sigue sin demostrarse y se descarta explícitamente.

El repositorio advierte en mayúsculas que se producirán cambios que romperán la compatibilidad. No es una nota menor de lanzamiento. Cambia la forma en que las organizaciones deberían evaluar el proyecto.

Un equipo puede experimentar hoy con DeepSeek Harness. No debería asumir que los perfiles, los contratos de plugins, los archivos de configuración o los servicios internos seguirán siendo estables entre actualizaciones.

Esta incertidumbre es especialmente importante para un framework diseñado en torno a interfaces reemplazables. Cada componente personalizado depende de algún contrato, incluso cuando la arquitectura minimiza el acoplamiento directo.

Si esos contratos cambian, los desarrolladores de plugins deben actualizar sus implementaciones. Una modularidad profunda puede contener un cambio, pero no puede eliminar el coste de mantener los límites.

La configuración también presenta un riesgo sutil. El sistema de capas documentado reemplaza toda la configuración de una fila específica en lugar de combinar automáticamente cada valor anidado.

Esta regla puede resultar predecible para operadores experimentados. También puede generar configuraciones faltantes cuando los usuarios suponen que un parche parcial conservará los campos no especificados.

El desafío mayor es el de las pruebas combinatorias. Un producto terminado puede validar una colección limitada de combinaciones de modelos, herramientas, sandboxes e interfaces.

Un framework que permite cambiar cada capa afronta una superficie de compatibilidad mucho mayor. DeepSeek no puede probar de forma realista cada adaptador de modelo de terceros frente a cada canal de herramientas y proveedor de almacenamiento.

Por tanto, la responsabilidad se desplaza hacia los autores de perfiles y los equipos de despliegue. Deben probar la composición exacta que planean operar.

La seguridad exige una cautela similar. Los sandboxes reemplazables y las políticas de herramientas crean oportunidades para un aislamiento más sólido, pero la posibilidad de reemplazarlos no garantiza una configuración segura.

Un proveedor permisivo de subprocesos puede socavar una lista de herramientas cuidadosamente restringida. Un plugin personalizado puede gestionar mal las credenciales, exponer contexto sensible o eludir el comportamiento de aprobación esperado.

El código abierto ayuda a los revisores a inspeccionar esas rutas. No significa que cada plugin con el tema dsh-plugin haya recibido una auditoría de seguridad.

El descubrimiento de plugins se convierte por sí mismo en un problema de confianza. Los desarrolladores necesitan procedencia, compatibilidad de versiones, señales de mantenimiento y una forma de entender qué código obtiene acceso a sesiones o credenciales.

Los ecosistemas de paquetes tradicionales ya tienen dificultades con dependencias maliciosas y módulos abandonados. Un plugin de agente puede tener un papel aún más sensible porque puede observar prompts, código fuente, resultados de herramientas y estado de ejecución.

El registro de solo anexado crea otra disyuntiva. Un historial detallado de eventos permite la reproducción y la auditoría, pero el contexto de modelo almacenado puede contener código propietario, documentos internos o entradas sensibles de usuarios.

Las organizaciones deben decidir dónde reside ese registro, quién puede buscar en él, cuánto tiempo permanece disponible y cómo se hacen cumplir los requisitos de eliminación.

El framework ofrece el almacenamiento como una preocupación reemplazable. La preparación empresarial dependerá de si los despliegues reales pueden configurar controles de retención y acceso sin debilitar las garantías de reproducción.

La atención de Google News también corre el riesgo de convertir el entusiasmo arquitectónico en afirmaciones de rendimiento sin respaldo. DeepSeek no ha demostrado con este lanzamiento que Harness haga que sus modelos sean más precisos que los de sus competidores.

El lanzamiento no proporciona un benchmark neutral que demuestre que la composición de plugins mejora la finalización de tareas. Tampoco prueba que la recuperación de Cordis produzca mejores resultados durante trabajos de larga duración.

Un harness capaz puede hacer que un modelo sea más útil al proporcionarle las herramientas y el contexto adecuados. No puede reparar todas las limitaciones del modelo subyacente.

Una planificación débil sigue siendo una planificación débil. Una selección incorrecta de herramientas aún puede causar fallos. Un agente puede conservar un registro perfecto de un enfoque fallido.

Los informes de usuarios publicados inmediatamente después de un lanzamiento pueden identificar pistas útiles, pero no pueden sustituir las pruebas controladas. Los primeros adoptantes se autoseleccionan, las configuraciones varían y la novedad puede influir en el juicio.

Los desarrolladores deberían evaluar el framework usando repositorios representativos y tareas repetibles. Las pruebas deberían incluir operaciones interrumpidas, permisos denegados, herramientas fallidas, compresión de contexto y actualizaciones de plugins.

También deberían comparar configuraciones equivalentes de modelos y herramientas. De lo contrario, un resultado favorable puede reflejar un modelo mejor, un conjunto de permisos más amplio o una tarea más sencilla, en lugar del harness.

DeepSeek merece reconocimiento por etiquetar el lanzamiento con precisión. La advertencia de vista previa para desarrolladores establece una expectativa honesta de que el proyecto avanza con rapidez.

La siguiente pregunta es si DeepSeek mantiene esa claridad a medida que crece la adopción. El versionado estable, la guía de migración, los informes de seguridad y las pruebas de compatibilidad importarán más que el eslogan original del lanzamiento.

Qué vigilar tras la atención de Google News

Tres señales mostrarán si DeepSeek Harness se convierte en infraestructura duradera o sigue siendo un experimento admirado.

La primera señal es la estabilización de contratos. Los desarrolladores deberían vigilar las notas de lanzamiento en busca de políticas de compatibilidad definidas para plugins, perfiles, eventos de sesión e interfaces de capacidades.

Los cambios incompatibles son normales durante una vista previa inicial. La medida importante es si esos cambios convergen hacia superficies estables documentadas.

Las herramientas de migración reforzarían el argumento. Períodos claros de deprecación y esquemas de configuración verificables por máquina reducirían el coste de mantener perfiles personalizados.

Si DeepSeek estabiliza las principales uniones sin congelar el progreso arquitectónico, su argumento a favor del framework se fortalece. Las reescrituras repetidas de integraciones de plugins lo debilitarían.

La segunda señal es la evidencia operativa independiente. Los equipos necesitan pruebas reproducibles que involucren repositorios reales, sesiones largas, fallos de herramientas y sandboxes restringidos.

El éxito de las tareas es solo una métrica. Los evaluadores también deberían medir el comportamiento de recuperación, el trabajo duplicado, la precisión del contexto, la aplicación de permisos y el esfuerzo necesario para diagnosticar fallos.

Los benchmarks deberían separar la capacidad del modelo del comportamiento del harness. Siempre que sea posible, el mismo modelo debería ejecutarse con diferentes configuraciones de harness.

Una prueba creíble también debería publicar sus permisos y herramientas disponibles. Un agente con acceso ilimitado al shell no debería compararse a la ligera con otro que opera dentro de un sandbox restringido.

Si las evaluaciones independientes muestran una recuperación fiable y una ejecución inspeccionable, el mecanismo de DeepSeek gana respaldo. Si los resultados dependen de un amplio ajuste manual, el framework seguirá siendo más útil para especialistas.

La tercera señal es la calidad del ecosistema de plugins. El número de repositorios y la atención social miden curiosidad, no una oferta fiable.

Los plugins útiles necesitan documentación mantenida, cobertura de pruebas, prácticas de seguridad e información explícita de compatibilidad. Un ecosistema de confianza también necesita procesos para informar sobre paquetes maliciosos o abandonados.

DeepSeek anima a los desarrolladores a etiquetar repositorios de plugins para facilitar su descubrimiento. El siguiente paso es una forma fiable de evaluar qué extensiones merecen acceso a herramientas, sesiones y credenciales.

Esta señal determinará quién adopta el framework. Los equipos de investigación pueden auditar por sí mismos módulos experimentales. La mayoría de los equipos empresariales necesitan un conjunto más reducido de componentes compatibles y revisables.

Las reacciones de los competidores merecen atención dentro de estas tres señales. Un rival no necesita copiar Cordis para validar la dirección de DeepSeek.

Más sandboxes reemplazables, historiales de eventos exportables, bucles de agentes documentados o SDK de orquestación de nivel inferior sugerirían que los desarrolladores demandan control por debajo de la interfaz.

El silencio no significaría automáticamente fracaso. Los productos consolidados pueden seguir triunfando mediante facilidad de uso, soporte y rendimiento integrado de modelos.

El resultado más sólido para DeepSeek sería un mercado dividido. Los agentes terminados atenderían a usuarios que quieren una herramienta coherente, mientras que Harness atendería a equipos que construyen agentes especializados a partir de piezas intercambiables.

Esa división refleja una historia más amplia del software. Los frameworks y las aplicaciones terminadas suelen coexistir porque resuelven distintos problemas de propiedad.

Es posible que los trabajadores del conocimiento no operen DeepSeek Harness directamente, pero su arquitectura aún les afecta. Los sistemas de agentes tocan cada vez más archivos de proyectos, investigación interna, mensajes y conocimiento organizacional.

Cuando esos sistemas fallan, los usuarios necesitan saber qué contexto recibió el modelo y qué herramientas actuaron. Un historial de eventos reconstruible puede hacer esa investigación más concreta.

Los equipos que construyen flujos de trabajo de IA relacionados deberían aplicar la misma disciplina a sus fuentes de información. Una base de conocimiento de IA mantenida puede preservar los documentos y las decisiones que rodean la salida de un agente.

Esa práctica no resuelve la seguridad en tiempo de ejecución. Ayuda a las personas a distinguir las conclusiones generadas de la evidencia y el contexto institucional utilizados para alcanzarlas.

El juicio final debería seguir siendo limitado. DeepSeek ha lanzado una propuesta arquitectónica seria con código funcional, documentación detallada y una definición inusualmente amplia de lo que es un plugin.

Aún no ha demostrado que los desarrolladores corrientes puedan gestionar esa flexibilidad de forma segura. No ha demostrado que los componentes de terceros sigan siendo compatibles ni que el diseño produzca mejores resultados en las tareas.

El titular de Google News captura la idea memorable, pero los próximos tres meses deberían juzgarse mediante contratos estables, pruebas operativas independientes y plugins confiables.

Si estás evaluando DeepSeek Harness, comienza con un flujo de trabajo acotado. Registra el modelo, las herramientas, los permisos, el perfil y el resultado esperado. Luego interrumpe la ejecución, deniega una herramienta, sustituye un proveedor e inspecciona si el registro de eventos aún explica el resultado. Ese ejercicio pone a prueba la tesis real de DeepSeek con mayor eficacia que una lista de funcionalidades. La cuestión no es si todo puede ser un plugin. La cuestión es si los equipos pueden sustituir esos plugins sin perder fiabilidad, seguridad ni la capacidad de entender lo que hizo su agente.