მოდელიდან აგენტამდე: Responses API-ის აღჭურვა კომპიუტერული გარემოთი

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

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

იმის ნაცვლად, რომ დეველოპერებისთვის საკუთარი გაშვების გარემოების აგება დაგვეკისრებინა, ჩვენ შევქმენით საჭირო კომპონენტები, რათა Responses API⁠(იხსნება ახალ ფანჯარაში) კომპიუტერული გარემოთი აღგვეჭურვა და რეალური ამოცანები სანდოდ შეგვესრულებინა.

OpenAI-ის Responses API, shell tool-თან და ჰოსტირებულ კონტეინერის სამუშაო სივრცესთან ერთად, შექმნილია ამ პრაქტიკული პრობლემების გადასაჭრელად. მოდელი სთავაზობს ნაბიჯებსა და ბრძანებებს; პლატფორმა კი მათ იზოლირებულ გარემოში ასრულებს, სადაც არის ფაილური სისტემა შემომავალი და გამავალი მონაცემებისთვის, სურვილისამებრ სტრუქტურირებული საცავი (მაგალითად, SQLite) და შეზღუდული ქსელური წვდომა. 

ამ პოსტში განვიხილავთ, როგორ ავაშენეთ აგენტებისთვის კომპიუტერული გარემო და გაგიზიარებთ რამდენიმე ადრეულ გაკვეთილს, თუ როგორ გამოიყენოთ ის უფრო სწრაფი, გამეორებადი და უსაფრთხო საწარმოო სამუშაო ნაკადებისთვის.

კარგი აგენტური სამუშაო ნაკადი იწყება მჭიდრო შესრულების ციკლით: მოდელი სთავაზობს მოქმედებას, მაგალითად ფაილების წაკითხვას ან API-ით მონაცემების გამოთხოვას, პლატფორმა მას ასრულებს, ხოლო შედეგი შემდეგ ნაბიჯს კვებავს. დავიწყებთ shell tool-ით — ეს უმარტივესი გზაა ამ ციკლის მოქმედებაში სანახავად — და შემდეგ გადავხედავთ კონტეინერის სამუშაო სივრცეს, ქსელს, ხელახლა გამოსაყენებელ skills-ებს და კონტექსტის კომპაქტაციას.

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

shell tool მოდელს მკვეთრად აძლიერებს: ის ბრძანების სტრიქონის საშუალებით კომპიუტერთან ურთიერთქმედებს და ასრულებს მრავალფეროვან ამოცანებს — ტექსტის ძიებიდან თქვენს კომპიუტერზე API მოთხოვნების გაგზავნამდე. ნაცნობ Unix ინსტრუმენტებზე აგებული ჩვენი shell tool აკეთებს ყველაფერს, რასაც მოელით; grep, curl და awk ტიპის უტილიტები თავიდანვე ხელმისაწვდომია.

ჩვენს არსებულ code interpreter-თან შედარებით, რომელიც მხოლოდ Python-ს ასრულებს, shell tool ბევრად ფართო გამოყენების შემთხვევებს ხსნის — მაგალითად, Go-ს ან Java-ს პროგრამების გაშვებას, ან NodeJS სერვერის ამოქმედებას. ეს მოქნილობა მოდელს რთული აგენტური ამოცანების შესრულების საშუალებას აძლევს.

თავისით მოდელს მხოლოდ shell ბრძანებების შეთავაზება შეუძლია, მაგრამ როგორ სრულდება ეს ბრძანებები? გვჭირდება ორკესტრატორი, რომელიც მიიღებს მოდელის შედეგს, გამოიძახებს ინსტრუმენტებს და ინსტრუმენტის პასუხს ციკლურად დაუბრუნებს მოდელს, სანამ ამოცანა არ დასრულდება.

Responses API არის საშუალება, რომლითაც დეველოპერები OpenAI-ის მოდელებთან ურთიერთობენ. როდესაც ის custom tools-თან ერთად გამოიყენება, Responses API კონტროლს ისევ კლიენტს უბრუნებს და ინსტრუმენტების გასაშვებად კლიენტს საკუთარი harness სჭირდება. თუმცა ამ API-ს შეუძლია ასევე მოდელსა და ჰოსტირებულ ინსტრუმენტებს შორის ორკესტრირება თავიდანვე უზრუნველყოს. 

როდესაც Responses API იღებს მოთხოვნას, ის აწყობს მოდელის კონტექსტს: მომხმარებლის მოთხოვნას, წინა საუბრის მდგომარეობას და ინსტრუმენტების ინსტრუქციებს. იმისთვის, რომ shell შესრულება იმუშაოს, მოთხოვნაში ნახსენები უნდა იყოს shell tool-ის გამოყენება, და არჩეული მოდელი გაწვრთნილი უნდა იყოს shell ბრძანებების შეთავაზებაზე — GPT‑5.2 და უფრო ახალი მოდელები ამისთვის გაწვრთნილია. მთელი ამ კონტექსტის ფონზე, მოდელი შემდეგ მოქმედებას წყვეტს. თუ ის shell შესრულებას აირჩევს, Responses API სერვისს ერთ ან მეტ shell ბრძანებას უბრუნებს. API სერვისი ამ ბრძანებებს კონტეინერის გაშვების გარემოს გადასცემს, shell-ის შედეგს სტრიმინგით აბრუნებს და შემდეგი მოთხოვნის კონტექსტში ისევ მოდელს აწვდის. ამის შემდეგ მოდელს შეუძლია შედეგები შეამოწმოს, დამატებითი ბრძანებები გასცეს ან საბოლოო პასუხი შექმნას. Responses API ამ ციკლს იმეორებს, სანამ მოდელი დასრულებულ პასუხს დამატებითი shell ბრძანებების გარეშე არ დააბრუნებს.

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

მოდელს შეუძლია ერთ ნაბიჯში რამდენიმე shell ბრძანება შესთავაზოს, ხოლო Responses API მათ პარალელურად, სხვადასხვა კონტეინერის სესიის გამოყენებით, ასრულებს. თითოეული სესია შედეგს დამოუკიდებლად სტრიმავს, ხოლო API ამ სტრიმებს სტრუქტურირებულ ინსტრუმენტის შედეგებად მულტიპლექსირებს და კონტექსტად აბრუნებს. სხვა სიტყვებით, აგენტის ციკლს შეუძლია სამუშაოს პარალელიზაცია — მაგალითად, ფაილების ძიების, მონაცემების გამოთხოვისა და შუალედური შედეგების შემოწმების.

როდესაც ბრძანება ფაილებთან მუშაობას ან მონაცემთა დამუშავებას მოიცავს, shell-ის შედეგი შეიძლება ძალიან დიდი გახდეს და კონტექსტის ბიუჯეტი მოიხმაროს სასარგებლო სიგნალების დამატების გარეშე. ამის სამართავად, მოდელი თითოეული ბრძანებისთვის შედეგის ზღვარს განსაზღვრავს. Responses API ამ ზღვარს იცავს და აბრუნებს შეზღუდულ შედეგს, რომელიც ინახავს როგორც დასაწყისს, ისე ბოლოს, ხოლო გამოტოვებულ ნაწილს აღნიშნავს. მაგალითად, შეგიძლიათ შედეგი 1,000 სიმბოლოთი შეზღუდოთ და შეინარჩუნოთ დასაწყისი და ბოლო:

ტექსტი დასაწყისში ... 1000 სიმბოლო შეკვეცილია ... ტექსტი ბოლოს

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

აგენტის ციკლების ერთ-ერთი პოტენციური პრობლემა ისაა, რომ ამოცანები შეიძლება დიდხანს გაგრძელდეს. ხანგრძლივი ამოცანები ავსებს კონტექსტის ფანჯარას, რომელიც მნიშვნელოვანია კონტექსტის შესანარჩუნებლად როგორც ნაბიჯებს შორის, ისე აგენტებს შორის. წარმოიდგინეთ აგენტი, რომელიც skill-ს იძახებს, იღებს პასუხს, ამატებს ინსტრუმენტის გამოძახებებსა და მსჯელობის შეჯამებებს — შეზღუდული კონტექსტის ფანჯარა სწრაფად ივსება. იმისთვის, რომ აგენტმა მუშაობის გაგრძელებისას მნიშვნელოვანი კონტექსტი არ დაკარგოს, გვჭირდება გზა, რომ საკვანძო დეტალები შევინარჩუნოთ და ზედმეტი მოვაშოროთ. იმის ნაცვლად, რომ დეველოპერებს საკუთარი შეჯამების ან მდგომარეობის გადატანის სისტემების დაპროექტება და მოვლა მოვთხოვოთ, Responses API-ში მშობლიური კომპაქტაცია დავამატეთ, რომელიც შეესაბამება იმას, როგორ იქცევა მოდელი და როგორ არის გაწვრთნილი.

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

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

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

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

კონტეინერის კონტექსტის პირველი ნაწილი არის ფაილური სისტემა რესურსების ატვირთვის, ორგანიზებისა და მართვისთვის. ჩვენ შევქმენით container და file⁠(იხსნება ახალ ფანჯარაში) API-ები, რათა მოდელს ხელმისაწვდომი მონაცემების რუკა მივცეთ და დავეხმაროთ, ფართო და ხმაურიანი სკანირების ნაცვლად, მიზნობრივი ფაილური ოპერაციები აირჩიოს.

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

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

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

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

ამ პრობლემების გადასაჭრელად, აგენტების სარგებლიანობის შეზღუდვის გარეშე, ჩვენ ჰოსტირებული კონტეინერები sidecar egress proxy-ის გამოყენებით ავაგეთ. ყველა გამავალი ქსელური მოთხოვნა გადის ცენტრალიზებულ პოლიტიკის ფენაზე, რომელიც enforce-ს უკეთებს allowlist-ებსა და წვდომის კონტროლს და ამავე დროს ტრაფიკს დაკვირვებადს ტოვებს. სერთიფიკატებისთვის ვიყენებთ დომენის მასშტაბით secret injection-ს egress-ზე. მოდელი და კონტეინერი მხოლოდ placeholder-ებს ხედავენ, ხოლო ნედლი საიდუმლო მნიშვნელობები მოდელისთვის ხილული კონტექსტის გარეთ რჩება და მხოლოდ დამტკიცებული დანიშნულებებისთვის გამოიყენება. ეს ამცირებს გაჟონვის რისკს და მაინც შესაძლებელს ხდის ავტენტიფიცირებულ გარე გამოძახებებს.

Shell ბრძანებები ძლიერია, მაგრამ ბევრი ამოცანა იმავე მრავალსაფეხურიან შაბლონებს იმეორებს. აგენტებს ყოველ გაშვებაზე თავიდან უწევთ სამუშაო პროცესის აღმოჩენა — ხელახალი დაგეგმვა, ბრძანებების თავიდან გაშვება და კონვენციების თავიდან სწავლა — რაც არათანმიმდევრულ შედეგებსა და ფუჭ შესრულებას იწვევს. Agent skills⁠(იხსნება ახალ ფანჯარაში) ამ შაბლონებს ხელახლა გამოსაყენებელ, კომპოზირებად სამშენებლო ბლოკებად აყალიბებს. კერძოდ, skill არის საქაღალდის პაკეტი, რომელიც მოიცავს ‘SKILL.md⁠(იხსნება ახალ ფანჯარაში)’-ს (მეტამონაცემებითა და ინსტრუქციებით) და ნებისმიერ დამხმარე რესურსს, როგორიცაა API სპეციფიკაციები და UI აქტივები.

ეს სტრუქტურა ბუნებრივად ერგება runtime არქიტექტურას, რომელიც ადრე აღვწერეთ. კონტეინერი უზრუნველყოფს მუდმივ ფაილებსა და შესრულების კონტექსტს, ხოლო shell ინსტრუმენტი უზრუნველყოფს შესრულების ინტერფეისს. ამ ორის არსებობისას მოდელს შეუძლია საჭიროებისას shell ბრძანებებით (`ls`, `cat` და სხვ.) აღმოაჩინოს skill ფაილები, განმარტოს ინსტრუქციები და skill სკრიპტები გაუშვას — ყველაფერი იმავე აგენტის ციკლში.

ჩვენ OpenAI პლატფორმაზე skills-ის სამართავად API-ებს⁠(იხსნება ახალ ფანჯარაში) ვაწვდით. დეველოპერები ტვირთავენ და ინახავენ skill საქაღალდეებს ვერსიონირებულ პაკეტებად, რომელთა მოგვიანებით მოძიებაც skill ID-ით არის შესაძლებელი. სანამ მოთხოვნა მოდელს გაეგზავნება, Responses API ტვირთავს skill-ს და მას მოდელის კონტექსტში ათავსებს. ეს მიმდევრობა დეტერმინისტულია:

1. მოიტანეთ skill-ის მეტამონაცემები, მათ შორის სახელი და აღწერა.
2. მოიტანეთ skill პაკეტი, დააკოპირეთ კონტეინერში და გაშალეთ.
3. განაახლეთ მოდელის კონტექსტი skill-ის მეტამონაცემებითა და კონტეინერის ბილიკით.

როდესაც გადაწყვეტს, რელევანტურია თუ არა skill, მოდელი თანდათანობით იკვლევს მის ინსტრუქციებს და მის სკრიპტებს კონტეინერში shell ბრძანებებით ასრულებს.

ყველა ნაწილის ერთად მოსაყრად: Responses API უზრუნველყოფს ორკესტრირებას, shell tool უზრუნველყოფს შესრულებად მოქმედებებს, hosted container უზრუნველყოფს მუდმივ runtime კონტექსტს, skills ამატებს ხელახლა გამოყენებად სამუშაო პროცესის ლოგიკას, ხოლო compaction აგენტს საშუალებას აძლევს დიდხანს იმუშაოს მისთვის საჭირო კონტექსტით.

ამ პრიმიტივებით ერთი მოთხოვნა შეიძლება გაფართოვდეს სრულ, end-to-end სამუშაო პროცესად: იპოვოს სწორი skill, მოიტანოს მონაცემები, გარდაქმნას ისინი ადგილობრივ სტრუქტურირებულ მდგომარეობად, ეფექტიანად გამოკითხოს და შექმნას მდგრადი არტეფაქტები.

ქვემოთ მოცემული დიაგრამა აჩვენებს, როგორ მუშაობს ეს სისტემა ცოცხალი მონაცემებიდან ცხრილის შექმნისას.

Shell ინსტრუმენტისა და კომპიუტერული გარემოს end-to-end სამუშაო პროცესებისთვის გაერთიანების სიღრმისეული მაგალითისთვის იხილეთ ჩვენი დეველოპერთა ბლოგპოსტი⁠(იხსნება ახალ ფანჯარაში) და cookbook⁠(იხსნება ახალ ფანჯარაში), სადაც აღწერილია skill-ის პაკეტირება და მისი შესრულება Responses API-ის მეშვეობით.

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