Nuevas herramientas para crear agentes
(openai.com)- OpenAI presentó Responses API, herramientas integradas, Agents SDK y herramientas de observabilidad para facilitar el desarrollo de agentes listos para producción
- Responses API combina la simplicidad de Chat Completions API con las capacidades de uso de herramientas de Assistants API, permitiendo manejar búsqueda web, búsqueda de archivos y uso de computadora en un solo flujo
- Para nuevas integraciones se recomienda usar Responses API, mientras que Assistants API entrará en proceso de descontinuación con el objetivo de finalizar a mediados de 2026, una vez alcanzada la paridad funcional
- Las herramientas integradas admiten información web actualizada, búsqueda en documentos a gran escala y automatización de tareas de computadora basadas en mouse y teclado, aunque para computer use se recomienda especialmente la supervisión humana en entornos que no sean de navegador
- Los desarrolladores pueden combinar API, herramientas, SDK y funciones de seguimiento y evaluación en una sola plataforma para crear, desplegar y optimizar agentes
Nuevos componentes para el desarrollo de agentes
- OpenAI considera a los agentes como sistemas que realizan tareas de forma independiente en nombre de los usuarios
- Durante el último año, la incorporación de razonamiento avanzado, interacciones multimodales y nuevas técnicas de seguridad sentó las bases para manejar tareas complejas de varios pasos
- Los clientes tuvieron dificultades al convertir estas capacidades en agentes listos para producción
- Se requiere una amplia iteración de prompts
- Hay que crear lógica de orquestación personalizada por cuenta propia
- Falta visibilidad suficiente y soporte integrado
- Los componentes presentados ahora son los siguientes
- Responses API: combina la simplicidad de Chat Completions API con las capacidades de uso de herramientas de Assistants API
- Herramientas integradas: web search, file search, computer use
- Agents SDK: orquesta flujos de trabajo de agentes individuales y multiagente
- Herramientas de observabilidad: rastrean e inspeccionan la ejecución de flujos de trabajo de agentes
Responses API
- Responses API es la nueva unidad base de API para crear agentes usando las herramientas integradas de OpenAI
- Combina la simplicidad de Chat Completions con las capacidades de uso de herramientas de Assistants API
- En una sola llamada a Responses API se pueden usar múltiples herramientas y varios turnos de modelo para manejar tareas más complejas
- Las herramientas admitidas inicialmente son las siguientes
- Búsqueda web
- Búsqueda de archivos
- Uso de computadora
- También incluye mejoras de usabilidad
- Diseño unificado basado en items
- Polimorfismo más simple
- Eventos de streaming intuitivos
- Helpers del SDK como
response.output_text
- Está diseñada para desarrolladores que quieren combinar modelos de OpenAI y herramientas integradas en sus apps sin integrar por separado varias API o proveedores externos
- Al almacenar datos en OpenAI, las funciones de seguimiento y evaluación facilitan la evaluación del rendimiento de los agentes
- OpenAI no usa datos empresariales para entrenar modelos de forma predeterminada, incluso cuando los datos están almacenados en OpenAI
- Está disponible desde hoy para todos los desarrolladores y no tiene cobro adicional; los tokens y herramientas se cobran con las tarifas estándar de la página de precios
- La documentación inicial está disponible en la guía de inicio rápido de Responses API
Relación con las API existentes
- Chat Completions API seguirá recibiendo soporte como la API más adoptada de OpenAI
- Los desarrolladores que no necesiten herramientas integradas podrán seguir usándola
- Los nuevos modelos para funciones que no dependen de herramientas integradas ni de múltiples llamadas a modelos seguirán lanzándose también en Chat Completions
- Responses API es un superconjunto de Chat Completions y ofrece el mismo rendimiento, por lo que se recomienda Responses API para nuevas integraciones
- La retroalimentación de la beta de Assistants API se reflejó en Responses API, haciéndola más flexible, rápida y fácil de usar
- Se está trabajando para lograr paridad funcional completa entre Assistants API y Responses API, incluidos objetos tipo Assistant, objetos tipo Thread y la herramienta Code Interpreter
- Una vez completada la paridad funcional, se planea anunciar oficialmente la descontinuación de Assistants API
- La fecha objetivo de finalización es mediados de 2026
- Al anunciar la descontinuación, se ofrecerá una guía de migración que permita conservar datos y trasladar aplicaciones
- Hasta antes del anuncio oficial de descontinuación, se seguirán ofreciendo nuevos modelos también en Assistants API
- OpenAI posiciona a Responses API como la dirección futura para crear agentes en OpenAI
Herramientas integradas de Responses API
-
Búsqueda web
- Los desarrolladores pueden obtener respuestas rápidas y actualizadas desde la web con citas claras de las fuentes
- En Responses API, la búsqueda web se ofrece como herramienta al usar
gpt-4oygpt-4o-mini, y puede usarse junto con otras herramientas o llamadas a funciones - En las pruebas iniciales, los casos de uso aparecieron en apps que requieren información web actualizada, como asistentes de compras, agentes de investigación y agentes de reserva de viajes
- Hebbia usa la herramienta de búsqueda web para ayudar a gestores de activos, firmas de capital privado y crédito, y profesionales legales a extraer rápidamente insights accionables de grandes conjuntos de datos públicos y privados
- La búsqueda web de la API se basa en el mismo modelo usado en ChatGPT search
- En SimpleQA, GPT‑4o search preview registró 90% de precisión y GPT‑4o mini search preview registró 88%
- Las respuestas de búsqueda web de la API incluyen enlaces a fuentes como artículos de noticias y publicaciones de blogs
- Los sitios web o publishers pueden optar por aparecer en la búsqueda web de la API
- La herramienta de búsqueda web está disponible en vista previa para todos los desarrolladores en Responses API
- En Chat Completions API, se puede acceder directamente a los modelos de búsqueda mediante
gpt-4o-search-previewygpt-4o-mini-search-preview - Los precios comienzan en 30 dólares por cada 1,000 consultas para GPT‑4o search y 25 dólares por cada 1,000 consultas para 4o-mini search
-
Búsqueda de archivos
- La herramienta file search mejorada permite buscar fácilmente información relevante en documentos a gran escala
- Admite varios formatos de archivo, optimización de consultas, filtrado por metadatos y reranking personalizado
- En Responses API se puede integrar con unas pocas líneas de código
- Los casos de uso incluyen
- Un agente de soporte al cliente accede a una FAQ
- Un asistente legal consulta rápidamente casos anteriores para profesionales calificados
- Un agente de programación consulta documentación técnica
- Navan usa file search en su agente de viajes basado en IA para ofrecer rápidamente respuestas precisas a partir de documentos de bases de conocimiento, como políticas de viaje de la empresa
- La optimización de consultas y el reranking integrados permiten configurar un pipeline RAG sin ajustes ni configuración adicionales
- Al tener almacenes vectoriales dedicados por grupo de usuarios, se pueden ofrecer respuestas ajustadas a la configuración de la cuenta y los roles de usuario
- file search está disponible para todos los desarrolladores en Responses API
- El precio por uso es de 2.50 dólares por cada 1,000 consultas; el almacenamiento de archivos cuesta 0.10 dólares por GB por día, con el primer GB gratis
- También seguirá disponible en Assistants API
- Se agregó un nuevo endpoint de búsqueda a los objetos de Vector Store API, que permite consultar directamente datos para usarlos en otras aplicaciones y API
-
Uso de computadora
- La herramienta computer use es una función de Responses API para crear agentes que realizan tareas en una computadora
- Esta herramienta está impulsada por el modelo Computer-Using Agent(CUA) que hizo posible Operator
- El modelo de vista previa de investigación registró los siguientes resultados en benchmarks
- OSWorld: 38.1% en tareas generales de uso de computadora
- WebArena: 58.1%
- WebVoyager: 87% en interacciones basadas en la web
- La herramienta integrada computer use captura acciones de mouse y teclado generadas por el modelo
- Los desarrolladores pueden convertir estas acciones en comandos ejecutables en su propio entorno para automatizar tareas de uso de computadora
- Los casos de uso incluyen la automatización de flujos de trabajo basados en navegador, como control de calidad de apps web e ingreso de datos entre sistemas legacy
- Unify usa la herramienta computer use en un sistema para crecimiento de ingresos donde los agentes interpretan intención, investigan cuentas y contactan compradores
- Los agentes también pueden aprovechar información a la que no se podía acceder mediante API
- Por ejemplo, una empresa de administración inmobiliaria puede verificar mediante mapas en línea si un negocio está ampliando su superficie inmobiliaria
- Luminai integró la herramienta computer use para automatizar flujos de trabajo operativos complejos en grandes empresas con sistemas legacy sin API ni datos estandarizados
- En un piloto con una gran organización de servicios comunitarios, automatizó en cuestión de días el procesamiento de solicitudes y el proceso de registro de usuarios
- Para RPA tradicional habría sido difícil lograr la misma tarea incluso tras meses de intentos
- Antes de lanzar CUA en Operator, se realizaron extensas pruebas de seguridad y red teaming en tres áreas: uso indebido, errores del modelo y riesgos de frontera
- También se realizaron evaluaciones de seguridad adicionales y red teaming para abordar los riesgos de extender las funciones de Operator a sistemas operativos locales mediante CUA en la API
- También se agregaron mitigaciones para desarrolladores
- Controles de seguridad contra prompt injection
- Prompts de confirmación para tareas sensibles
- Herramientas para ayudar al aislamiento del entorno
- Detección mejorada de posibles violaciones de políticas
- Aunque las mitigaciones reducen el riesgo, el modelo puede cometer errores no intencionales, especialmente en entornos que no sean de navegador
- El rendimiento de 38.1% en OSWorld indica que aún no tiene alta confiabilidad para automatizar tareas de sistema operativo, por lo que en estos casos se recomienda supervisión humana
- Los detalles del trabajo de seguridad específico de la API se pueden consultar en la system card actualizada
Agents SDK y orquestación de flujos de trabajo
- Los agentes necesitan no solo lógica central y acceso a herramientas, sino también orquestación de flujos de trabajo
- El nuevo Agents SDK de código abierto simplifica la orquestación de flujos de trabajo multiagente
- Mejora el SDK experimental Swarm presentado el año pasado
- Sus principales funciones son
- Agents: LLM fáciles de configurar con instrucciones claras y herramientas integradas
- Handoffs: transfieren de forma inteligente el control entre agentes
- Guardrails: controles de seguridad configurables para validar entradas y salidas
- Tracing & Observability: visualiza el seguimiento de ejecuciones de agentes para apoyar la depuración y optimización de rendimiento
- Los casos de uso reales aplicables incluyen automatización de soporte al cliente, investigación de múltiples pasos, generación de contenido, revisión de código y prospección de ventas
- Coinbase usó Agents SDK para prototipar y desplegar rápidamente AgentKit, que permite a agentes de IA interactuar con billeteras de criptomonedas y actividad on-chain
- En cuestión de horas integró acciones personalizadas del Developer Platform SDK en un agente completamente funcional
- La arquitectura simplificada de AgentKit facilita agregar nuevas acciones de agentes
- Box creó en pocos días un agente que utiliza búsqueda web y Agents SDK para permitir buscar, consultar y extraer insights de datos no estructurados dentro de Box y de fuentes públicas de internet
- Los clientes empresariales pueden buscar no solo información actualizada, sino también datos internos propietarios de una forma que respeta permisos internos y políticas de seguridad
- Por ejemplo, una empresa de servicios financieros puede crear un agente personalizado que combine análisis de mercado internos almacenados en Box con noticias y datos económicos en tiempo real de la web
- Agents SDK funciona con Responses API y Chat Completions API
- También puede usarse con modelos de otros proveedores si ofrecen endpoints de API al estilo Chat Completions
- Puede integrarse de inmediato en bases de código Python, y el soporte para Node.js estará disponible próximamente
- En el diseño de Agents SDK, OpenAI se inspiró en el trabajo de Pydantic, Griffe y MkDocs
- OpenAI planea seguir construyendo Agents SDK como un framework de código abierto para que la comunidad pueda ampliar el enfoque
Dirección para expandir la plataforma de agentes
- OpenAI considera que los agentes pronto serán un componente clave de la fuerza laboral y aumentarán significativamente la productividad en todas las industrias
- A medida que crece la demanda de las empresas por usar IA en tareas complejas, se enfoca en ofrecer componentes que permitan a desarrolladores y empresas crear sistemas autónomos con impacto real
- Este lanzamiento es el primer conjunto de componentes para facilitar la creación, despliegue y escalamiento de agentes de IA confiables y de alto rendimiento
- A medida que las capacidades de los modelos evolucionen hacia un comportamiento más agentivo, OpenAI seguirá invirtiendo en integraciones más profundas en todas sus API y en nuevas herramientas que ayuden a desplegar, evaluar y optimizar agentes en producción
- El objetivo es ofrecer una experiencia de plataforma fluida para crear agentes que puedan ayudar con una amplia variedad de tareas en cualquier industria
1 comentarios
Opiniones en Hacker News
No sé qué tanto ayudan estos cambios de API a los desarrolladores que quieren integrar OpenAI en productos reales.
En mi caso, las máquinas de estado administradas por el proveedor para manejar conversaciones, mensajes, entrega de prompts, etc., terminaron siendo insuficientes, haciendo demasiadas suposiciones o estorbando.
Al final termino usando la Chat Completions API solo con salida estructurada activada, y aun dentro de eso hago bastante uso de herramientas, conversaciones recursivas, RAG, etc.
No veo valor en delegar a un tercero la gestión del estado de mi “agente”; es mucho más autónomo mantener ese tipo de cosas localmente.
El punto central es simplemente que metes cierto literal de cadena en una caja negra y recibes una nueva cadena, idealmente en el formato pedido, como JSON.
Si te enfocas en componer la cadena adecuada cada vez, todo lo demás desaparece, y se vuelve como generar una cadena altamente estructurada a partir del estado de negocio de una base de datos.
En la práctica es lo mismo que renderizar del lado del servidor una página web con PHP; la verdadera diferencia es solo la forma de entrega.
Todavía no he encontrado un framework de agentes que agregue lo que necesito encima de una simple llamada de generación estructurada.
La mayoría de las solicitudes a LLM deberían ser “entrada de prompt, salida estructurada”, y eso también encaja con la filosofía Unix de hacer una sola cosa bien.
Los frameworks de agentes son demasiado prematuros; no son más que una capa que abstrae un conjunto de patrones de diseño que aún no son comunes.
Solo deberíamos crear abstracciones cuando sea evidente que todos están reinventando la rueda; con los agentes no hay ninguna rueda que inventar, todo son simples llamadas a modelos de lenguaje.
Suelo decir que “el modelo de lenguaje debería ser la parte menos interesante del código”.
La mayor parte del tiempo debería dedicarse a crear el software y las herramientas reales, y el LLM debería ser un componente pequeño del software.
Para mi gusto, los frameworks de agentes hacen que la presencia del modelo de lenguaje sea demasiado grande en la base de código.
Incluso la abstracción de function calling de OpenAI alucina parámetros y esquemas, y JSON Schema en sí es tan verboso que, apenas se vuelve un poco más complejo que cinco llamadas a funciones muy simples, todo se viene abajo.
Parece que están apilando más cosas sobre una abstracción de caja negra que ya está rota, y no sirve de mucho para aplicaciones reales.
Puede ayudar a crear rápido una pequeña app de prueba de concepto.
Hay que ser ingenuo para construir una empresa sobre estas API.
Los LLM serán commodities, y OpenAI no tiene más opción que luchar contra ese destino si quiere justificar su valuación y el nivel de inversión que seguirá necesitando.
Si construiste sobre la Assistant API, toma la indirecta y no lo reescribas simplemente con la Responses API: debes ser dueño de tu propio producto.
Por ahora conviene envolver los LLM en una caja negra.
Es por la parte que dice: “Al usar Chat Completions, el modelo siempre obtiene información de la web antes de responder. Para hacer que modelos como gpt-4o y gpt-4o-mini llamen a web_search_preview como herramienta solo cuando sea necesario, migra a la Responses API”.
Portar a la nueva Responses API no es sencillo, y nosotros ya tenemos historial, RAG y lo necesario para los asistentes.
He desarrollado varios agentes usando solo function calling y salida estructurada, y llevan más de un año corriendo en producción.
Antes ni siquiera llamábamos agente a esto.
Esto parece dirigido a quienes ya usan frameworks de agentes junto con la API de OpenAI.
Hay un buen hilo de Twitter donde el diseñador de la nueva API explica el trasfondo de varias decisiones de diseño: https://twitter.com/athyuttamre/status/1899541471532867821
También hay un enlace alternativo para quienes no hayan iniciado sesión en Twitter: https://nitter.net/athyuttamre/status/1899541471532867821
Estos intentos de agentes de IA parecen errar desde lo fundamental.
Es porque intentan reemplazar a las personas en los sistemas existentes, en vez de crear una forma nueva de hacer las cosas.
La economía, la vida y todo lo demás tratan, en última instancia, de interacciones entre personas, así que es fundamentalmente miope.
El enfoque actual de los agentes de IA parece una variación del chiste de que “una IA expande una oración en un correo largo y convincente, y la IA del receptor vuelve a resumir ese correo largo en una sola oración”.
Entiendo la utilidad de automatizar tareas de los sistemas existentes, pero la verdadera oportunidad está en eliminar la mayor parte de esos sistemas.
Los humanos no son tan malos.
Me pregunto si de verdad el camino hacia adelante es crear UI para humanos con IA y luego hacer que otra IA opere esa UI.
¿Cuántas canastas hechas con ramas dobladas a mano usas?
La historia muestra que lo que se puede automatizar se automatiza, y lo que puede hacerse más barato o más rápido también termina haciéndose así.
Por ejemplo, en el ecosistema de B2B SaaS, como una experiencia de usuario asistida que permita a usuarios avanzados dentro de una organización macroautomatizar la configuración de clientes y tareas de gestión de proyectos.
Si la abstracción, el contexto y el conjunto de usuarios están bien acotados, el uso de herramientas puede ser bastante estable.
Algo que falta notablemente: Model Context Protocol
https://www.anthropic.com/news/model-context-protocol
Los agentes siempre necesitan algún tipo de protocolo de comunicación, y el mundo de los frameworks agénticos es un mar de logos, así que sin estándares abiertos se vuelve difícil.
Ahora estoy en Comet, también trabajé directamente en una implementación de MCP y contribuí al Agent SDK con integración nativa y mejoras en el suite de pruebas.
https://github.com/comet-ml/opik-mcp
https://github.com/openai/openai-agents-python/pull/91
Lanzamos la integración reciente el primer día.
https://www.comet.com/docs/opik/tracing/integrations/openai_...
Creo que el punto central hacia el que va OpenAI es ofrecer simplicidad a los desarrolladores mediante componentes fáciles de usar.
No voy a hablar de estrategia ni de precios, pero desde el punto de vista de un desarrollador, al verlo por primera vez, el enfoque modular simple del SDK y la ausencia de relleno se sienten refrescantes.
Esto no es de propósito general; es para usar llamadas a herramientas de mcp.run con modelos de OpenAI.
Aun así, no dar soporte directo a MCP es casi una de las jugadas más hostiles para los desarrolladores, y viniendo de OpenAI no sorprende.
Sería excelente que lo agregaran.
A la pregunta “¿El Agents SDK soporta conexiones MCP? ¿Se pueden dar herramientas fácilmente a un agente específico mediante una conexión cliente-servidor MCP?”, la respuesta fue: “Como puedes definir las herramientas que quieras, puedes implementar herramientas MCP con function calling”.
En resumen, hay que hacer uno mismo un poco de trabajo de plomería.
Issue relacionado: https://github.com/openai/openai-agents-python/issues/23
Soy swyx.
Tuve tiempo de ver con anticipación toda la nueva API con el equipo de API/DX y hacerles preguntas frecuentes.
https://latent.space/p/openai-agents-platform
El punto interesante es si ahora, dado que las respuestas se almacenan gratis por defecto, se puede abusar de la Responses API como si fuera una base de datos.
También hay preguntas que a la gente de HN le podrían gustar.
Hiperparámetros de la búsqueda web, es decir, cómo ajustar la profundidad y la amplitud de la búsqueda al crear un Deep Research casero.
Ahora que OAI ofrece RAG y reranking de forma nativa como parte de la Responses API, ¿cuándo conviene crear tu propio RAG?
Personalmente creo que alguien debería hacer un benchmark del rendimiento RAG de la Files API. La impresión de la comunidad no parece haberse actualizado mucho desde el primer lanzamiento de la Assistants API.
La diferencia entre Agents SDK y OAI Swarm es, a grandes rasgos, tipos, tracing y LLM intercambiable.
También me pregunto si el fine-tuning de
search-previewycomputer-use-previewse fusionará en GPT5.0 - https://ai.pydantic.dev/
Una de las razones principales para crear uno mismo este tipo de herramienta de búsqueda con IA es poder controlar por completo la profundidad y la amplitud, y también personalizar los loaders para los datos o sitios que quieras.
La búsqueda web actual no es transparente sobre qué sitios no tienen texto completo y en cuáles solo se usan snippets.
Tener computer use y búsqueda web juntos sin duda es potente. En esencia, es algo como Deep Research de OpenAI.
En la presentación no revelaron los precios
Muy probablemente porque sabían que sería carísimo
Búsqueda web [0]: GPT‑4o search y 4o-mini search cuestan $30 y $25 por cada 1,000 consultas, respectivamente
Búsqueda de archivos [1]: $2.50 por cada 1,000 consultas; almacenamiento de archivos a $0.10/GB/día; el primer GB es gratis
Herramienta de uso de computadora (modelo computer-use-preview) [2]: $3 por 1 millón de tokens de entrada y $12 por 1 millón de tokens de salida
[0] https://platform.openai.com/docs/pricing#web-search
[1] https://platform.openai.com/docs/pricing#built-in-tools
[2] https://platform.openai.com/docs/pricing#latest-models
No termino de ver en qué es mejor esta API que https://www.anthropic.com/news/model-context-protocol
La motivación parece haber sido más “cómo ganamos más dinero” que “cómo somos más útiles para los usuarios”
Me gusta, movimiento audaz
Para cuando la gente lenta de Google por fin se ponga al día, tal vez ya sea demasiado tarde para Google
También escribí un script que busca en la web y funciona bastante bien. Usa vercel ai sdk [1]
[0] - https://brave.com/search/api/
[1] - https://gist.github.com/bramses/41e90b27d156590154bcefd4119f...
Creé yo mismo una versión mucho más simple y potente que la Responses API, y funciona con todos los proveedores de LLM
https://github.com/Anilturaga/aiide
Se ve bien, realmente promete
Hay una frase que dice: “Tenemos previsto anunciar formalmente la descontinuación de la Assistant API, con una fecha objetivo de cierre a mediados de 2026”
La nueva Responses API es un paso en la dirección correcta, incluso con una función integrada de “handoff”
Aun así, para casos de uso de agentes todavía se siente algo limitada y le faltan guardrails y lógica de máquina de estados oficiales
Dijeron que “el objetivo es ofrecer una experiencia de plataforma fluida para que los desarrolladores puedan crear agentes”, así que será interesante ver cómo se migra a esta plataforma
Creo que en unos meses veremos flujos de control basados en grafos
Incluso ahora hay innumerables soluciones open source, pero la mayoría se queda corta o agrega opacidad y complejidad innecesarias
Con una combinación de llamadas a herramientas y respuestas JSON ya era posible crear flujos de tipo agente, pero falta un componente de nivel superior que todavía nadie ha resuelto bien
Me impresionan los avances de Computer Use mencionados aquí, así que me pregunto si ya está lo bastante maduro como para usarlo en pruebas de usabilidad
En general, si una UI es difícil de navegar para una IA, ¿podría tomarse como una señal de que probablemente también es relativamente difícil para una persona y que habría que simplificarla o mejorarla de alguna forma?
La forma en que un LLM interactúa con una UI es muy distinta de la forma en que los humanos usan una UI
El Agents SDK enlazado da 404
Como referencia, MindRoot tiene algo similar a Responses y a parte de File Search usando la task API: https://github.com/runvnc/mindroot/blob/main/api.md
Esto se puede combinar con la herramienta query_kb del plugin mr_kb y permite buscar en varias KB, así que en realidad podría ser mejor que File Search
Si alguien quiere ayudar con mi programa, crear plugins o enviar PR, puede contactarme sin problema por GitHub, email o Discord/Telegram (runvnc)
Tal vez sea porque inicié sesión