Келісуден кейін агентті қайталама төлемсіз жалғастыру

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

Төлем, қайтарым, шарт жіберу, CRM-де мәміле жасау және тапсырыс күйін өзгерту бір ережеге бағынады: үзіліске дейін өзгермейтін ниетті сақтап, жалғастырғаннан кейін алдымен орындалу фактісін анықтау керек. Құралды тек осы тексеруден кейін шақыруға болады. «Келісу болды, демек қайталай беруге болады» деп санауға болмайды.

Үзіліс сыртқы шақырудың белгісіздігін жоймайды

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

Бұл күйді нақты атау керек: unknown. Ол жүйенің сыртқы өзгерістің болған-болмағанын білмейтінін білдіреді. Көптеген іске асырулар интерфейсті көрсету және retry құру оңай болғандықтан, бұл күйді failed деп жасырады. Кейін бухгалтерия екінші аударымды іздейді, ал команда екі воркердің қайсысы «шын мәнінде» кінәлі болғанын анықтауға тырысады.

Жанама әсері бар әрекеттің төрт бөлек сәті болады:

1. Агент ниетті қалыптастырды.
2. Адам дәл осы ниетті бекітті.
3. Сыртқы сервис шақыруды қабылдады немесе қабылдамады.
4. Қолданбаңыз нәтижені сенімді түрде жазды.

Үшінші және төртінші сәттің арасында ақау әрқашан болуы мүмкін. Сондықтан операциялар журналы диалог тарихынан, LLM трассировкасынан және тапсырмалар кезегінен бөлек болуы керек. Диалог агенттің неліктен әрекет ұсынғанын түсіндіреді. Журнал басқа сұраққа жауап береді: жүйе қандай өзгерісті жасауға тырысты және оның нәтижесі қандай болды.

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

Мәтіндік жауапты емес, ниет snapshot-ын келісу керек

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

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

{
  "operation_id": "op_01JQ8R7D9M4K",
  "action": "create_payment",
  "tenant_id": "org_482",
  "payload": {
    "invoice_id": "inv_9182",
    "beneficiary_id": "vendor_77",
    "amount_minor": 1250000,
    "currency": "KZT"
  },
  "policy_version": "payments-v3",
  "payload_hash": "sha256:7c4f...",
  "approval": {
    "status": "pending",
    "expires_at": "2026-07-23T16:00:00Z"
  },
  "tool": {
    "name": "payments.create",
    "idempotency_key": "op_01JQ8R7D9M4K"
  },
  "execution_status": "not_started"
}

Интерфейсте адам осы объектінің түсінікті көрінісін көреді: кімге, қанша, не үшін, қай заңды тұлғадан және қандай әрекет орындалады. Дерекқорда канондық объектінің өзі мен оның хеші сақталады. Мақұлдаудан кейін тек келісу күйі өзгереді. Төлем өрістерін жасырын түрде өңдеуге болмайды.

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

Құралдың идемпотенттілігі мен процестің идемпотенттілігі бір нәрсе емес

Идемпотентті API қайталанған сұрауды танып, екінші объект жасамауды біледі. Бұл пайдалы, бірақ сыртқы шақырудың бір ғана қасиеті. Идемпотентті процесс хабарламаның қайта жеткізілуіне, воркердің құлауына, қатар келген екі resume шақыруына, кешіккен webhook-қа және тапсырманы қолмен қайта іске қосуға төтеп беруі керек.

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

Практикалық ереже қарапайым: operation_id-ті қолданбаңыз алғашқы сыртқы шақыруға дейін жасайды. Идемпотенттілік кілті осы идентификатордан детерминирленген түрде шығарылады. Бір бизнес-әсер барлық retry кезінде бір кілтті қолданады. Жаңа бизнес шешімі, мысалы реквизит қатесі түзетілген төлем, жаңа operation_id және жаңа келісім алады.

Қате нұсқа мынадай:

# Әр retry жаңа операция жасайды. Бұлай жасауға болмайды.
key = uuid4()
payments.create(invoice_id=invoice_id, amount=amount, idempotency_key=str(key))

Жұмыс істейтін нұсқа идентификаторды шақыруға дейін сақтайды:

operation = db.get(operation_id)
key = operation.tool_idempotency_key
result = payments.create(
    invoice_id=operation.payload["invoice_id"],
    amount=operation.payload["amount_minor"],
    idempotency_key=key,
)

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

Операциялар журналы әрекетті, нәтижені және дәлелді сақтауы керек

approved = true деген бір жол жеткіліксіз. Нақты жанама әрекеттің өмірлік циклін сипаттайтын және ниеттің бастапқы snapshot-ын кейін өзгеріссіз сақтайтын жазба қажет.

Минималды модель әдетте мына өрістерді қамтиды:

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

Провайдер толық жауап қайтарғанға дейін external_id берген болса, оны бос қалдырмаңыз. Оны алған бойда бөлек қысқа транзакцияда сақтаңыз. Көптеген API үшін сұрау идентификаторы да, идемпотенттілік кілті де пайдалы. Мысалы, Stripe жауап тақырыбында request ID жариялайды және нақты шақыруды журналдардан табу үшін соны қолданады.

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

Resume алдымен күйді салыстырады, содан кейін жазуға болатынын шешеді

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

Төлемге, CRM жазбасына немесе тапсырыс күйін өзгертуге мына ретпен жұмыс істеу керек.

1. Compare-and-set немесе қысқа мерзімді аренда арқылы операция жазбасын бұғаттаңыз. Екі воркер бір тапсырманы қатар орындай алмауы керек.
2. Келісуді, оның мерзімін, payload_hash мәнін және саясат нұсқасын оқыңыз. Сәйкессіздік болса, операцияны cancelled күйіне ауыстырыңыз немесе жаңа келісу өтінімін жасаңыз.
3. Күй succeeded болса, сақталған нәтижені қайтарыңыз. Құралды шақырмаңыз.
4. Күй unknown болса немесе in_progress арендасы аяқталса, провайдерден external_id, идемпотенттілік кілті немесе бірегей сыртқы өріс бойынша lookup жасаңыз.
5. Салыстыру операцияның жоқ екенін дәлелдесе, күйді not_started мәніне қайтарып, содан кейін ғана бұрынғы кілтпен шақырыңыз. Нәтиже нақты болмаса, unknown күйін сақтап, жағдайды операторға беріңіз.

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

Маңызды әрекеттер үшін командаларды prepare, execute және reconcile кезеңдеріне бөліңіз. prepare деректерді тексеріп, ниет қалыптастырады. execute бір сыртқы шақыру жасайды. reconcile ештеңе жасамайды, тек күйді оқып, журналыңызды нақты фактпен сәйкестендіреді. Осы үш рөл pay_invoice() функциясына біріктірілсе, диагностика кезінде қайта іске қосу жанама әсерлер жасай бастайды.

Келісуден кейінгі төлем retry емес, салыстырып тексеру айналасында құрылуы керек

inv_9182 шоты 12 500 KZT болсын. Агент ережелерді тексеріп, op_01JQ8R7D9M4K ниетін дайындады және келісім алды. Ол күйді in_progress деп өзгертті, op_01JQ8R7D9M4K кілтімен POST жіберді, бірақ жауапқа дейін байланыс үзілді.

Қате іске асыру resume кезінде аяқталмаған қадамды көріп, сол POST-ты, кейде жаңа кілтпен, қайта жібереді. Банк идемпотенттілікті қолдамаса немесе кілт өзгерсе, екінші аударым пайда болады. API кілтті қолдаса да, команда кілтті сақтау мерзімі өтіп кеткенде, сұрау денесі сәйкес келмегенде немесе делдал тақырыпты жеткізбегенде ғана мәселені байқайды.

Дұрыс іске асыру былай әрекет етеді:

operation_id: op_01JQ8R7D9M4K
status: unknown
provider_lookup:
  reference: op_01JQ8R7D9M4K
  result: payment_78431, status=accepted
local_update:
  status: succeeded
  external_id: payment_78431
  evidence: provider lookup at 2026-07-23T14:18:09Z

Осыдан кейін агент пайдаланушыға төлемнің қабылданғанын хабарлап, екінші POST жасамайды. Егер lookup «табылмады» деп қайтарса, жүйе сол кілтпен сұрауды қайталай алады, бірақ провайдер шарты мұндай мағынаны тікелей анықтаса ғана. Провайдер сілтеме бойынша іздеуді де, идемпотентті жасауды да ұсынбаса, оның API-ін автономды төлемдер үшін қолданбаңыз. Қолмен салыстырып тексеруді енгізуге немесе интеграцияны ауыстыруға тура келеді.

Техникалық қатені бизнес шешімінің күшін жоюмен шатастырмаңыз. Дұрыс емес ЖСН немесе жабық шот салдарынан болған 400 қатесі бекітілген ниетті орындауға болмайтынын білдіреді. Реквизитті жай түзетіп, ескі келісіммен қайта шақыруға болмайды. Түзетілген реквизиттер әрекет объектісін өзгертеді.

CRM де қайтымсыз салдар тудырады

Командалар CRM-ді жиі қауіпсіз аймақ деп санайды: «Контакт дубликат болып кетсе де, ақша емес қой». Іс жүзінде қос лид екі хат тізбегін іске қосып, есептілікті өзгертіп, клиентті әртүрлі менеджерлерге бекітіп, сату бөліміне қосымша қол жұмысын жасайды. Ал мәміле кезеңін қайта өзгерту webhook арқылы биллингке, қолдау қызметіне немесе қолжетімділік жүйесіне хабар жіберуі мүмкін.

Объект жасағанда CRM объектімен бірге сақтайтын бірегей сыртқы идентификаторды қолданыңыз. Мысалы, agent_operation_id = op_01JQ8R7D9M4K. resume кезінде алдымен осы өріс бойынша жазбаны іздеңіз. Бір жазба табылса, external_id мәнін тіркеп, операцияны аяқтаңыз. Бірнеше жазба табылса, «ең жаңасын» таңдамаңыз. Бұл деректер инциденті, оған бөлек шешу ережесі қажет.

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

{
  "operation_id": "op_01JQ8R7D9M4K",
  "action": "crm.update_deal",
  "target": "deal_442",
  "expected_version": 19,
  "patch": {
    "stage": "contract_sent"
  }
}

CRM нұсқа қайшылығын қайтарса, агент карточкадағы жаңа деректермен PATCH-ті қайта жібермеуі керек. Ол не өзгергенін көрсетіп, жаңа шешім сұрауы тиіс. «Мәмілені келісімшарт кезеңіне ауыстыру» келісімі сома мен жауапты менеджер өзгергеннен кейін де оны ауыстыруға келісім дегенді білдірмеуі мүмкін.

«Барлық tool calls идемпотентті болсын» деген кеңес мұнда жеткіліксіз. Жазба жасауды сыртқы идентификатор арқылы идемпотентті етуге болады. Жазбаны өзгерту үшін оған қоса нұсқаны бақылау қажет. Жою, хат жіберу және иесін ауыстырудың өз шарттары бар. idempotent: true деген бір ортақ жалауша айырмашылықтарды жасырып, қауіпсіздік туралы жалған сенім қалыптастырады.

Webhook сыртқы фактіні растайды, бірақ журналды алмастырмайды

Провайдер төлемді асинхронды түрде қабылдауы мүмкін. CRM 202 Accepted қайтарып, объектіні кейін жасауы ықтимал. Мұндайда webhook салыстырып тексеруді аяқтауға көмектеседі, бірақ webhook-тың өзі де қайталанып, кешігіп немесе басқа ретпен келуі мүмкін.

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

Жақсы схема webhook-ты шексіз күтпейді. Операцияның белгілі бір мерзімі болады. Осы мерзім өткенде воркер reconcile іске қосады: провайдердегі күйді оқиды, келген оқиғаларды ескереді және түсінікті қорытынды қалдырады. Егер API соңғы күйді тек көшірме немесе қолмен басқарылатын кабинет арқылы берсе, бұл шектеуді дизайнда ашық көрсету керек. Мұндай интеграцияларда түсініксіз жіберілімнен кейін автоматты resume жасауға болмайды.

Тексеру процесті ең қолайсыз жерлерде тоқтатуы керек

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

Автоматты тестерге арналған ең аз сценарийлер:

• HTTP сұрауы жіберілгеннен кейін, бірақ жауап сақталғанға дейін процесс тоқтады;
• екі воркер бір resume сигналын қатар алды;
• келісім мерзімі өткеннен кейін келді;
• адам өтінімнің жаңа нұсқасында соманы немесе алушыны өзгертті;
• webhook екі рет және қолмен жасалған салыстырудан кейін жеткізілді.

Әр тестте тек соңғы күйді тексермеңіз. Құралдың қанша рет шақырылғанын, payload_hash өзгермегенін, сыртқы объектінің бірегейлігін және lookup жасалмай тұрып unknown жазбасының қайталанған шақыруға айналмағанын тексеріңіз.

Production ортасында unknown операцияларына, салыстырып тексеруге дейінгі уақытқа, CRM нұсқасы қайшылықтарына, қайта келісулерге және қолмен талданған жағдайлар санына метрикалар қосыңыз. unknown санының күрт өсуі әдетте желідегі мәселені, тайм-ауттарды немесе провайдер API-індегі өзгерісті көрсетеді. Қайта келісулердің көбеюі агент әрекетті тым ерте қалыптастырып, адамды тым ұзақ күтетінін білдіруі мүмкін.

Егер модель қабатыңыз AI Router арқылы жұмыс істесе, бұл схема өзгермейді: ұсынысты қай модель дайындағанына қарамастан, сервисіңіз операциялар журналын сақтап, детерминирленген resume орындауы керек.

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