به‌روزرسانی Agents SDK بیشتر درباره مالکیت اجراست تا خود دستور shell

بخش جالب به‌روزرسانی Agents SDK که OpenAI در میانه آوریل ۲۰۲۶ معرفی کرد این نیست که ایجنت می‌تواند دستور shell بزند. خیلی از سیستم‌ها از قبل می‌توانستند یک ترمینال به مدل پیچ کنند. جابه‌جایی مفید این است که اجرا دور مدل دارد چیز درجه اول می‌شود: فایل، ابزار، چیدمان فضای کار، ارائه‌دهنده سندباکس، حافظه، دستورالعمل، skill، وصله، و بازیابی وضعیت، به‌جای تلی از چسب سفارشی.

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

اجرا بخشی از محصول است

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

نسخه به‌روزشده روی همین تکیه می‌کند. OpenAI از هارنس نزدیک به مدل حرف می‌زند با ارکستراسیون آگاه از سندباکس، ابزار فایل‌سیستم، اجرای shell، ویرایش به سبک apply-patch، MCP، skill، دستورالعمل به سبک AGENTS.md، و حافظه قابل تنظیم. کلمه کلیدی هارنس است. هارنس به قدری صاحب‌نظر است که مدل راه قابل پیش‌بینی برای کار داشته باشد، و هنوز اپ کنترل می‌کند کدام ابزار، فایل، و سندباکس در دسترس است.

پشتیبانی سندباکس بخش عملی است

اجرای سندباکس بومی اولین چیزی است که من به آن توجه می‌کنم. ایجنت مفید فضای کاری می‌خواهد که ورودی را بخواند، وابستگی نصب کند، دستور بزند، فایل را ویرایش کند، و مصنوع نهایی را بنویسد. قبل از این، هر تیم باید تصمیم می‌گرفت چقدر از این را خودش بسازد: لفاف shell محلی، آداپتور Docker، کلاینت سندباکس مخصوص ارائه‌دهنده، صحنه‌آرایی فایل، منطق mount، پاک‌سازی، رفتار تلاش دوباره، و نقشه فی‌البداهه اینکه خروجی کجا برود.

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

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

استدلال امنیتی اختیاری نیست

OpenAI صریح است که سیستم ایجنت باید با تلاش prompt injection و خروج داده طراحی شود. پیش‌فرض درستی است. اگر مدل سند نامطمئن بخواند و کد اجرا کند، باید فرض کنی سند ممکن است دستور داشته باشد که راز بدزدد، رفتار را عوض کند، یا داده را از راه ابزار نشت دهد.

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

من مدل را مستقیم می‌سازم

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

ایجنت بازبینی کد نباید کل محیط پروداکشن را بگیرد. checkout، شاید کش مدیر بسته، مجموعه باریک دستور، و راه تولید وصله یا گزارش کافی است. ایجنت استخراج داده باید مجموعه سند mountشده و پوشه خروجی بگیرد، نه شبکه پهن و راز اپ. ایجنت بررسی پشتیبانی شاید لاگ و trace فقط‌خواندنی بخواهد. هر تغییر باید از ابزار تأییدشده انسان رد شود.

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

فاصله TypeScript واقعی است

یک گیر مهم برای تیم JavaScript و TypeScript: طبق خود به‌روزرسانی، قابلیت تازه هارنس و سندباکس اول در Python آمده و پشتیبانی TypeScript برای بعد گفته شده. SDK جاوااسکریپت از قبل ابزارهای مفیدی دارد، از جمله shell که محلی یا در کانتینر میزبانی‌شده اجرا شود، به‌علاوه رابط apply-patch و computer-use. ولی جریان تازه‌تر سندباکس هنوز در هر دو زبان به یک اندازه در دسترس نیست. این را قبل از تعهد معماری روی سند روز چک کن، نه روی خاطره مقاله.

انتخاب تیم TypeScript-اول این است. اگر اجرا همین حالا مرکز محصول است، شاید ارزش داشته باشد کارگر ایجنت را در Python پشت API تمیز اجرا کنی و وب و بک‌اند محصول را در TypeScript نگه داری. اگر گردش کار هنوز زود است، می‌توانی با ابزارهای JS ادامه بدهی و قرارداد فضای کار را خودت طوری طراحی کنی که وقتی پشتیبانی کامل‌تر TypeScript رسید تمیز نگاشت شود.

نسخه بد این روند روشن است: به ایجنت کانتینر بزرگ بده، نصف شرکت را mount کن، شبکه را باز بگذار، و اسمش را خودمختاری بگذار. این معماری نیست. حادثه امنیتی است که منتظر یک PDF قانع‌کننده است.

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

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