মডেলকে এজেন্টে রূপান্তর: Responses API-কে একটি কম্পিউটার এনভায়রনমেন্ট বা পরিবেশের সাথে সজ্জিত করা

আমরা বর্তমানে নির্দিষ্ট টাস্কে দক্ষ মডেল ব্যবহার থেকে জটিল ওয়ার্কফ্লো হ্যান্ডেল করতে সক্ষম এজেন্ট ব্যবহারের দিকে শিফট করছি. মডেলগুলিকে প্রম্পট করার মাধ্যমে, আপনি কেবল প্রশিক্ষিত বুদ্ধিমত্তায় অ্যাক্সেস করতে পারেন. তবে, মডেলকে একটি কম্পিউটার এনভায়রনমেন্ট বা পরিবেশ প্রদান করলে আরও অনেক বিস্তৃত পরিসরের ব্যবহারক্ষেত্র অর্জন করা যায়, যেমন সার্ভিস চালানো, API থেকে ডেটা অনুরোধ করা অথবা স্প্রেডশিট বা রিপোর্টের মতো আরও উপযোগী আর্টিফ্যাক্ট তৈরি করা.

এজেন্ট তৈরি করার চেষ্টা করলে কয়েকটি বাস্তব সমস্যা সামনে আসে: মধ্যবর্তী ফাইলগুলো কোথায় রাখা হবে, বড় টেবিলগুলো কিভাবে প্রম্পটে পেস্ট করা এড়ানো যায়, নিরাপত্তাজনিত ঝামেলা তৈরি না করে ওয়ার্কফ্লোকে কিভাবে নেটওয়ার্ক অ্যাক্সেস দেওয়া যায় এবং নিজে একটি ওয়ার্কফ্লো সিস্টেম তৈরি না করেই টাইমআউট ও রিট্রাই কিভাবে সামলানো যায়.

ডেভেলপারদের নিজেদের এক্সিকিউশন এনভায়রনমেন্ট তৈরি করার দায়িত্ব দেওয়ার পরিবর্তে, আমরা বাস্তব জগতের কাজগুলো নির্ভরযোগ্যভাবে সম্পাদন করতে একটি কম্পিউটার এনভায়রনমেন্টসহ Responses API⁠(একটি নতুন উইন্ডোতে খোলে) সজ্জিত করার জন্য প্রয়োজনীয় উপাদান তৈরি করেছি.

OpenAI-এর 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 পৃথক কন্টেইনার সেশন ব্যবহার করে সেগুলো একযোগে কার্যকর করতে পারে. প্রতিটি সেশন স্বাধীনভাবে আউটপুট স্ট্রিম করে, এবং API সেই স্ট্রিমগুলোকে কনটেক্সট হিসেবে স্ট্রাকচার্ড টুল আউটপুটসে মাল্টিপ্লেক্স করে ফিরিয়ে দেয়. অন্য কথায়, এজেন্ট লুপ কাজকে সমান্তরাল করতে পারে, যেমন ফাইল অনুসন্ধান করা, ডেটা আনা এবং মধ্যবর্তী ফলাফল যাচাই করা.

যখন কমান্ডে ফাইল অপারেশন বা ডেটা প্রক্রিয়াকরণ জড়িত থাকে, তখন শেল আউটপুট খুব বড় হয়ে যেতে পারে এবং উপযোগী কোনো সংকেত যোগ না করেই কনটেক্সট বাজেট খরচ করতে পারে. এটি নিয়ন্ত্রণ করতে, মডেল প্রতিটি কমান্ডের জন্য একটি আউটপুট সীমা নির্ধারণ করে. Responses API সেই ক্যাপটি প্রয়োগ করে এবং একটি সীমাবদ্ধ ফলাফল ফেরত দেয়, যা আউটপুটের শুরু এবং শেষ—দুটিই সংরক্ষণ করে, পাশাপাশি বাদ দেওয়া কনটেন্ট চিহ্নিত করে. উদাহরণস্বরূপ, আপনি আউটপুটকে 1,000 অক্ষরের মধ্যে সীমাবদ্ধ করতে পারেন, শুরু এবং শেষ অংশ সংরক্ষিত রেখে:

শুরুর অংশের টেক্সট ... 1000 অক্ষর সংক্ষিপ্ত করা হয়েছে ... শেষের অংশের টেক্সট

একত্রে, কনকারেন্ট এক্সিকিউশন এবং সীমাবদ্ধ আউটপুট এজেন্টের লুপকে দ্রুত ও কনটেক্সট-সাশ্রয়ী করে তোলে; ফলে মডেলটি র টার্মিনাল লগের ভারে জর্জরিত না হয়ে বরং প্রাসঙ্গিক ফলাফলগুলো নিয়ে নিজের যৌক্তিক বিশ্লেষণ বা রিজনিং চালিয়ে যেতে পারে.

এজেন্ট লুপের একটি সম্ভাব্য সমস্যা হলো কাজগুলো দীর্ঘ সময় ধরে চলতে পারে. দীর্ঘ-চলমান কাজগুলো কনটেক্সট উইন্ডো পূরণ করে, যা টার্ন জুড়ে এবং এজেন্টদের মধ্যে প্রেক্ষাপট প্রদান করার জন্য গুরুত্বপূর্ণ. ভাবুন, একটি এজেন্ট একটি স্কিল কল করছে, একটি রেসপন্স পাচ্ছে, টুল কল ও রিজনিং সামারি যোগ করছে—সীমিত কনটেক্সট উইন্ডো দ্রুতই ভরে যায়. এজেন্ট চলতে থাকলে গুরুত্বপূর্ণ কনটেক্সট হারানো এড়াতে, আমাদের এমন একটি উপায় দরকার যাতে মূল বিবরণগুলো রাখা যায় এবং অপ্রয়োজনীয় সবকিছু সরিয়ে ফেলা যায়. ডেভেলপারদের কাস্টম সামারাইজেশন বা স্টেট-ক্যারিং সিস্টেম ডিজাইন ও মেইনটেইন করতে বাধ্য করার পরিবর্তে, আমরা Responses API-তে নেটিভ কমপ্যাকশন যোগ করেছি, যা মডেল কিভাবে আচরণ করে এবং কিভাবে এটি প্রশিক্ষিত হয়েছে তার সাথে সামঞ্জস্যপূর্ণভাবে ডিজাইন করা হয়েছে.

আমাদের সর্বশেষ মডেলগুলোকে পূর্ববর্তী কথোপকথনের স্টেট বিশ্লেষণ করতে এবং একটি কমপ্যাকশন আইটেম তৈরি করতে প্রশিক্ষণ দেওয়া হয়েছে, যা এনক্রিপ্টেড টোকেন-দক্ষ রিপ্রেজেন্টেশনে পূর্ববর্তী গুরুত্বপূর্ণ স্টেট সংরক্ষণ করে. কম্প্যাকশনের পরে, পরবর্তী কনটেক্সট উইন্ডোটি এই কম্প্যাকশন আইটেম এবং আগের উইন্ডোর উচ্চ-মূল্যের অংশগুলি নিয়ে গঠিত. এটি উইন্ডো বা সেশনের সীমানা অতিক্রম করেও কাজের ধারা বা ওয়ার্কফ্লো নিরবচ্ছিন্ন ও সংগতিপূর্ণ রাখতে সাহায্য করে, এমনকি দীর্ঘায়িত মাল্টি-স্টেপ এবং টুল-চালিত সেশনগুলোর ক্ষেত্রেও. Codex দীর্ঘস্থায়ী কোডিং কাজ এবং টুলের বারবার ব্যবহার চালিয়ে যাওয়ার জন্য এই পদ্ধতির উপর নির্ভর করে, যাতে কাজের গুণগত মান বজায় থাকে.

কম্প্যাকশন সার্ভারে বিল্ট-ইন হিসেবে অথবা একটি স্বতন্ত্র `/compact` এন্ডপয়েন্টের মাধ্যমে উপলব্ধ. সার্ভার-সাইড কম্প্যাকশন আপনাকে একটি থ্রেশহোল্ড কনফিগার করতে দেয় এবং সিস্টেম স্বয়ংক্রিয়ভাবে কম্প্যাকশনের সময় নির্ধারণ পরিচালনা করে, জটিল ক্লায়েন্ট-সাইড লজিকের প্রয়োজনীয়তা দূর করে. এটি কম্প্যাকশনের ঠিক আগে ছোটখাটো অতিরিক্ততা সহ্য করার জন্য সামান্য বড় কার্যকর কনটেক্সট উইন্ডো ইনপুট কনটেক্সট উইন্ডো অনুমোদন করে, ফলে সীমার কাছাকাছি থাকা অনুরোধগুলো প্রত্যাখ্যাত না হয়ে এখনও প্রক্রিয়াকরণ ও কম্প্যাক্ট করা যায়. মডেল প্রশিক্ষণ যত বিকশিত হয়, প্রতিটি OpenAI মডেল রিলিজের সাথে সাথে নেটিভ কমপ্যাকশন সমাধানও ততই বিকশিত হয়.

Codex আমাদের কম্প্যাকশন সিস্টেম তৈরি করতে সাহায্য করেছে, পাশাপাশি এর একজন প্রাথমিক ব্যবহারকারী হিসেবেও কাজ করেছে. যখন একটি Codex ইনস্ট্যান্সে কমপ্যাকশন ত্রুটি হতো, আমরা তদন্ত করার জন্য দ্বিতীয় একটি ইনস্ট্যান্স চালু করতাম. ফলাফল ছিল যে Codex সমস্যাটিতে কাজ করেই একটি নেটিভ, কার্যকর কমপ্যাকশন সিস্টেম পেয়েছিল. Codex-এর নিজের ভেতরটা পরিদর্শন ও নিজেকে পরিমার্জন করার এই ক্ষমতা OpenAI-এ কাজ করার ক্ষেত্রে বিশেষভাবে আকর্ষণীয় একটি অংশ হয়ে উঠেছে. বেশিরভাগ টুলে ব্যবহারকারীকে শুধু সেগুলো কিভাবে ব্যবহার করতে হয় তা শিখলেই চলে; Codex আমাদের সঙ্গে সঙ্গে শেখে.

এখন, চলুন স্টেট এবং উৎসসমূহ নিয়ে আলোচনা করি. কন্টেইনারটি শুধুমাত্র কমান্ড চালানোর একটি স্থানই নয়, বরং এটি মডেলটির কাজ করার জন্য একটি গুরুত্বপূর্ণ প্রেক্ষাপট বা 'ওয়ার্কিং কনটেক্সট' হিসেবেও কাজ করে. কন্টেইনারের ভিতরে, মডেল ফাইল পড়তে পারে, ডেটাবেসে কোয়েরি করতে পারে এবং নেটওয়ার্ক নীতিমালা নিয়ন্ত্রণের অধীনে বাহ্যিক সিস্টেমে অ্যাক্সেস করতে পারে.

কনটেইনার কনটেক্সটের প্রথম অংশ হলো রিসোর্স আপলোড, সংগঠিত এবং পরিচালনার জন্য ফাইল সিস্টেম. আমরা কন্টেইনার এবং ফাইল⁠(একটি নতুন উইন্ডোতে খোলে) API তৈরি করেছি, যাতে মডেল উপলব্ধ ডেটার একটি মানচিত্র পায় এবং বিস্তৃত, অপ্রয়োজনীয় স্ক্যান চালানোর বদলে লক্ষ্যভিত্তিক ফাইল অপারেশন বেছে নিতে পারে.

একটি সাধারণ অ্যান্টি-প্যাটার্ন হলো সব ইনপুট সরাসরি প্রম্পট কনটেক্সটে ঢুকিয়ে দেওয়া. ইনপুট বড় হলে, প্রম্পট অতিরিক্তভাবে ভরে ফেলা ব্যয়বহুল হয়ে ওঠে এবং মডেলের জন্য নেভিগেট করা কঠিন হয়. একটি আরও ভালো প্যাটার্ন হলো কন্টেইনার ফাইল সিস্টেমে রিসোর্সগুলো স্টেজ করা এবং শেল কমান্ডের মাধ্যমে কী খুলবে, পার্স করবে বা ট্রান্সফর্ম করবে তা মডেলকে সিদ্ধান্ত নিতে দেওয়া. মানুষের মতোই, মডেলগুলো সংগঠিত তথ্যের সাথে আরও ভালোভাবে কাজ করে.

কন্টেইনার কনটেক্সটের দ্বিতীয় অংশ হলো ডেটাবেস. অনেক ক্ষেত্রে, আমরা ডেভেলপারদের জন্য পরামর্শ দিই যে তারা SQLite-এর মতো ডেটাবেসে স্ট্রাকচার্ড ডেটা বা সুসংগঠিত তথ্য সংরক্ষণ করুক এবং সেখান থেকে সেগুলো কুয়েরি (Query) করুক. উদাহরণস্বরূপ, পুরো একটি স্প্রেডশিট প্রম্পটে কপি করার বদলে, আপনি মডেলকে টেবিলগুলোর একটি বর্ণনা দিতে পারেন—কোন কোন কলাম আছে এবং সেগুলোর মানে কী—এবং তারপর সেটিকে প্রয়োজনীয় সারিগুলো টেনে নিতে দিতে পারেন.

উদাহরণস্বরূপ, আপনি যদি জিজ্ঞাসা করেন, "এই প্রান্তিকে (quarter) কোন পণ্যগুলোর বিক্রি কমেছে?" তবে মডেলটি পুরো স্প্রেডশিটটি স্ক্যান করার পরিবর্তে কেবল প্রাসঙ্গিক সারিগুলো (rows) কুয়েরি (query) করতে পারে. এটি আরও দ্রুত, আরও সাশ্রয়ী, বড় ডেটাসেটের জন্য আরও স্কেলেবল.

কন্টেইনার কনটেক্সটের তৃতীয় অংশ হলো নেটওয়ার্ক অ্যাক্সেস, যা এজেন্ট ওয়ার্কলোডের একটি অপরিহার্য অংশ. এজেন্টের ওয়ার্কফ্লোতে লাইভ ডেটা ফেচ করা, বাহ্যিক API কল করা বা প্যাকেজ ইনস্টল করার প্রয়োজন হতে পারে. একই সময়ে, কনটেইনারগুলোকে সীমাহীন ইন্টারনেট অ্যাক্সেস দেওয়া ঝুঁকিপূর্ণ হতে পারে: এতে বাহ্যিক ওয়েবসাইটে তথ্য উন্মুক্ত হয়ে যেতে পারে, অনিচ্ছাকৃতভাবে সংবেদনশীল অভ্যন্তরীণ বা থার্ড-পার্টি সিস্টেমে সংযোগ স্থাপন হতে পারে, অথবা ক্রেডেনশিয়াল লিক এবং ডেটা এক্সফিল্ট্রেশন থেকে সুরক্ষা দেওয়া আরও কঠিন হয়ে যেতে পারে.

এজেন্টদের উপযোগিতা সীমিত না করে এই উদ্বেগগুলো সমাধান করতে, আমরা সাইডকার ইগ্রেস প্রক্সি ব্যবহার করার জন্য হোস্টেড কনটেইনার তৈরি করেছি. সমস্ত আউটবাউন্ড নেটওয়ার্ক রিকোয়েস্ট একটি কেন্দ্রীভূত পলিসি লেয়ারের মাধ্যমে প্রবাহিত হয়, যা অ্যালাউলিস্ট এবং অ্যাক্সেস কন্ট্রোল প্রয়োগ করে, পাশাপাশি ট্র্যাফিককে পর্যবেক্ষণযোগ্য রাখে. ক্রেডেনশিয়ালের জন্য, আমরা ইগ্রেসে ডোমেইন-স্কোপড সিক্রেট ইনজেকশন ব্যবহার করি. মডেল এবং কন্টেইনার কেবল প্লেসহোল্ডারগুলো দেখতে পায়, যেখানে আসল সিক্রেট ভ্যালু বা গোপন তথ্যগুলো মডেলের দৃশ্যমান প্রেক্ষাপটের বাইরে থাকে এবং সেগুলো কেবল অনুমোদিত গন্তব্যস্থলেই প্রয়োগ করা হয়. এটি লিকেজের ঝুঁকি কমায়, একই সঙ্গে প্রমাণীকৃত বাহ্যিক কলগুলো সক্ষম রাখে.

শেল কমান্ড শক্তিশালী, কিন্তু অনেক কাজ একই বহু-ধাপের প্যাটার্ন বারবার পুনরাবৃত্তি করে. এজেন্টদের প্রতিবার চালানোর সময় ওয়ার্কফ্লো নতুন করে আবিষ্কার করতে হয়—পুনরায় পরিকল্পনা করা, কমান্ড পুনরায় জারি করা এবং কনভেনশনগুলো আবার শেখা—ফলে অসামঞ্জস্যপূর্ণ ফলাফল এবং অপচয় হওয়া এক্সিকিউশন ঘটে. এজেন্টের দক্ষতা⁠(একটি নতুন উইন্ডোতে খোলে) সেই প্যাটার্নগুলোকে পুনঃব্যবহারযোগ্য, সংযোজ্য নির্মাণ ব্লকে প্যাকেজ করে. স্পষ্টভাবে বলতে গেলে, একটি স্কিল হলো একটি ফোল্ডার বান্ডল, যাতে ‘SKILL.md⁠(একটি নতুন উইন্ডোতে খোলে)’ অন্তর্ভুক্ত থাকে (মেটাডেটা এবং নির্দেশাবলীসহ) এবং যেকোনো সহায়ক রিসোর্স, যেমন API স্পেসিফিকেশন এবং UI অ্যাসেট.

এই কাঠামোটি আমরা আগে যে রানটাইম আর্কিটেকচার বর্ণনা করেছি, তার সঙ্গে স্বাভাবিকভাবেই মিলে যায়. কন্টেইনার স্থায়ী ফাইল এবং এক্সিকিউশন কনটেক্সট প্রদান করে এবং শেল টুল এক্সিকিউশন ইন্টারফেস প্রদান করে. দুটোই স্থাপিত থাকলে, মডেল প্রয়োজন হলে শেল কমান্ড (`ls`, `cat`, ইত্যাদি) ব্যবহার করে স্কিল ফাইলগুলো খুঁজে পেতে পারে, নির্দেশনা ব্যাখ্যা করতে পারে এবং একই এজেন্ট লুপের মধ্যে স্কিল স্ক্রিপ্টগুলো চালাতে পারে.

OpenAI প্ল্যাটফর্মে দক্ষতা পরিচালনা করতে আমরা APIs⁠(একটি নতুন উইন্ডোতে খোলে) প্রদান করি. ডেভেলপাররা স্কিল ফোল্ডারগুলোকে ভার্সনযুক্ত বান্ডল হিসেবে আপলোড ও সংরক্ষণ করেন, যা পরে স্কিল ID দিয়ে পুনরুদ্ধার করা যেতে পারে. মডেলে প্রম্পট পাঠানোর আগে, Responses API স্কিল লোড করে এবং সেটিকে মডেল কনটেক্সটে অন্তর্ভুক্ত করে. এই সিকোয়েন্সটি ডিটারমিনিস্টিক:

1. স্কিল মেটাডেটা সংগ্রহ করুন, যার মধ্যে নাম এবং বর্ণনা অন্তর্ভুক্ত থাকবে.
2. স্কিল বান্ডেলটি সংগ্রহ করুন, সেটিকে কন্টেইনারের ভেতরে কপি করুন এবং আনপ্যাক করুন.
3. স্কিল মেটাডেটা এবং কনটেইনার পাথ দিয়ে মডেল কনটেক্সট আপডেট করুন.

কোনো স্কিল প্রাসঙ্গিক কিনা সিদ্ধান্ত নেওয়ার সময়, মডেল ধাপে ধাপে তার নির্দেশাবলী অন্বেষণ করে এবং কন্টেইনারে শেল কমান্ডের মাধ্যমে তার স্ক্রিপ্টগুলো কার্যকর করে.

সবগুলো অংশকে একত্রে সাজালে বিষয়টি দাঁড়ায়: Responses API অর্কেস্ট্রেশন বা সমন্বয় প্রদান করে, শেল টুল সম্পাদনযোগ্য কাজের সুবিধা দেয়, হোস্টেড কন্টেইনার দীর্ঘস্থায়ী রানটাইম কনটেক্সট নিশ্চিত করে, স্কিলস পুনঃব্যবহারযোগ্য ওয়ার্কফ্লো লজিক স্তর হিসেবে কাজ করে এবং কম্প্যাকশন একজন এজেন্টকে প্রয়োজনীয় কনটেক্সটসহ দীর্ঘ সময় ধরে কাজ চালানোর সুযোগ দেয়.

এই প্রিমিটিভগুলোর মাধ্যমে, একটি একক প্রম্পট একটি এন্ড-টু-এন্ড ওয়ার্কফ্লোতে বিস্তৃত হতে পারে: সঠিক স্কিল খুঁজে বের করা, ডেটা আনা, সেটিকে লোকাল স্ট্রাকচার্ড স্টেটে রূপান্তর করা, দক্ষভাবে কুয়েরি করা এবং টেকসই আর্টিফ্যাক্ট তৈরি করা. 

নিচের ডায়াগ্রামটি দেখায় কিভাবে এই সিস্টেমটি লাইভ ডেটা থেকে একটি স্প্রেডশিট তৈরি করতে কাজ করে.

শেল টুল এবং কম্পিউটার এনভায়রনমেন্টকে এন্ড-টু-এন্ড ওয়ার্কফ্লোর জন্য একত্রিত করার একটি বিস্তারিত উদাহরণ দেখতে, Responses API-এর মাধ্যমে একটি স্কিল প্যাকেজ করা এবং তা এক্সিকিউট করার প্রক্রিয়া দেখানো আমাদের ডেভেলপার ব্লগ পোস্ট⁠(একটি নতুন উইন্ডোতে খোলে) এবং কুকবুক⁠(একটি নতুন উইন্ডোতে খোলে) দেখুন.

এই প্রিমিটিভগুলোর সেট দিয়ে ডেভেলপাররা কী তৈরি করে তা দেখতে আমরা উচ্ছ্বসিত. ভাষা মডেলগুলো কেবল টেক্সট, ছবি এবং অডিও তৈরি করার চেয়েও বেশি কিছু করার জন্য তৈরি—জটিল, বাস্তব-জগতের কাজগুলো বৃহৎ পরিসরে সামলাতে আরও সক্ষম হয়ে উঠতে আমরা আমাদের প্ল্যাটফর্মকে বিকশিত করতে থাকব.