AI-агент күйін сақтау: Redis, БД немесе журнал

Қадамдардың арасында күй қайда жоғалады

Мәселелер агент сұрауға жауап берген кезде емес, ол күтуі керек болғанда басталады. Бір сағаттық үзіліс, түн, қолмен мақұлдау — сол жерде процесте қалыпты күй қоймасы бар ма, әлде бәрі воркердің жадында және жолы болуға ғана сүйеніп тұр ма, бірден көрінеді.

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

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

Бұл әсіресе продакшенде байқалады, мұнда LLM шақырулары API-шлюз немесе кәдімгі OpenAI-үйлесімді эндпоинт арқылы өтеді. Модельге сұрау қалыпты өтуі мүмкін, бірақ шақырулардың арасындағы бизнес-қадам бәрібір бөлек өмір сүруі керек: Redis-те, БД-да немесе оқиғалар журналында.

Воркер қайта іске қосылғаннан кейін әдетте үш нәрсе бұзылады. Тұрақты қоймаға жазылмаса, ағымдағы қадам жоғалады. Жауапты 18:00-ге дейін мақұлдауды күтіп тұрмыз сияқты уақытша белгілер жоғалады. Бұрын сыртқы шақыру орындалды ма, жоқ па деген жергілікті есте сақтау да өшеді.

Таймауттан кейінгі дубльдер одан да байқалмай пайда болады. Бір сервис сұрауды жіберді, 30 секундта жауап күтпеді де, оны қайталады. Бірінші іске қосу жұмыстың жартысын жасап үлгеруі мүмкін, бірақ аяқталғаны туралы растау жоғалды. Екінші іске қосу сол тапсырманы алып, хатты қайта жібереді, екінші жазбаны жасайды немесе сыртқы API-ді қайта шақырады.

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

Агент нені есте сақтауы керек

Чат тарихы аздық етеді. Агентке жұмыс контексті керек: ол не істеді, қай жерде тоқтады және қай әрекетті қажетсіз қайталаусыз қайта жасауға болады.

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

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

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

Әдетте мынадай жинақ жеткілікті: кіріс деректер мен промпт нұсқасы, ағымдағы қадам мен статус, тапсырма иесі, сыртқы API, файлдар мен хабарламаларға арналған сұрау идентификаторлары, келесі мақұлдауға арналған пайдаланушы немесе топ, қате себебі және соңғы әрекет уақыты.

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

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

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

Redis қашан жеткілікті

Redis қысқа өмір сүретін және жиі оқылатын күйге жақсы келеді. Агент бірнеше қадамды қатар жасаса, қызметтің жауабын 30 секунд күтіп тұрса немесе қолмен растауды 10-20 минутқа тоқтата тұрса, көбіне соның өзі жеткілікті.

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

Redis қай кезде ыңғайлы

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

Бұл воркерге жақын тұруы тиіс жедел күйге сай келеді. Мысалы, контакт-орталықтағы агент деректерді жинап, LLM-ге шлюз арқылы сұрау жіберіп, жауаптың нобайын алып, оператордың жылдам мақұлдауын күтіп отыр. Пауза қысқа болса, Redis әдетте бөлек БД схемасынан қарапайым әрі жылдам.

Тағы бір плюс — TTL. Уақытша деректерге өмір сүру мерзімін бірден беріп, кейін қолмен тазалаудың қажеті жоқ. Уақытша сеанстар, rate limit, тапсырмаларды дедупликациялау және қысқа ретрайлар үшін бұл өте ыңғайлы.

Бірақ Redis-тің қатаң шегі бар. Егер күйдің snapshot-ын жасамасаңыз немесе оқиғаларды тұрақты қоймаға жазбасаңыз, тарих тым оңай жоғалады. Сәтсіздіктен кейін көбіне тек қазіргі мәнді білесіз, ал агент ол жерге неге келгенін білмейсіз.

Ұзақ күту де тез мәселе туғызады. Егер тапсырма бір күн, бір аптаға тұрып қалуы мүмкін болса немесе ескі іске қосуларды іздеу керек болса, Redis ыңғайсыз бола бастайды. Күрделі таңдаулар, аудит, күй нұсқаларын салыстыру және даулы жағдайларды талдау БД-да немесе оқиғалар журналында жақсырақ сақталады.

Қарапайым ереже мынадай: егер күй қысқа өмір сүрсе, жиі оқылса және толық тарих қажет болмаса, Redis жұмысты артық күрделіліксіз жабады.

Қашан кәдімгі БД жақсы

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

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

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

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

Бірақ мұнда да шектеу бар. Ағымдағы статусы бар бір жол жүйенің оған қалай келгенін түсіндірмейді. Көптеген тапсырма үшін бұл жеткілікті. Даулы шешімдер, қайта іске қосудар және аудит үшін — жоқ. Онда БД-ның қасына әдетте оқиғалар журналы немесе кемінде тарихтың бөлек кестесі пайда болады.

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

Қашан оқиғалар журналы қажет

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

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

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

Журнал қай кезде ақталады

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

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

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

Көлемі де тез өседі. Бұл әсіресе LLM-сценарийлерде байқалады, өйткені агент көп аралық қадам, модель жауаптары және қызметтік белгілер жазады. Сақтау мерзімін алдын ала белгілеу керек: нені бір ай, нені жарты жыл сақтау, ал нені архивке жіберуге болады.

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

Қосымша күрделіліксіз схеманы қалай таңдау керек

Күй қоймасын сәнге қарап емес, тапсырманың өмір сүру уақыты мен қатенің бағасына қарап таңдаған дұрыс. Процесс 30 секунд өмір сүрсе, талап бір бөлек. Өтінім екі күн мақұлдауды күтіп, кейін жалғасса, схема да басқа болады.

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

Таңдаудың қарапайым тәртібі

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

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

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

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

Егер қысқа ереже керек болса, ол мынадай:

• Redis — қысқа паузалар, блокировкалар және жылдам resume үшін.
• БД — ұзақ процестер, қолмен мақұлдау және жұмыс экраны үшін.
• Оқиғалар журналы — дәл replay және аудит үшін.
• Аралас схема — жылдам қолжеткізу де, толық тарих та керек болғанда.

Бастауды қарапайым нәрседен алған дұрыс. Көбіне run_id, status, current_step, updated_at, retry_count, approved_by және жазба нұсқасы жеткілікті. Маңыздысы кестелер саны емес, жаңарту ережелерінің түсініктілігі: статусты кім өзгертеді, агент қадамның бұрын орындалғанын қалай түсінеді және қайта іске қосылғанда не істеу керек.

Егер сұрауларды AI Router арқылы өткізіп, провайдерді немесе модельді SDK мен кодты өзгертпей ауыстыра алсаңыз, процестің күйін бәрібір модель қабатынан тыс сақтау дұрыс. Сонда маршрутты ауыстыру пауза, мақұлдау және қайта іске қосуды бұзбайды.

Өтінім мен қолмен мақұлдау мысалы

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

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

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

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

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

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

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

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

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

Өрістерді бөлек сақтаған сенімдірек: процестің статусы, қадам нөмірі, қадам кірісі, қадам нәтижесі, жаңарту уақыты, схема нұсқасы. Сонда қайта іске қосу болжаммен емес, анық ережелермен жүреді.

Тағы бір жиі қателік — күйді, кэшті және аудитті бір жерге үйіп тастау. Кэш қысқа өмір сүреді және ескіруі мүмкін. Аудит тарих үшін керек. Күй қазір қандай шешім қабылдау керегін көрсетуі тиіс: жалғастыру, күту немесе қадамды кері қайтару. Егер мұның бәрі бір жазбада жатса, агент ескі кэшті факт деп оңай қабылдайды, ал журнал қызметтік және бизнес-оқиғалардың араласпасына айналады.

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

Схема нұсқасы мен идемпотентті кілтсіз қайта іске қосу тез қауіпті болады. Агент хатты екінші рет жіберіп, ақшаны қайта есептен шығарып немесе CRM-де тапсырманы қайта құруы мүмкін. Қолмен мақұлдау бар жүйелерде бұл әсіресе жағымсыз: оператор бір рет растадым деп ойлайды, ал жүйе оны екі рет орындайды.

TTL-ді де жиі мақсатсыз қолданады. Егер жазба бірнеше сағат не күндік паузадан аман қалуы керек болса, TTL-ді архив деп санауға болмайды. Ол кэшке жарайды, бірақ процестің күйіне емес. Әйтпесе өтінім адам мақұлдауға қайта оралғанша жоқ болып кетеді.

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

Мықты жұмыс істейтін қарапайым схема мынадай: бөлек ағымдағы күй, бөлек аудит, бөлек кэш, әр жазбада схема нұсқасы және сыртқы әсері бар әр қадамда идемпотенттік кілт. Сонда қайта іске қосу болжам жасамайды, тек бір түсінікті әрекет орындайды.

Іске қосудың алдында жылдам тексеру

Продакшенге дейін сақтау схемасын идея деңгейінде таласпай-ақ қойыңыз. Оны қарапайым сәтсіздіктер мен қайталаулармен тексеріңіз. Бес қысқа тест көбіне ұзақ диаграммадан көп нәрсе көрсетеді.

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

Бірінші тест сенің сенім артуға болатын-болмайтын бірден көрсетеді. Егер рестарттан кейін тапсырма прогресті жоғалтса, Redis сізде, бәлкім, сенімді қойма емес, уақытша жады сияқты жұмыс істеп тұр. Кезек үшін бұл қалыпты. Ұзақ өтінім мен мақұлдау паузасы үшін — жоқ.

Мақұлдау кезіндегі пауза процесті ең үнсіз бұзады. Агент шешімді күтеді, бірақ әртүрлі адамдар әртүрлі көрініс көреді: операторда қадам тексеруде, воркерде таймаут, БД-да бос. Статусты 10 секундта таба алмасаңыз, өндірісте қолмен тексеру басталады.

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

Деректермен жалығып, қатаң болған дұрыс. Тіпті модельдерге шақырулар AI Router арқылы өтсе де, онда деректерді ел ішінде сақтау, PII бүркеу, аудит-логтар және кілт деңгейіндегі rate-limit бар болса да, өз қоймаңызды бәрібір бөлек тексеру керек. Көбіне шикі өрістер күй кестесінде, оқиға payload-ында немесе воркердің debug-log-ында қалып қояды.

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

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

Әрі қарай не істеу керек

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

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

Бастау үшін әдетте бес әрекет жеткілікті:

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

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

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

Егер агент AI Router сияқты шлюз арқылы әртүрлі LLM-ге шығып жүрсе, әр модельдік сұраудың идентификаторын тапсырмамен бірге сақтаңыз. Егер команда api.airouter.kz сияқты OpenAI-үйлесімді endpoint арқылы жұмыс істеп, тек base_url-ды өзгертсе, бұл негізгі ережені өзгертпейді: процестің шынайы көзі модельден бөлек өмір сүруі керек. Сонда провайдерді ауыстыру, ақауды талдау және жеке қадамдарды қауіпсіз қайта іске қосу жеңілірек болады.

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