CrewAI თუ AutoGen: აგენტების როლები თუ საუბრის მოქნილი მარშრუტი

თუ კვლევისა და ანალიზის ეტაპები წინასწარ ცნობილია, CrewAI-ში სამუშაოს როლებად, ამოცანებად და მართულ Flow-დ გაყოფა უფრო პირდაპირი არჩევანია. თუ შემდეგი მონაწილე მიღებულ პასუხზე უნდა იყოს დამოკიდებული, AutoGen AgentChat-ის საუბარზე აგებული გუნდები უკეთ ერგება ამ მარშრუტს. CrewAI-ის დოკუმენტაცია განასხვავებს აგენტების თანამშრომლობასა და Flows-ს, რომლებშიც შესაძლებელია განშტოება, მდგომარეობის მართვა და შესრულების შენახვა.

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

როგორ ირჩევა შემდეგი ნაბიჯი

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

AutoGen AgentChat-ში კონტროლის ფორმა გუნდის შაბლონით იცვლება. RoundRobinGroupChat მონაწილეებს დადგენილი რიგით რთავს, SelectorGroupChat კი შემდეგ მოსაუბრეს მოდელის დახმარებით არჩევს. Swarm-ში აგენტი დავალებას HandoffMessage-ით გადასცემს სხვა მონაწილეს; MagenticOneGroupChat უფრო ღია ამოცანებისთვისაა შექმნილი. ამ შაბლონებს საერთო საუბრის კონტექსტი აქვთ, თუმცა დეველოპერი მაინც ადგენს მონაწილეებსა და შეჩერების პირობას. მოდელის მიერ მოსაუბრის არჩევა მოქნილობას იძლევა, მაგრამ წინასწარ განსაზღვრულ რიგთან შედარებით მარშრუტის პროგნოზირება რთულდება.

ერთი კვლევა–ანალიზის პროცესი ორ არქიტექტურაში

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

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

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

მდგომარეობა, შეცდომა და ადამიანის დასტური

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

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

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

რას ზომავს latency-ისა და token-ების შედარება

გამოქვეყნებული Agent Framework Benchmark-ის ცხრილში მონაცემთა ინჟინერიის დავალებებზე CrewAI-ის კონფიგურაციის საშუალო დაყოვნება დაახლოებით 20,0 წამია და საშუალო მოხმარება — 5 005 token; AutoGen-ის კონფიგურაციისთვის მაჩვენებლებია 17,9 წამი და 5 678 token. აღწერილი გაშვებები ერთსა და იმავე Groq Llama 3.3 70B მოდელს, მოთხოვნებსა და დროის შეზღუდვას იყენებს. ეს არის კონკრეტული ტესტის კონფიგურაციების შედეგი და არა რომელიმე ჩარჩოს მუდმივი სიჩქარე ან ფასი.

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

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

რას ცვლის მხარდაჭერის სტატუსი არჩევანში

ახალი პროექტის დაგეგმვისას AutoGen-ის ტექნიკურ შესაძლებლობებთან ერთად მისი განვითარების ჰორიზონტიც გასათვალისწინებელია. AutoGen-ის ოფიციალური რეპოზიტორია ჩარჩოს maintenance mode-ში ასახელებს, ახალი ფუნქციების დამატებას აღარ გეგმავს და ახალ მომხმარებლებს Microsoft Agent Framework-ისკენ მიუთითებს. არსებული AutoGen არქიტექტურები მუშაობისთვის ხელმისაწვდომია, მაგრამ ახალი პროდუქტის გრძელვადიან გეგმაში ეს სტატუსი რეალური შეზღუდვაა.

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

ასევე წაიკითხეთ:

• Workato-ს AI Registry აგენტებს ერთ კატალოგში აქცევს — კონტროლი ვრცელდება
• AI აგენტებს საკუთარი იდენტობა ექნებათ — 12 კომპანია წესებზე შეთანხმდა
• Microsoft Foundry-ის აგენტები დავალებებს უკვე განრიგითაც შეასრულებენ