AI-агенттегі replay мен resume-ді неге шатастыруға болмайды?

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

Оларды бір «Қайта іске қосу» батырмасына біріктіру оңай. Кейін агент CRM жүйесінде өтінімді екі рет жасайды, тауарды қайта брондайды немесе клиентке мазмұны әртүрлі екі хат жібереді. Әдетте бұл модельдің қатесі емес. Бұл оркестратор, күй қоймасы және сыртқы құралдар арасындағы келісімнің қатесі.

Replay өткен тарихты тексереді, ал resume міндеттемені жалғастырады

Replay checkpoint-тен кейін жаңа орындауды жасайды. Ол debugging, жаңа тармақты тексеру, модель шешімін талдау немесе сақталған кірістер арқылы ақауды қайталау үшін қолданылады. Мұндай іске қосылым бастапқы процестен бөлек болуы керек: жеке идентификаторы, іске қосу себебі және құралдармен жұмыс режимі болуы тиіс.

Resume сол логикалық процесті жалғастырады. Оның пайдаланушы мен сыртқы жүйелер алдындағы міндеттемелері бар. Агент аударымды келісу кезінде тоқтаса, resume шешімді күтіп, кейінгі түйіндерді орындауы керек. Сұрауды қайта жіктемеуі, жаңа өтінім жасамауы немесе бұрын расталған қорды қайта брондамауы тиіс.

Деректер моделінде осы айырманы бекітіңіз. Бір пайдаланушы әңгімесі бір іске қосылымға тең емес, бір іске қосылым бір командаға тең емес, ал команда сыртқы әсермен бірдей емес.

conversation_id = "conv_8841"
run_id          = "run_01J..."
command_id      = "cmd_send_offer_03"
effect_id       = "eff_run_01J_cmd_send_offer_03"

conversation_id хабарламаларды байланыстырады. run_id графтың жеке орындалуын сипаттайды. command_id іске қосылым ішіндегі агент ниетін анықтайды. effect_id бір сыртқы нәтижені жасау әрекеттерін байланыстырады. Төрт рөлдің бәріне бір thread_id қолданылса, жүйе «Бұл бұрынғы операцияның жалғасы ма, әлде сол әрекетті жаңадан орындау талпынысы ма?» деген қарапайым сұраққа жауап бере алмайды.

LangGraph құжаттамасы шекараны анық көрсетеді: replay таңдалған checkpoint-тен кейінгі түйіндерді іске қосады, ал оған дейінгілерді орындамайды, өйткені олардың нәтижелері сақталған. Бірақ кейінгі LLM, API және interrupt шақырулары қайта орындалуы мүмкін. Бұл «журналды көру» емес, кодты нақты орындау.

Күй снимогы сыртқы әсер болмағанын дәлелдемейді

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

Мысалы, send_invoice түйінін алайық. Агент биллинг жүйесіне HTTP сұрауын жіберді. Биллинг шот жасап, 201 Created қайтарды, бірақ жауап checkpoint-ке жазылғанға дейін процесс құлады. Қалпына келгенде оркестратор ескі күйді көреді: invoice_id өрісі бос. Сыртқы жүйеде шот бар. Resume сұрауды жай ғана қайталаса, клиент екі шот алады.

Мұндай белгісіздік терезесі мұқият архитектурада да болады:

1. агент әрекет ниетін жазды;
2. агент сыртқы сервисті шақырды;
3. сыртқы сервис әрекетті орындады;
4. жауап жоғалды, таймаут болды немесе нәтиже бекітілмей тұрып процесс аяқталды;
5. оркестратор қалпына келуге тырысады.

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

Маңызды әрекеттер үшін желілік шақыруға дейін әсер ниеті туралы бөлек жазба сақтаңыз. Шақырудан кейін сол жазбаны нәтижемен жаңартыңыз. Келесі талпыныста код «checkpoint бос болса, ештеңе болмаған» деп ойламай, алдымен осы жазбаның мәртебесін оқуы керек.

{
  "effect_id": "eff_run_01J_cmd_send_offer_03",
  "type": "crm.create_offer",
  "status": "pending",
  "request_hash": "sha256:...",
  "provider_reference": null,
  "created_at": "2026-07-23T09:14:06Z"
}

pending, accepted, completed, failed мәртебелері бір done логикалық өрісінен пайдалырақ. pending шақыруды қайта жібермес бұрын оның тағдырын тексеру керегін білдіреді. accepted алушы команданы қабылдағанын, бірақ соңғы нәтиже әлі белгісіз екенін көрсетеді. Бұл айырма төлемдерде, хабар жеткізуде және асинхронды тапсырмаларда ерекше маңызды.

Idempotency key талпынысты емес, әрекетті сипаттауы керек

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

Ең жиі кездесетін қате - құрал функциясының ішінде UUID жасау. Бірінші талпыныста агент бір кілт жібереді, ал resume кезінде екіншісі жасалады. Сыртқы сервис оны жаңа операция деп қабылдайды. Мұндай «идемпотентті» код бір HTTP клиенті ішіндегі кездейсоқ қайталаудан қорғайды, бірақ процесті қалпына келтіруден қорғамайды.

Кілт бірінші талпынысқа дейін пайда болып, процесс күйінде сақталуы керек.

from hashlib import sha256

def effect_key(run_id: str, command_id: str) -> str:
    raw = f"{run_id}:crm.create_offer:{command_id}".encode()
    return sha256(raw).hexdigest()

async def create_offer(state, crm):
    key = state["effect_id"]
    existing = await crm.find_effect(key)
    if existing and existing["status"] == "completed":
        return {"offer_id": existing["offer_id"], "effect_status": "completed"}

    response = await crm.create_offer(
        customer_id=state["customer_id"],
        amount=state["amount"],
        idempotency_key=key,
    )
    return {"offer_id": response["id"], "effect_status": "completed"}

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

Барлық құралда idempotency key болмайды. Ондайда дедупликацияны өзіңіз жасаңыз: (effect_type, effect_id) өрістеріне бірегей индексі бар әсерлер кестесін құрыңыз, ниетті транзакциялық түрде жазыңыз және шақыру алдында аяқталған не күтілетін жазбаны тексеріңіз. Бұл сыртқы сервис сұрауды сіздің ақауыңызға дейін орындаған болуы мүмкін жағдайда, алушымен салыстыру қажеттігін жоймайды. Бірақ жүйеде ниет туралы шынайы ақпарат сақталатын орын пайда болады.

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

Келісу кезіндегі кідіріс түйін кодын қайта іске қосуы мүмкін

Human-in-the-loop қауіпсіз көрінеді: агент әрекет дайындайды, мақұлдауды сұрайды, жауап алып, жұмысын жалғастырады. Бірақ көптеген runtime сақталған код жолынан емес, бүкіл түйіннен немесе функциядан жалғастырады.

LangGraph құжаттамасында interrupt() арқылы resume кезінде түйін басынан басталатыны айтылған. Сондықтан interrupt() алдындағы код та қайта орындалады. Құжаттама жанама әсерлерді interrupt-тен кейін қоюды, оған дейінгі әрекеттерді идемпотентті етуді немесе оларды бөлек түйіндерге шығаруды ұсынады.

Қауіпті түйін мынадай болуы мүмкін:

def approve_and_send(state):
    audit.create({"event": "offer_prepared", "run_id": state["run_id"]})
    decision = interrupt({"offer": state["offer"]})
    if decision["approved"]:
        mail.send(state["recipient"], state["offer"])

Resume-ден кейін audit.create() тағы орындалады. Audit append-only оқиғалары бірегей кілтсіз сақталса, дайындық туралы екі оқиға пайда болады. Бұл әлі төзуге болатын жағдай. Ал кідіріс алдында crm.create_lead() немесе payment.authorize() тұрса, салдары ауыр.

Қауіпсізі, фазаларды бөліңіз:

def request_approval(state):
    return interrupt({"effect_id": state["effect_id"], "offer": state["offer"]})

def send_approved_offer(state):
    if not state["approved"]:
        return {"status": "rejected"}
    return send_with_idempotency_key(state)

Бірінші функция адамға нақты ниетті көрсетеді. Екіншісі процесс шешімді бекіткеннен кейін ғана сыртқы сервисті шақырады. Pause механизмін ішкі тоқтату сигналын жұтып қоятын кең try/except блогына орамаңыз. LangGraph-та interrupt арнайы exception арқылы іске асады және runtime-ға жетуі керек.

LLM шақыруының replay-і жауапты қайталаумен бірдей емес

Replay көбіне «детерминирленген debugging іске қосылымы» деп аталады. Агент үшін бұл тек нақты нені қайталайтыныңыз анық болғанда ғана дұрыс.

Сұрауды сақтап, модельдің жазылған жауабын қайтарсаңыз, шешім қабылдау тарихын қайта жасайсыз. Бұл агенттің неліктен құрал шақырғанын немесе белгілі бір бағытты таңдағанын түсінуге көмектеседі. Ал сол prompt-ты модельге қайта жіберсеңіз, экспериментті қайталайсыз. Жауап өзгеруі мүмкін, сонымен бірге tool call, әрекет тәртібі және нәтиже де өзгереді.

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

Әр кірісті үш түрдің біріне белгілеңіз:

• replay жаңа шақырусыз қайтаруға тиіс жазылған факт;
• сол деректермен қайта орындауға болатын қайталанатын есептеу;
• әдейі қазіргі сыртқы әлемге жүгінетін тірі сұрау.

Replay үшін режим таңдаңыз. evidence режимінде агент сақталған LLM жауаптарын, tool output мәндерін және құжаттарды пайдаланады. simulation режимінде тест құралдары мен оқшауланған деректер көшірмелеріне рұқсат беріледі. live режимінде нақты шақыруларға болады, бірақ жаңа run жасалып, нақты рұқсатсыз қайтымсыз командаларға тыйым салынуы тиіс.

Мұндай режимсіз «replay» сөзі қауіпті. Инженер матч жазбасын аштым деп ойлайды, ал шын мәнінде ойыншыны алаңға қайта шығарады.

Тарихты тармақтау жаңа run_id мен анық шежірені талап етеді

Команда prompt-ты өзгерткенде, күйдегі мәнді түзеткенде немесе ескі checkpoint таңдағанда, ол бастапқы тарихты жалғастырмайды, балама тарих жасайды.

Тармақта кемінде мына төрт өрісті сақтаңыз:

{
  "run_id": "run_01K_new",
  "parent_run_id": "run_01J_original",
  "parent_checkpoint_id": "cp_0042",
  "launch_reason": "debug_after_tool_timeout"
}

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

LangGraph-та күйді жаңарту ескісін өзгертпей, жаңа checkpoint жасайды. Бұл дұрыс модель: өткен тарих тергеу үшін қолжетімді қалады, ал жаңа жол жеке бастапқы нүкте алады.

Оператор интерфейсіндегі командаларды мағынасына қарай бөліңіз:

• «Жалғастыру» тек бастапқы run-ның кідірісінде, ақауында немесе күтілетін әрекетінде қолжетімді;
• «Checkpoint-тен қайталау» әрқашан жаңа run жасайды;
• «Өзгеріспен тармақ жасау» күй айырмашылықтарын көрсетіп, себепті талап етеді;
• «Сыртқы әсерді қайталау» replay ішіне жасырылмайды, бұл бөлек артықшылықты команда.

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

Әсерлер журналы tool call трассировкасынан маңыздырақ

Трассировка модельдің құрал шақыруды сұрағанын көрсетеді. Әсерлер журналы жүйенің сыртқы әлемде не істегенін көрсетеді. Production үшін екіншісі әдетте маңыздырақ.

Әр жазбада әсер идентификаторы, команда түрі, нормаланған сұрау хеші, талпыныс уақыты, алушы идентификаторы, соңғы мәртебе және run/checkpoint сілтемесі болуы керек. Толық payload-ты қолжетімділік пен деректерді сақтау ережелері рұқсат ететін жерде ғана сақтаңыз. Жеке деректер үшін шифрланған қорғалған журнал және операторға арналған маскаланған көрініс жеткілікті болуы мүмкін.

«Құрал 200 қайтарды» дегенді бизнес әсерінің мәртебесімен шатастырмаңыз. API тапсырманы қабылдауы мүмкін, бірақ оны әлі аяқтамаған болуы ықтимал. Мысалы, құжат жіберу accepted қайтаруы мүмкін, ал хат кейін жіберілуі немесе алушы саясаты бойынша қабылданбауы мүмкін. Әр құралдың түсінікті келісімі қажет: әсер синхронды ма, соңғы мәртебені қалай білуге болады, оны effect_id арқылы сұрауға бола ма, сервис дедупликация кілтін қанша уақыт сақтайды.

Мұны кодты оқумен емес, авариялық тестілермен тексеріңіз. Нақты тест нысанын жасайтын құрал алыңыз. Сұрау жіберілгеннен кейін, checkpoint-ке дейін процесті әдейі тоқтатыңыз. Resume effect_id арқылы бұрын жасалған нысанды табуы немесе сол кілтпен бір нысанды сақтай отырып шақыруды қайталауы керек. Содан кейін тест ортасында checkpoint-тен replay іске қосып, оның бастапқы run-ды жалғастырмай, жаңа run жасағанына көз жеткізіңіз.

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

Код нұсқалары resume-ді желі ақауынан да байқатпай бұзуы мүмкін

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

Әсіресе бар interrupt алдына жаңасын қосу немесе runtime сақталған нәтижелермен сәйкестендіретін шақырулардың ретін ауыстыру қауіпті. LangGraph құжаттамасы resume нүктесіне дейін task пен interrupt ретін өзгерту сақталған мәнді басқа шақырумен байланыстыруы мүмкін екенін ескертеді. Аяқталмаған процестерді аяқтауды күту, жаңа логиканы жаңа task-ке шығару немесе entrypoint-тің жаңа нұсқасын іске қосу ұсынылады.

Практикалық ереже қарапайым: әр workflow-та run ішінде сақталатын workflow_version болсын. Runtime resume алдында үйлесімділікті тексеруі керек. Жаңа нұсқа ескі күйді оқи алмаса, болжам жасамауы тиіс. Ол күй миграциясын, ескі нұсқамен орындауды немесе қолмен талдауды ұсынуы керек.

{
  "run_id": "run_01J...",
  "workflow_name": "sales_offer_agent",
  "workflow_version": 7,
  "state_schema_version": 4,
  "status": "waiting_approval"
}

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

Қайталау саясаты құрал класына байланысты болуы керек

Барлық tool call үшін бір жаһандық retry баптауы дерлік әрқашан қате. Оқу, жазу және қайтымсыз әрекеттің тәуекелі әртүрлі.

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

LLM шақыруы автоматты түрде таза есептеу болып саналмайды. Ол дерекқорды тікелей өзгертпейді, бірақ кейінгі шешімді өзгертуі мүмкін. Жауап тек жоба үшін қолданылса, қайталау әдетте қолайлы. Ал ол сыртқы сервиске жіберілетін команданы анықтаса, бастапқы жауапты, tool call аргументтерін және таңдалған маршрутты сақтаңыз.

AI Router модель шақыруларына арналған бірыңғай OpenAI-үйлесімді шлюз бола алады, бірақ checkpoint, әсерлер журналы және идемпотенттілік бәрібір қолданбаның міндеті болып қалады. Прокси модельге сұрауды бағыттайды, бірақ хатыңыздың, төлеміңіздің немесе CRM жазбаңыздың тағдырына жауап бермейді.

Алдымен қауіпті батырманы алып тастаңыз, содан кейін графты күрделендіріңіз

Интерфейсте бір ғана «Retry» командасы болса, келесі инцидентке дейін оны ауыстырыңыз. Аяқталмаған операция үшін «Жалғастыру» атауын қолданыңыз. Тергеу үшін «Replay жасау» деп атаңыз. Сыртқы команданы қайта жеткізуге effect_id көрсетілетін және алушыдағы мәртебе тексерілетін бөлек операция жасаңыз.

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

Агенттің пайымдауы болжамсыз болуы мүмкін. Бірақ оның командаларының орындалуы олай болмауы керек.