چارچوبهای آزمون سبکتر و عاملهای قادر به اجرای کد برای وظایف باز مناسبترند؛ زیرا هماهنگسازی بیشازحد سختگیرانه میتواند عملکرد مدل را محدود کند.
در پی این تحول، اجرای کد و سندباکسسازی اکنون از ملاحظات اصلی معماری سیستمهای عاملی هستند.
در آزمونهای ما، Agents SDK پیچیدگی و کد لازم برای ساخت عاملهای قادر به اجرای کد را تا ۶ برابر کاهش میدهد.
برای مدتی طولانی، پیشرفت سیستمهای عاملی حاصل بهبود هماهنگسازی بود: اعلانهای بهتر، رابطهای ابزار، مدیریت زمینه و جریان کنترل منسجمتر. اما با توانمندترشدن عاملهای کدنویسی، این توازن در حال تغییر است.
در بسیاری از گردشکارهای باز، گلوگاه دیگر خود حلقه عامل نیست، بلکه لایه اجراست: سندباکسی که مدل در آن کد مینویسد، فرمان اجرا میکند، خروجیها را بررسی میکند و کار را تکرار میکند. با انتقال بخش بیشتری از استدلال مربوط به وظیفه به این محیط، هماهنگسازی پیرامونی باید سادهتر شود تا مدل بتواند تمام توانایی خود را بروز دهد.
این دقیقاً همان تحولی است که نسخه جدید Agents SDK امکانپذیر میکند. آزمونهای ما در دوره دسترسی زودهنگام نشان داد که این SDK، بهجای افزودن لایه دیگری از منطق چارچوب، لایه اجرا را ماژولارتر و ترکیبپذیرتر میکند تا باقی سیستم سبک بماند.
در مهندسی چارچوب آزمون، کاهش چارچوب آزمون به حداقل شکل مؤثر آن به رویکردی رایج تبدیل شده است. در سطح کلان، چارچوب آزمون همان نرمافزار پیرامون مدل است: لایهای که زمینه، ابزارها، جریان کنترل و حلقههای بازخورد را مدیریت میکند تا مدل بتواند کارها را با اطمینان انجام دهد.
در چند سال گذشته، بسیاری از پیشرفتهای عملکرد عاملها از تقویت همین لایه حاصل شد. ابزارهای بهتر، حافظه و بازیابی بهتر، تجزیه صریحتر وظایف و هماهنگسازی منسجمتر، اغلب سیستمها را قابلاعتمادتر و توانمندتر میکردند. در این الگو، پیشرفت عمدتاً به معنای گنجاندن منطق بیشتری از وظیفه در نرمافزار پیرامون مدل بود.
این الگو اکنون، دستکم برای گروهی از وظایف باز، در حال تضعیف است. شمار فزایندهای از پروژهها و مقالهها نشان میدهند که تجویزیترشدن چارچوب آزمون همیشه عملکرد را بهبود نمیدهد. در کدنویسی به کمک هوش مصنوعی، وظایف طولانیمدت، کار با مرورگر، و وظایف با زمینه طولانی، الگویی یکسان بارها دیده میشود: وقتی مدل بهاندازه کافی هوشمند باشد، تحمیل ساختار بیشازحد وظیفه به نرمافزار پیرامونی میتواند بهجای مزیت، به محدودیت تبدیل شود.
بنابراین، نقش چارچوب آزمون در حال تغییر است. چارچوب آزمون، بهجای تلاش برای پیشبینی وظیفه از طریق هماهنگسازی سختگیرانه، بیشازپیش بستری تمیز برای اجرا فراهم میکند: سندباکسی که مدل در آن میتواند وضعیت را بررسی کند، کد اجرا کند، خطاها را رفع کند و رویکرد خود را تطبیق دهد، درحالیکه همچنان به رابطها و سازوکارهای ایمنی سیستم مقید است. این تحول به چیزی نزدیک است که آندری کارپاتی در مهندس نرمافزار ۳.۰ توصیف کرد: بخشی از منطقی که پیشتر در نرمافزار قرار داشت، به سطح بالاتر یعنی «اعلان» منتقل میشود.
درس این تحول آن نیست که سیستمهای عاملی باید همهجا ساختار را حذف کنند. بسیاری از وظایف همچنان از گردشکارهای صریح، روشهای اکتشافی و حفاظهای قطعی سود میبرند؛ بهویژه وقتی وظیفه محدود یا پرتکرار است یا معیار موفقیت روشنی دارد. همانطور که در مطلب پیشین خود درباره روشهای اکتشافی طراحی سیستمهای عاملی استدلال کردیم، وقتی جریان منطقی قابلاعتماد هم ممکن و هم مطلوب باشد، هماهنگسازی قدرتمند همچنان اهمیت دارد.
برای وظایف باز، تمرکز در حال تغییر است. چالش دیگر چندان طراحی لایههای هماهنگسازی پیچیدهتر نیست؛ بلکه ساخت محیطهای اجرایی ساده، مشاهدهپذیر و بهاندازه کافی ماژولار است تا مدل بتواند در آنها بهطور مؤثر کار کند.
وقتی یک عامل بتواند فایلها را بخواند، کد بنویسد، فرمانهای پوسته را اجرا کند و وظایف طولانیمدت راه بیندازد، چالش مهندسی تغییر میکند. بخش دشوار دیگر صرفاً بهینهسازی اعلان یا مسیریابی ابزار نیست. کارکردن عامل روی یک سیستم واقعی، این عاملها را بهمراتب قدرتمندتر میکند؛ اما با گسترش سطح ایمنی و امنیتی، حساسیت آنها را نیز افزایش میدهد. برای نمونه، عاملی که میتواند کد اجرا کند، اگر محیطش بهدرستی ایزوله نشده باشد ممکن است اقدامات زیانباری انجام دهد (به Sandbox Bench از AISI مراجعه کنید).
ازاینرو، سندباکسسازی به یکی از ملاحظات حیاتی در چارچوبهای عامل تبدیل شده است. در سیستمهای قدیمیتر، اجرا اغلب قابلیتی الحاقی تلقی میشد: ابزاری که به چارچوب آزمون متصل شده بود. اما وقتی اجرا وضعیتمند، طولانیمدت یا راهدور میشود، این رویکرد دیگر پاسخگو نیست. مدیریت خود سندباکس، چرخه عمر، وضعیت و رابطهای آن و نیز اتصالش به حلقه عامل، بهسرعت به مسئلهای مستقل در طراحی سیستم تبدیل میشود. این یکی از دلایلی است که اکنون ارائهدهندگان بیشتری، از جمله Container API و ابزار shell شرکت OpenAI، همچنین Modal، Cloudflare، Daytona و E2B، محیطهای مدیریتشده برای اجرای کد ارائه میکنند.
این مرزبندی مهم است، زیرا اجرای کد در مقایسه با سایر بخشهای چارچوب آزمون به ایزولهسازی قویتر و کنترل دقیقتر زمان اجرا نیاز دارد. در عمل، پیادهسازی ضعیف عاملهای قادر به اجرای کد میتواند سه ریسک حیاتی برای کسبوکار ایجاد کند: هزینه پردازشی مهارنشده، اقدامات مخرب روی سیستمهای داخلی و افشای اطلاعات حساس. با کانتینرسازی و ایزولهسازی مناسب و سازوکارهای حفاظتی زمان اجرا، میتوان این ریسکها را تا سطحی مهار کرد که برای استقرارهای واقعی پذیرفتنی باشد.
برای درک بهتر، تصور کنید بهجای کلید تمام دفتر، فضای کاری مهرومومشدهای در اختیار عامل قرار میدهید. عامل همچنان میتواند در آن فضا کار مفید انجام دهد، اما فقط در محدودههایی که بهروشنی تعریف شدهاند. میتوانید میزان مصرف منابع پردازشی آن را سقفگذاری کنید، دسترسیاش به سیستمها و فایلها را محدود سازید و از ابتدا تعیین کنید چه اطلاعاتی در اختیارش باشد.
این کار ریسک را کاملاً از بین نمیبرد، اما مسئله را از «عاملی رهاشده در زیرساخت شما» به «عاملی فعال در محیطی کنترلشده» تبدیل میکند. اگر قرار است این لایه به بخشی استاندارد از سیستمهای عاملی تبدیل شود، باید در خود چارچوب پشتیبانی درجهیک داشته باشد. بهاینترتیب، سندباکس به لایه اجرایی ماژولاری با اجزای پایه انتقالپذیر تبدیل میشود که توسعهدهندگان میتوانند آنها را سریع بهکار بگیرند، بین ارائهدهندگان جابهجا کنند و بدون بازنویسی مداوم منطق عامل مقیاس دهند.
وقتی یک عامل کد اجرا میکند، خود سندباکس نیز به هماهنگسازی نیاز دارد. گذار از نمونه اثبات مفهوم محلی به اجرای راهدور، چندین زیرساخت پشتیبان یا نشستهای طولانیمدت، بار عملیاتی را بهشدت افزایش میدهد. به روشی یکپارچه نیاز دارید تا محیطها را ایجاد و متوقف کنید، آنها را موقتاً متوقف و از سر بگیرید، از وضعیت تصویر لحظهای بسازید، بعداً دوباره متصل شوید و همه این موارد را در میان ارائهدهندگان مدیریت کنید.
هیچیک از این کارها از نظر مفهومی جذاب نیست، اما در عمل اهمیت دارد. این دقیقاً همان نوع زیرساختی است که وقتی هر تیم خط لوله عاملی را از ابتدا میسازد، دردسرساز میشود؛ بهویژه اگر با چارچوب عامل یکپارچه نشده باشد…
اینجاست که پشتیبانی بهتر چارچوب اهمیت پیدا میکند. ما به نسخه جدیدتر Agents SDK شرکت OpenAI دسترسی زودهنگام داشتیم و با استفاده از آن عاملهای سندباکسشده ساختیم. آنچه بیش از همه جلب توجه میکرد، تغییر تأکید معماری بود: SDK اجرا را نه ابزاری جانبی، بلکه لایهای درجهیک در نظر میگیرد. در عمل، این یعنی میتوانید با کد کمتری یک عامل سندباکسشده راهاندازی کنید، از سندباکس تصویر لحظهای بگیرید یا اجرا را از سر بگیرید—در برخی آزمونهای ما با حدود ۶ برابر کد کمتر—و سپس بدون بازنویسی منطق پیرامونی عامل، زیرساخت پشتیبان را تغییر دهید.
این تفکیک روشنتر مسئولیتها اجازه میدهد چارچوب آزمون بر استدلال، زمینه و گردشکار متمرکز بماند. لایه اجرا نیز میتواند بر ایزولهسازی، انتقالپذیری و وضعیت زمان اجرا تمرکز کند. این انتزاع، ساخت عاملهای کدنویسی توانمندتر و تکاملپذیرتر را آسان میکند؛ عاملهایی که میتوانند بین اجرای محلی و راهدور جابهجا شوند، از وظایف طولانیتر پشتیبانی کنند و بدون نیاز به بازطراحی کل سیستم، زیرساخت اجرایی خود را تغییر دهند.
با انتقال بخش بیشتری از منطق وظیفه از چارچوب آزمون به مدل، بخشی از پیچیدگی سیستم نیز همراه آن به لایه اجرا منتقل میشود. اجرای کد و سندباکسسازی اکنون از ملاحظات اصلی معماری سیستمهای عاملی هستند؛ بهویژه برای وظایف باز و وظایفی که بخش عمده آنها کدنویسی است. طراحی محیطی که عامل بتواند در آن با ایمنی، اطمینان و در طول زمان فعالیت کند، اکنون بهاندازه طراحی خط لوله عاملی اهمیت دارد.
به همین دلیل، انتزاعهای سطح بالاتر برای اجرای سندباکسشده اهمیت دارند. نسخه جدیدتر Agents SDK شرکت OpenAI با درنظرگرفتن اجرا بهعنوان لایهای ماژولار از سیستم، در همین مسیر حرکت میکند: لایهای انتقالپذیر میان زیرساختهای پشتیبان، وضعیتمند در وظایف طولانیمدت و آنقدر ساده که برای هر پیکربندی جدید نیازی به بازسازی همان زیرساخت نباشد.
درس کلیتر این است که نسل بعدی چارچوبهای عامل احتمالاً نه با میزان منطق هماهنگسازی افزودهشده، بلکه با کیفیت ساختاربندی محیطهای اجرایی تعریف میشود که عاملها روزبهروز بیشتر به آنها وابستهاند.