Assistants API афіцыйна адключаны 26 жніўня 2026 года і больш недаступны. Працоўныя прыкладанні павінны перанесці генерацыю, стан дыялогу, інструменты і патокі даных у Responses API. Надзейны шлях такі: правесці інвентарызацыю кожнага Assistant, Thread, Run і інструмента, аднавіць паводзіны ў канфігурацыі Responses, імпартаваць гісторыю, якую захоўвае ваша прыкладанне, а перад пераключэннем трафіку праверыць адказы і пабочныя дзеянні. Дата адключэння і адпаведнасць аб’ектаў пацверджаны ў афіцыйным кіраўніцтве OpenAI па міграцыі Assistants.
Што змяняе адключэнне 26 жніўня 2026 года
Гэта міграцыя канчатковых кропак і аб’ектаў, а не перайменаванне мадэлі. Пасля адключэння звароты да старых рэсурсаў Assistants нельга лічыць часовым папярэджаннем. Код, які стварае або чытае /v1/assistants, /v1/threads, /v1/threads/messages ці /v1/threads/runs, патрабуе новага шляху. Не пачынайце новую інтэграцыю са старым API і не стварайце запасны шлях, які разлічвае на даступнасць старых аб’ектаў.
Актуальная адпаведнасць, апублікаваная OpenAI:
| Assistants API | Платформа Responses | Практычны сэнс |
|---|---|---|
| Assistant | Prompt або канфігурацыя запыту | Захоўвайце мадэль, інструкцыі, аб’явы інструментаў і правілы вываду ў версіёненай канфігурацыі. Цяперашняе кіраўніцтва дазваляе стварыць Prompt з Assistant у панэлі, але таксама папярэджвае пра састарэнне шматразовых Prompt-аб’ектаў. |
| Thread | Conversation або гісторыя прыкладання | Conversation захоўвае элементы, у тым ліку паведамленні, выклікі інструментаў і іх вынікі. Стан можна захоўваць у сваёй базе і перадаваць патрэбныя элементы. |
| Run | Response | Запыт Responses атрымлівае ўваходныя элементы і вяртае выходныя. Асобны аб’ект Run і цыкл апытання больш не з’яўляюцца галоўнай абстракцыяй. |
| Run step | Item | Апрацоўвайце тыпізаваныя элементы message, function_call, function_call_output і reasoning, а не лічыце кожны вынік паведамленнем. |
Прачытайце кіраўніцтва па пераходзе на Responses API разам з кіраўніцтвам пра адключэнне. У ім Responses названы рэкамендаваным API для новых праектаў і апісаны адрозненні ад Chat Completions, а таксама фарматы ўводу і вываду.
Новая мадэль працы
Раней Assistant быў пастаянным серверным наборам налад. Thread захоўваў паведамленні, а Run выконваў Assistant адносна гэтага Thread. Responses падзяляе гэтыя абавязкі. Запыт задае мадэль, інструкцыі, уваход і інструменты. Вынік — тыпізаваны Response, у якім output з’яўляецца ўпарадкаваным спісам элементаў.
Такі падыход перадае прыкладанню выразную адказнасць за аркестрацыю. Код вырашае, як ідэнтыфікаваць карыстальніка, колькі гісторыі адпраўляць, якія выклікі дазволены, як правяраць аргументы, як паўтараць няўдалыя аперацыі і калі патрэбна згода чалавека. OpenAI па-ранейшаму прапануе варыянты захавання стану, але гэта свядомы выбар, а не схаваны жыццёвы цыкл Assistant.
Ёсць тры практычныя стратэгіі стану:
- Выкарыстоўвайце запыт без стану і перадавайце абмежаваны спіс уваходных элементаў на кожным ходзе. Так ваша база кантралюе захоўванне і скарачэнне гісторыі.
- Звязвайце ходы праз previous_response_id. Гэты спосаб паказаны ў дакументацыі пра стан дыялогу. Ён зручны для кароткіх сцэнарыяў, але папярэднія ўваходныя токены ўсё роўна аплачваюцца, а захоўванне павінна адпавядаць вашай палітыцы.
- Стварыце аб’ект Conversations API і перадавайце яго ID у Responses. Conversation мае трывалы ідэнтыфікатар і працуе паміж сесіямі, прыладамі і задачамі. Элементы захоўваюцца да выдалення, таму ID паказвае на захаваны стан, а не ўключае прыватнасць.
Выберыце адну стратэгію для кожнага патоку прадукту. Не змешвайце лакальна адноўленую стэнаграму, Conversation і ланцужок previous_response_id без вызначанай крыніцы ісціны. Дубляваныя ходы могуць змяніць паводзіны мадэлі, павялічыць выдаткі і ўскладніць выкананне запытаў на выдаленне.
Правядзіце інвентарызацыю да змены кода
Стварыце запіс міграцыі для кожнага Assistant ID і кожнага вытворчага шляху сесіі. Зафіксуйце мадэль, інструкцыі, параметры па змаўчанні, схемы інструментаў, vector stores, файлы, выкарыстанне Code Interpreter, фармат адказу, метаданыя, патрабаванні да захоўвання і ўвесь код, які апытвае стан Run. Шукайце не толькі на серверы, але і ў фонавых задачах, адміністрацыйных скрыптах, панэлях, тэстах і спажыўцах аналітыкі. Паспяховы тэкставы адказ не даказвае, што file search, структураваны вывад, streaming або функцыя з пабочным дзеяннем працуюць гэтак жа.
Аддзяліце паводзіны ад захаваных даных. Інструкцыі і аб’явы інструментаў можна аднавіць з канфігурацыі. Паведамленні Thread і загружаныя файлы — гэта даныя, для якіх патрэбны экспарт або копія пад кантролем прыкладання. Калі сістэма ніколі не захоўвала паведамленні па-за Threads, спачатку вырашыце, як апрацаваць гэтыя запісы. Кіраўніцтва пасля адключэння паведамляе, што атрыманне старых паведамленняў Thread больш не працуе, і раіць выкарыстоўваць паведамленні, якія ўжо захавала прыкладанне.
Аднавіце базавы запыт
Для тэкставай узаемадзеі замяніце паслядоўнасць beta Thread і Run адным выклікам Responses. Поле input прымае радок або спіс элементаў, падобных да паведамленняў. Выкарыстоўвайце instructions для стабільных сістэмных паводзін, а тэкст карыстальніка пакідайце ў input. Звычайны тэкст чытайце праз response.output_text, але правярайце response.output, калі магчымыя інструменты або нетэкставыя элементы.
from openai import OpenAI
client = OpenAI()
response = client.responses.create(
model="gpt-5.6",
instructions="Адказвай выразна і спасылайся на пададзеныя запісы.",
input=[{"role": "user", "content": "Падсумуй стан замовы."}],
store=False,
)
print(response.output_text)
Новая канчатковая кропка — /v1/responses, а метад SDK — client.responses.create. Не пераносіце без змен ключ messages, шлях choices[0].message.content або цыкл апытання з Runs. Калі Responses трэба захоўваць, зрабіце гэта асобным рашэннем. У дакументацыі па кантролі даных цяпер указана, што стан Responses захоўваецца 30 дзён па змаўчанні або калі store мае значэнне true, з пералічанымі выключэннямі.
Назва мадэлі ў прыкладзе не гарантуе міграцыю. Праверце мадэль і магчымасці ў актуальным каталогу мадэляў, зафіксуйце snapshot, калі важная ўзнаўляльнасць, і правядзіце ўласныя тэсты якасці і затрымкі.
Правільна захавайце гісторыю
Калі стэнаграма належыць вашаму прыкладанню, нармалізуйце яе да ўваходных элементаў Responses. Тэкст карыстальніка становіцца input_text, тэкст асістэнта — output_text, а выява — input_image з URL або спасылкай на файл. Захавайце храналагічны парадак і пары выкліку інструмента ды яго выніку, патрэбныя для разумення папярэдняга ходу.
Наступны прыклад стварае сталую Conversation з гісторыі прыкладання, а потым адпраўляе новы ход:
from openai import OpenAI
client = OpenAI()
conversation = client.conversations.create(
items=[
{
"role": "user",
"content": [{"type": "input_text", "text": "Мая замова — 1842."}],
},
{
"role": "assistant",
"content": [{"type": "output_text", "text": "Я магу праверыць замову 1842."}],
},
]
)
response = client.responses.create(
model="gpt-5.6",
conversation=conversation.id,
input=[{"role": "user", "content": "Яна гатовая да адпраўкі?"}],
)
print(response.output_text)
Пасля адключэння не спрабуйце міграваць праз threads.messages.list. Экспартуйце даныя, пакуль стары endpoint даступны, толькі калі працуеце ў асяроддзі да адключэння. У сістэме пасля адключэння выкарыстоўвайце запісы, якія захавала прыкладанне. Да імпарту супастаўце асобу карыстальніка, запыты на выдаленне, рэгіянальныя правілы, укладанні і часавыя меткі. Conversation ID ад кліента нельга прымаць без праверкі належнасці аўтэнтыфікаванаму карыстальніку.
Перанясіце інструменты і выклікі функцый
Інструменты Responses аб’яўляюцца ў запыце. Убудаваныя web search, file search, computer use, Code Interpreter, генерацыя выяў і аддалены MCP апісаны ў Using tools. Уласныя функцыі па-ранейшаму рэалізуюцца на баку прыкладання. Мадэль можа запытаць функцыю, але не можа самастойна аўтарызаваць або выканаць бізнес-аперацыю.
Цыкл кантролю цяпер відавочны. Адпраўце першы запыт, праверце response.output на элементы function_call, праверце і выканайце кожную дазволеную функцыю, дадайце элементы вываду мадэлі і function_call_output, а потым адпраўце наступны запыт. Для reasoning-мадэляў захоўвайце reasoning-элементы, вернутыя разам з выклікам, як апісана ў кіраўніцтве па function calling.
import json
from openai import OpenAI
client = OpenAI()
tools = [
{
"type": "function",
"name": "lookup_order",
"description": "Вярнуць стан замовы, якая належыць аўтэнтыфікаванаму карыстальніку.",
"parameters": {
"type": "object",
"properties": {
"order_id": {"type": "string"},
},
"required": ["order_id"],
"additionalProperties": False,
},
"strict": True,
}
]
input_items = [{"role": "user", "content": "Дзе мая замова 1842?"}]
response = client.responses.create(
model="gpt-5.6",
tools=tools,
input=input_items,
)
input_items += response.output
for item in response.output:
if item.type == "function_call" and item.name == "lookup_order":
arguments = json.loads(item.arguments)
result = {"order_id": arguments["order_id"], "status": "packed"}
input_items.append(
{
"type": "function_call_output",
"call_id": item.call_id,
"output": json.dumps(result),
}
)
response = client.responses.create(
model="gpt-5.6",
tools=tools,
input=input_items,
)
print(response.output_text)
Строгі рэжым дапамагае выконваць схему, але не выдае дазволы. У кодзе правярайце аўтэнтыфікаванага карыстальніка, уладальніка замовы, дыяпазоны, значэнні enum і стан аперацыі. Для аплаты, выдалення, публікацыі або адпраўкі выкарыстоўвайце ідэмпатэнтнасць ці транзакцыю. Пры памылцы вяртайце структураваную памылку інструмента, а не імітуйце поспех. Абмяжуйце колькасць хадоў інструмента і запісвайце выклікі, вынікі ды рашэнні пра адабрэнне з замаскіраванымі адчувальнымі значэннямі.
Фармат вызначэнняў функцый Responses адрозніваецца ад старой абгорткі функцый Chat Completions. Пераносьце схему наўмысна і тэстуйце памылковыя аргументы, невядомыя функцыі, паўторныя і паралельныя выклікі, тайм-аўты і вынік інструмента з недавераным тэкстам.
Захавайце структураваны вывад
Калі стары Assistant выкарыстоўваў JSON mode або схему адказу, перанясіце яе ў канфігурацыю Responses text.format, а response_format не капіруйце без змен. Кіраўніцтва па структураваных вывадах апісвае актуальную форму схемы і дапаможнікі SDK. Правярайце разабраны вынік да запісу ў базу, паказу ў інтэрфейсе або перадачы іншаму інструменту. Правільны JSON усё яшчэ можа ўтрымліваць няправільны нумар замовы, небяспечную інструкцыю ці няпоўнае бізнес-рашэнне.
Трымайце схему невялікай і версіянуйце яе разам з Prompt або канфігурацыяй запыту. Аб’яўляйце абавязковыя палі, задавайце additionalProperties=false там, дзе гэтага патрабуе строгі рэжым, і тэстуйце адмовы, няпоўныя адказы ды эвалюцыю схемы. Наяўнасць JSON-аб’екта сама па сабе не азначае поспеху аперацыі.
Бяспека і даныя пасля міграцыі
Міграцыя змяняе мяжу стану, таму яе трэба перагледзець як змяненне архітэктуры бяспекі. Захоўвайце API-ключы на давераным серверы, аўтэнтыфікуйце кожную сесію і звязвайце Conversation або лакальную стэнаграму з асобай карыстальніка на серверы. Не змяшчайце сакрэты, токены аўтарызацыі або неабмежаваныя запыты да базы ў інструкцыях і апісаннях інструментаў.
Выкарыстоўвайце найменшы патрэбны набор інструментаў. Аддзяляйце функцыі чытання ад запісу, патрабуйце відавочнага пацвярджэння важных дзеянняў і выконвайце аўтарызацыю незалежна ад вываду мадэлі. Лічыце атрыманыя файлы, вэб-старонкі і адказы аддаленага MCP недаверанымі ўваходнымі данымі. Аддаленыя MCP-серверы маюць уласныя правілы захоўвання, а размешчаныя кантэйнеры Code Interpreter могуць трымаць часовы стан падчас працы. Кіраўніцтва па кантролі даных пералічвае гэтыя абмежаванні.
Для кожнага патоку вырашыце, ці патрэбны store, Conversation або стэнаграма пад кантролем прыкладання. Бягучая дакументацыя кажа, што даныя API не выкарыстоўваюцца для навучання мадэляў OpenAI без відавочнай згоды, але гэта не замяняе праверку захоўвання, доступу, выдалення, рэгіянальнай апрацоўкі і пастаўшчыкоў. store=false не з’яўляецца агульнай палітыкай выдалення і не робіць Conversation часовай.
Абмяжоўвайце ўваход і выхад, ужывайце мадэрацыю пры патрэбе і арганізуйце чалавечую праверку рашэнняў з высокім уплывам. У рэкамендацыях OpenAI па бяспецы асобна раяцца adversarial-тэсты супраць prompt injection, мадэрацыя і чалавечы нагляд. Запісвайце ID запытаў і тыпы падзей, але маскіруйце тэкст карыстальніка, уліковыя даныя, аргументы функцый і вынікі інструментаў паводле палітыкі.
Частыя памылкі міграцыі
Стары endpoint вяртае памылку
Пасля 26 жніўня 2026 года запыты да Assistants — гэта дэфект міграцыі. Выдаліце стары шлях кліента, а не паўтарайце яго. Калі фонавы worker усё яшчэ апытвае Run ID, разгарніце worker Responses і замяніце thread_id і run_id на ідэнтыфікатары сесіі ды Response.
Адказ пусты або парсер падае
Вывад Responses — неаднародны спіс элементаў. output_text зручны для звычайнага тэксту, але выклік інструмента, адмова або няпоўны адказ патрабуюць праверкі стану і тыпаў элементаў. Не бярыце першы элемент па індэксе, лічачы яго паведамленнем.
Мадэль паўтарае кантэкст або выдаткі растуць
Выберыце стратэгію стану і правіла скарачэння. previous_response_id не робіць папярэднія ўваходныя токены бясплатнымі, а капіраванне адной гісторыі ў Conversation і input дублюе кантэкст. Вымярайце ўваходныя і выходныя токены ў staging на рэалістычных доўгіх дыялогах.
Функцыя выконваецца двойчы
Паўторы, паралельныя выклікі інструментаў, сеткавыя тайм-аўты і перападключэнні могуць паўторна выканаць выклік. Дайце кожнай аперацыі з пабочным дзеяннем ідэмпатэнтны ключ на аснове call ID і аўтэнтыфікаванага карыстальніка, а перад выкананнем праверце бізнес-транзакцыю. Паспяховае паведамленне мадэлі не даказвае аднаразовага выканання функцыі.
Старыя файлы або вынікі пошуку знікаюць
Інвентарызуйце vector stores, ID файлаў, тэрміны дзеяння і дазволы асобна ад гісторыі Thread. Аднавіце падтрыманы шлях пошуку, праверце доступ кожнага арандатара і пратэстуйце цытаты ды пустыя вынікі. Пераўтварэнне канфігурацыі Assistant не азначае капіравання файлаў.
Чэкліст міграцыі
Выконвайце крокі па парадку для кожнага вытворчага патоку:
- Запішыце залежнасці ад старых Assistant, Thread, Run, файлаў, vector stores, інструментаў, Prompt і метаданых.
- Перамясціце карыстальніцкія інструкцыі і схемы інструментаў у версіёненую канфігурацыю.
- Выберыце мадэль Responses і пацвердзіце інструменты, мультэмадальны ўвод, структураваны вывад і рэгіянальную даступнасць.
- Выберыце адну стратэгію стану: элементы без стану, previous_response_id або Conversations.
- Супастаўце messages з input, choices з output, а чытанне тэксту з output_text.
- Перапішыце вызначэнні функцый і рэалізуйце відавочны абмежаваны цыкл інструментаў.
- Асобна аднавіце file search, Code Interpreter, web search, MCP, streaming і структураваны вывад.
- Імпартуйце толькі гісторыю пад кантролем прыкладання, захаваўшы парадак, асобы, укладанні, выклікі і семантыку выдалення.
- Дадайце аўтарызацыю, ліміты ўводу, мадэрацыю, ідэмпатэнтнасць, замаскіраваныя логи і адабрэнне пабочных дзеянняў.
- Запусціце эталонныя дыялогі, adversarial-запыты, памылкі інструментаў, паўторы, адмовы, доўгі кантэкст і паралельныя сесіі.
- Параўнайце адказы, цытаты, эфекты інструментаў, токены, затрымку, памылкі і паводзіны захоўвання.
- Выпусціце змену за feature flag, спыніце старыя workers, назірайце памылкі Responses і захавайце адкат без адключанага API.
- Выдаляйце стары код Assistant і ключы толькі пасля праверкі экспарту, аўдыту і працэдур падтрымкі.
Пра дызайн сістэмы чытайце ў кіраўніцтве па production-архітэктуры AI-агента. Наборы рэгрэсій і паводзінскія праверкі апісаны ў кіраўніцтве па evals AI-агентаў.
Як зразумець, што міграцыя завершана
Міграцыя завершана, калі ніводны вытворчы шлях не залежыць ад рэсурсаў Assistants, для кожнай сесіі вызначаны ўладальнік стану, кожны выклік інструмента аўтарызаваны і абаронены ад паўтору, а кантракт вываду Responses пакрыты тэстамі. Захоўвайце запіс міграцыі са snapshot мадэляў, версіямі Prompt або канфігурацыі запыту, версіямі схем, рашэннямі пра захоўванне і вядомымі збоямі. Пераглядайце яго пры змяненні Responses API або мадэлі, бо адключэнне старога fallback не адмяняе пастаяннай ацэнкі.