از مدل تا عامل: مجهز کردن Responses API به محیط کامپیوتری

ما در حال حاضر در حال گذار از استفاده از مدل‌ها، که در انجام وظایف خاص عالی هستند، به استفاده از عامل‌هایی هستیم که قادر به مدیریت جریان‌های کاری پیچیده‌اند. با پرامپت دادن به مدل‌ها، فقط می‌توانید به هوش آموزش‌دیده دسترسی داشته باشید. با این حال، فراهم کردن یک محیط رایانه‌ای برای مدل می‌تواند دامنه بسیار گسترده‌تری از موارد استفاده را ممکن کند، مانند اجرای سرویس‌ها، درخواست داده از APIs، یا تولید مصنوعات مفیدتری مانند صفحه‌گسترده‌ها یا گزارش‌ها.

وقتی تلاش می‌کنید عامل بسازید، چند مشکل عملی به وجود می‌آید: این‌که فایل‌های میانی را کجا قرار دهید، چگونه از قرار دادن جدول‌های بزرگ در داخل پرامپت جلوگیری کنید، چگونه بدون ایجاد مشکلات امنیتی به گردش‌کار دسترسی شبکه بدهید، و چگونه بدون اینکه خودتان یک سیستم گردش‌کار بسازید، وقفه زمانی و تلاش‌های مجدد را مدیریت کنید.

به‌جای اینکه ساخت محیط‌های اجرای خودشان را به عهده توسعه‌دهندگان بگذاریم، ما مؤلفه‌های لازم را ساختیم تا Responses API⁠(در یک پنجره جدید باز می‌شود) را به یک محیط کامپیوتری مجهز کنیم که بتواند وظایف دنیای واقعی را به‌طور قابل‌اعتماد اجرا کند.

Responses API متعلق به OpenAI، به همراه ابزار شل و یک فضای کاری کانتینری میزبانی‌شده، برای رفع این مشکلات عملی طراحی شده است. مدل گام‌ها و دستورها را پیشنهاد می‌کند؛ پلتفرم آن‌ها را در یک محیط ایزوله با سیستم فایل برای ورودی‌ها و خروجی‌ها، ذخیره‌سازی ساختاریافتهٔ اختیاری (مانند SQLite) و دسترسی محدود به شبکه اجرا می‌کند. 

در این پست، توضیح خواهیم داد که چگونه یک محیط کامپیوتری برای عامل‌ها ساختیم و چند درس اولیه درباره اینکه چگونه از آن برای جریان‌های کاری تولید سریع‌تر، تکرارپذیرتر و ایمن‌تر استفاده کنیم، به اشتراک می‌گذاریم.

یک گردش کار خوبِ عامل با یک چرخه اجرای فشرده شروع می‌شود: مدل یک اقدام مثل خواندن فایل‌ها یا واکشی داده با API را پیشنهاد می‌کند، پلتفرم آن را اجرا می‌کند و نتیجه به گام بعدی وارد می‌شود. با ابزار شِل شروع می‌کنیم—ساده‌ترین راه برای دیدن این حلقه در عمل—و سپس فضای کاری کانتینر، شبکه‌سازی، مهارت‌های قابل استفاده مجدد و فشرده‌سازی زمینه را پوشش می‌دهیم.

برای درک ابزار شِل، ابتدا مفید است درک کنیم که یک مدل زبانی به‌طور کلی چگونه از ابزارها استفاده می‌کند: برای انجام کارهایی مثل فراخوانی یک تابع یا تعامل با یک رایانه. در طول آموزش، به یک مدل نمونه‌هایی از نحوه استفاده از ابزارها و اثرات حاصل از آن‌ها، گام‌به‌گام نشان داده می‌شود. این به مدل کمک می‌کند یاد بگیرد تصمیم بگیرد چه زمانی از یک ابزار استفاده کند و چگونه از آن استفاده کند. وقتی می‌گوییم «استفاده از ابزار»، منظورمان این است که مدل در واقع فقط یک فراخوانی ابزار را پیشنهاد می‌کند. نمی‌تواند به‌تنهایی آن فراخوانی را اجرا کند.

ابزار شل مدل را به‌طور چشمگیری قدرتمندتر می‌کند: این ابزار از طریق خط فرمان با یک رایانه تعامل می‌کند تا طیف گسترده‌ای از وظایف را انجام دهد، از جست‌وجوی متن گرفته تا ارسال درخواست‌های API از طریق رایانهٔ شما. بر پایه ابزارهای آشنای یونیکس ساخته شده است، ابزار شِل ما می‌تواند هر کاری را که انتظار دارید انجام دهد، و ابزارهایی مانند grep، curl و awk از همان ابتدا در دسترس هستند.

در مقایسه با مفسر کد موجود ما که فقط Python را اجرا می‌کند، ابزار شل دامنه بسیار گسترده‌تری از موارد استفاده را امکان‌پذیر می‌کند؛ مانند اجرای برنامه‌های Go یا Java یا راه‌اندازی یک سرور NodeJS. این انعطاف‌پذیری به مدل اجازه می‌دهد وظایف عامل‌محور پیچیده را انجام دهد.

یک مدل به‌تنهایی، فقط می‌تواند دستورات شل را پیشنهاد کند، اما این دستورات چگونه اجرا می‌شوند؟ ما به یک هماهنگ‌کننده نیاز داریم تا خروجی مدل را دریافت کند، ابزارها را فراخوانی کند، و پاسخ ابزار را در یک حلقه به مدل بازگرداند، تا زمانی که کار کامل شود.

Responses API روشی است که توسعه‌دهندگان از طریق آن با مدل‌های OpenAI تعامل می‌کنند. وقتی Responses API با ابزارهای سفارشی استفاده می‌شود، کنترل را دوباره به کلاینت برمی‌گرداند و در این حالت، کلاینت برای اجرای ابزارها به یک سازوکار اجرایی اختصاصی نیاز دارد. با این حال، این API همچنین می‌تواند به‌صورت آماده، بین مدل و ابزارهای میزبانی‌شده هماهنگی ایجاد کند. 

وقتی Responses API یک اعلان دریافت می‌کند، زمینه مدل را گردآوری می‌کند: اعلان کاربر، وضعیت گفتگوی قبلی و دستورالعمل‌های ابزار. برای اینکه اجرای شل کار کند، اعلان باید به استفاده از ابزار شل اشاره کند و مدل انتخاب‌شده باید برای پیشنهاد فرمان‌های شل آموزش دیده باشد—مدل‌های GPT‑5.2 و بعد از آن برای این کار آموزش دیده‌اند. با تمام این زمینه، مدل سپس درباره اقدام بعدی تصمیم می‌گیرد. اگر اجرای پوسته را انتخاب کند، یک یا چند دستور پوسته را به سرویس Responses API برمی‌گرداند. سرویس API آن فرمان‌ها را به زمان اجرای کانتینر ارسال می‌کند، خروجی شل را به‌صورت جریانی برمی‌گرداند، و آن را در زمینه درخواست بعدی به مدل می‌دهد. سپس مدل می‌تواند نتایج را بررسی کند، دستورات پیگیری صادر کند، یا یک پاسخ نهایی تولید کند. Responses API این حلقه را تکرار می‌کند تا زمانی که مدل یک تکمیل را بدون دستورات اضافی shell برگرداند.

هنگامی که Responses API یک فرمان شل را اجرا می‌کند، یک اتصال جریانی به سرویس کانتینر حفظ می‌کند. هم‌زمان با تولید خروجی، API آن را تقریباً در زمان واقعی به مدل منتقل می‌کند تا مدل بتواند تصمیم بگیرد که آیا منتظر خروجی بیشتری بماند، فرمان دیگری اجرا کند، یا به یک پاسخ نهایی ادامه دهد.

مدل می‌تواند در یک مرحله چندین دستور شل را پیشنهاد کند، و Responses API می‌تواند آن‌ها را به‌صورت هم‌زمان با استفاده از نشست‌های جداگانه‌ی کانتینر اجرا کند. هر جلسه خروجی را به‌صورت مستقل به‌صورت جریانی ارسال می‌کند، و API آن استریم‌ها را به‌عنوان زمینه دوباره به خروجی‌های ابزارِ ساختاریافته مالتی‌پلکس می‌کند. به عبارت دیگر، حلقه عامل می‌تواند کارها را به‌صورت موازی انجام دهد، مانند جست‌وجو در فایل‌ها، واکشی داده‌ها و اعتبارسنجی نتایج میانی.

وقتی فرمان شامل عملیات فایل یا پردازش داده باشد، خروجی شل می‌تواند بسیار بزرگ شود و بدون افزودن سیگنال‌های مفید، بودجه‌های زمینه را مصرف کند. برای کنترل این موضوع، مدل برای هر فرمان یک سقف خروجی تعیین می‌کند. Responses API آن سقف را اعمال می‌کند و نتیجه‌ای محدود برمی‌گرداند که هم آغاز و هم پایان خروجی را حفظ می‌کند، در حالی که محتوای حذف‌شده را علامت‌گذاری می‌کند. مثلاً ممکن است خروجی را به ۱۰۰۰ نویسه محدود کنید، با حفظ ابتدای متن و انتهای آن:

متن در ابتدا ... ۱۰۰۰ نویسه کوتاه شده ... متن در انتها

در کنار هم، اجرای هم‌زمان و خروجی محدود باعث می‌شوند حلقه عامل هم سریع باشد و هم از نظر زمینه کارآمد، تا مدل بتواند به‌جای اینکه با لاگ‌های خام ترمینال از پا دربیاید، همچنان بر نتایج مرتبط استدلال کند.

یکی از مشکلات بالقوه در حلقه‌های عامل این است که وظایف می‌توانند برای مدت طولانی اجرا شوند. وظایف طولانی‌مدت پنجره زمینه را پر می‌کنند، که برای فراهم کردن زمینه در سراسر نوبت‌ها و در سراسر عامل‌ها مهم است. تصور کنید یک عامل در حال فراخوانی یک مهارت است، پاسخی دریافت می‌کند، فراخوانی‌های ابزار و خلاصه‌های استدلال را اضافه می‌کند—پنجره زمینه محدود به‌سرعت پر می‌شود. برای جلوگیری از از دست رفتن زمینه مهم در حالی که عامل به اجرا ادامه می‌دهد، به راهی نیاز داریم تا جزئیات کلیدی را نگه داریم و هر چیز اضافی را حذف کنیم. به‌جای اینکه از توسعه‌دهندگان بخواهیم سیستم‌های سفارشیِ خلاصه‌سازی یا حملِ وضعیت را طراحی و نگهداری کنند، فشرده‌سازی بومی را به Responses API اضافه کردیم که طوری طراحی شده است تا با نحوه رفتار مدل و نحوه‌ای که آموزش دیده است، هم‌راستا باشد.

مدل‌های جدید ما برای تحلیل وضعیت مکالمهٔ قبلی آموزش دیده‌اند و یک مورد فشرده‌سازی تولید می‌کنند که وضعیت کلیدی قبلی را در یک نمایش رمزگذاری‌شده و کارآمد از نظر توکن حفظ می‌کند. پس از فشرده‌سازی، پنجره زمینه بعدی از این مورد فشرده‌سازی و بخش‌های باارزشِ پنجره قبلی تشکیل می‌شود. این امکان می‌دهد جریان‌های کاری به‌صورت منسجم در سراسر مرزهای پنجره ادامه پیدا کنند، حتی در نشست‌های طولانیِ چندمرحله‌ای و مبتنی بر ابزار. Codex برای پشتیبانی از وظایف کدنویسی طولانی‌مدت و اجرای تکرارشونده ابزارها بدون افت کیفیت، به این سازوکار متکی است.

قابلیت فشرده‌سازی یا به‌صورت داخلی در سرور در دسترس است، یا از طریق یک نقطهٔ پایانی مستقل با مسیر /compact قابل استفاده است. فشرده‌سازی سمتِ سرور به شما امکان می‌دهد یک آستانه را پیکربندی کنید و سیستم زمان‌بندی فشرده‌سازی را به‌طور خودکار مدیریت می‌کند و نیاز به منطق پیچیده سمتِ کلاینت را از بین می‌برد. این امکان را می‌دهد که پنجره زمینه ورودیِ مؤثر کمی بزرگ‌تر باشد تا درست پیش از فشرده‌سازی، از اضافه‌آمدن‌های کوچک چشم‌پوشی شود؛ بنابراین درخواست‌های نزدیک به حد می‌توانند همچنان پردازش و فشرده شوند، نه اینکه رد شوند. با تکامل آموزش مدل، راهکار فشرده‌سازی بومی نیز همراه با آن برای هر انتشار مدل OpenAI تکامل می‌یابد.

Codex به ما کمک کرد سیستم فشرده‌سازی را بسازیم و در عین حال به‌عنوان یکی از کاربران اولیهٔ آن عمل می‌کرد. وقتی یک نمونه Codex با خطای فشرده‌سازی مواجه می‌شد، یک نمونه دوم را بالا می‌آوردیم تا بررسی کنیم. نتیجه این بود که Codex فقط با کار کردن روی مسئله، یک سیستم فشرده‌سازی بومی و مؤثر به دست آورد. این توانایی Codex برای بررسی و اصلاح خودش به بخش به‌ویژه جالبی از کار کردن در OpenAI تبدیل شده است. بیشتر ابزارها فقط از کاربر می‌خواهند یاد بگیرد چگونه از آنها استفاده کند؛ Codex در کنار ما یاد می‌گیرد.

اکنون، بیایید حالت و منابع را پوشش دهیم. کانتینر نه‌تنها مکانی برای اجرای فرمان‌ها است، بلکه زمینه‌ی کاریِ مدل نیز هست. در داخل کانتینر، مدل می‌تواند فایل‌ها را بخواند، پایگاه‌های داده را پرس‌وجو کند و تحت کنترل‌های خط‌مشی شبکه به سیستم‌های خارجی دسترسی داشته باشد.

بخش اول زمینه کانتینر، سیستم فایل برای بارگذاری، سازمان‌دهی و مدیریت منابع است. ما APIs کانتینر و فایل⁠(در یک پنجره جدید باز می‌شود) را ساختیم تا یک نقشه از داده‌های در دسترس را به مدل بدهند و کمک کنند به‌جای انجام اسکن‌های گسترده و پرنویز، عملیات فایل هدفمند را انتخاب کند.

یک الگوی ضد رایج این است که همهٔ ورودی را مستقیماً در زمینهٔ اعلان بسته‌بندی کنید. با بزرگ‌تر شدن ورودی‌ها، پر کردن بیش از حد اعلان پرهزینه می‌شود و پیمایش آن برای مدل دشوار است. یک الگوی بهتر این است که منابع را در سیستم فایل کانتینر مرحله‌بندی کنید و اجازه دهید مدل تصمیم بگیرد با دستورات شل چه چیزی را باز کند، تجزیه کند یا تبدیل کند. درست مانند انسان‌ها، مدل‌ها با اطلاعات سازمان‌یافته بهتر کار می‌کنند.

بخش دومِ زمینه کانتینر، پایگاه‌های داده هستند. در بسیاری از موارد، پیشنهاد می‌کنیم توسعه‌دهندگان داده‌های ساخت‌یافته را در پایگاه‌های داده‌ای مانند SQLite ذخیره کنند و آن‌ها را کوئری کنند. به‌جای کپی کردن یک صفحه‌گسترده کامل در اعلان، برای مثال، می‌توانید به مدل یک توصیف از جدول‌ها بدهید—اینکه چه ستون‌هایی وجود دارند و چه معنایی دارند—و بگذارید ردیف‌هایی را که نیاز دارد استخراج کند.

برای مثال، اگر بپرسید «کدام محصولات در این فصل فروش کاهشی داشتند؟» مدل می‌تواند فقط ردیف‌های مرتبط را پرس‌وجو کند، به‌جای اینکه کل صفحه‌گسترده را اسکن کند. این سریع‌تر، ارزان‌تر و برای مجموعه‌داده‌های بزرگ‌تر مقیاس‌پذیرتر است.

بخش سوم زمینه کانتینر، دسترسی به شبکه است که بخش ضروری بارهای کاری عامل محسوب می‌شود. گردش‌کار عامل ممکن است نیاز داشته باشد داده‌های زنده دریافت کند، APIs خارجی را فراخوانی کند یا بسته‌ها را نصب کند. در عین حال، دادن دسترسی نامحدود به اینترنت به کانتینرها می‌تواند خطرناک باشد؛ زیرا ممکن است اطلاعات را در معرض وب‌سایت‌های خارجی قرار دهد، به‌طور ناخواسته با سیستم‌های حساس داخلی یا سامانه‌های شخص ثالث تعامل پیدا کند، یا جلوگیری از نشت اعتبارنامه‌ها و خروج غیرمجاز داده‌ها را دشوارتر کند.

برای رفع این نگرانی‌ها بدون محدود کردن کارایی عامل‌ها، ما کانتینرهای میزبانی‌شده را به‌گونه‌ای طراحی کردیم که از یک پروکسی خروجیِ سایدکار استفاده کنند. همه درخواست‌های شبکه خروجی از طریق یک لایه سیاست‌گذاری متمرکز عبور می‌کنند که ضمن اعمال لیست‌های مجاز و کنترل‌های دسترسی، ترافیک را قابل مشاهده نگه می‌دارد. برای اعتبارنامه‌ها، ما از تزریق محرمانهٔ محدود به دامنه در مسیر خروجی استفاده می‌کنیم. مدل و کانتینر فقط جانگهدارها را می‌بینند، در حالی که مقادیر واقعیِ محرمانه خارج از زمینهٔ قابل‌مشاهدهٔ مدل باقی می‌مانند و فقط برای مقصدهای تأییدشده اعمال می‌شوند. این کار خطر نشت اطلاعات را کاهش می‌دهد، در حالی که همچنان امکان برقراری تماس‌های خارجیِ احراز هویت‌شده را فراهم می‌کند.

دستورات شِل قدرتمند هستند، اما بسیاری از کارها همان الگوهای چندمرحله‌ای را تکرار می‌کنند. عامل‌ها مجبورند در هر اجرا جریان کاری را از نو کشف کنند—برنامه‌ریزیِ مجدد، صدورِ دوبارهٔ دستورات، و یادگیریِ دوبارهٔ قراردادها—که به نتایج ناسازگار و اجرای هدررفته منجر می‌شود. مهارت‌های عامل⁠(در یک پنجره جدید باز می‌شود) آن الگوها را در قالب بلوک‌های سازندهٔ قابل استفاده مجدد و قابل ترکیب بسته‌بندی می‌کند. به‌طور مشخص، یک مهارت یک بسته پوشه است که شامل «SKILL.md⁠(در یک پنجره جدید باز می‌شود)» (حاوی فراداده و دستورالعمل‌ها) به‌علاوه هرگونه منابع پشتیبان، مانند مشخصات API و دارایی‌های UI می‌شود.

این ساختار به‌طور طبیعی با معماری زمان اجرای که پیش‌تر توصیف کردیم، هم‌خوانی دارد. کانتینر فایل‌های پایدار و زمینه اجرای مداوم را فراهم می‌کند و ابزار شل رابط اجرای را فراهم می‌کند. با وجود هر دو، مدل می‌تواند در صورت نیاز فایل‌های مهارت را با استفاده از فرمان‌های شل («Is»، «cat» و غیره) کشف کند، دستورالعمل‌ها را تفسیر کند و اسکریپت‌های مهارت را همگی در همان چرخه عامل اجرا کند.

ما APIs⁠(در یک پنجره جدید باز می‌شود) را برای مدیریت مهارت‌ها در پلتفرم OpenAI ارائه می‌کنیم. توسعه‌دهندگان پوشه‌های مهارت را به‌صورت بسته‌های نسخه‌بندی‌شده بارگذاری و ذخیره می‌کنند که بعداً می‌توان آن‌ها را با شناسه مهارت بازیابی کرد. قبل از ارسال اعلان به مدل، Responses API مهارت را بارگذاری می‌کند و آن را در زمینه مدل قرار می‌دهد. این توالی قطعی است:

1. فراداده مهارت را، از جمله نام و توضیحات، دریافت کنید.
2. بسته مهارت را دریافت کنید، آن را درون کانتینر کپی کنید و از حالت فشرده خارج کنید.
3. زمینه مدل را با فراداده مهارت و مسیر کانتینر به‌روز کنید.

هنگام تصمیم‌گیری درباره اینکه آیا یک مهارت مرتبط است یا نه، مدل به‌تدریج دستورالعمل‌های آن را بررسی می‌کند و اسکریپت‌های آن را از طریق دستورات شل در کانتینر اجرا می‌کند.

برای کنار هم گذاشتن همه قطعات: Responses API هماهنگی را انجام می‌دهد، ابزار شل اقدام‌های قابل اجرا را فراهم می‌کند، کانتینر میزبانی‌شده زمینه زمان اجرای پایدار را فراهم می‌کند، مهارت‌ها منطق جریان کاری قابل استفاده مجدد را لایه‌بندی می‌کند و فشرده‌سازی به یک عامل اجازه می‌دهد برای مدت طولانی با زمینه‌ای که نیاز دارد اجرا شود.

با این بدیهیات، یک اعلان می‌تواند به یک گردش‌کار انتها به انتها گسترش یابد: مهارت درست را کشف کند، داده‌ها را واکشی کند، آن را به وضعیت ساختاریافتهٔ محلی تبدیل کند، آن را به‌طور کارآمد کوئری کند و مصنوعات ماندگار تولید کند. 

نمودار زیر نشان می‌دهد این سیستم چگونه برای ایجاد یک صفحه‌گسترده از داده‌های زنده کار می‌کند.

برای مشاهدهٔ یک مثال عمیق از ترکیب ابزار شل و محیط رایانه برای ایجاد گردش‌کارهای کاملِ سرتاسری، به پست وبلاگ توسعه‌دهندگان⁠(در یک پنجره جدید باز می‌شود) و کتاب راهنما⁠(در یک پنجره جدید باز می‌شود) ما مراجعه کنید که نحوهٔ بسته‌بندی یک مهارت و اجرای آن از طریق Responses API را گام‌به‌گام توضیح می‌دهند.

ما هیجان‌زده‌ایم ببینیم توسعه‌دهندگان با این مجموعه از اجزای پایه چه می‌سازند. مدل‌های زبانی قرار است فراتر از تولید متن، تصویر و صدا عمل کنند — ما همچنان پلتفرم خود را توسعه خواهیم داد تا در انجام وظایف پیچیدهٔ دنیای واقعی در مقیاس گسترده توانمندتر شود.