Cómo verificar la administración de errores que ha escrito tu agente de programación

El agente de codificación dice que ha agregado reintentos y control de límites de velocidad, y sus pruebas pasan. Antes de confiar en eso, compruebe contra qué sistema se ejecutaron las pruebas.

En una prueba que realizamos con 3 agentes de programación (210 ejecuciones), les pedimos que hicieran que las aplicaciones administraran los fallos de la API y demostraran que funcionaba. En el 76 % de las 140 ejecuciones en las que se solicitaba código funcional, el agente simuló el fallo manualmente mediante stubs de recuperación, httpx.MockTransport, o un servidor HTTP temporal. En las 75 ejecuciones en las que la API real estaba disponible y la indicación no la descartaba, ninguno probó la aplicación en su URL de API real. Superar pruebas como estas demuestra que el código del agente administra el fallo que este había imaginado. Se trata de un error diferente del que envía la API.

Checklist

  1. Pregunta con qué se ha realizado la prueba. Pregunta al agente: "¿A qué URL accedió la aplicación durante tu prueba y qué provocó el error?". Si la respuesta es un stub o un servidor local que él mismo creó, considera las pruebas como pruebas unitarias de las ramas que añadió.
  2. Busca los conmutadores añadidos para las pruebas. Busque en el diff las nuevas variables de entorno, la configuración de la dirección URL base o los indicadores. En nuestra prueba, 61 de las 105 ejecuciones en aplicaciones que acceden a GitHub, OpenAI o una API meteorológica añadieron uno. Decida si lo desea en producción.
  3. Compruebe el código con respecto al comportamiento documentado de la API. Cada API falla a su manera:
    • GitHub: cuando se supera el límite de frecuencia principal, se obtiene 403 o 429 con x-ratelimit-remaining establecido en 0, y se espera hasta el tiempo en x-ratelimit-reset, en segundos de época UTC. En el caso de los límites de tasa secundarios, espere retry-after si está allí; de lo contrario, hasta x-ratelimit-reset si x-ratelimit-remaining es 0; de lo contrario, al menos 1 minuto. El código que solo comprueba el código 429 pasa por alto los 403.
    • OpenAI: algunos 429s se refieren a los límites de facturación y gasto, como credit_balance_exhausted. Volver a intentarlos no ayudará. El código que vuelve a intentarlo cada vez que se produce un 429 te oculta el problema.
    • Anthropic: el límite de gasto 429 no tiene retry-afterencabezado, y las sobrecargas devuelven 529, algo que el código que solo conoce los códigos de estado estándar podría no esperar.
  4. Compruebe cómo se lee Retry-After. El encabezado contiene un número de segundos o una fecha HTTP (RFC 9110). Compruebe que el código gestiona el formato que envía su API, limita el número de intentos y el tiempo total de espera, y no reintenta además sobre un SDK que ya realiza reintentos.
  5. Compruebe lo que ve el usuario cuando se acaben los reintentos. Busque un mensaje claro en lugar de una traza de pila o un indicador de carga que no termina nunca, y compruebe que el usuario no pierda su trabajo.
  6. Ejecute la aplicación en sus direcciones URL reales con fallos simulados. Este es el único paso que muestra cómo se comportan conjuntamente la aplicación en ejecución, su SDK y su directiva de reintento.

Cómo verificar la administración de errores escrita por el agente

Approach Lo que encuentras Lo que se te escapa
Lee el diff Si el código parece correcto Si se comporta correctamente frente a las respuestas reales de la API
Ejecución de las pruebas del agente Que las ramas que ha escrito se ejecuten Todo lo que la simulación no modeló: códigos de estado reales, cabeceras, cuerpos de error y reintentos del SDK
Llama a la API real hasta que falle Comportamiento real No se pueden provocar fallos a voluntad y se consume cuota real.
Ejecuta la aplicación en URL reales con fallos simulados Cómo la aplicación en ejecución, su SDK y su política de reintentos gestionan los errores de la propia API Tu código de forma aislada. Reserve las pruebas unitarias del agente para eso.

Pruébalo en tu app

Dev Proxy intercepta las solicitudes que tu aplicación envía a la API real y devuelve los errores que elijas, sin necesidad de cambiar el código de tu aplicación. Para las API más populares, empiece con una configuración predefinida. Para comprobar la administración del límite de rate de GitHub que ha escrito tu agente:

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"

Ejecuta tu aplicación y observa la salida de Dev Proxy. El preajuste devuelve un 429 con los encabezados de límite de rate de GitHub una vez que tu aplicación supera el límite. El RetryAfterPlugin del preajuste te indica si tu aplicación vuelve a llamar a la API antes de que finalice el tiempo de espera. Los openai-throttling valores preestablecidos y anthropic-throttling hacen lo mismo para los propios errores de límite de velocidad del proveedor y openai-throttling también devuelven un credit_balance_exhausted valor 429 que no se debe reintentar.

Para otras API:

También puedes pedirle a tu agente de programación que escriba la configuración de Dev Proxy. Añade el servidor MCP de Dev Proxy a tu agente para que pueda consultar la documentación y las prácticas recomendadas de Dev Proxy, y comprobar qué versión tienes instalada. Revisa esa configuración como cualquier otro código que escriba el agente.

Para instalar Dev Proxy, consulte Configurar Dev Proxy.

Pasos siguientes

Prueba de mi aplicación con errores aleatorios

Consulte también

  • Se actualizó por última vez el