मॉडेलपासून एजंटपर्यंत: Responses API ला संगणक वातावरणाने सुसज्ज करणे
लेखक: बो शू, डॅनी झांग आणि रोहित अरुणाचलम
आम्ही सध्या विशिष्ट टास्क्समध्ये उत्कृष्ट असलेल्या मॉडेल्सचा वापर करण्यापासून कॉम्प्लेक्स वर्कफ्लोज हाताळण्यास सक्षम असलेल्या एजंट्सचा वापर करण्याकडे वळत आहोत. मॉडेल्सना प्रॉम्प्ट देऊन, तुम्ही केवळ प्रशिक्षित बुद्धिमत्तेमध्येच प्रवेश करू शकता. तथापि, मॉडेलला संगणक वातावरण दिल्यास वापर प्रकरणांची खूपच विस्तृत श्रेणी साध्य होऊ शकते—उदा., सेवा चालवणे, APIs कडून डेटा मागवणे, किंवा स्प्रेडशीट्स किंवा अहवालांसारखी अधिक उपयुक्त आर्टिफॅक्ट्स तयार करणे.
एजंट्स तयार करण्याचा प्रयत्न करता तेव्हा काही व्यावहारिक समस्या समोर येतात: मधल्या फाइल्स कुठे ठेवायच्या, मोठ्या टेबल्स प्रॉम्प्टमध्ये पेस्ट करणे कसे टाळायचे, सुरक्षा डोकेदुखी न निर्माण करता वर्कफ्लोला नेटवर्क प्रवेश कसा द्यायचा, आणि स्वतः वर्कफ्लो सिस्टम न तयार करता टाइमआउट्स आणि रिट्राइज कसे हाताळायचे.
विकसकांवर त्यांची स्वतःची कार्यान्वयन वातावरणे तयार करण्याची जबाबदारी टाकण्याऐवजी, आम्ही वास्तविक जगातील कामे विश्वासार्हपणे अंमलात आणण्यासाठी संगणक वातावरणासह Responses API(नवीन विंडोमध्ये उघडेल) सुसज्ज करण्यासाठी आवश्यक घटक तयार केले.
OpenAI’s Responses API, शेल टूल आणि होस्ट केलेला कंटेनर वर्कस्पेस यांसह, या व्यावहारिक समस्यांना संबोधित करण्यासाठी डिझाइन केलेले आहे. मॉडेल पायऱ्या आणि कमांड्स सुचवते; प्लॅटफॉर्म त्यांना इनपुट्स आणि आउटपुट्ससाठी फाइलसिस्टम, पर्यायी स्ट्रक्चर्ड स्टोरेज (SQLite सारखे), आणि मर्यादित नेटवर्क प्रवेश असलेल्या स्वतंत्र वातावरणात चालवतो.
या पोस्टमध्ये, आम्ही एजंट्ससाठी संगणक वातावरण कसे तयार केले याचे विश्लेषण करू आणि जलद, अधिक पुनरावृत्तीयोग्य आणि अधिक सुरक्षित उत्पादन कार्यप्रवाहांसाठी ते कसे वापरावे याबद्दल काही सुरुवातीचे धडे सामायिक करू.
चांगला एजंट वर्कफ्लो घट्ट अंमलबजावणी लूपने सुरू होतो: मॉडेल फाइल्स वाचणे किंवा API सह डेटा फेच करणे यासारखी कृती प्रस्तावित करते, प्लॅटफॉर्म ती चालवतो, आणि परिणाम पुढील टप्प्यात फीड होतो. आम्ही शेल टूलपासून सुरुवात करू—हा लूप प्रत्यक्षात कसा काम करतो ते पाहण्याचा सर्वात सोपा मार्ग—आणि मग कंटेनर वर्कस्पेस, नेटवर्किंग, पुनर्वापरयोग्य कौशल्ये, आणि कॉन्टेक्स्ट कॉम्पॅक्शन यांचा आढावा घेऊ.
शेल टूल समजून घेण्यासाठी, सर्वसाधारणपणे भाषा मॉडेल टूल्स कशी वापरते हे समजून घेणे आधी उपयुक्त ठरते: फंक्शन कॉल करणे किंवा संगणकाशी संवाद साधणे यांसारख्या गोष्टी करण्यासाठी. प्रशिक्षणादरम्यान, टूल्स कसे वापरले जातात आणि त्यांचे परिणामी परिणाम काय होतात याची उदाहरणे मॉडेलला टप्प्याटप्प्याने दाखवली जातात. यामुळे मॉडेलला टूल कधी वापरायचे आणि ते कसे वापरायचे हे ठरवायला शिकण्यास मदत होते. जेव्हा आम्ही “एखादे टूल वापरणे” असे म्हणतो, तेव्हा आमचा अर्थ असा असतो की मॉडेल प्रत्यक्षात फक्त टूल कॉल प्रस्तावित करते. ते स्वतःहून कॉल अंमलात आणू शकत नाही.
शेल टूल मॉडेलला नाट्यमयरीत्या अधिक शक्तिशाली बनवते: ते कमांड लाइनद्वारे संगणकाशी संवाद साधून मजकूर शोधण्यापासून ते तुम्हालाल्या संगणकावर API विनंत्या पाठवण्यापर्यंत विविध प्रकारची कामे पार पाडते. परिचित Unix टूलिंगवर आधारित, आमचे शेल टूल तुम्ही अपेक्षा कराल ते सर्व करू शकते, आणि grep, curl, आणि awk यांसारखी युटिलिटीज तयारच उपलब्ध आहेत.
आमच्या विद्यमान कोड इंटरप्रिटरच्या तुलनेत, जो फक्त Python कार्यान्वित करतो, शेल टूल अधिक व्यापक वापर प्रकरणांची श्रेणी सक्षम करते, जसे की Go किंवा Java प्रोग्राम्स चालवणे किंवा NodeJS सर्व्हर सुरू करणे. ही लवचिकता मॉडेलला क्लिष्ट एजंटिक टास्क्स पूर्ण करू देते.
स्वतःहून, मॉडेल फक्त शेल कमांड्स सुचवू शकते, पण या कमांड्सची अंमलबजावणी कशी केली जाते? कार्य पूर्ण होईपर्यंत, मॉडेल आउटपुट मिळवण्यासाठी, टूल्स कॉल करण्यासाठी, आणि टूलचा प्रतिसाद लूपमध्ये परत मॉडेलकडे पाठवण्यासाठी तुम्हालाल्याला एक ऑर्केस्ट्रेटर आवश्यक आहे.
Responses API ही विकसक OpenAI मॉडेल्सशी संवाद साधण्याची पद्धत आहे. कस्टम टूल्ससह वापरल्यास, Responses API नियंत्रण परत क्लायंटकडे देते, आणि टूल्स चालवण्यासाठी क्लायंटला स्वतःचा हार्नेस आवश्यक असतो. तथापि, हे API आउट ऑफ द बॉक्स मॉडेल आणि होस्टेड टूल्स यांच्यातही समन्वय साधू शकते.
Responses API ला प्रॉम्प्ट प्राप्त झाल्यावर, ते मॉडेल संदर्भ एकत्रित करते: वापरकर्ता प्रॉम्प्ट, आधीच्या संभाषणाची स्थिती, आणि टूल सूचना. शेल एक्झिक्युशन कार्य करण्यासाठी, प्रॉम्प्टमध्ये शेल टूल वापरण्याचा उल्लेख असणे आवश्यक आहे आणि निवडलेले मॉडेल शेल कमांड्स सुचवण्यासाठी प्रशिक्षित असणे आवश्यक आहे—GPT‑5.2 आणि त्यानंतरची मॉडेल्स यासाठी प्रशिक्षित आहेत. या सर्व संदर्भासह, मॉडेल नंतर पुढील क्रिया ठरवते. जर ते शेल एक्झिक्युशन निवडत असेल, तर ते Responses API सेवेला एक किंवा अधिक शेल कमांड्स परत करते. API सेवा त्या कमांड्स कंटेनर रनटाइमकडे फॉरवर्ड करते, शेल आउटपुट परत स्ट्रीम करते, आणि पुढील विनंतीच्या संदर्भात ते मॉडेलला फीड करते. मॉडेल नंतर परिणाम तपासू शकते, फॉलो-अप कमांड्स जारी करू शकते, किंवा अंतिम उत्तर तयार करू शकते. Responses API हे मॉडेल अतिरिक्त शेल कमांड्स शिवाय पूर्णता परत करेपर्यंत हा लूप पुन्हा पुन्हा करते.
Responses API जेव्हा शेल कमांड अंमलात आणते, तेव्हा ते कंटेनर सेवेशी स्ट्रीमिंग कनेक्शन कायम ठेवते. आउटपुट तयार होत असताना, API ते जवळजवळ रिअल-टाइममध्ये मॉडेलकडे रिले करते, जेणेकरून मॉडेल ठरवू शकेल की अधिक आउटपुटची वाट पाहायची, आणखी एक कमांड चालवायची, किंवा अंतिम प्रतिसादाकडे पुढे जायचे.
Responses API शेल कमांडचे आउटपुट स्ट्रीम करते
मॉडेल एका चरणात अनेक शेल कमांड्स सुचवू शकते, आणि Responses APIस्वतंत्र कंटेनर सत्रांचा वापर करून त्यांना समवर्तीपणे अंमलात आणू शकते. प्रत्येक सत्र आउटपुट स्वतंत्रपणे स्ट्रीम करते, आणि API त्या स्ट्रीम्सना परत संरचित टूल आउटपुट्स म्हणून संदर्भात मल्टिप्लेक्स करते. दुसऱ्या शब्दांत, एजंट लूप काम समांतरपणे करू शकतो, जसे की फाइल्स शोधणे, डेटा मिळवणे आणि मधल्या टप्प्यातील परिणामांची पडताळणी करणे.
जेव्हा कमांडमध्ये फाइल ऑपरेशन्स किंवा डेटा प्रक्रिया समाविष्ट असते, तेव्हा शेल आउटपुट खूप मोठे होऊ शकते आणि उपयुक्त संकेत न जोडता कॉन्टेक्स्ट बजेट्स वापरून टाकू शकते. हे नियंत्रित करण्यासाठी, मॉडेल प्रत्येक कमांडसाठी आउटपुटची कमाल मर्यादा निर्दिष्ट करते. Responses API त्या मर्यादेची अंमलबजावणी करते आणि वगळलेला मजकूर चिन्हांकित करत, आउटपुटची सुरुवात आणि शेवट दोन्ही जपणारा मर्यादित परिणाम परत करते. उदाहरणार्थ, तुम्ही आउटपुट 1,000 पात्रांपर्यंत मर्यादित करू शकता, सुरुवात आणि शेवट जतन करून:
सुरुवातीला मजकूर ... 1000 अक्षरे छाटली ... शेवटी मजकूर.
एकत्रितपणे, समांतर अंमलबजावणी आणि मर्यादित आउटपुट एजंट लूपला वेगवान आणि संदर्भ-कार्यक्षम बनवतात, ज्यामुळे मॉडेल कच्च्या टर्मिनल लॉग्समुळे गोंधळून न जाता संबंधित परिणामांवर रीझनिंग करू शकते.
एजंट लूप्समधील एक संभाव्य समस्या म्हणजे कामे लांब काळ चालू शकतात. दीर्घकाळ चालणारी कामे कॉन्टेक्स्ट विंडो भरून टाकतात, जे टर्न्समध्ये आणि एजंट्समध्ये संदर्भ प्रदान करण्यासाठी महत्त्वाचे आहे. एजंट एखादे स्किल कॉल करत आहे, प्रतिसाद मिळवत आहे, टूल कॉल्स आणि रीझनिंग सारांश जोडत आहे—मर्यादित कॉन्टेक्स्ट विंडो पटकन भरून जाते. एजंट चालू राहिल्यामुळे महत्त्वाचा संदर्भ गमावू नये म्हणून, मुख्य तपशील जपून ठेवण्याचा आणि अनावश्यक गोष्टी काढून टाकण्याचा आपल्याला एक मार्ग हवा आहे. डेव्हलपर्सना कस्टम समरीकरण किंवा स्टेट-कॅरींग सिस्टीम्स डिझाइन आणि मेंटेन करणे आवश्यक ठरवण्याऐवजी, आम्ही Responses API मध्ये नेटिव्ह कॉम्पॅक्शन जोडले, जे मॉडेल कसे वागते आणि ते कसे ट्रेन केले गेले आहे यासोबत ॲलाईन होण्यासाठी डिझाइन केलेले आहे.
आमची नवीनतम मॉडेल्स मागील संभाषण स्टेटचे विश्लेषण करण्यासाठी आणि एक कॉम्पॅक्शन आयटम तयार करण्यासाठी प्रशिक्षित आहेत, जो एन्क्रिप्टेड टोकन-इफिशंट प्रतिनिधित्वात महत्त्वाचा मागील स्टेट जतन करतो. संक्षिप्त केल्यानंतर, पुढील कॉन्टेक्स्ट विंडोमध्ये हा संक्षिप्त आयटम आणि आधीच्या विंडोमधील उच्च-मूल्य भाग असतात. यामुळे विंडो सीमांपलीकडेही वर्कफ्लो सुसंगतपणे सुरू राहू शकतात, अगदी विस्तारित बहु-चरणीय आणि टूल-आधारित सेशन्समध्येही. Codex या यंत्रणेवर अवलंबून आहे जेणेकरून गुणवत्ता कमी न होता दीर्घकाळ चालणारी कोडिंग कामे आणि टूल्सची पुनरावृत्तीने अंमलबजावणी टिकवून ठेवता येईल.
कॉम्पॅक्शन सर्व्हरवर अंगभूत स्वरूपात किंवा स्वतंत्र `/compact` एंडपॉइंटद्वारे उपलब्ध आहे. सर्व्हर-साइड कॉम्पॅक्शनमुळे तुम्ही एक थ्रेशोल्ड कॉन्फिगर करू शकता, आणि प्रणाली कॉम्पॅक्शनची वेळ स्वयंचलितपणे हाताळते, ज्यामुळे क्लायंट-साइडवरील गुंतागुंतीच्या लॉजिकची गरज नाहीशी होते. हे संक्षिप्तीकरणाच्या अगदी आधी लहान ओव्हरेजेस सहन करण्यासाठी किंचित मोठी प्रभावी संदर्भ विंडो परवानगी देते, त्यामुळे मर्यादेजवळील विनंत्या नाकारल्या जाण्याऐवजी तरीही प्रक्रिया करून संक्षिप्त केल्या जाऊ शकतात. मॉडेल प्रशिक्षण विकसित होत असताना, प्रत्येक OpenAI मॉडेल रिलीजसाठी त्यासोबतच नेटिव्ह कॉम्पॅक्शन सोल्यूशनही विकसित होते.
Codex ने कॉम्पॅक्शन सिस्टीम तयार करण्यात आम्हाला मदत केली, तसेच त्याचा सुरुवातीचा वापरकर्ता म्हणूनही काम केले. जेव्हा एखाद्या Codex उदाहरणात संकुचन त्रुटी आली, तेव्हा आम्ही तपासणी करण्यासाठी दुसरे उदाहरण सुरू करायचो. परिणाम असा झाला की फक्त समस्येवर काम करून Codex ला एक स्वदेशी, प्रभावी संकुचन प्रणाली मिळाली. Codex ची स्वतःची तपासणी आणि सुधारणा करण्याची ही क्षमता OpenAI मध्ये काम करताना विशेषतः मनोरंजक भाग बनली आहे. बहुतेक टूल्समध्ये वापरकर्त्याला फक्त ती कशी वापरायची हे शिकावे लागते; Codex मात्र आमच्यासोबत शिकतो.
आता, स्टेट आणि रिसोर्सेस पाहूया. कंटेनर हे केवळ आदेश चालवण्यासाठीचे ठिकाण नाही, तर मॉडेलसाठी कार्यरत संदर्भ देखील आहे. कंटेनरच्या आत, मॉडेल फाइल्स वाचू शकते, डेटाबेसमध्ये चौकशी करू शकते आणि नेटवर्क धोरण नियंत्रणांअंतर्गत बाह्य प्रणालींमध्ये प्रवेश करू शकते.
कंटेनर कॉन्टेक्स्टचा पहिला भाग म्हणजे संसाधने अपलोड करणे, संघटित करणे आणि व्यवस्थापित करण्यासाठीची फाईल सिस्टम. आम्ही कंटेनर आणि फाइल(नवीन विंडोमध्ये उघडेल) API तयार केल्या, ज्यामुळे मॉडेलला उपलब्ध डेटाचा नकाशा मिळतो आणि व्यापक, गोंगाटयुक्त स्कॅन करण्याऐवजी लक्षित फाइल ऑपरेशन्स निवडण्यात मदत होते.
एक सामान्य विरोधी नमुना म्हणजे सर्व इनपुट थेट प्रॉम्प्ट संदर्भात पॅक करणे. इनपुट्स वाढत गेल्यावर, प्रॉम्प्ट जास्त भरल्याने खर्च वाढतो आणि मॉडेलसाठी त्यातून नेव्हिगेट करणे कठीण होते. एक अधिक चांगला पॅटर्न म्हणजे कंटेनर फाइल सिस्टममध्ये संसाधने स्टेज करणे आणि शेल कमांड्सद्वारे काय उघडायचे, पार्स करायचे किंवा ट्रान्सफॉर्म करायचे हे मॉडेलला ठरवू देणे. मानवांप्रमाणेच, मॉडेल्सही सुव्यवस्थित माहितीसोबत अधिक चांगले काम करतात.
कंटेनर संदर्भाचा दुसरा भाग म्हणजे डेटाबेसेस. अनेक प्रकरणांमध्ये, आम्ही डेव्हलपर्सना संरचित डेटा डेटाबेसमध्ये SQLite म्हणून साठवण्याचा आणि त्यावर क्वेरी करण्याचा सल्ला देतो. उदाहरणार्थ, संपूर्ण स्प्रेडशीट प्रॉम्प्टमध्ये कॉपी करण्याऐवजी, तुम्ही मॉडेलला टेबल्सचे वर्णन देऊ शकता—कोणते कॉलम्स आहेत आणि त्यांचा अर्थ काय आहे—आणि त्याला आवश्यक त्या रांगा काढू द्या.
उदाहरणार्थ, जर तुम्ही विचाराल, “या तिमाहीत कोणत्या उत्पादनांची विक्री घटत होती?” तर मॉडेल संपूर्ण स्प्रेडशीट स्कॅन करण्याऐवजी फक्त संबंधित रकाने क्वेरी करू शकते. हे अधिक जलद, स्वस्त, आणि मोठ्या डेटासेट्ससाठी अधिक स्केलेबल आहे.
कंटेनर संदर्भाचा तिसरा भाग म्हणजे नेटवर्क प्रवेश, जो एजंट वर्कलोड्सचा एक महत्त्वाचा भाग आहे. एजंटच्या कार्यप्रवाहाला लाइव्ह डेटा मिळवणे, बाह्य APIs कॉल करणे किंवा पॅकेजेस इन्स्टॉल करणे आवश्यक असू शकते. त्याच वेळी, कंटेनर्सना निर्बंधरहित इंटरनेट प्रवेश देणे धोकादायक ठरू शकते: त्यामुळे माहिती बाह्य वेबसाइट्ससमोर उघडी पडू शकते, अनवधानाने संवेदनशील अंतर्गत किंवा तृतीय पक्ष प्रणालींना स्पर्श होऊ शकतो, किंवा क्रेडेन्शियल लीक आणि डेटा एक्सफिल्ट्रेशनपासून संरक्षण करणे कठीण होऊ शकते.
एजंट्सची उपयुक्तता मर्यादित न करता या चिंतांना संबोधित करण्यासाठी, आम्ही साइडकार इग्रेस प्रॉक्सी वापरण्यासाठी होस्टेड कंटेनर्स तयार केले. सर्व आउटबाउंड नेटवर्क विनंत्या अलॉवलिस्ट आणि प्रवेश नियंत्रण लागू करणाऱ्या केंद्रीकृत धोरण स्तरातून प्रवाहित होतात, तसेच ट्रॅफिक निरीक्षणयोग्य ठेवतात. क्रेडेन्शियल्ससाठी, आम्ही egress वेळी डोमेन-स्कोप्ड सीक्रेट इंजेक्शन वापरतो. मॉडेल आणि कंटेनरला फक्त प्लेसहोल्डर्स दिसतात, तर कच्ची गुप्त मूल्ये मॉडेलला दिसणाऱ्या कॉन्टेक्स्टच्या बाहेरच राहतात आणि फक्त मंजूर गंतव्यांसाठीच लागू केली जातात. यामुळे गळतीचा धोका कमी होतो, असतानाही प्रमाणीकृत बाह्य कॉल्स सक्षम राहतात.
शेल कमांड्स शक्तिशाली आहेत, पण अनेक कामे त्याच बहु-चरणीय पॅटर्न्सची पुनरावृत्ती करतात. एजंट्सना प्रत्येक रनमध्ये वर्कफ्लो पुन्हा शोधावा लागतो—पुन्हा नियोजन करणे, कमांड्स पुन्हा जारी करणे, आणि प्रथा पुन्हा शिकणे—यामुळे विसंगत परिणाम आणि वाया गेलेली अंमलबजावणी होते. एजंट कौशल्ये(नवीन विंडोमध्ये उघडेल) त्या पॅटर्न्सना पुनर्वापरयोग्य, संयोज्य मूलभूत घटकांमध्ये पॅकेज करतात. ठोसपणे सांगायचे तर, कौशल्य हे ‘SKILL.md(नवीन विंडोमध्ये उघडेल)’ समाविष्ट असलेले फोल्डर बंडल आहे (मेटाडेटा आणि सूचना यांचा समावेश असलेली) तसेच API विनिर्देश आणि UI संसाधने यांसारख्या कोणत्याही सहायक संटूल्ससह.
ही रचना आम्ही आधी वर्णन केलेल्या रनटाइम आर्किटेक्चरशी नैसर्गिकरित्या जुळते. कंटेनर सतत फाइल्स आणि अंमलबजावणी संदर्भ प्रदान करतो, आणि शेल टूल अंमलबजावणी इंटरफेस प्रदान करते. दोन्हीही ठिकाणी असल्यानंतर, मॉडेल गरज पडल्यावर शेल कमांड्स (`ls`, `cat`, etc.) वापरून स्किल फाइल्स शोधू शकते, सूचनांचे अर्थ लावू शकते, आणि त्याच एजंट लूपमध्ये स्किल स्क्रिप्ट्स चालवू शकते.
OpenAI प्लॅटफॉर्ममध्ये कौशल्ये व्यवस्थापित करण्यासाठी आम्ही API(नवीन विंडोमध्ये उघडेल) प्रदान करतो. डेव्हलपर्स कौशल्य फोल्डर्स आवृत्तीबद्ध बंडल्स म्हणून अपलोड करून साठवतात, जे नंतर कौशल्य ID द्वारे पुनर्प्राप्त करता येतात. मॉडेलला प्रॉम्प्ट पाठवण्यापूर्वी, Responses API कौशल्य लोड करते आणि ते मॉडेल संदर्भात समाविष्ट करते. हा क्रम निर्धारक आहे:
- नाव आणि वर्णनासह कौशल्य मेटाडेटा मिळवा.
- कौशल्य बंडल प्राप्त करा, ते कंटेनरमध्ये कॉपी करा, आणि ते अनपॅक करा.
- कौशल्य मेटाडेटा आणि कंटेनर पाथसह मॉडेल संदर्भ अद्ययावत करा.
एखादे स्किल संबंधित आहे की नाही हे ठरवताना, मॉडेल क्रमाक्रमाने त्याच्या सूचनांचा शोध घेते आणि कंटेनरमध्ये शेल कमांड्सद्वारे त्याच्या स्क्रिप्ट्स अंमलात आणते.
सर्व घटक एकत्र केल्यास: Responses API ऑर्केस्ट्रेशन प्रदान करते, शेल टूल अंमलबजावणीयोग्य क्रिया प्रदान करते, hosted container कायमस्वरूपी रनटाइम संदर्भ प्रदान करते, कौशल्यs थर पुनर्वापरयोग्य कार्यप्रवाह तर्क प्रदान करते, आणि compaction एजंटला आवश्यक संदर्भासह दीर्घकाळ चालू राहण्याची परवानगी देते.
या प्रिमिटिव्ह्जसह, एकच प्रॉम्प्ट एंड-टू-एंड वर्कफ्लोमध्ये विस्तारू शकतो: योग्य कौशल्य शोधणे, डेटा फेच करणे, तो स्थानिक संरचित स्थितीत रूपांतरित करणे, त्यावर कार्यक्षमतेने क्वेरी करणे, आणि टिकाऊ आर्टिफॅक्ट्स तयार करणे.
खालील आकृती थेट डेटामधून स्प्रेडशीट तयार करण्यासाठी ही प्रणाली कशी कार्य करते ते दर्शवते.
Responses API एजंटिक कार्य समन्वयित करते
शेल टूल आणि संगणकीय वातावरण एकत्र करून एंड-टू-एंड वर्कफ्लोसाठी सखोल उदाहरण पाहण्यासाठी आमचा विकसक ब्लॉग पोस्ट(नवीन विंडोमध्ये उघडेल) आणि कुकबुक(नवीन विंडोमध्ये उघडेल) पहा, ज्यात एखादी कौशल्य पॅकेज करून ती Responses API द्वारे कशी चालवायची ते दाखवले आहे.
या प्रिमिटिव्ह्जच्या या संचासोबत विकसक काय तयार करतात हे पाहण्यासाठी आम्ही उत्सुक आहोत. भाषा मॉडेल्सचा उद्देश केवळ मजकूर, प्रतिमा आणि ऑडिओ तयार करण्यापेक्षा अधिक आहे–आम्ही आमचे प्लॅटफॉर्म विकसित करत राहू, जेणेकरून ते मोठ्या प्रमाणावर क्लिष्ट, वास्तविक जगातील टास्क्स हाताळण्यात अधिक सक्षम होईल.
