DeepSeek Harness es un bucle. El agente lee tu espacio de trabajo, edita archivos, ejecuta comandos a través de su herramienta bash y decide qué hacer a continuación basándose en la salida. Entonces, ¿por qué tus pruebas de API no están en ese bucle? Permanecen en Apidog detrás de una interfaz gráfica de usuario y se ejecutan cuando alguien se acuerda de hacer clic. El agente nunca los toca.
La solución es un bloque de configuración. La CLI de Apidog es un paquete npm, apidog-cli, que ejecuta los escenarios de prueba que construiste en Apidog directamente desde una terminal. Una vez que la CLI está instalada y DeepSeek Harness sabe que existe, el agente ejecuta un escenario de Apidog de la misma manera que ejecuta tus pruebas unitarias: dispara el comando, lee el código de salida, corrige el código si está en rojo.
También hay un argumento de token para hacer esto. Un agente que confirma que tu API sigue funcionando releyendo el código del manejador y razonando sobre las formas de respuesta consume contexto en cada pasada. Un agente que ejecuta un comando obtiene la verdad fundamental en unas pocas líneas. La CLI comprime "¿es correcta la API?" en un código de salida, y el agente dedica su contexto a la solución en su lugar.
Esta guía cubre la parte específica del harness que la guía de instalación genérica omite: qué archivo de instrucciones lee realmente DeepSeek Harness, cómo su herramienta bash ejecuta apidog run, y cómo mantener el bucle honesto. Si aún no has instalado la CLI, hazlo primero. Cómo instalar la CLI de Apidog con un agente de codificación de IA explica la instalación de npm, la autenticación y la primera ejecución. Este artículo asume que apidog --version imprime un número y que tu máquina está autenticada.
De qué DeepSeek Harness se trata
DeepSeek Harness, dsh en la línea de comandos, es el harness de agente de código abierto que DeepSeek lanzó el 13 de agosto de 2026, junto con V4-Pro en la API. Tiene licencia MIT, se encuentra en github.com/deepseek-ai/deepseek-harness, y había superado las 169k estrellas el 20 de agosto. Lo inicias con npx @deepseek-ai/dsh web, que sirve una interfaz de usuario web local en http://127.0.0.1:3080. Allí eliges un espacio de trabajo, el directorio del proyecto donde lo iniciaste, y el agente trabaja dentro de él: leyendo y editando archivos, ejecutando comandos y preguntando antes de operaciones que requieren aprobación bajo la política de permisos activa.
Dos cosas dan forma a todo lo que sigue. Primero, el harness es una versión preliminar para desarrolladores. El archivo README advierte, en mayúsculas, que habrá cambios que romperán la compatibilidad, así que trata los nombres de archivo y las claves de configuración aquí como precisos para finales de agosto de 2026 y vuelve a verificar con la documentación del repositorio si algo no carga. Segundo, todo en dsh es un plugin, construido sobre la arquitectura Cordis, lo que hace que la pregunta práctica siguiente sea respondible: ¿qué plugin lee las reglas de tu proyecto y qué busca? Para un recorrido más amplio, consulta qué es DeepSeek Harness; para ver cómo se compara con el titular, consulta DeepSeek Harness vs Claude Code.
Paso 1: coloca la CLI en AGENTS.md
DeepSeek Harness lee las instrucciones del espacio de trabajo a través de su plugin @deepseek-ai/dsh-agent-instructions, y los valores predeterminados son amigables si has usado otros agentes. Según el código fuente del plugin y el catálogo de configuración, el cargador asciende desde el directorio de trabajo de la sesión hasta la raíz de tu proyecto (marcado por .git) y carga AGENTS.md, recurriendo a CLAUDE.md, en cada directorio del camino. Las superposiciones locales llamadas AGENTS.local.md o CLAUDE.local.md se cargan después de los archivos base, y un AGENTS.md fijo global para el usuario en $DSH_HOME (por defecto ~/.dsh) se aplica a través de los proyectos. Los archivos de más de 1 MiB se ignoran, algo a lo que tu archivo de reglas nunca se acercará.
## Pruebas de API con la CLI de Apidog
- Para probar la API, ejecuta el escenario de Apidog. No navegues por la interfaz gráfica.
- Comando: apidog run -t <scenario_id> -e <env_id> -r cli
- El código de salida 0 significa que todas las aserciones pasaron. Un valor distinto de cero significa un fallo; lee el informe y corrige el código.
- La máquina ya está autenticada. Nunca añadas un flag --access-token y nunca coloques un token en este archivo.
Por eso el archivo de reglas supera al chat. Un ID de escenario tecleado en el compositor de sesiones desaparece cuando termina la sesión. Uno escrito en AGENTS.md se carga en cada nueva sesión, para cada compañero de equipo, en cada máquina que clona el repositorio. Si trabajas en varios proyectos, el ~/.dsh/AGENTS.md global del usuario lleva el hábito ("siempre verifica los cambios de la API con el comando apidog run del proyecto") mientras que el propio archivo de cada repositorio lleva los ID reales.
Paso 2: obtén el comando de Apidog
No tienes que adivinar los ID del escenario y del entorno. Abre el escenario de prueba en Apidog, ve a su pestaña CI/CD y copia el comando generado. Se ve así:
apidog run -t 123456 -e 789012 -r cli
El flag -t es el ID del escenario de prueba, -e es el ID del entorno, y -r cli selecciona el reportero que imprime los resultados en línea, que es exactamente lo que un agente necesita leer. Pega los IDs reales en tu bloque AGENTS.md para que el agente ejecute el comando generado por Apidog, no una suposición.
Paso 3: haz que el agente ejecute la prueba
Inicia una sesión en la interfaz de usuario web de dsh con tu espacio de trabajo seleccionado. El cargador de instrucciones ya ha introducido tu AGENTS.md en el contexto del agente, por lo que sabe que la CLI existe. Realiza un cambio que afecte a tu API, o simplemente pregunta:
Ejecuta el escenario de prueba de Apidog y dime el código de salida.
El agente lo ejecuta a través de su herramienta bash, y saber cómo se comporta esa herramienta te ahorrará una sesión de depuración más adelante. Según el catálogo de herramientas, la herramienta bash predeterminada ejecuta cada comando en una shell nueva: no persisten el directorio de trabajo, las variables o las funciones entre llamadas, y los comandos se ejecutan desde el espacio de trabajo de la sesión a menos que se pase un workdir. Esto está bien para apidog run, un comando único y autocontenido, pero el agente no puede hacer cd a algún lugar primero y ejecutar la prueba como un segundo paso. Si tu escenario debe ejecutarse desde un subdirectorio, coloca la invocación completa en una sola línea en tu archivo de reglas.
Dos comportamientos más que vale la pena conocer. Las salidas distintas de cero regresan como un marcador explícito [código de salida: N], por lo que la señal de aprobación/falla sobrevive incluso cuando la salida larga se trunca a su cola. Y los comandos pueden ejecutarse bajo un entorno aislado de archivos (file sandbox): una operación bloqueada se informa como una denegación de política, no como un fallo de comando. Una ejecución de prueba de solo lectura rara vez activa esto, pero el reportero HTML que escribe en ./apidog-reports podría hacerlo, dependiendo de la política activa.
Si la ejecución necesita tu clic primero depende de esa misma política de permisos. La interfaz de usuario web pregunta antes de las operaciones que requieren aprobación bajo ella, según la guía de usuario. Cuando te pida apidog run, apruébalo: un escenario de prueba contra un entorno de staging es exactamente el tipo de comando seguro y de solo lectura que el flujo de aprobación permite pasar.
Paso 4: lee el informe
Cuando una ejecución se pone en rojo, el informe tiene la respuesta. Con -r cli, el agente obtiene un desglose legible en línea: cada solicitud, cada aserción y cuál falló con el valor esperado frente al real. La aserción fallida nombra el campo exacto o el código de estado, lo que suele ser suficiente para que el agente localice la solución sin que tú tengas que traducir.
Para un informe que puedas abrir en un navegador o entregar a un compañero de equipo, añade el reportero HTML:
apidog run -t 123456 -e 789012 -r cli,html
El reportero html escribe un archivo autocontenido en ./apidog-reports. Mantén cli en la lista para que el agente siga obteniendo la salida en línea que lee para decidir su siguiente paso.
El bucle, de principio a fin
Esto es lo que te ofrece la configuración. Supongamos que el agente está editando un manejador de pago. Sin la CLI, su bucle termina en "el código parece correcto". Con el bloque en AGENTS.md, el bucle se extiende: edita el manejador, ejecuta apidog run -t 123456 -e 789012 -r cli y lee el resultado. Si es verde, continúa. Si es rojo, ve [código de salida: 1], lee qué aserción falló (un 500 donde se esperaba un 200, un campo total faltante, un código de moneda incorrecto), parchea el manejador y lo vuelve a ejecutar. La verificación del contrato de la API se convierte en parte del mismo ciclo de edición-prueba-corrección que el agente ya utiliza para tus pruebas unitarias.
Fíjate en lo que el agente no hizo: releer cada archivo de ruta para convencerse de que la API funciona. El escenario ya codifica el comportamiento esperado, construido visualmente en Apidog por quien sea el propietario de la API. El agente delega la verificación a una herramienta determinista y gasta sus tokens donde se necesita juicio. Esa división del trabajo es el patrón completo: dsh escribe código, la CLI verifica la capa de la API, y tú creas escenarios en Apidog sin escribir código de prueba en absoluto.
Verifica que dsh realmente lo ejecutó
Los agentes reportan éxitos que no se ganaron, y un harness en vista previa para desarrolladores no es el lugar para tomar la prosa con fe. Tres comprobaciones, en el orden en que detectan problemas.
Primero, confirma que el comando se ejecutó. La interfaz de usuario web de dsh muestra las llamadas a las herramientas del agente y su salida en la sesión. Busca la llamada bash literal apidog run ... y su resultado. Si el agente dice que ejecutó las pruebas pero no aparece tal llamada, resumió algo que nunca hizo. Pídele que lo ejecute de nuevo y muestre la salida sin procesar.
Segundo, confirma el código de salida. Pregunta directamente: "¿cuál fue el código de salida de ese comando apidog run?" El harness entrega al agente un marcador explícito [código de salida: N] en caso de fallo, por lo que no hay ambigüedad detrás de la cual esconderse. Cuando el resumen del agente dice "pruebas superadas" pero el marcador indicó un valor distinto de cero, el marcador tiene razón.
Tercero, confirma que usó el escenario real. Un fallo de "escenario no encontrado" suele significar que el agente inventó o recordó mal un ID. Vuelve a verificar los valores -t y -e con tu bloque AGENTS.md y el comando en la pestaña CI/CD de Apidog. Los IDs en el archivo de reglas son la verdad; cualquier otra cosa que el agente haya escrito es una suposición.
Opcional: añade el servidor Apidog MCP para acceso a especificaciones
La ejecución de escenarios cubre la verificación. Si también quieres que el agente lea la especificación de tu API mientras escribe código, ese es un trabajo para MCP, y aquí la imagen honesta importa: a finales de agosto de 2026, el soporte de MCP no está documentado en el README o la guía de usuario del núcleo de DeepSeek Harness. Lo que existe es un plugin comunitario, hyqhyq3/dsh-mcp-manager, descubierto a través del tema de GitHub dsh-plugin como el resto del ecosistema. Añade una página de MCP en Configuración, soporta servidores HTTP remotos y stdio locales, registra herramientas como mcp__<name>__*, y lee las definiciones de servidor por proyecto de <espacio_de_trabajo>/.dsh/dshmm/mcp.json.
A través de él puedes conectar el servidor Apidog MCP, que expone tus especificaciones de API sobre MCP para que el agente pueda verificar el esquema real de un endpoint antes de escribir el manejador, en lugar de después de que el escenario falle. Un plugin comunitario más un host en vista previa para desarrolladores significa que esta combinación puede romperse con la actualización de cualquiera de las partes, así que trátalo como una capa adicional. La ruta de la CLI mencionada anteriormente es la principal: no necesita nada más que una shell.
Advertencias de la vista previa y hacia dónde va esto
DeepSeek Harness avanza rápido y te advierte que romperá cosas. Los detalles más propensos a cambiar son los aquí mencionados: los candidatos de archivo del plugin de instrucciones, la notificación de sandbox de la herramienta bash y cualquier cosa que toque el plugin comunitario de MCP. El patrón, sin embargo, es portátil. Un archivo de reglas que dice "verifica la API con este comando" más una CLI que devuelve un código de salida limpio funciona en dsh hoy por la misma razón que funciona en Claude Code y en cualquier otro harness de esta serie: los agentes son buenos leyendo la salida de los comandos y malos siendo confiados sin ella.
Así que: descarga Apidog, crea un escenario de prueba visualmente, copia su comando apidog run de la pestaña CI/CD y pega el bloque en el AGENTS.md que tu repositorio probablemente ya tenga. La próxima vez que DeepSeek Harness toque tu código API, comprobará su propio trabajo antes de decirte que ha terminado.
Preguntas Frecuentes
¿DeepSeek Harness lee AGENTS.md de forma nativa? Sí. El plugin @deepseek-ai/dsh-agent-instructions carga AGENTS.md (o CLAUDE.md como alternativa) desde la raíz de tu proyecto y los directorios superiores al directorio de trabajo de tu sesión, además de superposiciones AGENTS.local.md/CLAUDE.local.md y un AGENTS.md global de usuario en ~/.dsh. Si ya tienes un AGENTS.md para otros agentes, dsh lo toma sin cambios.
¿Necesito un plan de pago de DeepSeek para usar la CLI de Apidog en dsh? No. El harness es de código abierto con licencia MIT, y tú traes tu propio modelo: los proveedores de catálogo cubren Anthropic, OpenAI, Bedrock, Vertex y Azure, y las pasarelas personalizadas funcionan a través de settings.yaml, como se explica en cómo ejecutar cualquier modelo en DeepSeek Harness. La CLI de Apidog en sí es un paquete npm gratuito; necesita un escenario de prueba de Apidog y autenticación, no un modelo específico.
¿Por qué el segundo comando del agente olvida el directorio al que cambió el primero? Por diseño. La herramienta bash predeterminada de dsh ejecuta cada llamada en una shell nueva, por lo que cd no persiste entre comandos. Pasa el parámetro workdir de la herramienta o, más simple, mantén la invocación completa de apidog run en una sola línea en tu archivo de reglas para que no haya nada que olvidar.
¿Puede dsh ejecutar el escenario sin preguntarme cada vez? Eso depende de la política de permisos activa. La interfaz de usuario web pregunta antes de las operaciones que requieren aprobación bajo ella; la guía de usuario no enumera los niveles de política, así que verifica la Configuración en tu compilación para ver lo que permite tu implementación. Cuando solicite la aprobación, aprobar un apidog run contra staging es un sí seguro.