Cómo Probar Agentes de IA que Usan tus APIs Sin Perder Datos

Un agente de codificación de IA ejecutó un script, lo vio tener éxito, y luego vio desaparecer una tabla de la base de datos de producción. El post-mortem en Hacker News se volvió viral con un título contundente: "La IA no eliminó tu base de datos, tú lo hiciste". El mensaje caló porque es cierto. El agente siguió una definición de herramienta, la herramienta accedió a un punto final real, el punto final no tenía salvaguardas, y un humano había entregado las llaves a un proceso que no se detiene a preguntar si DELETE FROM users parece sospechoso. Un hilo separado en r/ClaudeAI contó una historia similar desde un ángulo diferente: un agente en un bucle de facturación consumió cientos de dólares en tokens antes de que alguien se diera cuenta. Superficie diferente, misma clase de fallo. El problema no es que el modelo sea tonto. El problema es que nadie probó la API.

TL;DR

Los agentes fallan en producción cuando sus herramientas no tienen salvaguardas del lado de la API: límites de velocidad ausentes, falta de idempotencia, eliminaciones en caliente, esquemas rotos. Esto se soluciona con cuatro movimientos: probar el contrato de las definiciones de herramientas del agente contra tu especificación OpenAPI, ejecutar un servidor de simulacro para puntos finales destructivos, aplicar presupuestos por agente y claves de idempotencia, y reproducir escenarios de fallo en CI. Apidog te proporciona la importación de OpenAPI, las simulaciones y el ejecutor de escenarios para hacer todo esto desde un solo proyecto.

Introducción

Hace un año, "probar el agente de IA" significaba pedir a Claude o GPT y calificar la respuesta. Ese ya no es el estándar. Los agentes de hoy llaman a funciones, esas funciones acceden a tus APIs, y tus APIs se comunican con bases de datos reales, procesadores de pagos y servicios de terceros. Una mala definición de herramienta o un límite de velocidad ausente no es un problema de estilo. Es un incidente de producción con tu nombre.

La historia viral de Hacker News este mes capturó el cambio. El autor argumentó que la IA no eliminó la base de datos; el humano lo hizo, al darle al agente acceso de escritura sin poner ningún control entre el modelo y los datos. El hilo estalló porque cada desarrollador que lo leía había pensado: "Casi envío eso". Unas semanas antes, una publicación de Reddit describía un bucle de facturación donde un agente reintentó una llamada fallida tantas veces que la factura superó los 800 euros antes de que alguien lo notara. Misma causa raíz: la confianza depositada en la capa equivocada.

Puedes solucionar esto. La capa del modelo importa, pero la capa de la API es donde detienes la hemorragia. Este artículo te muestra cómo probar las integraciones de API de los agentes de IA de extremo a extremo. Cubriremos las cuatro salvaguardas que necesita cada configuración agente-API, repasaremos un flujo de trabajo paso a paso de Apidog para simular puntos finales destructivos y finalizaremos con técnicas avanzadas como la detección de deriva de esquema y la separación de claves duales. Te irás con patrones concretos que puedes copiar en tu repositorio hoy mismo. Descarga Apidog antes de empezar para que puedas seguir los pasos del servidor de simulacro.

Por qué los fallos de los agentes parecen fallos de la API

Lee suficientes post-mortem de agentes y aparecerá un patrón: el modelo no es el protagonista. La API lo es.

Toma la inyección de prompt. Un usuario sube un PDF con instrucciones ocultas, el agente lo lee, y la siguiente llamada de herramienta va a tu punto final /admin/users con delete_all=true. El modelo no eligió esto; siguió instrucciones en las que no tenía motivos para desconfiar. La solución no es endurecer el prompt. La solución es construir una API que no exponga delete_all=true a un token que provino de una sesión de contexto de usuario. OWASP llama a esto LLM01 en su Top 10 de LLM, y la mitigación es la autorización del lado de la API, no la ingeniería de prompts.

Toma esquemas de herramientas defectuosos. Tu especificación OpenAPI dice que amount es un entero en céntimos. La definición de herramienta del agente dice que amount es un flotante en dólares. Tres meses después, alguien reembolsa un cargo de 19 céntimos como 19 dólares y te enteras de la discrepancia por contabilidad. El modelo no estaba equivocado; el modelo usó el esquema que le diste. El esquema se desvió de la API. Nadie probó el contrato.

Toma la ausencia de límites de velocidad. Un agente en un bucle de reintento golpea tu punto final de correo electrónico transaccional mil veces en dos minutos porque el planificador del agente seguía marcando el paso como "aún no exitoso". Cada reintento cuesta dinero. Cada reintento pone en cola un correo electrónico real. Para cuando te despiertas, tu proveedor ha marcado tu cuenta y tus clientes están siendo bombardeados con spam. El modelo no era malicioso. El modelo estaba trabajando desde una herramienta que no tenía límite.

Toma la falta de idempotencia. El agente llama a POST /payments para cobrar a un cliente, obtiene un tiempo de espera de red, reintenta porque el planificador cree que la llamada falló, y ahora el cliente es cobrado dos veces. La capa del agente no puede saber si la llamada original tuvo éxito; la API no le dio una forma de preguntar. Las claves de idempotencia resuelven esto en cinco líneas de código de servidor, pero tienes que escribirlas.

El hilo común: en cada uno de estos incidentes, el agente está haciendo exactamente lo que sus herramientas le dicen que haga. Las herramientas son la API. Así que cuando audites dónde falla la fiabilidad del agente, mira primero el contrato de la API, luego el arnés del agente, y casi nunca el modelo en sí. Este reenfoque es importante porque te dice dónde invertir. No necesitas un modelo más inteligente. Necesitas APIs probables con las salvaguardas activadas.

Las cuatro salvaguardas que toda integración agente-API necesita

Cuatro controles separan las configuraciones de agentes que fallan de forma segura de las configuraciones que fallan de forma costosa. Si solo tienes tiempo para añadir una este trimestre, empieza por la parte superior. Si puedes hacer las cuatro, habrás cubierto más del 90 por ciento de los escenarios de incidentes que verás en 2026.

1. Pruebas de contrato del esquema de herramientas

Tu especificación OpenAPI es la fuente de la verdad para tu API. Tu agente tiene una definición de herramienta separada, a menudo escrita a mano o copiada y pegada de la documentación. Estos dos artefactos se desvían constantemente. Las pruebas de contrato fallan en tu compilación de CI en el momento en que divergen.

Aquí hay una comprobación mínima en Python que valida una definición de herramienta de estilo Claude contra la especificación OpenAPI en vivo:

import json
from jsonschema import Draft202012Validator

def validate_tool_against_openapi(tool_def: dict, openapi_spec: dict) -> list[str]:
    """Devuelve una lista de errores de desajuste, lista vacía = pasa."""
    errors = []
    op = openapi_spec["paths"][tool_def["path"]][tool_def["method"].lower()]
    api_schema = op["requestBody"]["content"]["application/json"]["schema"]
    tool_schema = tool_def["input_schema"]

    api_props = set(api_schema.get("properties", {}).keys())
    tool_props = set(tool_schema.get("properties", {}).keys())

    for missing in api_props - tool_props:
        if missing in api_schema.get("required", []):
            errors.append(f"Falta un campo requerido en la herramienta: {missing}")
    for extra in tool_props - api_props:
        errors.append(f"La herramienta define un campo que no está en la API: {extra}")

    for prop, api_def in api_schema.get("properties", {}).items():
        if prop in tool_schema.get("properties", {}):
            tool_def_prop = tool_schema["properties"][prop]
            if api_def.get("type") != tool_def_prop.get("type"):
                errors.append(
                    f"Desajuste de tipo en {prop}: API={api_def.get('type')} "
                    f"herramienta={tool_def_prop.get('type')}"
                )
    return errors

Ejecuta esto en cada PR que toque la especificación OpenAPI o las definiciones de herramientas. Haz que la compilación falle si la lista no está vacía. Esta única comprobación habría detectado el error de flotante vs. céntimos en la sección anterior meses antes de que se realizara cualquier reembolso.

2. Entornos de prueba y simulacro para puntos finales destructivos

Los agentes necesitan un lugar para practicar. Nunca deben practicar en producción. El patrón es sencillo: cada punto final que muta el estado tiene un equivalente simulado que devuelve la misma forma de respuesta sin realizar el trabajo. Tu ciclo de desarrollo del agente utiliza las simulaciones. Tus pruebas de staging utilizan una base de datos de prueba. La producción permanece intacta hasta que un humano aprueba el despliegue.

Apidog genera simulaciones directamente desde la especificación OpenAPI, incluyendo valores de campo realistas impulsados por patrones de Faker. Apuntas la URL base de la API de tu agente al servidor de simulacro, ejecutas cien iteraciones de tu prompt y observas cómo se comporta. Si el agente sigue intentando PUT en /users/{id}/delete porque malinterpretó la documentación, la simulación lo detecta. La tabla de usuarios en producción nunca ve el error. Consulta el desarrollo contract-first para el patrón más amplio en el que encaja esto.

3. Claves de idempotencia y eliminaciones suaves para operaciones irreversibles

Cada punto final de escritura al que tu agente pueda llamar debe aceptar una clave de idempotencia. Cada eliminación debe ser una eliminación suave por defecto con una ruta de eliminación dura separada que los humanos autoricen.

El middleware se ve así en Express:

const idempotencyCache = new Map();

function idempotency(req, res, next) {
  const key = req.headers['idempotency-key'];
  if (!key) {
    return res.status(400).json({ error: 'Falta la cabecera Idempotency-Key' });
  }
  if (idempotencyCache.has(key)) {
    const cached = idempotencyCache.get(key);
    return res.status(cached.status).json(cached.body);
  }
  const originalJson = res.json.bind(res);
  res.json = function (body) {
    idempotencyCache.set(key, { status: res.statusCode, body });
    setTimeout(() => idempotencyCache.delete(key), 24 * 60 * 60 * 1000);
    return originalJson(body);
  };
  next();
}

app.post('/payments', idempotency, createPayment);

El agente genera un UUID por operación lógica y lo reutiliza en los reintentos. Tu API devuelve la respuesta en caché en la segunda llamada en lugar de cobrar dos veces. Este mismo patrón protege contra envíos duplicados en APIs de mensajería, creación de filas duplicadas en CRMs y la mayoría de los otros escenarios de "el agente reintentó y ahora tenemos un lío".

4. Límites de presupuesto por agente

Cada agente recibe un presupuesto. Presupuesto de tokens, presupuesto de solicitudes, presupuesto de dólares, presupuesto de tiempo. Cuando el presupuesto se agota, el agente se detiene. Sin excepciones. El incidente de Reddit de 800 euros ocurrió porque nadie estableció un límite a un bucle descontrolado, y para cuando el humano lo revisó, el daño ya estaba hecho.

Un middleware de presupuesto que envuelva tu puerta de enlace de API podría rastrear:

• Tokens por sesión, con un límite de 50.000
• Llamadas a la API por minuto, con un límite de 30
• Gasto acumulado en céntimos, con un límite de 500
• Profundidad de llamadas a herramientas, con un límite de 10 llamadas anidadas

Cuando se alcanza cualquier límite, devuelve HTTP 429 con un Retry-After estructurado y una cabecera X-Budget-Exceeded que nombra el límite. El planificador del agente puede entonces escalar a un humano o deshacer la tarea. Combina esto con el registro para que puedas ver qué agentes están forzando los límites y ajustarlos en consecuencia.

Estos cuatro controles se combinan. Las pruebas de contrato detectan los errores de esquema obvios. Las simulaciones detectan los destructivos. La idempotencia detecta las tormentas de reintentos. Los presupuestos detectan los bucles descontrolados. Juntos, convierten "el agente hizo algo terrible" en "el agente encontró un 429, registró el problema y pidió ayuda". Ese es el estándar.

Probar llamadas de API del agente con Apidog

Ahora la parte práctica. Así es como se configura un flujo de trabajo completo de pruebas agente-API en Apidog. Necesitarás la especificación OpenAPI para la API a la que llama tu agente, además de una lista de las definiciones de herramientas del agente.

Paso 1: Importar la especificación OpenAPI

Abre Apidog, crea un nuevo proyecto e importa tu archivo OpenAPI 3.x. Apidog analiza cada ruta, esquema y ejemplo y crea los puntos finales correspondientes en el proyecto. Si tu API aún no está documentada en OpenAPI, este es el momento de hacerlo; la fiabilidad del agente depende de tener una única fuente de verdad que lean tanto tus humanos como tus agentes de IA. La guía de flujo de trabajo de API design-first te explica esto si estás empezando desde cero.

Paso 2: Definir respuestas de simulacro para puntos finales destructivos

Encuentra cada punto final que modifica datos: POST, PUT, PATCH, DELETE. Para cada uno, haz clic en el punto final y añade una respuesta de simulacro. Apidog puede auto-generar simulaciones realistas a partir de tu esquema, pero debes sobrescribir los valores de los campos para que parezcan datos de prueba, no datos de producción. Utiliza prefijos como mock_user_ y marcas de tiempo en 1970 para que cualquier fuga sea obvia en los registros.

Inicia el servidor de simulacro. Apidog te proporciona una URL estable como https://mock.apidog.com/m1/your-project-id/. Apunta la URL base de la API de tu agente al servidor de simulacro durante el desarrollo. Ahora tu DELETE /users/{id} devuelve un 200 con una carga útil de usuario falsa, y tu base de datos real está segura.

Paso 3: Escribir un escenario que simule la secuencia de llamadas del agente

Los escenarios de Apidog te permiten encadenar llamadas a la API con aserciones, de la misma manera que lo hace una suite de pruebas. Para un agente que clasifica tickets de soporte, el escenario podría ser:

1. POST /auth/token con credenciales de prueba, captura el token de portador
2. GET /tickets?status=open con el token, captura el ID del primer ticket
3. POST /tickets/{id}/triage con una categoría, aserta 200 y captura el campo asignado a
4. POST /notifications con un mensaje con plantilla, aserta que el cuerpo del mensaje coincide con una expresión regular

Estás ensayando lo que hará el agente, en el servidor de simulacro, con aserciones en cada paso. Si un desarrollador cambia el esquema del ticket y la expresión regular deja de coincidir, el escenario falla y lo sabes antes de que el agente llegue a producción. Consulta pruebas de API para ingenieros de QA para el manual más amplio de pruebas de escenarios.

Paso 4: Ejecutar desde CI

Apidog incluye una CLI que ejecuta escenarios desde un GitHub Action, una pipeline de GitLab o cualquier ejecutor de CI. El comando se ve así: apidog run -t scenario-id --env test. Engánchalo a tu pipeline de PR para que cada cambio en la especificación OpenAPI o en las definiciones de herramientas del agente active una repetición completa del escenario.

Paso 5: Comparar dos versiones del modelo en paralelo

Cuando evalúas si actualizar de un modelo a otro, quieres saber si las llamadas de herramientas del nuevo modelo se comportan de la misma manera en los mismos escenarios. Ejecuta el agente contra el mismo escenario de Apidog con el modelo A, captura el rastro. Ejecuta de nuevo con el modelo B, captura el rastro. Compara los cuerpos de las solicitudes. Las sorpresas aparecen inmediatamente: el modelo B pasa un valor de priority diferente, o omite un campo, o usa un formato diferente para las fechas. Detectas la deriva de comportamiento antes de que se implemente. Este es uno de los patrones cubiertos en la integración de la API de GPT-5.5, donde evaluar el comportamiento de nuevos modelos es una necesidad recurrente.

Todo el flujo de trabajo tarda aproximadamente una hora en configurarse la primera vez y minutos por ejecución después. La recompensa es que cada cambio en tu API o en las herramientas de tu agente se ejercita contra el mismo punto de referencia de expectativas.

Técnicas avanzadas y consejos profesionales

Algunos patrones a los que recurren los equipos experimentados una vez que se han establecido los conceptos básicos.

Fija la temperatura a cero en las pruebas. Los agentes no deterministas provocan fallos de prueba no deterministas. Cuando pruebes el comportamiento de las herramientas, establece la temperatura en 0 y siembra cualquier fuente de aleatoriedad. Estás probando la capa de la herramienta, no la capa de la creatividad.

Rastros de llamadas a herramientas instantáneas. Cada ejecución de prueba registra la secuencia exacta de llamadas a herramientas que realizó el agente, con argumentos. Compara con la línea base anterior. Si el agente de repente comienza a llamar a /users dos veces en lugar de una, querrás saberlo de inmediato, no tres semanas después cuando llegue la factura.

Nunca des credenciales de producción a un agente. Los agentes obtienen cuentas de servicio con ámbito. Las credenciales de producción viven en bóvedas, no en archivos .env que un agente pueda leer. Si un agente necesita llamar a un punto final de producción, lo hace a través de un proxy que firma las solicitudes con tokens de corta duración.

Separa las claves API de lectura y escritura. La mayoría de las tareas del agente son principalmente de lectura. Emite claves de solo lectura para esas tareas. Las claves de escritura están reservadas para tareas que tienen puertas de aprobación humana. Este simple cambio reduce a la mitad el radio de impacto de un agente comprometido.

Usa HTTP 423 Locked para puntos finales de aprobación humana. Cuando un agente intenta llamar a un punto final que requiere confirmación humana, devuelve 423 con un campo confirmation_url. El planificador del agente ve el estado bloqueado, muestra la URL a un humano y espera. Esto es más limpio que un 403, porque 403 implica "no puedes hacer esto" mientras que 423 implica "no puedes hacer esto todavía".

Falla cerrado en caso de desviación del esquema. Si la definición de herramienta del agente no coincide con tu especificación OpenAPI, la compilación falla. No envíes una advertencia. Envía un error. El costo de unas pocas compilaciones fallidas adicionales es mucho menor que un incidente de producción.

Errores comunes a evitar:

• Codificar la URL de simulación directamente en los prompts del agente. Usa variables de entorno para que el mismo prompt se ejecute contra simulación, staging y producción.
• Omitir la idempotencia en puntos finales "pequeños". Cada escritura lo necesita. El envío de correos electrónicos no es una excepción.
• Registrar cuerpos de solicitud completos en producción. La PII se filtra en tu pila de observabilidad. Redacta tokens, correos electrónicos e identificadores antes de que lleguen a los registros.
• Permitir que los agentes tengan acceso directo a la base de datos. Siempre a través de la API. La API es donde residen tus pruebas.
• Confiar en la puntuación de confianza del agente. La puntuación refleja la certeza del modelo sobre la respuesta, no la seguridad de la API. Un agente 99% seguro aún puede llamar al punto final equivocado.

Si tu agente se comunica con servicios internos que no están detrás de una única puerta de enlace API, los patrones de prueba de microservicios cubren cómo distribuir las pruebas de escenario entre los servicios.

Alternativas y herramientas

Tienes opciones. Aquí hay una comparación justa de los cuatro enfoques comunes.

El resumen honesto: si trabajas en LangSmith, sigue haciendo lo que funciona en el lado del agente y añade una capa separada de pruebas de API. Si has superado los precios de Postman o su modelo de simulación, Apidog es un fuerte reemplazo. Si estás empezando de cero, elige la herramienta que maneje OpenAPI, las simulaciones y los escenarios en un solo proyecto, porque ahí es donde se va el 80 por ciento de tu tiempo de prueba agente-API.

Algunos equipos los combinan. Mantienen LangSmith para evaluaciones a nivel de prompt y usan Apidog para las pruebas de contrato del lado de la API y las reproducciones de escenarios. Eso funciona bien; las herramientas sirven a diferentes capas.

Casos de uso en el mundo real

El agente actualiza filas de la base de datos de producción. Un equipo de atención al cliente construyó un agente que actualiza campos de cuentas a partir de tickets de soporte. Antes del lanzamiento, configuraron cada punto final de escritura para que requiriera una clave de idempotencia y ejecutaron 200 repeticiones de escenarios en Apidog contra una base de datos de prueba. Las repeticiones detectaron dos casos en los que el agente intentó establecer subscription_status a una cadena que no estaba en el enumerado. Añadieron validación de esquema y se lanzaron sin incidentes.

El agente llama a una API de pagos. Un equipo de fintech que construye un agente de reembolso automatizado estableció límites estrictos: máximo 5 reembolsos por sesión, máximo 50 dólares por reembolso, idempotencia requerida en cada llamada. Ejecutaron la suite de pruebas de contrato contra la OpenAPI de Stripe en cada PR. Seis meses después, han procesado 12.000 reembolsos sin cargos duplicados.

El agente clasifica problemas de GitHub. Un equipo de plataforma construyó un agente de clasificación de problemas inspirado en Clawsweeper. Simularon la API de GitHub en Apidog, ejecutaron al agente a través de 50 pruebas de escenario que cubrían casos extremos (problemas eliminados, etiquetas faltantes, entrada de usuario mal formada) y encontraron tres fallos antes del lanzamiento. El agente ahora maneja la clasificación en un repositorio público con 5.000 problemas abiertos.

Conclusión

Si te llevas una cosa de esta guía, que sea esta: el agente no es el problema. La API es el problema, o es la solución, dependiendo de si la probaste.

Cinco conclusiones:

• Trata los esquemas de herramientas como contratos y ejecuta pruebas de contrato en CI.
• Simula puntos finales destructivos para cada ciclo de desarrollo del agente.
• Requiere claves de idempotencia en cada escritura que tu agente pueda llamar.
• Establece límites de presupuesto por agente que fallen en cerrado cuando se alcancen.
• Reproduce escenarios en cada PR que toque la API o las definiciones de herramientas.

Los incidentes virales de este año no serán los últimos. Todo equipo que desarrolle agentes se encontrará con uno de estos modos de fallo al menos una vez. Los equipos que se recuperan rápidamente son los que ya tenían las salvaguardas implementadas. Descarga Apidog y comienza con el paso del servidor de simulacro; solo eso te ahorrará una noche sin dormir este trimestre. Para la perspectiva del equipo de QA sobre este mismo problema, consulta herramientas de prueba de API para ingenieros de QA. Para un contexto más amplio sobre cómo escribir definiciones de herramientas que los agentes puedan usar de forma segura, consulta cómo escribir archivos AGENTS.md.

Preguntas Frecuentes

¿Cómo pruebo las llamadas a la API de los agentes de IA sin gastar dinero en tokens?

Ejecuta tu agente contra un servidor de simulacro durante el desarrollo. Las URLs de simulacro de Apidog devuelven respuestas realistas de forma gratuita, por lo que tus ciclos de prueba no consumen créditos reales de la API. Fija la temperatura en 0 y usa un conjunto de prompts pequeño y fijo. Puedes ejecutar miles de iteraciones de prueba por el costo del servidor de simulacro, que es cero. Consulta la lista de verificación de pruebas del ingeniero de QA para una configuración completa.

¿Cuál es la diferencia entre probar el agente y probar la API?

Las pruebas del agente comprueban si el modelo elige la herramienta correcta y rellena los argumentos correctamente. Las pruebas de la API comprueban si el punto final se comporta correctamente cuando se llama. Ambos importan. Un agente perfecto que llama a una API rota sigue produciendo resultados rotos, y un agente roto que llama a una API perfecta sigue enviando errores. Necesitas ambas capas probadas por separado.

¿Necesito claves de idempotencia en todos los puntos finales?

Sí, en cada punto final de escritura. Las lecturas son idempotentes por definición. Las escrituras no lo son, y los agentes reintentan. Las cinco líneas de middleware para soportar una cabecera de idempotencia se amortizan la primera vez que el agente reintenta un error 500 y no obtienes una fila duplicada.

¿Cómo evito que la inyección de prompts desencadene llamadas a la API incorrectas?

No dependas solo de la capa de prompts. La API debe aplicar la autorización basándose en el contexto original del usuario, no en la solicitud del agente. Si una sesión de contexto de usuario normalmente no puede acceder a /admin/delete-all-users, entonces el agente que actúa en nombre de ese usuario tampoco debería poder hacerlo, independientemente de lo que diga el prompt. El Top 10 de LLM de OWASP cubre esto en detalle.

¿Puedo usar Apidog con Claude o GPT directamente, sin escribir mi propia capa de herramientas?

Durante las pruebas, apuntas las definiciones de herramientas de tu agente a la URL de simulación de Apidog. Tanto Claude como GPT admiten URLs base HTTP arbitrarias en sus definiciones de herramientas, por lo que el cambio es una variable de entorno. Cuando estés listo para probar contra staging o producción, cambia la variable.

¿Cuál es el límite presupuestario adecuado para un agente?

Empieza estricto y relaja con los datos. Comienza con 50.000 tokens por sesión, 30 llamadas a la API por minuto, 5 dólares por tarea. Observa las métricas durante dos semanas. Aumenta los límites que realmente alcances. Reduce los límites que nunca alcanzas. Revisa mensualmente. El objetivo no es un número fijo; es un número lo suficientemente ajustado como para detectar bucles descontrolados y lo suficientemente flexible como para permitir que se realice el trabajo real.

¿Cómo detecto la deriva del esquema entre las herramientas de mi agente y mi API?

Ejecuta una diferencia de esquema en CI en cada PR. Compara la definición de herramienta del agente (esquema JSON) con el esquema del cuerpo de la solicitud OpenAPI para el mismo punto final. Haz que la compilación falle si divergen. El fragmento de Python de 30 líneas en la sección de salvaguardas anterior hace esto; cópialo en tu repositorio y conéctalo a GitHub Actions.