‏به هر ایجنت یه کامپیوتر بده

نویسنده (Amy Ru) با این جمله شروع می‌کنه که LLMها می‌تونن استدلال کنن ولی استدلال تنها کار زیادی پیش نمی‌بره. به گفتهٔ مقاله، اجرای کد توی یه ایجنت سخت‌تر از چیزیه که به نظر می‌رسه: ایجنت به یه کامپیوتر واقعی (فایل‌سیستم، شل، پکیج‌منیجر، حالت ماندگار) نیاز داره، ولی دادن دسترسی زیرساخت خودت بهش خطرناکه. اون از قول Satya Nadella نقل می‌کنه که «هر ایجنت به یه کامپیوتر نیاز داره» و می‌گه سؤال اینه که اون کامپیوتر چه شکلیه و چطور امن بهش بدیمش.

مقاله توضیح می‌ده وقتی یه ایجنت بتونه کد اجرا کنه، یه دستهٔ کامل از کارها باز می‌شه: یه دستیار کدنویسی که فیکس رو اعمال می‌کنه و تست‌ها رو اجرا می‌کنه، یه تحلیل‌گر داده که روی CSV پایتون اجرا می‌کنه، یه ایجنت CI که ریپو رو کلون می‌کنه و PR باز می‌کنه، و یه هارنس RL که هزاران محیط موازی بالا و پایین می‌کنه. حلقهٔ بازخوردِ «اجرا کن، خطا رو ببین، درستش کن» همون چیزیه که یه ایجنت دموی رو از یه ایجنت تولیدی جدا می‌کنه.

بخش امنیتی استدلال دو پایه داره. اول: ایجنت‌ها طبق تعریف کد ناشناخته اجرا می‌کنن، چون کد ممکنه از مدل، پرامپت کاربر، یه ریپوی کلون‌شده یا یه پکیج نصب‌شده بیاد. به‌عنوان نمونه به یه کرم خودتکثیر npm به اسم Shai-Hulud اشاره می‌شه که در سپتامبر ۲۰۲۵ بیش از ۵۰۰ پکیج رو آلوده کرد و در فاز دوم به ۷۹۶ پکیج و بیش از ۲۵٬۰۰۰ ریپوی GitHub رسید؛ کدی که در مرحلهٔ preinstall و قبل از هر اعتبارسنجی‌ای اجرا می‌شد.

پایهٔ دوم اینه که کانتینر کافی نیست. به گفتهٔ نویسنده، کانتینر برای جداسازی کدِ شناخته‌شده و بررسی‌شده عالیه، ولی برای ایجنتی که داره وابستگی دلخواه نصب می‌کنه و اسکریپت تولیدشده توسط مدل اجرا می‌کنه طراحی نشده. نکتهٔ مهم اینه که کانتینرها کرنل رو با میزبان شریک‌ان، پس یه اکسپلویت کرنل ازشون رد می‌شه. به یه آسیب‌پذیری به اسم Copy Fail (با شناسهٔ CVE-2026-31431) اشاره می‌شه؛ یه اسکریپت کوچیک پایتون که از طریق API رمزنگاری کرنل، عملاً همهٔ توزیع‌های لینوکس رو روت می‌کنه. جمع‌بندی مقاله اینه که برای کد ناشناختهٔ تولیدشده توسط مدل، به جداسازی در سطح سخت‌افزار نیاز داری.

محصول LangSmith Sandboxes دقیقاً همینه: هر سندباکس یه microVM مجازی‌سازی‌شده در سطح سخت‌افزاره، نه یه کانتینر؛ یه ماشین کامل با کرنل خودش که فایل‌سیستم، شل، پکیج‌منیجر، دسترسی شبکه و حالت ماندگار داره. ایجنت می‌تونه پکیج نصب کنه، اسکریپت اجرا کنه و توی یه نشست طولانی کار کنه بدون اینکه به زیرساخت تولیدی یا سندباکس ایجنت دیگه‌ای دست بزنه؛ و وقتی کار تموم شد، سندباکس از بین می‌ره. دسترسی هم از طریق همون SDK و کلید LangSmith هست:

from langsmith import Client

client = Client()
sandbox = client.create_sandbox()
result = sandbox.run("pip install pandas && python analysis.py")
print(result.stdout)

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

نویسنده در پایان می‌گه سندباکس وقتی مناسبه که ایجنت لازمه کاری «انجام بده» نه فقط «حرف بزنه»؛ مثل وقتی کد تولید می‌کنه و می‌خوای قبل از جواب‌دادن صحت اجراش رو بسنجه، یا ورودی کاربر ممکنه اجرا بشه. ولی اگه ایجنت فقط API با اسکیمای ثابت صدا می‌زنه و کد پویا اجرا نمی‌کنه، سندباکس زیادیه. به‌عنوان نمونهٔ واقعی هم به monday.com اشاره می‌شه که با همین سندباکس‌ها به دستیار Sidekick قابلیت نوشتن و اجرای کد داده.

نکات کلیدی:

• LangChain محصول LangSmith Sandboxes رو معرفی کرده: یه کامپیوتر مجزا برای هر ایجنت تا کد اجرا کنه و حالتش رو نگه داره
• استدلال اینه که ایجنت‌ها ذاتاً کد ناشناخته اجرا می‌کنن (مثل خطر کرم Shai-Hulud در زنجیرهٔ تأمین npm)
• کانتینر چون کرنل رو با میزبان شریکه مرز امنیتی کافی نیست؛ راه‌حل یه microVM سخت‌افزاری با کرنل مستقله
• قابلیت‌ها: اسنپ‌شات و فورک کپی‌روی‌نوشتن، بلوپرینت، آدرس سرویس احرازشده و auth proxy برای محافظت از سکرت‌ها
• سندباکس وقتی به‌درد می‌خوره که ایجنت کد پویا اجرا کنه؛ برای ایجنت بازیابیِ صرف زیادیه