„Assistants API“ jau išjungta: migracijoje neužtenka pakeisti galinio adreso

2026 m. spalio 12 d. 04:00|Autorius: QUASA redakcija|5 min. skaitymo| 1

„Assistants API“ 2026 m. rugpjūčio 26 d. buvo išjungta, o oficialios migracijos gairės vietoj jos nurodo „Responses API“. Senai integracijai atkurti reikia pakeisti objektų modelį: „Thread“ pokalbio tęstinumą perkelti į „Conversation“ arba valdyti savo sistemoje, „Run“ logiką pakeisti „Response“, o įrankių rezultatus susieti su jų kvietimais.

Pradėkite nuo turimos konfigūracijos ir pokalbių istorijos inventoriaus, tada perkelkite paprastą atsakymą, būseną, funkcijų ciklą ir srautinį apdorojimą. Senų „Thread“ pranešimų po išjungimo nebegalima pasiimti per „Assistants API“, todėl ankstesnę istoriją į naują pokalbį galima perkelti tik tada, jei ją jau turite savo saugykloje.

Senų ir naujų objektų atitikmenys

Atitikmenys rodo, kurią programos dalį reikia perrašyti, tačiau senų identifikatorių vien pervadinti neužtenka. Ypač svarbu atskirti asistento konfigūraciją, pokalbio istoriją ir vieno atsakymo vykdymą: naujoje sąsajoje tai skirtingos atsakomybės.

Assistant → Prompt arba programos konfigūracija. Perkelkite modelio pasirinkimą, instrukcijas ir įrankių aprašus. „Prompt“ galima kurti valdymo skydelyje, tačiau daugkartinio naudojimo „Prompt“ objektų taip pat atsisakoma; ilgalaikei integracijai konfigūraciją verta versijuoti savo programoje.
Thread → Conversation. „Thread“ saugojo pranešimus, o „Conversation“ saugo tipizuotų elementų seką, įskaitant pranešimus ir įrankių veiksmus. Naudotojo arba sesijos įrašą susiekite su nauju „conversation“ ID; seno „thread_id“ perduoti vietoj jo negalima.
Run → Response. Nauja užklausa gauna „input“ elementus arba naudoja „Conversation“; grąžinamas „response“ objektas su „output“ elementais. Programa, kuri tikisi vieno „Run“ pranešimo, turi išmokti atskirti tekstą nuo įrankio kvietimo.
Run steps → Items. Pranešimas, funkcijos kvietimas ir jos rezultatas yra atskiri elementai. Jei istoriją perduodate patys, išsaugokite visą reikalingą seką, o ne vien naudotojui parodytą tekstą.
response_format → text.format. Struktūruotos išvesties schemą įrašykite į naują lauką ir pakeiskite vietą, iš kurios programa skaito rezultatą.

Prieš keisdami maršrutus užfiksuokite kiekvieno seno asistento instrukcijas, įrankių schemas ir taikytą modelį iš savo turimų įrašų. Tai leidžia vėliau palyginti ne vien galutinį atsakymą, bet ir tai, ar funkcija buvo iškviesta su tinkamais argumentais. Jei integracijoje buvo naudojami failai, jų ryšius ir prieigos taisykles įtraukite į tą patį inventorių.

Pokalbio būsena ir duomenų saugojimas

Ilgalaikiam pokalbiui sukurkite „Conversation“, o jos identifikatorių saugokite šalia savo naudotojo ar sesijos įrašo. Kitoje „Responses“ užklausoje perduokite tą patį „conversation“ ID. Turimus senus pranešimus perkelkite iš savo saugyklos, išlaikydami jų eilę, vaidmenis ir turinio tipus; vien senas „thread_id“ istorijos neatkurs.

Alternatyva yra būseną valdyti programoje: kiekvienai užklausai sudaryti reikalingą ankstesnių elementų seką. „previous_response_id“ leidžia tęsti ankstesnio atsakymo grandinę, bet pasirinkimas tarp jo, rankinio elementų perdavimo ir „Conversation“ priklauso nuo to, kur turi gyventi istorija. Rankiniame variante praleidus funkcijos kvietimą ar jos rezultatą gali nutrūkti kontekstas, reikalingas kitam atsakymui.

Pagal „OpenAI“ pokalbio būsenos gaires, „Response“ objektai pagal numatytąją tvarką saugomi 30 dienų, o jų saugojimą galima išjungti nustačius „store: false“. „Conversation“ objektams ir jų elementams ši 30 dienų riba netaikoma; su pokalbiu susieti atsakymo elementai lieka jame. Todėl „store: false“ nelaikykite būdu panaikinti „Conversation“ istoriją. Jei ji turi likti tik jūsų sistemoje, būseną perduokite rankiniu būdu ir atskirai nustatykite savo duomenų saugojimo taisykles.

Funkcijų kvietimai ir struktūruota išvestis

„Responses“ migracijos aprašas nurodo tris susijusius pakeitimus: funkcijos rezultatą susieti per „call_id“, struktūruotos išvesties schemą perkelti į „text.format“ ir srautą apdoroti pagal tipizuotus įvykius. Tai atskiros kodo vietos, todėl sėkminga paprasto tekstinio atsakymo užklausa dar neparodo, kad visa integracija perkelta.

Funkcijos kvietimas gaunamas kaip „function_call“ išvesties elementas su pavadinimu, argumentais ir „call_id“. Programai įvykdžius funkciją, jos rezultatą reikia pateikti kaip „function_call_output“ įvesties elementą su tuo pačiu „call_id“. Jei atsakyme yra keli kvietimai, kiekvieną rezultatą susiekite su jo kvietimu; vienas bendras rezultato pranešimas šio ryšio neišsaugo.

Prieš vykdydami funkciją tikrinkite jos argumentus ir taikykite turimas prieigos taisykles. Šalutinį poveikį turinčioms funkcijoms, pavyzdžiui, įrašą keičiančiam veiksmui, numatykite saugų pakartotinį bandymą savo programoje. Atskiras regresinis bandymas turi patvirtinti, kad „text.format“ schema grąžina programos laukiamą struktūrą ir kad kodas nebeskaito senų „Run“ ar „Message“ laukų.

Srautiniai įvykiai: kada rodyti tekstą ir vykdyti įrankį

„Responses“ srautas siunčia skirtingų tipų įvykius, todėl klientas turi skirstyti juos pagal „type“. Teksto rodymui svarbūs „response.created“, „response.output_text.delta“, „response.completed“ ir „error“. Vien sudėti visus gautus fragmentus į teksto eilutę nepakanka, nes sraute gali būti ir funkcijos argumentų.

Argumentai gali būti siunčiami per „response.function_call_arguments.delta“, o jų pabaigą žymi „response.function_call_arguments.done“. Funkciją vykdykite tik surinkę visus jos argumentus; dalinis JSON fragmentas dar nėra paruoštas kvietimas. Naudotojo sąsajoje atskirkite matomą tekstą nuo galutinės vykdymo būsenos, kad pasibaigęs teksto fragmentų srautas nebūtų palaikytas užbaigtu atsakymu.

Perjungimo seka ir regresiniai bandymai

Susirašykite senus maršrutus, asistentų konfigūraciją, turimus pranešimus, funkcijas, failus ir struktūruotos išvesties schemas. Atskirai pažymėkite pokalbius, kurių istorijos jūsų sistema neturi.
Perkelkite paprastą užklausą į „Responses“: sudarykite „input“, perskaitykite tipizuotą „output“ ir patikrinkite naudotojui rodomą tekstą. Tada prijunkite pasirinktą būsenos modelį ir išsaugokite naujo pokalbio identifikatorių.
Perkelkite įrankių schemas, „call_id“ ciklą, „text.format“ ir srautinių įvykių apdorojimą. Nukreipkite nedidelę naujų pokalbių dalį per šį kelią, stebėdami klaidas ir neužbaigtus funkcijų kvietimus.

Regresijos scenarijus turi apimti visą pokalbį, o ne vieną atsakymą. Po kelių žinučių ir sesijos pertraukos tas pats naudotojas turi tęsti savo istoriją, o kito naudotojo duomenys neturi būti prijungti. Bandant funkcijas patikrinkite argumentų schemą, kiekvieno rezultato „call_id“ ir pakartotinio kvietimo poveikį.

Atskirai patikrinkite, kur lieka pranešimai bei įrankių elementai pasirinkus „Conversation“, rankinę istoriją ir „store: false“. Srautiniame scenarijuje tekstas turi pasirodyti tinkama tvarka, daliniai argumentai neturi paleisti funkcijos, o užbaigimo arba klaidos įvykis turi uždaryti laukimo būseną. Perjungdami senus naudotojus, istoriją atkurkite tik iš išsaugotų duomenų; likusiems pradėkite naują pokalbį.

Taip pat skaitykite:

Dalintis: