Cómo probar agentes de IA que llaman a 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. La autopsia en Hacker News se volvió viral con un título contundente: "La IA no borró tu base de datos, tú lo hiciste". El punto 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 barreras de seguridad, 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.

En resumen

Los agentes fallan en producción cuando sus herramientas no tienen barreras de seguridad del lado de la API: límites de tasa ausentes, no idempotencia, eliminaciones en caliente, esquemas rotos. Lo solucionas con cuatro movimientos: prueba de contrato las definiciones de herramientas del agente contra tu especificación OpenAPI, ejecuta un servidor mock para puntos finales destructivos, aplica límites de presupuesto por agente y claves de idempotencia, y reproduce escenarios de fallo en CI. Apidog te proporciona la importación de OpenAPI, los mocks 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 pedirle 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 tasa faltante 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 borró 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 se disparó 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 se diera cuenta. Misma causa raíz: confianza depositada en la capa equivocada.

Puedes solucionar esto. La capa del modelo importa, pero la capa de la API es donde detienes el sangrado. Este artículo te muestra cómo probar las integraciones de API de los agentes de IA de principio a fin. Cubriremos las cuatro barreras de seguridad que toda configuración de agente-API necesita, te guiaremos a través de un flujo de trabajo paso a paso de Apidog para simular puntos finales destructivos, y terminaremos con técnicas avanzadas como la detección de la deriva del esquema y la separación de claves dobles. 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 mock.

Por qué los fallos de los agentes se parecen a los fallos de las API

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

Considera la inyección de prompt. Un usuario sube un PDF con instrucciones ocultas, el agente lo lee, y la siguiente llamada a la 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 provenga 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.

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

Considera la ausencia de límites de tasa. Un agente en un bucle de reintentos bombardea 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 con una herramienta que no tenía un límite.

Considera 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 conductor: 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 auditas dónde falla la fiabilidad del agente, mira primero el contrato de la API, segundo el arnés del agente, y casi nunca el modelo mismo. Este reenfoque importa porque te dice dónde invertir. No necesitas un modelo más inteligente. Necesitas APIs comprobables con las barreras de seguridad activadas.

Las cuatro barreras de seguridad que toda integración de agente-API necesita

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

1. Pruebas de contrato de esquema de herramientas

Tu especificación OpenAPI es la fuente de verdad para tu API. Tu agente tiene una definición de herramienta separada, a menudo escrita a mano o copiada de la documentación. Estos dos artefactos se desvían constantemente. Las pruebas de contrato fallan 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 al 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]:
    """Return a list of mismatch errors, empty list = pass."""
    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"Tool missing required field: {missing}")
    for extra in tool_props - api_props:
        errors.append(f"Tool defines field not in 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"Type mismatch on {prop}: API={api_def.get('type')} "
                    f"tool={tool_def_prop.get('type')}"
                )
    return errors

Ejecuta esto en cada PR que afecte tanto a la especificación OpenAPI como a 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. centavos en la sección anterior meses antes de que se realizara cualquier reembolso.

2. Entornos de pruebas y simulación para puntos finales destructivos

Los agentes necesitan un lugar para practicar. Nunca deberían practicar en producción. El patrón es sencillo: cada punto final que modifica el estado tiene un equivalente simulado que devuelve la misma forma de respuesta sin realizar el trabajo. Tu bucle de desarrollo de agentes utiliza los simulacros. Tus pruebas de staging utilizan una base de datos de pruebas. La producción permanece intacta hasta que un humano aprueba el despliegue.

Apidog genera simulaciones directamente a partir de la especificación OpenAPI, incluyendo valores de campo realistas impulsados por patrones Faker. Apuntas la URL base de tu agente al servidor simulado, 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 basado en contratos para el patrón más amplio en el que encaja esto.

3. Claves de idempotencia y borrado suave para operaciones irreversibles

Cada endpoint de escritura que tu agente pueda llamar debería aceptar una clave de idempotencia. Cada borrado debería ser un borrado suave por defecto con una ruta separada de borrado duro 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: 'Missing Idempotency-Key header' });
  }
  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 cacheadas en la segunda llamada en lugar de cobrar dos veces. Este mismo patrón protege contra envíos dobles en APIs de mensajería, creación de filas duplicadas en CRMs, y la mayoría de otros escenarios de "el agente reintentó y ahora tenemos un desastre".

4. Límites de presupuesto por agente

Cada agente recibe un presupuesto. Presupuesto de tokens, presupuesto de solicitudes, presupuesto monetario, 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 para un bucle descontrolado, y para cuando el humano lo verificó, el daño ya estaba hecho.

Un middleware de presupuesto que envuelve tu pasarela 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 centavos, con un límite de 500
• Profundidad de llamada de herramienta, con un límite de 10 llamadas anidadas

Cuando se alcanza cualquier límite, devuelve HTTP 429 con un Retry-After estructurado y un encabezado 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 presionando los límites y ajustar en consecuencia.

Estos cuatro controles se combinan. Las pruebas de contrato detectan los errores obvios de esquema. Los mocks 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 a la API de agentes con Apidog

Ahora la parte práctica. Aquí te explicamos cómo configurar un flujo de trabajo completo de prueba de 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 tanto tus humanos como tus agentes de IA puedan leer. La guía de flujo de trabajo de API con diseño primero te explica esto si empiezas desde cero.

Paso 2: Definir respuestas simuladas para puntos finales destructivos

Encuentra todos los puntos finales que modifican datos: POST, PUT, PATCH, DELETE. Para cada uno, haz clic en el punto final y añade una respuesta simulada. Apidog puede generar simulaciones realistas automáticamente a partir de tu esquema, pero deberías 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 mock. Apidog te da una URL estable como https://mock.apidog.com/m1/your-project-id/. Apunta la URL base de la API de tu agente al servidor mock 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 un conjunto 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, afirma 200 y captura el campo asignado a
4. POST /notifications con un mensaje templado, afirma que el cuerpo del mensaje coincide con una expresión regular

Básicamente, estás ensayando lo que hará el agente, en el servidor simulado, con aserciones en cada salto. Si un desarrollador cambia el esquema de tickets 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 de pruebas de escenarios más amplio.

Paso 4: Ejecutar desde CI

Apidog incluye una CLI que ejecuta escenarios desde una Acción de GitHub, una tubería de GitLab o cualquier ejecutor de CI. El comando es algo como apidog run -t scenario-id --env test. Engánchalo a tu tubería 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 estás evaluando si actualizar de un modelo a otro, quieres saber si las llamadas a 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 rastreo. Vuelve a ejecutar con el modelo B, captura el rastreo. Compara los cuerpos de las solicitudes. Las sorpresas aparecen inmediatamente: el modelo B pasa un valor priority diferente, u omite un campo, o usa un formato diferente para las fechas. Detectas la desviación 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 los 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 los conceptos básicos están en su lugar.

Fijar la temperatura a cero en las pruebas. Los agentes no deterministas generan fallos de prueba no deterministas. Cuando estés probando el comportamiento de las llamadas a herramientas, establece la temperatura en 0 y siembra cualquier fuente de aleatoriedad. Estás probando la capa de herramientas, no la capa de creatividad.

Instantáneas de rastreos de llamadas a herramientas. Cada ejecución de prueba registra la secuencia exacta de llamadas a herramientas que hizo el agente, con sus 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 inmediatamente, 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 limitado. 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.

Separar las claves de API de lectura y escritura. La mayoría de las tareas de los agentes 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 humanas. Este único cambio reduce a la mitad el radio de acción de un agente comprometido.

Usa HTTP 423 Locked para puntos finales que requieren 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."

Fallo cerrado en caso de desviación del esquema. Si la definición de la 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 en 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 el entorno de simulación, staging y producción.
• Omitir la idempotencia en puntos finales "pequeños". Toda escritura la 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 pasa por 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 con un 99 por ciento de confianza 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 pasarela API, los patrones de prueba de microservicios cubren cómo distribuir las pruebas de escenario entre los servicios.

Alternativas y herramientas

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

El resumen honesto: si vives en LangSmith, sigue haciendo lo que funciona en el lado del agente y añade una capa de prueba de API separada. Si has superado los precios de Postman o su modelo de simulación, Apidog es un fuerte reemplazo. Si estás empezando de nuevo, 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 de agente-API.

Algunos equipos combinan estas herramientas. 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 reales

El agente actualiza filas de bases de datos de producción. Un equipo de atención al cliente creó un agente que actualiza campos de cuenta a partir de tickets de soporte. Antes del lanzamiento, configuraron todos los puntos finales de escritura para que requirieran una clave de idempotencia y ejecutaron 200 reproducciones de escenarios en Apidog contra una base de datos de pruebas. Las reproducciones detectaron dos casos en los que el agente intentó establecer subscription_status a una cadena que no estaba en el enum. Añadieron validación de esquema y se implementaron sin incidentes.

El agente llama a una API de pagos. Un equipo de tecnología financiera que construía un agente de reembolso automatizado estableció límites estrictos: un máximo de 5 reembolsos por sesión, un máximo de 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 incidencias de GitHub. Un equipo de plataforma creó un agente de clasificación de incidencias inspirado en Clawsweeper. Simularon la API de GitHub en Apidog, ejecutaron el agente a través de 50 pruebas de escenario que cubrían casos extremos (incidencias eliminadas, etiquetas faltantes, entrada de usuario mal formada) y encontraron tres bloqueos antes del lanzamiento. El agente ahora gestiona la clasificación en un repositorio público con 5.000 incidencias abiertas.

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 puntos clave:

• 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 modo cerrado cuando se alcancen.
• Reproduce escenarios en cada PR que afecte a la API o a las definiciones de herramientas.

Los incidentes virales de este año no serán los últimos. Cada equipo que despliega agentes se enfrentará a uno de estos modos de fallo al menos una vez. Los equipos que se recuperan rápidamente son los que ya tenían las barreras de seguridad implementadas. Descarga Apidog y comienza con el paso del servidor mock; eso por sí solo 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 agentes de IA sin gastar dinero en tokens?

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

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

Las pruebas del agente verifican si el modelo elige la herramienta correcta y rellena los argumentos correctamente. Las pruebas de la API verifican si el punto final se comporta correctamente cuando se llama. Ambas 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 que ambas capas se prueben por separado.

¿Necesito claves de idempotencia en cada punto final?

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 un encabezado de idempotencia se pagan solas 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 mock de Apidog. Tanto Claude como GPT admiten URLs base HTTP arbitrarias en sus definiciones de herramientas, por lo que el cambio es solo 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?

Comienza estricto y afloja con los datos. Empieza 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 legítimamente se superan. Reduce los límites que nunca se alcanzan. 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 desviación de esquemas 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 de 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 barreras de seguridad anterior hace esto; cópialo en tu repositorio y conéctalo a GitHub Actions.