Hozirgi kunda “AI agent” degan so'zni juda tez-tez eshitamiz. Dastlab bu oddiy bir modaga o'xshagandek tuyuldi, lekin turli mijoz muhitlarini tajribasidan o'tish jarayonida “bizning muhitimizga mos va xavfsiz ishlaydigan ish agenti mexanizmi kerak” degan talabning aniq oshayotgani haqida o'ylashimga sabab bo'ldi.
Shu fonda, hozirgi ish jarayonimizga mos keladigan DevOps vazifalarini ko'zda tutib, Ops agentini bitta orqa xizmat sifatida amalga oshirish haqida o'ylashni boshladik. Haqiqiy ishlab chiqish jarayonida OpenAI Codex kabi kodlash agentlarining yordamidan foydalanib, amalga oshirishni davom ettirdik.
Biroq, yaratsa bo'lganda, tezda to'qnashadigan savollar paydo bo'ladi.
“O'z-o'zidan qaror berishga ruxsat beramiz, lekin qadar qanchalik ruxsat beramiz?” “Xato qilganda qanday to'xtatamiz?” “O'rta jarayon ishonchli tarzda kuzatilishi mumkinmi?”
Boshida oddiy “savol → vosita chaqirish → javob” bilan boshlang'ich bo'lgan, lekin haqiqiy so'rovlar murakkablashishi bilan quyidagi muammo takrorlanmoqda.
- Nazorat yaxshi o'tmoqda, lekin choralar tabiiy ravishda davom etmayapti
- O'rta hukm berilganmi yoki faqat belgilangan retseptga rioya qilinganligi noma'lum
- Chiqish amalga oshirilganga o'xshaydi, lekin bajarilish natijalari nozik farq qiladi
- Xuddi muammolarni yana o'rganishda faqat loglardan sabablarni aniqlash qiyin
Ushbu maqola o'sha tajribalar orqali tuzilgan hozirgi arxitektura va mexanizm, shuningdek nima uchun bunday loyihalanganligi haqidagi yozuvdir.
Rivojlanishda amal qilishni xohlagan prinsiplar
Avval prinsiplarni aniqlab oldik. Agar prinsiplar qimirlaydigan bo'lsa, amalga oshirish tez ko'rinishda bo'ladi, lekin natijada qayta ishlash (refactoring) ko'payadi.
- Asosiy (runtime/flow/resolver) ga domenni qattiq kodlash taqiqlanadi
- Harakatni boshqarish kod bo‘laklaridan ko‘ra shartnoma/ siyosatning deklarativ tashqi qayta ishlanishiga ustunlik beradi
- Harakat must be autonomous, but only within the guardrails
- Naqting sharhlar va jarayonlarni ham tasdiqlash/ko'rish mumkin bo'lishi kerak
Asosiy narsa “mustaqillik” va “nazorat”ni qarama-qarshi qo'ymaslikdir. Mustaqillik - bu qarorlarning moslashuvchanligi, nazorat esa muvaffaqiyatsizlikning doirasini kamaytirish vositasidir.
Mimariy o'xshashlik
Ishga oshiriladigan tartibda tuzilgan namunalar quyidagilardir.
LLM + Tools + State + Control + Guardrails
Va harakat mexanizmi quyidagi to'rtta o'qqa asoslanadi.
Dinamik reja + qat'iy tekshirish + holat o'tkazilishi shartnoma + kuzatish/feedback
holat o'tish asos ijro(Davlat Mashinasi)Diyagrafрем
1) Dinamik reja: 'Nimani qilish kerakligini' belgilamaydi
Foydalanuvchi so'rovlar har doim mukammal tuzilgan holda kelmaydi. Masalan, “ilmiy tarqatish holatini tekshirib, choralar ko'ring” holati, holatni tasdiqlashdan tortib, yumshatish choralarigacha keng doirani o'z ichiga oladi.
Bu erda muhim narsa, dastlabki barcha bosqichlarni qattiq kodlashmaslikdir. Buning o'rniga, Planner hozirgi so'rov va kontekstga qarab reja tuzadi va kerakli imkoniyatlarni tanlaydi.
Faqat 'istalganini tanlash' imkoniyatini berish xavfli, shuning uchun tanlanadigan imkoniyatlar katalog bilan cheklanadi. Ya'ni, dinamik, lekin cheksiz emas.
Misol uchun, kubernetes ni ko'rishi mumkin bo'lgan imkoniyatlar kabi oldindan tayyorlangan katalogdan tanlab bajarilishi mumkin.
2) Qattiq tekshirish: reja amalga oshirilishidan oldin albatta filtrlashdan o'tadi
Reja chiqishi bilan darhol amalga oshirilmaydi. Preflight bosqichida shartnoma tekshiriladi.
Tekshirish nuqtalari taxminan bunday bo'ladi.
- Ruxsat etilgan imkoniyatlar ro'yxatida bormikan?
- Majburiy oldingi qobiliyat yo'qmi
- Ijro uslubi (tsikl/resepti/shartli va boshqalar) shartnoma bilan mos keladimi
- Argument referenciya talqin qilinishi mumkinmi
Bu bosqichning muhim sababi shundaki, “ijro paytidagi nosozlik”ni “ijrodan oldin rad etish/tuziq qilish”ga o'zgartirish mumkin. Haqiqatan ham mavjud bo'lmagan qobiliyatlar, etishmayotgan muhim argumentlar kabi muammolar shu vaqtni to'g'ri utilizatsiya qilishda sarf-xarajatni kamaytirishga yordam beradi.
3) Holat o'tishi shartnomasi: bosqichma-bosqich darvozalarni ko'rsatadi
So'rovni bitta chiqish sifatida ko'rmaymiz, balki holat mashinasi sifatida faoliyat yuritamiz.
Namuna oqimi:
- rejalashtirilgan
- preflight_validated
- ijro etish
- tugallangan / ruxsat kutmoqda / muvaffaqiyatsiz / rad etildi
Bu yerda asosiy narsa “qachon keyingi holatga o'tishimiz mumkinligi”ni shartnoma sifatida belgilashdir. Ayniqsa, harakatni o'z ichiga olgan so'rovlar faqat o'qish rejimida tugasa, foydalanuvchi kutishlariga ziddir.
Shuning uchun rivojlantirish va sinov o'tkazish jarayonida quyidagi shartnomalarni asta-sekin mustahkamlab boramiz.
- Agar g'alati signal paydo bo'lsa va foydalanuvchi harakat rejasini o'z ichiga olsa, action branchni qayta rejalashtirishga undaydi.
- Yuqori xavf chorasi waiting_approval ga o'tkaziladi
- Tasdiqlash ma'lumotlarining yaxlitligi tekshirilmasa, darhol rad etiladi
4) Kuzatuv/Fikr: Natijalarni ko'rayotganda kechikadi
So'rov birliklari qisqa tahlil optimallashtirish uchun jurnal tizimini o'rnatish va funksionallik yangilanishi bilan doimiy ravishda to'ldirish kerak.
- request-analysis: holat o'zgarish yo'li, muvaffaqiyatsizlik sababi, LLM chaqiruvi soni va boshqalar
- request-answer: oxirgi javob
Bu usulning afzalliklari xarajatning pastligi va operatsiya davomida sabablarni tezda aniqlash imkoniyatidir. Kamchiliklari esa o'rta oqim voqealarini to'liq qayta tiklash qiyinligidir.
Sh nonetheless, hozirgi maqsad (samara/sifat tahlili) uchun yetarlicha samaralidir. Ayniqsa, tez muammo tahlili uchun quyidagi savollarga tez javob berish mumkin bo'lishi kerak.
- Nima uchun failed/rejected bo'ldi
- Qanday qobiliyatda to'xtab qolindi
- LLM chaqiruvlari nega oshdi
- Oxirgi javob ijro natijasiga mos keladimi
“Shartnoma asosida” mustaqillik bilan to'qnashuvdami?
Bunday o'ylar ko'p marta bo'lib o'tdi va xulosani aytadigan bo'lsam, to'qnashuv olmaydi. Aksincha, o'zaro to'ldiruvchi hisoblanadi.
- Avtonomiya: qaysi imkoniyatlar kombinatsiyasini tanlash, qanday tartibda qayta rejalashtirish kerakligini
- Shartnoma: nimalar taqiqlangan / majburiy, qaysi holat o'tishlariga ruxsat berilgan
Agar shartnoma bo'lmasa, muvaffaqiyatga erishish oson bo'ladi. Muvaffaqiyat bo'lmasa, shartnoma oddiygina statik ish jarayoni bo'ladi.
Amalda “shartnoma asosidagi to'siqlarda o'z-o'zini boshqarish” eng muvozanatli tuzilma deb o'ylayman.
Hozirgi jarayon holatini qisqacha aytsak
Yaxshilangan jihatlar:
- Holat o'tishi/xato sababi/chaqiruvlar tahlili amalga oshirildi
- o'qish uchun faqat/ma'qullash/harakat chegaralari aniqlashtirildi
- Ba'zi takroriy tsikllar va keraksiz chaqiruvlar kamaydi.
Hali ham qoldiq nuqta:
- “Harakat qiling” turidagi so'rovlar uchun harakatdan oldin bajargan ishlar foizini oshirish kerak.
- Javob formatining izchilligi (ayniqsa bo'lim chegaralari) yanada mustahkam bo'lishi kerak.
- Shartnoma asosidagi qayta rejalashtirish siklining universalligini oshirish kerak.
Ya'ni, 'harakatga o'tadi' dan 'kutilganidek barqaror harakatga o'tadi' ga o'zgarish jarayonidamiz.
Tugallash
Agent yaratganda, model samaradorligi haqida gapirish oson. Ammo operatsion agentda yanada muhim bo'lgan narsa tuzilma ishonchlilikdeb hisoblayman.
- reja vaziyatga mos ravishda moslashi kerak
- Ijro oldin tasdiqlanishi kerak
- Holat o'tishi shartnoma bilan boshqarilishi kerak
- Natija bilan birga jarayon ham kuzatilishi kerak
Ops Agent universal agent bo'lish maqsadida quyidagi bosqichlardan o'tdi.
- Stsenariyani mustahkamlash bosqichi
Dastlab, scenarioId/scenarioType atrofida oldindan belgilangan oqimni barqaror bajarishga e'tibor qaratdik. Afzalligi - bashorat qilinishi mumkinligi, cheklovi esa yangi talablar uchun moslashuvchanlikning pastligidir.
- Shartnomaga asoslangan nazorat bosqichi
Keyin capability katalogi, preflight tekshiruvi, tasdiqlash darvozasi, javob shartnomasini qo'shib, “nima qilish mumkin/ mumkin emas”ni aniq boshqarishni boshladik. Bu bosqichda barqarorlik oshdi, lekin hali ham reja retseptga yaqin holatlarda bo'lgan.
- Hozirgi: Gard rail + shartnoma asosidagi avtonom orkestratsiya
Hozirda dinamik rejalashtirishni asosiy qilib olamiz va qat'iy tekshirish va holat o'tkazish shartnomasi (masalan: rejalashtirilgan → tasdiqlangan → bajarilayotgan → tasdiq kutmoqda/tamomlangan) orqali ijro etishni boshqaramiz. Shuningdek, kuzatuv jurnali orqali muvaffaqiyatsizlik sabablari va takrorlanuvchi shablonlarni kuzatib borib, rejalashtirish tsikllarini bosqichma-bosqich rivojlantirib bormoqdamiz.
Hali yo'l uzoq. Shunga qaramay, ssenariy moslamasidan boshlanib, shartnoma markazli nazorat orqali, hozirgi xavfsizlik chiziqlari + shartnomaga asoslangan avtonom orkestratsiyaga o'tish orqali "tushuntiriladigan ijro" yaqinlashganimizni o'ylayman.
To'liq emas, balki yaxshilash jarayoniga yaqin, lekin asosni yaratish uchun harakat qilmoqdaman va kelajakda ham shu printsip asosida kichik sinovlar o'tkazib, aniq kengayishga reja tayyorlayapman.
Andy