Агент генерациясынан бас тарту және ішінара нәтижені сақтау

Агент генерациясынан бас тарту «осы уақытқа дейін болғанның бәрін тастау» дегенді білдірмейді. Бұл жүйе әрі қарайғы жұмысты тоқтатып, нақты шекараны адал белгілеуі керек деген сөз: пайдаланушы нені көрді, сервер нені растады, сыртқы жүйелер нені қабылдап үлгерді және енді нені нәтиженің бөлігі деп санауға болмайды.

«Бас тарту» батырмасын басқаннан кейінгі келесі сұрау пайдаланушы көрген жерден жалғаспаса, мәселе батырмада емес. Мәселе токендер ағыны, workflow күйі және интерфейс бір оқиғаның үш бөлек нұсқасы ретінде өмір сүріп тұрғанында. Production ортасында оларды бір келісімге келтіру керек.

Ішінара мәтін мен процесс күйі бір нәрсе емес

Сақталған ішінара нәтиже желідегі ағынның кездейсоқ бөлігі емес, диалогтың қайта қалпына келтірілетін күйі болуы керек. Браузер 800 таңба алуы мүмкін, сервер тағы 300 таңбаны қалыптастырып үлгеруі мүмкін, ал оркестратор сол уақытта іздеуді, CRM сұрауын немесе төлемді дайындауды бастауы ықтимал. Тарихқа экранға жеткен бөлікті ғана жазсаңыз, нақты орындау күйіне сәйкес келмейтін диалог аласыз.

Мен тоқтатылған іске қосу деректерін әдетте төрт қабатқа бөлемін:

• Көрінетін нәтиже: пайдаланушыға жарияланған хабарламалар мен құрылымдалған блоктар, мысалы кесте немесе хаттың дайын үзіндісі.
• Расталған workflow күйі: кіріс деректерінің нұсқасы, өткен түйіндер, аяқталған тапсырмалардың нәтижелері, таңдалған тармақ және checkpoint.
• Аяқталмаған жұмыс: ағымдағы генерация, күтілудегі құрал шақыруы, кезектегі сұрау және фондық тапсырмалар.
• Орындау іздері: іске қосу идентификаторы, бас тарту себебі, команданың қабылданған уақыты және сыртқы операциялардың идемпотенттік кілттері.

Бұл қабаттарды бір messages өрісіне біріктіруге болмайды. «Мен клиентке хат жіберіп жатырмын» деген мәтін хаттың шынымен кеткенін дәлелдемейді. send_email API нәтижесі пайдаланушының дайын мәтінді көргенін білдірмейді. Ал cancelled жалауы сұраудың сыртқы провайдерге жеткенге дейін тоқтатылғанын көрсетпейді.

Кең тараған қате, келген әр токенді бірден негізгі тарихқа сақтау. Бір қарағанда бұл бәрін шешетіндей көрінеді: бас тартқанда толық жоба дайын тұрады. Шын мәнінде, сіз тұрақсыз артефакт сақтайсыз. Модель JSON-ды жаппауы, функция шақыруын аяқтамауы, аралық тұжырымды шығарып, келесі токендерде оны түзетуі мүмкін. Осындай мәтінді жалғастырғанда ол жалған контекстке айналады, ал пайдаланушы оны агент айтып қойған сөз ретінде қабылдайды.

Негізгі тарихқа тек жарияланған блок түседі. Ағынды байланыс қалпына келтіру немесе қатені зерттеу қажет болса, қысқа өмір сүретін техникалық буфер ретінде бөлек сақтауға болады. Бірақ агентті жалғастыру checkpoint пен жарияланған хабарламаларды оқуы керек, шикі SSE немесе WebSocket буферін емес.

Бас тартудың тек воркерге жіберілетін сигналы емес, өз протоколы болуы керек

Бас тарту командасы іске қосу сияқты деңгейлердің бәрінен өтуі керек: интерфейс, API, оркестратор, воркер, құралдар және күй қоймасы. Браузердегі abort сигналы пайдалы, бірақ ол тек клиенттің жауапты тыңдауды тоқтатқысы келетінін білдіреді. Бұл сервердегі жұмыстың тоқтағанын растамайды.

Күйдің ең қарапайым моделі мынадай:

{
  "run_id": "run_8f3c",
  "state_version": 17,
  "status": "running",
  "cancel_requested_at": null,
  "cancel_reason": null,
  "published_message_id": "msg_204",
  "active_operation": {
    "kind": "model_generation",
    "operation_id": "gen_771"
  }
}

Пайдаланушы сұрағаннан кейін сервер не болғанын әлі білмесе, бірден соңғы cancelled жауабын бермеуі керек. Алдымен ол іске қосуды тоқтату ниетін атомарлы түрде жазады:

{
  "run_id": "run_8f3c",
  "expected_state_version": 17,
  "action": "cancel",
  "reason": "user_requested"
}

Бұл командаға қалыпты жауап мынадай болуы мүмкін:

{
  "run_id": "run_8f3c",
  "status": "cancel_requested",
  "accepted_state_version": 18,
  "resume_checkpoint_id": "cp_18",
  "published_message_id": "msg_204"
}

Одан кейін воркер бас тарту жалауын қауіпсіз нүктелерде тексереді. Генерацияда бұл ағын бөліктерінің арасындағы шекара, кезекте келесі тапсырманы алар алдындағы сәт, ал құралда қайтымсыз әрекетке дейінгі кезең. Воркер тоқтағанда немесе басталған операцияны аяқтағанда, ол іске қосуды терминалдық күйге ауыстырып, жалғастыруға нақты не қалғанын жазады.

Model Context Protocol тапсырмалар спецификациясы пайдалы ереже ұсынады: қабылданған бас тартудан кейін тапсырма cancelled күйіне өтеді және орындау кейінірек іс жүзінде аяқталса да, осы күйде қалады. Бұл күй атауына қатысты ұсақ талап емес. Ол ең жағымсыз сценарийден қорғайды: пайдаланушы тапсырмадан бас тартып, «тоқтатылды» дегенді көреді, ал бір секундтан кейін агент бас тарту болмағандай жаңа жауап жариялайды.

Агенттік қолданбада операцияның аяқталуына біраз уақыт кетсе, мен тағы бір cancelling күйін қосамын. Ол шын жағдайды көрсетеді: сервер команданы қабылдады, бірақ модель провайдері немесе құрал тоқтады деп әлі уәде бере алмайды. cancelled күйін жай ғана анимация үшін қолданбаңыз.

Checkpoint әр таңбаны емес, шешімді бекітеді

Checkpoint күйдің мағыналы ауысуынан кейін пайда болуы керек. Бұл аяқталған іздеу, жоспардың расталған таңдауы, жарияланған жауап, алынған құрал нәтижесі немесе салдары бар операция алдындағы үзіліс болуы мүмкін. Ол әр токеннен кейін пайда болмауы керек және оған қажеттілік жоқ.

Checkpoint-тің үш міндеті бар. Ол жалғастыруға болатын нүкте береді. Дайын нәтижелерді орындалып жатқан жұмыстан бөледі. Серверге пайдаланушының қай нұсқаны өңдеуге немесе дамытуға құқылы екенін интерфейске түсіндіруге мүмкіндік береді.

Жақсы checkpoint модельдің ішкі «ойлауын» емес, жалғастыру кезінде бұрын расталған шешімдер сол күйінде қабылдануы үшін жеткілікті деректі сақтайды:

{
  "checkpoint_id": "cp_18",
  "run_id": "run_8f3c",
  "parent_checkpoint_id": "cp_16",
  "state_version": 18,
  "conversation": [
    {"id": "msg_201", "role": "user", "content": "Сравни варианты поставки"},
    {"id": "msg_204", "role": "assistant", "content": "Я нашёл два применимых варианта...", "published": true}
  ],
  "completed_steps": ["extract_requirements", "search_catalog"],
  "tool_results": [
    {"call_id": "tool_91", "name": "catalog_search", "result_ref": "obj_667"}
  ],
  "pending": {
    "step": "draft_recommendation",
    "input_hash": "sha256:..."
  },
  "cancelled_generation": {
    "discarded_stream_chars": 412,
    "resume_policy": "regenerate_pending_step"
  }
}

Мұндағы discarded_stream_chars өнімге де, аналитикаға да арналмаған. Ол инженерге пайдаланушы неге сервер модельден қабылдап үлгергеннен қысқарақ жауап көргенін түсінуге көмектеседі. Бірақ жалғастыру механизмі осы 412 таңбаны алып, жаңа мәтінге жалғамауы керек. Ол аяқталмаған қадамды расталған контекстпен қайта іске қосады.

LangGraph құжаттамасы да осы шекараны көрсетеді: checkpointer ағын күйін сақтайды, ал thread_id жалғастырғанда қай күйді жүктеу керегін көрсетеді. Мұнда бас тартуды жобалағанда жиі ескерілмейтін маңызды жайт бар: жалғастыру кезінде түйін үзіліс болған нақты жолдан емес, басынан орындалады.

Бұдан шығатын қорытынды қарапайым. Егер сіздің «түйініңіз» мәтін генерациялап, үш құрал шақырып, хат жіберсе, оны ауыртпалықсыз тоқтатып, жалғастыруға болатын бір түйін деп санауға болмайды. Бұл бір функцияға қате біріктірілген бірнеше түрлі күй ауысуы.

Интерфейстегі жариялауда нұсқа шекарасы болуы керек

Интерфейс мәтінді ғана емес, оның қай нұсқада көрінгенін де білуі керек. Әйтпесе «осы жауапты жалғастыру» мен «күй басқа қойындыда өзгергеннен кейін сұрауды қайталау» әрекеттерін ажырата алмайсыз.

Әр жарияланған блок үшін кемінде мына төрт өрісті сақтаңыз: message_id, state_version, publication_status және run_id. Пайдаланушы «Жалғастыру» батырмасын басқанда, клиент жай ғана «толықтыр» демей, нақты нүктеге сілтеме жіберуі керек:

{
  "thread_id": "thr_42",
  "resume_from_checkpoint_id": "cp_18",
  "expected_state_version": 18,
  "user_message": "Продолжи сравнение и добавь риски"
}

Сервер expected_state_version мәнін ағымдағы тармақпен салыстыруы керек. Егер басқа қойынды диалогты жалғастырып, 19-нұсқаны жасап қойған болса, сервер жаңа сұрауды өзгерген контекстке үнсіз қоса салмауы тиіс. Ол күй қайшылығын қайтарады:

{
  "error": "state_version_conflict",
  "current_checkpoint_id": "cp_19",
  "current_state_version": 19,
  "allowed_actions": ["reload", "fork_from_cp_18"]
}

Мұндай жауапты жүйе қатаң көрінуі мүмкін, бірақ кері жағдайды елестетіп көріңіз. Пайдаланушы A браузерінде есеп жобасынан бас тартады. B браузерінде агент іздеуді аяқтап, жаңа дерек алады. Содан кейін A браузері «жалғастыр, бірақ қысқарақ» деп жібереді. Сервер тексермей қабылдаса, модель экранда ескі нұсқа тұрғанымен, басқа диалогты жалғастырады. Пайдаланушы байланысқандай көрінетін, бірақ өзі көрмеген әрі таңдамаған деректерге сүйенген жауап алады.

Нұсқалау бірінші релизде күрделі тармақтар жүйесін қажет етпейді. Монотонды күй нөмірі, ата-аналық checkpoint және қайшылық кезінде қабылданатын нақты шешім жеткілікті. Өнім екі жұмыс желісін де сақтауға мүмкіндік бергенде ғана тармақ керек. Әзірлеушілер 409 қайтарғысы келмегендіктен оны енгізудің қажеті жоқ.

Пайдаланушыға сервер адал орындай алатын әрекеттерді ғана көрсетіңіз:

• «Сақталған жерден жалғастыру», егер жарамды checkpoint бар болса.
• «Сұрауды өзгертіп жалғастыру», егер жаңа реплика осы checkpoint-тің еншілес күйі болса.
• «Жаңа тармақ бастау», егер ағымдағы тарих алға кетіп қойған болса.
• «Жобаны жою», егер жарияланған ішінара мәтін әңгімеде қажет болмаса.

Бұл жерде «Қайталау» батырмасы тым түсініксіз. Ол модельге сұрауды қайталауды, құралды қайта шақыруды, генерацияны жалғастыруды немесе жаңа жауап жасауды білдіруі мүмкін. Инженерлер енгізген төрт нұсқаның қайсысы екенін пайдаланушының болжауына мәжбүрлемеңіз.

Құралдарға қайтымсыз әрекетке дейінгі шекара қажет

Мәтін генерациясын тоқтатып, қайта бастауға болады. Ал сыртқы әрекеттерді жиі қайтару мүмкін емес. Агент өтінім жасаса, хат жіберсе, CRM жазбасын өзгертсе, уақыт белгілесе немесе құжат жарияласа, бас тарту операцияның қай кезеңде тұрғанын ескеруі керек.

Практикалық үлгі екі бөліктен тұрады: дайындау және бекіту. Дайындау кезінде агент дәлелдерді жинайды, пайдаланушыға әрекетті көрсетеді және идемпотенттік кілті бар ниет жазбасын жасайды. Бекіту кезінде бөлек воркер қайтымсыз шақыруды орындайды. Осы екі кезеңнің арасында checkpoint орналасады.

Нашар рет мынадай:

сгенерировать письмо -> отправить письмо -> показать пользователю текст -> ждать подтверждения

Бас тартудан кейін нені сақтағаныңызды айта алмайсыз. Хат кетіп қалуы мүмкін, бірақ пайдаланушы оның соңғы нұсқасын көрмеген. Қайта іске қосқанда агент дубликат хат жіберуі ықтимал, өйткені күйде расталған операция жоқ.

Жұмыс істейтін рет басқа:

сгенерировать черновик -> опубликовать черновик -> сохранить checkpoint -> получить подтверждение -> отправить с idempotency_key -> записать результат

Мұнда да бас тарту қайтарып алуға тең емес. Егер провайдер тоқтату сигналын алғанға дейін жіберу сұрауын қабылдап қойса, іске қосу күйі cancelled болуы мүмкін, ал хат адресатқа бәрібір жетеді. Интерфейс: «Бас тарту қабылданды. Жіберу сыртқы жүйеге беріліп қойды, операция журналын тексеріңіз» деп хабарласа, бұл қайшылық емес. Жағымсыз болса да нақты хабарлама жалған кепілдіктен жақсы.

LangGraph құжаттамасы жанама әсерлерді үзіліс нүктесінен кейін орналастыруды немесе оларды идемпотентті етуді тікелей ұсынады, себебі жалғастырылған түйін қайта орындалуы мүмкін. Дерекқорда жазбаны қайталап жасау мысалы таныс: код алғашқы орындалуда дұрыс көрінеді де, үзіліс, retry немесе бас тартудан кейін ғана жаңа нысандарды көбейте бастайды.

Идемпотенттік кілт орындау әрекетін емес, бизнес әрекетін сипаттауы керек. Ұсыныс жіберу үшін quote:483:revision:7:send деген кілт қолайлы, әр шақыруға жасалатын кездейсоқ UUID емес. Сонда желі таймаутынан кейінгі қайталау сол нәтижені қайтарады немесе операцияның бұрын орындалғанын көрсетеді.

Бас тартылған деректердің бәрін тарихта қалдыру міндетті емес

Ішінара нәтижені сақтау оны әңгіменің тұрақты бөлігіне айналдыру керек деген сөз емес. Кейде пайдаланушы агенттің дұрыс бағытқа кетпегені үшін бас тартады. Кейде ағынға қате детальдар, жарамсыз JSON немесе келесі операторға көрсетуге болмайтын үзінді түседі. Кейде деректерді сақтау талаптары шикі шығарылымды қалдыруға тыйым салады.

Артефакттардың төрт түріне саясатты алдын ала белгілеген пайдалы.

Ең қауіпті санат, құрылымдалған ішінара қалыптасқан нәтиже. Агент тапсырыс параметрлері бар JSON жасап, quantity өрісінен кейін тоқтады делік. Парсер бірнеше өрісті шығара алғаны үшін оны дайын тапсырыс карточкасы ретінде сақтауға болмайды. Жүйе орындауға қатыспайтын, жоба деп анық белгіленген нұсқаны жариялауы немесе оны алып тастап, соңғы жарамды нысаннан жалғастыруы керек.

Бұл алынған деректерге де қатысты. Агент іздеуден үш жазбаны көрсетіп үлгерсе, төртіншісі бас тартудан кейін келсе, оны келесі қадамда білдіртпей қоспаңыз. Үш жазбадан тұратын жиын сақталғанын көрсетіп, жалғастырғанда іздеуді қайталаңыз немесе жиын жаңартылғанын ашық белгілеңіз. Пайдаланушы агенттің кейінгі қорытындысын қандай материалға сүйеніп жасағанын түсінуі керек.

Жергілікті сақтау талаптары бар жүйелер үшін тағы бір деңгей маңызды. Күйдің, бас тарту журналының және ағынның техникалық буферінің өмір сүру мерзімі мен сезімталдығы әртүрлі. Схема ыңғайлы болсын деп оларды бір қоймада ұстамаңыз. AI Router командалары бірыңғай OpenAI-үйлесімді endpoint қолдануы мүмкін, бірақ data residency, PII маскировкасы және аудит журналдары талаптарын осы артефакттардың әрқайсысы үшін бөлек ескеру керек. Тоқтатылған ағынды зиянсыз жоба деп қабылдамаңыз.

Ағынды, checkpoint-ті және экранды оқиғалармен байланыстырыңыз

Сервер ағыны интерфейсті жылдам сезіндіреді, бірақ шындықтың жалғыз көзі болмауы керек. Байланыс үзіліп, пайдаланушы қайта қосылғанда да клиент экранды расталған деректерден жинай алуы үшін оқиғалар енгізіңіз.

Мысалы, реттілік мынадай болуы мүмкін:

{"type":"run.started","run_id":"run_8f3c","state_version":17}
{"type":"message.delta","message_id":"msg_204","seq":51,"text":"Я нашёл"}
{"type":"message.delta","message_id":"msg_204","seq":52,"text":" два варианта"}
{"type":"message.published","message_id":"msg_204","state_version":18,"checkpoint_id":"cp_18"}
{"type":"run.cancel_requested","run_id":"run_8f3c","state_version":19}
{"type":"run.cancelled","run_id":"run_8f3c","resume_checkpoint_id":"cp_18"}

message.delta жоғалуы, екі рет келуі немесе пайдаланушы бас тартқаннан кейін жетуі мүмкін. Сондықтан клиент оны уақытша мәтін ретінде көрсете алады, бірақ message.published оқиғасынсыз тұрақты тарихқа жазбауы керек. Жариялау оқиғасы экранды checkpoint-пен байланыстырады. Бас тарту оқиғасы келесі ниетке қай нүкте қолжетімді екенін көрсетеді.

Өнімге «дәл қазір көрініп тұрғанды сақтау» режимі қажет болса, оны бөлек әрекет ретінде жасаңыз. Клиент көрінетін жобаны соңғы реттік нөмірімен бірге бекіту туралы сұрау жібереді, ал сервер оны дербес пайдаланушы артефакті ретінде тексереді. Бұл үзінді дайын модель жауабы сияқты әсер қалдырмаңыз. «Сақталған үзінді» деген белгі пайдаланушыға да, келесі іске қосуға да түсініксіздікті жояды.

Үлкен жүйелерде run_id мен thread_id мәндерін бөлген пайдалы. Біріншісі бір орындау әрекетін, екіншісі әңгімені немесе жұмыс нысанын сипаттайды. Бір thread_id ішінде бас тартудан кейін checkpoint 18-ді жалғастыратын жаңа run_id пайда болуы мүмкін. Екі ұғымды бір идентификаторда сақтауға тырысу аудитті, retry-ді және қолдауды жиі бұзады.

Жалғастыру сөйлемді жапсырмай, ниетті қайталауы керек

Пайдаланушы «жалғастыр» дегенде, әдетте модельден үзілген сөйлемді механикалық түрде аяқтауды сұрамайды. Ол көбіне бұрын жасалған жұмысты пайдаланып, тапсырмаға қайта оралғысы келеді. Бұл екі түрлі нәрсе.

Егер бас тарту еркін мәтін кезінде орын алса, жалғастыру сол аяқталмаған қадамды қайта іске қосуы мүмкін. Модельге расталған контекст беріңіз, алдыңғы шығарылымды пайдаланушы тоқтатқанын айтыңыз және тасталған токендерге сүйенбей, келесі жарияланатын блокты қалыптастыруды сұраңыз. Мәтін дәл сол күйінде шықпайды, бұл қалыпты жағдай. Мәтіннің детерминизмі жасанды түрде уәде етуге тұрарлық кепілдік емес.

Егер бас тарту аяқталған құралдан кейін болса, жалғастыру оның расталған нәтижесін пайдалануы керек. Пайдаланушы түсіндірме генерациясын тоқтатқаны үшін іздеуді немесе ақша есептен шығаруды қайта орындау архитектуралық ақау болады. Күй қай қадам аяқталғанын, қайсысы аяқталмағанын сақтауы керек.

Егер бас тарту құрал жұмыс істеп тұрған кезде келсе, шешім оның келісіміне байланысты:

• Құрал бас тартуды қолдап, оны растайды. Нәтижені жоқ деп белгілеңіз және жалғастырғанда жұмысты қайталаңыз.
• Құрал бас тартуды қолдамайды, бірақ қайталап орындағанда қауіпсіз. Нәтижені күтіңіз немесе оны idempotency key арқылы сұраңыз.
• Құралдың салдары бар. Жаңа іске қосудың алдында операция күйін нақтылап, пайдаланушыға оның орындалғанын көрсетіңіз.

Модель мен провайдер есептеудің өз деңгейінде дәл тоқтаған жерден жалғастыруды қолдамаса, «дәл тоқтаған жерден жалғастырамыз» деп уәде бермеңіз. Интерфейстің адал тұжырымы қарапайым: «Сақталған күйден жалғастыру». Бұл жүйе шынымен басқара алатын нәрсені сипаттайды.

Бас тартуды әдемі демода ғана емес, жарыстарда тексеріңіз

Пайдаланушы баяу генерациядан бас тартып, тоқтаған курсорды көретін тест ештеңені дерлік дәлелдемейді. Оқиғалар қолайсыз ретпен келетін сценарийлер қажет.

Кемінде мына жағдайларды тексеріңіз:

1. Клиент cancel жіберді, бірақ соңғы message.delta желіде болып қойған. Интерфейс оны кейіннен жарияламауы керек.
2. Воркер cancel_requested жазылып, жалауды оқыған аралықта құралды аяқтап үлгерді. Келесі іске қосу операцияның нақты күйін көруі керек.
3. Екі қойынды бір checkpoint-ті жалғастырады. Бірі жаңа нұсқа алады, екіншісі қайшылық алады немесе анық тармақ жасайды.
4. Клиент байланысын жоғалтты, бірақ іске қосуды тоқтатпады. Қайта қосылғанда ол жұмысты автоматты түрде тоқтатылған деп санамай, өзекті күйді көруі керек.
5. Воркер мәтінді жариялағаннан кейін, бірақ іске қосудың соңғы күйіне дейін құлады. Қалпына келтіру checkpoint-ті тауып, retry қажет пе екенін шешуі керек, бүкіл диалогты қайталамауы тиіс.

Әр жағдай үшін тек HTTP кодын емес, инвариантты тексеретін тест жазыңыз. Мысалы: «Тарихта checkpoint-і жоқ жарияланған хабарлама болмауы керек», «бір idempotency key бірден көп сыртқы әрекет жасамауы керек», «жалғастыру әрқашан бар checkpoint-ке сілтеме жасауы керек», «терминалдық cancelled run жаңа хабарлама жарияламауы керек».

Durable workflow жүйелерінде жағымсыз, бірақ пайдалы тәртіп бар: жалғастыру еркін функцияның ішіндегі нақты орынға тәуелді болмауы керек. LangGraph құжаттамасы checkpoint-ті қадамдардан кейін сақтауды және аяқталған тапсырмалардың нәтижелерін қалпына келтіруді сипаттайды, процессорды код жолына сиқырлы түрде қайтаруды емес. Жұмысты анық күй ауысуларына бөлсеңіз, бас тарту try/except ішінде жасыратын ерекше жағдай емес, процестің қалыпты күйіне айналады.

Жүйені шындықты айтуға мәжбүр ететін бір өзгерістен бастаңыз: жауап жарияланған кезде күй нұсқасын қосып, жалғастыру сұрауында сол нұсқаны талап етіңіз. Осыдан кейін қай жерде жай ғана мәтін сақтап отырғаныңыз, қай жерде checkpoint бар екені және агенттің байланыс үзілмей тұрғанда ғана жұмыс істейтіні бірден көрінеді.