મોડલથી એજન્ટ સુધી: Responses API ને કમ્પ્યુટર પર્યાવરણથી સજ્જ કરવું

હાલમાં અમે એવા પરિવર્તનમાંથી જઈ રહ્યા છીએ જ્યાં ખાસ કાર્યોમાં નિપુણ મોડલ્સનો ઉપયોગ થતો હતો, ત્યાંથી જટિલ workflows સંભાળી શકે એવા એજન્ટ્સના ઉપયોગ તરફ આગળ વધી રહ્યા છીએ. મોડલ્સને પ્રોમ્પ્ટ કરીને તમે માત્ર તાલીમિત બુદ્ધિ સુધી પહોંચો છો. પરંતુ મોડલને કમ્પ્યુટર પર્યાવરણ આપવાથી services ચલાવવી, APIs માંથી data માગવું, અથવા spreadsheets કે reports જેવા વધુ ઉપયોગી આર્ટિફેક્ટ્સ બનાવવું જેવા વધુ વ્યાપક ઉપયોગકેસ શક્ય બને છે.

જ્યારે તમે એજન્ટ્સ બનાવવા પ્રયત્ન કરો છો ત્યારે થોડા વ્યવહારિક પ્રશ્નો ઊભા થાય છે: મધ્યવર્તી files ક્યાં રાખવી, મોટી tables ને પ્રોમ્પ્ટમાં paste કરવી ટાળવી કેવી રીતે, સુરક્ષાની મુશ્કેલી ઉભી કર્યા વગર workflow ને network access કેવી રીતે આપવી, અને workflow system જાતે બનાવ્યા વગર timeouts અને retries કેવી રીતે સંભાળવા.

ડેવલપર્સ પર પોતાનું execution environment બનાવવા જવાબદારી મૂકવાની જગ્યાએ, અમે Responses API⁠(નવી વિન્ડોમાં ખૂલે છે) ને કમ્પ્યુટર પર્યાવરણથી સજ્જ કરવા માટે જરૂરી ઘટકો બનાવ્યા જેથી વાસ્તવિક દુનિયાના કાર્યો વિશ્વસનીય રીતે ચલાવી શકાય.

OpenAI ની Responses API, shell tool અને hosted container workspace સાથે મળીને, આ વ્યવહારિક પ્રશ્નો ઉકેલવા માટે ડિઝાઇન કરવામાં આવી છે. મોડલ પગલાં અને commands સૂચવે છે. પ્લેટફોર્મ તેમને isolated environment માં ચલાવે છે, જ્યાં inputs અને outputs માટે filesystem, વૈકલ્પિક structured storage (જેમ કે SQLite) અને મર્યાદિત network access હોય છે.

આ પોસ્ટમાં, અમે એજન્ટ્સ માટે કમ્પ્યુટર પર્યાવરણ કેવી રીતે બનાવ્યું તેનું વિભાજન કરીશું અને ઝડપી, વધુ પુનરાવર્તિત અને વધુ સુરક્ષિત production workflows માટે તેનો ઉપયોગ કેવી રીતે કરવો તેના કેટલાક પ્રારંભિક પાઠો શેર કરીશું.

સારો એજન્ટ workflow મજબૂત execution loop થી શરૂ થાય છે: મોડલ files વાંચવા અથવા API દ્વારા data મેળવવા જેવી ક્રિયા સૂચવે છે, પ્લેટફોર્મ તેને ચલાવે છે, અને પરિણામ આગળના પગલાંમાં જાય છે. અમે shell tool થી શરૂ કરીશું—આ લૂપને કાર્યરત રીતે જોવા માટેનો સૌથી સરળ માર્ગ—અને પછી container workspace, networking, reusable skills અને context compaction પર આવશે.

shell tool સમજવા માટે, પહેલાં સામાન્ય રીતે language model ટૂલ્સ કેવી રીતે વાપરે છે તે સમજવું ઉપયોગી છે: જેમ કે function call કરવી અથવા કમ્પ્યુટર સાથે ક્રિયા કરવી. તાલીમ દરમિયાન, મોડલને tools કેવી રીતે વપરાય છે અને તેના પગલા-દર-પગલા પરિણામો શું થાય છે તેના ઉદાહરણો બતાવવામાં આવે છે. આ મોડલને ક્યારે tool વાપરવું અને કેવી રીતે વાપરવું તે શીખવામાં મદદ કરે છે. જ્યારે અમે “tool વાપરવું” કહીએ છીએ, ત્યારે અમારો અર્થ એ છે કે મોડલ ખરેખર માત્ર tool call સૂચવે છે. તે call પોતે ચલાવી શકતું નથી.

shell tool મોડલને નોંધપાત્ર રીતે વધુ શક્તિશાળી બનાવે છે: તે command line દ્વારા કમ્પ્યુટર સાથે ક્રિયા કરીને લખાણ શોધવાથી લઈને તમારી કમ્પ્યુટર પરથી API requests મોકલવા સુધીના વિવિધ કાર્યો કરે છે. ઓળખાણના Unix tooling પર આધારિત, અમારી shell tool માં grep, curl અને awk જેવી utilities મૂળભૂત રીતે ઉપલબ્ધ છે.

અમારા હાલના code interpreterની સરખામણીમાં, જે ફક્ત Python ચલાવે છે, shell tool વધુ વ્યાપક ઉપયોગકેસ શક્ય બનાવે છે, જેમ કે Go અથવા Java programs ચલાવવું અથવા NodeJS server શરૂ કરવો. આ લવચીકતા મોડલને જટિલ agentic કાર્યો પૂરાં કરવામાં મદદ કરે છે.

પોતાના બળે, મોડલ ફક્ત shell commands સૂચવી શકે છે, પરંતુ આ commands ચલાવવામાં કેવી રીતે આવે? કાર્ય પૂર્ણ થાય ત્યાં સુધી loop માં મોડલ આઉટપુટ મેળવવા, tools બોલાવવા અને tool response ને ફરી મોડલ સુધી પહોંચાડવા માટે અમને orchestrator જોઈએ.

Responses API એ રીત છે જેના દ્વારા developers OpenAI મોડલ્સ સાથે ક્રિયા કરે છે. જ્યારે custom tools સાથે તેનો ઉપયોગ થાય છે, ત્યારે Responses API નિયંત્રણ ફરી client ને આપે છે, અને tools ચલાવવા માટે client ને પોતાનો harness જોઈએ. છતાં, આ API મૂળભૂત રીતે મોડલ અને hosted tools વચ્ચે orchestration પણ કરી શકે છે.

જ્યારે Responses API ને પ્રોમ્પ્ટ મળે છે, ત્યારે તે model context એકત્ર કરે છે: user prompt, અગાઉની conversation state અને tool instructions. shell execution કામ કરે તે માટે, prompt માં shell tool વાપરવાનો ઉલ્લેખ હોવો જોઈએ અને પસંદ કરાયેલ મોડલ shell commands સૂચવવા માટે તાલીમિત હોવું જોઈએ—GPT‑5.2 અને ત્યારબાદના મોડલ્સ માટે આ તાલીમિત છે. આ તમામ context સાથે, મોડલ પછીનું પગલું નક્કી કરે છે. જો તે shell execution પસંદ કરે, તો તે Responses API service ને એક અથવા વધુ shell commands પરત આપે છે. API service એ commands ને container runtime સુધી પહોંચાડે છે, shell output સ્ટ્રીમ કરીને પાછું આપે છે અને આગલી request ના context માં તેને મોડલ સુધી પહોંચાડે છે. ત્યારબાદ મોડલ પરિણામો તપાસી શકે છે, અનુગામી commands આપી શકે છે અથવા અંતિમ જવાબ આપી શકે છે. Responses API આ લૂપ ત્યાં સુધી દોહરાવે છે જ્યાં સુધી મોડલ વધારાના shell commands વગર completion પરત ન આપે.

જ્યારે Responses API shell command ચલાવે છે, ત્યારે તે container service સાથે streaming connection જાળવે છે. જેમ જેમ output ઉત્પન્ન થાય છે, API તેને લગભગ વાસ્તવિક સમયમાં મોડલ સુધી પહોંચાડે છે જેથી મોડલ નક્કી કરી શકે કે વધુ output માટે રાહ જોવી, બીજી command ચલાવવી કે અંતિમ પ્રતિસાદ પર જવું.

મોડલ એક જ પગલામાં બહુવિધ shell commands સૂચવી શકે છે, અને Responses API તેમને અલગ container sessions દ્વારા સમકાલીન રીતે ચલાવી શકે છે. દરેક session સ્વતંત્ર રીતે output સ્ટ્રીમ કરે છે, અને API આ streams ને context તરીકે structured tool outputs માં multiplex કરે છે. એટલે કે, agent loop files શોધવા, data મેળવવા અને મધ્યવર્તી પરિણામો ચકાસવા જેવા કામને parallelize કરી શકે છે.

જ્યારે command માં file operations અથવા data processing સામેલ હોય, ત્યારે shell output બહુ મોટું થઈ શકે છે અને ઉપયોગી સંકેતો ઉમેર્યા વગર context budget વાપરી શકે છે. આ નિયંત્રિત કરવા માટે, મોડલ દરેક command માટે output cap નિર્ધારિત કરે છે. Responses API તે cap અમલમાં મૂકે છે અને એવું મર્યાદિત પરિણામ પરત આપે છે જે output ની શરૂઆત અને અંત બંને જાળવે છે, સાથે છોડાયેલ સામગ્રીનું ચિહ્નન પણ કરે છે. ઉદાહરણ તરીકે, તમે output ને 1,000 characters સુધી મર્યાદિત કરી શકો, જેમાં શરૂઆત અને અંત સાચવવામાં આવે:

શરૂઆતમાં લખાણ ... 1000 chars truncated ... અંતે લખાણ

સમકાલીન execution અને મર્યાદિત output મળીને agent loop ને ઝડપી અને context-efficient બનાવે છે જેથી મોડલ raw terminal logs થી ભરડાઈ જવાને બદલે સંબંધિત પરિણામો પર reasoning ચાલુ રાખી શકે.

agent loops સાથેની એક સંભવિત સમસ્યા એ છે કે કાર્યો લાંબા સમય સુધી ચાલી શકે છે. લાંબા ચાલતા કાર્યો context window ભરી દે છે, જે turns અને agents વચ્ચે context જાળવવા માટે મહત્વપૂર્ણ છે. કલ્પના કરો કે એજન્ટ કોઈ skill બોલાવે, પ્રતિસાદ મેળવે, tool calls અને reasoning summaries ઉમેરે—મર્યાદિત context window ઝડપથી ભરાઈ જાય છે. એજન્ટ ચાલુ રહે ત્યારે મહત્વપૂર્ણ context ન ગુમાય તે માટે, અમને મુખ્ય વિગતો જાળવવાનો અને ગેરજરૂરી બાબતો દૂર કરવાનો માર્ગ જોઈએ. Developers ને custom summarization અથવા state-carrying systems ડિઝાઇન અને જાળવવાની જરૂર ન પડે તે માટે, અમે Responses API માં native compaction ઉમેર્યું છે, જે મોડલ કેવી રીતે વર્તે છે અને તેને કેવી તાલીમ આપવામાં આવી છે તેની સાથે સુસંગત રીતે ડિઝાઇન કરાયું છે.

અમારા તાજેતરના મોડલ્સને અગાઉની conversation state નું વિશ્લેષણ કરીને encrypted અને token-efficient representation માં મુખ્ય prior state જાળવનાર compaction item બનાવવાની તાલીમ આપવામાં આવી છે. compaction પછી, આગળની context window આ compaction item અને અગાઉની window ના high-value ભાગોથી બને છે. આથી workflows વિન્ડો સીમાઓ પાર પણ સુસંગત રીતે ચાલુ રહી શકે છે, ખાસ કરીને લાંબી multi-step અને tool-driven sessions માં. Codex આ મિકેનિઝમ પર આધાર રાખે છે જેથી લાંબા ચાલતા coding કાર્યો અને પુનરાવર્તિત tool execution ગુણવત્તા ઘટ્યા વગર ચાલુ રહી શકે.

compaction server પર built-in રૂપે અથવા સ્વતંત્ર /compact એન્ડપોઇન્ટ દ્વારા ઉપલબ્ધ છે. Server-side compaction તમને threshold કન્ફિગર કરવાની મંજૂરી આપે છે, અને સિસ્ટમ compaction timing આપમેળે સંભાળે છે, જેથી જટિલ client-side logic ની જરૂર રહેતી નથી. તે compaction પહેલાંની નાની વધારાની મર્યાદાઓ સહન કરવા માટે થોડું મોટું effective input context window મંજૂર કરે છે, જેથી મર્યાદા નજીકની requests reject થવાને બદલે process અને compact થઈ શકે. જેમ જેમ મોડલ તાલીમ વિકસે છે, તેમ native compaction solution પણ દરેક OpenAI મોડલ release સાથે વિકસે છે.

Codex એ compaction system બનાવવામાં અમને મદદ કરી અને પોતે તેના પ્રારંભિક વપરાશકર્તા તરીકે પણ કામ કર્યું. જ્યારે કોઈ Codex instance ને compaction error મળતી, ત્યારે અમે તપાસ માટે બીજી instance શરૂ કરતા. પરિણામે, સમસ્યા પર કામ કરતાં કરતાં Codex ને native, અસરકારક compaction system મળી ગઈ. Codex ની પોતાની તપાસ અને પોતાને સુધારવાની આ ક્ષમતા OpenAI માં કામ કરવાનો ખાસ રસપ્રદ ભાગ બની ગઈ છે. મોટા ભાગના tools માં ફક્ત વપરાશકર્તાએ જ તેનો ઉપયોગ શીખવો પડે છે. Codex અમારાં સાથે શીખે છે.

હવે state અને resources આવરી લઈએ. કન્ટેનર ફક્ત commands ચલાવવાની જગ્યા નથી, પરંતુ મોડલ માટે કામકાજનો context પણ છે. કન્ટેનરની અંદર, મોડલ files વાંચી શકે છે, databases query કરી શકે છે અને network policy controls હેઠળ બાહ્ય systems ઍક્સેસ કરી શકે છે.

કન્ટેનર કોન્ટેક્સ્ટનો પ્રથમ ભાગ file system છે, જે resources upload, ગોઠવવા અને મેનેજ કરવા માટે છે. અમે મોડલને ઉપલબ્ધ data નો નકશો આપવા અને વ્યાપક, અવાજવાળી scans કરવા બદલે targeted file operations પસંદ કરવામાં મદદ કરવા માટે container and file⁠(નવી વિન્ડોમાં ખૂલે છે) APIs બનાવ્યાં.

એક સામાન્ય anti-pattern એ છે કે બધું input સીધું prompt context માં ભરી દેવું. inputs વધતાં જાય ત્યારે prompt ભરમારીવાળો બને છે, ખર્ચાળ બને છે અને મોડલ માટે તેને સમજવો મુશ્કેલ બને છે. વધુ સારી રીત એ છે કે resources ને container file system માં stage કરવો અને મોડલને shell commands થી શું ખોલવું, parse કરવું અથવા transform કરવું તે નક્કી કરવા દેવું. મનુષ્યોની જેમ, મોડલ્સ પણ ગોઠવેલી માહિતી સાથે વધુ સારું કામ કરે છે.

કન્ટેનર કોન્ટેક્સ્ટનો બીજો ભાગ databases છે. ઘણા કિસ્સાઓમાં, અમે developers ને સૂચવીએ છીએ કે structured data SQLite જેવા databases માં સંગ્રહિત કરો અને તેમને query કરો. ઉદાહરણ તરીકે, આખી spreadsheet ને prompt માં copy કરવાની બદલે, તમે મોડલને tables નું વર્ણન આપી શકો—કયા columns છે અને તેમનો અર્થ શું છે—અને પછી તેને જરૂરી rows ખેંચવા દો.

ઉદાહરણ તરીકે, જો તમે પૂછો, “આ ક્વાર્ટરમાં કયા products ની sales ઘટી હતી?” તો મોડલ આખી spreadsheet સ્કેન કરવા બદલે માત્ર સંબંધિત rows query કરી શકે છે. આ વધુ ઝડપી, સસ્તું અને મોટા datasets માટે વધુ scalable છે.

કન્ટેનર કોન્ટેક્સ્ટનો ત્રીજો ભાગ નેટવર્ક ઍક્સેસ છે, જે એજન્ટ વર્કલોડનો આવશ્યક ભાગ છે. એજન્ટ વર્કફ્લોને live data મેળવવાની, બાહ્ય APIs બોલાવવાની અથવા packages ઇન્સ્ટોલ કરવાની જરૂર પડી શકે છે. તે જ સમયે, કન્ટેનર્સને અનિયંત્રિત ઇન્ટરનેટ ઍક્સેસ આપવી જોખમી બની શકે છે: તે બાહ્ય websites પર માહિતી ખુલ્લી પાડી શકે છે, અનાયાસે સંવેદનશીલ આંતરિક અથવા third-party systems સુધી પહોંચી શકે છે, અથવા credential leaks અને data exfiltration સામે રક્ષણ કરવું વધુ મુશ્કેલ બનાવી શકે છે.

એજન્ટ્સની ઉપયોગિતા મર્યાદિત કર્યા વગર આ ચિંતાઓ ઉકેલવા માટે, અમે hosted containers ને sidecar egress proxy વાપરવા માટે બનાવ્યા. બધા outbound network requests એક કેન્દ્રિત policy layer માંથી પસાર થાય છે, જે allowlists અને access controls અમલમાં મૂકે છે અને સાથે ટ્રાફિકને દૃશ્યમાન રાખે છે. credentials માટે, અમે egress પર domain-scoped secret injection વાપરીએ છીએ. મોડલ અને કન્ટેનર માત્ર placeholders જ જુએ છે, જ્યારે raw secret values મોડલ-દૃશ્યમાન context ની બહાર જ રહે છે અને માત્ર મંજૂર destinations માટે લાગુ પડે છે. આ લીકેજનો જોખમ ઘટાડે છે અને સાથે authenticated external calls પણ શક્ય બનાવે છે.

Shell commands શક્તિશાળી છે, પરંતુ ઘણા કાર્યોમાં એ જ બહુ-પગલાવાળા પેટર્ન વારંવાર આવે છે. એજન્ટ્સને દરેક run માં ફરી workflow શોધવો પડે છે—ફરી આયોજન કરવું, ફરી commands આપવી અને ફરી conventions શીખવી—જે અસંગત પરિણામો અને વ્યર્થ એક્ઝિક્યુશન તરફ દોરી જાય છે. Agent skills⁠(નવી વિન્ડોમાં ખૂલે છે) એ પેટર્નને ફરી વાપરી શકાય અને સંયોજન કરી શકાય એવા building blocks માં પેક કરે છે. સ્પષ્ટ રીતે કહીએ તો, skill એ folder bundle છે જેમાં ‘SKILL.md⁠(નવી વિન્ડોમાં ખૂલે છે)’ (metadata અને instructions સાથે) તેમજ API specs અને UI assets જેવા સહાયક resources સામેલ હોય છે.

આ રચના અમે અગાઉ વર્ણવેલી runtime architecture સાથે સ્વાભાવિક રીતે મેળ ખાતી આવે છે. કન્ટેનર persistent files અને execution context પૂરો પાડે છે, અને shell tool execution interface આપે છે. બંને ઉપલબ્ધ હોય ત્યારે, મોડલ જરૂર પડે ત્યારે shell commands (`ls`, `cat`, વગેરે) નો ઉપયોગ કરીને skill files શોધી શકે છે, instructions સમજી શકે છે અને એ જ agent loop માં skill scripts ચલાવી શકે છે.

અમે OpenAI platform માં skills મેનેજ કરવા માટે APIs⁠(નવી વિન્ડોમાં ખૂલે છે) પૂરી પાડીએ છીએ. Developers skill folders ને versioned bundles તરીકે upload અને store કરે છે, જે પછી skill ID દ્વારા પાછાં મેળવી શકાય છે. મોડલને prompt મોકલતાં પહેલાં, Responses API skill લોડ કરે છે અને તેને model context માં સામેલ કરે છે. આ ક્રમ નિશ્ચિત છે:

1. નામ અને વર્ણન સહિત skill metadata મેળવો.
2. skill bundle મેળવો, તેને container માં copy કરો અને unpack કરો.
3. skill metadata અને container path સાથે model context અપડેટ કરો.

skill સંબંધિત છે કે નહીં તે નક્કી કરતી વખતે, મોડલ તેની instructions ને ક્રમશઃ તપાસે છે અને container માં shell commands મારફતે તેની scripts ચલાવે છે.

બધા ભાગોને એકસાથે મૂકી કહીએ તો: Responses API orchestration આપે છે, shell tool ચાલી શકતી ક્રિયાઓ આપે છે, hosted container persistent runtime context આપે છે, skills ફરી વાપરી શકાય તેવી workflow logic ઉમેરે છે, અને compaction એજન્ટને જરૂરી context સાથે લાંબા સમય સુધી ચલાવવાની મંજૂરી આપે છે.

આ primitives સાથે, એક જ પ્રોમ્પ્ટ end-to-end workflow માં વિસ્તરી શકે છે: યોગ્ય skill શોધવી, data મેળવવું, તેને સ્થાનિક structured state માં રૂપાંતરિત કરવું, કાર્યક્ષમ રીતે query કરવું અને ટકાઉ આર્ટિફેક્ટ્સ જનરેટ કરવું.

નીચેનું ચિત્ર બતાવે છે કે live data માંથી spreadsheet બનાવવા માટે આ સિસ્ટમ કેવી રીતે કામ કરે છે.

end-to-end workflows માટે shell tool અને computer environment ને જોડવાનું ઊંડાણપૂર્વકનું ઉદાહરણ જોવા માટે, skill ને package કરવું અને તેને Responses API મારફતે ચલાવવું સમજાવતી અમારી developer blog post⁠(નવી વિન્ડોમાં ખૂલે છે) અને cookbook⁠(નવી વિન્ડોમાં ખૂલે છે) જુઓ.

આ primitives ના સમૂહ સાથે developers શું બનાવે છે તે જોવા માટે અમે ઉત્સુક છીએ. Language models નો હેતુ ફક્ત લખાણ, છબીઓ અને ઑડિયો જનરેટ કરવો નથી. મોટા પાયે જટિલ, વાસ્તવિક દુનિયાના કાર્યો સંભાળવામાં વધુ સક્ષમ બનવા માટે અમે અમારી platform ને સતત વિકસિત કરતા રહીશું.