Trae es un bucle. Su agente Builder lee tu repositorio, edita archivos, ejecuta comandos en el terminal y lee la salida para decidir qué hacer a continuación. Entonces, ¿por qué tus pruebas de API no están en ese bucle? Se encuentran en Apidog detrás de una GUI y se ejecutan cuando alguien recuerda hacer clic. Tu agente nunca las 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 un terminal. Una vez que la CLI está instalada y Trae sabe que existe, el Builder 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.
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 npm, la autenticación y la primera ejecución, con el agente haciendo el tecleo. Este artículo asume que apidog --version imprime un número y que tu cuenta de Apidog está autenticada.
De qué Trae hablamos
Trae es el IDE de IA de ByteDance, construido sobre VS Code, con un modo de agente llamado Builder que edita archivos y ejecuta comandos de terminal por sí solo. Puedes leer los detalles del producto en el sitio oficial de Trae. Este artículo trata sobre el IDE de escritorio, no sobre el proyecto de investigación independiente trae-agent en GitHub. Si abres Trae, ves un panel de chat junto a tu editor y puedes cambiar el agente a Builder, estás en el lugar correcto.
La distinción importa porque Trae tiene su propia forma de aprender las reglas del proyecto, y ese mecanismo convierte un "ejecutar mis pruebas" puntual en algo que el Builder utiliza por sí solo. Ese mecanismo es un archivo de reglas del proyecto. Si primero quieres la versión agnóstica de esta herramienta para este flujo de trabajo, la guía completa de la CLI de Apidog cubre la CLI por sí sola.
Paso 1: Añadir el archivo de reglas del proyecto
Trae lee los archivos de reglas antes de que el Builder comience a trabajar. El archivo a nivel de proyecto reside en .trae/rules/project_rules.md en la raíz de tu repositorio, según la documentación de reglas de Trae. El agente carga estas reglas durante la inicialización y las referencia mientras genera y edita código. También hay un archivo user_rules.md a nivel de usuario que se aplica a todos tus proyectos; para este flujo de trabajo, un archivo de proyecto en la raíz del repositorio es suficiente.
Crea .trae/rules/project_rules.md y añade un bloque corto que nombre la CLI, el comando exacto del escenario y las reglas que mantienen al Builder honesto:
## Pruebas de API con la CLI de Apidog
Cuando cambies código que afecte a un endpoint de API, verifícalo ejecutando el
escenario de prueba de Apidog, no solo las pruebas unitarias.
Comando:
apidog run -t <scenario_id> -e <env_id> -r cli
Reglas:
- `apidog run` sale con 0 cuando todas las aserciones pasan y distinto de cero en cualquier fallo.
Considera un código de salida distinto de cero como una prueba fallida, incluso si el resumen parece correcto.
- Esta máquina ya está autenticada a través de `apidog login`. Nunca añadas un
flag --access-token y nunca coloques un token en este archivo.
- Si un flag es desconocido, ejecuta `apidog run --help` y usa el flag exacto de allí.
Por eso escribes la CLI en project_rules.md en lugar de mencionarla en el chat. Un ID de escenario tecleado en el panel de chat desaparece cuando termina la sesión. Uno en .trae/rules/project_rules.md está allí para cada compañero de equipo y cada ejecución del Builder de ahora en adelante. Trae también lee las carpetas .trae/rules/ en subdirectorios, por lo que un monorepo puede mantener reglas por servicio junto a cada servicio.
Paso 2: Obtener el comando de Apidog
No tienes que adivinar el comando. Abre el escenario de prueba en Apidog, ve a su pestaña CI/CD y copia la línea apidog run generada. Ya tiene el ID de escenario real después de -t y el ID de entorno después de -e, por lo que estás pegando un comando que Apidog sabe que es válido en lugar de inventar IDs manualmente.
Inserta esos IDs exactos en el bloque de .trae/rules/project_rules.md, reemplazando los marcadores de posición <scenario_id> y <env_id>. Para ver el conjunto completo de flags y lo que hace cada uno, consulta la referencia del comando apidog run.
Paso 3: Hacer que el Builder ejecute la prueba
Con el bloque en su lugar, cambia el agente de Trae a Builder e inícialo en tu repositorio. El Builder carga project_rules.md al inicializarse, por lo que ya sabe que la CLI está allí. Haz un cambio que afecte a tu API, o simplemente pídele que ejecute la comprobación:
Ejecuta el escenario de prueba de Apidog y dime el código de salida.
El Builder emite el comando apidog run de tu archivo de reglas. El modelo de aprobación de Trae es importante aquí: cuando el agente quiere ejecutar un comando de shell, recomienda el comando y muestra un botón "Ejecutar", y el comando se ejecuta en el terminal de Trae solo después de que hagas clic. Una vez que se ejecuta, el Builder lee y analiza automáticamente la salida. Así que apruebas el apidog run una vez, y el agente toma el resultado de ahí.
El reportero -r cli imprime un resultado paso a paso y un resumen directamente en el terminal, donde el Builder lee cada solicitud y aserción a medida que suceden. Quieres ver la ejecución y al Builder informando tanto el resumen como el código de salida.
Paso 4: Leer el informe dentro de Trae
Cuando una ejecución falla, el informe tiene la respuesta. Con -r cli, el Builder obtiene un desglose legible en el terminal de Trae: 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 Builder encuentre la solución.
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 <scenario_id> -e <env_id> -r cli,html
El reportero html escribe un archivo autocontenido en ./apidog-reports. Mantén cli en la lista para que el Builder siga obteniendo la salida en línea que lee para decidir su siguiente paso. Para todos los reporteros, incluidos los formatos JSON y JUnit que analizan los paneles de control de CI, consulta la guía de informes de prueba de la CLI de Apidog.
Pruebas de Trae dentro de su propio bucle
El punto es lo que sucede cuando dejas de preguntar y el Builder ejecuta el escenario por sí solo porque project_rules.md se lo indicó.
Imagina al Builder editando un manejador que construye una respuesta de compra. Su bucle cambia: edita el código, luego, en lugar de declarar victoria, ejecuta tu escenario de Apidog contra el entorno de prueba, lee el código de salida y actúa en consecuencia. Si es verde, avanza. Si es rojo, abre el informe, lee qué aserción falló (el código de estado, el campo faltante, el valor incorrecto), intenta una solución y vuelve a ejecutar. La prueba de API se convierte en parte del mismo bucle de edición-prueba-corrección que el Builder ya usa para tus pruebas unitarias. Escribiste una instrucción y el Builder incorporó el comando en cómo ya funciona.
Este es el modelo delegar-y-verificar que hace que cualquier flujo de trabajo de agente sea seguro. El Builder ejecuta el comando y lee el resultado; tú sigues creando escenarios visualmente en Apidog y verificas que el agente lee los códigos de salida honestamente. Para el patrón más amplio, consulta cómo usar agentes de IA para pruebas de API y el arnés de pruebas de IA de Apidog.
Verifica que Trae realmente está ejecutando la CLI
Los agentes reportan éxitos que no obtuvieron, y el Builder no es una excepción. Tres comprobaciones, en orden de la frecuencia con la que detectan problemas.
Primero, confirma que el comando se ejecutó en absoluto. Trae muestra los comandos que el Builder ejecutó y su salida en el terminal. Busca la línea literal apidog run y un resultado debajo. Si el Builder dice que ejecutó las pruebas pero no ves el comando, resumió algo que nunca hizo. Pídele que lo ejecute de nuevo y que muestre la salida en bruto.
Segundo, confirma el código de salida:
¿Cuál fue el código de salida de ese comando apidog run?
apidog run sale con 0 cuando todas las aserciones pasan y distinto de cero cuando algo falla. Ese comportamiento único permite al Builder, o a una tubería, tratar la ejecución como una puerta limpia. Cuando el texto del Builder dice "las pruebas pasaron" pero el código de salida es distinto de cero, el código de salida tiene la razón.
Tercero, confirma que usó el escenario real. Si una ejecución falla con "escenario no encontrado", el Builder puede haber inventado o recordado mal un ID. Vuelve a verificar los valores de -t y -e contra project_rules.md y el comando que Apidog generó en la pestaña CI/CD. Los IDs en tu archivo de reglas son la verdad.
Opcional: Conectar el servidor MCP de Apidog
Ejecutar apidog run desde project_rules.md cubre la mayor parte de lo que necesitas. Conectar un servidor MCP va un paso más allá. Los agentes de Trae actúan como clientes MCP, por lo que el Builder puede llamar a herramientas que un servidor MCP expone.
Para añadir uno, abre la configuración de Trae, ve a la pestaña MCP y elige un servidor del marketplace o selecciona "Añadir manualmente" y pega un bloque JSON con el command, args y env del servidor, según la guía de Trae para añadir servidores MCP. El servidor MCP de Apidog expone tus especificaciones de API a través de MCP, para que el Builder pueda leer tu esquema mientras escribe código, no solo después de los hechos. La división del trabajo es clara: la CLI ejecuta las pruebas, y MCP alimenta al agente con la especificación.
Cuando Trae se equivoca
Algunos fallos aparecen a menudo durante la configuración.
Ignora el archivo de reglas. Si el Builder ejecuta un comando genérico o ninguno, es posible que el archivo no se esté cargando. Confirma que está en .trae/rules/project_rules.md en la raíz de tu repositorio y que la carpeta se llama rules, no rule. Reiniciar la sesión fuerza una nueva lectura de las reglas.
Pasa un token de acceso de todos modos. Si el Builder intenta añadir --access-token, está adivinando a partir de ejemplos públicos. El bloque ya le dice que no lo haga, ya que la máquina está autenticada a través de apidog login. Refuerza la línea y nunca pongas un token real en project_rules.md. Para saber cómo la CLI maneja las credenciales en uso interactivo y en CI, consulta autenticación de la CLI de Apidog.
Inventa un flag. Un error de "opción desconocida" significa que el Builder adivinó un flag que tu versión no tiene. Dile que ejecute apidog run --help y que copie el flag exacto de allí, que siempre es correcto para tu versión instalada.
Informa un aprobado en una ejecución fallida. El más costoso, y la razón por la que la regla del código de salida está en tu project_rules.md y en tu paso de verificación. Cuando el resumen y el código de salida no concuerdan, el código de salida gana.
De un agente diario a un bucle probado
Esa es la configuración. Instala apidog-cli una vez siguiendo la guía de instalación, añade un bloque corto de Apidog a .trae/rules/project_rules.md, y el Builder sabrá cómo ejecutar tus pruebas de API y leer el resultado dentro del mismo bucle que ya usa para editar código. Un endpoint roto se detecta mientras el Builder aún está trabajando en el cambio, no después de que se haya desplegado.
Una prueba detrás de una GUI se ejecuta cuando un humano hace clic; un comando de una sola línea se ejecuta cuando el Builder lo decide. Tú sigues construyendo escenarios visualmente en Apidog, y tu agente los ejecuta donde no estás mirando. Descarga Apidog, construye un escenario, inserta su comando apidog run en .trae/rules/project_rules.md, y observa cómo el Builder lo detecta en el siguiente cambio. Cuando estés listo para ejecutar el mismo escenario sin un agente presente, la CLI de Apidog en GitHub Actions cubre los secretos, los reportadores y la verificación de códigos de salida para CI.