Loop, Interaction va Approval o‘rtasidagi chegara
-LLM avtonomligini oshirishdan oldin qaror qabul qilish va bajarish mas’uliyatini ajratish tajribasi-
Bir necha LLM funksiyalarini bosqichma-bosqich ishlashdan yagona oqimga birlashtirganimizda, dastlab keyingi funksiyani avtomatik chaqirishning o‘zi Agentic Workflow yaratish uchun yetarli deb o‘yladik. Ammo amalda zarur tuzilma shunchaki chaqiruvlar tartibidan iborat emas edi. U joriy holatda qaysi amallarni bajarish mumkinligini aniqlashi, zarur foydalanuvchi qarorlarini so‘rashi va foydalanuvchi tasdiqlagan natija haqiqiy bajariladigan obyekt bilan bir xil ekanini tekshirishi kerak edi. Ushbu qarorlar va tekshiruvlarni izchil bajarish uchun Workflow Loop, Domain Adapter, strukturaviy Interaction va snapshot asosidagi Approval o‘rtasidagi chegaralarni ajratdik.
1. Asos va muammo
Dastlab har bir funksiya mustaqil bosqich sifatida ishlardi. Foydalanuvchi ma’lumot kiritganda, bir bosqich natija hosil qilib, uni keyingi bosqichga kirish ma’lumoti sifatida uzatar va keyingi bajarilishni tanlardi. Natijalarni yaratish, tekshirish, o‘zgartirish va saqlash funksiyalariga ega bo‘lsak-da, umumiy oqimni ulash mas’uliyati baribir foydalanuvchida qolardi. Funksiyalar to‘liq edi, biroq maqsad darajasidagi bajarish tajribasi bo‘laklangan edi.
Bir nechta API’larni oldindan belgilangan tartibda oddiygina chaqirish yetarli emas edi. So‘rovlar foydalanuvchi qarorlariga qarab o‘zgarishi, avvalgi bosqichlar esa tekshiruv natijalariga asoslanib to‘ldirilishi yoki qayta bajarilishi kerak edi. Tarmoqlanishlar, qayta urinishlar va foydalanuvchi javoblarini kutishni oddiy sikllar va shart operatorlari bilan bog‘lash oqim kengaygani sari holatni boshqarish va davom ettirishni tobora murakkablashtiradi. Shu sababli joriy holat va keyingi amalni boshqarish uchun Agentic Workflow’ni joriy etdik. U zarur ma’lumotlarni so‘raydi, qaytarib bo‘lmaydigan operatsiyalardan oldin tasdiqni kutadi, so‘ng bajarilishni to‘xtagan joyidan davom ettiradi.
Agentic Workflow’ni loyihalashda birinchi ajratgan mas’uliyatimiz Workflow’ni bajaruvchi LLM bilan domen funksiyalarini bajaruvchi LLM mas’uliyati bo‘ldi. Workflow LLM joriy bajarilish holatidan keyingi amal nomzodini tanlaydi. Domen LLM har bir Tool ichida natijalarni yaratadi, tekshiradi yoki o‘zgartiradi. Agar Workflow LLM domen natijalarini yoki yakuniy Tool kiritmasini ham yaratsa, u tekshirilgan holatdan farq qiluvchi qiymatlarga murojaat qilishi mumkin. Aksincha, keyingi bosqichni hatto domen LLM belgilasa, bajarish qoidalari funksiyalar o‘rtasida takrorlanib ketadi. Shuning uchun Workflow Loop bajarish tartibi, kutish va davom ettirishni boshqardi. Domain Adapter domen Tool’ini chaqirishdan oldin joriy ruxsat etilgan amallar va Tool kiritmasini tekshirdi. Ushbu ajratish tufayli domen qoidalaridagi o‘zgarishlarni umumiy Workflow’ni o‘zgartirmasdan Adapter va Tool ichida boshqarish mumkin bo‘ldi.
2. Bajarish mas’uliyatlarini ajratish
Umumiy tuzilma umumiy bajarish protsedurasini muayyan biznes maqsadlaridan ajratadi. Workflow Loop bajarish tartibi, kutish va davom ettirishni boshqaradi hamda keyingi amalni belgilaydi. Domain Adapter biznes maqsadiga mos funksiyalarni tanlaydi va Domain Tool chaqiruvini tayyorlaydi. Interaction·Approval foydalanuvchi bilan Loop’ni bog‘laydi, Loop va Adapter esa Decision·Tool chaqiruv interfeysi orqali ulanadi. Ikki Session faqat identifikatorlar orqali bog‘lanadi; shu tariqa bajarishni boshqarish ma’lumotlari biznes natijalaridan ajratiladi.
사용자 -- Interaction / Approval --> Workflow Loop
Workflow Loop <-> Domain Adapter -> Domain Tool
Workflow Session: 실행 / 대기 / 재개 | Domain Session: 업무 결과 / 검증 / 버전Workflow Session joriy Decision’ni, kutilayotgan Interaction·Approval’ni va jarayon yakunlangan, muvaffaqiyatsiz tugagan yoki siyosat tomonidan bloklanganligini saqlaydi. Loop ushbu ma’lumotni o‘qib, Tool’ni chaqiradi yoki foydalanuvchi javobini kutadi, chaqiruvdan keyin esa muvaffaqiyat yoki xatolikni hamda keyingi bajarilish nuqtasini qayd etadi. Bu yerda Workflow holati biznes natijasining mazmunini anglatmaydi; u bajarilish qanchalik ilg‘orlaganini va jarayon nimani kutayotganini ko‘rsatadi. Loop biznes natijalarining ma’nosini talqin qilmaydi.
Domain Session muayyan biznes maqsadiga erishish jarayonida hosil qilingan natijalarni, natija versiyalarini, tekshiruv holatini va o‘zgartirish maqsadlarini saqlaydi. Adapter ushbu ma’lumotni o‘qib, qaysi Tool’ni bajarish va foydalanuvchi qarori zarur yoki zarur emasligini aniqlaydi, so‘ng yakuniy kiritmani tekshirilgan natijadan yig‘adi. Adapter shuningdek tasdiqlangan natija bajarilishi mo‘ljallangan natija bilan bir xil ekanini tekshiradi. Bu yerda Domain holati biznes jarayoni qanday natija hosil qilganini va ushbu natijaga ishonish mumkin yoki mumkin emasligini bildiradi.
Xulosa qilib aytganda, Loop “qanday aylanishni”, Adapter esa “hozir nima qilishga ruxsat berilganini” belgilaydi. Loop Decision turiga qarab umumiy qayta ishlashni tanlaydi, Adapter esa Domain Session’dagi tekshiruv natijasiga asoslanib, o‘zgartirish Tool’iga ruxsat berish yoki avval foydalanuvchi tasdig‘ini so‘rash kerakligini aniqlaydi.
2.1 Decision va Policy
Workflow Loop va Domain Adapter keyingi amalni Decision orqali almashadi. Adapter Policy orqali ruxsat etilgan amallarni hisoblab, Decision qaytarganda, Loop uni bajaradi. Decision Tool chaqiruvi, foydalanuvchi savoli, tasdiq so‘rovi, yakunlanish, xatolik yoki kutish holatini ifodalaydi. Policy Adapter qaytarishi mumkin bo‘lgan amallarni cheklaydi. Tekshiruv muvaffaqiyatsiz bo‘lsa, faqat o‘zgartirish Tool’iga ruxsat beriladi, tasdiqlanmagan o‘zgartirish Tool’lari esa bloklanadi.
Bu yerda LLM — Workflow LLM. Dastlab allow-and-block oqimini LLM’siz, faqat Policy qoidalari yordamida sinab ko‘rdik. Keyin Workflow LLM ruxsat etilgan amallardan birini tanladi yoki faqat qisqa niyatni taklif qildi. Adapter yakuniy Tool kiritmasini Domain Session’dan tekshirilgan natijani va Workflow Session’dan tasdiq ma’lumotlarini o‘qib yig‘di. Ushbu qiymatlarni LLM bevosita yozmaydi.
Mavjud bosqichma-bosqich ishlaydigan funksiyalarni ham qayta yozmadik. Tool Registry allaqachon tekshirilgan funksiyalarni chaqirishi va Workflow faqat Registry orqali bajarilishi uchun ularni o‘rab qo‘ydik. Bu yangi bajarish oqimini joriy etish bilan birga mavjud funksiyalarning xatti-harakatlarini taqqoslash imkonini berdi. Umumiy modullarni boshidanoq kuchli abstraksiyalash o‘rniga, keyingi qarorlarni qabul qilishdan oldin ularning kontraktlarini haqiqiy oqimlar ichida tekshirishga qaror qildik.
책임 기준 Workflow Loop는 실행 생명주기를, Domain Adapter는 업무 결과 해석과 허용 행동을, Domain Tool은 실제 기능 수행을 담당합니다.3. Strukturaviy Interaction
Bajarish mas’uliyatlarini ajratganimizdan so‘ng, foydalanuvchi kiritmasi kontraktidagi bo‘shliqlarni aniqladik. Dastlab Workflow foydalanuvchiga yuboriladigan savollarni o‘z ichiga olgan satrli xabarlarni qaytarardi. Bu oddiy savollar uchun yetarli edi, biroq variant tanlash, maqsadni ko‘rsatish yoki o‘zgarishlarni ko‘rib chiqish kabi foydalanish qulayligini oshiradigan aloqa usullarini ifodalash qiyin edi. Backend faqat savol kerakligini bildirardi, UI esa foydalanuvchi aslida nima qilishi kerakligini taxmin qilishi lozim edi.
Buni hal qilish uchun Interaction’ni ekran matni sifatida emas, foydalanuvchi amalining ma’nosi sifatida belgiladik. Biz type, target, options, required va boshqa maydonlardan iborat interfeysdan foydalandik. type Interaction oddiy kiritma, tanlash, ko‘rib chiqish yoki boshqa tur ekanini bildiradi, target esa javob qaysi ish natijasiga taalluqli ekanini aniqlaydi. options tanlash turidagi Interaction uchun tanlanishi mumkin bo‘lgan qiymatlarni o‘z ichiga oladi, required esa javobsiz jarayon davom etishi mumkin yoki mumkin emasligini ko‘rsatadi. UI ushbu kontraktni chat kiritmasi, tanlash kartalari yoki o‘zgarishlarni taqqoslash ekrani kabi kontekstga mos komponentlar orqali ifodalaydi.
{
"type": "REVIEW_DIFF",
"target": "result",
"required": true
}4. Snapshot Approval va holat
Foydalanuvchi qarorlari orasida ma’lumotlarni o‘zgartiradigan yoki tashqi operatsiyalarni bajaradigan Tool’lar kuchliroq tasdiq kontraktini talab qildi. Agar tasdiq yagona Boolean qiymat sifatida saqlansa, foydalanuvchi tasdiq tugmasini bosgani haqidagi faktgina qoladi. Qaysi holatda qaysi natija tasdiqlanganini bilib bo‘lmaydi. Demak, natija o‘zgartirilgan yoki uning tekshiruv holati almashtirilganidan keyin ham o‘sha tasdiq qiymatidan qayta foydalanish mumkin bo‘ladi.
Shu sababli tasdiqni bajarish maqsadining snapshot’iga bog‘ladik. Tasdiq ma’lumotlari maqsadli Tool, natija versiyasi va xeshi, tekshiruv natijasi xeshi hamda idempotency key’ni o‘z ichiga oldi. Bajarishdan bevosita oldin joriy natijani tasdiq berilgan paytdagi natija bilan taqqosladik. Maqsadli Tool, versiya yoki xeshlarning hatto bittasi farq qilsa ham, bajarish amalga oshirilmadi. Foydalanuvchi shunchaki “bajarilishi mumkin”ligini emas, balki aniq identifikatsiya qilinadigan muayyan natijani tasdiqladi.
Ushbu tekshiruv tasdiq berilgan vaqt bilan bajarish vaqti oralig‘idagi o‘zgarishlarning ham oldini oladi. Foydalanuvchi natijani ekranda ko‘rib chiqqanidan keyin boshqa so‘rov o‘sha natijani darhol o‘zgartirishi yoki so‘rov bajarish navbatida kutayotgan paytda tekshiruv natijasi o‘zgarishi mumkin. Shartlarni faqat tasdiq berilgan paytda tekshirish bunday o‘zgarishlarni aniqlamaydi. Bajarishdan bevosita oldin identifikatsiyani qayta tekshirish foydalanuvchi ko‘rgan mazmun haqiqatan saqlangan mazmun bilan bir xil ekanini ta’minlaydi.
실행 가능 = 승인됨
&& 대상 Tool 일치
&& 결과 버전 / 해시 일치
&& 검증 결과 해시 일치
&& 멱등성 키 유효Shuningdek, nomuvofiqliklarni Tool bajarilishidagi xatoliklardan ajratdik. Agar tasdiq mavjud bo‘lmasa, eskirgan bo‘lsa yoki joriy natijadan farq qilsa, Policy Tool chaqirilishidan oldin operatsiyani blokladi. Aksincha, ruxsat etilgan Tool chaqirilganidan keyin yuz bergan ichki yoki tashqi xatolik bajarilish xatoligi sifatida tasniflandi. Ushbu holatlarni ajratish xatolikni qayta urinib ko‘rish mumkinmi yoki foydalanuvchi qayta tasdiqlashi yoxud holat yangilanishi kerakmi, degan savolga javob berishni osonlashtiradi.
4.1 Audit va Idempotency
Tasdiq so‘rovlari, tasdiq natijalari, Tool chaqiruvlari va Policy bloklari Audit Events sifatida qayd etildi. Audit yozuvlari faqat keyinchalik ko‘rish uchun mo‘ljallangan loglarni anglatmaydi. Ular keyingi Decision’ga avvalgi bajarilish natijalarini talqin qilish va operatorlarga muayyan bajarilish nima sababdan davom etgani yoki to‘xtaganini aniqlash uchun asos beradi. O‘zaro bog‘liq hodisalarni bir xil bajarish oqimiga guruhlash foydalanuvchi javoblari va Tool natijalarini birgalikda kuzatish imkonini beradi.
Bir xil tasdiq so‘rovining ikki marta bajarilishiga yo‘l qo‘ymaslik uchun idempotency key’dan foydalandik. Tarmoq orqali qayta urinish yoki foydalanuvchining tugmani takroran bosishi yuz bersa ham, allaqachon qayta ishlangan key yana bajarilmaydi. Muhim jihat shundaki, idempotency tekshiruvini faqat Tool ichiga emas, balki tasdiq va bajarish kontraktlariga ham kiritdik. Shu tariqa Workflow nuqtayi nazaridan bir xil niyat faqat bir marta qayta ishlanganini tushuntirish mumkin bo‘ladi.
4.2 Doimiy holat
Dastlab Workflow holatining bir qismini so‘rovlar va javoblar orqali uzatdik. Bu qisqa funksional testlar uchun qulay edi, biroq sahifa yangilangandan, server qayta ishga tushirilgandan yoki uzoq tasdiq kutilganidan keyin ishonchli davom ettirishni kafolatlash qiyin bo‘ldi. Agar tasdiq va audit ma’lumotlari mijozda saqlanadigan holatga bog‘liq bo‘lsa, server uchun joriy bajarilishning vakolatli holatini mustaqil aniqlash ham qiyinlashadi.
Keyingi ishlarimizda Workflow Session, tasdiq va audit holatlarini JPA yordamida doimiy saqladik.
5. Qo‘llash mezonlari va xulosa
Ushbu ishda Agentic Workflow’ni loyihalashda quyidagi mezonlarga amal qildik. Birinchidan, bajarish sikli va domen qarorini ajratdik. Chegarani belgilashda mantiq biznes natijasining mazmunini bilishi kerakmi-yo‘qmi, deb tekshirdik. Agar u natijaning ma’nosini yoki ruxsat etilgan qoidalarni bilishi kerak bo‘lsa, uni Adapter’ga joylashtirdik; kutish, davom ettirish yoki yakunlash kabi biznes domenidan qat’i nazar takrorlanadigan protsedura bo‘lsa, uni Loop’ga joylashtirdik. Ushbu mezonsiz yangi oqimlarni qo‘shish Loop’dagi shart operatorlari va holat talqinining muttasil ko‘payishiga olib kelardi.
Ikkinchidan, LLM’ga ruxsat etilgan doirada amallarni taklif qilishga imkon berdik, biroq yakuniy Tool kiritmasini unga topshirmadik. Policy mumkin bo‘lgan amallarni hisoblaydi, Adapter esa tekshirilgan natija va tasdiq ma’lumotlaridan foydalanib kiritmani yig‘adi. Workflow LLM faqat shu doiradagi amalni tanlaydi; u yangi natija mazmuni yoki tasdiq qiymatlarini yaratmaydi. Ushbu ajratish qaysi qiymatlar LLM taklifi, qaysilari esa ilova tomonidan tekshirilgan fakt ekanini farqlash imkonini beradi. Avtonomlikni oshirish bajarish nazoratidan voz kechish bilan bir xil emas.
Uchinchidan, mazmunni foydalanuvchiga faqat satr sifatida uzatish o‘rniga, uni amal formati sifatida ifodaladik. Oddiy kiritma, tanlash va ko‘rib chiqish turlicha yo‘riqnoma va javob usullarini talab qiladi. type amal turini, target esa javob qaysi ish natijasiga taalluqli ekanini ko‘rsatadi. Tanlash talab etilganda, options mumkin bo‘lgan qiymatlarni, required esa javobsiz jarayon davom etishi mumkin yoki mumkin emasligini bildiradi. Strukturaviy Interaction’ning maqsadi UI’ni boshqarish emas, balki foydalanuvchi va Workflow o‘rtasidagi aloqa usulini aniqlashtirishdir.
To‘rtinchidan, tasdiqni tasdiq berilgan paytdagi bajarish maqsadining snapshot’iga bog‘ladik. Faqat tugma bosilganini saqlash tasdiqdan keyingi o‘zgarishlar yoki takroriy bajarilishning oldini ololmaydi. Maqsadli Tool, natija versiyasi va xeshi, tekshiruv holati hamda idempotency key bajarishdan bevosita oldin qayta tekshirilishi kerak. Shartlar mos kelmasa, Tool chaqirilmaydi va hodisa Policy bloki sifatida qayd etiladi. Aksincha, shartlar bajarilgandan keyin Tool ichida xatolik yuz bersa, u bajarilish xatoligi sifatida qayd etiladi. Ushbu natijalarni farqlash qayta tasdiq talab etiladimi yoki qayta urinish mumkinmi, degan savolni aniqlash imkonini beradi.
To‘xtatish va davom ettirish uchun zarur bo‘lgan Workflow Session, tasdiq va audit holatlarini keyingi ishlarimizda JPA yordamida doimiy saqladik.
Ushbu ishda Agentic Workflow’ni LLM chaqiruvlarini avtomatik zanjirlaydigan tuzilma sifatida emas, balki qaror qabul qilish va bajarish mas’uliyatini ajratadigan tuzilma sifatida tashkil etdik. Loop va Adapter rollarini ajratdik, Interaction orqali foydalanuvchi javoblari qaysi maqsadga taalluqli ekanini aniqlashtirdik va Approval orqali tasdiqlangan natijani haqiqiy bajarish maqsadi bilan moslashtirdik. Oxir-oqibat muhim bo‘lgan narsa LLM’ni ko‘proq ish qildirish emas, balki kim nimani va qaysi asosda baholashi hamda bajarish qaysi asosda amalga oshirilishini aniq belgilash edi.
DEVKC