Microsoft Foundry-ის აგენტები დავალებებს უკვე განრიგითაც შეასრულებენ

Microsoft-მა Foundry Agent Service-ის Routines 24 სექტემბრის განცხადებაში საერთო ხელმისაწვდომობაში გადაიყვანა. აგენტი შეიძლება გაეშვას ერთხელ, წინასწარ დანიშნულ დროს, განმეორებადი განრიგით ან მხარდაჭერილი გარე მოვლენის შემდეგ. Foundry იღებს ტრიგერს, რიგში აყენებს გამოძახებას და ინახავს გაშვების შედეგს. მარტივი ამოცანისთვის დეველოპერს ცალკე დამგეგმავის, რიგისა და აგენტამდე შეტყობინების მიმტანი კოდის შენარჩუნება შეიძლება აღარ დასჭირდეს.

WindowsForum-ის მიმოხილვა იმავე გამოშვებას აღწერს, როგორც დაგეგმილი და მოვლენაზე დამოკიდებული გაშვებების საერთო ხელმისაწვდომობას, თუმცა ყურადღებას ამახვილებს იდენტობისა და მხარდაჭერილი კონფიგურაციების საზღვრებზეც. პრაქტიკული განსხვავება ისაა, იწყებს თუ არა პროცესი მხოლოდ ერთი აგენტის მუშაობას, თუ შემდეგ რამდენიმე მოქმედების კოორდინაციასაც მოითხოვს. Routines პირველ შემთხვევას ემსახურება: იგი განსაზღვრავს გაშვების მიზეზსა და დროს, ხოლო უფრო რთული პროცესის ლოგიკა ცალკე რჩება.

დანიშნული დრო, განმეორებადი განრიგი და გარე მოვლენა

Microsoft Learn-ის ტექნიკური აღწერით, თითოეულ routine-ს ერთი ტრიგერი და ერთი მოქმედება აქვს; განმეორებადი განრიგის მინიმალური ინტერვალი ხუთი წუთია. მოქმედება ერთ prompt ან hosted აგენტს იძახებს. ერთჯერადი ტაიმერი კონკრეტულ მომავალ დროს ამოქმედდება და ამის შემდეგ უმოქმედო ხდება. განმეორებადი ტრიგერი cron-ის მსგავსი განრიგით მუშაობს, ამიტომ ის შეესაბამება ამოცანას, რომლის დაწყების დრო წინასწარ არის ცნობილი და მეორდება.

მესამე გზა გარე მოვლენაა. ამჟამად მხარდაჭერილია GitHub-ის issue-ს გახსნა ან დახურვა და Microsoft Teams-ის არხში ახალი შეტყობინება. მოვლენის მისაღებად Foundry-ის პროექტს შესაბამისი კავშირი სჭირდება; შემოსული მონაცემები შემდეგ აგენტის გამოძახებას უკავშირდება. პირობითად, ახალი GitHub issue შეიძლება აგენტს მისცეს დახარისხების წინადადების მომზადების საფუძველი. თავად წინადადების ხარისხი კვლავ აგენტის ინსტრუქციებზე, მის ხელმისაწვდომ მონაცემებსა და ხელსაწყოებზეა დამოკიდებული.

ეს სია განსაზღვრავს webhook-ინფრასტრუქტურის ჩანაცვლების ფარგლებს. თუ აგენტს სწორედ მხარდაჭერილ GitHub-ის ან Teams-ის მოვლენაზე უნდა უპასუხოს, მოვლენის მიღებისა და აგენტამდე მიტანის ცალკე სერვისის აწყობა შეიძლება აღარ იყოს საჭირო. სხვა სისტემიდან სიგნალის მისაღებად კვლავ საჭიროა გარე ინტეგრაცია; პერიოდული შემოწმება ალტერნატივაა მხოლოდ მაშინ, როცა ამოცანა დაყოვნებას იტანს. ზოგადი სახელწოდება „მოვლენაზე დამოკიდებული“ ნებისმიერი webhook-ის პირდაპირ მიერთებას არ გულისხმობს.

განრიგის შერჩევისას მნიშვნელობა აქვს დროის სარტყელსაც. პორტალში არჩეული დრო მომხმარებლის ბრაუზერის ადგილობრივ დროად განიმარტება, ხოლო API-სა და SDK-ში შესაძლებელია დროის სარტყლის ცალკე მითითება. საქართველოს გუნდს, რომელიც გაშვებას სხვა ქვეყანაში შექმნილ ან რედაქტირებულ პროექტში გეგმავს, ამ განსხვავებამ შეიძლება მოულოდნელი საათი მისცეს. ეს განსაკუთრებით მნიშვნელოვანია ყოველდღიური ამოცანისთვის, რომლის შედეგსაც კონკრეტული სამუშაო დღის დაწყებამდე ელიან.

რომელი იდენტობით გამოიძახება აგენტი

ნაგულისხმევად routine აგენტს მისი საკუთარი იდენტობით იძახებს. ამ შემთხვევაში აგენტის ხელსაწყოები იმ უფლებებით მუშაობს, რომლებიც ამ იდენტობას Microsoft Entra ID-ში აქვს მინიჭებული. თუ ხელსაწყოს მომხმარებლის დელეგირებული წვდომა სჭირდება, routine-ის შექმნისას შეიძლება შემქმნელის იდენტობის არჩევა. პირობითი მაგალითია აგენტისთვის გამოყოფილ რესურსთან საკუთარი იდენტობით მუშაობა და კონკრეტული პირის OAuth-წვდომაზე დამოკიდებული ხელსაწყოსთვის შემქმნელის იდენტობის გამოყენება.

აქ „შემქმნელი“ routine-ის შექმნისას გამოყენებულ პირს ან მომსახურების პრინციპალს ნიშნავს. ის ავტომატურად არც აგენტის ავტორია, არც მოგვიანებით routine-ის რედაქტორი და არც საბოლოო მომხმარებელი. არჩევანი შექმნისას ფიქსირდება: არსებული routine-ის რედაქტირებით გაშვების იდენტობა არ იცვლება. მის შესაცვლელად routine უნდა წაიშალოს და სასურველი იდენტობით ხელახლა შეიქმნას. ამიტომ იმ ანგარიშის უფლებები და თანხმობა, რომლის სახელითაც მოქმედება შესრულდება, კონფიგურაციის ნაწილია.

გარე მოვლენის კავშირს საკუთარი ავტორიზაცია აქვს. მაგალითად, GitHub-ის საცავზე ან Teams-ის არხზე კავშირის წვდომა დამოუკიდებელია იმ იდენტობისგან, რომლითაც Foundry შემდეგ აგენტს გამოიძახებს. შემქმნელის იდენტობის არჩევა ამ კავშირის უფლებებს არ ცვლის. თუ კავშირის მფლობელი შესაბამის რესურსზე წვდომას დაკარგავს, მოვლენის მიღება შეიძლება შეწყდეს მაშინაც, როცა აგენტის გაშვების იდენტობა გამართულია. ორივე უფლებამოსილება ერთი ავტომატიზაციის სხვადასხვა ეტაპს ემსახურება.

რას აჩვენებს გაშვების ისტორია

ტრიგერის ამოქმედებისას Foundry პროექტში ქმნის გაშვების ჩანაწერს, აგენტს მისი არსებული endpoint-ით იძახებს და სტატუსს ინახავს. ისტორიაში ჩანს მიღებული შეყვანა, პასუხი, დასრულების მდგომარეობა და ბმული აგენტის შესრულების კვალზე. ეს ჩანაწერები საშუალებას იძლევა გაირკვეს, საერთოდ ამოქმედდა თუ არა ტრიგერი და რა მოხდა აგენტთან გამოძახების შემდეგ. შეჩერებული routine-ის ხელახლა ჩართვა აგენტის თავიდან შექმნას არ მოითხოვს.

სტატუსის მნიშვნელობას ზღვარი აქვს: აგენტამდე მოთხოვნის წარმატებით მიტანა თავისთავად არ ამტკიცებს, რომ აგენტის მიერ დაწყებული ყველა ასინქრონული სამუშაო უკვე დასრულებულია. თუ აგენტი შემდგომ მოქმედებას სხვა სისტემაში იწყებს, საბოლოო შედეგი იმ სისტემის მდგომარეობითაც უნდა შეფასდეს. გაშვების ჩანაწერი ამგვარად კონკრეტული გამოძახების აუდიტს იძლევა; იგი გარეთ დაწყებული პროცესის სრული ისტორიის შემცვლელი არ არის.

პორტალში შესაძლებელია routine-ის ხელით საცდელი გაშვებაც, მომდევნო ტრიგერის დალოდების გარეშე. ამ დროს შესამოწმებელია, აღწევს თუ არა გამოძახება სწორ აგენტამდე და რა პასუხს აბრუნებს იგი. ხელით გაშვება მხოლოდ გაშვების გზას ამოწმებს: GitHub-ის ან Teams-ის რეალური მოვლენის მიღებას შესაბამისი კავშირის მუშაობა განსაზღვრავს. ამიტომ მოვლენის არმოსვლა და აგენტის წარუმატებელი პასუხი ისტორიაში სხვადასხვა პრობლემად უნდა გაირჩეს.

სად რჩება ცალკე ორკესტრაცია

Routine-ის ამოცანაა ერთი აგენტის დაწყება. თუ პროცესს პირობითი განშტოება, რამდენიმე აგენტის კოორდინაცია, ადამიანის თანხმობის ეტაპი ან რთული მდგომარეობის შენარჩუნება სჭირდება, ამ ლოგიკას workflow ან სხვა ორკესტრაცია სჭირდება. Routine პირდაპირ workflow აგენტს ვერ იძახებს, თუმცა მის მიერ გამოძახებულ hosted აგენტს საკუთარი შიდა სამუშაო პროცესი შეიძლება ჰქონდეს. ამიტომ გარე cron-ის მოხსნა და მთელი პროცესის ერთ routine-ში გადატანა სხვადასხვა გადაწყვეტილებაა.

წარმოებაში დანერგვაზე გავლენას ახდენს პროექტის რეგიონი და დაშიფვრის მოთხოვნაც. Routines ყველა რეგიონში ხელმისაწვდომი არ არის და მომხმარებლის მიერ მართული გასაღებით დაშიფვრას არ უჭერს მხარს; ვირტუალური ქსელით დაცულ პროექტებთან კი მუშაობს. ცალკე ფუნქციაა hosted აგენტის მიერ საკუთარი ხელახალი გაშვების დაგეგმვა reminder tool-ით. ის ჯერ წინასწარი წვდომის რეჟიმშია, ამიტომ Routines-ის საერთო ხელმისაწვდომობა მასზე არ ვრცელდება.

დეველოპერისთვის მთავარი შედეგი ინფრასტრუქტურის შემცირების კონკრეტული შესაძლებლობაა: მხარდაჭერილი დროის ან მოვლენის ტრიგერი, ერთი აგენტის გამოძახება, უფლებები და გაშვების ისტორია იმავე Foundry პროექტში თავსდება. სადაც საჭიროა სხვა მოვლენის წყარო ან რამდენიმე ეტაპის მართვა, გარე ინტეგრაცია და ორკესტრაცია პროცესის ნაწილად რჩება. ეს საზღვარი განსაზღვრავს, რომელი არსებული დამგეგმავის ან webhook-სერვისის ამოღება შეიძლება არქიტექტურიდან.