La tabla es un punto de partida. El contrato real de su aplicación puede incluir comportamientos que no aparecen en los objetos de OpenAI, como permisos, límites por cliente, deduplicación, auditoría y confirmación antes de realizar acciones.
No se limite a copiar el texto de las instrucciones. Un Asistente puede depender de los recursos en tool_resources, un esquema estructurado o la lógica aplicada durante la creación de la ejecución.
Transforme este conjunto en una configuración versionada en el repositorio. Cada cambio debe ser revisado, probado y posible volver a la versión anterior.
| Identidad interna |
heredado |
Nuevo |
| Usuario o cuenta |
ID propio |
ID propio |
| Sesión o servicio |
thread_id |
conversation_id |
| Mensaje |
message_id |
ID del artículo |
| Ejecución |
run_id |
response_id |
| Versión conductual |
id_asistente |
Versión de configuración |
| Base documental |
vector_store_id |
vector_store_id validado |
La API Threads funciona recuperando objetos por thread_id. En la práctica, la base de datos y los registros de la aplicación deben tratarse como el catálogo de subprocesos que deben migrarse o archivarse.
El inventario debe incluir todas las páginas de mensajes, no solo el primer lote devuelto por la API. Regístrate también:
- orden cronológico;
- papel del autor;
- textos, imágenes y archivos;
- adjuntos;
- notas y citas;
- metadatos;
- relaciones con ejecuciones;
- Mensajes incompletos o de error.
Herramientas y recursos persistentes
Listar por separado:
- funciones propias y sus esquemas;
- servicios externos llamados por funciones;
- efectos secundarios como envío, compra o cambio de registro;
- archivos cargados;
- almacenes de vectores y archivos contenidos en ellos;
- resultados producidos por Code Interpreter;
- webhooks;
- analizadores de transmisión;
- políticas de retención y eliminación.
El inventario se completa solo cuando cada recurso antiguo tiene un destino, una decisión de eliminación documentada o un trabajo pendiente que bloquea el recorte.
Cómo conservar conversaciones
La API de Conversaciones mantiene un objeto duradero que se puede reutilizar en todas las sesiones, dispositivos o tareas. Una conversación almacena elementos que pueden representar mensajes, llamadas a herramientas, resultados y otros datos.
OpenAI informa que no habrá una herramienta automática para convertir Hilos en Conversaciones. La guía oficial es dirigir los chats nuevos a Conversaciones y migrar los antiguos según sea necesario. La guía también presenta un ejemplo de relleno que pagina los mensajes de un hilo en orden ascendente, convierte el contenido en elementos y crea una conversación.
Una estrategia segura consta de cuatro pasos.
1. Deja de crear nueva deuda
Una vez validada la ruta de Respuestas, reenvíe nuevas conversaciones directamente a la API de Conversaciones. Registre inmediatamente la relación entre la identidad interna de la sesión y el nuevo id_conversación.
2. Convertir el historial bajo demanda
Al abrir una conversación antigua:
- busca el thread_id;
- recuperar todas las páginas de mensajes;
- convertir tipos de contenido aceptados;
- crear la conversación;
- registrar la correspondencia entre los dos ID;
- verifique el recuento, el orden y el contenido antes de publicar la respuesta.
Este proceso debe ser idempotente: dos intentos en el mismo hilo no pueden crear dos conversaciones independientes.
El ejemplo de relleno oficial cubre texto e imagen por URL. Las integraciones que utilizan archivos de imágenes, archivos adjuntos, anotaciones, resultados de herramientas o formatos propietarios deben ampliar el convertidor y probar cada tipo por separado.
3. Conserva una copia canónica
No dependa de la disponibilidad futura de puntos finales antiguos para reconstruir el historial. Antes del cierre, conserva en tu propio almacenamiento el contenido necesario para su continuidad, auditoría y recuperación, de acuerdo con tu base legal y política de retención.
Esta copia debe registrar la fuente y la versión del convertidor.. No es necesario reproducir todos los detalles internos de OpenAI, pero debería ser suficiente para reconstruir la experiencia del usuario.
4. Revisar la retención y la privacidad
Las respuestas almacenadas tienen, de forma predeterminada, retención del estado de la aplicación durante 30 días. Las conversaciones y sus elementos permanecen hasta que se eliminan y no son elegibles para la Retención Cero de Datos. Los elementos de una respuesta asociada a una conversación se conservan sin el límite estándar de 30 días.
La elección entre conversaciones, subprocesos por id_respuesta_anterior o historial autoadministrado debe considerar la privacidad, la eliminación, la residencia de datos, la auditoría y los requisitos contractuales, no solo la conveniencia técnica.
Cómo migrar herramientas
Llamada a función
En el modelo antiguo, una ejecución podía ingresar require_action. En la API de Responses, la salida contiene elementos de llamada de función. La aplicación identifica cada llamada, ejecuta la función correspondiente y devuelve un elemento function_call_output con el mismo call_id. El bucle de herramientas pasa a ser responsabilidad explícita de la aplicación.
Las pruebas deben verificar:
- nombre de la función;
- validez de los argumentos;
- campos faltantes o inesperados;
- llamadas paralelas;
- tiempo de espera;
- repetición de la misma acción;
- manejo de errores;
- confirmación para operaciones irreversibles.
La documentación recomienda esquemas en modo estricto. En este modo, los objetos deben declarar propiedades adicionales: falso y marcar los campos definidos como obligatorios, usando nulo cuando un valor puede ser opcional.
Búsqueda de archivos
file_search continúa utilizando los almacenes de vectores tanto en la API de Asistentes como en la API de Respuestas. En lugar de depender del enlace mantenido en el Asistente o Hilo, la nueva solicitud informa vector_store_ids en la configuración de la herramienta.
Antes de cortar, pruebe:
- acceso al mismo almacén de vectores;
- cantidad y estado de los expedientes;
- calidad de las respuestas;
- presencia de citas;
- filtros por metadatos;
- permisos por usuario;
- comportamiento cuando no se encuentran resultados.
Los resultados de búsqueda completos no se incluyen de forma predeterminada. Para observabilidad y depuración, la API de Responses le permite solicitar file_search_call.results a través del parámetro de inclusión.
Intérprete de código
En la API de Respuestas, el intérprete de código utiliza un contenedor. Se puede crear de forma automática o explícita, con los archivos necesarios. Los contenedores deben tratarse como recursos efímeros: la documentación indica que caducan después de 20 minutos de inactividad y que sus datos no se pueden recuperar después de la expiración.
Nunca utilice el contenedor como almacenamiento definitivo. Los archivos producidos que deben permanecer disponibles deben copiarse al sistema de la aplicación mientras el contenedor está activo.
Procesos largos, sondeo y streaming
Las tareas cortas pueden utilizar respuestas sincrónicas. Para ejecuciones largas, el modo en segundo plano le permite realizar un seguimiento de estados como en cola e in_progress, recuperar la respuesta y cancelarla. Los webhooks pueden informar eventos como respuesta.completada.
La transmisión por secuencias también ha cambiado. La API de Responses emite eventos de tipo semántico, incluida la creación, deltas de texto, llamadas a herramientas, finalización y error. Los analizadores basados en eventos antiguos necesitan pruebas específicas; No basta con cambiar el punto final.
Matriz de pruebas de regresión
| Área |
Prueba |
Criterios de aceptación |
| Historial |
Migrar conversaciones paginadas largas |
Mismo orden, autoría y contenido relevante |
| Identidad |
Reabrir sesión en otro dispositivo |
Mismo id_conversación autorizado |
| Instrucciones |
Ejecutar conjunto de casos de referencia |
Comportamiento dentro de límites definidos |
| Funciones |
Forzar cada herramienta y escenario de error |
Argumentos válidos y efectos idempotentes |
| Búsqueda de archivos |
Consultar documentos conocidos y faltantes |
Recuperación y citas coherentes |
| Intérprete de código |
Generar y conservar un archivo |
Archivo copiado antes de que expirara el contenedor |
| Transmisión |
Detener y volver a conectar el cliente |
Interfaz consistente, sin duplicaciones |
| Fondo |
Completar, fallar y cancelar tareas |
Estados tratados sin bucle infinito |
| Seguridad |
Intenta acceder a la conversación de otro usuario |
Acceso denegado antes de la llamada API |
| Retención |
Eliminar usuario o conversación de prueba |
Datos eliminados por política |
| Observabilidad |
Correlacionar sesión, respuesta y herramienta |
Registros suficientes para el diagnóstico |
| Rendimiento |
Comparar latencia, tokens y costo |
Variación aceptada y documentada |
No se limite a comparar oraciones literales. Los modelos generativos pueden producir textos diferentes y aun así cumplir el mismo contrato. Evalúe hechos, formato, decisiones, llamadas de herramientas, seguridad y efecto final.
Plano de corte y inversión gradual
Coloque la nueva ruta detrás de un indicador de característica por cliente, usuario o sesión. Comience con el tráfico interno, avance a un grupo pequeño y amplíelo solo cuando las métricas permanezcan dentro de los límites definidos.
Durante el período de convivencia:
- no registrar la misma acción externa dos veces;
- mantener la correlación entre objetos antiguos y nuevos;
- comparar fallas, latencia, tokens y llamadas a herramientas;
- supervisar conversaciones sin mapeo;
- bloquear la eliminación de recursos heredados;
- preservar la capacidad de desactivar rápidamente la nueva ruta.
Antes del 26 de agosto, revertir temporalmente puede significar redirigir el tráfico a la integración heredada. Después del cierre, esta deja de ser una estrategia válida. El plan posterior a la fecha límite debe recurrir a una versión anterior y estable de la implementación en Responses, utilizando el estado canónico almacenado por la aplicación.
Horario sugerido para los 23 días restantes
- 3-6 de agosto: Inventario, exportación y congelación de nuevos recursos heredados.
- 7 al 13 de agosto: implementación de Conversaciones, Respuestas y adaptadores de herramientas.
- 14 al 19 de agosto: backfill controlado, pruebas de regresión y ejecución paralela sin efectos.
- 20 al 23 de agosto: recorte progresivo y corrección de divergencias.
- 24 y 25 de agosto: operación completa en la nueva ruta, con guardia y reversión entre versiones de Responses.
- 26 de agosto: ningún recorrido de producción debería depender de Asistentes, Hilos, Mensajes, Ejecuciones o Pasos de ejecución.
Esta línea de tiempo es una recomendación editorial, no un calendario oficial de OpenAI. Los equipos con alto volumen, requisitos regulatorios o herramientas que producen efectos externos deben anticipar los pasos y requerir aprobación técnica formal.
Lista de verificación de migración de API de Final Assistants
-
Se han identificado todos los asistentes en producción.
-
Las instrucciones, modelos, herramientas y esquemas están versionados en la aplicación.
-
La arquitectura final no se basa en mensajes reutilizables.
-
Todos los thread_ids conocidos están vinculados a usuarios o sesiones autorizados.
-
El historial requerido se ha exportado o convertido.
-
Las sesiones nuevas ya crean conversaciones.
-
El reabastecimiento es paginado, idempotente y auditable.
-
Se han probado textos, imágenes, archivos adjuntos y notas.
-
Las funciones validan argumentos y evitan efectos duplicados.
-
Los archivos y almacenes de vectores se han conciliado.
-
Los resultados de la búsqueda de archivos conservan citas y permisos.
-
Los archivos del intérprete de código se conservan fuera del contenedor.
-
Se han actualizado el sondeo, la cancelación, los webhooks y la transmisión.
-
Se han reevaluado la retención, la eliminación y la retención cero de datos.
-
Existen métricas comparables entre la ruta antigua y la nueva.
-
El corte está protegido por una bandera de característica.
-
Hay una reversión a una versión estable basada en las Respuestas.
-
Ningún flujo de producción dependerá de la API de Asistentes el 26 de agosto.
La migración finaliza cuando el sistema puede continuar una conversación, recuperar los recursos correctos, ejecutar herramientas de forma segura y explicar cada paso sin consultar la API heredada. Cambiar el punto final es solo el comienzo.
Actualizado el 3 de agosto de 2026. La documentación, los SDK y las características de la plataforma pueden cambiar antes de su publicación o edición.
Temas de este artículoConversations APIdesenvolvimento com IAferramentas de agentesmigração de APIsOpenAI APIResponses API
