En la madrugada de hoy, se lanzó la versión oficial de DeepSeek V4 Pro, desatando un gran entusiasmo. Ahora, a medio día de distancia, ¡también ha llegado DeepSeek Harness (versión de vista previa para desarrolladores)!
Por supuesto, esto no es una sorpresa, ya que el proyecto había estado preparándose durante mucho tiempo. Por ejemplo, Cui Tianyi, del equipo de DeepSeek Harness, había estado publicando publicaciones de calentamiento en redes sociales y reclutando talentos para el equipo.
A principios de agosto, también obtuvimos acceso beta a DeepSeek Harness, disfrutando por adelantado de este marco de agentes inteligentes que sin duda traerá nuevas transformaciones a la comunidad de IA.
Dirección del código abierto: https://github.com/deepseek-ai/deepseek-harness
Por ejemplo, aquí, con DeepSeek Harness configurado con el modelo oficial DeepSeek-V4-Flash, construimos un juego de disparos en primera persona contra zombis. Sin intervenir en ningún momento, obtuvimos un producto final no perfecto pero bastante jugable en poco más de 30 minutos.
Considerando que recientemente el enfoque de Andrej Karpathy de generar mundos 3D con IA ha sido muy popular, también desafiámos a DeepSeek Harness (V4-Flash) con el "benchmark de Hua Qiang comprando sandías": recrear el fragmento clásico "Hua Qiang compra sandías" en una animación 3D basada en una descripción de texto (también resultado de una instrucción única o "one-shot"):
En general, aunque todavía está lejos de ser perfecto, la trama de esta animación está bastante recreada y las relaciones entre personajes son en gran medida reconocibles. En comparación, la animación que hicimos usando la misma indicación pero con Codex configurado con GPT-5.6 sol-xhigh fue mucho peor:
Hay que tener en cuenta que la escala de parámetros de DeepSeek-V4-Flash es mucho menor que la de GPT-5.6 sol. Se puede imaginar que DeepSeek Harness debe haber tenido un gran mérito en esto.
Hoy, con el lanzamiento de la versión oficial de DeepSeek V4 Pro, también hemos conectado este modelo a DeepSeek Harness y lo hemos ejecutado nuevamente:
El efecto es efectivamente un poco mejor.
A continuación, observemos la estructura del proyecto, que es muy sorprendente: el repositorio ya contiene más de 230 miembros del espacio de trabajo, con código distribuido en áreas como packages/, apps/, examples/, python/, native/, vendor/, website/, etc. Sistema de archivos, terminal, subprocesos, PTY, servidor de lenguaje, acceso web, habilidades, subagentes, flujos de trabajo, modo de planificación, persistencia de sesión, configuraciones, credenciales, telemetría... casi cada capacidad tiene su propio paquete.
Si comparamos un proyecto de agente ordinario con una computadora ya ensamblada, entonces DeepSeek Harness se parece más a una placa de prototipos (breadboard) de tamaño enorme: el modelo, las herramientas, la interfaz, el almacenamiento, las políticas de seguridad y la gestión del contexto se pueden conectar y también se pueden desconectar.
Ofrece un esquema de ensamblaje predeterminado, pero está claro que lo que DeepSeek realmente quiere crear no es un "asistente de programación DeepSeek" de forma fija, sino una forma de ensamblar agentes inteligentes.
¿Qué es DeepSeek Harness?
Aclaremos primero una confusión común: DeepSeek Harness no es un nuevo modelo DeepSeek, ni un simple cliente API. Es un conjunto de SDK y marco de aplicación para construir, ejecutar y ampliar agentes inteligentes. Por defecto, puede conectarse a modelos DeepSeek (también se puede personalizar fácilmente para conectarse a otros modelos), permitiendo que el modelo lea proyectos, modifique archivos, ejecute comandos, gestione tareas, asigne subtareas e interactúe con el usuario a través de Web UI, terminales de pantalla completa, comandos Headless o protocolos de automatización.
El lado web de DeepSeek Harness proporciona una entrada conveniente para configurar directamente otros servicios de modelo, sin necesidad de que el usuario edite manualmente los archivos de configuración.
La comunidad de IA ya no es ajena al término "Harness". Su significado original es arnés, correa, dispositivo de sujeción, etc. Abstraído, su función es conectar la potencia a un mecanismo que pueda trabajar, evitando al mismo tiempo que esa fuerza se desboque. En el contexto de la IA, Harness se encarga de conectar el modelo al sistema de archivos, Shell, editor de código, páginas web y otros agentes, mientras registra lo que hizo, limita lo que puede hacer y decide, en caso de error, si reintentar, cancelar, comprimir el contexto o devolver el problema al usuario.
Esto quizás también explique por qué el volumen de código y el número de paquetes de este proyecto es tan grande. Después de todo, las tareas y opciones de herramientas involucradas son muy numerosas, incluyendo si las llamadas a herramientas pueden ser paralelas, si los comandos de cancelación pueden realmente detener subprocesos, si los resultados de las herramientas contaminan el contexto, dónde deberían insertarse los nuevos mensajes que envía el usuario mientras el modelo se está ejecutando, cómo reconstruir la entrada del modelo original al reanudar una sesión, qué herramientas posee un subagente, si la escritura de archivos sobrepasa el área de trabajo, y si el contenido visto durante la reproducción en la interfaz puede ser consistente con la ejecución en tiempo real.
DeepSeek Harness intenta convertir todos estos problemas en capacidades formales del sistema.
Todo es un plugin
La propuesta de diseño más llamativa de DeepSeek Harness es "Todo es un plugin", incluso el propio "Agent Loop" (bucle del agente) también se considera un plugin.
El proyecto está construido sobre el microkernel Cordis. Un Harness en ejecución es esencialmente un "Cordis Context". Diferentes paquetes registran servicios, eventos y capacidades en el Context, que finalmente son combinados por archivos de configuración para formar un agente inteligente ejecutable.
packages/core/ es el núcleo de todo el sistema, que contiene Session, System Prompt, Tools, Agent y Agent Loop. Resuelven los problemas más básicos: qué es una sesión, cómo se ensamblan las indicaciones del sistema, cómo se registran y llaman las herramientas, cómo se crea un agente, y cómo una ronda de conversación pasa de la entrada del usuario a la solicitud del modelo, ejecución de herramientas y respuesta final.
Fuera del núcleo hay una gran cantidad de paquetes de capacidades:
- packages/llm/ se encarga de los adaptadores de modelo y la salida en flujo (streaming);
- packages/shell/, packages/subprocess/ y packages/terminal/ se encargan de comandos únicos, árboles de procesos y terminales persistentes;
- packages/fs/ se encarga de lectura/escritura de archivos, edición, búsqueda y restricciones de políticas;
- packages/lsp/ conecta con servidores de lenguaje, permitiendo al Agente no solo buscar por texto, sino también obtener navegación de código a nivel semántico;
- packages/web/ se encarga de la búsqueda y el raspado web (web scraping);
- packages/skill/ gestiona habilidades reutilizables;
- packages/subagent/ y packages/workflow/ expanden un solo agente a un sistema multiagente que puede delegar y orquestar.
Mirando más allá, la planificación, objetivos, tareas pendientes, tareas en segundo plano, compresión de contexto, consulta de sesiones, títulos de sesión, credenciales, configuraciones de usuario, mecanismos de aprobación y telemetría también están divididos en capacidades independientes. Lo más interesante de esta estructura es que refleja una conciencia de límites casi obsesiva: quién posee la interfaz, quién se encarga de la implementación, quién presenta la capacidad al modelo, todo debe mantenerse separado.
La documentación del proyecto divide las capacidades típicas en tres capas: interfaz, implementación y consumidor.
Tomando Bash como ejemplo, la interfaz define qué es "ejecutar un comando", la implementación local se encarga de realmente crear el proceso, y el paquete de herramientas orientado al modelo se encarga de convertir esta capacidad en un esquema y resultados que el modelo pueda entender. En el futuro, si el Shell local se va a reemplazar por un contenedor remoto, un entorno de pruebas (sandbox) en la nube o una plataforma de ejecución empresarial, en teoría solo se necesitaría reemplazar la capa de implementación, sin tener que reescribir las herramientas del modelo y el Agent Loop.
Esta es una forma de pensar típica de un marco de trabajo (framework). Hace que el repositorio parezca enorme en las primeras etapas, pero también indica que el objetivo de DeepSeek Harness no es hacer un producto terminado que solo el equipo oficial pueda mantener, sino permitir que diferentes implementadores cambien el modelo, el almacenamiento, las políticas de seguridad, agreguen herramientas, o incluso reemplacen el ciclo del agente inteligente.
Aquí también vemos el verdadero · código abierto que DeepSeek siempre ha defendido.
cordis.yml
Un archivo de configuración ensambla diferentes Agentes
La arquitectura de plugins finalmente llega a manos del desarrollador a través de cordis.yml. El archivo de configuración enumera los nombres de los plugins, ID estables y parámetros, determinando exactamente qué conjunto de capacidades posee el agente actual.
El mismo código puede ser ensamblado en formas de producto completamente diferentes. Agregando el adaptador LLM de DeepSeek, sistema de archivos, Bash y TUI, se obtiene un agente de programación en la terminal; cambiando la interfaz de interacción por un plugin web, se obtiene una aplicación de navegador; usando una entrada Headless, aceptará una tarea, completará las rondas de modelo y herramientas, imprimirá la respuesta y saldrá; cambiándolo por una puerta de enlace ACP o JSON-RPC, puede convertirse en un servicio de automatización que otros programas puedan controlar.
La configuración también admite capas de superposición (overlay). TUI y Web UI pueden compartir una configuración base y luego superponer sus propios plugins de interfaz y parámetros; la configuración personal se encuentra en la última capa. De esta manera, el implementador no necesita copiar todo el árbol de configuración, solo necesita reemplazar plugins específicos. Sin embargo, hay un detalle a tener en cuenta aquí: el parche de configuración reemplaza toda la config del plugin objetivo, no se fusiona en profundidad. Si solo se escribe un nuevo campo, la clave API, la dirección base u otros parámetros existentes podrían desaparecer. Es explícito, pero no necesariamente intuitivo para un usuario primerizo.
El proyecto también permite leer variables de entorno y expresiones de tiempo de ejecución en YAML a través de !!js, por ejemplo, obtener la clave secreta desde DEEPSEEK_API_KEY. La configuración solo hace referencia al nombre de la credencial, la clave secreta se resuelve en el momento de la llamada real. Web UI escribirá la clave en $DSH_HOME/.credentials.yaml, mientras que las variables de entorno y .env pueden ser fuentes de respaldo (fallback) para automatización o desarrollo local; las claves secretas no deben escribirse directamente en cordis.yml o registrarse en los logs de sesión.
Agent Loop
No es un ciclo, es un conjunto de reglas de tráfico
El código central de muchos proyectos de agentes tempranos puede simplificarse en unas pocas líneas: enviar el mensaje al modelo, si el modelo devuelve una llamada a herramienta, ejecutar la herramienta, luego devolver el resultado al modelo, hasta que el modelo genere texto. DeepSeek Harness también hace esto, por supuesto, pero descompone este proceso en un ciclo de vida estricto.
Una entrada de usuario inicia un "Turn" (turno), un Turn puede contener múltiples "Step" (pasos); un Step corresponde a una solicitud de modelo y su posterior ejecución de herramienta. Antes de la solicitud, el sistema ensambla indicaciones de sistema estables, el entorno de ejecución actual, esquemas de herramientas y mensajes de la sesión; después de la solicitud, los fragmentos (chunks) en flujo del modelo, el mensaje completo, llamadas a herramientas, resultados de herramientas y razones de finalización ingresan al flujo de eventos.
El juego de disparos contra zombis mencionado anteriormente ejecutó 3 turnos, 127 pasos.
Las herramientas tampoco son simplemente "llamar cuando se obtiene el nombre de la función". Pasan por políticas previas, guardias de seguridad irreversibles, ejecución real, procesamiento posterior, organización de contenido y notificación de resultados. Permiso o denegación, tiempo de espera, reintento, estadísticas de métricas, contexto adicional, todo se puede integrar desde diferentes posiciones en la línea de ensamblaje. Una herramienta puede declarar que las llamadas bajo cierto tipo de parámetros son concurrentemente seguras, y el planificador permitirá que las tareas de solo lectura consecutivas se ejecuten en paralelo; una vez que se encuentra una llamada que modifica el estado o cuya seguridad no se puede determinar, se trata como una barrera, esperando a que las tareas anteriores terminen antes de ejecutarla en exclusiva.
Este diseño puede parecer como instalar un sistema de control de tráfico aéreo en un camino rural, pero cuando el agente comienza a buscar diez archivos simultáneamente, ejecutar pruebas, aceptar instrucciones adicionales del usuario y, además, permitir cancelaciones en cualquier momento, estas reglas pasan rápidamente de ser un "diseño excesivo" a ser "lo que más se desea tener en un informe de investigación de accidentes".
También maneja seriamente el destino de los mensajes durante la ejecución. El nuevo contenido que el usuario envía mientras el agente está trabajando puede ser la siguiente tarea o una instrucción de cambio de dirección para el trabajo actual. El sistema distingue entre mensajes en cola, inyección de contexto y "Steering", y confirma mediante acuse de recibo si una instrucción de dirección realmente ingresó a una solicitud de modelo específica. En otras palabras, no solo le importa "si el mensaje fue recibido", sino también "en qué paso exacto el modelo lo vio".
Session Log
La verdadera fuente de autoridad de todo el sistema
Otro diseño notable de DeepSeek Harness es el Session Log (Registro de Sesión).
El proyecto estipula que cualquier contenido visto por el modelo debe poder reconstruirse a partir del registro. Los mensajes del usuario, el contexto del entorno de ejecución, información de solicitud del modelo, salida en flujo, llamadas y resultados de herramientas, eventos de compresión, cambios de permisos, razones de cancelación, todo ingresa al flujo de sesión de tipo append (agregado) como eventos. La interfaz, persistencia, recuperación, Fork, telemetría y reproducción no deberían mantener cada uno un estado "aproximadamente correcto", sino derivarse de la misma fuente de eventos.
Este principio resuelve un problema muy difícil en los sistemas de agentes: cuando una tarea falla, ¿podemos realmente saber qué vio el modelo en ese momento?
Si el sistema solo guarda el texto final del chat, se pierden muchos factores clave. Quizás el modelo acababa de inyectar el estado del área de trabajo antes de la solicitud, quizás el resultado de la herramienta fue recortado, quizás el sistema cambió automáticamente el enrutamiento del modelo, quizás el usuario cambió de dirección a mitad de la salida en flujo. DeepSeek Harness guardará en los límites de la solicitud registros suficientes para reconstruir el mensaje, y los fragmentos (chunks) originales del flujo también se conservan, para que la interfaz y la reproducción mantengan la coherencia.
La persistencia de sesión en sí misma sigue siendo un plugin. El proyecto proporciona backends como JSONL y SQLite, la capacidad de consulta puede acceder primero a la sesión en vivo, o buscar en registros históricos a través de la búsqueda de texto completo de SQLite. Resume continúa el trabajo usando la sesión original, mientras que Fork deriva una nueva sesión desde un límite histórico determinado. Para los desarrolladores, esto proporciona una base unificada para depuración, evaluación, auditoría y automatización.
De un Agente a un grupo de Agentes
DeepSeek Harness ya incluye capacidades integradas para múltiples subagentes y flujos de trabajo.
El agente principal puede delegar tareas a subagentes. Un subagente puede ser una instancia completamente nueva, o un Fork desde el límite de finalización de una sesión existente, o conectarse a través de ACP a subprocesos externos.
El juego de disparos contra zombis mencionado anteriormente creó 5 subagentes ejecutados en paralelo.
El diseño del ámbito (scope) aquí es importante. Cada agente tiene su propia capa de contexto, viendo herramientas, indicaciones y comandos específicos. Se puede limitar a un subagente a solo realizar búsquedas y análisis, mientras que a otro se le permite modificar archivos. Las capacidades registradas en el ámbito del agente se limpian automáticamente con el ciclo de vida del agente, sin depender de convenciones de nombres globales para mantener el aislamiento.
Los flujos de trabajo (workflow) van un paso más allá: permiten orquestar múltiples agentes inteligentes con scripts, conectando múltiples subtareas, salidas estructuradas y continuaciones de ejecución. El proyecto también proporciona objetivos, planificación, tareas pendientes y tareas en segundo plano; no son simplemente cuatro widgets de UI con nombres similares, sino que en realidad son estados de colaboración con diferentes ciclos de vida. El modo de planificación registra la fase de colaboración actual, los objetivos pueden existir de forma continua a través de la misma sesión, las tareas pendientes proporcionan al modelo una lista de tareas ligera, y las tareas en segundo plano gestionan el trabajo real que aún se está ejecutando.
Esto indica que Harness quiere cubrir no solo la "programación de pregunta-respuesta". Espera soportar tareas largas, investigaciones en paralelo, ejecuciones automatizadas y coordinación con sistemas externos. En cuanto a si el modelo puede manejar de manera estable tantos mecanismos, esa es otra prueba; al menos el marco primero ha creado el volante, el tablero de instrumentos y los frenos.
Web, TUI, Headless y SDK
Para usuarios comunes, el proyecto recomienda Web UI, que por defecto escucha en http://127.0.0.1:3080. Proporciona conversación, barra lateral de sesiones, selección de permisos, modo de planificación, tarjetas de herramientas e interacción con el área de trabajo.
Web UI también proporciona cuatro modos predefinidos de agente. No son cuatro agentes independientes entre sí, ni solo cambian el estilo de las indicaciones, sino que, basados en el mismo host de Harness, ensamblan diferentes herramientas, indicaciones y capacidades de tiempo de ejecución para la sesión actual:
Modo Estándar: El agente de codificación general más completo funcionalmente, proporciona edición de archivos, Shell, búsqueda de archivos y web, Skills, planificación, objetivos, subagentes y flujos de trabajo, adecuado para la mayoría de las tareas de desarrollo diarias.
Modo PTC: Conserva todas las capacidades del modo estándar, y al mismo tiempo presenta las herramientas al modelo a través del SDK de Code Mode. El modelo puede escribir un programa TypeScript y combinar múltiples pasos en un solo "run_code", reduciendo la sobrecarga de ida y vuelta entre el modelo y las herramientas, más adecuado para tareas complejas con cadenas de llamadas largas.
Modo Mínimo: Solo proporciona dos herramientas: Bash persistente y str_replace_editor. Un conjunto de herramientas más pequeño reduce la carga de selección y contexto, adecuado para tareas de codificación con un camino claro, donde se espera que el agente actúe directamente.
Modo Creativo: Agrega al modo estándar inspección del tiempo de ejecución Cordis, experimentación con plugins temporales y guía para la creación de presets de agente. El agente no solo puede usar herramientas existentes, sino también explorar y recombinar su propio tiempo de ejecución, creando así nuevos presets personalizados. Debido a que puede ejecutar código de plugin escrito por el modelo, este es un modo de alta confianza para usuarios avanzados.
Este conjunto de presets es quizás la expresión más intuitiva del producto de "Todo es un plugin": el enrutamiento del modelo subyacente, persistencia de sesión, sandbox y aprobación siguen siendo proporcionados por el host compartido; el preset solo decide qué capacidades específicas se cargan en un contexto de agente. Por lo tanto, el mismo Web UI puede cambiar de un agente mínimo de dos herramientas al modo estándar capaz de orquestar subagentes, o incluso convertirse en el modo creativo que puede modificarse a sí mismo.
Por ejemplo, aquí, en el modo creativo, hicimos que DeepSeek Harness, conectado a DeepSeek V4 Pro, creara un "modo de tres columnas" que el Web UI oficial no tiene:
Además de Web UI, TUI está dirigido a desarrolladores que prefieren permanecer en la terminal.
El modo Headless es adecuado para scripts y CI: acepta una tarea, espera a que el agente se detenga por completo, luego imprime la última respuesta válida y sale. Si el programa necesita eventos estructurados y control continuo, debe usar ACP o JSON-RPC/SDK de Python.
En cuanto a automatización, el proyecto proporciona servicios ACP y entrada JSON-RPC. El SDK de Python impulsa el entorno de ejecución JSON-RPC incluido, permitiendo que las aplicaciones Python puedan iniciar sesiones, enviar tareas, recibir notificaciones, sin necesidad de incrustar directamente el kernel Node. El repositorio también incluye ejemplos como Code Mode, Cordis autoreferencial (self-referential), servicio de memoria MCP, etc.
Vale la pena señalar que estas entradas no son cuatro agentes que evolucionan por separado. Comparten el modelo central de capacidades, semántica de eventos de sesión y la mayoría de los plugins base, pero no son simplemente reemplazar una capa de UI, sino ensamblar formas de producto como Web, tareas únicas y servicios de automatización a través de diferentes paquetes (bundles). Este es precisamente el resultado más intuitivo de "Todo es un plugin".
El Agente puede inspeccionar e incluso modificar su propio comportamiento
DeepSeek Harness también proporciona un conjunto de herramientas de Cordis autoreferencial (self-referential). No ingresan a los modos Estándar, PTC o Mínimo, sino que se proporcionan a través del "Modo Creativo" en Web UI como una entrada explícita para usuarios avanzados. Al seleccionar este preset, el agente puede inspeccionar el árbol de plugins del tiempo de ejecución actual y montar o desmontar dinámicamente plugins temporales.
Esto suena un poco como hacer que un automóvil se cambie su propio motor en la autopista, por lo que el proyecto no lo activa por defecto. Es adecuado para investigación o escenarios avanzados de automatización: el modelo puede escribir temporalmente un listener de eventos, registrar una nueva herramienta, proporcionar un servicio y luego desmontarlo después de completar la tarea.
Los agentes de automodificación fácilmente pueden convertirse en demostraciones conceptuales, pero Harness al menos lo coloca dentro del ciclo de vida de plugins existente. Los plugins dinámicos aún se ejecutan bajo el mecanismo de Context y Effect de Cordis, y los elementos registrados tienen una ruta de limpieza clara.
Todavía está lejos de ser seguro y sin preocupaciones, pero muestra hacia dónde realmente quiere llegar esta arquitectura: el agente inteligente no solo usa capacidades, sino que también puede recombinar su propio tiempo de ejecución dentro de límites controlados.
Para el diseño detrás de Cordis, puede consultar el documento oficial publicado simultáneamente: "A Programming Paradigm for Spatiotemporal Composability":
Dirección del documento: https://github.com/cordiverse/paper
Políticas de seguridad
Una vez que un agente de programación obtiene permisos de sistema de archivos y Shell, puede modificar código, instalar dependencias, iniciar procesos, e incluso tocar el entorno del host fuera del área de trabajo. DeepSeek Harness claramente trata esto como un problema de infraestructura básica, no simplemente agregando un cuadro de diálogo de confirmación en la interfaz.
El proyecto adopta por defecto el modo "workspace-write", limitando la ejecución de comandos y la modificación de archivos al área de trabajo actual y directorios temporales permitidos, y combinándolo con una política de aprobación "ask" para manejar operaciones que necesitan ampliar permisos. También existe el modo más permisivo "danger-full-access", pero debe ser elegido explícitamente por el implementador; no está empaquetado como una opción de compatibilidad aparentemente inofensiva.
Las llamadas a herramientas también pasan por políticas previas, guardias de seguridad monótonas, envoltorios de ejecución y procesamiento posterior. Las operaciones rechazadas por un guardia no pueden ser aprobadas nuevamente por plugins posteriores; los comandos que requieren ampliar permisos deben explicar la razón y reintentar a través del mecanismo de aprobación. El sistema de archivos, Bash y los subprocesos comparten la misma política de sandbox, evitando límites fragmentados como "los comandos están restringidos, pero las herramientas de archivos pueden eludirlo".
Lo que es aún más digno de elogio es que DeepSeek Harness adopta el principio de "fallo cerrado" (fail-closed). Si el sistema no puede confirmar que el mecanismo de aislamiento está realmente activo, rechazará la ejecución en lugar de degradarse silenciosamente a una ejecución sin protección. Los cambios de permisos, solicitudes de aprobación, parámetros de herramientas, resultados de ejecución y razones de cancelación también ingresan al Session Log, proporcionando una base para auditorías posteriores y reproducción de problemas.
Este diseño no puede eliminar todos los riesgos de que un agente ejecute operaciones locales, pero refleja una actitud de ingeniería rara: La seguridad es una restricción sistémica que atraviesa la configuración, ejecución, aprobación, registro y mecanismos de recuperación. El modelo puede proponer acciones, pero quien realmente decide si la acción puede ocurrir sigue siendo Harness.
Lo que DeepSeek quiere hacer no es solo "otro Codex"
Si solo miramos Web UI o TUI, es fácil interpretar DeepSeek Harness como una versión de Codex, Claude Code u otros asistentes de programación de DeepSeek. Pero desde la estructura del repositorio, su objetivo es claramente más fundamental.
La aplicación predeterminada es importante, por supuesto, permite a los desarrolladores obtener directamente una herramienta que puede leer/escribir proyectos, ejecutar comandos, planificar tareas e invocar subagentes. Pero lo que realmente ocupa el centro del proyecto son las interfaces de capacidad reemplazables, el ciclo de vida impulsado por eventos, el registro de sesión autoritativo y la composición declarativa. En otras palabras, el agente terminado se parece más al primer cliente de este SDK.
Esto también completa una pieza del ecosistema de modelos de DeepSeek que antes no era tan visible. El modelo determina el límite superior de la inteligencia, Harness determina cómo esta inteligencia ingresa al entorno real, cómo usa herramientas, cómo retiene el estado y cómo funciona dentro de los límites de permisos. Para los desarrolladores empresariales, esto último a menudo es más importante que unos pocos botones más en la ventana de chat, porque determina si el sistema puede ser auditado, extendido, reemplazado y mantenido a largo plazo.
DeepSeek Harness todavía está lejos de la etapa "instalado, todo funciona sin problemas", pero ya muestra un juicio técnico bastante completo: un agente no debería ser un ciclo cada vez más inflado, sino un conjunto de capacidades que se pueden combinar, observar y reemplazar; una sesión no debería ser solo un registro de chat, sino los hechos de la ejecución; una herramienta no debería ser solo una función, sino tener simultáneamente políticas, registros y protocolos de presentación.
Por lo tanto, lo más destacable de DeepSeek Harness no es si hoy puede reemplazar el asistente de programación que estás usando, sino hasta qué punto ha hecho público la respuesta de DeepSeek a la ingeniería de agentes.
Este artículo proviene de la cuenta de WeChat "机器之心" (ID: almosthuman2014), autor: 关注DSH的机器之心
