மாடலிலிருந்து ஏஜென்ட்டிற்கு: Responses API-க்கு ஒரு கணினி சூழலை வழங்குதல்

தற்போது, குறிப்பிட்ட பணிகளில் சிறந்து விளங்கும் மாடல்களைப் பயன்படுத்துவதிலிருந்து, சிக்கலான பணிச்சூழல்களை கையாளக்கூடிய ஏஜென்ட்களைப் பயன்படுத்துவதற்கான மாற்றத்தில் நாம் இருக்கிறோம். மாடல்களை உந்துவதன் மூலம், நீங்கள் பயிற்சி பெற்ற நுண்ணறிவை மட்டுமே அணுக முடியும். எனினும், மாடலுக்கு ஒரு கணினி சூழலை வழங்குவது சேவைகளை இயக்குதல், APIகளிலிருந்து தரவை கோருதல், அல்லது விரிதாள்கள் அல்லது அறிக்கைகள் போன்ற மேலும் பயனுள்ள கைவினைகளை உருவாக்குதல் போன்ற மிக விரிவான பயன்பாட்டு நிலைகளை அடைய முடியும்.

ஏஜென்ட்களை உருவாக்க முயற்சிக்கும் போது சில நடைமுறை சிக்கல்கள் தோன்றுகின்றன: இடைநிலை கோப்புகளை எங்கே வைப்பது, பெரிய அட்டவணைகளை ஒரு ப்ராம்ப்ட்-இல் ஒட்டுவதை எவ்வாறு தவிர்ப்பது, பாதுகாப்பு தலைவலியை உருவாக்காமல் பணிப்பாய்வுக்கு நெட்வொர்க் அணுகலை எவ்வாறு வழங்குவது, மேலும் ஒரு பணிப்பாய்வு அமைப்பை நீங்களே உருவாக்காமல் நேர முடிவுகள் மற்றும் மீண்டும் முயற்சிப்புகளை எவ்வாறு கையாளுவது.

டெவலப்பர்கள் தங்களுக்கென செயல்படுத்தும் சூழல்களை உருவாக்க வேண்டிய பொறுப்பை அவர்கள்மீது வைப்பதற்குப் பதிலாக, உண்மையான உலகப் பணிகளை நம்பகமாக செயல்படுத்த ஒரு கணினி சூழலுடன் Responses API⁠(புதிய சாளரத்தில் திறக்கும்) ஐ சீரமைக்க தேவையான கூறுகளை நாங்கள் உருவாக்கினோம்.

OpenAI இன் Responses API, ஷெல் கருவி மற்றும் ஹோஸ்ட் செய்யப்பட்ட கண்டெய்னர் வர்க்ஸ்பேஸ் ஆகியவற்றுடன் சேர்ந்து, இந்த நடைமுறை சிக்கல்களைத் தீர்க்க வடிவமைக்கப்பட்டுள்ளது. மாடல் படிகள் மற்றும் கட்டளைகளை முன்மொழிகிறது; பிளாட்ஃபாரம் அவற்றை உள்ளீடுகள் மற்றும் வெளியீடுகளுக்கான filesystem உடன், விருப்பமான கட்டமைக்கப்பட்ட சேமிப்பு (SQLite போன்றது), மற்றும் கட்டுப்படுத்தப்பட்ட நெட்வொர்க் அணுகல் உடன் ஒரு தனிமைப்படுத்தப்பட்ட சூழலில் இயக்குகிறது. 

இந்த பதிவில், ஏஜென்ட்களுக்கான கணினி சூழலை எவ்வாறு உருவாக்கினோம் என்பதை நாங்கள் பகுப்பாய்வு செய்து, வேகமான, மீண்டும் செய்யக்கூடிய மற்றும் பாதுகாப்பான உற்பத்தி பணிப்பாய்வுகளுக்காக அதை எவ்வாறு பயன்படுத்துவது என்பதற்கான சில ஆரம்ப பாடங்களைப் பகிர்கிறோம்.

ஒரு நல்ல ஏஜென்ட் பணிப்பாய்வு ஒரு இறுக்கமான செயலாக்கச் சுழற்சியுடன் தொடங்குகிறது: மாடல் கோப்புகளைப் படிப்பது அல்லது API மூலம் தரவைப் பெறுவது போன்ற ஒரு நடவடிக்கையை முன்மொழிகிறது, பிளாட்ஃபார்ம் அதை இயக்குகிறது, மேலும் முடிவு அடுத்த படிக்கட்டிற்கு ஊட்டமளிக்கிறது. நாம் ஷெல் கருவியுடன் தொடங்குவோம்—இந்த சுழற்சியை செயல்படுவதைப் பார்க்க மிக எளிய வழி—பின்னர் கண்டெய்னர் வர்க்ஸ்பேஸ், நெட்வொர்க்கிங், மீண்டும் பயன்படுத்தக்கூடிய திறன்கள், மற்றும் சூழல் சுருக்கம் ஆகியவற்றை கவர் செய்வோம்.

ஷெல் கருவியைப் புரிந்துகொள்ள, முதலில் ஒரு மொழி மாடல் பொதுவாக கருவிகளை எவ்வாறு பயன்படுத்துகிறது என்பதைப் புரிந்துகொள்வது பயனுள்ளதாக இருக்கும்: ஒரு செயல்பாட்டை அழைப்பது அல்லது கணினியுடன் தொடர்பு கொள்வது போன்றவற்றைச் செய்ய. பயிற்சியின் போது, ஒரு மாடலுக்கு கருவிகள் எவ்வாறு பயன்படுத்தப்படுகின்றன மற்றும் அதன் விளைவுகள் என்ன என்பதற்கான எடுத்துக்காட்டுகள், படிப்படியாகக் காட்டப்படுகின்றன. இது மாடல் ஒரு கருவியை எப்போது பயன்படுத்த வேண்டும் மற்றும் அதை எவ்வாறு பயன்படுத்த வேண்டும் என்பதை முடிவு செய்ய கற்றுக்கொள்ள உதவுகிறது. நாங்கள் “ஒரு கருவியைப் பயன்படுத்துவது” என்று சொல்வதன் மூலம், மாடல் உண்மையில் ஒரு கருவி அழைப்பை மட்டுமே முன்மொழிகிறது என்பதையே குறிக்கிறோம். அது தனியாகவே அந்த அழைப்பை இயக்க முடியாது.

ஷெல் கருவி மாடலை கணிசமாக மேலும் சக்திவாய்ந்ததாக மாற்றுகிறது: இது கட்டளை வரி மூலம் கணினியுடன் தொடர்பு கொண்டு, உரையைத் தேடுவதிலிருந்து உங்கள் கணினியில் API கோரிக்கைகளை அனுப்புவதுவரை பல்வேறு பணிகளை நிறைவேற்றுகிறது. பரிச்சயமான Unix கருவிகளின் அடிப்படையில் உருவாக்கப்பட்ட எங்கள் ஷெல் கருவி, நீங்கள் எதிர்பார்ப்பதெல்லாம் செய்ய முடியும்; grep, curl, மற்றும் awk போன்ற பயன்பாடுகள் உள்ளமைக்கப்பட்டவையாகவே கிடைக்கின்றன.

எங்கள் தற்போதுள்ள கோட் இன்டர்பிரிட்டருடன் ஒப்பிடுகையில், அது Python மட்டுமே இயக்கும் நிலையில், shell tool மிகவும் பரந்த அளவிலான பயன்பாட்டு நிலைகளை இயலுமைப்படுத்துகிறது; உதாரணமாக Go அல்லது Java நிரல்களை இயக்குவது அல்லது ஒரு NodeJS சர்வரை தொடங்குவது. இந்த நெகிழ்வுத்தன்மை மாடல் சிக்கலான ஏஜென்டிக் பணிகளை நிறைவேற்ற அனுமதிக்கிறது.

தனியாக, ஒரு மாடல் ஷெல் கட்டளைகளை மட்டுமே முன்மொழிய முடியும், ஆனால் இந்த கட்டளைகள் எவ்வாறு செயல்படுத்தப்படுகின்றன? பணியை முடிக்கும் வரை, மாடல் வெளியீட்டைப் பெறவும், கருவிகளை அழைக்கவும், கருவி பதிலை ஒரு லூப்பில் மீண்டும் மாடலுக்கு அனுப்பவும் ஒரு ஒருங்கிணைப்பாளர் தேவை.

Responses API என்பது டெவலப்பர்கள் OpenAI மாடல் உடன் தொடர்பு கொள்ளும் வழியாகும். தனிப்பயன் கருவிகளுடன் பயன்படுத்தும்போது, Responses API கட்டுப்பாட்டை வாடிக்கையாளருக்கு மீண்டும் வழங்குகிறது, மேலும் கருவிகளை இயக்குவதற்கு வாடிக்கையாளருக்கு அதன் சொந்த harness தேவைப்படுகிறது. எனினும், இந்த API பெட்டியிலிருந்தே மாடல் மற்றும் ஹோஸ்ட் செய்யப்பட்ட கருவிகளுக்கிடையில் ஒருங்கிணைப்பையும் செய்ய முடியும். 

Responses API ஒரு ப்ராம்ப்ட்டை பெறும்போது, அது மாடல் சூழலை ஒருங்கிணைக்கிறது: பயனர் ப்ராம்ப்ட், முந்தைய உரையாடல் நிலை, மற்றும் கருவி வழிமுறைகள். ஷெல் செயல்படுத்தல் வேலை செய்ய, ப்ராம்ப்ட் ஷெல் கருவியைப் பயன்படுத்துவதை குறிப்பிட வேண்டும் and தேர்ந்தெடுக்கப்பட்ட மாடல் ஷெல் கட்டளைகளை முன்மொழிய பயிற்சியளிக்கப்பட்டிருக்க வேண்டும்—GPT‑5.2 மற்றும் அதற்குப் பிந்தைய மாடல்கள் இதற்காக பயிற்சியளிக்கப்பட்டுள்ளன. இந்த அனைத்து சூழலுடனும், மாடல் அடுத்த நடவடிக்கையைத் தீர்மானிக்கிறது. அது ஷெல் செயல்படுத்தலைத் தேர்ந்தெடுத்தால், அது Responses API சேவைக்கு ஒன்று அல்லது அதற்கு மேற்பட்ட ஷெல் கட்டளைகளைத் திருப்பி வழங்குகிறது. API சேவை அந்த கட்டளைகளை கண்டெய்னர் ரன்டைமுக்கு முன்னோக்கி அனுப்புகிறது, ஷெல் வெளியீட்டை ஸ்ட்ரீம் செய்து திருப்பி அனுப்புகிறது, மேலும் அடுத்த கோரிக்கையின் சூழலில் அதை மாடலுக்கு வழங்குகிறது. மாடல் பின்னர் முடிவுகளை ஆய்வு செய்யலாம், பின்தொடர்தல் கட்டளைகளை வழங்கலாம், அல்லது ஒரு இறுதி பதிலை உருவாக்கலாம். Responses API இந்த வளையத்தை, மாடல் கூடுதல் ஷெல் கட்டளைகள் இல்லாமல் ஒரு நிறைவைத் திருப்பி வழங்கும் வரை, மீண்டும் மீண்டும் செய்கிறது.

ரெஸ்பான்ஸஸ் API ஒரு ஷெல் கட்டளையை செயல்படுத்தும் போது, அது கண்டெய்னர் சேவைக்கு ஒரு ஸ்ட்ரீமிங் இணைப்பை பராமரிக்கிறது. வெளியீடு உருவாக்கப்படும் போது, மாடல் மேலும் வெளியீட்டுக்காக காத்திருக்க வேண்டுமா, மற்றொரு கட்டளையை இயக்க வேண்டுமா, அல்லது இறுதி பதிலுக்கு நகர வேண்டுமா என்பதை முடிவு செய்யும் வகையில், API அதை கிட்டத்தட்ட நேரடி நேரத்தில் மாடலுக்கு அனுப்புகிறது.

மாடல் ஒரே படியில் பல ஷெல் கட்டளைகளை முன்மொழியலாம், மேலும் Responses API அவற்றை தனித்தனி கண்டெய்னர் அமர்வுகளைப் பயன்படுத்தி ஒரே நேரத்தில் செயல்படுத்தலாம். ஒவ்வொரு அமர்வும் வெளியீட்டை தனித்தனியாக ஸ்ட்ரீம் செய்கிறது, மேலும் API அந்த ஸ்ட்ரீம்களை சூழலாக கட்டமைக்கப்பட்ட கருவி வெளியீடுகளாக மீண்டும் மல்டிப்ளெக்ஸ் செய்கிறது. வேறு வார்த்தைகளில், ஏஜென்ட் லூப் கோப்புகளைத் தேடுதல், தரவைப் பெறுதல், மற்றும் இடைநிலை முடிவுகளைச் சரிபார்த்தல் போன்ற பணிகளை இணையாகச் செய்ய முடியும்.

கட்டளை கோப்பு செயல்பாடுகள் அல்லது தரவு செயலாக்கத்தை உள்ளடக்கியிருக்கும் போது, ஷெல் வெளியீடு மிகப் பெரியதாகி, பயனுள்ள சிக்னல்களைச் சேர்க்காமல் சூழல் பட்ஜெட்டுகளைச் செலவழிக்கக்கூடும். இதை கட்டுப்படுத்த, மாடல் ஒவ்வொரு கட்டளைக்கும் ஒரு வெளியீட்டு வரம்பை குறிப்பிடுகிறது. Responses API அந்த வரம்பை அமல்படுத்தி, நீக்கப்பட்ட உள்ளடக்கத்தை குறியிடும் போது வெளியீட்டின் தொடக்கமும் முடிவும் இரண்டையும் பாதுகாக்கும் வரையறுக்கப்பட்ட முடிவை திருப்பி அளிக்கிறது. உதாரணமாக, நீங்கள் வெளியீட்டை 1,000 எழுத்துகளாக வரையறுக்கலாம், தொடக்கமும் முடிவும் பாதுகாக்கப்பட்ட நிலையில்:

தொடக்கத்தில் உள்ள உரை ... 1000 எழுத்துகள் துண்டிக்கப்பட்டது ... முடிவில் உள்ள உரை.

ஒன்றாக, ஒரே நேரச் செயல்படுத்தலும் வரையறுக்கப்பட்ட வெளியீடும் ஏஜென்ட் லூப்பை வேகமாகவும் சூழல்-திறனுள்ளதாகவும் ஆக்குகின்றன; இதனால் மாடல் மூல டெர்மினல் பதிவுகளால் மூழ்கடிக்கப்படுவதற்குப் பதிலாக பொருத்தமான முடிவுகளின் மீது தொடர்ந்து ரீஸனிங் செய்ய முடியும்.

ஏஜென்ட் லூப்புகளுடன் ஏற்படக்கூடிய ஒரு சாத்தியமான பிரச்சினை என்னவென்றால், பணிகள் நீண்ட நேரம் இயங்கக்கூடும். நீண்ட நேரம் இயங்கும் பணிகள் சூழல் சாளரத்தை நிரப்புகின்றன, இது முறைமாற்றங்களிலும் ஏஜென்ட்களிலும் சூழலை வழங்குவதற்கு முக்கியமானது. ஒரு ஏஜென்ட் ஒரு திறனை அழைத்து, ஒரு பதிலைப் பெற்று, கருவி அழைப்புகள் மற்றும் ரீஸனிங் சுருக்கங்களைச் சேர்ப்பதை கற்பனை செய்யுங்கள்—வரையறுக்கப்பட்ட சூழல் சாளரம் விரைவாக நிரம்பிவிடுகிறது. ஏஜென்ட் தொடர்ந்து இயங்கும்போது முக்கியமான சூழல் இழக்கப்படாமல் இருக்க, முக்கிய விவரங்களை வைத்துக்கொண்டு தேவையற்றவற்றை அகற்ற ஒரு வழி நமக்கு தேவை. டெவலப்பர்கள் தனிப்பயன் சுருக்கம் அல்லது நிலை-தாங்கும் அமைப்புகளை வடிவமைத்து பராமரிக்க வேண்டியதற்குப் பதிலாக, மாடல் எவ்வாறு நடக்கிறது மற்றும் அது எவ்வாறு பயிற்சி பெற்றுள்ளது என்பதுடன் ஒத்திசைவாக இருக்குமாறு வடிவமைக்கப்பட்ட Responses API-யில் நேட்டிவ் காம்பாக்ஷனை நாங்கள் சேர்த்தோம்.

எங்களின் சமீபத்திய மாடல்கள் முந்தைய உரையாடல் நிலையை பகுப்பாய்வு செய்து, முக்கிய முந்தைய நிலையை குறியாக்கப்பட்ட டோக்கன்-திறமையான பிரதிநிதித்துவத்தில் பாதுகாக்கும் ஒரு காம்பாக்ஷன் உருப்படியை உருவாக்க பயிற்சியளிக்கப்பட்டுள்ளன. சுருக்கத்திற்குப் பிறகு, அடுத்த சூழல் சாளரம் இந்த சுருக்க உருப்படியையும் முந்தைய சாளரத்தின் உயர்-மதிப்பு பகுதிகளையும் கொண்டுள்ளது. இது நீட்டிக்கப்பட்ட பல-படி மற்றும் கருவி-இயக்கப்படும் அமர்வுகளிலும் கூட, சாளர எல்லைகளைக் கடந்து பணிப்பாய்வுகள் ஒற்றுமையாகத் தொடர அனுமதிக்கிறது. Codex இந்த செயல்முறையை நம்புகிறது நீண்டகால குறியீட்டுப் பணிகளையும் கருவிகளை மீண்டும் மீண்டும் இயக்குவதையும் தரம் குறையாமல் நிலைநிறுத்த.

சுருக்கம் சேவையகத்தில் உட்பொதிந்ததாகவோ அல்லது தனித்த `/compact` எண்ட்பாயிண்ட் மூலம் கிடைக்கிறது. சர்வர்-சைடு காம்பாக்ஷன் ஒரு த்ரெஷோல்டை உள்ளமைக்க உங்களை அனுமதிக்கிறது, மேலும் சிஸ்டம் தானாகவே காம்பாக்ஷன் நேரத்தைக் கையாளுகிறது, இது சிக்கலான கிளையன்ட்-சைட் லாஜிக்கின் தேவையை நீக்குகிறது. சுருக்கம் செய்வதற்கு முன் உடனடியாக ஏற்படும் சிறிய மீறல்களைத் தாங்க, இது சற்றே பெரிய செயல்திறன் உள்ளீட்டு சூழல் சாளரத்தை அனுமதிக்கிறது; ஆகவே வரம்பை நெருங்கிய கோரிக்கைகள் நிராகரிக்கப்படுவதற்குப் பதிலாக இன்னும் செயலாக்கப்பட்டு சுருக்கப்படலாம். மாடல் பயிற்சி வளர்ச்சியடையும்போது, ஒவ்வொரு OpenAI மாடல் வெளியீட்டுடனும் நேட்டிவ் காம்பாக்ஷன் தீர்வும் அதனுடன் சேர்ந்து வளர்ச்சியடைகிறது.

Codex, காம்பாக்ஷன் அமைப்பை உருவாக்க எங்களுக்கு உதவியது; அதே நேரத்தில் அதன் ஆரம்ப பயனராகவும் இருந்தது. ஒரு Codex நிகழ்வில் காம்பாக்ஷன் பிழை ஏற்பட்டால், விசாரிக்க நாங்கள் இரண்டாவது நிகழ்வை தொடங்குவோம். இதன் விளைவாக, பிரச்சினையில் வேலை செய்ததன் மூலம் Codex-க்கு நேட்டிவ், பயனுள்ள காம்பாக்ஷன் சிஸ்டம் கிடைத்தது. Codex தன்னைத் தானே ஆய்வு செய்து மேம்படுத்திக்கொள்ளும் இந்த திறன், OpenAI-யில் பணிபுரிவதில் குறிப்பாக சுவாரஸ்யமான ஒரு பகுதியாக மாறியுள்ளது. பெரும்பாலான கருவிகள் பயனரிடம் அவற்றை எவ்வாறு பயன்படுத்துவது என்பதை மட்டும் கற்றுக்கொள்ள வேண்டுமெனக் கோரும்; Codex நம்முடன் ஒன்றாக கற்றுக்கொள்கிறது.

இப்போது, நிலை மற்றும் ஆதாரங்களைப் பற்றி பேசலாம். கன்டெய்னர் என்பது கட்டளைகளை இயக்குவதற்கான இடம் மட்டுமல்ல, மாடலுக்கான வேலை செய்யும் சூழலாகவும் செயல்படுகிறது. கன்டெய்னருக்குள், நெட்வொர்க் கொள்கை கட்டுப்பாடுகளின் கீழ் மாடல் கோப்புகளை வாசிக்கவும், தரவுத்தளங்களை வினவவும், வெளிப்புற அமைப்புகளை அணுகவும் முடியும்.

கொள்கலன் சூழலின் முதல் பகுதி வளங்களை பதிவேற்றம், ஒழுங்கமைத்தல் மற்றும் நிர்வகித்தலுக்கான கோப்பு முறைமை. கிடைக்கக்கூடிய தரவுகளின் வரைபடத்தை மாடலுக்கு வழங்கவும், பரந்த, சத்தமுள்ள ஸ்கேன்களைச் செய்வதற்குப் பதிலாக இலக்கிடப்பட்ட கோப்பு செயல்பாடுகளைத் தேர்வு செய்யவும் உதவுவதற்காக, நாங்கள் கண்டெய்னர் மற்றும் கோப்பு⁠(புதிய சாளரத்தில் திறக்கும்) APIகளை உருவாக்கினோம்.

ஒரு பொதுவான எதிர்முறை என்பது அனைத்து உள்ளீட்டையும் நேரடியாக ப்ராம்ப்ட் சூழலில் அடுக்கிவைப்பதாகும். உள்ளீடுகள் பெருகும்போது, ப்ராம்ப்ட்டை அதிகமாக நிரப்புவது செலவாகவும் மாடலுக்கு வழிநடத்த கடினமாகவும் ஆகிறது. ஒரு சிறந்த முறையாக, வளங்களை கண்டெய்னர் கோப்பு அமைப்பில் ஸ்டேஜ் செய்து, ஷெல் கட்டளைகளின் மூலம் எதைத் திறக்க, பார்ஸ் செய்ய, அல்லது மாற்ற வேண்டும் என்பதை மாடல் முடிவு செய்ய விடுங்கள். மனிதர்களைப் போலவே, மாடல்கள் ஒழுங்கமைக்கப்பட்ட தகவலுடன் சிறப்பாக செயல்படும்.

கண்டெய்னர் சூழலின் இரண்டாவது பகுதி தரவுத்தளங்கள். பல சந்தர்ப்பங்களில், டெவலப்பர்கள் கட்டமைக்கப்பட்ட தரவை SQLite போன்ற தரவுத்தளங்களில் சேமித்து, அவற்றை வினவுமாறு நாங்கள் பரிந்துரைக்கிறோம். உதாரணமாக, ஒரு முழு விரிதாளை ப்ராம்ப்ட்டில் நகலெடுப்பதற்குப் பதிலாக, அட்டவணைகள் பற்றிய ஒரு விளக்கத்தை—எந்த நெடுவரிசைகள் உள்ளன, அவை என்ன அர்த்தம் என்பதையும்—மாடலுக்கு வழங்கலாம், மேலும் அதற்கு தேவையான வரிசைகளை அது எடுத்துக்கொள்ளட்டும்.

உதாரணமாக, நீங்கள், “இந்த காலாண்டில் எந்த தயாரிப்புகளின் விற்பனை குறைந்தது?” என்று கேட்டால், மாடல் முழு ஸ்பிரெட்ஷீட்டை ஸ்கேன் செய்வதற்குப் பதிலாக just தொடர்புடைய வரிசைகளை மட்டுமே வினவ முடியும். இது வேகமாகவும், மலிவாகவும், பெரிய தரவுத் தொகுப்புகளுக்கு மேலும் விரிவுபடுத்தக்கூடியதாகவும் உள்ளது.

கண்டெய்னர் சூழலின் மூன்றாவது பகுதி நெட்வொர்க் அணுகல் ஆகும், இது ஏஜென்ட் பணிச்சுமைகளின் முக்கியமான பகுதியாகும். ஏஜென்ட் பணிப்பாய்வுக்கு நேரடி தரவைப் பெற, வெளிப்புற APIs ஐ அழைக்க, அல்லது பேக்கேஜ்களை நிறுவ வேண்டியிருக்கலாம். அதே நேரத்தில், கண்டெய்னர்களுக்கு கட்டுப்பாடற்ற இணைய அணுகலை வழங்குவது அபாயகரமாக இருக்கலாம்: அது தகவல்களை வெளிப்புற வலைத்தளங்களுக்கு வெளிப்படுத்தலாம், தவறுதலாக நுண்ணுணர்வான உள்துறை அல்லது மூன்றாம் தரப்பு அமைப்புகளைத் தொடலாம், அல்லது அங்கீகாரத் தகவல் கசிவுகள் மற்றும் தரவு வெளியேற்றத்திலிருந்து பாதுகாப்பதை மேலும் கடினமாக்கலாம்.

ஏஜென்ட்களின் பயன்தன்மையை கட்டுப்படுத்தாமல் இந்த கவலைகளை தீர்க்க, sidecar egress proxy ஐ பயன்படுத்த நாங்கள் ஹோஸ்டட் கண்டெய்னர்களை உருவாக்கினோம். அனைத்து வெளிப்புற நெட்வொர்க் கோரிக்கைகளும் அனுமதி பட்டியல்கள் மற்றும் அணுகல் கட்டுப்பாடுகளை அமல்படுத்தும், அதே நேரத்தில் டிராஃபிக்கை காணக்கூடியதாக வைத்திருக்கும் மையமாக்கப்பட்ட கொள்கை அடுக்கு வழியாக பாய்கின்றன. சான்றுகளுக்காக, நாங்கள் egress இல் டொமைன்-வரம்புடைய ரகசிய செருகலைப் பயன்படுத்துகிறோம். மாடல் மற்றும் கொள்கலன் இடம்பிடிப்புகளை மட்டுமே பார்க்கின்றன, அதே நேரத்தில் மூல ரகசிய மதிப்புகள் மாடல்-தெரியும் சூழலுக்கு வெளியே இருக்கும் மற்றும் அங்கீகரிக்கப்பட்ட இடங்களுக்கு மட்டுமே பயன்படுத்தப்படும். இது கசிவு அபாயத்தை குறைக்கிறது, அதே நேரத்தில் அங்கீகரிக்கப்பட்ட வெளிப்புற அழைப்புகளை இன்னும் செயல்படுத்துகிறது.

ஷெல் கட்டளைகள் சக்திவாய்ந்தவை, ஆனால் பல பணிகள் அதே பல-படி முறைமைகளை மீண்டும் மீண்டும் செய்கின்றன. ஒவ்வொரு இயக்கத்திலும் ஏஜென்ட்கள் பணிப்பாய்வை மீண்டும் கண்டுபிடிக்க வேண்டியுள்ளது—மீண்டும் திட்டமிடுதல், கட்டளைகளை மீண்டும் வெளியிடுதல், மற்றும் நடைமுறைகளை மீண்டும் கற்றுக்கொள்ளுதல்—இதனால் ஒற்றுமையற்ற முடிவுகளும் வீணான செயல்படுத்தலும் ஏற்படுகின்றன. ஏஜென்ட் திறன்கள்⁠(புதிய சாளரத்தில் திறக்கும்) அந்த வடிவங்களை மீண்டும் பயன்படுத்தக்கூடிய, ஒன்றிணைக்கக்கூடிய கட்டுமானத் தொகுதிகளாக தொகுக்கின்றன. உறுதியான முறையில், ஒரு திறன் என்பது ‘SKILL.md⁠(புதிய சாளரத்தில் திறக்கும்)’ ஐ உள்ளடக்கிய ஒரு கோப்புறை தொகுப்பாகும் (மெட்டாடேட்டா மற்றும் வழிமுறைகள் கொண்ட) மேலும் API விவரக்குறிப்புகள் மற்றும் UI வளங்கள் போன்ற எந்த ஆதரவு வளங்களும்.

இந்த அமைப்பு, நாங்கள் முன்பு விவரித்த இயக்க நேர கட்டமைப்புடன் இயல்பாக பொருந்துகிறது. கண்டெய்னர் நிலையான கோப்புகள் மற்றும் செயல்படுத்தல் சூழலை வழங்குகிறது, மேலும் ஷெல் கருவி செயல்படுத்தல் இடைமுகத்தை வழங்குகிறது. இரண்டும் இடத்தில் இருந்தால், மாடல் தேவையானபோது ஷெல் கட்டளைகள் (`ls`, `cat`, etc.) பயன்படுத்தி திறன் கோப்புகளை கண்டறியவும், வழிமுறைகளைப் புரிந்துகொள்ளவும், மற்றும் அதே ஏஜென்ட் லூப்பில் திறன் ஸ்கிரிப்ட்களை இயக்கவும் முடியும்.

OpenAI தளத்தில் திறன்களை நிர்வகிக்க APIs⁠(புதிய சாளரத்தில் திறக்கும்) வழங்குகிறோம். டெவலப்பர்கள் திறன் கோப்புறைகளை பதிப்பிடப்பட்ட பண்டில்களாக பதிவேற்றி சேமிக்கிறார்கள்; பின்னர் அவற்றை திறன் ID மூலம் மீட்டெடுக்கலாம். மாடலுக்கு ப்ராம்ப்ட்டை அனுப்புவதற்கு முன், Responses API திறனை ஏற்றி அதை மாடல் சூழலில் சேர்க்கிறது. இந்த வரிசை நிர்ணயமானது:

1. பெயர் மற்றும் விளக்கத்தை உட்பட திறன் மெட்டாடேட்டாவை பெறவும்.
2. திறன் தொகுப்பை பெற்று, அதை கன்டெய்னரில் நகலெடுத்து, அதை அவிழ்த்து விடுங்கள்.
3. திறன் மெட்டாடேட்டா மற்றும் கண்டெய்னர் பாதையுடன் மாடல் சூழலை புதுப்பிக்கவும்.

ஒரு திறன் தொடர்புடையதா என்பதைத் தீர்மானிக்கும் போது, மாடல் அதன் வழிமுறைகளை படிப்படியாக ஆராய்ந்து, கண்டெய்னரில் ஷெல் கட்டளைகள் மூலம் அதன் ஸ்கிரிப்ட்களை செயல்படுத்துகிறது.

அனைத்து கூறுகளையும் ஒன்றாக இணைத்துப் பார்க்கும்போது: Responses API ஒருங்கிணைப்பை வழங்குகிறது, shell tool செயல்படுத்தக்கூடிய செயல்களை வழங்குகிறது, hosted container நிலையான இயக்கநேர சூழலை வழங்குகிறது, skills அடுக்கு மீண்டும் பயன்படுத்தக்கூடிய பணிப்பாய்வு தர்க்கத்தை வழங்குகிறது, மேலும் compaction ஒரு ஏஜென்ட்-ஐ அதற்குத் தேவையான சூழலுடன் நீண்ட நேரம் இயங்க அனுமதிக்கிறது.

இந்த அடிப்படை கூறுகளுடன், ஒரு ஒற்றை ப்ராம்ப்ட் தொடக்கம் முதல் முடிவுவரை பணிப்பாய்வாக விரிவடைய முடியும்: சரியான திறனை கண்டறிதல், தரவைப் பெறுதல், அதை உள்ளூர் கட்டமைக்கப்பட்ட நிலையாக மாற்றுதல், அதை திறமையாக வினவுதல், மற்றும் நீடித்த கலைப்பொருட்களை உருவாக்குதல். 

கீழே உள்ள வரைபடம், நேரடி தரவிலிருந்து ஒரு ஸ்பிரெட்ஷீட்டை உருவாக்க இந்த அமைப்பு எவ்வாறு செயல்படுகிறது என்பதைக் காட்டுகிறது.

முழுமையான வொர்க்ஃப்ளோக்களுக்காக ஷெல் கருவி மற்றும் கணினி சூழலை இணைப்பதற்கான ஆழமான உதாரணத்திற்காக, எங்கள் டெவலப்பர் வலைப்பதிவு பதிவை⁠(புதிய சாளரத்தில் திறக்கும்) மற்றும் குக்புக்⁠(புதிய சாளரத்தில் திறக்கும்) பார்க்கவும்; இதில் ஒரு ஸ்கில்லைக் பேக்கேஜ் செய்து அதை Responses API மூலம் செயல்படுத்துவது படிப்படியாக விளக்கப்பட்டுள்ளது.

இந்த அடிப்படை கூறுகளின் தொகுப்பைப் பயன்படுத்தி டெவலப்பர்கள் எதை உருவாக்குகிறார்கள் என்பதைப் பார்க்க நாங்கள் உற்சாகமாக உள்ளோம். மொழி மாடல்கள் உரை, படங்கள், மற்றும் ஆடியோவை உருவாக்குவதைக் காட்டிலும் அதிகம் செய்யவே உருவாக்கப்பட்டவை–சிக்கலான, நிஜ உலகப் பணிகளை அளவிலாக கையாள்வதில் மேலும் திறன் பெறும் வகையில் எங்கள் பிளாட்ஃபார்மை தொடர்ந்து மேம்படுத்துவோம்.