Responses API-ra váltás: a Threads–Runs páros helyére új állapotmodell jön

Az Assistants API-ról a Responses API-ra való átállásnál először a régi objektumok szerepét kell megfeleltetni, majd külön megtervezni, hol marad meg a beszélgetés állapota. Az OpenAI migrációs útmutatója az Assistant helyére a Promptot, a Thread helyére a Conversationt, a Run helyére a Response-t, a Run steps helyére pedig az Items elemeket állítja. Az Assistants API már nem érhető el, így a régi végpontra épülő visszaállás nem működő tartalékút.

A biztonságos sorrend: készíts leltárt a konfigurációról, válassz állapotkezelési módot, a saját mentésedből vezesd át a szükséges előzményeket, majd alakítsd át az eszközhívást és a streaming feldolgozását. Végül egy teljes beszélgetésen ellenőrizd a folytatást, a tárolási beállítást és a hibából való helyreállást. Az első sikeres Response csak azt mutatja, hogy egy kérés lefutott; a migrációhoz a következő fordulónak is a megfelelő előzményből kell indulnia.

A konfigurációt válaszd el a beszélgetéstől

Írd össze minden korábbi Assistant modelljét, instrukcióit, eszközeit és elvárt kimeneti formátumát. Ugyanebben a leltárban jelöld azokat az alkalmazásútvonalakat, amelyek Threadet hoztak létre, Runt indítottak vagy Run steps elemeket olvastak. Az ellenőrizhető kimenet egy megfeleltetési lista: minden régi konfigurációhoz tartozik egy új konfiguráció és az azt használó alkalmazásfunkció.

A Prompt fogalmi megfelelő, nem csereszabatos Assistant-azonosító. Az újrahasználható Prompt a felületen hozható létre és verziózható, de az OpenAI a kivezetésére is figyelmeztet; hosszú életű integrációnál ezért érdemes eldönteni, hogy ilyen objektumra hivatkozol-e, vagy az alkalmazásodban tartod a konfigurációt. Ha strukturált kimenetre támaszkodsz, a régi séma helyét is ellenőrizd: a Responses kérésben a formátum a text.format alatt szerepel. Ez a lépés akkor kész, ha az új kérés ugyanazt a szándékolt viselkedést és kimeneti szerződést adja az alkalmazásnak.

Válassz állapotmodellt, aztán vezesd át az előzményt

A korábbi Thread szerepét nem minden integrációban egy új Conversation tölti be. A TheRouter átállási útmutatója három mintát különít el: folytatás a previous_response_id segítségével, tartós Conversation objektum használata, illetve a korábbi Items elemek alkalmazásoldali visszaküldése. A döntés azt határozza meg, ki őrzi az előzményt, és miből állítható helyre egy megszakadt beszélgetés.

A previous_response_id láncánál az alkalmazásnak meg kell őriznie az utolsó válasz azonosítóját; a korábbi kérés legfelső szintű instrukcióit a következő kérésben ismét át kell adni. A Conversation akkor illik a régi Thread feladatához, ha tartósan azonosítható, több alkalommal folytatható beszélgetés kell. Kézi állapotkezelésnél a bemeneti és kimeneti Items elemeket az alkalmazás tárolja, küldi vissza és szükség esetén rövidíti. Egy adott beszélgetés folytatását következetesen a választott minta szerint építsd fel; egy elveszett azonosítót csak akkor tudsz pótolni, ha máshol megmaradt a szükséges előzmény.

A régi Thread azonosítója önmagában nem viszi át az üzeneteket. A megszűnt Assistants API-n keresztül a Thread üzenetei már nem kérhetők le, ezért meglévő beszélgetést csak a korábban alkalmazásoldalon megőrzött adatokból lehet újraépíteni. Az üzenetek sorrendje és szerepe mellett ellenőrizd a képekre, fájlokra vagy más csatolmányokra mutató hivatkozásokat is; ami nincs meg a mentésben, azt ne tüntesd fel helyreállított előzményként. A próba kimenete egy folytatott párbeszéd, amelyben az új válasz a ténylegesen átadott korábbi fordulókra támaszkodik.

Az eszközhívásnak saját feldolgozási ága van

A Response kimenete típusos Items elemekből áll: egy szöveges üzenet és egy eszközhívás nem ugyanaz a kimenettípus. Az OpenAI Responses-átállási útmutatója a saját függvény hívását function_call kimeneti elemként, az eredményét pedig ugyanahhoz a call_id értékhez kötött function_call_output bemeneti elemként írja le. A feldolgozó ezért a response.output elemein járjon végig, és típus szerint döntse el, melyikből lesz felhasználói szöveg, illetve melyikhez kell külső művelet.

Egy feltételes rendeléslekérdezésnél a modell function_call elemet adhat vissza; az alkalmazás a kapott argumentumok alapján lefuttatja a saját lekérdezését, majd az eredményt a megfelelő call_id mellett adja át a következő kérésnek. Az elfogadási próba során a hívás, a külső eredmény és az utána születő válasz ugyanahhoz a művelethez kapcsolódjon. Időtúllépés után a saját rendszerednek azt is el kell döntenie, végrehajtódott-e már a művelet, mielőtt újraindítaná; ez különösen fontos, ha az eszköz írást vagy más mellékhatást végez.

A streaminget események, nem szövegtöredékek vezérlik

A Responses streamingje típusos eseményeket küld. A response.output_text.delta a megjeleníthető szöveg bővülését jelzi, a függvény argumentumai pedig saját delta és done eseményekben is érkezhetnek. A feldolgozó a response.completed eseménynél tekintse késznek a választ, az error és a hibás végállapot esetén pedig külön kezelje a megszakadást. A részleges argumentum ne indítson külső műveletet, és a félbeszakadt szöveg ne jelenjen meg végleges válaszként.

Próbálj ki olyan megszakítást is, amely a function_call beérkezése után történik. A visszacsatlakozáskor a helyben tárolt állapotból ki kell derülnie, elküldte-e már az alkalmazás az eszköz eredményét. Enélkül egy ismételt stream ugyanazt a műveletet újra elindíthatja, vagy eredmény nélkül hagyhatja a modell hívását. A naplóban a válasz azonosítója, az eseménytípusok, a call_id és a végállapot együtt adnak ellenőrizhető nyomot.

A tárolás és a visszaállás ugyanannak a döntésnek a része

A Responses alapértelmezés szerint tárolja a válaszokat; ha ez nem felel meg az adatkezelési követelménynek, a store: false beállítást és a kézi előzménykezelést együtt kell megtervezni. Állapot nélküli működésnél, ha a modell érvelési elemeit később is tovább kell vinni, a visszakapott titkosított reasoning Items elemeket is meg kell őrizni és vissza kell küldeni. Írd le, hol található a teljes beszélgetési történet, meddig őrzitek, ki törli, és melyik azonosító kell a következő fordulóhoz.

A kiadás előtti ellenőrzés fedjen le egyszerű választ, többfordulós folytatást, eszközhívást, megszakított streamet és hibás külső műveletet. Mindegyiknél rögzítsd a választott állapotazonosítót, a releváns Item típusokat, az eszközhívás és eredménye kapcsolatát, a végállapotot és a tárolási beállítást. Ha az új kiadás hibás, csak olyan korábban ellenőrzött Responses útvonalra irányítsd vissza a forgalmat, amely érti az addig megőrzött állapotot; az alkalmazásoldali előzménymentés teszi ezt a tervet végrehajthatóvá.

Olvassa el ezt is:

• Emberi jóváhagyás MI-ügynökben: a folytatható állapot a kulcs
• Az Adobe beköltözik a Geminibe és a Claude-ba – 80 eszköz jön egy chatbe
• Az X új Live API-ja a teljes közvetítést átadja külső eszközöknek