AI агенттерін оркестрлеу: ақаулар, мақұлдаулар және қайталаулар

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

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

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

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

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

Оркестраторға тапсырма бергеннен кейін не болатынын қарастырайық.

Perplexity-нің Computer семинарындағы мысалды қарастырыңыз: Salesforce, Snowflake, электрондық пошта, күнтізбе және соңғы жаңалықтардағы ақпаратты пайдаланып, клиенттер туралы аналитикалық бақылау тақтасын құру.

Мақсатты түсініп, жұмысты жоспарлаңыз. Оркестратор сұралған нәтижеден бастап, оны нақты тәуелділіктері бар тапсырмаларға бөледі. Біздің бақылау тақтасы мысалымызда бұл әртүрлі көздерден ақпарат жинап, оны дайын нәтижеге айналдыруды қамтиды. Жоспарлаушы қай қадамдар басқаларына тәуелді екенін және қайсысы дербес орындала алатынын анықтайды.
Тапсырмаларды тиісті агенттерге бағыттаңыз. Оркестратор тәуелділіктері орындалған тапсырмаларды анықтап, жұмысты мамандандырылған агенттерге немесе модельдерге тапсырады. Тәуелді тапсырмалар өздерінің алғышарттарын күтеді. Perplexity Computer бірнеше озық модельді пайдаланып, жұмыс процесінің әртүрлі бөліктерін сол тапсырмаларға сай келетін жүйелерге бағыттайды. Бұл сондай-ақ дербес жұмысты қатар орындауға мүмкіндік береді.
Құрал шақыруларын басқарылатын орталарда орындаңыз. Агенттер өз ортасымен веб-іздеу, API, қосылған қолданбалар, файл операциялары немесе код орындау сияқты құралдар арқылы өзара әрекеттеседі. Орындау деңгейі осы әрекеттерді іске асырып, нәтижелерді агенттерге қайтарады.
Нәтижелер мен контекстті агенттер арасында беріңіз. Агент өз тапсырмасын аяқтағаннан кейін, жалғастыру үшін келесі агентке тиісті нәтиже қажет. Тапсыру жазбасында тапсырма идентификаторы, нәтижеге сілтеме, схема нұсқасы және дереккөз метадеректері болуы мүмкін. Оркестратор келесі қадамдарға қажетті контекстті сақтай отырып, осы тапсыруларды үйлестіреді. Ең бастысы, агенттерге басқа әр агент жұмысының бүкіл тарихын өз контекст терезелерінде сақтаудың қажеті жоқ.
Орындау күйін агент контекстінен бөлек жазыңыз. Агенттер тапсырмаларды бастаған, аяқтаған немесе орындай алмаған сайын, орындау механизмі тапсырма күйлері, орындау әрекеттері, нәтижелерге сілтемелер және қалған жұмыс туралы ақпаратпен тұрақты жұмыс процесі жазбасын жаңартады. Бұл жазба оркестраторға жұмыс процесін әңгіме тарихынан қалпына келтіру үшін LLM-ге сүйенбей-ақ, барысты қадағалауға және үзілістерден кейін жұмысты жалғастыруға мүмкіндік береді.
Нәтижелерді тексеріп, әрі қарай не болатынын шешіңіз. Тапсырма нәтиже қайтарғанда, оркестрлеу деңгейі оның нәтижесі күтілетін келісімшартқа сай келетінін және келесі тапсырманың тәуелділіктері орындалғанын тексереді. Мәселе табылса, жұмыс процесі түзету үшін алдыңғы қадамға оралуы немесе кідіртілуі мүмкін. Әйтпесе, ол аяқталуға қарай жылжиды.

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

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

Демек, оркестрлеу үш жағдайда пайдалы:

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

Басқа жағдайларда оркестрлеу — жай ғана қымбат тренд. Агенттер көбейген сайын үйлестіру де көбейеді және токен шығындары артуы мүмкін.

«Мен әдетте ең қарапайым нұсқадан бастап, соның негізінде дамытамын. Егер біз қадамдарды білсек және олар қайталанатын болса, бұл, бәлкім, жұмыс процесі. Бірнеше агентті енгізуге себепті олардың жауапкершіліктері, рұқсаттары немесе пайдаланушылары әртүрлі болғанда ғана көремін», — дейді Josh Spilker, AirOps компаниясының іздеу маркетингі жөніндегі басшысы.

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

Агенттерді үйлестіруді құрылымдаудың үш кең таралған тәсілі бар — орталықтандырылған, орталықсыздандырылған және иерархиялық оркестрлеу. Дұрыс архитектураны таңдау бір сұраққа келіп тіреледі: Жұмысты кім басқарады және агенттер бір-бірімен қалай үйлеседі?

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

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

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

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

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

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

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

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

Бұл құрылым жұмыс процестері бір оркестратор тиімді басқара алмайтындай тым ауқымды болғанда көмектесе алады.

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

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

Бұл архитектуралар қалай салыстырылады:

Критерийлер	Орталықтандырылған	Орталықсыздандырылған	Иерархиялық
Орындауға жауапкершілік	Тапсыруды бір оркестратор басқарады	Агенттер әріптес агенттер немесе ортақ күй арқылы үйлеседі	Жауапкершілік оркестрлеу деңгейлері бойынша бөлінеді
Күйдің дәйектілігі	Бір басқару нүктесі арқылы үйлестіру оңайырақ	Нақты синхрондауды және қақтығыстарды өңдеуді қажет етеді	Тармақтар ішінде және олар арасында үйлестіруді қажет етеді
Ақауларды оқшаулау	Орталық контроллер маңызды тәуелділікке айналуы мүмкін	Жекелеген агенттер бір-біріне тәуелсіз істен шығуы мүмкін, бірақ ортақ инфрақұрылым маңызды болып қала береді	Қалпына келтіруге арналып жобаланса, ақаулар тармақтар ішінде шектелуі мүмкін
Саясаттардың орындалуын қамтамасыз ету	Ортақ бақылау шараларын орталықтан қолдануға болады	Саясаттар барлық қатысушылар арасында біркелкі орындалуы тиіс	Бақылау шараларын жаһандық және домен деңгейлерінде қолдануға болады
Операциялық күрделілік	Әдетте төменірек	Үйлестіру күрделірек	Бірнеше оркестрлеу деңгейіне байланысты күрделілік жоғарырақ

Тағы бір айырмашылықты түсінген жөн. Архитектура агенттерді кім үйлестіретінін анықтайды. Ал орындау үлгісі олардың тапсырмалары қалай алға жылжитынын анықтайды.

Орындаудың үш үлгісі бар:

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

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

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

Ақпарат жоғалатын агенттік тапсырулар. Оркестратор маманданған агентке жоспардың қысқаша мазмұнын береді, бірақ онда шектеулер, тәуелділіктер немесе іске асыру бөлшектері түсіп қалады.
Нәтижелерді мерзімінен бұрын біріктіру (fan-in). Кейінгі кезеңдегі агент алдыңғы кезеңдегі барлық тапсырмалар аяқталмай тұрып нәтижелерді біріктіре бастайды.
Ортақ күйдің детерминистік емес жаңартулары. Параллель агенттер нақты анықталған біріктіру семантикасынсыз бірдей күй кілттеріне жазады. Фреймворктің жаңартуларды қалай өңдейтініне байланысты бұл жазбалардың жоғалуына, деректердің қайталануына, ретке тәуелді нәтижеге немесе қайшы өзгерістерге әкелуі мүмкін.
Бақылау нүктесі мен жанама әсерлер арасындағы алшақтық. Тапсырма сыртқы операцияны орындайды, бірақ оның сәтті орындалғаны орындаушы процесс істен шыққанға дейін тұрақты түрде тіркелмейді. Қалпына келтіру кезінде оркестратор аяқталмаған тапсырманы көріп, оны қайта іске қосады.
Адам мақұлдағаннан кейін жалғастыру кезіндегі жарыс жағдайлары. Орындауды тоқтатып, қайта жалғастыру синхрондаудың өзіндік мәселелерін тудырады.
Делегаттау циклдері және қайталау әрекеттерінің күшеюі. Міндеттері бір-бірімен қабаттасатындықтан, тәуелділіктер тұйықталғандықтан немесе аяқтау шарттары анық болмағандықтан, агенттер жұмысты бір-біріне қайта-қайта береді.
Нұсқаулық деңгейіндегі шектеулерді орындау қауіпсіздігі деп қате түсіну. Оркестратор агенттерге белгілі бір ресурстарға кірмеуді немесе маңызды әрекеттерді орындамауды айтуы мүмкін, бірақ модельге берілген нұсқаулар операциялық жүйе рұқсаттарын, желілік шектеулерді немесе авторизация шекараларын мәжбүрлі түрде қолданбайды. Perplexity-дің қауіпсіздік инженериясы бойынша зерттеуі агенттердің тіпті зиянды нұсқауларсыз да заңды мақсаттарға жету барысында қауіпсіздік шекараларын неліктен бұза алатынын көрсетеді

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

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

Мысалы, анда-санда сәтсіз аяқталатын интеграциялық тестті түзетуге жауапты агент үшін келісімшартты былай анықтауға болады:

Мақсат: Тапсырысты рәсімдеу (checkout) API-інің тұрақсыз интеграциялық тестінің себебін анықтап, түзету.
Кіріс деректері: Тесттің бастапқы коды, CI ақауларының журналдары, соңғы коммиттер және тиісті қолданба коды.
Шектеулер: Тесттерді өшірмеңіз, тексерулерді (assertions) әлсіретпеңіз және қолданбаның қатысы жоқ әрекетін өзгертпеңіз.
Күтілетін нәтиже: Код патчы, түпкі себептің түсіндірмесі және тестті орындау нәтижелері.
Қабылдау критерийлері: Бұрын сәтсіз аяқталған тест қатарынан 10 рет іске қосылғанда сәтті өтеді және тиісті регрессиялық тест жинағы да сәтті өтеді.
Сәтсіздік шарттары: Түпкі себепті анықтау мүмкін емес, түзету регрессияларға әкеледі немесе қажетті тест ортасы қолжетімсіз.

Бірақ тағы бір маңызды бөлік бар: агент қашан тоқтауы керек?

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

CI мысалымызға оралайық. Мына тоқтату шарттарын анықтауға болады:

Сәтті аяқталу: Түзету қатарынан 10 тест іске қосылымынан және тиісті регрессиялық тест жинағынан сәтті өтеді.
Итерация шегі: Агент екіден көп түзету нұсқасын қолданып көре алмайды.
Орындау бюджеті: Мәселе шешілмей қалса да, агент 60 минуттан кейін тоқтауы керек.
Делегаттау шегі: Агент жұмысты тек бір маманданған агентке тапсыра алады, ал одан әрі субагенттерге делегаттауға болмайды.
Ішінара орындау: Егер екі әрекет те сәтсіз аяқталса немесе уақыт шегі өтіп кетсе, агент өз тұжырымдарын, енгізуге тырысқан өзгерістерін және тест нәтижелерін қайтарады.
Бөгелген орындау: Егер тест ортасы қолжетімсіз болса, агент сәтті аяқталды деп мәлімдеудің орнына тоқтап, кедергі туралы хабарлайды.

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

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

Мына мысалды қарастырыңыз: status: completed бүкіл жұмыс процесіне емес, агентке тағайындалған жұмысқа қатысты. Тесттер әлі pending күйінде болғандықтан, оркестратор соңғы нәтижені мақұлдамауы керек.

json

{
  "task_id": "fix-42",
  "status": "completed",
  "artifact_ref": "patch-17",
  "test_status": "pending",
  "blockers": []
}

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

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

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

Мысалы, CI агентіңіз тестті іске қосады, бірақ API сұрауының күту уақыты аяқталады. Тест іске қосылмай қалды ма, әлде CI қызметі оны кезекке қойып, жауапты жоғалтып алды ма?

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

Уақытша қателер (429, 503): Шектелген экспоненциалды кідіріс пен кездейсоқ ауытқуды (jitter) қолданып қайталаңыз және Retry-After берілген болса, оны ескеріңіз.
Валидация немесе рұқсат қателері (400, 403): Сол сұрауды қайталамай, тоқтаңыз немесе негізгі мәселені түзетіңіз.
Анық емес нәтижелер (ықтимал жазудан кейінгі күту уақытының аяқталуы): Операцияны қайта орындамас бұрын оның сәтті өткен-өтпегенін тексеріңіз.

Ескертпе: Қайталауға болатын қателердің өзіне де шектеу қажет. Әр құрал шақыруына күту уақытын орнатыңыз, қайталау әрекеттерінің санын және жалпы қайталау уақытын шектеңіз, сондай-ақ кірістірілген агенттер бір операцияны қайта-қайта іске қоса бермеуі үшін жұмыс процесінің жалпы соңғы мерзімін белгілеңіз. Егер тәуелділік қайта-қайта істен шықса, сұрауларды уақытша тоқтату үшін автоматты ажыратқышты (circuit breaker) қолданыңыз.

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

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

CI агентіміздің қайталау логикасының псевдокод түріндегі мысалы:

python

op_id = get_or_create_operation_id(
    task_id=task_id,
    patch_id=patch_id,
    action="start_ci_run"
)

try:
    return ci.start_run(commit, request_id=op_id)
except TimeoutError:
    run = ci.find_by_request_id(op_id)
    if run:
        return run

    if ci.supports_idempotency:
        return bounded_retry(
            lambda: ci.start_run(commit, request_id=op_id)
        )

    raise NeedsReconciliation(op_id)

Код туралы ескертпе: Мысал CI API іске қосылымдарды сұрау идентификаторы бойынша іздеуді қолдайды деп болжайды. request_id провайдер идемпотенттілікке нақты кепілдік берген жағдайда ғана қайталануларды болдырмайды. bounded_retry() — көрнекілік үшін берілген псевдокод. Өндірістік ортада қайталау әрекеттері операцияға арналған қайталау бюджетімен (ең көп әрекет саны немесе өткен уақыт) және жұмыс процесінің жалпы соңғы мерзімімен шектелуі керек.

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

Мұнда екі нәрсені теңестіру керек: әр тапсырмаға модельдің қаншалықты мүмкіндігі қажет және бір мезгілде қанша тапсырманы орындай аласыз. Екеуінің бірінде қателессеңіз, агенттер ортақ API квоталары үшін бәсекелесуі немесе тек қымбат пайымдау модельдеріне сүйенуі мүмкін.

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

Мысалы, Perplexity Computer-дің Effort Mode функциясы модельді қолмен таңдамай-ақ, тапсырмаға қанша күш жұмсау керектігін таңдауға мүмкіндік береді. Light, Standard, High немесе Ultra деңгейін таңдасаңыз, Perplexity оркестрлеуші модельді және оның пайымдау деңгейін автоматты түрде таңдайды. Содан кейін бұл оркестратор ішкі тапсырмаларды әртүрлі провайдерлердің модельдерін пайдалана алатын көмекші агенттерге тапсырады.

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

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

Ресурс тұтынуын болжамды ұстау үшін ресурс шектеулері мен жоспарлауды басқару құралдарын енгізіңіз:

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

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

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

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

Адамның мақұлдауын қажет ететін әрекеттер үшін орындауды тоқтатып, ұсынылған операцияны дәл күйінде сақтаңыз:

оның параметрлері
оның мақсатты ресурсы
оның коммиті немесе күй нұсқасы
тексерушінің шешімі

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

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

Spilker сондай-ақ мақсат ретінде қабылданатын толық автономды, басынан аяғына дейін жұмыс істейтін агенттер идеясын қолдамайды. «Менің ойымша, міндеттері нақты, рұқсаттары анықталған және тиісті кезеңдерде адам тексеретін бірнеше мақсатты агент құрған дұрыс. Осылайша толық бақылаудан бас тартпай-ақ тиімділікке қол жеткізесіз», — деп қорытындылайды ол.

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

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

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

OpenTelemetry-дің GenAI семантикалық конвенциялары бұл операцияларды сипаттаудың стандартталған тәсілін ұсынады. Мысалы, invoke_workflow жұмыс процесінің орындалуын, invoke_agent агент шақыруын, ал execute_tool құрал шақыруын білдіреді. Әр операцияны уақыты, күйі және тиісті метадеректері бар span ретінде жазуға болады.

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

plaintext

invoke_agent  generate_patch   OK
execute_tool  start_ci_run     OK  run_id=9812
execute_tool  get_ci_result    TIMEOUT

agent_response: "Success"

Орындау трассасының көрнекі мысалы.

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

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

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

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

Мұны тексеру үшін сынақ ортасында ақауларды әдейі енгізіңіз:

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

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

Мысалы, CI агентіңіз сынақ іске қосуды бастау үшін сұрау жібереді, бірақ API жауабының күту уақыты өтіп кетеді. Агент әрекетті қайталайды, сәтті жауап алады және Success деп хабарлайды. CI қызметін тексеріп, бір емес, екі сынақ іске қосу жасалғанын байқағанша бәрі дұрыс сияқты көрінеді.

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

Анықталған ақауларды регрессиялық сынақтарыңызға қосыңыз, сонда болашақ өзгерістер оларды қайта туғызбайды.

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

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

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

Шектеулерді бірнеше деңгейде орнатыңыз: құрал шақыруын қайталаудың ең көп саны, агент итерацияларының ең көп саны, делегациялау тереңдігі және жұмыс процесінің жалпы соңғы мерзімі. Қайталамас бұрын ақауларды жіктеңіз. Уақытша 429 жауаптары үшін Retry-After берілген болса, оны сақтаңыз. Әйтпесе, кездейсоқ ауытқуы (jitter) бар, шектелген экспоненциалды кідірісті (backoff) пайдаланыңыз.

Валидация немесе рұқсат қателерінен кейін өзгертілмеген сұрауларды қайталауды тоқтатыңыз. Егер төменгі деңгейдегі қызмет қайта-қайта істен шықса, автоматты ажыратқыш (circuit breaker) агенттердің қосымша жүктеме тудыруына жол бермейді.

Қалпына келтіру механизмі орындау ортаңызға байланысты. LangGraph-та PostgresSaver сияқты тұрақты checkpointer граф күйін thread_id бойынша сақтайды, бұл орындауды сақталған күйден жалғастыруға мүмкіндік береді. Temporal-да басқа воркер жұмыс процесін оның оқиғалар тарихын қайта ойнату арқылы қалпына келтіре алады. Қайта ойнату кезінде ол бұрын жазылған әрекет (activity) нәтижелерін қайта пайдаланады.

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

Бірдей репрезентативті тапсырмаларды бірнеше рет орындаңыз және pass@k (k әрекеттің кемінде біреуі сәтті ме) мен pass^k (k әрекеттің барлығы сәтті ме) көрсеткіштерін ажыратыңыз

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

ЖИ агенттерін оркестрлеу дегеніміз не?

ЖИ агенттерін оркестрлеу қалай жұмыс істейді: орындау механизмінің ішінде

ЖИ агенттерін оркестрлеуді қашан қолдану керек?

ЖИ агенттерін оркестрлеу архитектуралары және олардың артықшылықтары мен кемшіліктері

Орталықтандырылған оркестрлеу

Орталықсыздандырылған оркестрлеу

Иерархиялық оркестрлеу

Тізбекті, параллель және тапсыруға негізделген орындау

ЖИ агенттерін оркестрлеудегі жиі кездесетін ақаулар

Өндірістік ортада сенімділікті қамтамасыз ететін ЖИ агенттерін оркестрлеудің 7 үздік тәжірибесі

1. Тапсырма келісімшарттарын, қабылдау критерийлерін және тоқтату шарттарын нақты анықтаңыз

2. Оркестраторларды ықшам ұстап, құрылымдалған тапсыруларды міндеттеңіз

3. Жұмыс процесінің күйін тұрақты сақтап, контекст өсуін бақылаңыз

4. Ақауларды ескеретін қайталау әрекеттерін және қалпына келтірілетін құрал орындалуын жобалаңыз

5. Жұмысты нақты ресурс бюджеттері арқылы бағыттап, параллельдеңіз

6. Мақұлдауларды міндеттеп, агенттің орындалуын оқшаулаңыз

7. Нәтижелерді тәуелсіз тексеріп, қалпына келу әрекетін тестілеңіз

Не қате кеткенін анықтау үшін жұмыс процесін трассалаңыз

Нәтижені тәуелсіз тексеріңіз

Қалпына келуді тестілеу үшін ақауларды әдейі енгізіңіз

AI агенттерін оркестрлеу бойынша жиі қойылатын сұрақтар

Неліктен оқшауланған AI агенттері кәсіпорын ауқымында дұрыс жұмыс істемей қалады?

AI агенттеріндегі шексіз қайталау циклдарының алдын қалай алуға болады?

AI агентінің жұмыс процесін істен шыққаннан кейін қалай жалғастыруға болады?

AI агенттерін оркестрлеудің сенімділігін қалай тексеруге болады?