Open Responses: estándar abierto de inferencia para Agents | Keryc
Open Responses llega como un estándar abierto para inferencia pensado específicamente para la era de los agentes autónomos. Viene iniciado por OpenAI y desarrollado por la comunidad open source con el ecosistema de Hugging Face, y busca reemplazar las limitaciones de los formatos de chat tradicionales.
Qué es Open Responses
Open Responses es una especificación abierta basada en la Responses API (lanzada en 2025) que unifica cómo los modelos generan texto, imágenes, JSON estructurado y videos, y cómo ejecutan bucles agenticos que invocan herramientas y devuelven resultados finales.
¿Por qué importa? Porque la mayoría del ecosistema aún usa formatos diseñados para conversaciones por turnos, y eso no se adapta bien a sistemas que deben razonar, planear y actuar durante largos horizontes temporales. Open Responses propone un formato estandarizado, extensible y más adecuado para estos flujos.
Diseño y cambios técnicos clave
Stateless por defecto: el estándar asume peticiones independientes, con soporte para razonamiento cifrado cuando el proveedor lo requiere.
Parámetros de configuración estandarizados: facilita interoperabilidad entre modelos y proveedores.
Streaming definido como eventos semánticos: no es solo texto delta; los streams describen eventos como razonamientos, llamadas a herramientas y estados.
Extensible: permite parámetros específicos por proveedor para cubrir diferencias prácticas sin romper la compatibilidad.
Streaming y razonamiento
Open Responses sustituye "reasoning_text" por chunks extendibles de reasoning. El streaming ya no es simplemente enviar fragmentos de texto: se transmiten eventos con tipo, secuencia y metadatos que mejoran observabilidad y replicabilidad.
Ejemplo de petición vía proxy (curl):
curl https://evalstate-openresponses.hf.space/v1/responses \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $HF_TOKEN" \
-H "OpenResponses-Version: latest" \
-N \
-d '{
"model": "moonshotai/Kimi-K2-Thinking:nebius",
"input": "explain the theory of life"
}'
Open Responses distingue claramente dos categorías de herramientas:
Internas: corren dentro de la infraestructura del proveedor (por ejemplo, búsquedas de archivos o integraciones de Drive). El proveedor ejecuta la llamada y alimenta el resultado al modelo sin que el desarrollador haga la ejecución manual.
Externas: funciones o servidores hospedados fuera del proveedor, ejecutadas por el cliente o por infraestructuras externas.
Esta separación permite que los proveedores optimicen loops internos y que los routers orquesten llamadas entre diferentes upstreams.
Bucle agentico estandarizado
La especificación formaliza el bucle: muestreo del modelo, emisión de llamadas a herramientas, ejecución de la herramienta (interna o externa), retroalimentación de resultados al modelo y repetición hasta completar la tarea. Para control, el cliente puede usar parámetros como max_tool_calls y tool_choice:
{
"model": "zai-org/GLM-4.7",
"input": "Find Q3 sales data and email a summary to the team",
"tools": [...],
"max_tool_calls": 5,
"tool_choice": "auto"
}
La respuesta incluye todos los items intermedios: llamadas a herramientas, resultados y razonamientos, lo que facilita auditoría y depuración.
Migración: clientes, proveedores y routers
Clientes: la migración desde Responses a Open Responses suele ser de bajo esfuerzo si ya soportas Responses. Cambios principales: adoptar chunks de reasoning y manejar payloads de estado más ricos (por ejemplo, estados específicos para interpretes de código).
Proveedores de modelo: si ya cumplen Responses, la transición es directa; deben soportar los nuevos eventos semánticos y parámetros estandarizados.
Routers (intermediarios): ganan la oportunidad de normalizar endpoints y exponer opciones de configuración por proveedor para personalización sin romper compatibilidad.
Con el tiempo, funciones útiles tenderán a estandarizarse en la especificación base, reduciendo la fragmentación que existe hoy por extensiones no documentadas.
Implicaciones para seguridad, observabilidad y operaciones
Observabilidad mejorada: los eventos semánticos y estados intermedios permiten trazar pasos del razonamiento y de las llamadas a herramientas.
Privacidad y cifrado: el modo stateless y el soporte para razonamiento cifrado facilitan cumplir requisitos regulatorios de algunos proveedores.
Control de costos y latencia: los routers pueden limitar max_tool_calls y escoger proveedores según latencia o coste, esencial en producción.
Desde mi experiencia orquestando pipelines de búsqueda y resumen, tener todos los pasos (búsqueda, resumen, redacción) dentro de una sola petición reduce complejidad de infraestructura y facilita trazabilidad. Open Responses apunta precisamente a ese tipo de flujo.
Recomendaciones prácticas para desarrolladores técnicos
Empezar por probar la versión de acceso temprano en Hugging Face para validar tu stack actual.
Adaptar clientes para consumir eventos response.reasoning.* y almacenar items intermedios para auditoría.
Definir límites (max_tool_calls) y políticas de selección de herramientas antes de poner agentes en producción.
Evaluar necesidades de cifrado si trabajas con datos sensibles y priorizar proveedores que ofrezcan encrypted reasoning.
Open Responses no es solo otra API: es un intento por alinear interfaces con las necesidades reales de agentes autónomos y la interoperabilidad entre proveedores. Si trabajas con agentes, vale la pena explorar la especificación y planear la migración.