¿Qué es OpenAI AgentKit?

OpenAI AgentKit es un conjunto de herramientas para construir, desplegar y medir agentes de IA en la plataforma de OpenAI. Si alguna vez has configurado un agente manualmente, manejando código de orquestación, conectores y scripts de evaluación, AgentKit fue la respuesta de OpenAI a esa fragmentación. Hay un detalle importante en 2026 que debes saber antes de comprometerte, por lo que esta guía explica qué incluye AgentKit, para quién es, un flujo de construcción de alto nivel y dónde encajan las herramientas de prueba de API como Apidog cuando tu agente comienza a llamar a servicios externos.

Qué es AgentKit

OpenAI presentó AgentKit en DevDay el 6 de octubre de 2025. No era un único producto. Era un conjunto de piezas que se superponen a la API existente de OpenAI y al SDK de Agentes de OpenAI, con el objetivo de reducir la brecha entre "tengo una idea para un agente" y "tengo un agente funcionando frente a los usuarios".

Antes de AgentKit, construir un agente generalmente significaba unir lógica de orquestación sin control de versiones, conectores personalizados para cada fuente de datos, pipelines de evaluación hechos a mano, ajuste manual de prompts y una buena cantidad de trabajo de frontend antes de que algo se lanzara. AgentKit empaquetó soluciones a esos problemas bajo un mismo paraguas.

Una cosa a destacar de antemano, porque cambia cómo debes tratar esto: el 3 de junio de 2026, OpenAI anunció que va a retirar dos de las piezas de AgentKit, Agent Builder y Evals. Más detalles sobre las fechas a continuación. La conclusión es que el camino duradero y de código primero a través de AgentKit es el SDK de Agentes, y es sobre lo que debes construir si quieres algo que perdure.

Las piezas de AgentKit

AgentKit se lanzó con cuatro componentes principales. Aquí está lo que hace cada uno y su estado actual.

Agent Builder

Agent Builder es un lienzo visual para diseñar flujos de trabajo de agentes de varios pasos. Arrastras y sueltas nodos para cada paso, los conectas en un flujo, previsualizas ejecuciones con entradas reales y publicas instantáneas versionadas del flujo de trabajo. Es el punto de entrada de "no hay página en blanco", con plantillas para empezar.

Un detalle útil para los desarrolladores: Agent Builder no es un callejón sin salida lejos del código. Tiene una pestaña del SDK de Agentes que exporta tu flujo de trabajo como Python o TypeScript ejecutable, para que puedas tomar el diseño visual y extenderlo en tu propio entorno.

El estado importa aquí. OpenAI está desaprobando Agent Builder, con una fecha de cierre de la plataforma del 30 de noviembre de 2026, según su página de desaprobaciones. Si estás comenzando hoy, trata el lienzo visual como una ayuda para prototipos y planea terminar en el código del SDK.

ChatKit

ChatKit es una interfaz de chat incrustable para poner tu agente frente a los usuarios. En lugar de construir una interfaz de usuario de chat desde cero, insertas un componente web, lo apuntas a un ID de flujo de trabajo publicado y personalizas el tema y el comportamiento. Maneja respuestas en streaming, hilos y la fontanería de chat habitual.

ChatKit sigue disponible y es la forma recomendada de desplegar una experiencia de agente basada en chat. Es la pieza de AgentKit menos afectada por los cambios de 2026.

Registro de Conectores

El Registro de Conectores es un lugar con interfaz de administración para gestionar cómo se conectan los datos y las herramientas a través de los productos de OpenAI, abarcando ChatGPT y la API. Consolida conectores preconstruidos (piensa en Dropbox, Google Drive, SharePoint, Microsoft Teams) y servidores MCP de terceros en un único panel, para que un administrador controle lo que un agente puede alcanzar.

Si quieres entender el lado MCP de esa imagen, nuestra guía sobre servidores MCP y el SDK de Agentes de OpenAI cubre cómo los agentes llaman a herramientas a través del Protocolo de Contexto del Modelo.

Evaluaciones y optimización

Las características de Evals añadieron conjuntos de datos, calificación de rastros (puntuación de cada paso de una ejecución multi-agente), optimización automática de prompts y la capacidad de calificar contra modelos de terceros, no solo los de OpenAI. El objetivo era medir la calidad del agente y ajustar los prompts sin construir tu propia herramienta de evaluación.

Al igual que Agent Builder, Evals está siendo retirado. Se volverá de solo lectura para los usuarios existentes el 31 de octubre de 2026 y se cerrará el 30 de noviembre de 2026.

Cómo se relaciona AgentKit con el SDK de Agentes

Esta es la parte que vale la pena entender bien, porque determina sobre qué construirás.El SDK de Agentes es el framework a nivel de código. Es donde defines agentes, herramientas, traspasos y barandillas en Python o TypeScript. El Agent Builder de AgentKit se sitúa por encima como una capa visual que genera código SDK. ChatKit se sitúa a su lado como una superficie de despliegue.

La guía de migración de OpenAI es directa: para flujos de trabajo que deben vivir como código, migra al SDK de Agentes. Para casos de uso de lenguaje natural que no necesitan código, usa Agentes de Workspace en ChatGPT. Si estás leyendo esto para decidir dónde invertir, el SDK de Agentes es la respuesta para los equipos de ingeniería.

Para quién es AgentKit

AgentKit se dirigió a varios grupos. Los equipos de producto que querían lanzar un agente rápidamente sin escribir código de orquestación se apoyaron en Agent Builder y ChatKit. Las empresas que necesitaban acceso gobernado a datos internos utilizaron el Registro de Conectores. Los equipos de ingeniería que querían control total recurrieron directamente al SDK de Agentes y utilizaron Evals para medir la calidad.

Dadas las desaprobaciones, la lectura más clara para 2026 es esta: si eres un ingeniero construyendo algo para mantener, comienza con el SDK de Agentes. Si estás prototipando y quieres una ventaja visual antes de que el lienzo desaparezca, Agent Builder aún exporta código utilizable.

Un flujo de construcción de alto nivel

Ya sea que comiences visualmente o con código, la forma de construir un agente es similar. Aquí está el flujo que la mayoría de los equipos sigue.

1. Define el trabajo del agente. ¿Qué objetivo persigue y qué herramientas necesita? Las herramientas suelen ser llamadas a API externas: un endpoint de búsqueda, una consulta de CRM, un microservicio interno.
2. Compón el flujo de trabajo. En Agent Builder arrastras nodos; en el SDK de Agentes defines agentes y adjuntas herramientas y traspasos en código.
3. Añade barandillas de seguridad. OpenAI ofrece una capa de barandillas de seguridad modular de código abierto que puede enmascarar o marcar PII, detectar intentos de jailbreak y aplicar otras comprobaciones. Puedes usarla como nodos de flujo de trabajo o como una biblioteca independiente.
4. Conecta datos y herramientas. A través del Registro de Conectores o registrando servidores MCP y herramientas de función que el agente puede llamar.
5. Prueba y evalúa. Ejecuta el agente con entradas reales, califica los rastros y ajusta los prompts.
6. Despliega. Incrusta a través de ChatKit con un ID de flujo de trabajo publicado, o ejecuta tu código exportado del SDK de Agentes en tu propia infraestructura.

Los pasos 4 y 5 son donde reside la mayor parte del dolor del mundo real, y donde las pruebas de API demuestran su valía.

Un ejemplo realista: las herramientas que tu agente llama

Un agente es tan bueno como las herramientas que puede llamar, y esas herramientas son casi siempre APIs HTTP. Cuando registras una herramienta de función con el SDK de Agentes, la describes con un esquema JSON para que el modelo sepa cuándo y cómo llamarla. Una herramienta que obtiene los pedidos recientes de un cliente podría definirse así:

{
  "type": "function",
  "name": "get_recent_orders",
  "description": "Busca los pedidos recientes de un cliente por ID de cliente.",
  "parameters": {
    "type": "object",
    "properties": {
      "customer_id": {
        "type": "string",
        "description": "El identificador único del cliente"
      },
      "limit": {
        "type": "integer",
        "description": "Cuántos pedidos devolver",
        "default": 5
      }
    },
    "required": ["customer_id"],
    "additionalProperties": false
  }
}

Cuando el modelo decide llamar a get_recent_orders, tu código recibe los argumentos, realiza una solicitud real a tu API de pedidos y devuelve el resultado al agente. Esa solicitud podría verse así:

curl https://api.your-company.com/v1/customers/cus_8842/orders?limit=5 \
  -H "Authorization: Bearer $ORDERS_API_KEY" \
  -H "Content-Type: application/json"

Aquí está el problema. El comportamiento del agente depende completamente de lo que devuelva esa API. Si la API de pedidos es lenta, está caída o devuelve una forma que el modelo no esperaba, el razonamiento del agente se descarrila. Y durante el desarrollo, la API de pedidos podría no existir todavía, o quizás no quieras bombardear la producción con ejecuciones de prueba. Ahí es donde Apidog encaja.

Dónde encajan las pruebas y la simulación de API

Apidog no es un framework de agentes, y no construye agentes. AgentKit y el SDK de Agentes hacen eso. Lo que hace Apidog es la capa subyacente: prueba, simula y documenta las APIs y herramientas que tu agente llama. Constantemente surgen tres trabajos concretos.

Primero, simula las APIs externas antes de que estén listas. Si tu agente necesita llamar a un servicio de pedidos que el equipo de backend aún no ha terminado, puedes configurar una API simulada que devuelva respuestas realistas que coincidan con el esquema acordado. Tu agente se desarrolla contra un contrato estable en lugar de esperar al backend, y controlas los casos límite, resultados vacíos, errores, respuestas lentas, bajo demanda.

Segundo, asegúrate de que cada herramienta devuelva lo que el agente espera. Una llamada a una herramienta que devuelve un 200 con nombres de campo incorrectos es peor que un fallo total, porque el modelo intentará razonar sobre datos basura. Al escribir casos de prueba de API que validan códigos de estado, forma de la respuesta y valores de campo específicos, detectas el desvío del contrato en cada endpoint que tu agente toca antes de que llegue al modelo.

Tercero, gestiona las claves de entorno y las URLs base en entornos de desarrollo, staging y producción. Las herramientas del agente llevan secretos como $ORDERS_API_KEY. Mantenerlos en variables de entorno e intercambiarlos por entorno, sin pegar claves en el código, es exactamente el tipo de cosa que una plataforma de API maneja de forma limpia. Puedes descargar Apidog e integrar los endpoints de tus herramientas en un proyecto para probarlos de forma aislada, lejos del tiempo de ejecución del agente.

Si quieres un tutorial detallado sobre cómo tratar las llamadas a herramientas de un agente como APIs testeables, escribimos uno en cómo probar las llamadas a herramientas de un agente de IA. La versión corta: cada herramienta que tu agente llama es una API, y las APIs merecen pruebas.

Preguntas frecuentes

¿Es gratuito OpenAI AgentKit?

Las herramientas de AgentKit se basan en tu uso de la API de OpenAI, por lo que pagas por los tokens del modelo subyacente y por cualquier llamada a herramientas que realice el agente. No hay un elemento de suscripción independiente de AgentKit; el costo es el uso del modelo y de la API que genera tu agente. Siempre consulta los precios actuales en la plataforma de OpenAI, ya que las tarifas del modelo cambian.

¿Cuál es la diferencia entre AgentKit y el SDK de Agentes?

El SDK de Agentes es el framework a nivel de código para definir agentes, herramientas y barandillas de seguridad. AgentKit es un paquete más amplio que incluía el Agent Builder visual, ChatKit, el Registro de Conectores y Evals, además de ese SDK. Dado que Agent Builder y Evals se están retirando a finales de 2026, el SDK de Agentes es el camino duradero y de código primero. Nuestra guía del SDK de Agentes lo cubre de principio a fin.

¿Desaparece Agent Builder?

Sí. OpenAI anunció el 3 de junio de 2026 que está desaprobando Agent Builder y la plataforma Evals. Ambos se cerrarán el 30 de noviembre de 2026, y Evals se volverá de solo lectura el 31 de octubre de 2026. ChatKit sigue disponible, y OpenAI recomienda mover los flujos de trabajo de código primero al SDK de Agentes y los de lenguaje natural a los Agentes de Workspace en ChatGPT.

¿Puedo probar las APIs que llama mi agente de AgentKit?

Sí, y deberías. Cada herramienta que un agente llama es una API HTTP con una solicitud y una respuesta. Puedes simular esas APIs mientras aún se están construyendo, asegurar que sus respuestas coincidan con el esquema que tu agente espera y gestionar las claves que cada una necesita. Una plataforma como Apidog maneja los tres para que las herramientas de tu agente se comporten de forma predecible antes de llegar a un usuario real.

Conclusión

AgentKit proporcionó a los desarrolladores de OpenAI una vía de acceso más rápida para construir agentes: un lienzo visual en Agent Builder, una interfaz de usuario incrustable en ChatKit, conectores gobernados en el Registro de Conectores y medición a través de Evals. Hacia finales de 2026, Agent Builder y Evals serán retirados, por lo que la apuesta duradera para los equipos de ingeniería es el SDK de Agentes, junto con ChatKit y el Registro de Conectores.

Cualquiera que sea el camino que tomes, la fiabilidad de tu agente se reduce a las APIs que llama. Simúlalas pronto, asegura sus respuestas y mantén tus claves organizadas. Apidog te proporciona un único lugar para probar y simular cada endpoint de herramienta de la que depende tu agente, para que las integraciones resistan cuando un agente las somete a carga.